「AI Agent」Single-Agent 与 Multi-Agent 怎么选：选型标准与中心化编排
0 前言
本文内容整理自公众号「小林面试笔记」的文章 11. 说说 Single-Agent 和 Multi-Agent 的设计方案？，用于记录与总结 AI Agent 相关的核心面试知识点。
「什么时候用 Single-Agent，什么时候上 Multi-Agent？Multi-Agent 又该怎么组织？」，可以这样作答：
选型不能凭「复杂」这种模糊感觉，要看三个具体信号：context 撑爆了、需要不同专业分工、有独立子任务可以并行——出现这三类情况，Single-Agent 才真正力不从心，Multi-Agent 才有价值；否则 Single-Agent 就够了，盲目引入 Multi-Agent 只会增加复杂度、带来不了对应收益。
Multi-Agent 架构上主要有两种拓扑：中心化的 Orchestrator 模式，由一个主 Agent（总调度员）读懂大目标、拆成子任务、分派给各 Worker、最后汇总拼装；去中心化的 Peer-to-Peer 模式，Agent 之间通过共享消息队列直接通信、自行协商。工程实践里几乎都用中心化，因为它可控、可追踪、出了问题能顺着调度链路精准定位；去中心化虽然听起来灵活，但任务分配没协调、执行顺序没保证、失败没感知，生产环境几乎不可用。
实际选型可以套用两个问题：你的任务 Single-Agent 能搞定吗？ 流程明确、不太长、不需要专业分工，就选 Single-Agent；你能接受系统行为不可控的风险吗？ 生产环境几乎不能，所以就用 Orchestrator 模式。更稳妥的工程策略是渐进式演进：先用 Single-Agent 跑通，发现某个环节成了瓶颈（context 频繁撑满、某类子任务质量差），再把那个环节拆出来交给专门的 Worker Agent，而不是一上来就设计五六个 Agent 的系统。
生产级例子：Cursor 和 Claude Code 已经把「中心化编排」做成了日常。Cursor 的 Background Agents / Cloud Agents 由主对话统一派发、在各自独立的工作区（Cloud Agents 甚至在自己独立的 git 分支）里并行执行，最后由主对话整合结果，这正是「Orchestrator 分派 Worker、并行扇出」的生产级落地。Claude Code 的 subagents 体系同样如此——主代理根据任务类型委派 Explore（代码定位）、generalPurpose（复杂多步任务）、shell（命令执行）等专用子代理，需要质量把关时再把改动丢给 Bugbot、Security Review 这类「评审角色」，子代理在隔离的 context 里干完活交回结果，主代理始终掌握全局调度。
1 Single-Agent：单人作战，链路完全可控
Single-Agent 的本质是一个 LLM 加上一套工具，跑一个决策循环：LLM 判断下一步该做什么 → 调用工具执行 → 拿到结果再判断 → 直到任务完成。
它最大的优势不只是「架构简单」，更核心的是整条任务链路完全在你掌控之内：任务怎么走、用什么工具、什么时候结束，所有逻辑都在一个地方写清楚，出了问题链路短、好排查。类比一下，一个人完全可以独立完成「写一篇博客」——查资料、列大纲、写下来，不需要团队协作，单人反而更高效，沟通成本为零。
2 什么时候 Single-Agent 不够用：三类真实信号
Single-Agent 开始力不从心，是在遇到下面这三类任务的时候：
1. 任务太长、信息量太大，context 撑爆。 任务越长，早期内容越容易被挤出 context window，Agent 开始「遗忘」，输出质量崩塌。
2. 不同步骤需要完全不同的专业能力。 什么都塞进一个 Agent，它每件事都做得不够专注——泛才不如专才，且一个环节出错会拖垮整条链路，信息全混在一个 context 里，连问题出在哪一步都难定位。
3. 任务中有多个相互独立的子任务。 理论上可以并行，但单 Agent 只能一个个来，耗时是全部步骤之和。
遇到这三类情况，Multi-Agent 就有了真实价值。但要强调：如果你的任务不属于这三类，Single-Agent 就够了，不要为了「用新技术」而强行引入 Multi-Agent——系统变复杂、难维护，却没有带来对应的收益。
3 中心化方案：Orchestrator 总调度
Multi-Agent 的中心化方案，核心是一个叫 Orchestrator 的特殊角色。直译是「交响乐指挥」，在 Multi-Agent 系统里可以理解成「总调度员」或「项目经理」。
它是整个系统里最特殊的 Agent——不做任何具体工作，只负责三件事：
- 读懂用户的大目标，把它拆成一个个子任务；
- 判断每个子任务该交给哪个 Worker Agent；
- 收集每个 Worker 的产出，拼装成最终答案。
3.1 Orchestrator 的三种变体
Orchestrator 不是铁板一块，按复杂度和能力可以分成三档，适合不同场景。
| 变体 | 机制 | 适用 |
|---|---|---|
| 静态路由（Static Router） | 任务拆分和分配规则预先写死，比如「代码任务交给 Coder，搜索任务交给 Researcher」 | 流程固定、逻辑简单可预测的场景 |
| 动态规划（Dynamic Planner） | Orchestrator 本身是 LLM，根据用户输入动态生成任务计划，决定几步、每步交给谁，计划可执行中调整 | 大多数项目场景，够用且好调 |
| 自适应编排（Adaptive Orchestration） | 在动态规划基础上，还根据 Worker 的执行结果实时调整后续计划，比如搜索信息不够就追加一轮搜索 | 任务变化大、对结果要求高的场景；调试复杂度也高很多 |
实际项目里，大多数场景用动态规划就够了；自适应编排虽然更强大，但调试复杂度也高很多，除非必要不必上。
3.2 Worker Agent：职责单一的「执行者」
与 Orchestrator 相对，Worker Agent 就是「执行者」。每个 Worker 只关注自己那块：不需要知道整体任务是什么，不需要知道其他 Worker 在做什么，只需要拿到属于自己的指令，做完返回结果，然后退出。
它的 context 是干净的，只装和自己职责相关的信息——这正是 Multi-Agent 相对 Single-Agent 的核心收益之一：工作台不堆杂物，专注度和质量都更高。
3.3 案例：AI 行业竞品分析
用「帮我写一份 AI 行业竞品分析」走一遍完整流程：Orchestrator 把任务拆成「搜索竞品信息 → 对比分析 → 撰写报告」，分别派给 Researcher、Analyst、Writer 三个 Worker，各自完成后回收产出、拼成最终报告。
这个流程最大的好处是每个环节出了问题都能精准定位：报告内容不准确？可能是 Researcher 搜的信息不够好；分析逻辑有问题？可能是 Analyst 的对比维度不对；格式不符合要求？是 Writer 的输出问题。职责清晰，排查不需要猜，顺着 Orchestrator 的调度记录一步步追下去就能找到根源。
4 去中心化方案：为什么工程上几乎不用
去中心化的思路是没有总调度：多个 Agent 通过共享的消息队列或状态空间自行协商、直接通信。听起来像一个能自我组织的团队——不需要领导，大家自动配合，还更灵活。但实际工程里，灵活只是表面。
用一个具体场景说明。假设三个 Agent 处理同一个任务：Agent A 在搜索信息，Agent B 也在搜索类似信息，Agent C 负责汇总，但没有人统筹调度。问题会同时冒出来：
- 没有协调：没人告诉 A 和 B「你们各搜什么范围」，很可能大量内容搜重了，做重复工作；
- 没有顺序保证：C 需要等 A 和 B 都搜完才能汇总，但没人告诉 C「A 和 B 什么时候算搜完了」，C 不知道等多久，也不知道有没有漏掉结果；
- 失败无感知：如果 A 中途出错，没有中央调度者收到错误通知，B 和 C 还在正常运行，最后汇总出一份不完整的结果，而系统甚至不知道这里出了问题；
- 无人确认完成：没有人来确认「任务整体完成了没有」。
总结下来，去中心化系统里四类问题会频繁出现：任务分配没有协调、执行顺序没有保证、失败没有感知、无人确认整体完成。类比一个没有项目经理的团队：每个人都很能干，但没人协调时间节点和接口，最后交出来的是互不兼容的结果，还没人知道整体进度。
这就是为什么去中心化更多停留在学术研究里——研究的是「AI 系统能不能实现自主协调」这个更宏观的问题；而生产环境里，几乎所有正经项目都选 Orchestrator 模式，因为可控、可追踪、出了问题能排查，这才是工程上真正需要的。
5 选型决策：两个问题 + 渐进式演进
选型的逻辑其实可以用两个问题搞定。
先问第一个问题：你的任务，Single-Agent 能搞定吗？ 如果任务流程明确、不太长、不需要多种专业分工，Single-Agent 就够了——架构简单、维护成本低、链路透明，不要为了「显得高级」而引入 Multi-Agent。
如果确实超出了 Single-Agent 的边界，再问第二个问题：你能接受系统行为不可控的风险吗？ 生产环境里这个问题的答案几乎一定是「不能」，所以就用 Orchestrator 模式。
实际工程里还有一个很实用的策略叫渐进式演进：先用 Single-Agent 把系统跑起来，当你发现某个环节确实成为瓶颈了——比如 context 经常撑满、某类子任务质量不行——再把那个环节拆出来，交给一个专门的 Worker Agent。不要一上来就设计五六个 Agent 的复杂系统，你可能连真正的瓶颈在哪都还没搞清楚。从 Single-Agent 演进到 Multi-Agent 是一个自然的过程，而不是一开始就做的架构决策。
6 行业趋势：A2A 跨框架协作协议
值得关注的另一个方向是 A2A（Agent-to-Agent）协议，Google 在 2025 年 4 月提出的开放标准。它要解决的问题是：不同团队、不同框架开发的 Agent 之间怎么互相通信和协作。此前每个 Multi-Agent 框架都有自己的通信方式，Agent 只能在同一个框架内协作；A2A 定义了一套标准化通信协议，让不同来源的 Agent 在协议层面可以互相发现和调用，思路上很像微服务。2025 年 6 月，A2A 被捐赠给了 Linux 基金会维护，IBM 的 Agent Communication Protocol（ACP）也已并入 A2A。
不过这个协议目前还在较早期阶段：生态里「真正即插即用地跨框架调用」还没完全成熟，更多是社区实现和示范项目，生产级的跨框架互操作仍在演进。但长远看，这个方向会深刻改变 Multi-Agent 系统的构建方式。
7 三种方案对比
| 维度 | Single-Agent | Multi-Agent（中心化） | Multi-Agent（去中心化） |
|---|---|---|---|
| 架构复杂度 | 低 | 中 | 高 |
| Context 压力 | 全部压在一个 Agent | 各 Agent 独立管理，Orchestrator 只维护高层状态 | 各 Agent 独立管理，但需额外共享协调状态 |
| 专业能力 | 泛才，什么都做 | 专才分工，各有专责 | 专才分工，各有专责 |
| 并行能力 | 不支持 | 支持子任务并行 | 支持并行 |
| 可控性 | 高 | 高，Orchestrator 统管 | 低，难以统一调度 |
| 调试难度 | 容易 | 中，按调度链路追踪 | 难，行为不可预测 |
| 工程实用性 | 高 | 高 | 低，主要用于学术研究 |
| 适用场景 | 任务清晰、复杂度适中 | 需要分工或并行的复杂任务 | 学术探索场景 |
8 要点回顾
回答这道选型题，要答出三个层次才完整：
| 层次 | 要点 |
|---|---|
| 何时用 Single-Agent | 任务流程明确、不太长、无需专业分工；判断标准看三类信号：context 撑爆、需要分工、有可并行子任务，出现才考虑 Multi-Agent |
| Multi-Agent 怎么组织 | 中心化 Orchestrator（读目标 / 拆任务 / 分派 Worker / 汇总）vs 去中心化 Peer-to-Peer；工程上几乎都用中心化 |
| 去中心化为何不可用 | 任务分配没协调、执行顺序没保证、失败没有感知、无人确认整体完成，行为不可控、难排查 |
再补充两个进阶加分项：Orchestrator 的三种变体（静态路由 / 动态规划 / 自适应编排，大多数场景动态规划就够）；渐进式演进策略（先 Single-Agent 跑通，遇到瓶颈再拆出专用 Worker，别一上来就设计复杂系统）。把三个层次加上进阶点答全，再补上 Cursor 的 Background Agents / Cloud Agents 和 Claude Code 的 subagents 这些生产级例子，这道题就回答得很漂亮了。
参考
- 11. 说说 Single-Agent 和 Multi-Agent 的设计方案？ | 小林面试笔记
- 10. 什么是 Multi-Agent？ | 小林面试笔记（前一篇：Multi-Agent 的两大驱动因素与三种协作模式）
- 7. 复杂任务怎么做的任务拆分？ | 小林面试笔记（相关：任务拆分与并行优化）
本文图片均来源于公众号「小林面试笔记」，版权归原作者所有。