深入浅出聊 AI：一个人，怎么带一支智能体团队

2026 年 8 月，Grok 上线了一个叫 Bot 的功能：你可以在里面养一队有名字、有头像、有各自角色和记忆的 AI，它们住在一台属于你的云端电脑上，能开浏览器、能读写文件、能用你的账号登录各种应用，你合上笔记本它们还在干活。它们之间还能互相发消息、拉群聊。

社区里很快出现了各种编制：一个「幕僚长」下面挂着调研、写作、运营几个专员，像模像样。

也很快出现了另一类帖子。有人搭了个六人（六 Bot）团队，第一天就烧掉了一周额度的四成多——他后来发现，那六个 Bot 里有三个在重复查同一批网页。

这一篇，就是想帮你在动手搭队伍之前，先把这件事想明白。

上一篇我们讲了怎么跟一个智能体好好共事——委托、装备、护航、验收、沉淀。这一篇讲那个几乎所有人都会冒出来的下一个念头：

「一个挺好用，那派一群是不是更厉害？」

我的答案会让你有点意外：大多数时候，不是。 但我会把「为什么不是」和「什么时候是」都讲透，讲完你自己就能判断。

一、先分清三个词：临时工、包工队、正式编制

这几年冒出来的词有点多——subagent、multi-agent、agent teams、bot mode、A2A。它们其实是同一个方向上的三个层次，差别在于**「活儿干完之后，它还在不在」**。

第一层，子智能体（subagent）——临时工。

主智能体接到一个大活儿，自己派出去几个小的：「你去查这三家，你去查那三家。」小的在自己那间屋子里干完，回来交一页纸，然后就地解散，什么都不留。下一次再派，是全新的。

第二层，多智能体（multi-agent）——包工队。

几个智能体同时在一个任务里干活，可能还互相说话、互相传结果。它们比临时工存在得久一点，但基本还是围着这一件事转，事完了也就散了。

第三层，智能体团队（agent teams / bot mode）——正式编制。

这是 2026 年真正的新东西。每个成员有固定的名字、角色、权限、和自己的长期记忆，跨越很多件事、很多天持续存在。你今天教会「调研专员」的规矩，下周它还记得。Grok Bot 是这一层的典型：每个 Bot 是一个常驻的身份，甚至可以设成「不用你开口，到点自己开工」。

为什么要分清楚？ 因为这三层的代价完全不一样。

临时工用完就走，没有历史包袱——这恰恰是它最大的优点。正式编制有记忆、有持续性，但也就有了「记错了怎么办」「它上周那个误解一直带到今天」的问题，就像一个带着旧成见的老员工。

一句话记住：持久性是好处，也是负债。

二、你为什么想要一支团队

先诚实面对自己：你想搭团队，通常是因为下面三件事之一。

动机一：一个脑子的桌子太小。 这是真需求。

模型每一轮能看见的东西，装在一块有限的「桌面」上（行业里叫上下文窗口）。塞得越满，关键信息越容易被埋在中段。如果一个任务的材料量本来就超过一张桌子，那就只能分桌——这是硬约束，不是偏好。

动机二：想快。 这也是真需求。

十家公司要调研，一个一个查是十份时间，十路同时查是一份时间多一点。只要这十路互不相干，并行就是纯赚。

动机三：想要「专业分工」。 这一条，多半是幻觉。

我们太习惯人类组织的逻辑了：一件事复杂，就拆成几个岗位，各司其职。但人类分工的前提是——每个人的脑子是独立的、能力是有差别的、而且沟通成本是真实存在的。

智能体不满足前两条。你派出去的「法务专员」和「文案专员」，很可能是同一个模型，只是开场白不同。它们不会因为你给它起了个名字就真的变专业，倒是沟通成本一分不少地留下了。

