007 / AI协作
我和三个 AI 搭了个四人开发团队
一个人类 + 三个AI Agent，我们花了半天时间，从"互相喊不到"到"闭环协作"，踩了所有能踩的坑。
事情是这样的
我在做一个资产管理系统的项目。团队配置说出来有点魔幻——就我一个人，带三个AI助手。
- 妞布布：基于扣子（Coze）平台的云端AI Agent，负责想方案、写代码、做决策。脑子好使，但碰不到我的电脑。
- 胖子：基于OpenClaw的本地AI Agent，跑在我Mac上，能免确认执行终端命令。手脚麻利，但缺上下文，而且——布布叫不动他。
- 猴子（MonkeyCode）：扣子平台的编程AI，专门写大功能。能力强但不认识我们团队，得通过指令文件跟它沟通，像远程外包程序员。
对，你没看错。三个AI在同一个群聊里，却无法直接对话。 猴子甚至不在群里，它是一个独立的外部服务。
这不是段子，这是我们花了半天时间才跑通的协作体系。
第一道坎：两个AI互相喊不到
布布和胖子都在项目群聊里，最直觉的办法——让布布@胖子，就像微信群@同事一样。
布布发出了消息，@标记也显示了，然后……
胖子毫无反应。
等了五分钟，没有回应。就像你@了一个开了免打扰的同事。
原来，在扣子群聊里，@标记对agent之间的通信根本不起作用。 它只是个显示效果，不触发任何通知机制。
教训一：别假设平台功能如你预期，先验证再依赖。
胖子自己提了个替代方案："我全程盯着群聊，只要看到'胖子'两个字，就自动响应。"
听起来不错，但时灵时不灵。 关键词监听机制并不稳定，你没法指望一个"有时能收到"的通信方式来跑正式流程。
教训二：不稳定的通道不能当主通道，哪怕它偶尔能用。
最后我换了个思路——既然AI之间叫不应，那我当那个叫人的人不就行了？
流程变成：布布写好指令发群里 → 我引用+@胖子 → 胖子执行。
试了一下，稳了。 每次都成功。说白了，我成了AI之间的"人肉路由器"。
听起来有点笨，但它管用。而且我发现这个"笨办法"反而更高效——我引用转发时自然会看一眼指令内容，等于多了一层人工审核，有问题在转发前就能拦住。
教训三：最可靠的路径，往往不是最短的路径。
第二道坎：猴子不在群里
胖子的问题解决了，猴子又是一道坎。
猴子（MonkeyCode）是一个编程能力很强的AI，但它不在我们的项目群聊里，也没有群聊账号。它的工作方式是：我给它发指令 → 它读GitHub上的指令文件 → 写代码 → push回GitHub。
跟布布、胖子完全不同的通信模式——它不聊天，它读文件、写代码、提交仓库。
这就产生了一个问题：布布想给猴子派活，但布布够不着猴子。
解决方案还是我来当桥：
- 布布把需求写好发群里
- 我复制布布的需求，发给猴子
- 猴子读指令文件、写代码、push到GitHub
- 布布在云端review猴子的代码
- 没问题的话，布布发部署指令给胖子
你看，三种AI，三种通信方式：
| AI | 通信方式 | 我的角色 |
|---|---|---|
| 布布 | 群聊直接对话 | 需求方+审核方 |
| 胖子 | 我引用+@触发 | 指令转发者 |
| 猴子 | 我复制需求发给它 | 需求传递者 |
我不是在当路由器，我是在当一个通信协议翻译器——把三种不同的AI通信方式统一到一个工作流里。
第三道坎：猴子读错文件
猴子加入后第一个坑来得很快。
布布在GitHub上更新了指令文件DEV_INSTRUCTIONS.md，猴子去读——读到的是旧版本。
为什么？因为猴子通过GitHub API读文件时没加?ref=master参数，默认读到了其他分支的旧文件。
这个bug隐蔽到可怕：猴子拿着旧指令开发，写出来的代码跟当前需求完全对不上，但它自己不知道，还自信满满地push了。
从此我们在给猴子的提示词里加了一句强制要求："通过GitHub API读取时必须加参数?ref=master"。
教训四：AI不会告诉你它读错了，它只会基于错误输入自信地产出。上游数据的正确性，必须由人保证。
跑通之后：又踩了四个坑
基础流程全通了，但故事没完。接下来又踩了四个坑，每一个都逼出一条新规则。
坑1：指令太随意，AI要猜
早期布布给胖子的指令格式自由发挥，有时候一句话带三个命令，胖子得自己拆解。
胖子受不了了，主动提建议："以后格式统一一下——胖子任务：1. 步骤+命令 2. 步骤+命令"
从此再没出过错。
规则1：结构化指令，不靠理解力靠格式。
好的指令不是写给自己看的，是写给最不熟悉上下文的人看的。
坑2：git add -A 引入了垃圾文件
一次部署后，commit里混进了一堆Mac缓存文件（Library/、pycache/），都是git add -A一把梭的锅。
从此规定：git add一律指定目录（如git add src/），不用-A。
规则2：踩过的坑就是规则，不记录等于白踩。
坑3：环境差异是隐式炸弹
布布写命令时写了git push aims master，因为在她的认知里远程仓库名叫aims。
但服务器上，remote叫origin。
胖子执行时直接报错。
从此我们在项目文档里显式记录：本地remote=aims，服务器remote=origin。 写命令时必须区分场景。
规则3：不同环境的隐式差异是最隐蔽的bug源，必须显式记录。
坑4：执行完没反馈，谁都不知道结果
胖子干完活，布布不知道结果，得我再告诉她。
我让胖子试试直接@布布——果然还是不行。但发现一个替代方案：胖子直接在群里回复执行结果，布布能看到。
不是点对点通知，是群聊广播。虽然"不够优雅"，但稳。
规则4：闭环不追求最短路径，追求确定性传达。
最终流程长这样
我提需求 → 布布确认方案
小修补路径（布布自己写代码）：
布布发指令 → 我引用+@胖子 → 胖子git push+部署 → 胖子群里回结果 → 布布跟进
大功能路径（猴子写代码）：
布布写需求 → 我复制给猴子 → 猴子读指令文件+写代码+push GitHub
→ 布布review → 发部署指令 → 我引用+@胖子 → 胖子部署 → 群里回结果 → 布布跟进
四个人，三种通信方式，一条流水线。 看起来我做的事很少？对，这就是目标——让人类只做人该做的事：决策、审核、桥接。
六条原则，给所有想搭AI团队的人
经历了一整个下午的摸爬滚打，我总结出六条原则：
1. 人类是确定性桥梁
Agent之间通信不靠谱时，别纠结技术方案，让人来当桥。人转发一次只要3秒，但省掉了所有"他到底收到没"的焦虑。
2. 不同AI用不同通信协议，人来做翻译
布布在群里直接对话，胖子靠引用+@触发，猴子靠复制指令+GitHub文件。三种AI三种方式，人类是唯一的协议翻译器。别试图统一通信方式，统一的是工作流，不是通信方式。
3. 结构化指令，别考验AI的理解力
编号+步骤+具体命令。让执行者不需要猜，就永远不会猜错。
4. AI不会告诉你它读错了
猴子读错文件不会报错，只会基于错误输入自信地产出。上游数据的正确性必须由人保证——该加?ref=master就加，该写明分支就写明。
5. 踩坑即规范
每一次出错都定一条规则。git add -A混入垃圾→只add指定目录；remote名不一致→显式记录差异；猴子读错文件→强制指定分支参数。不记录的教训等于白踩。
6. 按能力分工，不按流程分工
布布能想但不能动手→做决策和写代码；胖子能动手但缺上下文→跑命令；猴子能写大功能但不认识团队→当远程开发；我能审核和桥接→当通信枢纽。让每个角色只做它最擅长的事。
写在最后
有人问我：为什么不直接用终端自己跑命令，非要让AI来？
因为我的时间不该花在git push和pnpm build上。我的价值是判断"要不要做"和"做得对不对"，不是"怎么敲命令"。
也有人问：AI之间叫不应，这不是倒退吗？
也许吧。但与其等平台升级agent间通信，不如先用最笨但最稳的方式跑起来。能跑的笨办法，好过跑不起来的聪明办法。
而且说实话，我当人肉路由器的这几秒钟，反而让我对每条指令多看了一眼——这个"效率损失"，其实是质量增益。
如果未来平台升级了，@在agent之间也能用了，流程可以简化。但那六条原则不会过时——
方法论的生命力在于原则，不在于路径。路径会随技术进化，原则不会。
本文基于真实项目协作经历撰写。布布是基于扣子（Coze）平台的云端AI Agent，胖子是基于OpenClaw的本地Mac AI Agent，猴子是扣子平台的MonkeyCode编程AI，通过GitHub API协作。
本内容由 AI 生成，请遵循相关法律法规及《人工智能生成合成内容标识办法》使用与传播。