智能体团队：要组织架构，不要任务清单

当一个 bot 不够用时：角色分工、调度者、共享渠道，以及小团队的纪律。

最令人惊艳的 Grok Bot 项目都长一个样：不是一个更大的 bot，而是多个小 bot 各有名字和岗位——调研员、写手、审稿人、调度员——像一家微型公司那样协作。这一课讲团队怎么真正跑起来，以及没人提醒过你的那些坑。

为什么团队胜过一个大型 bot

一个 bot 同时做调研、写稿、发布，等于把三份工作塞进同一个上下文。上下文会串味：调研腔漏进稿子里，审稿变成走过场（“看起来不错”），每次修改都可能弄坏不相干的东西。

按角色拆开后，三件事立刻改善：

• 每份提示词保持简短——调研员不需要知道发布规则。
• 审稿变成真的——独立的审稿人对稿件没有沉没成本。
• 故障可以定位——“写手无视了资料”直接点名凶手。

最小可行团队

两个 bot 加一个人：

• 干活的——执行：调研、起草、盯梢、分诊。
• 调度者——管花名册：叫醒干活的、收产出、只升级真正需要你的事。

就这样。多数”我用 bot 开了家公司”的故事，都是这个模式的重复。只有当调度者的岗位说明开始出现复句时，才值得加专家（写手、审稿人、侦察员）。

组织架构落地

每个 bot 一份角色提示词，各 10 行左右：

你是 Scout。你只找符合 config.md 的候选项。
绝不起草、绝不发送、绝不拍板。输出：一份清单，
每项附来源和一行理由。最多 10 条。

你是 Chief。花名册：Scout、Writer、Reviewer。
每天早上：逐一唤醒、收产出、对照 jobs.md，
然后给我一份报告：已完成 / 受阻 / 需要我。
你绝不亲手替专家干活。

调度者的那句”绝不亲手替他们干活”比看上去重要——调度者都热心，而一个什么都重写的调度者，就是一个带了管理层包袱的大型 bot。

共享渠道与文件

团队用和单体 bot 相同的原语协作，只是更讲纪律：

• 共享任务板文件（jobs.md）——每个任务一行状态：排队中、进行中、受阻、完成。
• 统一汇报渠道——所有 bot 向同一个地方交作业。绝不和单个 bot 私聊问进度——舰队就是这么失联的。
• 花名册——谁在编、角色是什么、最后在线时间。监工模式读这个文件，发现谁悄悄辞职了。

失败模式，如实点名

• **中层膨胀。**调度者生出调度者。给组织架构设上限；一个只会开会的 bot，删。
• **沉默离职者。**某个 bot 的定时任务两周前就停了，没人发现——因为它的报告还在来，来自过期的运行。药方：花名册里记录最后在线时间。
• **上下文复印件。**每个 bot 都带着一份规则拷贝，拷贝之间渐渐不同。药方：一份规则文件，每次运行都读，全员引用。
• **审稿表演。**审稿人全票通过。药方：给审稿人明确的否决标准，并要求引用标准。

什么时候不需要团队

如果整个工作流塞得进一条提示词加一个文件，团队就是多余的 overhead。只有当不同角色需要不同指令、不同时间表、不同权限时，团队才回本——之前都不用。