字节笔记本
2026年6月21日
hermes教程-教程:GitHub PR 审查代理
教程:构建一个 GitHub PR 审查代理
问题: 你的团队开 PR 的速度比你审查的速度还快。PR 搁置数天无人问津。初级开发人员合并了有 bug 的代码,因为没人有时间检查。你每天早上都在追赶 diff,而不是在构建。
解决方案: 一个 AI 代理,全天候监控你的仓库,审查每个新 PR 中的 bug、安全问题和代码质量,并向你发送摘要——这样你只需花时间在真正需要人工判断的 PR 上。
你将构建的内容:
┌───────────────────────────────────────────────────────────────────┐
│ │
│ Cron 定时器 ──▶ Hermes 代理 ──▶ GitHub API ──▶ 审查交付 │
│ (每 2 小时) + gh CLI (PR diff) (Telegram, │
│ + 技能 Discord, │
│ + 记忆 本地) │
│ │
└───────────────────────────────────────────────────────────────────┘本指南使用 cron 任务 按计划轮询 PR——无需服务器或公共端点。可在 NAT 和防火墙后工作。
提示——想要实时审查吗?
如果你有可用的公共端点,请查看 使用 Webhook 的自动化 GitHub PR 评论 ——当 PR 被打开或更新时,GitHub 会立即将事件推送到 Hermes。
前提条件
- 已安装 Hermes 代理 —— 参见 安装指南
- 网关正在运行 以支持 cron 任务:
bash
hermes gateway install # 安装为服务
或
hermes gateway # 在前台运行
- **已安装并认证 GitHub CLI (`gh`)**:
```bash
## 安装
brew install gh # macOS
sudo apt install gh # Ubuntu/Debian
## 认证
gh auth login提示——没有消息服务?没问题
使用
deliver: "local"将审查结果保存到~/.hermes/cron/output/。非常适合在配置通知之前进行测试。
步骤 1:验证设置
确保 Hermes 可以访问 GitHub。启动一个聊天:
hermes用一个简单命令测试:
运行:gh pr list --repo NousResearch/hermes-agent --state open --limit 3
你应该会看到打开的 PR 列表。如果这能工作,你就准备好了。
步骤 2:尝试手动审查
仍在聊天中,让 Hermes 审查一个真实的 PR:
审查这个拉取请求。阅读 diff,检查 bug、安全问题和代码质量。
要具体指出行号并引用有问题的代码。
运行:gh pr diff 3888 --repo NousResearch/hermes-agentHermes 将:
- 执行
gh pr diff获取代码变更 - 阅读整个 diff
- 生成带有具体发现的结构化审查
如果你对质量满意,就可以自动化了。
步骤 3:创建一个审查技能
技能为 Hermes 提供一致的审查指南,这些指南在会话和 cron 运行之间持久存在。没有技能,审查质量会参差不齐。
mkdir -p ~/.hermes/skills/code-review创建 ~/.hermes/skills/code-review/SKILL.md:
---
name: code-review
description: 审查拉取请求中的 bug、安全问题和代码质量
---
## 代码审查指南
审查拉取请求时:
## 检查内容
1. **Bug** —— 逻辑错误、差一错误、null/undefined 处理
2. **安全** —— 注入、认证绕过、代码中的密钥、SSRF
3. **性能** —— N+1 查询、无界循环、内存泄漏
4. **风格** —— 命名约定、死代码、缺少错误处理
5. **测试** —— 变更是否经过测试?测试是否覆盖了边界情况?
## 输出格式
对于每个发现:
- **文件:行号** —— 确切位置
- **严重性** —— 严重 / 警告 / 建议
- **问题** —— 一句话描述
- **修复** —— 如何修复
## 规则
- 要具体。引用有问题的代码。
- 不要标记风格上的吹毛求疵,除非它们影响可读性。
- 如果 PR 看起来不错,就直说。不要编造问题。
- 以以下之一结束:APPROVE / REQUEST_CHANGES / COMMENT验证它已加载——启动 hermes,你应该在启动时看到技能列表中有 code-review。
步骤 4:教会它你的约定
这是让审查者真正有用的关键。启动一个会话,教会 Hermes 你团队的标准:
记住:在我们的后端仓库中,我们使用 Python 和 FastAPI。
所有端点必须有类型注解和 Pydantic 模型。
我们不允许使用原始 SQL —— 只使用 SQLAlchemy ORM。
测试文件放在 tests/ 中,并且必须使用 pytest fixtures。记住:在我们的前端仓库中,我们使用 TypeScript 和 React。
不允许使用 `any` 类型。所有组件必须有 props 接口。
我们使用 React Query 进行数据获取,永远不要使用 useEffect 进行 API 调用。这些记忆会永久保留——审查者会在不每次告知的情况下强制执行你的约定。
步骤 5:创建自动化 Cron 任务
现在将所有内容连接起来。创建一个每 2 小时运行一次的 cron 任务:
hermes cron create "0 */2 * * *" \
"检查新的打开 PR 并进行审查。
要监控的仓库:
- myorg/backend-api
- myorg/frontend-app
步骤:
1. 运行:gh pr list --repo REPO --state open --limit 5 --json number,title,author,createdAt
2. 对于每个在过去 4 小时内创建或更新的 PR:
- 运行:gh pr diff NUMBER --repo REPO
- 使用 code-review 指南审查 diff
3. 格式化输出为:
## PR 审查 — 今天
### [repo] #[number]: [title]
**作者:** [name] | **裁决:** APPROVE/REQUEST_CHANGES/COMMENT
[发现]
如果没有找到新 PR,则输出:没有新的 PR 需要审查。" \
--name "pr-review" \
--deliver telegram \
--skill code-review验证它已安排:
hermes cron list其他有用的调度
| 调度 | 时间 |
|---|---|
0 */2 * * * | 每 2 小时 |
0 9,13,17 * * 1-5 | 每天三次,仅工作日 |
0 9 * * 1 | 每周一早上汇总 |
30m | 每 30 分钟(高流量仓库) |
步骤 6:按需运行
不想等待调度?手动触发:
hermes cron run pr-review或者在聊天会话中:
/cron run pr-review
更进一步
直接将审查发布到 GitHub
不交付到 Telegram,而是让代理直接在 PR 上评论:
将以下内容添加到你的 cron 提示中:
审查后,发布你的审查:
- 对于问题:gh pr review NUMBER --repo REPO --comment --body "YOUR_REVIEW"
- 对于严重问题:gh pr review NUMBER --repo REPO --request-changes --body "YOUR_REVIEW"
- 对于干净的 PR:gh pr review NUMBER --repo REPO --approve --body "Looks good"注意
确保
gh拥有具有repo范围的令牌。审查将以gh认证的用户身份发布。
每周 PR 仪表板
创建所有仓库的周一早上概览:
hermes cron create "0 9 * * 1" \
"生成每周 PR 仪表板:
- myorg/backend-api
- myorg/frontend-app
- myorg/infra
对于每个仓库显示:
1. 打开的 PR 数量和最旧 PR 的年龄
2. 本周合并的 PR
3. 过时的 PR(超过 5 天)
4. 没有分配审查者的 PR
格式化为清晰的摘要。" \
--name "weekly-dashboard" \
--deliver telegram多仓库监控
通过向提示中添加更多仓库来扩展。代理会顺序处理它们——无需额外设置。
故障排除
"gh: command not found"
网关在最小环境中运行。确保 gh 在系统 PATH 中,并重启网关。
审查过于泛泛
- 添加
code-review技能(步骤 3) - 通过记忆教会 Hermes 你的约定(步骤 4)
- 它对你的技术栈了解得越多,审查效果就越好
Cron 任务不运行
hermes gateway status # 网关是否在运行?
hermes cron list # 任务是否已启用?速率限制
GitHub 允许认证用户每小时 5,000 次 API 请求。每次 PR 审查大约使用 3-5 次请求(列表 + diff + 可选评论)。即使每天审查 100 个 PR,也远在限制之内。
下一步是什么?
- 基于 Webhook 的 PR 审查 —— 当 PR 打开时立即获得审查(需要公共端点)
- 每日简报机器人 —— 将 PR 审查与你的早间新闻摘要结合起来
- 构建一个插件 —— 将审查逻辑封装成可共享的插件
- 配置文件 —— 运行一个专用的审查者配置文件,拥有自己的记忆和配置
- 回退提供者 —— 确保即使一个提供者宕机,审查也能运行