团队用27B自托管模型实现每个PR自动审查

我们的自动评审系统 MVP 现在已经覆盖主项目中的每一个仓库。上线第一个月，75% 的 PR 在 8 分钟内收到了反馈。评审由自托管模型完成，并可透明地回退到托管服务商（例如 Anthropic）。

今年年初，LLM 带来的效率提升已经足够明显，团队开始重新审视软件交付流程中的一些根本问题。代码评审是第一个被质疑的环节，因为其成本与收益的平衡已经被打破。机会成本在扩大：花在评审上的时间，就没法用来做规划、设计、实现或维护，而我们在这些任务上的效率都在提高。与此同时，同行评审带来的收益（知识传递、一致性、集体所有权）似乎在消退，因为工程师们倾向于把这件事交给自己的编码工具链。

这给我们留下了两个问题：一是实现一个系统，能够评审我们扔给它的任意数量的代码，同时不牺牲质量；二是找到替代方案，弥补不读大部分代码带来的认知缺陷。

从高层设计来看，这个评审系统就是一个“无聊的”程序化脚手架，围绕参与评审流程的专用 agent 构建。这基于两条关键设计原则。

很大一部分工作涉及系统之间通过 API 调用和数据库查询交换结构化数据——这些操作重复、可预测，用编程语言实现一次几乎不花成本，在 CPU 上运行也很便宜。唯一需要 LLM 的部分，是在大型代码库、工程实践、规格文档等背景下理解 diff。

一个通用 AI agent 可以独自完成这两类工作，但并非没有代价。用 token 预算去处理 REST API 请求并不划算。更重要的是，这种做法忽视了 LLM 的非确定性——在单次会话中几乎察觉不到，但当重复累积时，其影响就会显现。

对于一个处理连续工作流的系统来说，跨 PR 的行为必须保持一致和可预测。当 prompt 聚焦于特定任务，而不是试图用自然语言端到端地描述整个系统时，这一点更容易做到。（证据：我们花了好几个小时试图让 agent 可靠地遵守一些琐碎指令，比如输出一行 JSON 模板供下游系统解析用于审计，在正确的位置 POST 评论且不弄乱数据负载，不重复上一轮评审中已经给出的反馈。超过一半的 prompt 都在处理这些方面。）

前沿模型能做到吗？大概可以。但同样，燃烧 token，并增加验证开销来控制非确定性行为，当我们用 Python 程序和更便宜的模型就能得到相同结果时，这并不合理。

PR 本来就是多方交互的场所：人类、编码 agent、传统自动化。把未经打磨的 agent 放进这个生态，很快就演变成“瓷器店里的公牛”。有一次，一位工程师报告说他“失去了对这个 PR 的控制”，这恰恰与我们的目标相反。我们缩减了专用 agent 的数量，正是因为它们之间、它们与工程师之间、以及它们与 Claude 编码会话之间的交互有时会变得混乱。太多，也太早。

评审系统必须融入团队、提升效率而不造成干扰。因此，我们花了相当多精力观察交互动态，把系统往正确的方向引导。Nitpicker 倾向于用反馈淹没工程师，在 PR 里喷洒关于其思考过程的长篇大论、对 SonarCloud 发现的反思，或者记录前几轮评审的流水账。这些都必须通过 prompt 纠正掉。事实证明，让 agent 的 prompt 保持精简、聚焦于无法编程实现的单一目的，并把其余部分移到脚手架中，是值得的。

随着评审 agent 赢得信任，人类的贡献已经不再主要是“肉眼盯代码的时间”，而更多是高层判断。工程师把读代码委托给 agent，并介入分析评审报告、必要时深入代码、做出判断。这包括在评论线程中仲裁 Nitpicker（我们的主评审 agent）与 Claude 之间那些颇为精彩的辩论。人类的工作流和肌肉记忆也随之调整，摒弃了低效习惯，比如复制粘贴 URL 和反馈给 Claude，或者在笔记本电脑上触发 Claude 评审（那位“同事”两分钟前也已经做过了）。

GitHub PR · 检查 评审 Observer webhook + 重新同步 唯一写入者 PostgreSQL GitHub 状态 Agent 状态 审计 Loop 需要做什么工作？ Scheduler 槽位 · 权重 UI 仪表盘 Agent N 个槽位 · 任意专用 agent 1 · nitpicker 2 · handholder 3 · nitpicker 4 · 空闲 LLM harness 回退链 1 · opencode 2 · Claude webhooks 检查 入队 派发 读取 Job 结果 · 审计 评审评论 · 批准 · 标签 · push

系统有四个基本构建块。Observer 从 GitHub 接收事件，并存储项目中每个 PR 的视图。Loop 检查该视图，并向相关 agent 发出请求。Scheduler 将工作派发给 agent 并收集审计信息。UI 提供可见性和一些控制功能，任何人都可以暂停任何组件、检查审计日志、查看个人或团队范围内正在进行的工作等。

为了运行 agent，Scheduler 管理固定数量的 runner，这些 runner 会用临时的、特定于 agent 的凭证以及相关 PR 分支的 checkout 来预热。然后它组装一个 prompt，并将其管道传输到一个全新的 opencode 或 claude 会话（我们将在下面看到为什么不在同一 PR 的多次评审之间保持会话），同时处理重试、超时，并在运行后收集审计信息。扩展 Scheduler 和运行时很可能是未来的开发方向，我们关注的是类似 Agent Executor 的东西。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）