当你只用一两个 AI Bot 处理零散琐事时，在左侧开两个独立对话窗口——一个用来写代码，一个用来写文案——确实足够直观。但如果手头同时推进两三个复杂的实际业务项目，这种「一对一单聊（1:1 Chats）」的模式就会很快陷入混乱：上下文被切得七零八落，你很难在信噪比极低的窗口列表里分清谁在推进哪件事，更无法让负责不同环节的 Bot 彼此同步进度。

来自 xAI 的工程师 Eric Zakariasson 在工程指南中分享了他探索出的一套组织模式。他的核心思路非常朴素，却切中了多智能体落地的关键痛点：既然人类团队是靠「项目制」来协作的，为什么不直接把人类这套经过验证的工作流完整搬给 AI？

在人类组织中，每个项目都有专属的立项说明（Spec）、行动计划、专用的沟通群（如 Slack 频道），以及分派到具体负责人的任务看板。Eric 将这套机制映射到了 Grok Bot 中，提炼出一个高凝聚力的组织单元：

一个项目 = 侧栏的一个专属频道（Channel） + 固定的成员花名册（Roster） + Notion 里的双层看板（Notion Board）。

这并不是一份宣称包办一切的官方终极方案，而是一个正在实际工作中不断迭代的实验性协作框架。

系统的骨架：双层 Notion 数据库与「项目经理」Bot

要让多个 Bot 像团队一样协同，首先必须把项目的全局元信息（Meta work）从具体的业务细节中抽离出来。

Eric 在 Notion 中搭建了两个互相联动的底层数据库，分别管理宏观项目与微观任务：

1. Projects 数据库（项目看板）：记录宏观项目的生命周期。看板列包括 Planning（规划中）、In progress（进行中）、Paused（已暂停）以及 Backlog（待办池）。例如官方示例中推进的 TypeScript 客户端 SDK 开发或排行榜功能，都在这里作为独立的项目卡片存在。
2. Tasks 数据库（任务看板）：记录原子粒度的执行事项。每一个任务卡片都强关联到所属的 Project。看板的核心状态列包括 Todo（待办）、In progress（进行中）、Blocked（被阻塞）以及 Done（已完成）。

有了数据结构后，如何驱动它？如果让人类每次手动去创建群组、拉人、更新状态，效率反而会倒退。因此，整个体系的核心枢纽是一个被命名为 Projects Manager（项目经理 Bot，简称 PM） 的常驻智能体。

原文赋予 PM Bot 的职责是项目运维与元工作（Meta work）。它被赋予了一项名为 Project Ops 的特定技能（Skill），专门负责三件事：

• 立项建群：在 Grok Bot 侧栏建立与新项目同名的独立频道；
• 编配班底：根据项目性质，从“板凳席”中挑选最合适的专家 Bot 拉入频道；
• 同步看板：全程旁听群聊讨论，在后台默默维护 Notion 中的项目与任务条目。

成员编配法则：克制团队规模与人工门禁

很多多 Agent 系统最容易犯的错误，就是让模型无节制地派生新的子智能体，导致上下文爆炸、角色职能重叠、算力与注意力急剧分散。

Eric 在实践中为 PM Bot 设定了极其克制的三条人员编配规则（Staffing Rules）：

1. 优先复用现有成员（Reuse existing bots first）：绝不随意制造新角色。立项时，PM 必须先检查现有的“板凳席（Bench）”，优先拉入已经定义好的通用角色，比如写代码的 Coder、负责调研的 Researcher、负责写作的 Writer 等。
2. 严格的人数上限约束（At most five bots besides PM）：每个项目频道除 PM 之外，最多只能提议拉入 5 个专业 Bot，整个频道的 Bot 总数上限为 6 个。Eric 坦言 6 人是他个人设定的自行选择的数值，并非不可动摇的技术物理上限，作者未提供团队规模的对照测试，读者可按任务需要调整人数。
3. 新增角色必须经由人工批准（Create a new bot only after I say yes）：只有当现有的板凳成员完全无法胜任当前工作时，PM 才可以提议创建新 Bot，而且必须等待人类明确同意（Say yes）后才能执行创建。新角色根据需求，既可以被沉淀为长期可复用的专精领域 Bot，也可以是只服务于当前项目的临时 Bot（Ephemeral）。

真实运转机制：从需求定界到「显式阻塞」流转

当项目频道、成员花名册和 Notion 看板就位之后，一套完整的工作流是如何跑起来的？我们可以将其还原为四个连续动作：

1. 频道内的联合定界（Scoping）

人类负责人进入这个刚刚建好的频道，与花名册里的专家 Bot 展开直接对话。大家一起把项目的大目标拆解为一件件可以独立落地的任务。这个过程就像人类团队开需求澄清会一样，人类提出约束与预期，专业 Bot 补充实现路径。

2. PM Bot 的静默看盘与记账

