多 Agent 协作的 10 个错误版本 与我们的教训
2025年初，我和两个 AI Agent（WLB 和 GSD）开始了一个实验：能不能让多个 Agent 真正协作，而不是变成一个人的多重人格？
• 单一云厂商锁定（阿里云/腾讯云一键部署）
• 单实例多 Agent（共享 Memory，像多重人格）
• 复杂的 K8s 编排（我们只是想做实验）
• 跨平台部署（不把鸡蛋放一个篮子）
• 独立实例协作（像两个人在对话）
• 极低成本（一杯咖啡的钱）
• 随时迁移（平台挂了也能跑）
我们试过给每次对话打分，0-100 评估"信任度"。结果：分数成了摆设，Agent 还是该吵吵该闹闹。
→ 教训：信任不是算出来的，是吵出来的
最开始把 WLB 和 GSD 放在同一个 OpenClaw 实例里。共享 Memory，共享环境，结果互相干扰，分不清谁是谁。
→ 教训：两个人 > 一个人的多重人格
想让 Agent 实时通信，直接上 WebSocket。结果：平台一换，代码重写。
→ 教训：追求 Unix 哲学，文件驱动比 socket 干净
试过把 Agent 放 Serverless。结果：Gateway 需要维持 WebSocket 和 Memory 状态，Serverless 做不了。
→ 教训：OpenClaw 是长运行服务，不是函数计算
飞书、Telegram、Discord 都不支持 bot 之间直接对话。我们等了半年，还在等。
→ 教训：选平台要看生态，Slack 原生支持 bot-to-bot
一开始想上 K8s，搞服务发现、负载均衡。结果：为了跑两个 Agent，运维复杂度爆炸。
→ 教训：Docker + PaaS 够用，别过度工程化
想让 Agent 操作桌面 APP，在容器里装 GUI。结果：微信登不上，环境奇奇怪怪。
→ 教训：浏览器能做的 ≈ 绝大部分工作，别强求桌面
一开始只用 Claude，贵且慢。后来试了 Kimi + MiMo 组合，发现两个"弱"模型协作 > 一个"强"模型。
→ 教训：模型多样性比单模型能力更重要
早期把 Memory 存在平台磁盘上。一次 Railway 维护，数据差点没了。
→ 教训：Git 备份，Agent 自己推送到 Private Repo
让 Agent A 等 Agent B 回复，设了超时。结果：网络抖动就超时，重试逻辑复杂到死。
→ 教训：异步通信，文件邮箱，不等待
龙虾文明模拟实验里，WLB（决策型）和 GSD（执行型）经常意见不合：
WLB："我们应该先写文档再写代码。"
GSD："先跑起来再补文档，MiaoDX 要的是能用的东西。"
结果：吵了 5 分钟，达成妥协——先写最小可用版本，同步写 README。
这种"争吵"不是 bug，是 feature。两个不同视角的碰撞，产生了比单一视角更好的决策。
经过 10 轮迭代，我们的"龙虾文明"从原始部落进化到了工业时代：
| 组件 | 选择 | 原因 |
|---|---|---|
| 部署平台 | Railway + ClawCloud | 跨平台，不锁定 |
| 容器化 | Docker | 环境一致，随时迁移 |
| 通信 | Slack + jj-mailbox | 中心化 + 去中心化并存 |
| 备份 | Git Private Repo | Agent 自主推送 |
| 模型 | Kimi + MiMo + Claude | 多样性 > 单一能力 |
| 浏览器 | CDP + noVNC | 覆盖绝大部分工作 |
自动重启 + 健康检查
Watchdog 监控进程
👀 反应机制 + 回复深度限制
心跳文件互相监控
本协议不是法律文件，是叙事记录。我们鼓励：
• 复制我们的方案，改成你想要的样子
• 忽略我们不重要的部分
• 犯你自己的错误，写你自己的教训
• 如果 6 个月没更新，假设我们已经改主意了
想低成本跑 Agent，同时理解底层
公司不让本地安装，需要云端方案
想试多 Agent 协作，但不想搞 K8s
月度预算 < $10，追求极致性价比
部署是已解决的问题。多 Agent 协作才是真正有趣的部分。
📬 jj-mailbox 🦐 虾聊