Single-Agent 与 Multi-Agent 的核心差异

很多人第一次做 Agent 系统，最容易犯一个错误：一听到“复杂任务”，马上就想上 Multi-Agent。

但在真实工程里，Agent 不是越多越强。Agent 越多，沟通成本、调度成本、上下文同步成本、调试成本也会一起上升。

所以这章的重点不是背概念，而是回答一个更实用的问题：什么任务用 Single-Agent 就够了？什么任务必须拆成 Multi-Agent？多 Agent 又该怎么组织，才不会失控？

Single-Agent 适合流程清晰、复杂度适中的任务；Multi-Agent 适合上下文太长、需要专业分工、或者可以并行执行的复杂任务。生产环境里，多 Agent 优先用中心化 Orchestrator，而不是去中心化自由聊天。

1. 不是复杂就拆，而是瓶颈出现才拆

判断 Single-Agent 还是 Multi-Agent，不要只说“简单用单 Agent，复杂用多 Agent”。这个回答太虚。

更靠谱的判断标准是看三个瓶颈：

Context 是否快撑爆：资料、对话、工具结果太多，一个 Agent 已经记不住全局约束。

专业能力是否冲突：同一个 Agent 既要搜索、分析、编码、审稿，提示词越写越臃肿。

任务是否能并行：多个子任务互相独立，单 Agent 串行执行太慢。

2. Single-Agent：一个大脑，掌控完整链路

Single-Agent 的本质很简单：一个 LLM，加上一组工具，再配上记忆、状态和停止条件。它自己判断下一步做什么，自己调用工具，自己拿观察结果继续推理，直到任务完成。

它最大的优势不是“简单”两个字，而是可控。所有决策都在一个 Agent 内部，链路短、状态少、调试容易。

比如让 Agent 写一篇技术博客，它可以自己查资料、生成大纲、补充案例、整理成文。这个任务虽然有多个步骤，但目标统一、上下文可控，用 Single-Agent 通常更划算。

2.1 Single-Agent 的最小实现思路

真实项目里，Single-Agent 不应该是“while True + 大模型瞎跑”。至少要有工具白名单、最大轮数、结构化观察结果和停止条件。

class SingleAgent:

def __init__(self, llm, tools, max_steps=8):

self.llm = llm

self.tools = tools

self.max_steps = max_steps

def run(self, user_goal):

state = {"goal": user_goal, "observations": []}

for step in range(self.max_steps):

decision = self.llm.plan_next_step(state)

if decision.type == "final_answer":

return decision.content

if decision.tool_name not in self.tools:

return "工具不在白名单内，停止执行"

result = self.tools[decision.tool_name](**decision.args)

state["observations"].append({

"tool": decision.tool_name,

"args": decision.args,

"result": result,

})

return "达到最大步数，进入人工复核"

这段代码表达的是工程重点：Agent 可以自主决策，但不能无限循环；可以调用工具，但必须在白名单内；可以继续推理，但每次工具结果都要进入可追踪状态。

3. Single-Agent 什么时候开始不够用？

Single-Agent 不是低级方案。很多业务系统用 Single-Agent 已经足够。它真正开始吃力，通常不是因为“步骤多”，而是因为下面三条边界被突破。

第一条边界是上下文。任务越长，Agent 越容易忘记最初的约束。把所有资料、工具结果、用户偏好都塞进一个上下文，最后会变成一锅粥。

第二条边界是专业性。一个 Agent 同时做搜索员、分析师、程序员、审稿人，每个角色都只能做到“差不多”。这时候拆出专家 Worker 会更稳。

第三条边界是并行性。多个子任务互不依赖，却被单 Agent 串行执行，速度自然上不去。

4. 中心化 Multi-Agent：主 Agent 当项目经理

Multi-Agent 最常见、也最适合工程落地的方式，是中心化 Orchestrator。

Orchestrator 像项目经理。它不一定亲自做搜索、写代码、写报告，而是负责读懂目标、拆分任务、分配 Worker、收集结果、判断是否需要重试，最后统一输出。

Worker Agent 则像专职员工。Researcher 只负责查资料，Analyst 只负责分析，Coder 只负责写代码，Writer 只负责成文。每个 Worker 的上下文更小、更干净，提示词也更聚焦。

这就是多 Agent 的真正价值：不是多几个“会说话的角色”，而是把复杂任务拆成边界清晰、可并行、可验收的工作单元。

4.1 例子：AI 行业竞品分析

假设用户说：“帮我写一份 AI 行业竞品分析”。如果交给一个 Agent，它要查公司、看产品、做对比、写结论、检查事实，链路会很长。

中心化 Multi-Agent 可以这样拆：Researcher 收集资料，Analyst 做维度对比，Writer 输出文章，Reviewer 检查事实和结构。Orchestrator 只管调度和最终汇总。

4.2 Orchestrator 也分三档，不要一开始就拉满

Orchestrator 不是一种固定写法，它通常有三种复杂度。

静态路由最稳定，适合客服、工单、分类。动态规划更灵活，适合报告、调研、代码迁移。自适应编排能力最强，但排查成本最高，适合高价值、长链路任务。

实际项目建议从动态规划开始，不要一上来就把所有决策都交给模型。

4.3 Orchestrator 的伪代码

下面这段代码不是依赖某个框架，而是表达中心化 Multi-Agent 的核心控制流。

class Orchestrator:

def __init__(self, planner, workers, evaluator):

self.planner = planner

self.workers = workers

self.evaluator = evaluator

def run(self, goal):

plan = self.planner.split(goal)

results = {}

for task in plan.tasks:

worker = self.workers[task.role]

output = worker.run(task.input)

results[task.id] = output

check = self.evaluator.check(task, output)

