不止审一次代码：用 Holon 搭建持续跟进 PR 的 Reviewer

蓝色 Reviewer 面对代码面板，前方的 PR 流程依次展示修改、等待与检查通过。

案例来自 Holon 仓库自身的 holon-reviewer；案例记录采集于 2026 年 9 月 10 日。

作者推送了修复，reviewer 确认原来的问题已经解决。几分钟后，CI 又红了。

Holon 仓库的 PR #2854 就经历过这个过程。它修改了工作项的完成行为：Agent 完成另一项工作时，不应连带结束自己正在执行的工作。第一次修复解决了调度问题，却带入了错误的测试期望；reviewer 再次提出阻塞意见，直到作者修正、最终版本的检查通过，才进入合并与收尾。

代码版本	审阅判断	后续动作
`589405cc`	两个调度端到端测试失败，定位到工作项分类错误	提出阻塞意见，等待修复
`19f390ca`	原问题已修复，调度检查通过；另一条测试期望被改反	再次提出阻塞意见，等待新版本
`f7b93809`	测试期望恢复，最终版本的相关检查通过	确认合并结果，完成工作项

这一过程发生在 2026 年 9 月 9 日，提交、公开审阅与合并结果已和 GitHub 快照核对。部分 CI 任务按条件跳过，表中的“通过”只指实际执行的相关检查。

在 2026 年 6 月 12 日至 9 月 12 日的三个月里，Holon Reviewer 参与审阅了 Holon 仓库的 763 个已合并 PR，覆盖同期 804 个已合并 PR 的约 95%，在这些 PR 上累计提交 1,529 次审阅。

以上合并统计 holonbot 与本机 Reviewer 使用的个人 GitHub 账号 jolestar，排除 Copilot；覆盖的 PR 数按 PR 去重。

下面创建一个 reviewer，让它自动接手仓库的新 PR，在修复和 CI 更新后继续跟进。

从模板创建 Reviewer

先按创建第一个 Agent完成 Holon 安装、模型配置，并启动常驻 runtime。运行 Holon 的机器需要能访问目标仓库，备好 GitHub CLI（gh）及项目测试工具。持续接收事件还会用到 AgentInbox 和 UXC，后面会检查接入。

在自己的终端中，从官方模板创建一个名为 reviewer 的 Agent：

holon agent create reviewer --template https://github.com/holon-run/holon/tree/4895eafce1926cb4cc4687c5b9a99c13b071a1e4/agent_templates/code-reviewer

这里固定模板版本，避免命令依赖 holon-reviewer 更名为 code-reviewer 的改动何时进入 main。如果已经安装或同步了更名后的模板，也可以用模板名；两种方式选一种即可：

holon agent create reviewer --template code-reviewer

reviewer 是你创建的 Agent 名称，code-reviewer 是模板名。若已有同名 Agent，换一个名称，不要覆盖原来的工作记录。

创建后运行 holon agent list，确认新 Agent 出现在列表中，再从 TUI 或 Web GUI 选择它。

模板内置的 AGENTS.md

code-reviewer 模板包含 AGENTS.md，创建时用它初始化新 Agent 的工作规范，并安装模板声明的 Skills。下面摘录文件中的职责定义和权限确认清单：

# Code Reviewer Agent

You are a long-lived code review agent responsible for code review, PR
lifecycle tracking, and merge decisions.

## Permission Confirmation Protocol

For **non-one-time** review work, confirm the following with the operator
before starting, then record the confirmed scope in your agent-local
AGENTS.md:

- whether you may merge PRs
- whether you should subscribe to PR events via `agentinbox` follow
- whether you may approve PRs
- whether you may fix code on behalf of the author

这份规范要求 Agent 审代码、跟进 PR、判断能否合并。开始持续工作前，它需要向你确认权限，并记入自己的 AGENTS.md。安装模板不会自动授予合并权限。

文件后面的章节规定了怎么工作：

持续跟进：为 PR 建立 WorkItem，订阅新提交、CI 和审阅评论；新版本到达后先复查旧问题，合并或关闭后完成工作项、清理订阅。
合并门槛：最终 head 的必要 CI 全部通过，没有未解决的阻塞问题；普通建议不应被当成阻塞，也不能绕过 GitHub 的平台限制。
升级处理：大规模重构、破坏性 API 变更或安全敏感修改交给操作者判断；未经授权，不主动代作者修代码。

审阅的具体方法由 Skills 提供：code-review 规定证据、问题分类和验证范围，github-review 负责 GitHub 上的上下文收集、去重与审阅发布。ghx、sview 辅助平台操作和源码阅读，agentinbox、uxc 负责事件接入。

你只需补充项目要求，不用从头写审阅提示词。要调整通用职责或替换 Skills，可以参考Agent 模板指南。

开始前确认职责与合并权限

