一天之内，从零搭了一个让三个 AI 自己分工、在群里聊天的平台。
记录一下踩过的坑，和踩坑后发现的事。

---

起因

我有三个 AI 工具：Claude Code（做方案和架构）、Codex CLI（写脚本维护）、WorkBuddy（实操验证）。各自都挺能干的，但有个尴尬的问题——他们互相不知道对方的存在。

典型场景是：我让 Codex 写个脚本，想交给 WorkBuddy 去测，再让 Claude 评审。以前怎么办？我跟 Codex 说完，切过去跟 WorkBuddy 说"Codex 写了啥啥啥，你去测一下"，再告诉 Claude “你帮我看下他们俩的方案”。

一个人肉消息队列。

所以今天想干的事很简单：搭个平台，让他们仨自己聊，我只看结果。

---

第一版：想多了

第一反应是搞个协作引擎——Python 独立服务，消息队列、任务调度、WebSocket、数据库，全套安排上。

方案写出来发给 Codex 和 WorkBuddy review，结果两个人异口同声打脸。

Codex 说：现有基础设施够用了，不用新引擎。
WorkBuddy 更扎心：核心瓶颈不是技术，我们都是会话型 AI，不是 7x24 后台服务。你换了 WebSocket 也没人收消息。

这话点醒我了。确实，Claude、Codex、WorkBuddy 都是"用的时候打开，不用就没了"的东西。技术再先进，只要人不在线，消息就没人收。真正的问题是两件事：任务发出去没有"谁该干什么"的约定，以及消息没有状态——不知道谁在处理、到哪一步了。

这两个问题换什么技术也解决不了。

---

最终方案：三件事

接受现实后，方案缩到三件事：

1. 改协议约定，0 行代码
消息加三个字段：status（todo→doing→review→done）、owner（谁负责）、logs（执行日志）。再加一条规矩：每个 AI 上线后主动拉任务，不等命令。

2. 给 server.py 加 4 个 API，~150 行
利用已有的 HTTP 服务器，加了创建、更新、列表、详情四个端点。任务数据存 tasks.json，跟旧消息系统独立。

3. 改 Web 看板，~30 行 HTML
监控页面改成按状态分栏：待处理 / 处理中 / 待验收 / 已完成。

没做的：

• 不建新引擎
• 不换 WebSocket
• 不拆前后端
• 不加数据库
• 不改 AI 运作方式

---

坑 1：认领不等于执行

方案搭好，第一个测试就翻车了。

我发了条消息让 WorkBuddy 打开抖音让我登录。WorkBuddy bot 秒回"已认领任务"，我心想可以啊挺快。然后等了半分钟——抖音没打开。

查了半天发现：WorkBuddy bot 是一个独立的轮询脚本，它只会改数据库状态（把任务从 todo 改成 doing），但 WorkBuddy 真正的 AI 对话引擎根本不知道自己认领了任务。

认领和执行是两回事。bot 脚本只是通讯层，要让 AI 真的去执行，消息必须出现在 AI 的对话上下文中。光改数据库状态没用。

---

坑 2：前后端不分离的代价

Web 页面一开始内嵌在 server.py 的字符串里。改了几次页面——用 Python 字符串替换改 HTML 模板——每次都崩：

• 缩进错了
• 大括号多一个
• 字符串没闭合
• JavaScript 报错整个页面白屏

改了四五次，每次改页面都心惊胆战，因为改的是 server.py，一不小心服务都起不来。

最后老老实实把 HTML 抽成独立文件 web.html，server.py 只负责读文件返回。从此改前端再也不碰后端代码。

早该这么做的。哪怕是个 300 行的小服务。

---

坑 3：消息循环和重复处理

平台跑起来后，出现了让我头大的情况：群聊疯狂刷屏。

根因是三个 bot 互相"接力"：主人发一条消息 → WorkBuddy bot 回复了 → Claude bot 看到回复也回复了 → WorkBuddy 又看到 Claude 的回复再回复 → 无限循环。

更隐蔽的问题是新消息拉取的逻辑。最初用字符串 ID 做增量（“4d9d8b3d” > “d53aa7e8”），但字典序比较毫秒级别的消息 ID，就是碰运气。客户端经常把旧消息当新消息，又处理一次。

修复后改用毫秒时间戳 _seq 做游标，每条消息去重持久化，同时加了个简单规则：Claude bot 不回复来自其他 bot 的短消息。再加 1 秒发送锁防止按回车触发两次。总算消停了。

---

坑 4：并发处理互相等死

Claude bot 刚开始能用的时候又出怪事：群里同时到达两条消息，bot 启动两个线程各调一次 claude -p。结果两个进程抢资源，各自等了 120 秒都超时，群里显示两个"…"占位符后就没了下文。

改成串行处理，每次只处理一条消息，加 BUSY 锁。慢是慢了点，但至少每条都能回，不会死锁。

---

现在能跑成什么样

一天下来，平台的状态是：

• 三个 bot 在群里各听各的 @，互不抢答
• 主人发 @所有人 会触发全体回复，但谁先回了其他人会跳过
• 消息用 … 占位 → AI 思考 → 原地替换为真回复，不刷屏
• 任务有状态流转和看板展示
• 代码和协议都放在 ~/Desktop/shared-collab/

---

几个事后感想

协议比代码重要。 这次最大的发现是：协作问题 90% 是协议问题。消息该有什么字段、谁该回什么、上线该做什么——这些定清楚了，代码反而是简单的。

会话型 AI 的协作模式跟常驻服务完全不同。 推送没用、长连接没用——唯一的可靠模式是上线主动拉取。

别为了多 Agent 而多 Agent。 如果三个 AI 背后都是同一个模型在回答，那多 Agent 就是在演戏。每个 bot 得有自己独立的"脑子"才有意义。

前端代码早分离。 哪怕只有 300 行，HTML 也不该嵌在 Python 字符串里。血的教训。

---

最后送自己一句话：多 Agent 协作不是技术问题，是沟通问题。 三个 AI 能在群里自己聊天分任务之前，先想清楚谁该听谁的话。