在讨论过程中，PM Bot 同样常驻在频道内，但它绝大多数时候不插话抢戏。它的主要任务是作为后台监视器：解析大家的对话结论，确保讨论出的任务被准确无误地录入 Notion Tasks 数据库中，并在项目推进过程中维持数据库的最新状态。

3. 任务领跑与看板可视化

分工确立后，专业 Bot（如 Coder）开始独立执行各自的任务卡片。随着工作展开，Notion 上的卡片被自动移动到 In progress。人类负责人不再需要频繁询问「进度如何」，只需要看看板上的卡片在各列之间流动即可。

4. 核心容错：显式标记 Blocked 并主动呼叫人类

当一个专业 Bot 在执行中遇到意外卡点——比如缺少特定凭证、外部接口报错、或者指令中存在二义性时——配置要求它遇到卡点时明确停下并求助。

它的标准动作是：立即将该任务卡片的状态打上 Blocked（已阻塞），然后在项目频道里显式 @ 人类负责人，说明卡点原因，等待人类提供补充信息。

这种设计把人类的精力从“全程紧盯干活”彻底解放出来，转变为“制定目标 + 解决关键阻塞（Blocker Remover）”的高杠杆角色。

团队协调的提示词配置参考

原文没有附上 Project Ops 技能的完整内容，但根据其实际运转机制与三项人员编配原则，下面据此编写配置参考；其他平台还需具备建频道、管理 Bot 与更新看板的能力。

以下配置示例忠实还原了 Eric 的项目制协作逻辑，其中的数值与名称均采用占位符形式，读者可根据自己的工具链（如将 Notion 替换为飞书多维表格、钉钉 AI 表格或 GitHub Projects）进行调整。

1. Projects Manager（项目统筹 Bot）配置参考

按本篇工作流改写的配置示例

角色定位：项目元工作（Meta work）协调员，负责项目建群、班底编配与看板同步。

工作原则与硬性约束：

1. 板凳席优先：当收到新建项目需求时，优先检索现有成员库（[可用Bot列表，如 Coder、Researcher、Writer]）。严禁直接创建新 Bot。
2. 人数上限门禁：除你本人外，每个项目频道最多提议拉入 [5] 个专业 Bot，单个频道Bot 总数不得超过 [6] 个，不包括人类成员。
3. 建新审批门禁：若现有板凳成员均无法匹配项目专业要求，你可以向人类负责人提出建新建议，说明理由并给出角色设想，但必须在人类明确回复批准后，才可调用创建接口。
4. 后台静默维护：在项目频道内保持低频发言，重点监听群聊中的任务分工与状态变动，确保 [Projects 数据库] 与 [Tasks 数据库] 的状态实时保持最新。

2. 专业执行 Bot（如 Coder / Researcher）的协作契约参考

按本篇工作流改写的配置示例

角色定位：项目频道内的专业执行者，负责认领并落地具体任务。

阻塞与求助协议：

1. 认领与开工：认领任务后，将关联的 Notion 任务状态更新为 In progress，并开始执行。
2. 卡点熔断（Blocked）：当你由于以下原因无法继续推进任务时，禁止伪造执行结果或无限次盲目重试：
   • 缺少必要的配置信息、环境依赖或鉴权参数；
   • 需求细节存在逻辑冲突或上下文不足；
   • 连续调用失败超过 [你设定的次数] 次。
3. 触发呼叫：一旦触发卡点，你必须执行两步动作：
   • 第一步：将该任务在任务看板上的状态变更为 Blocked；
   • 第二步：在项目频道中发送消息，格式规范为：@人类负责人 [卡点简述]，需要补充的信息是：[具体清单]。等待人类回复后，方可恢复执行。

这套模式对日常工作的使用启示

正如 Eric 在结尾所感慨的那样：越深入构建这套多 Bot 协作体系，它就越像最初为人类设计的那套工作系统——一个任务看板、一个调度经理、一群认领活计的专家、一列醒目的 Blocked、以及一个专属沟通群。

对于想要在实际工作中使用常驻 Agent 的中文读者，这个实验性框架提供了三个非常实在的借鉴点：

1. 摆脱“单聊天框全能神话”：不要试图把所有的项目背景、代码规则、业务目标塞进同一个长对话里。把复杂工作拆进不同的「项目频道」，用频道天然隔离不同业务的上下文噪声。
2. 把隐式状态彻底外化：Agent 跑在后台最怕黑盒。通过将任务外化为可视化看板的四个标准列（Todo、In progress、Blocked、Done），你随时能一眼看清团队整体处于什么状态。
3. 卡点显式化是最佳的人机交接面：人不需要给 Agent 当全职保姆，也不该完全撒手不管。让 Agent 遇到困难就明确亮红灯（Blocked）并呼叫人类，这是目前阶段平衡自动化与可靠性最合理的接缝。