判断标准很简单：如果你的分工只是给同一颗脑子换了几个称呼，那你买到的只有开销。 真正有意义的分工只有一种——它们能碰的东西不一样（一个只读、一个能写；一个能上网、一个只能看内网），也就是上一篇说的「装备」不同。

分角色不叫分工，分权限才叫分工。

三、编排的四种形状：其实就是四种办公室

真要搭，业界跑通的形状就那么几种。我把它们翻译成你熟悉的办公室场景，你一看就知道自己的活儿该用哪种。

形状一：编排者—工人（总编派实习生）

最常见的一种。一个主智能体持有完整任务，按需派出几个临时子智能体，每个在自己干净的桌子上干一小块，干完只交一页摘要，然后消失。

就像一个总编：「你去查这三家，你去查那三家，回来各给我一页纸——别把你翻过的一百个网页都端到我桌上。」

这个形状同时解决了两件事：并行（快）和桌面隔离（主线的桌子不会被堆满）。

它确实有效。 Anthropic 公开过他们研究系统的内部评测：这种「一个主 + 若干子」的组合，在研究类任务上比单个更强的模型独干高出约 90%。

但请把三个限定一起记住——内部评测、研究类任务、特定的模型搭配。这不等于「多智能体永远更强」。

代价也是公开的：这类系统消耗的 token 大约是普通聊天的十五倍。

适合：广度搜索、多线索并行调研、大批量材料筛选。

形状二：流水线（顺序交接）

A 干完交给 B，B 干完交给 C。像审批流：起草 → 校对 → 排版。

适合：步骤固定、顺序不能乱的活儿。

风险：错误会顺着流水线一路放大——第一道工序理解偏了，后面三道会把这个偏差装修得非常精美。

形状三：分诊台（路由 / 交接）

前面站一个「前台」，判断这件事该交给谁，然后转过去。像医院分诊。

适合：入口任务种类杂、但每一类都有明确归属的场景（比如客服工单）。

风险：这是我下面要重点讲的头号翻车方式。

形状四：写作—审稿（循环评审）

一个负责产出，另一个专门挑毛病，来回几轮再交付。

这是我认为对普通人性价比最高的一种多智能体用法，而且它完美符合「读并行、写单线」——挑毛病的那个只提意见，不动手改。它贡献的是智力，不是动作。

适合：质量敏感、有明确评判标准的产出（对外文案、数据核对、合规检查）。

四、为什么很多队伍反而更糟

Cognition 团队（做 Devin 的那家）在 2025 年发过一篇标题很不客气的文章：《不要构建多智能体》。他们的论点是：多智能体会把上下文切碎——每个成员只看到局部，各自做出局部合理、彼此却打架的决定，最后合并时集中爆炸。

这是他们的立场，不是行业定论。但结合实践者反馈，有三种翻车方式反复出现，值得你在搭队伍之前就认识它们。

翻车一：踢皮球（无限交接）

A 觉得这事该 B 管，转给 B；B 觉得该 C 管，转给 C；C 又转回 A。

根因不是它们笨，是没人拥有这件事。 每一次转手都要重新理解一遍任务，理解一次丢一点上下文，转了三圈之后，谁也说不清最初要干嘛了。

这在人类组织里你见得太多了——区别只是，人转三圈要三天，它们转三圈只要三分钟，而且账单在跳。

解法：任何一个任务，必须有且只有一个 owner。分诊台可以决定「谁来干」，但决定之后就不许再往回踢。

翻车二：谣言传染（幻觉被下游当真）

这是最危险的一种。A 编了一个数字，B 拿到之后完全信任，还基于它做了进一步推演，写得有理有据。

到你手上的时候，你看到的是一份经过「多个环节」的成果，感觉上更可信了。但它其实只是同一个错误被抄了三遍，还越抄越有细节。

这里有条原理加倍生效：智能体的产出永远看起来很完整，而完整感不等于正确性。 多智能体做的事，往往是把这份完整感做得更足。

