四个 Grok Bot 组队开发，为什么交接没崩？

多智能体协作有一个常见死法：交接时丢上下文。

后端 Bot 说接口写好了，但表结构、错误码、哪些 case 不处理，都留在它自己的线程里。前端 Bot 接手时只剩一句话。

Akshay 的解法是：状态住在磁盘上，不靠聊天消息传递。他用 Grok Bot 搭了四人研发团队。四个角色，一台共享云计算机，一个文件型任务板，跑通了一个真实功能：密码重置。

四个角色

Piper 是项目经理。她把需求拆成任务，维护任务板，检查每份交接文档。她不写应用代码，最有用的行为是拒绝：交接文档缺文件路径、缺接口契约、缺未完成清单，会被打回去，而不是继续往下传。

Bay 是后端开发。它负责数据库、API、服务端逻辑，以及 InsForge 后端本身。它不碰 UI，每次开工先问“现在实际是什么”，而不是凭记忆。

Fin 是前端开发。它按 Bay 写的契约做界面。契约缺失或含糊时，它停下来问 Piper，不猜字段名。它也不改服务端契约，需要新接口时，把任务标成阻塞，而不是绕过去。

Tess 是测试。她按验收标准写测试计划，发现问题写成独立文件，打回对应角色。她从不修自己发现的 bug：一个会偷偷修 bug 的测试，很快就会停止报告 bug。

四个 Bot 跑的是同一套模型，差异来自角色定义、上下文和 skills，不是模型选择器。

关键在文件，不在提示词

Grok Bot 的特点是，一个账号的所有 Bot 共用一台常驻云计算机。文件、浏览器登录态、命令行凭据都在这台机器上。一个 Bot 写的文件，另一个 Bot 直接读。

任务、项目上下文、交接笔记都存成文件。消息里只传路径。后端完成后，表结构、错误码、没处理的 case 写进 handoff note；前端打开文件就拿到全部上下文。下一个 Bot 从不冷启动。

任务板是一个目录：board.md 是索引，tasks/ 下每个文件是一张工单，handoffs/ 放交接记录。只有 Piper 写 board.md，避免两个 Bot 同时写同一个文件而静默丢更新。

后端不靠猜

这套团队里，Bay 用 InsForge 操作真实后端。InsForge 是开源后端平台，提供 Postgres、auth、storage、边缘函数和模型网关。和传统 dashboard 不同，agent 可以用 CLI 直接读当前环境：npx @insforge/cli metadata 一条命令，表结构、RLS 策略、auth 配置、已部署函数一次返回。

传统后端给 agent 用有三个问题：文档检索把所有内容倒进上下文；状态没有一个完整视图；错误信息裸返回，agent 看到 403 就猜原因，猜错了就重试。InsForge 的 skills 启动时只加载描述，匹配到具体任务才加载全文，所以四个 skills 全装也不会撑爆上下文。

一次真实运行

团队跑的第一个功能是密码重置。需求里写了“30 分钟过期、撤销旧会话”，但 Bay 检查项目后发现，这只是需求里的假设，项目实际没有这个配置。

Bay 没有猜一个值让任务通过。它没写交接文档，把问题标成 Blocked，交回给 Piper。Piper 把问题交还给人类用户拍板，确认后重开任务，并明确要求不要发明 TTL。

Bay 实现后，在交接文档里写清“实际过期和会话行为是平台默认”，没编数字。Fin 按这个文档接着做，Tess 验证时也注明：30 分钟过期和旧会话没有被测试，因为已经移出范围。

整个功能从提需求到上线，实际耗时几分钟，中间只等了一次人的决定。

边界与疑问

评论区有人问：如果 Bay 在 Fin 已经按契约开发后改了 API，Piper 能在交接时发现吗，还是拖到 Tess 阶段？也有人认为，让 agent 互相评审，正是错误 schema 带着自信上线的开始。

这些是真实的边界。Akshay 的做法能成立，前提是每条交接文档都足够具体，而文档质量又取决于定义文档格式的人。他把这总结成一句：交接质量是文件格式问题，不是提示词问题。

完整 prompt、setup 步骤和 InsForge 配置在 Akshay 的原文 里。InsForge 在 GitHub 开源，Apache 2.0：InsForge/InsForge。