「AI Agent」什么是 Multi-Agent：两大驱动因素与三种协作模式

0 前言

本文内容整理自公众号「小林面试笔记」的文章 10. 什么是 Multi-Agent？，用于记录与总结 AI Agent 相关的核心面试知识点。

「什么是 Multi-Agent？为什么需要它？」，可以这样作答：

Multi-Agent 就是多个 Agent 协作完成任务，每个 Agent 有明确分工——有的负责搜索、有的负责写代码、有的负责评审，核心思路是「团队作战代替单打独斗」。

为什么需要它，有两个结构性驱动因素。一是 context window 的硬上限：单个 Agent 的工作台容量有限，任务越复杂、信息量越大，早期内容就会被「挤落」，Agent 开始遗忘；二是单点专业度不足：让一个 Agent 既搜信息、又写代码、又做测试，它在每件事上都只是「泛才」，而且某个环节出错会拖垮整条链路，没有隔离性。

Multi-Agent 的协作方式主要有三种：顺序流水线（A 做完交给 B，依次流转）、并行扇出（调度者把独立子任务同时分发给多个 Worker，最后汇总）、辩论/评审（多个 Agent 各自给方案，由裁判或互相评审选出最优解）。

分工之后每个 Agent 的 context 只装自己那块信息，工作台干净、专业度更高；可并行的子任务还能同时执行，整体速度有实质提升。这是我在实际项目中优先考虑 Multi-Agent 方案的核心原因。

生产级例子：Cursor 和 Claude Code 已经把「多 Agent 协作」做成了日常。Claude Code 用 subagents 实现分工——既有专门做代码定位的 Explore 代理、干重活的 generalPurpose 代理，也有负责深度排查的 Bugbot、Security Review 这类「评审角色」子代理，主代理可以把多个相互独立的子任务并行分派出去，各自在隔离的 context 里完成后再汇总，这正是「并行扇出 + 专业分工」的生产级落地。Cursor 的 Background Agents / Cloud Agents 同样如此：多个代理可以同时在各自独立的工作区（甚至独立 git 分支）里并行处理不同任务，主对话再统一整合结果，多角色并行协作已经是一线开发者的日常操作。

1 为什么需要 Multi-Agent：单个 Agent 的两个硬限制

很多人把 Multi-Agent 理解为「多个 AI 一起干活，效率更高」，这个说法太笼统。真正驱动 Multi-Agent 的，是单个 Agent 两个绕不开的结构性限制。

1.1 硬限制一：context window 有上限，复杂任务会「遗忘」

想象你让一个 Agent 完成「写一份完整的 AI 行业竞品分析报告」。它需要搜索十几家竞品、读懂每家的产品功能、梳理核心差异、整理对比数据、最后写结论。

光是搜索阶段，每家竞品几百字，十家就是几千字的搜索结果；再加上来回确认的对话历史、模型自己的中间推理——还没开始写结论，整个「工作台」就已经快撑满了。

这里说的「工作台」，就是 LLM 的 context window。LLM 处理任务时，把它当前能看到的所有内容——指令、推理过程、工具返回结果、历史对话——全部摆在桌面上一起处理。这张桌子是有容量上限的，常见模型从 12.8 万到 100 万 token 不等。塞满之后，早期的内容就会开始「掉落」：就像一张桌子放满了东西，新东西要放进来，旧东西就得被推到地上。

于是，你三十分钟前确认的方案、第一批搜集的资料，就这么悄悄消失了——Agent 开始「遗忘」。这是结构性的限制，不是靠提示词优化就能绕过去的。

单个 Agent 超载：工作台被塞满

1.2 硬限制二：单点能力有限，什么都做等于什么都不精

context 有上限是第一层硬限制，更深的其实是「专业度」问题。

让一个 Agent 既搜信息、又写代码、又做测试、又写文档，它在每件事上都得兼顾，精力被分散——就像一个人同时担任产品经理、程序员、测试工程师和文档工程师，每个角色都做得不够专注，互相干扰。

更麻烦的是没有隔离性：一旦某个环节出问题，整条链路就卡住了，而且因为所有信息都混在一个 context 里，排查起来特别痛苦——你不知道问题到底出在搜索阶段、分析阶段还是写作阶段。

Multi-Agent 的核心思路，就是把任务按职能拆开，让每个 Agent 只负责一件事、专心做好自己那块，做完把结果传给下一个。就像公司里部门协作：产品经理负责需求梳理、开发负责写代码、测试负责验收，每个人专注自己的职责，信息传递清晰，哪个环节出了问题也好定位责任。

2 三种协作模式

Multi-Agent 之间的协作方式，主要有三种模式。

2.1 顺序流水线（Sequential Pipeline）

Agent A 做完把结果交给 Agent B，B 做完交给 Agent C——就像工厂流水线一样，每个环节依次处理。

适合依赖关系明确的场景：前一步的输出是后一步的输入，天然只能串行。优点是流程清晰、好追踪；缺点是整体耗时是所有步骤之和，无法并行。

2.2 并行扇出（Fan-out）

一个调度者（Orchestrator）把多个相互独立的子任务同时分发给不同的 Worker Agent，它们各自并行执行，最后由调度者收集汇总。

这是 Multi-Agent 在效率上的核心优势：能并行的子任务不需要等前一个完成，整体耗时从「串行之和」变成「最长路径」。前提是子任务之间没有依赖关系——这正是上一篇文章《任务拆分》里「依赖分析 + DAG 并行执行」的延续。

