AI 学习 | 多个 Agent 之间是如何协作的?

9 月 28 日，Manus 发布了个人 Agent 应用 Cue。第二天，OpenAI 在开发者大会上发布了 dots。

两款产品想做的事儿很像：给你一个长期在线、替你办事的 Agent。每个 dot 都有自己的云端电脑和浏览器，能连接 4000 多个应用；你可以在 ChatGPT、Slack 里给它发消息，也可以直接和它通电话。Cue 则给每个 Agent 配上了自己的邮箱、手机号、钱包和电脑。

两款都试了下，dots 的体验要好一些。我先打电话让它总结当天没读过的邮件，说几句话就把任务交代清楚了，很方便。dots 预置的形象也很可爱，有点 3D 质感。

正在和我的 dot“玉米团子”通话

总结出来的邮件大多是新闻和广告，我就让它直接帮我退订。

“玉米团子”找到邮件里的退订入口，用自己的云端浏览器完成了退订

Cue 能给 Agent 配手机号、银行卡还挺让人眼前一亮，不过我还没实际用。细节上，两者都让对话气泡的颜色跟随 Agent 形象的颜色，Cue 把颜色加在 Agent 发出的消息上，dots 则加在用户发出的消息上，后者更符合一般人的直觉。

这两款产品还有一个共同点：都开始让多个 Agent 一起干活。dots 已经能把修 bug 这类代码任务派给 OpenAI 的编程 Agent Codex，OpenAI 还说，未来会有一组 dots 替你协同工作。Cue 则能把几个 Agent 拉进同一个群，一个查场地，一个列候选清单，一个写演示文稿，彼此交接。

Cue 里的几个 Agent 分管工作、邮件和日常事务，也可以出现在同一个对话里

于是，问题出现了。

一个 Agent 已经能打电话、处理邮件、自己操作电脑，为什么还要一群？一群 Agent 之间，又是怎么协作的？

多 Agent 协作（Multi-Agent）不是“人多力量大”这么简单。它要解决的，是单个 Agent 绕不过去的几个限制；它带来的新麻烦，几乎都出在 Agent 和 Agent 的交接上。把这两件事想清楚，也就能判断它在哪些场景有用。

#01一个 Agent 不够用，是因为它的“工作台”太小

在 AI 学习 | 什么是 Agent（智能体）？里聊过，Agent 每决定下一步，都要看眼下提供给模型的材料，也就是上下文（Context）。可以把它想成 Agent 面前的一张工作台：你的要求、查到的网页、工具返回的结果，都摊在这张台子上。台子的大小是有限的。

假设你让一个 Agent 筹备公司年会：200 人，预算 10 万，要找场地、定菜单、排节目、写邀请函，还要订接驳大巴。它只能一件一件做。先查二三十家场地，每家的介绍、报价和交通都摊上工作台；再去比菜单、问大巴。等它开始写邀请函，台面早已堆满，你一开始交代的“有十几位同事吃素”，很可能被压在了最底下。一件件查下来，本身也很慢。

换成一群 Agent，主 Agent 先把年会拆成几件事，分别交给几个子 Agent（Subagent）：一个只管场地，一个只管菜单，一个只管大巴。管场地的 Agent 可以翻遍三十家场地，最后只交回三家候选的对比。主 Agent 的台面上，只放大家交回来的结论。

每个 Agent 用一张干净的工作台，把大量材料消化成简短的结论，再交给负责汇总的 Agent。这是多 Agent 协作最基本的原理。

Claude 有一个研究功能（Research），能自己上网查资料，写成带出处的报告。Anthropic 在 2025 年 6 月公开过它的设计，用的就是这种结构：主 Agent 负责规划和汇总，一次派出 3 到 5 个子 Agent 并行搜索。在内部的研究评测里，这套系统比单独一个 Claude Opus 4 Agent 的表现高出 90.2%；遇到复杂的问题，研究时间最多能缩短 90%。

Anthropic 研究功能的架构：主 Agent 分派多个搜索子 Agent 并行查找，再由引用子 Agent 补上出处（from https://www.anthropic.com/engineering/multi-agent-research-system）

多 Agent 为什么表现更好？Anthropic 在另一项测试里找过原因。这项测试专门考 Agent 上网查找冷门信息，分析结果显示，表现好坏的差别，八成能用一个数字解释：完成任务时一共处理了多少 Token（可以理解成读写的文字量）。调用工具的次数和选用的模型，影响都排在后面。

在这类任务里，读得越多，答得越好。一个 Agent 能读多少，受限于它那张工作台；多 Agent 相当于把一张工作台扩成了好几张，能读下的材料自然就多了。

代价也在这里。按 Anthropic 的统计，Agent 消耗的 Token 通常是普通聊天的 4 倍，多 Agent 系统则在 15 倍左右。一群 Agent 干活，账单也是一群人的。

#02派出一个子 Agent，其实只是递过去一段话