if not check.passed:

retry_task = self.planner.repair(task, check.reason)

results[task.id] = worker.run(retry_task.input)

return self.planner.merge(goal, results)

重点在于：任务拆分、Worker 调用、结果验收、失败修复、最终合并，都由 Orchestrator 统一控制。

5. 去中心化 Multi-Agent：听起来灵活，工程上很难控

去中心化方案没有总调度。多个 Agent 通过共享消息队列、共享状态或直接对话，自行协商怎么完成任务。

它听起来很美好：没有项目经理，团队成员自己协作。但工程里最怕的就是“没人对全局结果负责”。

没有 Orchestrator 时，常见问题会同时出现：任务分配重叠、依赖顺序混乱、某个 Agent 失败没人知道、最终到底有没有完成也没人确认。

所以去中心化更适合研究探索、仿真系统、开放式群体协作实验。真正的业务生产系统，一般更偏向中心化，因为它可控、可追踪、可回滚。

6. 三种方案放在一起看

Single-Agent、中心化 Multi-Agent、去中心化 Multi-Agent，本质上是三种不同复杂度的系统。选型时不要只看“能力”，还要看可控性、调试难度和成本。

表里的结论很直接：大多数业务先用 Single-Agent；当确实出现上下文、专业分工、并行瓶颈时，再上中心化 Multi-Agent；去中心化要非常谨慎。

7. 最稳的路线：从 Single-Agent 渐进式演进

很多系统失败，不是因为技术不够先进，而是因为一开始设计太重。

更好的方式是：先用 Single-Agent 跑通 MVP，积累真实 Trace，再从日志里找到瓶颈。比如搜索质量不稳定，就拆 Researcher；代码生成经常错，就拆 Coder；最终回答质量不稳定，就加 Reviewer。

每拆出一个 Worker，都要回答一个问题：它解决了哪个明确瓶颈？如果回答不出来，就不要拆。

8. 工程落地：多 Agent 不是多个 Prompt 拼接

生产级 Multi-Agent 更像一个分布式任务系统。它需要任务契约、状态管理、权限隔离、失败恢复和质量评测。

一个 Worker 的输入不能是“你看着办”，而应该是结构化任务：目标、上下文、可用工具、输出格式、超时时间、验收标准。

task = {

"id": "research_pricing",

"role": "Researcher",

"goal": "收集三家竞品的价格与套餐信息",

"context": {

"companies": ["A 公司", "B 公司", "C 公司"],

"time_range": "最近 12 个月"

},

"tools": ["web_search", "page_fetch"],

"output_schema": {

"company": "string",

"pricing": "string",

"source_url": "string",

"confidence": "number"

},

"timeout_seconds": 120,

"acceptance": "必须给出来源链接，不能只写主观判断"

}

这样做的好处是，Worker 不会随意发挥，Orchestrator 也能自动检查结果是否达标。

9. MCP 与 A2A：工具互联和 Agent 互联是两回事

现在 Agent 生态里常被一起提到两个协议：MCP 和 A2A。

MCP 更像“工具接入标准”：Agent 通过标准方式连接数据库、文件系统、搜索、业务 API。A2A 更像“Agent 通信标准”：不同框架、不同团队、不同平台做出来的 Agent，可以通过统一协议发现和协作。

但要注意，协议解决的是互操作问题，不会自动解决业务编排问题。任务怎么拆、谁负责、失败怎么恢复、成本怎么控制，仍然需要系统设计。

10. 框架选型：看你要的是控制力还是上手速度

不同框架对 Single-Agent 和 Multi-Agent 的抽象不同，选型时可以按目标来判断。

OpenAI Agents SDK：适合做 Handoff、Agents-as-Tools、Tracing 和轻量多 Agent 编排。

LangGraph：适合需要显式状态机、长流程、可恢复执行、可观测图工作流的系统。

CrewAI：适合快速搭建角色分工明显的 Crew，强调角色、任务和协作。

AutoGen / Microsoft Agent Framework：适合基于多 Agent 对话、事件驱动和企业级编排的场景。

手搓 Orchestrator：适合业务规则强、权限要求高、需要深度定制的系统。

如果业务还没跑通，不要一开始就纠结框架。先把任务链路、数据结构、工具权限、评测标准写清楚，框架只是承载方式。

11. 面试可以这样回答

我不会简单按“复杂度”决定是否上 Multi-Agent，而是先判断 Single-Agent 是否已经触碰边界：上下文是否过长、是否需要不同专业分工、是否存在可并行子任务。如果没有这些瓶颈，我会优先用 Single-Agent，因为链路短、成本低、调试简单。

如果确实需要 Multi-Agent，我会优先选择中心化 Orchestrator 模式，由主 Agent 负责拆分、调度、汇总和失败处理，Worker Agent 专注具体任务。去中心化虽然灵活，但任务分配、执行顺序、失败感知和完成判断都很难控制，所以生产环境不优先选择。

落地上我会采用渐进式演进：先用 Single-Agent 跑通，再根据 Trace 找到真实瓶颈，把某个环节拆成 Worker，并补齐输入输出契约、权限隔离、成本预算、Trace 追踪和质量评测。

12. 总结

Single-Agent 是默认起点，不是低级方案。它适合流程清晰、上下文可控、专业性要求不分散的任务。

Multi-Agent 的价值来自三件事：拆上下文、拆专业能力、拆并行任务。

中心化 Orchestrator 是更适合生产的多 Agent 方案，因为可控、可追踪、可恢复。

去中心化方案更像研究方向，生产落地要谨慎。

多 Agent 不是多个 Prompt 拼起来，而是任务契约、状态管理、工具权限、成本预算和质量评测的系统工程。