14个bot，4个主管：多智能体又长成了公司

Akshay Pachaar 在 X 上展示了一套 Grok Bot 配置。14个bot，分成四组，他只直接和其中4个对话。这4个是 Pam、Tyrion、Gilfoyle、Rachel，分别管行政、研究、代码和设计。任务先到主管，主管分给团队，完成品再交回。

组织结构图里，Pam 下有 Erin、Dwight、Oscar；Tyrion 下有 Sam、Varys、Littlefinger；Gilfoyle 下有 Dinesh、Jared；Rachel 下有 Monica、Chandler。每个bot都有职位，状态标着 working 或 on hold。Akshay 说，接下来会发完整视频，覆盖如何复现这套配置、Grok Bot 的底层机制、怎么加技能和集成，以及如何用 Claude Code、Codex 或任意 harness 运行。

评论区里，已经有人跑过类似结构。Dave 说他有18个bot，一个 chief of staff 负责把请求路由给其余bot；Gdmv 用大约20个bot管健身房，每天先打开晨报，看夜里发生了什么；Shanto 说自己跑了约30个，让系统维持住的关键是每个bot交回证据，不能只回一个 done，否则那4个主管只是在转述猜测。

ege 的做法相反。他删掉12个bot，改成每个团队一个 lead 加一个 builder，理由是省额度。按他的经验，一个团队超过2个bot，多出来的主要是在增加 handoff。他还问了一个很具体的问题：这14个里，每天真正跑起来的有几个？Theo 则用共享文件夹解决协作，每个bot保留自己的记忆文件，也能读其他bot的文件，不靠互相发消息。Benjamin 担心静默交接，BlockedPath 担心 stop conditions 在多层转手下失效。Justin 问得更直接：为什么要4个主管，不用一个 orchestrator？

这套配置有意思的地方，在于它又一次把多智能体系统排成了公司。接口收缩到4个主管，对话负担确实小了。但多一层转手，就多一次信息损耗和 token 消耗。评论里最实际的问题落在完成定义上：主管说 done，文件却没被打开，这套结构就只是在传猜测。命名用熟悉的角色会让对话更像人，也会带来边界问题。有人开玩笑说，Gilfoyle 可能正在回复房东。