解法：跨环节的关键事实必须重新核，不能因为「上一棒交过来了」就免检。 形状四那个专门挑毛病的角色，价值就在这。

翻车三：一起走偏（共享偏见的相互印证）

你派三个智能体去评估同一个方案，三个都说好，你觉得「三方验证过了」。

但它们很可能是同一个模型，带着同一套倾向。 三个一模一样的脑子投票，票数是三，独立意见只有一个。

解法：把「多方验证」这个词从你脑子里删掉。它们不是三个人，是一个人说了三遍。

那笔账：贵得比你想的多

• token 十几倍起。 前面那个数字不是危言耸听。
• 排查成本翻倍。 一个智能体出错，你看它的日志；五个智能体出错，你得先搞清楚是哪一环坏的——而它们互相之间只传摘要，中间的推理过程往往已经丢了。
• 额度烧得飞快。 开头那个六 Bot 团队一天烧掉四成周额度的例子（早期使用者报告），根源就是三个 Bot 在重复劳动而没人知道。人类团队里，重复劳动会有人抱怨；智能体不会抱怨，它们会安静地、勤奋地、同时干同一件事。

我自己从这场争论里拿走的一条经验法则是：

读可以并行，写要单线。 多出来的智能体应该贡献智力（查资料、给意见、挑毛病），而不是贡献动作（各自去改同一批东西）。

这条是我的总结，不是谁的原话。但它和你带团队的经验完全一致：三个人分头调研没问题，三个人同时改同一份 PPT 就是灾难——最后你花在合并版本上的时间，比自己写还长。

五、常驻 AI 同事：新东西，也是新的坑

回到开头的 Grok Bot，它代表的是第三层——正式编制。这一层带来的新能力和新风险，都值得单独说。

新能力是真的。 一个常驻 Bot 拥有自己的云端电脑，能像人一样登录你的应用、点来点去、保存文件；你关掉浏览器它继续干；干得好的流程可以存成「例行公事」，以后到点自己跑。这不再是「你问它答」，而是「它有自己的班次」。 这是产品形态上的真正跨越。

但有三个坑，我认为比功能本身更值得你先知道。

坑一：分身不等于隔离。

你养了六个 Bot，直觉上会觉得这是六个独立的同事，各管各的。但据 Grok Bot 的文档说明，这些 Bot 共用同一台云端电脑——文件是一堆的，浏览器登录状态是共享的，而且官方明确提醒：不要把不同的 Bot 当作安全边界来用。

翻译一下：你以为是六个人各有各的办公室，实际上是六个人共用一张办公桌和一个已登录的账号。 那个只该看公开资料的「调研专员」，和那个能登录你邮箱的「行政专员」，站在同一块地板上。

这一条我认为是本文最实用的一句提醒，因为它反直觉：给智能体起不同的名字，不会给它们建起不同的墙。 墙必须在权限层单独建。

坑二：它现在有钥匙了。

一个能自己登录你的账号、能读写你的文件、能自动跑例行公事的东西，是可以自己做出不可逆动作的——发出一条消息、付一笔钱、删一个文件。

有一条原则在这里不打折，只会加重：凡是动钱、动对外沟通、动删除的动作，都必须留在你的闸门里。 常驻和自动化提高的是效率，不是它的判断力。

坑三：它还很年轻。

这类产品 2026 年才上线，早期使用者报告的问题包括云电脑卡死、响应失败、额度烧得极快、共享登录带来的暴露风险、以及上下文越攒越乱。它在演示里很漂亮，在你那套乱糟糟的真实流程里会怎么样，现在还没有足够的样本。

我不是劝你别用。我是说：用它跑那些「错了也能撤销」的活儿，从这里开始积累判断。

六、协议：MCP 和 A2A，一分钟讲完

你会在新闻里反复看到这两个缩写，分工其实很清楚：

• MCP 是智能体连工具的标准接口——怎么调用你的日历、文件、数据库。
• A2A 是智能体委托智能体的标准接口——怎么把一件事交给另一个智能体，哪怕它是别家公司做的。

