最近，我连续实践了一套以 Issue、分支、PR 和验证证据为中心的 Agent 开发流程。不同任务的技术栈和交付目标并不相同，但复盘后呈现出一个非常一致的结论：Agent 可以显著提高写代码和补验证的吞吐，真正决定交付质量的却仍然是任务边界、证据链和合并治理。

这篇文章不介绍具体项目，也不是某个模型的能力评测，更不试图证明“一个人加多个 Agent 等于一支完整团队”。我只讨论一个工程问题：当 Agent 已经能并行实现大量任务时，怎样让这些产出成为可审查、可合并、可追责、可回滚的工程交付。

先说结论：协作中心不是聊天窗口

在连续实践中，最稳定的数据流都不是 Agent 之间共享对话，而是：

需求与约束
  -> Issue：目标、边界、风险、验收标准
  -> Branch / Worktree：隔离写入
  -> PR：差异、测试和未完成项
  -> CI / 人工证据：判断是否可合并
  -> Merge：形成新的主干事实

Claude Code、Codex、Gemini CLI 或其他 Agent 只是这个数据流中的执行运行时。模型可以替换，事实源不能漂移。真正需要长期保留的是 Issue、代码差异、测试结果、审批和发布证据，而不是某次对话里 Agent 说过“已经完成”。

这也是配套手册《10–100 人软件团队 AI Agent 协作落地手册》的核心原则：人负责目标、风险判断、授权与最终责任；Agent 负责检索、实现、验证和审查加速；Git、Issue、PR/MR 与 CI 保存可审计事实。

实战之后，瓶颈从“写不出来”变成“怎样相信”

在最近的集中交付中，Agent 已经可以快速完成检索、实现、补测试、生成构建物和整理 PR 说明。分支交付速度明显提高，但新的问题也很快出现：

• 一个 Issue 包含太多目标，Agent 一次生成很大的 PR，人工难以保持足够的审查密度；
• 多个 Agent 修改相邻目录，长期分支不断同步主干，冲突成本最终回到负责人；
• Agent 自测、另一个 Agent Review、同一人合并，看起来角色齐全，却没有形成独立批准；
• 本地文档写着完整质量要求，远程 CI 实际只执行其中一部分，“全绿”的含义逐渐缩水；
• 自动化报告很完整，但真机、签名、公证、法务、体验和生产授权仍然没有责任人确认。

这些问题说明，Agent 工作流的核心难题已经不是“能否生成代码”，而是“谁有权相信哪一份证据”。如果证据来源、责任人和阻断规则不清楚，更多 Agent 只会更快地产生待审查内容。

把完成定义变成可执行证据

“功能可用”通常过于模糊。更有效的 Issue 会把验收拆成可以重复执行和比较的行为，例如固定输入重放、不同输入对照、截图、存档比较、关键路径操作、性能阈值和构建产物检查。能够机器验证的要求，应尽量变成测试、脚本、结构化报告或 CI 检查。

但“Agent 帮我生成了一份验收报告”不等于“验收已经发生”。每项证据都应该标注来源：

• 由 CI 产生的测试、构建、静态分析和可复现实验结果；
• 由设备或外部服务产生的签名、公证、兼容性和上线结果；
• 由明确责任人确认的体验、合规、版权和业务判断。

只有来源和责任都清楚，证据才有意义。

真实运行证据拥有否决权

自动化检查全部通过后，真实桌面环境、移动设备或生产流量仍可能发现新的生命周期、存储、权限和兼容性问题。此时重新打开 Issue 不是流程失败，反而说明流程允许新事实纠正旧结论。

成熟的 Agent 工作流不追求一次对话“闭环”。修复合并后出现新证据，应重新打开原 Issue，或者建立清楚关联、可独立验证的后续任务。不要为了维持完成率，把返工藏进聊天、评论或下一次大改。

门禁变化也必须接受治理

删除不稳定、重复或成本过高的检查本身不一定错。真正的风险是：门禁被移除后，谁负责替代验证、证据保存在哪里、文档是否同步，没有形成同等清楚的新契约。

一旦仓库文档、实际 CI 和分支保护发生漂移，Agent 会严格执行过期规则，人也很难判断某个“全绿”到底覆盖了什么。每次新增、删除或降级门禁，都应像代码变化一样经过 Review，并同步完成定义、责任人和回滚条件。

角色名称不等于职责分离

给 Agent 命名为 Backend、QA、Reviewer，并不会自然产生团队治理。一个人可以借助多个 Agent 提高检索和交叉检查能力，但如果实现、接受审查和合并仍由同一人决定，本质上仍是 single-owner workflow。

这种模式适合个人项目或早期试点，却不能直接宣称已经形成 10–100 人团队的独立批准。团队级流程需要把作者、Reviewer、CODEOWNER 和发布授权者落实到不同的责任主体，并让平台保存批准事实。

连续实践验证的七条规则

1. 一个 Issue 只设置一个写入负责人

