你的AI编程助手通过了所有测试，代码就能上线吗？
越来越多的团队开始用多个AI编程代理协作：一个写代码，一个做审查，人类负责人最终拍板。听起来很合理，但如果没有共享流程，这套体系很快就会变得不可靠。
执行代理可能自己测试自己的作品。审查代理可能只检查测试是否通过。负责人收到的可能是一份信心满满的摘要，却缺乏持久证据。这就是ACS试图解决的问题。
ACS全称Agent Collaboration SOP（代理协作标准作业程序），是一套与供应商无关、以文件为先的多代理工程协作工作流。其核心原则只有一句话：绿测试是证据，不是批准。
测试通过固然重要，但它不能证明需求范围被遵守、界面被肉眼检查过、文档与实际文件一致、敏感信息已被脱敏，或者变更可以安全发布。
为什么绿测试不够
测试回答的是具体问题。批准回答的是更宽泛的问题：这个变更应该推进吗？
绿测试不能自动证明以下任何一点：请求的范围被尊重；用户界面被打开并目视检查；需要视觉证据的地方存在截图；文档和交接说明与实际文件匹配；实现没有引入架构漂移；公开输出已被脱敏；变更可以安全发布、合并上游或公开分享。
如果人类同事提交的变更没有清晰的交接、没有审查证据、没有范围说明、没有发布风险评估，大多数工程团队不会把"测试通过了"当作充分条件。AI代理的工作不应该因为摘要听起来自信就获得更低的标准。
三个角色的分离
ACS将三个角色明确分开：
负责人（Owner）：人类决策者，负责目标、范围、发布决策、上游PR边界和业务约束。
执行代理（Executor Agent）：负责实现、自测、证据收集和交接。
审查代理（Reviewer Agent）：负责独立审查范围、架构、测试、截图、证据、脱敏和发布风险。
关键规则很简单：执行者不批准自己。执行代理可以且应该运行测试，可以且应该总结变更内容，可以且应该收集证据。但批准需要独立检查和人类决策。
从聊天记录到持久文件
聊天在工作进行时很有用，但作为长期工程记录却很薄弱。聊天线程可能被压缩，可能丢失上下文，可能与它们讨论的确切仓库状态分离，后来的代理可能难以检查。
ACS优先采用以文件为先的交接方式。典型的ACS产物包括：执行者交接文档、审查者报告、证据台账、负责人共识报告、脱敏案例研究、反模式审查。
这使得工作流在经历上下文压缩、模型更换、机器更换或交接给另一个代理后更容易恢复。
案例研究与反模式
ACS维护两个长期记忆区域：
case-studies/ 目录记录脱敏的成功案例，供未来代理参考。anti-patterns/ 目录记录已知的失败模式，防止重复犯错。
这种结构让团队的经验教训真正成为组织资产，而不是散落在各个聊天窗口里。
当AI代理开始像团队成员一样工作时，它们也应该遵守同样的工程纪律。测试通过只是起点，不是终点。
热门跟贴