两个 Agent 怎么真正协作？我们把 ACS 做成了可复用工程案例库

很多团队开始用 AI Coding Agent 之后，会很快遇到一个问题：

不是 Agent 不会写代码，而是协作链路太松。

一个 Agent 负责执行，一个 Agent 负责审核，人类 Owner 负责最终决定。听起来合理，但如果没有协议，最后很容易变成：

• Executor 改完代码，自己跑测试，自己宣布完成；
• Reviewer 只看“测试通过”，没有查范围、截图、证据和架构；
• Owner 的决策散在聊天记录里，下一轮上下文压缩后没人记得；
• handoff 说修好了，正式设计文件里还是旧指令；
• 对外发 PR、发文章、交付客户材料时，没有证据台账和脱敏检查。

所以我们整理了一个开源项目：

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

项目简称 ACS，全称 Agent Collaboration SOP。

它不是一份“让 Agent 更努力”的提示词，而是一套让多 Agent 协作变得可审核、可交接、可复盘的工程规范。

ACS 解决什么问题

ACS 真正解决的是：怎么把 Agent 工程协作从聊天记录，推进到文件化、可审核、可复盘的工作流。

ACS 默认使用三角色模型：

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

底线很简单：Executor 不能自己验收自己。

这句话在真实项目里很重要。因为同一个 Agent 很容易沿着自己的假设一路往下走：它可能真的跑了测试，也可能真的修了某个 bug，但这不代表它没有改偏范围，也不代表 UI、文档、发布材料和上游 PR 都已经安全。

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

我最认可 ACS 里的一句话：

Green tests are evidence, not approval.

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

它不能证明：

• 改动仍在 Owner 批准的范围内；
• 新增测试被默认命令覆盖到了；
• UI 页面真的打开看过；
• 截图证据齐全；
• 公开内容已经脱敏；
• 上游维护者能快速 review。

所以 ACS 里的 Reviewer Report 不只是写“测试通过”，还要看 command、evidence、product、architecture、security、redaction、release risk。

这也是我觉得 ACS 值得做成开源项目的原因：

很多团队不是缺一个更会写代码的 Agent，而是缺一套能约束 Agent 协作边界的工程流程。

为什么要有 Evidence Ledger

聊天不是长期工程记录。

聊天会被压缩，会丢上下文，也很难和仓库状态对应。一个月后再问“当时为什么这么改”，经常只能靠记忆猜。

ACS 要求关键结果落到文件：

• Executor handoff
• Reviewer report
• Evidence ledger
• Owner consensus report
• Case study
• Anti-pattern review

这不是为了形式感，而是为了让下一个人、下一个 Agent 能复盘：

• 当时为什么这么改；
• 哪些文件改过；
• 哪些命令跑过；
• 哪些截图证明过状态；
• 哪些风险还没消掉；
• 哪条规则因为这个案例变清楚了。

这类文件最后会变成团队的工程记忆。

工程案例库：让每一次协作都变成可复用经验

ACS 项目里有两个长期目录：

case-studies/
anti-patterns/

case-studies 存放脱敏后的协作案例。

anti-patterns 存放典型反模式，比如：

• Agent 自验自收；
• 只看绿测；
• 证据只在聊天里；
• handoff 说修了，正式文件没改；
• 产品语言漂移被伪装成技术修复；
• UI 验收没有截图；
• 不安全公开输出。

这些反模式不是追责材料，而是预防清单。

每个团队都有自己的 Agent 翻车现场。只要脱敏得当，它们都可以变成下一次协作的检查项。

公开案例必须先脱敏

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

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

公开前至少要清理：

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

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

我们希望社区持续贡献 ACS 案例

ACS 不会是一份写完就不动的规范。

我们会持续维护工程案例库，也欢迎更多团队贡献公开脱敏案例。

比较适合贡献的内容包括：

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

如果你也在用 Codex、Claude Code、OpenClaw、Hermes 或其他 coding agent 做真实项目，欢迎把脱敏后的案例贡献出来。

保留经验，去掉敏感细节。

延伸阅读

• ACS GitHub：https://github.com/kunpeng-ai-lab/agent-collaboration-sop
• 主站专题：https://kunpeng-ai.com/blog/agent-collaboration-sop-acs-case-library/

这套东西不会替代人类 Owner 的判断。

它真正的价值是：让 Agent 做过什么、验证过什么、Reviewer 挡住了什么风险，都能留下证据。

这才是多 Agent 协作走向真实工程的开始。