1. 为什么我要把 PR 审查交给 Hermes 和统一 Key每次提 PR最怕的不是 CI 红而是没人 review。团队小、节奏快代码评审经常拖到第二天等来的还可能是「LGTM」三个字母。我试过把 AI 拉进评审流程但很快撞上两个现实问题一是每个仓库、每个脚本都要单独配一份模型 Key散落在各种.env和 CI Secret 里轮换一次要改十几个地方二是 Webhook 触发之后怎么把 diff 稳定地喂给模型、再把评审意见准确回写到 PR 评论中间链路全靠自己拼。Hermes 的 GitHub PR 审查能力正好补上后半段它内置 Webhook 监听、路由配置、技能系统和投递层PR 一提交就能触发 AI 审查并发布评论。而前半段的「统一 Key」问题我用 TaoToken 来解决——一个 Key 走通所有模型调用Hermes 的settings.json/config.toml里只填一处Webhook 触发的评审请求全部经这条通道出去。这篇就把这条端到端链路拆开Webhook 怎么配、Key 怎么接、PR 怎么验证、报错怎么排。适合谁看手上有一两个活跃仓库、想让 PR 自动过一遍 AI 评审、又不想维护一堆 Key 的开发者。全程可复制配置骨架直接抄。2. TaoToken 前置一个 Key 打通评审链路Hermes 的评审流程里模型调用发生在「Agent 拿到 diff 之后」。也就是说Webhook 只负责把 PR 事件送进来真正烧 token 的是后面那次 AI 审查。如果这一步的 Key 管理是散的整条链路的可维护性就很差。TaoToken 在这里的角色是统一入口官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。你只需要在 TaoToken 控制台生成一个 Key然后把它写进 Hermes 的配置里Webhook 触发的每一次评审都复用这一个 Key。具体要准备三样东西第一TaoToken 的 API Key。登录控制台在 API Keys 页面创建一个复制出来。这个 Key 就是后面settings.json里api_key字段的值。第二确认模型名。TaoToken 兼容主流模型调用格式你在配置里填的model字段要和通道支持的模型名一致。评审场景我一般选推理能力强的模型diff 长了也不容易漏掉边界问题。第三本地或服务器上跑着 Hermes并且能对外暴露一个 Webhook 端口默认 8644。GitHub 要能访问到这个地址所以本地调试建议用内网穿透工具把端口映射出去或者直接部署在有公网 IP 的机器上。注意Webhook 的 Secret 和 TaoToken 的 API Key 是两回事。前者用来验证「这个请求确实来自 GitHub」后者用来调用模型。两个都要配别混。拿到 Key 之后先别急着配 Webhook先把 Hermes 的模型通道接通确认单次调用能通再去接 GitHub 事件。顺序反了的话出问题你分不清是 Key 错还是 Webhook 错。3. 可复制配置settings.json 与 config.toml 骨架Hermes 的配置分两层模型通道配置Key、endpoint、model和 Webhook 路由配置端口、secret、routes。前者我放在settings.json后者放在config.toml职责清晰改起来不打架。3.1 settings.json接入 TaoToken 统一 Key{ providers: { taotoken: { type: openai-compatible, base_url: https://taotoken.net/api, api_key: sk-your-taotoken-key, model: your-preferred-model, timeout: 120 } }, default_provider: taotoken }几个字段说明一下。type填openai-compatible因为 TaoToken 的 API 端点兼容这套调用格式。base_url就是 https://taotoken.net/api 注意不要带多余的路径后缀。api_key填你在控制台生成的那个。timeout给到 120 秒PR diff 大的时候模型响应会慢一些超时太短会误判成失败。default_provider指向taotoken这样 Hermes 里所有没显式指定 provider 的调用都走这条通道包括 Webhook 触发的评审。3.2 config.tomlWebhook 与路由骨架[platforms.webhook] enabled true port 8644 secret global-fallback-secret [platforms.webhook.routes.github-pr] events [pull_request] secret github-webhook-secret prompt Review this pull request: Repository: {repository.full_name} PR #{number}: {pull_request.title} Author: {pull_request.user.login} URL: {pull_request.html_url} Diff URL: {pull_request.diff_url} Action: {action} skills [github-code-review] deliver github_comment deliver_extra { repo {repository.full_name}, pr_number {number} }这里的关键点routes.github-pr里的secret必须和 GitHub Webhook 页面填的 Secret 完全一致Hermes 会用它对请求做 HMAC-SHA256 校验。events只勾pull_request避免 issues、push 之类的事件也触发评审。prompt里的{...}是变量占位Hermes 会从 GitHub 的 payload 里按点号路径取值比如{pull_request.user.login}就是提 PR 的人。deliver github_comment表示评审结果通过ghCLI 回写成 PR 评论。deliver_extra把仓库名和 PR 号传进去告诉gh评论发到哪个 PR。3.3 认证 gh CLI回写评论依赖gh所以要先登录gh auth login # 按提示选择 GitHub.com → HTTPS → 浏览器授权 gh auth status # 确认输出 Logged in to github.comgh auth status显示已登录说明评论回写这条腿是通的。如果这一步没过后面 Webhook 触发了、模型也审了但评论发不出去你会以为是模型问题其实是 CLI 没认证。4. 验证请求从 PR 提交到评论回写配置齐了走一遍完整验证。这一步的目标是看到「PR 上真的出现了一条 AI 评审评论」。4.1 在 GitHub 创建 Webhook进入仓库 → Settings → Webhooks → Add webhook。Payload URL 填http://your-server:8644/webhooks/github-prContent type 选application/jsonSecret 填和config.toml里github-webhook-secret一样的值。事件选择那里选「Let me select individual events」只勾Pull requests。保存后 GitHub 会发一个 ping 事件Hermes 日志里应该能看到收到请求。如果 ping 都收不到先查网络和端口别往下走。4.2 启动 Hermes 并观察日志hermes gateway # 前台运行方便看实时日志启动后确认 Webhook 监听在 8644。然后提交一个测试 PRgit checkout -b test-pr-review echo // test change src/demo.js git add . git commit -m test: trigger ai review git push origin test-pr-review # 在 GitHub 上创建 PRPR 一创建GitHub 就会发pull_request事件。Hermes 收到后按路由配置走校验 secret → 渲染 prompt → 注入github-code-review技能 → 调用 TaoToken 通道的模型 → 拿到评审结果 → 通过gh回写评论。4.3 成功结果长什么样几秒到几十秒后取决于 diff 大小和模型速度PR 页面会出现一条评论内容大致是分点的评审意见潜在 bug、命名建议、边界条件提醒。同时 Hermes 日志里能看到这次调用的 token 消耗和耗时。如果评论出现了说明整条链路通了Webhook 触发正常、Key 通道正常、技能加载正常、评论回写正常。这时候你可以把测试 PR 关掉正式用起来。5. 本篇常见错排查5.1 Webhook 返回 401 或 403八成是 secret 不匹配。GitHub 那边填的 Secret 和config.toml里routes.github-pr.secret必须逐字符一致注意别把global-fallback-secret和路由 secret 搞混。改完 secret 后 GitHub 需要重新发一次事件才能验证。5.2 模型调用报鉴权失败检查settings.json里的api_key是不是 TaoToken 控制台生成的那个base_url是不是 https://taotoken.net/api 。如果 Key 刚生成确认没有多余空格。另外确认default_provider指向的是taotoken别指向了一个没配 Key 的 provider。5.3 评论发不出来但日志显示评审完成这是ghCLI 的问题。跑gh auth status确认登录状态再确认运行 Hermes 的用户和登录gh的用户是同一个。服务器上跑的话gh auth login要用 token 方式别用浏览器授权。5.4 变量渲染成字面量比如评论里出现{pull_request.title}原样输出。说明 payload 里没有这个字段或者路径写错了。Hermes 对缺失的键保留字面量不会报错。用{__raw__}把整个 payload 打出来会截断到 4000 字符对照着改路径。5.5 触发太频繁或误触发默认限速 30 请求/分钟Body 限制 1 MB。如果仓库 PR 很密集可能撞限速。另外确认events只勾了pull_request别把push也勾上否则每次 push 都会触发一次评审token 消耗会失控。6. 把评审链路固定下来跑通之后我建议做两件事让这条链路更稳。第一把github-code-review技能的内容按团队规范调一遍。技能文件里定义了评审的关注点比如是否检查测试覆盖、是否强制要求错误处理。改技能比改 prompt 更清晰也更容易复用。第二给 Webhook 加个失败告警。Hermes 的投递层支持多平台你可以在路由里加一个deliver到 Telegram 或 Discord 的配置评审失败时推一条消息别等 PR 挂了一天没人发现。长期做编码和 Agent 自动化的可以考虑 Coding Plan 这类按周期计费的方案把评审、补全、Agent 调用都归到一个额度里比零散按次调用好管。模型对话调试可以直接在模型对话页面验证 prompt 效果接入文档在接入文档Key 管理在 API Keys。这条链路的价值不在于「AI 帮你 review」而在于它把评审从「等人」变成「等几秒」而且每次评审的标准是一致的。Key 统一之后你换模型、调额度、加仓库都只动一处配置。