可以有多个只读 Agent 帮助检索、规划或审查，但同一任务同时写代码的主体应该唯一。并行应通过独立 Issue、分支或 worktree 实现，而不是共享工作目录。

2. Agent 开始前，Issue 必须达到 Ready

至少写清目标、非目标、可修改范围、验收条件、风险、依赖、人工批准点和停止条件。只有一句“优化一下”的 Issue，会把歧义推迟到代码阶段，最后变成大 PR 和返工。

3. PR 保存证据，不保存表演

PR 应记录变更范围、测试命令、关键输出、截图或产物、未验证项、风险和回滚方法。没有必要上传完整聊天记录；长对话既难审查，也不是可靠事实源。

4. 自动化结果与外部事实分开

CI 可以证明某个提交在某个环境通过了某组检查，不能证明真实设备、生产权限、法律权属、用户体验或业务决策已经完成。无法自动化的项目必须保留明确的人类责任人。

5. 允许真实证据重新打开 Issue

修复合并后出现新证据，应重新打开原 Issue 或创建清楚关联的后续 Issue。不要为了维持“完成率”把问题藏在评论、聊天或下一次大改里。

6. 模型按能力和风险路由，不按品牌永久分工

架构判断、常规实现、机械检索和敏感数据任务，需要的能力、权限与成本不同。团队可以维护 Tier A/B/C 和私有模型层，但应使用真实任务定期评测，不应固化成“某模型永远规划、某模型永远写代码”。

7. CI 是可合并性的机器裁判，但规则也需要治理

Required checks、CODEOWNERS、审批规则和 Merge Queue 应由平台维护。检查被调整时，文档、责任人和替代证据必须同步更新。否则 CI 绿色只代表“剩下的检查通过了”，不代表交付标准没有下降。

四个很容易出现的反模式

• 用角色名称冒充独立审查：同一负责人让一个 Agent 实现、另一个 Agent Review，能提高发现问题的概率，但不能构成人员层面的独立批准。
• PR 越大，越觉得 Agent 能力强：大 PR 往往意味着边界过宽，人工 Review 密度下降，冲突和回滚成本上升。吞吐应看成功交付的 Issue，而不是一次生成多少行代码。
• 把“Agent 说测试通过”当证据：测试命令、提交 SHA、CI 结果和产物必须能被第三方复查。
• 为速度持续拆除门禁：临时绕过很容易变成永久漂移。门禁可以重构，但不能在没有替代责任和证据的情况下消失。

下一阶段最值得补的不是更多 Agent

实践已经证明：Issue 驱动、分支隔离、Agent 实现和结构化验证可以把单一负责人的交付速度推到很高。接下来若要扩展到 10–100 人团队，优先级应该转向以下四件事：

1. 建立真正独立的 Reviewer 和 CODEOWNER 责任。 作者、审查者和高风险路径批准者分离，平台保存批准记录。
2. 恢复并固化 required checks。 至少让编译、核心测试、策略检查和安全底线在失败时阻止合并。
3. 缩小 PR。 以可独立验证、可独立回滚的行为切片拆 Issue，降低中位变更量和冲突面。
4. 把发布外部门禁交给明确的人。 真机、签名、公证、合规、体验和生产授权不能停留在“稍后人工检查”。

团队不应只统计 Agent 数量或生成代码量。更有用的指标是 Issue Ready 到交付的周期、首次 CI 通过率、Review 等待时间、返工率、逃逸缺陷、回滚率，以及每个成功交付 Issue 的模型、Runner 和人工总成本。

一份可直接采用的最小流程

对于准备落地的团队，我建议从下面这条主线开始：

人：确认需求、风险和验收
  -> 人 + Agent：整理为 Ready Issue
  -> 人：认领并成为唯一写入负责人
  -> Agent：在独立分支 / worktree 中实现和自测
  -> 人：检查最终 diff，提交 PR
  -> CI：生成不可手工覆盖的基础证据
  -> 独立的人 + 只读 Agent：Review
  -> CODEOWNER / 发布负责人：高风险批准
  -> Merge Queue：合并并验证主干
  -> 真实运行反馈：必要时重新打开 Issue

先用 10–20 个中等复杂度、可回滚的真实 Issue 试点。试点阶段不要追求全自动合并，而要验证三件事：任务是否足够清楚，证据是否真的可复查，出现错误时能否快速停止和回滚。连续运行稳定后，再逐步开放低风险任务的自动化权限。

最后的判断

这套流程已经形成了一组有价值的 Agent 工程实践：任务进入 Issue，写入发生在隔离分支，结果通过 PR 汇总，验收尽量变成可执行证据，外部事实不由自动化报告冒充。

实践也暴露了下一步：当写代码不再稀缺，Review、CI 门禁、所有权分离和发布授权就会成为新的约束。Agent 吞吐不等于交付成熟度。真正成熟的系统，是在模型更换、人员增加、任务并行和证据反转时，团队仍然知道谁能做什么、什么才算完成，以及出现问题后如何回到可控状态。