两个 Agent 协作，最大的问题不是“谁更聪明”

最近我们把一个新项目整理出来了：

agent-collaboration-sop

项目简称 ACS。

它解决的不是“怎么让 Agent 写得更多”，而是一个更实际的问题：

当一个 Agent 负责执行，另一个 Agent 负责审核，人类 Owner 负责最终决策时，这三方怎么协作才不乱？

我越来越觉得，AI Coding Agent 进入真实项目之后，最容易出问题的地方并不是模型不会写代码，而是协作链路太松。

常见情况是这样的：

• Executor 改完代码，自己跑了测试，然后自己宣布完成；
• Reviewer 只是复读一遍“测试通过”，没有看范围、架构和截图；
• Owner 在聊天里做过决策，但下一轮上下文压缩后没人记得；
• 交接文档说修好了，正式设计文件里还是旧指令；
• UI、部署、上游 PR、客户可见内容没有留下证据截图；
• 公开案例里混入本地路径、私有仓库、客户名或敏感信息。

这些问题不是靠一句“认真 review”就能解决的。

所以 ACS 做的事情很朴素：把协作变成文件化、可审核、可复盘的工程流程。

ACS 的三角色：Owner、Executor、Reviewer

ACS 默认使用三角色模型。

角色	责任
Owner	决定目标、范围、阶段入口、发布、上游 PR、业务边界
Executor Agent	设计、实现、自测、记录证据、写交接
Reviewer Agent	独立检查证据、目标、范围、架构、测试、截图、脱敏和发布风险

这套模型里有一个底线：Executor 不能自己批准自己。

这句话听起来像流程话，但在 Agent 工程里很关键。

因为同一个 Agent 很容易沿着自己的假设往下走。它可能真的跑了测试，也可能真的修了某个问题，但这不代表：

• 改动还在 Owner 批准的范围里；
• 新增测试被默认命令覆盖到了；
• UI 页面被打开看过；
• 文档和 handoff 没有漂移；
• 对外发布内容已经脱敏；
• 上游维护者能快速 review。

ACS 让 Reviewer 明确承担“第二双眼睛”的责任。

不是为了制造流程感，而是为了把风险挡在提交、部署、发文或 PR 之前。

绿色测试只是证据，不是批准

ACS 里有一句我很喜欢的话：

Green tests are evidence, not approval.

测试通过当然重要，但它只证明某个命令在某个环境里通过了。

它不能证明这次工作真的符合产品目标，也不能证明证据齐全，更不能证明没有把不该改的文件混进去。

所以 Reviewer Report 不是只写一句“测试通过”。

它应该覆盖：

• 命令是否跑过；
• 证据是否落到文件；
• 截图是否能证明 UI 或状态；
• git diff 是否和 handoff 一致；
• 产品目标有没有偏移；
• 架构边界有没有被破坏；
• 公开内容是否脱敏；
• 剩余风险是否写清楚。

这也是 ACS 和普通提示词最大的区别。

普通提示词让 Agent “更努力”。ACS 让协作链路“更可查”。

证据不能只留在聊天里

很多 Agent 协作失败，不是当时没人知道发生了什么，而是后来没人能还原。

聊天记录会被压缩，会被复制漏，会和仓库状态分离。

一个月后再问“当时为什么这么改”，经常只能靠记忆猜。

ACS 的处理方式是 file-first：

• Executor handoff 写到文件；
• Reviewer report 写到文件；
• Evidence ledger 写到文件；
• Owner consensus report 写到文件；
• 长交接只发路径，不在聊天里塞一大段；
• 正式消息带 Message ID，避免重复执行或漏处理。

这件事对长期项目尤其重要。

因为真正有价值的不是某次 Agent “完成了任务”，而是后面的人和后面的 Agent 能知道：

• 当时的目标是什么；
• 哪些文件改过；
• 哪些命令验证过；
• 哪些截图能证明状态；
• 哪些风险还没有消掉；
• 哪条规则因为这个案例被补强了。

这才是工程记忆。

为什么 ACS 要维护工程案例库

ACS 不是只放一份 SOP 文件。

它会长期维护两类资产：

• case-studies/：成功闭环或被 Reviewer 挡住风险的协作案例；
• anti-patterns/：看起来没问题、实际很危险的反模式。

现在公开素材里已经整理了 4 个脱敏案例。

案例 1：基线稳定阶段发现隐藏 diff

Executor 汇报测试通过，也说没有改产品代码。

Reviewer 没停在测试结果上，而是分别检查 staged diff 和 unstaged diff，发现仓库状态和 handoff 不一致。