2.3 辩论/评审（Debate/Review）

多个 Agent 对同一个问题各自给出方案，然后由一个裁判 Agent 或者它们互相评审，筛选出最优解。

这种模式在需要高质量决策的场景特别有用，比如代码评审、方案选型。它用「多视角对抗」换来输出的可靠性——多个独立意见互相校验，比单个 Agent 自说自话更不容易出错。

三种协作模式

3 案例：开发一个爬虫工具

光讲概念不够直观，用一个「开发爬虫工具」的例子感受两种做法的差距。

3.1 单 Agent 的做法：思路乱成一锅粥

一个 Agent 接到「开发爬虫工具」的任务，同时要想需求文档、代码结构、测试策略。context 里塞满了各种信息，思路乱成一锅粥，写出来的东西哪块都不够好；更致命的是，任何一步失误都可能要从头来——比如写到一半发现需求理解错了，前面的代码全废。

3.2 Multi-Agent 的做法：流水线分工

把任务按职能拆给不同的 Agent：

需求分析师 Agent：只做一件事——把用户需求转化成清晰的功能列表，输出之后就完成使命退出了，它的工作台是干净的；
程序员 Agent：拿到功能列表，专注写代码，不需要知道需求是怎么来的，context 里只有代码相关的信息；
测试工程师 Agent：拿到代码，专注写测试用例。

每个 Agent 的工作台都很干净，只装自己这块任务相关的内容，专业度也更高。

分工之后每个 Agent 的工作台都保持干净

3.3 并行扇出的双重收益

更关键的是，需求分析结束之后，程序员 Agent 和测试工程师 Agent 其实可以并行工作——测试框架的搭建不需要等代码写完。调度者识别出哪些子任务之间没有依赖关系，就把它们同时派出去，等所有结果回来再统一整合。

并行带来的不只是速度提升，还有一个隐藏的好处：每个 Worker 的 context 是完全隔离的。程序员 Agent 不会被测试用例的信息干扰，测试 Agent 也不会被代码实现细节淹没，各自在干净的环境里专注工作，输出质量也更高。

4 生产级框架选型

聊完了原理，实际项目中怎么落地？目前业界已经有不少成熟的 Multi-Agent 框架可以直接用。

CrewAI：偏上层、易上手，把「Agent 角色 + 任务 + 流程」的编排封装得很好，适合快速搭建多角色协作系统。

LangGraph：更底层、更灵活，提供有状态、可编排的图结构，适合需要精细控制流程、自定义节点逻辑的复杂场景。

值得一提的变化是：微软在 2025 年推出了 Microsoft Agent Framework（MAF），把微软两条并行的产品线——Semantic Kernel（企业级）和 AutoGen（多 Agent 编排）——合并成一个面向生产的统一 SDK。原 AutoGen 仓库继续以研究/原型项目身份迭代，社区也 fork 出了 AG2 保持向后兼容。

选型建议：微软技术栈的生产场景优先考虑 MAF；其他场景 CrewAI（上层易用）或 LangGraph（底层灵活）都是持续维护的主流选择。

Multi-Agent 框架矩阵

5 组织方式：中心化 vs 去中心化

Multi-Agent 系统的组织方式主要有两种。

中心化：由一个统一的调度者（Orchestrator）分配任务、收集结果。调度逻辑清晰、责任归属明确、排查问题容易，工程上用得更多。

去中心化：Agent 之间自行协商、直接通信。灵活性更高，但协调成本大、行为不可控，排查问题也难，实际项目里用得较少。

简单类比：中心化像一个有项目经理的项目组，所有任务派发和结果汇总都过项目经理；去中心化像自由职业者互相直接对接，协作灵活但出了问题找不到负责人。

中心化 vs 去中心化

6 生产级实例：Cursor 与 Claude Code 的多 Agent 协作

Multi-Agent 不是论文里的概念，而是当下生产级 Agent 产品都在用的基础能力。用 Cursor 和 Claude Code 来对照前面讲的每个点。

专业分工：Claude Code 内置了多种专用 subagents——Explore（快速定位代码）、generalPurpose（处理复杂多步任务）、shell（命令执行专家）等，主代理根据任务类型选择最合适的「专家」委派出去，就是「按职能分工」。

并行扇出：在 Cursor 中，多个 Background Agents / Cloud Agents 可以同时运行——比如一个代理负责重构后端、另一个代理同步更新文档、第三个代理跑测试，各自在隔离的工作区（Cloud Agents 甚至在自己的独立 git 分支）里互不干扰地并行推进，最后由主对话统一整合。

评审模式（Debate/Review）：Claude Code 的 Bugbot 和 Security Review 子代理就是典型的「评审 Agent」——代码改动完成后，主代理把改动丢给专门的评审代理做深度排查，多一重视角校验输出质量。

这些产品把 Multi-Agent 的核心价值——分工、并行、隔离、评审——全部工程化，也印证了前面讲的每个概念都来自真实需求。

7 要点回顾

回答「什么是 Multi-Agent」这道题，要答出三个层次才完整：

层次	要点
为什么需要	context window 有硬上限，复杂任务会「遗忘」；单点能力有限，什么都做等于什么都不精，且没有隔离性
三种协作模式	顺序流水线（依次流转）、并行扇出（独立子任务同时分发、结果汇总）、辩论/评审（多方案互评选优）
组织与选型	中心化（调度者统一分配，工程上更常用）vs 去中心化（自行协商）；框架选 CrewAI / LangGraph / 微软 MAF