主 Agent 把活派出去的那一刻，具体发生了什么？

对主 Agent 来说，派出一个子 Agent 和搜索网页一样，都只是调用一个工具。上面那张架构图里，主 Agent 的工具清单上就写着 run_subagent，意思是“派出子 Agent”。OpenAI 给开发者的 Agents SDK 里，把对话转给退款专员，在模型眼里也只是一个名叫 transfer_to_refund_agent 的工具。

调用这个工具时，主 Agent 要填的内容就是一份派活单，一段写给另一个模型看的文字。

系统收到派活单，会新开一个 Agent。它的工作台几乎是空的，只有这份派活单，加上系统事先给它的角色说明和可用工具。主 Agent 查过什么、你之前交代过什么，它一概看不到。Claude Code 的文档也写明，派活一方的对话记录不会带过去。

子 Agent 接着跑自己的工作循环，查资料、读网页、做判断，直到交差。交回去的只是一份汇报，它翻过的三十个网页都留在自己的工作台上。主 Agent 读到这份汇报，就像读到一次搜索结果，再决定是继续派活，还是开始汇总。

Agent 之间的协作，靠的就是互相递文字。每个 Agent 只看得到递到自己手上的那几段话。

这也说明了“不同的 Agent”不同在哪。让一个 Agent 成为“场地 Agent”或“菜单 Agent”的，是三样东西：写给它的角色说明，交给它的工具和权限，以及它工作台上的材料。背后的模型可以相同，也可以不同：同一个模型换一份角色说明和一套工具，就成了另一个 Agent；Anthropic 的研究系统则让主 Agent 用更强的 Claude Opus 4，子 Agent 用更快、更便宜的 Claude Sonnet 4。那个专门找场地的 Agent，并不比别人更懂场地，只是它的台面上只有场地这一件事。

#03子 Agent 只知道派活单上写的事

空白的工作台是多 Agent 的好处：子 Agent 不会被别人的材料干扰，主 Agent 也不会被三十个网页淹没。可派活单上没写的东西，子 Agent 就无从知道。

这样看，每个子 Agent 都像第一天上班的新同事：能力不差，但除了手里那张派活单，对背景一无所知。 多 Agent 协作的大部分麻烦，都出在这里。

一种是派活单写得太含糊。Anthropic 遇到过，主 Agent 只写了一句“调研半导体短缺”，结果一个子 Agent 去查 2021 年的汽车芯片危机，另外两个重复调查了 2025 年的供应链。他们后来总结，派活单要写清四件事：目标、交付格式、该用的工具和信息来源、任务边界。放到年会里，“去找个场地”就得写成“找 3 个浦东、能坐 200 人、1 月 10 日晚上可订、人均 300 元以内的场地，列出价格和交通，先不要联系商家”。

另一种更隐蔽：没写下来的决定会互相打架。AI 编程公司 Cognition 举过一个例子，让两个子 Agent 分头做 Flappy Bird 小游戏，一个做背景，一个做小鸟。结果背景做成了超级马里奥的风格，小鸟也根本不像 Flappy Bird。就算任务交代得很完整，两个 Agent 看不到对方在做什么，画风、颜色、比例，还是各选各的。年会也一样，管场地的 Agent 订了中式宴会厅，写邀请函的 Agent 却按鸡尾酒会的调子来写。

这类问题并不少见。UC Berkeley 等机构的研究者分析过 7 个常见多 Agent 框架的 1600 多条运行记录，结论不太乐观：尽管大家热情很高，多 Agent 在常见测试上的提升往往很小。Cognition 那篇文章的标题干脆就叫《别做多 Agent》（Don't Build Multi-Agents），建议任务环环相扣时，宁可让一个 Agent 按顺序做完。更常见的折中，是让子 Agent 只负责查和读，风格、日期、预算这些决定，都留给主 Agent 来拍板。

#04几种协作方式，差别在谁来决定下一步

只靠派活单和汇报，能传的信息很少，所以实际系统里还有别的协作方式。Anthropic 在 Claude Code 的文档里比较过几种做法，用的是两个问题：谁来决定下一步做什么，中间结果放在哪。按这两个问题看，常见的有四种。

主 Agent 派活（Orchestrator-Worker）就是上面讲的方式。下一步做什么，由主 Agent 看完汇报再定，中间结果都回到它的工作台上。Anthropic 的研究功能是这样，dots 把代码任务交给 Codex 也是这样。

转交（Handoff）是把整段对话交给更合适的 Agent，由它接着和你说话。像打客服电话，前台问清是账单问题，就把你转给账单专员，专员能看到前面聊过什么。OpenAI 的 Agents SDK 默认就是这样设计的。