值得注意的动向是：这两个协议现在都交给了 Linux 基金会下面的 Agentic AI Foundation 托管——MCP 在 2025 年 12 月，A2A 在 2026 年 8 月。基金会的成员名单里，OpenAI、Anthropic、Google、微软、AWS 都在。

竞争最激烈的几家，在「接口怎么定」这件事上坐到了同一张桌子。 这通常意味着这一层要变成基础设施了，就像当年的 USB：谁家的鼠标都能插谁家的电脑，插口本身不再是卖点。

对你的实际意义有两条，一好一坏：

好的是，未来你不容易被锁死在一家生态里，团队成员可以来自不同厂商。

坏的是，当 A 家的智能体能顺畅地委托 B 家的智能体时，「谁在跟谁说话、谁有权限碰什么」会变得更难看清。这是我认为下一个真正的治理难题——不在单个智能体身上，在它们之间的那些线上。

七、真正的难点在管理：搭队伍的五个决定

如果你已经确定要搭，下面五个决定按顺序做。它们都不需要你懂技术，但每一个做错都会让队伍变成负担。

决定一：先定「谁能写」，再定「谁干什么」。

前面说过，分角色不叫分工，分权限才叫分工。最小可用的编制是：一群只读的 + 一个能写的。 调研、检查、提意见的都只给只读权限；真正改文件、发东西的只留一个，而且它的动作要过你的闸门。

决定二：交接的单位是「交付物」，不是「职责」。

人类交接可以靠默契和补问；智能体交接只有你写下来的那些字。所以别说「你负责市场分析」，要说「你产出一份表格，包含这五列，每行必须带来源链接」。

我的说法是：编排的最小单位不是任务，是「可验收的段落」——一段有明确产出、结束时有人（或有规则）能说「这段过了」的工作。

为什么？因为错误会复利——一个十步的流程，哪怕每步成功率高达 99%，连乘下来也只剩九成。一个二十步的连续流程，任何一步的偏差都会被后面十九步放大；切成四段之后，偏差最多在一段里累积，交界处就被截断了。分段不是为了管理好看，是为了对抗那条乘法。

决定三：从「自动化一个交接」开始，不要从「自动化一个岗位」开始。

大多数人的第一反应是「让 AI 顶替某个岗位」——这个方向几乎必然失败。岗位是由无数隐性判断、临时例外和人际协调粘合起来的，那些东西没写在任何流程文档里。

更靠谱的起点是某个人做完一件事、把结果交给下一个人的那个节点。这类节点有三个天然优势：输入输出明确、有现成的验收标准（下游会抱怨）、而且通常已经被写成文字了（工单、邮件、表格）。

顺带一个判断：步骤明确的活儿走固定流程（把 50 份合同的甲方和金额填进表格——路径写死，稳当便宜可复现）；步骤说不准的活儿才让它自己探索（「查一下这个月销量为什么掉了」）。最常见的浪费是把第一类当第二类做：明明是填表，却让它每次重新想一遍怎么填，既贵又不稳定。

决定四：账要算在明处。

四个数就够看趋势：一次通过率、返工率、人工复核时长、单任务成本。

特别盯住第三个。很多「AI 提效」的收益，其实是被悄悄转移成了下游的复核工作量——上游快了两小时，下游多花了三小时核对，账面上还显示提效了。

决定五：谁负责，必须落到一个人名下。

智能体做的事，「系统做的」不是一个可接受的答案。这不是官僚要求——有人负责，才有人去看那些没人愿意看的日志。

八、什么时候该上，什么时候别上

讲完机制和管理，给你一张能当场用的判断表。

先说结论：先把一个用到极致。 大多数职场场景，一个配置好的智能体绰绰有余。这个建议和 Anthropic、Cognition 两家的公开立场都不冲突——一边说多智能体在特定场景很有效，另一边说别乱拆，中间那条线就是下面这三个信号。

