Tools / Agent Stack
一个不够,就分工
你说一个 AI agent 已经挺能干了,干嘛还要好几个凑一块儿?——多智能体协作,说白了就是给 AI 分工编队:把一个大活儿拆开,交给几个各管一摊、各带趁手工具的专精 agent,再按一套队形把它们的活儿拼起来。为啥这么干?专精(少而专的工具胜过一身五十样)、并行(同时开干省时间)、互查(一个写一个挑错)。自动化工作流里,它能跑深度调研、客服、内容生产、数据流水线这些"一个脑子忙不过来"的活。但记住一条:它有实打实的代价,不是越多越好。
从"为啥要多个"走到"怎么用、用不用"
咱们先看单个 agent 卡在哪,你就懂为啥要分工;然后说清"协作"到底是什么;橙色那站是四种协作队形,记住它你就能看懂市面上大部分多智能体系统;再落到自动化工作流的具体应用;最后泼盆冷水——它有代价,讲清什么时候别用。
先看单个 agent 卡在哪
要懂为啥要"多个",得先看一个 agent 干大活时会撞上什么墙。一个先把概念对齐一下:这里说的 agent,是能自己拆任务、调工具、看结果、再调整的 AI 执行体,不是只会答一句话的聊天框。
它能干,但有三堵墙。第一堵,工具一多就晕:你给一个 agent 塞 50 个工具、什么都让它干,它反而挑花眼、容易选错;给它 5 个聚焦的工具,它干得又快又准2。第二堵,只能一件一件来:要它读 20 份文档,它只能一份一份串着读,慢1。第三堵,自己检查自己,查不出错:让它写完再自己审,它往往看不出自己的毛病——人也一样,自己的文章总觉得没问题2。
你看,这三堵墙——专精不够、不能并行、自查不灵——正好就是多智能体要解决的三件事。多智能体不是为了炫技,是给这三堵墙各开一扇门。
这三堵墙,你觉得哪一堵单靠"把模型换得更强"就能推倒?先想一下再点开。
试着先答
都不能完全靠"换更强的模型"解决——尤其是后两堵。"只能串着来"是结构问题:再聪明的脑子,一个人读 20 份文档也得一份份来,要快就得多开几个并行。"自查不灵"是立场问题:再强的模型,当裁判审自己写的东西,也天然有盲区,得换个独立的 agent 来挑。这两件,换大模型省不掉,得靠"多个 + 分工"。所以多智能体不是模型不够强的临时补丁,是另一个维度的解法。
记住这一句:单个 agent 有三堵墙——工具多了就晕、只能串着干、自查查不出错。多智能体不是炫技,是给这三堵墙各开一扇门:专精、并行、互查。
"协作"到底是什么:分工 + 编队
那"多智能体协作"具体指啥?——别想复杂了,就两件事:分工和编队。
分工:把一个大任务拆成几块,每块配一个专精 agent——它有明确的职责、一套趁手的少量工具、和为这件事写的提示词。就像一个团队里有人管查资料、有人管写稿、有人管校对,各干各擅长的4。
编队:光有几个 agent 还不算协作,得有一套规矩管它们怎么传话、谁先谁后、结果怎么拼——这套规矩叫"编排"(orchestration)3。是一个总管派活、还是排成流水线一棒接一棒、还是同时撒出去再汇总——不同的编队方式,就是下一节的四种队形。
"多智能体不就是把一个 prompt 拆成好几次调用嘛?"——你以为是把一次对话切几段,其实差着一层。关键区别在每个 agent 有独立的角色、独立的工具、独立的上下文,它们像不同的同事,各自带着自己那摊东西干活、再交接;而不是同一个脑子换着话题问几遍。没有"独立分工"这层,那只是多轮对话,不是多智能体协作。
记住这一句:多智能体协作=分工(每个 agent 有独立角色/工具/上下文)+ 编队(一套编排规矩管它们怎么传话、排序、合并)。少了"独立分工"这层,就只是多轮对话。
四种协作队形:看懂这个就够用
这一节是核心。市面上花样再多,绝大多数多智能体系统都是这四种队形(或它们的组合)15。记住这四个,你就能看懂几乎任何一套多智能体设计。
| 队形 | 怎么排 | 最适合 |
|---|---|---|
| 编排-工人(总管制) | 一个总管 agent 拆任务、派给若干工人 agent、收回结果再汇总 | 任务能拆成清楚的子任务、要灵活调度 |
| 流水线(接力制) | 排成一条线,每个 agent 加工一道、交给下一个 | 有固定先后步骤(如 抽取→清洗→生成) |
| 并行扇出(分头制) | 同时撒出多个 agent 各干一摊,最后汇总 | 子任务互相独立、想省时间 |
| 辩论/评审(互查制) | 一个产出、另一个独立挑错,甚至来回辩 | 对质量、正确性要求高 |
把它们画出来,关系一目了然——核心差别就是"谁指挥、活儿怎么流":
给三个场景各选一种最合适的队形:
· A. 把一篇长录音转成"逐字稿→摘要→生成标题"三步固定流程 → ?
· B. 同时去 5 个网站抓同一个产品的报价,最后比价 → ?
· C. AI 写一段合同条款,必须有人独立审有没有坑 → ?
对答案
A=流水线(固定先后、一棒接一棒);B=并行扇出(5 个网站互相独立,同时抓最省时间,再汇总比价);C=互查制(一个写、一个独立挑错,正确性要求高)。选队形的诀窍:看任务是"有固定步骤"(流水线)、"能拆开同时干"(并行)、"要灵活调度"(总管),还是"要把关质量"(互查)。
记住这一句:四种队形——总管制(派活汇总)、流水线(串行接力)、并行扇出(分头再合)、互查制(产出+挑错)。看任务是"灵活调度/固定步骤/能并行/要把关",就知道该用哪种。
自动化工作流里,它用在哪
知道了队形,套到真实工作流就顺了。下面几个是已经在跑、也最能体现多智能体价值的场景——共同点都是"一个脑子忙不过来、或者忙不安全"。
| 工作流 | 怎么编队 | 占了哪个好处 |
|---|---|---|
| 深度调研报告 | 总管拆题 → 多个 agent 并行查不同信源 → 汇总 → 另一个 agent 审稿 | 并行 + 互查 |
| 客服 / 工单 | 一个 agent 查知识库、一个查订单系统、一个拟回复,同时跑 | 专精 + 并行3 |
| 内容生产线 | 选题 → 写初稿 → 配图提示 → 校对润色,排成流水线 | 流水线 + 专精 |
| 数据流水线 | 抽取 → 清洗 → 转换 → 入库,每步一个 agent | 流水线 |
| 写代码(就像 Claude Code) | 主 agent 规划,子 agent 并行查代码 / 跑测试 / 审 diff | 专精 + 并行 + 互查 |
就拿你最熟的"深度调研"说:你要一份"竞品全景报告"。单 agent 干法是它一个一个网站翻,翻到第十个早忘了第一个说啥。多智能体干法:总管把题拆成"价格/功能/口碑/团队"四块,撒四个 agent 同时去查(并行,省四倍时间),各自回来一段,总管拼成初稿,再派一个"挑刺 agent"专门找哪儿没引用来源、哪儿自相矛盾(互查)。你看,并行省了时间、互查保了质量,这正是单 agent 给不了的——这也就是前面那篇里 Claude Code 用子 agent 跑搜索的同一个道理。
记住这一句:多智能体最对路的工作流,都是"一个脑子忙不过来"的——深度调研、客服、内容线、数据流水线、写代码;看它占了专精/并行/互查里的哪几样,就知道该排什么队形。
泼盆冷水:它有实打实的代价
讲了一堆好处,得拦你一下:多智能体不是默认更优,它有实打实的代价,很多任务根本不该用。
代价主要两笔。第一笔,协调开销:agent 之间传话、等结果、合并,本身要花功夫,业界估算光协调就多出四到五成的额外开销1。第二笔才是真要命——烧 token:你想啊,多个 agent 各自带一份上下文、还来回交流,token 消耗可能是单 agent 的十几倍1。还有看不见的第三笔:链条一长,调试和排错都更难——一个环节出错,整条链的结果都歪,你还得一个个 agent 查是谁的锅。
有人会说:"既然多智能体专精、并行、还能互查,那我以后所有自动化都拆成多智能体,不是更高级吗?"——这想法很自然,但方向反了。代价摆在那:多智能体≈多花四五成协调 + 十几倍 token1。本讲稿的立场是:只有当"专精/并行/互查"带来的好处,明显压过这些代价时,才值得上多智能体。一个简单的、一步到位的任务,硬拆成五个 agent,你换来的是更慢、更贵、更难修。判断口诀很简单:能一个 agent 干好的,就别编队。
记住这一句:多智能体的代价是真金白银——多花约四五成协调、十几倍 token、还更难调试。能一个 agent 干好的就别拆;只有专精/并行/互查的收益明显压过代价,才编队。
给 AI 分工编队,但只在值得时
正面收个口。多智能体协作,一句话就是给 AI 分工编队:把一个大活拆开,交给几个各管一摊、各带少量趁手工具的专精 agent,再用一套编排规矩(谁指挥、活儿怎么流、结果怎么合)把它们串成一个系统。它治的是单个 agent 的三堵墙——工具多了就晕、只能串着干、自查查不出错——对应给出三味解药:专精、并行、互查。你别看队形花样多,落到底就四种,记住就够看懂大半江湖:总管制(派活汇总)、流水线(串行接力)、并行扇出(分头再合)、互查制(产出加挑错)。自动化工作流里,凡是"一个脑子忙不过来"的活——深度调研、客服工单、内容生产线、数据流水线、写代码——都是它的主场,看任务占了专精/并行/互查的哪几样,就对应排哪种队。但什么时候别用?——它有实打实的代价:多花约四五成协调、十几倍 token、还更难调试排错。所以判断口诀就一句:能一个 agent 干好的,就别编队;只有当专精、并行或互查的收益明显压过这笔代价时,多智能体才划算。你要是正构思一个自动化流程,先别急着拆 agent——先问"这活儿真的一个脑子忙不过来吗?"答案是肯定的,再谈编队。
这些地方我说实话也没全把握
- "四五成协调开销、十几倍 token"这组数字是业界估算,不是精确常数。它随任务、模型、实现差很多,你听个量级、记住"代价显著"就行,别拿去当精确预算。
- "四种队形"是为了好懂的归纳,现实里经常混用、嵌套。一个真实系统常常是"总管下面挂一条流水线、某步再并行扇出"的组合。我拆成四种是给你一副认知地图,不是说它们互相排斥。
- 多智能体 vs 单 agent 谁更好,业界还在吵、也在快速变。有人主张"能单别多",也有人押注多智能体是未来主流架构。我倾向"按收益-代价判断",但这是个还在演化的领域,半年后最佳实践可能又变了。
读完盖住,试着答这几题
用一句话说清"多智能体协作"是什么,它由哪两件事组成?
试着先答
给 AI 分工编队。两件事:分工(每个 agent 有独立角色、独立工具、独立上下文)+ 编队(一套编排规矩管它们怎么传话、排序、合并)。
单个 agent 的三堵墙是什么?多智能体对应的三味解药呢?
试着先答
三堵墙:工具多了就晕、只能串着一件件干、自查查不出错。三味解药:专精(少而专的工具)、并行(同时开干)、互查(一个产出一个独立挑错)。
四种协作队形分别是什么?各自最适合哪类任务?
试着先答
总管制(任务能拆、要灵活调度)、流水线(有固定先后步骤)、并行扇出(子任务独立、想省时间)、互查制(对质量/正确性要求高)。
什么时候不该用多智能体?判断口诀是什么?
试着先答
它有代价:多花约四五成协调、十几倍 token、更难调试。口诀:能一个 agent 干好的就别编队;只有专精/并行/互查的收益明显压过代价时才用。
应用题:"把一段会议录音转成逐字稿,再生成会议纪要,再翻译成英文",这条流程该用哪种队形?为什么?
试着先答
流水线(接力制)。因为三步有严格的固定先后(必须先有逐字稿才能写纪要、有纪要才能翻译),每个 agent 加工一道交给下一个,正是流水线的典型形状。不适合并行(后一步依赖前一步),也不必上总管(步骤固定不用灵活调度)。
把这几题截图,过两三天再凭记忆答一遍 —— 记得住才算真学会。
Sources
- Multi-Agent Patterns: Orchestrators, Workers, and Pipelines(三大队形、并行优势、协调开销与 ~15× token 代价) — https://aiagentsblog.com/blog/multi-agent-patterns/
- Anthropic — Building a multi-agent research system(专精胜过 50 工具、并行子 agent、互查/独立 critique) — https://www.anthropic.com/engineering/multi-agent-research-system
- AI Agent Orchestration Patterns(Azure Architecture Center:编排=协调多 agent 的协议,客服等并行编队) — https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
- Multi-Agent Orchestration: How to Build Agent Teams That Actually Work(专精 agent = 角色+少量工具+提示词、分工与编队) — https://www.mindstudio.ai/blog/multi-agent-orchestration-patterns
- The Orchestration of Multi-Agent Systems: Architectures, Protocols, and Enterprise Adoption(arXiv 综述:架构、协议与企业落地) — https://arxiv.org/html/2601.13671v1