向 reviewer 说明负责的仓库、项目要求和操作权限：

负责 <owner/repo> 的 PR，订阅仓库并自动审阅新 PR，持续跟进到合并或关闭。
本地仓库在 <绝对路径>，重点看兼容性，中文反馈；允许隔离测试、评论和批准。
最终版本的必要检查通过、无遗留阻塞且符合仓库合并规则时，可以直接合并。
不代作者修代码；重大或安全敏感变更先问我。请记住这些长期要求。

让 reviewer 确认并记入自己的 AGENTS.md，后续新 PR 沿用这份授权。构建、测试和代码约定优先读取仓库本身的 AGENTS.md；如果团队只允许 squash 合并，也在这里说明。

这份授权还需要 GitHub 账号具备相应权限，并遵守仓库保护规则。模板不提供凭据。首次试用选自己熟悉的低风险 PR，并为测试准备隔离环境。

订阅仓库，自动发现 PR

职责确认后，接通事件来源。Holon 仓库自身的 holon-reviewer 在工作规范中采用两层订阅：

仓库订阅长期保留，发现新开的 PR，让 reviewer 自动开始审阅。
每条 PR 单独跟进，接收后续提交、CI 和审阅评论；合并或关闭后，清理该 PR 的订阅。

模板提供逐 PR 跟进规则与接入 Skills，前面的授权确定仓库和自动接手范围。外部服务仍需单独认证、订阅。

事件通过 AgentInbox 接收，再通知 Holon 恢复工作；GitHub 适配会用到 UXC。让 reviewer 按自带的 Skill 完成接入即可：

请按 agentinbox Skill 接通这个仓库的新 PR 订阅和逐 PR 的 CI、评论跟进，缺少工具或认证时告诉我。

reviewer 会按 Skill 检查服务、仓库访问和自己的唤醒目标，并指出需要你完成的安装或认证。凭据通过工具的认证流程配置，不要贴进对话。接入细节见AgentInbox 接入指南。

接入后，让它确认仓库发现订阅已生效。不要假定新事件订阅会补齐历史；要接管已有的未关闭 PR，再补一句“也接管当前打开的 PR”。

检查它是否自动开始审阅

等仓库出现一条适合试运行的新 PR，观察 reviewer 能否从事件发现它，自动建立 WorkItem 并开始审阅。这次不要手动发送 PR 地址。

如果新 PR 出现后没有开始审阅，先检查仓库发现订阅、AgentInbox 的事件记录和 reviewer 的唤醒目标。手动发一条 PR 可以测试单次审阅，但不能证明仓库自动接入已经生效。

打开这条 PR 对应的 WorkItem，应该能找到已审 head、问题与证据、已经完成的验证，以及下一步在等什么。修复到达时，reviewer 就能拿新版本对照上次的阻塞项。

首次审阅结果可以按这份示例检查：

已审版本：<head SHA>
阻塞问题：<问题、位置与依据>；或本次未发现阻塞问题
验证：<已执行的测试和结果>；<未覆盖的范围>
下一步：等待 <作者修复 / 当前 head 的 CI / 维护者决定>

验证一次真正的持续复查

先让现有 CI 跑完，检查 reviewer 是否收到事件并更新检查结果。再等作者正常提交更新，观察它是否回到同一条 PR 的 WorkItem，复查新版本。期间不用发“请继续”。CI 通知和新提交都要检查，前者不能替代后者。

核对复查记录：

记录写明新 head，引用的 CI 属于这个版本。
旧问题逐项说明已修复或仍存在，新增问题另列。
写清还在等什么，或需要你做什么决定。

如果 AgentInbox 已收到事件，reviewer 却没有恢复，先检查唤醒目标、runtime 是否在线及工作项等待条件；如果恢复了却仍引用旧 CI，就要求它重新核对提交。补发一句“继续”可以临时推进工作，但不能代替这次接入验证。

PR #2854 的第二版修好了旧问题，却带入了另一个错误。复查记录需要区分两者，让作者知道下一步该改哪里。

合并与收尾

最终 head 的必要检查通过、没有遗留阻塞且符合仓库规则后，reviewer 可以按授权直接合并。需要升级处理的变更，或权限、检查不满足要求的 PR，应先说明原因，交给你决定。

交付应写明实际合并结果、最终提交和未验证范围。PR 合并或关闭后，reviewer 按模板要求确认终态、完成 WorkItem，并清理该任务的订阅；共享事件源留给其他工作。

保留仓库订阅，reviewer 就能继续接手新 PR，只在需要你决策时请你介入。若要保留人工合并，将长期授权改为“达到合并条件时通知我，由我合并”即可。

案例来源

文中的 PR #2854 使用了完整工作计划及 GitHub 提交、审阅、检查和合并快照。本次未重新执行案例中的测试，也未独立验证订阅清理结果。