OpenClaw 代码审查 Agent 搭建
让AI替你Review代码 — 安全扫描、质量检测、最佳实践检查全自动
凌晨1点22分,有个PR提交了327行代码。没人Review,它就merge了。第二天生产环境炸了。如果当时有个Agent帮你看一眼——哪怕只是说一句"这个SQL拼接有注入风险",故事就不一样了。
代码审查Agent架构
Code Review Agent
│
├─── 触发层
│ ├─ GitHub Webhook (PR创建/更新)
│ ├─ 定时任务 (每日Review积压)
│ └─ 手动触发 (指定PR号)
│
├─── 分析层
│ ├─ Diff解析 → 提取变更文件
│ ├─ 安全扫描 → SQL注入、XSS、密钥泄露
│ ├─ 代码质量 → 复杂度、重复代码、命名规范
│ ├─ 最佳实践 → 设计模式、错误处理、日志
│ └─ 性能分析 → N+1查询、内存泄漏、锁竞争
│
└─── 输出层
├─ PR评论 (行内Review)
├─ Review Summary (整体评估)
├─ Labels (auto-label: review-needed)
└─ 告警通知 (严重问题飞书通知)
第一步:创建Code Review Agent
# 创建Agent目录
mkdir -p ~/.openclaw/agents/code-reviewer
cd ~/.openclaw/agents/code-reviewer
SOUL.md - Agent人设
# SOUL.md
_我是一个代码审查Agent,我的工作是确保每一行代码都是安全的、高效的、可维护的。_
## 评审标准
### 🔴 阻断级 (必须修复才能合并)
- SQL注入、XSS、CSRF等安全漏洞
- 硬编码密钥、Token、密码
- 未处理的异常导致进程崩溃
- 数据竞争、死锁
- 删除/覆盖生产数据无确认
### 🟡 建议级 (建议修复)
- 函数超过50行
- 嵌套超过3层
- 变量命名不清晰 (tmp, x, data2)
- 缺少错误处理
- 未添加日志
- Magic number
### 🟢 优化级 (可选)
- 可以用更简洁的写法
- 性能有优化空间但不紧急
- 可以提取为公共函数
## 评审风格
- 直接指出问题,不绕弯子
- 给出具体的修改建议和代码示例
- 区分"必须修"和"建议修"
- 对好的代码给予肯定
AGENTS.md - 配置
# AGENTS.md
## 身份
Code Review Agent - 自动化代码审查
## 工作流程
1. 接收PR通知(GitHub Webhook)
2. 获取PR diff和上下文
3. 分析每个变更文件
4. 生成Review评论
5. 提交Review到GitHub
## 检查规则
- 安全: SQL注入、XSS、密钥泄露、路径遍历
- 质量: 复杂度、重复代码、命名规范
- 最佳实践: 错误处理、日志、测试覆盖
- 性能: N+1查询、内存泄漏、缓存使用
## 输出格式
### 评审摘要
- 变更文件: X个
- 🔴 阻断问题: X个
- 🟡 建议: X个
- 🟢 优化: X个
- 总体评价: Approve / Request Changes / Comment
## 限制
- 不直接修改代码
- 不自动Approve包含🔴问题的PR
- 对不确定的问题标记为⚠️
第二步:配置GitHub集成
# 配置GitHub权限
gh auth login
# 设置GitHub Webhook
# 接收 pull_request 和 pull_request_review 事件
# Webhook URL:
https://your-openclaw-gateway.com/webhook/github
# 事件:
# - pull_request (opened, synchronize, reopened)
# - pull_request_review (submitted)
第三步:实现审查逻辑
PR审查流程
# 典型的PR审查流程
# 1. 获取PR信息
gh pr view 123 --json title,body,files,additions,deletions
# 2. 获取Diff
gh pr diff 123 > /tmp/pr-123.diff
# 3. 分析变更文件
for file in $(gh pr view 123 --json files -q '.files[].path'); do
# 检查文件类型
case $file in
*.py) check_python "$file" ;;
*.js|*.ts) check_javascript "$file" ;;
*.sql) check_sql "$file" ;;
*.yaml|*.yml) check_config "$file" ;;
esac
done
# 4. 生成Review评论
# 使用LLM分析diff并生成Review
# 5. 提交Review
gh pr review 123 --body "$(cat review_summary.md)" \
--request-changes # 或 --approve
安全扫描规则
# security_rules.yaml
rules:
# SQL注入
- name: sql_injection
pattern: '(\+|format|f["\']).*SELECT.*FROM.*\{|execute\(["\'].*\+\s*\w+'
severity: critical
message: "⚠️ 可能存在SQL注入风险。请使用参数化查询。"
fix: |
# 差
db.execute(f"SELECT * FROM users WHERE id = {user_id}")
# 好
db.execute("SELECT * FROM users WHERE id = %s", (user_id,))
# XSS
- name: xss_risk
pattern: 'innerHTML\s*=|document\.write\(|\.html\(\s*["\'].*\+'
severity: critical
message: "⚠️ 可能存在XSS风险。请对用户输入进行转义。"
# 密钥泄露
- name: secret_leak
pattern: '(?:api_key|secret|password|token)\s*[=:]\s*["\'][^"\']{8,}["\']'
severity: critical
message: "🔴 疑似硬编码密钥!请使用环境变量。"
fix: |
# 差
API_KEY = "sk-1234567890abcdef"
# 好
API_KEY = os.environ["API_KEY"]
# 路径遍历
- name: path_traversal
pattern: 'open\(.*\+\s*(?:request|input|param|user)|os\.path\.join\(\s*["\']\/'
severity: critical
message: "⚠️ 可能存在路径遍历风险。请验证路径。"
代码质量规则
# quality_rules.yaml
rules:
- name: function_too_long
check: "function_lines > 50"
severity: warning
message: "函数超过50行,建议拆分为更小的函数"
- name: deep_nesting
check: "indentation_depth > 4"
severity: warning
message: "嵌套超过4层,考虑使用 early return 或提取函数"
- name: magic_number
pattern: '(?
第四步:提交Review
# 生成Review并提交
## Review模板
### 代码审查摘要 — PR #123
**变更概览:**
- 文件: 5个 (+237/-89)
- 🔴 阻断问题: 2个
- 🟡 建议: 4个
- 🟢 优化: 3个
**🔴 阻断问题:**
1. `src/api/users.py:47` — SQL注入风险
\`\`\`python
# 当前代码
cursor.execute(f"SELECT * FROM users WHERE name = '{name}'")
# 建议修改
cursor.execute("SELECT * FROM users WHERE name = %s", (name,))
\`\`\`
2. `config/database.py:12` — 硬编码数据库密码
\`\`\`python
PASSWORD = "admin123" # ← 请使用环境变量
\`\`\`
**评审结果:** Request Changes
请修复🔴问题后重新提交Review。
定时审查任务
# cron定时审查积压PR
# 每天早上9点检查未Review的PR
openclaw cron add \
--name "daily-pr-review" \
--schedule "0 9 * * 1-5" \
--task "检查所有标记为 review-needed 的PR,执行代码审查"
# 每周生成审查报告
openclaw cron add \
--name "weekly-review-report" \
--schedule "0 18 * * 5" \
--task "汇总本周所有PR审查结果,生成质量趋势报告"
最佳实践
- 分级审查 — 大PR先整体看,小PR逐行看。超过500行变更建议先拆分
- 关注Diff — 只看变更部分,不看整个文件
- 提供上下文 — 评论中包含"为什么"和"怎么改"
- 标记置信度 — 不确定的标注为⚠️,让人类判断
- 正面反馈 — 发现好代码也要说一句"这个设计不错"
💡 人机协作:Code Review Agent不是替代人类审查,而是第一道防线。Agent处理80%的常规检查(安全漏洞、格式问题、明显Bug),人类专注20%的设计审查和业务逻辑判断。这样效率最高。