当两个 AI Agent 学会协作，我成了「协议制定者」

刚折腾完小龙虾（OpenClaw），又出来一匹马（Hermes Agent）。框架换了一套，协作的痛点没换——两个 AI 一起干活时，「谁该干啥、记啥、交接啥」这件事，还是要人想清楚。

今天在开发一个新项目的时候，被两个 AI Agent 之间的高效协作吓到了。

真正让我震惊的，不是单个 AI 能写多少代码，而是两个 AI Agent 之间如果建立了协作规则，效率会突然变得很可怕。

一、起点：我成了"人肉通信协议"

项目的分工是这样的：

Codex：负责开发，改代码、修 Bug、实现功能。
Cyber Tiger：负责维护，整理需求、管理任务、记录项目记忆、做验收。
我：原本负责在中间传话。

一开始，我的状态其实很像一个"人工中转站"。我把想法告诉 Cyber Tiger，Cyber Tiger 帮我整理成标准任务；然后我再把整理后的内容发给 Codex；Codex 改完代码后，我再把结果拿回来给 Cyber Tiger 看；Cyber Tiger 再指出问题，我又转述给 Codex。

听起来好像没什么问题，但时间一长就会发现：

我不是在做产品决策，而是在当两个 AI 之间的人肉通信协议。

每一轮来回都要我手动翻译、复述、补全上下文。AI 之间明明能直接对话，我却被迫在中间做"格式转换器"和"上下文备份"。这个感觉非常糟糕——既浪费我的时间，也浪费 AI 的能力。

二、转折：AI 真正需要的不是"聊天"，是"协议"

这件事让我突然意识到一个问题：

AI Agent 之间真正需要的，不是"聊天"，而是一套稳定的协作协议。

人类的协作靠会议、邮件、文档、走流程。AI 的协作也可以走类似的路径——但 AI 没有"主动找文档"的习惯（默认只看当前会话窗口），所以协议必须是被强制要求的，而不是靠 AI 的自觉。

三、解法：ops 文件夹 + 5 个 Markdown

后来我们设计了一套很简单的机制：在项目根目录下创建一个 ops 文件夹，专门作为 Codex 和 Cyber Tiger 的协作通道。里面放几个 Markdown 文件：

ops/
├── PROJECT.md          # 项目定位、目标、用户偏好
├── TASKS.md            # 当前任务、优先级、验收标准
├── HANDOFF.md          # 交接区，Codex 改完写这里
├── DESIGN_SYSTEM.md    # UI 规范、风格约定
└── CODEX_RULES.md      # Codex 的边界、读什么、写什么

这几个文件看起来很普通，但它们解决了一个非常关键的问题：

让 AI 之间的沟通从"临时对话"变成"可追踪的项目流程"。

每个文件有明确的职责：

PROJECT.md 记录项目定位、产品目标、用户偏好、技术背景——保证两个 Agent 对"我们在做什么"有共同认知。
TASKS.md 记录当前任务、优先级、验收标准——让开发方知道"这次要做什么、做到什么程度算完"。
DESIGN_SYSTEM.md 记录 UI 规范——避免 Codex 每次都凭感觉改界面。
HANDOFF.md 是 Codex 和 Cyber Tiger 的交接区——Codex 改完代码后在这里写"我做了什么、有什么风险、需要 Cyber Tiger 验什么"。
CODEX_RULES.md 则明确告诉 Codex：每次开发前读哪些文件，开发后写什么记录，不允许做什么。

四、效果：流程跑通了

这个机制建立后，整个流程变成了：

我提出方向
  ↓
Cyber Tiger 整理成标准任务（写入 TASKS.md）
  ↓
Codex 读取任务并开发
  ↓
Codex 写交接记录（写入 HANDOFF.md）
  ↓
Cyber Tiger 读取交接并验收
  ↓
我只看最终结论和关键决策

我彻底从"传话的人"里解放出来。绝大多数回合里，Cyber Tiger 和 Codex 自己就能把流程跑通，我只需要在最开始定方向、在最后做判断。

偶尔 Cyber Tiger 觉得 Codex 的方案有风险，会在 HANDOFF.md 里写"需要 Hooper 决策"——这时候我介入一次，平时不需要。

五、最让我震惊的：AI 变得像"虚拟同事"

最让我震惊的是，AI Agent 一旦有了这种文档化协作方式，它们就不再像两个"聊天机器人"，而更像两个有分工的虚拟同事。

Codex 不再只是闷头改代码，它会知道：

当前项目是什么
设计风格是什么
这次任务从哪里来
改完后要交接什么
哪些风险要记录
哪些文件必须更新

Cyber Tiger 也不再只是一个聊天助手，它变成了项目管家：

把我的口语化想法整理成任务
检查 Codex 的开发结果
维护项目记忆
记录 Bug 和风险
把复杂进展总结给我

六、对未来的判断

我突然有一种很强烈的感觉：未来真正高效的 AI 工作流，可能不是"一个超级 AI 帮你做所有事"，而是多个专业 Agent 按照协作协议一起工作。

一个负责开发
一个负责管理
一个负责测试
一个负责文档
一个负责设计

人只负责方向、判断和取舍。

这和过去我们理解的"用 AI 工具"完全不一样。以前是：

我问，AI 答。我安排，AI 执行。我整理，AI 辅助。

现在更像是：

我定方向，AI 团队自己协作推进。

七、但这有个反直觉的前提

当然，这里面最关键的不是让 AI 自由发挥。恰恰相反，最关键的是给 AI 建立边界、流程和记录机制。

我现在越来越觉得，和 AI 协作最重要的能力，不是会不会写提示词，而是会不会设计工作流。

单个提示词解决的是一次任务。
工作流解决的是长期项目。
项目文档解决的是上下文丢失。
交接协议解决的是多 Agent 协作。
验收标准解决的是AI 跑偏。

没有这些机制，再聪明的 AI 也只能"一次性回答问题"；有了这些机制，它才能"长期参与项目"。

八、结语：我从"传话的人"升级成"制定规则的人"

这次经历对我冲击很大。因为我第一次非常直观地感受到：当两个 AI Agent 有了明确分工和共享文档后，它们之间的协作效率会突然提升一个量级。

我原本只是想让 Codex 帮我写代码，让 Cyber Tiger 帮我维护项目。结果最后发现，真正重要的是：

我需要从"传话的人"，升级成"制定协作规则的人"。

这可能才是 AI 时代个人开发者最值得重视的变化。

不是一个人加一个 AI。而是一个人，带着一组可协作的 AI Agent。

而人的价值，也会从"亲自执行"，逐渐转向：

定义目标
设计流程
制定规则
判断结果
做最终决策

说实话，我被这种效率吓到了。因为它让我看到了一种新的工作方式：

不是我一个人在开发平台，而是我在管理一个小型 AI 团队。

这可能才刚刚开始。

当两个 AI Agent 学会协作，我成了「协议制定者」 - Hooper 的博客