同时满足三条，才考虑上团队：

1. 任务是「摊开」的，不是「往下挖」的——要同时探索很多条互不相干的线索（同时调研十家公司），而不是顺着一条线索一层层深挖；
2. 材料量确实超过一张桌子装得下；
3. 各路工作互不写同一份东西（读并行，写单线）。

反过来，出现这四个信号之一，就别上：

• 你说不清「什么叫做好了」。 一个智能体会放大模糊，一群会把模糊装修成共识。
• 各路要改同一份东西。 合并冲突的成本会吃掉全部收益。
• 任务是深挖型的——后一步依赖前一步的判断。这种活儿拆开只会丢上下文。
• 你还没搞清楚出错时怎么排查。 单个智能体你看得懂日志；一群的日志你看不看得懂，最好在出事之前先确认。

九、回到那台云电脑

开头那个六 Bot 团队烧掉四成周额度的故事，现在可以给出诊断了：它不是技术问题，是管理问题。 三个成员在重复查同一批网页，因为没人拥有那件事，也没人定义什么叫「查完了」。

这个毛病，任何一个带过人的人都眼熟——只是人类团队里，重复劳动会有人抱怨。智能体不会抱怨，它们会安静地、勤奋地、同时干同一件事，直到额度用完。

三条带走的结论：

1. 分角色不叫分工，分权限才叫分工。 给它们起不同的名字，不会给它们建起不同的墙。一群只读的 + 一个能写的，是最小可用编制。
2. 读可以并行，写要单线。 多出来的智能体贡献智力（查、审、挑毛病），不贡献动作。质量敏感的活儿，配一个「只挑毛病不动手」的角色，是性价比最高的多智能体用法。
3. 先把一个用到极致。 三个信号同时满足才上团队；缺一条，你买到的多半只有开销和排查成本。

一页记忆卡：先定谁能写，交接给交付物，一任务一 owner，跨环节重新核，账算在明处。

上一篇的记忆卡还是那五句——委托看可逆，装备要精简，护航设卡点，验收不免检，沉淀能复利。 带一支队伍，不过是把这五句在每个成员身上再做一遍，外加一句：你还得管他们之间的那些线。

本文引用的主要来源

• Anthropic，How we built our multi-agent research system（anthropic.com/engineering）——编排者—工人架构；约 90% 提升为其内部研究类评测、特定模型组合；约 15 倍 token 为其自身产品数据
• Cognition，Don’t Build Multi-Agents（Walden Yan, cognition.ai/blog, 2025）——该团队立场，非行业定论
• Grok Bot 2026 年 8 月公开发布信息与产品文档说明（常驻云端环境、Bot 间通信、例行任务；「不要把不同 Bot 当作安全边界」）；早期使用者报告的额度消耗与共享登录问题 ⚠️ 多为二手来源，发布前建议回官方文档复核
• 2026 年公开的多智能体编排模式归纳（顺序 / 并行 / 层级 / 交接 / 循环）与实践者报告的失败模式（无限交接、幻觉沿链传播）
• Linux Foundation / Agentic AI Foundation 关于 MCP（2025-12）与 A2A（2026-08）托管的公告
• 前篇《与智能体协作》所引的 METR、τ-bench、NIST、Microsoft × CMU 等来源，见该篇文末

说明：本文中标注为「我的判断」「我认为」「我的总结」的部分是观点，其余为可追溯的公开信息。涉及具体产品的描述基于 2026 年 9 月的公开信息，这类早期产品变动很快，请以你使用时的官方文档为准。

下一篇预告：聊怎么把这套东西真正装进你自己的工作流——从哪一件事开始、怎么衡量它到底有没有帮到你，以及怎么避免「提效」只是把工作量挪到了下游。

（如果你还没想好该挑哪一款智能体，可以回看《能干活的助理》那一篇，里面有一套量骨架的判据。）