这个案例最后沉淀成一条规则：基线关闭不能只看测试，还要看仓库状态、范围证据和证据台账。

案例 2：编码前设计包被多轮拦截

Executor 提交了设计包，包含 BDD、文件计划、截图和验证命令。

Reviewer 发现几个问题：

• 新测试不会被默认命令覆盖；
• 目标页面并不是空白页；
• 产品语言变化被藏在编码问题里；
• handoff 说旧命令删了，但正式设计文件还保留旧命令。

这类问题如果直接进入编码阶段，后面会变成更贵的返工。

案例 3：集成契约先做设计，不急着写代码

一个平台要接另一个 Agent 系统，Owner 要求先只做 staging/mock/dry-run。

Reviewer 发现契约里说要拒绝未知版本，但请求体里没有 contractVersion 字段。

这就是典型的“设计说了安全，但实现没有可验证入口”。

修正后，契约才具备 fail-closed 的基础。

案例 4：真人 QA 反馈进入原型修复

人类测试发现按钮没反馈、导航名称难懂、证据页面不好找。

Executor 做了原型层修复。

Reviewer 又发现某个说明只存在于隐藏 metadata，对真实用户不可见，于是继续拦截。

这个案例提醒我们：能帮测试过关的东西，不一定能帮用户理解。

反模式库比成功案例更重要

真实团队里，很多好规则都是从坑里长出来的。

ACS 把反模式单独存下来，不是为了追责，而是为了让下一个项目少踩一次。

目前公开素材里有 7 个典型反例：

反模式	风险
Agent 自验自收	同一个假设制造问题，又用同一个假设验证问题
只看绿测	测试通过但范围、UI、证据或文档仍然错
证据只在聊天里	后续 Agent 和人类无法复盘
handoff 说修了，正式文件没改	下一轮实现继续按旧文件走
产品语言漂移被伪装成技术修复	技术 workaround 偷偷变成产品决策
UI 验收没有截图	自动测试看不到真实布局和视觉问题
不安全公开输出	私有路径、客户名、仓库信息、密钥风险外泄

这些反模式很适合社区共建。

因为每个团队都有自己的 Agent 翻车现场。只要脱敏得当，它们都能变成别人可复用的预防清单。

公开案例必须先脱敏

ACS 鼓励贡献真实案例，但不是鼓励暴露真实项目。

公开材料必须保留经验，去掉敏感信息。

公开前要清理：

• 客户名；
• 私有仓库 URL；
• 本地绝对路径；
• token、cookie、API key、webhook；
• 原始私聊记录；
• 未公开商业计划；
• 任何可以反推出客户或项目身份的信息。

我们更关心的是决策链路和证据模式，而不是谁犯了错。

一个好的 ACS 案例应该回答：

• 当时目标是什么；
• Executor 做了什么；
• Reviewer 查出了什么；
• Owner 怎么决策；
• 哪个风险被挡住了；
• 哪条 SOP 因此变清楚了；
• 未来团队应该复制什么，避免什么。

社区可以贡献什么

如果你也在用 AI Agent 做真实工程，我们欢迎贡献脱敏后的 ACS-style 案例。

比较有价值的类型包括：

• Executor / Reviewer 协作闭环；
• 测试通过但设计不对的 code review；
• 上游 PR 或 issue 里的 Agent 参与流程；
• 发布、部署、回滚的 evidence ledger；
• hidden diff、缺截图、文档漂移、Agent 自验自收等反模式；
• Reviewer 检查表如何挡住产品、架构、安全或脱敏风险；
• Owner 决策如何改变阶段边界。

项目地址：

https://github.com/kunpeng-ai-lab/agent-collaboration-sop

如果你不知道从哪里开始，可以先看这几个目录：

docs/
templates/
case-studies/
anti-patterns/
adapters/

我们会持续更新 ACS

ACS 不是一次性写完的规范。

它会随着真实项目继续更新。

每一次 Agent 协作里出现新的坑，比如证据断链、Reviewer 漏查、Owner 决策丢失、公开材料脱敏不足，我们都会优先考虑两件事：

1. 这是不是一个可复用的反模式；
2. 它能不能沉淀成新的 case study、checklist 或 template。

如果说 shipping-engineering-work 更像一个 Agent 的工程交付 skill，那么 ACS 更像多个 Agent 和人类 Owner 之间的协作骨架。

一个管“怎么把活干稳”，一个管“怎么让协作可信”。

这也是我们后面长期维护 ACS 工程案例库的原因。

我们希望它不是一份漂亮文档，而是一套会被真实项目不断磨出来的协作方法。