教程：GitHub PR 审查 Agent
问题： 你们团队开 PR 的速度，往往比人工审查的速度更快。PR 一挂就是几天，等不到人看。初级开发者可能在没人检查的情况下把 bug 合进去。你早上醒来先补 diff，而不是做真正重要的开发。
解决方案： 搭一个全天候盯着仓库的 AI agent。它会自动审查每一个新 PR，从 bug、安全问题和代码质量三个方向给出反馈，把真正需要人类判断的 PR 筛出来。
你将构建的是：
┌───────────────────────────────────────────────────────────────────┐
│ │
│ Cron Timer ──▶ Hermes Agent ──▶ GitHub API ──▶ Review │
│ (every 2h) + gh CLI (PR diffs) delivery │
│ + skill (Telegram, │
│ + memory Discord, │
│ local) │
│ │
└───────────────────────────────────────────────────────────────────┘
本指南使用 cron jobs 按计划轮询 PR，不需要服务器公网入口。放在 NAT 或防火墙后面也能用。
如果你有公网端点，可以改看 Automated GitHub PR Comments with Webhooks。那种方式由 GitHub 在 PR 创建或更新时即时推送事件给 Hermes。
前置条件
- 已安装 Hermes Agent -> 参考 Installation guide
- 已运行 gateway，供 cron 使用：
hermes gateway install # Install as a service
# or
hermes gateway # Run in foreground - 已安装并认证 GitHub CLI (
gh)：# Install
brew install gh # macOS
sudo apt install gh # Ubuntu/Debian
# Authenticate
gh auth login - 已配置消息平台（可选）-> Telegram 或 Discord
如果你暂时不接消息平台，可以用 deliver: "local" 把审查结果保存到 ~/.hermes/cron/output/。这很适合在接通知系统之前先做测试。
第 1 步：验证基础环境
先确认 Hermes 能访问 GitHub。启动一个聊天会话：
hermes
然后执行一个简单测试：
Run: gh pr list --repo NousResearch/hermes-agent --state open --limit 3
如果你能看到打开中的 PR 列表，就说明环境已经准备好了。
第 2 步：手动做一次审查
还在刚才的会话里，先让 Hermes 真实审查一个 PR：
Review this pull request. Read the diff, check for bugs, security issues,
and code quality. Be specific about line numbers and quote problematic code.
Run: gh pr diff 3888 --repo NousResearch/hermes-agent
Hermes 会：
- 执行
gh pr diff拉取代码变更 - 通读整个 diff
- 生成结构化审查结果，并给出具体发现
如果你对质量满意，就可以开始自动化了。
第 3 步：创建审查技能
技能可以给 Hermes 一套在不同会话和 cron 运行之间都保持一致的审查规则。没有技能时，审查质量会更飘。
mkdir -p ~/.hermes/skills/code-review
创建 ~/.hermes/skills/code-review/SKILL.md：
---
name: code-review
description: Review pull requests for bugs, security issues, and code quality
---
# Code Review Guidelines
When reviewing a pull request:
## What to Check
1. **Bugs** — Logic errors, off-by-one, null/undefined handling
2. **Security** — Injection, auth bypass, secrets in code, SSRF
3. **Performance** — N+1 queries, unbounded loops, memory leaks
4. **Style** — Naming conventions, dead code, missing error handling
5. **Tests** — Are changes tested? Do tests cover edge cases?
## Output Format
For each finding:
- **File:Line** — exact location
- **Severity** — Critical / Warning / Suggestion
- **What's wrong** — one sentence
- **Fix** — how to fix it
## Rules
- Be specific. Quote the problematic code.
- Don't flag style nitpicks unless they affect readability.
- If the PR looks good, say so. Don't invent problems.
- End with: APPROVE / REQUEST_CHANGES / COMMENT
验证它是否成功加载：启动 hermes 后，你应该能在启动时的技能列表中看到 code-review。
第 4 步：教会它你的团队规范
这是让审查器真正变得有用的关键。启动一个会话，然后把你们团队的标准教给 Hermes：
Remember: In our backend repo, we use Python with FastAPI.
All endpoints must have type annotations and Pydantic models.
We don't allow raw SQL — only SQLAlchemy ORM.
Test files go in tests/ and must use pytest fixtures.
Remember: In our frontend repo, we use TypeScript with React.
No `any` types allowed. All components must have props interfaces.
We use React Query for data fetching, never useEffect for API calls.
这些记忆会长期保留下来。之后审查器就会自动按你们的规范做判断，而不需要你每次重复强调。
第 5 步：创建自动 cron 任务
现在把所有东西接起来。创建一个每 2 小时运行一次的 cron 任务：
hermes cron create "0 */2 * * *" \
"Check for new open PRs and review them.
Repos to monitor:
- myorg/backend-api
- myorg/frontend-app
Steps:
1. Run: gh pr list --repo REPO --state open --limit 5 --json number,title,author,createdAt
2. For each PR created or updated in the last 4 hours:
- Run: gh pr diff NUMBER --repo REPO
- Review the diff using the code-review guidelines
3. Format output as:
## PR Reviews — today
### [repo] #[number]: [title]
**Author:** [name] | **Verdict:** APPROVE/REQUEST_CHANGES/COMMENT
[findings]
If no new PRs found, say: No new PRs to review." \
--name "pr-review" \
--deliver telegram \
--skill code-review
确认它已经被成功加入计划：
hermes cron list
其它常用计划
| Schedule | When |
|---|---|
0 */2 * * * | 每 2 小时一次 |
0 9,13,17 * * 1-5 | 工作日每天 3 次 |
0 9 * * 1 | 每周一早上一次 |
30m | 每 30 分钟一次（适合高流量仓库） |
第 6 步：按需立即运行
如果你不想等调度时间，可以手动触发：
hermes cron run pr-review
或者在聊天会话里执行：
/cron run pr-review
进一步扩展
直接把审查结果发回 GitHub
如果你不想把结果发到 Telegram，而是想直接在 PR 上评论，可以在 cron prompt 中加入这些指令：
After reviewing, post your review:
- For issues: gh pr review NUMBER --repo REPO --comment --body "YOUR_REVIEW"
- For critical issues: gh pr review NUMBER --repo REPO --request-changes --body "YOUR_REVIEW"
- For clean PRs: gh pr review NUMBER --repo REPO --approve --body "Looks good"
请确认 gh 使用的 token 带有 repo scope。审查结果会以 gh 当前认证身份发出。
每周 PR 仪表盘
你也可以做一个每周一早上的多仓库总览：
hermes cron create "0 9 * * 1" \
"Generate a weekly PR dashboard:
- myorg/backend-api
- myorg/frontend-app
- myorg/infra
For each repo show:
1. Open PR count and oldest PR age
2. PRs merged this week
3. Stale PRs (older than 5 days)
4. PRs with no reviewer assigned
Format as a clean summary." \
--name "weekly-dashboard" \
--deliver telegram
多仓库监控
如果想扩展规模，只要继续往 prompt 中添加更多仓库即可。agent 会按顺序处理它们，不需要额外配置。
故障排除
"gh: command not found"
gateway 运行在一个比较精简的环境中。请确认 gh 在系统 PATH 中，并在修改后重启 gateway。
审查结果太泛
- 添加
code-review技能（第 3 步） - 通过记忆把团队规范教给 Hermes（第 4 步）
- 它对你的技术栈了解越多，审查结果通常越好
Cron 任务没有运行
hermes gateway status # Is the gateway running?
hermes cron list # Is the job enabled?
速率限制
GitHub 对认证用户默认允许 5,000 次 API 请求 / 小时。每次 PR 审查大约消耗 3 到 5 次请求（list + diff + 可选评论）。即使你一天审查 100 个 PR，也通常远在限制之内。
接下来可以看什么
- Webhook-Based PR Reviews — 在 PR 打开时即时审查（需要公网 endpoint）
- Daily Briefing Bot — 把 PR 审查和晨间新闻摘要结合起来
- Build a Plugin — 将审查逻辑封装成可共享插件
- Profiles — 运行一个拥有独立记忆和配置的专用审查 profile
- Fallback Providers — 确保某个 provider 宕机时审查仍能继续运行