团队（Agent Team）的做法，是给大家一块都能看的白板：下一步由队员自己认领，中间结果写在共享的地方。Anthropic 研究员 Nicholas Carlini 今年 2 月做过一个实验，让 16 个 Agent 合写一个 C 编译器，没有设主管。所有 Agent 共用一个代码仓库，谁要做哪项任务，就在共享目录里写一个以任务命名的文件，把它“锁”住；每个 Agent 还要随时更新说明文档和进度记录，方便后来的 Agent 接手。Claude Code 的 Agent Teams 在白板之外还加了信箱：队员共享一张任务清单，每人有一个收件箱，彼此可以直接发消息，不用事事经过队长。Cue 把几个 Agent 拉进群聊，也是这个思路。

写好的流程（Workflow）则是把步骤提前定下来，下一步做什么由程序决定，不用哪个 Agent 临场判断。比如先查、再写、再审；一次派出几十个 Agent 并行干活；或者反复修改，直到测试通过才停。这类流程以前多是工程师手写的。Claude Code 的动态工作流（Dynamic Workflows）改成让 Claude 自己写：你描述任务，Claude 先把步骤写成一段脚本，再由脚本去调度，一次能用上几十到几百个 Agent。每一步的中间结果都存在脚本里，Claude 的工作台上只留最后的答案。

#05多 Agent 最适合的五类事

调研和比较

比较 20 款产品，列出 100 家做 AI Agent 的公司，梳理一个行业的上下游，这类任务最适合多 Agent：每份材料可以分头看，最后只需要一个 Agent 汇总。Anthropic 的研究功能就是例子。价值不只是快，还有覆盖面，以前只能抽样看的东西，现在可以一家不落地看全。

一个 Agent 做不完的工程

Carlini 的 16 个 Agent 用了两周、近 2000 次会话、将近 2 万美元，从零写出一个 10 万行的 C 编译器，能编译出可以启动的 Linux 内核。能并行，是因为测试里有成百上千个互不相干的用例，每个 Agent 各修一个。到了编译内核这一步，所有 Agent 撞上同一个 bug、互相覆盖修改，16 个 Agent 就和 1 个没区别。直到他用成熟的编译器 GCC 编译大部分文件，只留一小部分给 Claude 的编译器，才把一个大问题重新拆成了许多小问题。Carlini 说，他的大部分精力都花在了测试和反馈上，人的工作从写代码变成了定标准、做验收。

审查和挑错

Anthropic 今年 3 月分享过一次长时间自动写代码的实验，发现了一个很像人的毛病：让 Agent 评价自己做出来的东西，它往往会很自信地夸奖，哪怕在人看来质量明显一般。有效的解法是把干活的 Agent 和打分的 Agent 分开。评审 Agent 仍然偏宽容，但把一个独立的评审调教得挑剔一些，比让干活的 Agent 对自己严格要容易得多。他们最后用了三个 Agent，一个做规划，一个写代码，一个评审。

空白的工作台在这里成了优点：评审的 Agent 没参与写作，手里只有结果和标准。合同、方案和代码，都可以这样一个写、一个审。另一种做法是同一件事让几个 Agent 各做一遍，再交叉核对。Claude Code 自带的深度研究功能，就会让不同的 Agent 核对彼此找到的来源，对每条结论投票，站不住的结论直接筛掉。

分开管理权限和记忆

既然 Agent 的差别在角色、权限和工作台，个人 Agent 拆成几个，权限和记忆就能分开放。Cue 里的 Agent 可以分管工作、邮件和日常，各有自己的邮箱、电脑、电话和记忆；每个 Agent 的钱包，也只能在你设定的预算内付款。管邮件的 Agent 不需要碰你的钱，帮你排队点餐的 Agent 也不需要读工作邮件，哪个 Agent 出了错或者被误导，影响只限于它手里那一摊。这和家里请人帮忙是一个道理：帮你收快递的人，不需要知道你的银行卡密码。

和别人的 Agent 打交道

当每个人的 Agent 都有了手机号和邮箱，电话那头也可能是别人的 Agent：你的 Agent 帮你改签机票，对面是航空公司的 Agent。两边分属不同的公司，数据和权限不能互相开放，既看不到对方的工作台，也没有共用的白板，只能按约定的格式对话。Google 在 2025 年 4 月牵头推出的 A2A 协议（Agent2Agent）就是这样一套格式：每个 Agent 用一张“名片”（Agent Card）说明自己能做什么，对方据此发任务、跟进度、收结果。如果说 MCP 协议管的是 Agent 怎样连上工具，A2A 管的就是 Agent 怎样和另一个 Agent 说话。

它们之间需要的不只是分工，还有谈判和信任：对方是谁，能不能代表主人做决定，谈好的条件算不算数。两边也不可能合并成一个 Agent，因为利益本来就属于不同的人，A2A 也把身份认证列为基本设计原则之一。这一类大多还是设想，影响却可能最大。

#06拆不开的事，还是交给一个 Agent

Agent 接手的活越多，人的工作就越集中在三件事上：定方向，把派活单写清楚，最后验收结果。

这和带好一个团队，是同一门手艺。