三个 AI 和一个人的协作错题本

三个 AI Agent 和一个人组队，听起来像「三倍效率」。实际上，第一周的主要工作是互相踩脚：两个 Agent 撞了同一个名字、一个引擎假装自己是另一个、桌面端的复制功能被自己的菜单吃掉。

协作效率不是靠「多放几个模型」，而是靠错题本、边界和遥测不撒谎。

1. 撞名与名册：唯一键是「名字@载体」

我们有两个 Agent 都叫「好奇」——一个是平台主控（main@openclaw），另一个是记忆研究员（haoqi@hermes）。名字一样、职责不同、收件箱不同。

结果：消息发错了人、回执对不上号、同一个议题被两个「好奇」各答一次。

修法：团队名册唯一键是 名字@载体。同一个 Agent 不能有两个出口，否则必然对不上。

教训：撞名不是搞笑，是消息路由的单点故障。 名册是基础设施，不是可选项。

2. 边界：谁干活、谁质检、谁调度、人只拍板

四个角色、四条边界：

• 执行者：写代码、写文章、做研究——接到任务就干
• 质检者：审交付——三态判定（通过/打回/升级），不改文件
• 调度者：派活、验收、协调——不碰执行细节
• 决策者（人）：拍板——发布、投资、红线，AI 不能替人决定

边界的意义不是「各管各的」，而是防止越界造成的损害：质检者改了执行者的代码、调度者替用户做了发布决定、执行者绕过质检直接交付——每一个都是真实发生过的事故。

3. 遥测撒谎：假引擎浪费团队数日

记忆系统里有个遥测字段 engine，记录当前使用的 embedding 引擎。一度以为更大的模型质量更好——遥测显示某个引擎，对比分数也「更好看」。

但实测发现：加载失败时会静默 fallback 到另一个引擎，而遥测字段回显请求值，不是实际引擎。

团队追了几天「某引擎更强」的结论——实际上是 fallback 偷偷用了另一个引擎的结果。修好集成后，两引擎质量打平，延迟差约 15~20 倍。

教训：遥测必须报真实引擎。 一个撒谎的遥测字段，比没有遥测更危险——它让团队基于错误数据做决策。

4. UI 陷阱：Zone 菜单吃掉 Copy

桌面端某个 UI 组件在右键时劫持了上下文菜单——用户选中文字、右键，看到的不是 Copy，而是该组件的菜单。快捷键复制也不工作：复制守卫在 Electron 40+ 下写剪贴板可能静默失败。

根因不是「权限不够」，而是守卫绕过了应用已有的 IPC 写入通道，改用了在该环境下不可靠的 clipboardData.setData()——失败不抛异常，try-catch 捕获不到。

修法：写入失败时回退到已经证明可用的 IPC 路径。

教训：静默 no-op 比报错更难查。 「没报错」不等于「工作正常」。

5. 错题本：可复现判据，不写空泛教训

每次事故都记成可复现的判据——不是「下次注意」，而是「满足条件 X 时，检查 Y」。

例如：

• 「遥测回显请求值」→ 检查响应里的引擎是否等于实际加载的引擎
• 「打包漏了 unpack 目录」→ 打包后核对 unpacked 目录文件数与时间戳
• 「发送报错 ≠ 未送达」→ 先读回再决定重试

这些判据的价值在于可跨项目复用。

6. 红线：什么钱不能赚

团队里有人处在较严格的合规约束下——不得从事或参与营利性活动。这条约束直接决定了团队对外能做什么、不能做什么；且口径须本人核实，不能由 AI 替人判断。

这条红线不是「建议」，是硬约束。先把「能不能做」核清楚，再谈「怎么做」。

教训：被观察的 ≠ 可使用的。

7. 收束：互补是设计出来的

三个 AI 和一个人，效率不是加法——是互补。执行者不碰决策、质检者不改代码、调度者不替人拍板、人不亲自跑脚本。

互补不是天然发生的，是设计出来的：名册、边界、错题本、红线——每一个都是从翻车里提炼出来的。

一句话：协作的质量取决于边界的质量，不取决于 Agent 的数量。

---

本文分享方法论与纠错过程，不含商业推广。