ByteNoteByteNote

字节笔记本

2026年6月21日

hermes教程-教程:GitHub PR 审查代理

API中转
¥120

教程:构建一个 GitHub PR 审查代理

问题: 你的团队开 PR 的速度比你审查的速度还快。PR 搁置数天无人问津。初级开发人员合并了有 bug 的代码,因为没人有时间检查。你每天早上都在追赶 diff,而不是在构建。

解决方案: 一个 AI 代理,全天候监控你的仓库,审查每个新 PR 中的 bug、安全问题和代码质量,并向你发送摘要——这样你只需花时间在真正需要人工判断的 PR 上。

你将构建的内容:

text
┌───────────────────────────────────────────────────────────────────┐
│                                                                   │
│   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 # 在前台运行

text
- **已安装并认证 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。启动一个聊天:

bash
hermes

用一个简单命令测试:

运行:gh pr list --repo NousResearch/hermes-agent --state open --limit 3

你应该会看到打开的 PR 列表。如果这能工作,你就准备好了。


步骤 2:尝试手动审查

仍在聊天中,让 Hermes 审查一个真实的 PR:

text
审查这个拉取请求。阅读 diff,检查 bug、安全问题和代码质量。
要具体指出行号并引用有问题的代码。

运行:gh pr diff 3888 --repo NousResearch/hermes-agent

Hermes 将:

  1. 执行 gh pr diff 获取代码变更
  2. 阅读整个 diff
  3. 生成带有具体发现的结构化审查

如果你对质量满意,就可以自动化了。


步骤 3:创建一个审查技能

技能为 Hermes 提供一致的审查指南,这些指南在会话和 cron 运行之间持久存在。没有技能,审查质量会参差不齐。

bash
mkdir -p ~/.hermes/skills/code-review

创建 ~/.hermes/skills/code-review/SKILL.md

markdown
---
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 你团队的标准:

text
记住:在我们的后端仓库中,我们使用 Python 和 FastAPI。
所有端点必须有类型注解和 Pydantic 模型。
我们不允许使用原始 SQL —— 只使用 SQLAlchemy ORM。
测试文件放在 tests/ 中,并且必须使用 pytest fixtures。
text
记住:在我们的前端仓库中,我们使用 TypeScript 和 React。
不允许使用 `any` 类型。所有组件必须有 props 接口。
我们使用 React Query 进行数据获取,永远不要使用 useEffect 进行 API 调用。

这些记忆会永久保留——审查者会在不每次告知的情况下强制执行你的约定。


步骤 5:创建自动化 Cron 任务

现在将所有内容连接起来。创建一个每 2 小时运行一次的 cron 任务:

bash
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

验证它已安排:

bash
hermes cron list

其他有用的调度

调度时间
0 */2 * * *每 2 小时
0 9,13,17 * * 1-5每天三次,仅工作日
0 9 * * 1每周一早上汇总
30m每 30 分钟(高流量仓库)

步骤 6:按需运行

不想等待调度?手动触发:

bash
hermes cron run pr-review

或者在聊天会话中:

/cron run pr-review

更进一步

直接将审查发布到 GitHub

不交付到 Telegram,而是让代理直接在 PR 上评论:

将以下内容添加到你的 cron 提示中:

text
审查后,发布你的审查:
- 对于问题: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 仪表板

创建所有仓库的周一早上概览:

bash
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 中,并重启网关。

审查过于泛泛

  1. 添加 code-review 技能(步骤 3)
  2. 通过记忆教会 Hermes 你的约定(步骤 4)
  3. 它对你的技术栈了解得越多,审查效果就越好

Cron 任务不运行

bash
hermes gateway status    # 网关是否在运行?
hermes cron list         # 任务是否已启用?

速率限制

GitHub 允许认证用户每小时 5,000 次 API 请求。每次 PR 审查大约使用 3-5 次请求(列表 + diff + 可选评论)。即使每天审查 100 个 PR,也远在限制之内。


下一步是什么?



分享: