type
Post
status
Published
date
May 9, 2026
slug
agent34
summary
tags
Agent
category
icon
password
1. 先给结论：Multi-Agent 不是“多个聊天机器人”
在 LLM 应用里，Agent 通常指一个可以围绕目标自主循环执行的智能体：它会读取上下文、规划下一步、调用工具、观察结果、更新状态，然后继续行动。Multi-Agent 系统则是让多个具备不同角色、上下文、工具权限和执行策略的 Agent 协同完成一个复杂任务。
Anthropic 在其 Research 系统复盘中给出的定义非常直接：Multi-Agent 系统由多个“自主使用工具循环工作的 LLM Agent”共同完成任务；它们的 Research 功能会由一个 Agent 规划研究过程，再创建并行 Agent 同时搜索不同方向的信息。(Anthropic)
单 Agent 系统像“一个全栈工程师从头做到尾”；Multi-Agent 系统更像“一个项目负责人 + 多个专职成员”：有人负责拆解任务，有人负责检索资料，有人负责写代码，有人负责审查安全，有人负责汇总引用。
2. 单 Agent 与 Multi-Agent 的核心差异
单 Agent 的基本形态如下：
Multi-Agent 的典型形态如下：
两者最大的区别不是“模型数量”，而是以下几个工程维度：
维度 | 单 Agent | Multi-Agent |
上下文 | 一个上下文窗口承载所有信息 | 每个 Agent 有独立上下文窗口 |
工具权限 | 通常共享一套工具 | 每个 Agent 可限制不同工具 |
任务拆解 | 由同一个 Agent 自己规划并执行 | 由协调 Agent 拆解，再分配给专职 Agent |
并行能力 | 多数时候是串行工具调用 | 可并行检索、并行审查、并行探索 |
成本 | 较低 | 更高，token、工具调用、协调成本都会增加 |
可控性 | 结构简单，易调试 | 需要解决协调、评估、冲突和权限问题 |
适用任务 | 较短、线性、依赖强的任务 | 开放式、宽搜索、多领域、多工具任务 |
LangChain 官方文档也强调，并不是所有复杂任务都需要 Multi-Agent；很多任务用一个拥有合适工具和 Prompt 的单 Agent 就能完成。Multi-Agent 更适合上下文管理、能力模块独立维护、并行化和工具边界清晰的场景。(LangChain 文档)
3. 为什么会出现 Multi-Agent？
3.1 单 Agent 的上下文窗口会被“脏信息”淹没
以代码任务为例，一个单 Agent 可能需要同时处理：
项目结构、用户需求、历史对话、代码文件、测试日志、错误栈、依赖文档、安全规范、最终输出格式。
这些信息全部塞进一个上下文窗口，容易导致三个问题：
第一，重要信息被日志、搜索结果、长文件污染。第二，Agent 对工具选择变差，例如明明只需要读文件，却开始大范围搜索。第三，后续回答会受到早期探索路径影响，产生路径依赖。
Claude Code 的 subagent 设计正是为了解决这个问题：它的文档说明，subagent 会在自己的上下文窗口里工作，使用独立系统提示词、特定工具访问和独立权限；主对话只接收 summary，从而避免搜索结果、日志和文件内容淹没主上下文。(Claude API Docs)
3.2 多工具、多领域任务需要角色边界
在 OpenCode 中，官方文档把 Agent 分为 primary agents 和 subagents。Primary agent 是用户直接交互的主助手，例如 Build 和 Plan；subagent 则由 primary agent 自动调用，或由用户通过
@ 手动调用。Build 默认用于完整开发工作，Plan 则是偏只读的规划/分析 Agent。(OpenCode)这说明一个成熟 Agent 系统通常不会只靠一个“万能 Prompt”，而是会拆成：
规划 Agent：只读、低风险、适合分析。构建 Agent：可写文件、可运行命令、适合实现。审查 Agent：只读或有限权限，适合代码质量、安全和性能检查。检索 Agent：负责外部知识、文档、RAG、Web 搜索。汇总 Agent：负责结果裁剪、冲突处理、引用归因。
3.3 并行搜索能显著提升宽任务覆盖率
Anthropic 在 Multi-Agent Research 系统中使用了 orchestrator-worker 模式：Lead Agent 负责分析用户问题、制定策略，并创建多个 subagent 并行探索不同方面，最后由 Lead Agent 汇总；后面还会交给 CitationAgent 做引用定位。(Anthropic)
Anthropic 内部评估中，一个由 Claude Opus 4 作为 lead agent、Claude Sonnet 4 作为 subagents 的多 Agent 研究系统，在内部 research eval 上比单 Agent Claude Opus 4 高出 90.2%；但代价也很明显：Agent 通常比普通 chat 多用约 4 倍 token，Multi-Agent 又可能达到普通 chat 的约 15 倍 token。(Anthropic)
这就是 Multi-Agent 的本质：
用更多 token、更复杂的调度和更多工具调用，换取更大的搜索空间、更好的覆盖率和更强的复杂任务处理能力。
4. 从成熟项目看 Multi-Agent 的几种实现形态
4.1 Claude Code：subagent 是“上下文隔离 + 工具权限隔离”
Claude Code 文档里，subagent 的重点是：
每个 subagent 有独立上下文窗口。每个 subagent 有自己的系统提示词。每个 subagent 可以限制工具访问和权限。主 Agent 根据 subagent 描述自动决定是否委派。适合把搜索、日志、代码探索等高噪声任务隔离出去。(Claude API Docs)
一个典型的 Claude Code subagent 配置可以抽象成下面这样：
这个设计的关键不是 Prompt 写得多漂亮，而是 权限边界 和 上下文边界。如果审查 Agent 不需要写文件，就不应该给它 Edit/Write 权限；如果探索 Agent 只需要搜索代码，就不应该让它执行任意 Bash 命令。
4.2 OpenCode：primary agent + subagent + permission
OpenCode 官方文档给出了更配置化的 Agent 模型。它支持通过
opencode.json 定义 primary agent 和 subagent，并分别指定 mode、model、prompt、permission。官方示例中，build 是 primary agent，可以允许 edit/bash；plan 是 primary agent，但 edit/bash 被 deny；code-reviewer 是 subagent，并且禁止 edit。(OpenCode)可以抽象成如下配置：
这给我们一个很重要的工程启发：
Multi-Agent 系统不是让多个 Agent “自由发挥”，而是要把每个 Agent 的工具权限、调用边界、输出格式、失败策略配置清楚。
4.3 OpenClaw：从单会话 Agent 走向多渠道、多工作区、多 Agent 路由
OpenClaw 的公开仓库 README 把它描述成一个本地优先的 Gateway：统一管理 sessions、channels、tools 和 events；它还强调 multi-channel inbox，可以连接 Slack、Discord、Telegram、WhatsApp、LINE、Teams 等渠道，并支持 multi-agent routing，把不同入站渠道、账号或联系人路由到隔离的 agents、workspaces 和 per-agent sessions。(GitHub)
OpenClaw 的另一个特征是 workspace + skills：默认工作区在
~/.openclaw/workspace，会注入 AGENTS.md、SOUL.md、TOOLS.md，skills 则位于 ~/.openclaw/workspace/skills/<skill>/SKILL.md。(GitHub)这类系统更像“个人/企业 Agent 操作系统”：
这说明 Multi-Agent 不一定只发生在“同一个任务内部”，也可能发生在“多个入口、多种身份、多种工作区、多种权限边界”的长期系统中。
4.4 LangChain / LlamaIndex：Multi-Agent 是一种编排模式，而不是产品形态
LangChain 文档把 Multi-Agent 的主要模式归纳为 subagents、handoffs、skills、router、custom workflow 等。其中 subagents 是主 Agent 把子 Agent 当工具调用；handoffs 是根据状态切换当前 Agent；router 是先分类再分发给不同 Agent；custom workflow 则适合用 LangGraph 构建确定性逻辑 + Agent 节点混合的流程。(LangChain 文档)
LlamaIndex 也把多 Agent 模式分为 AgentWorkflow、Orchestrator pattern 和 Custom planner：前者让框架管理 handoff；中间是编排 Agent 选择调用哪个子 Agent；后者则由开发者自己写计划和调用逻辑。(Developer Documentation)
这说明在工程实现上，Multi-Agent 至少有三种常见架构。
5. Multi-Agent 的三种核心架构
5.1 Supervisor / Worker 模式
这是最常见、最好落地的模式。
适合：
深度研究报告。多代码文件改造。多数据源分析。一次任务中有多个相对独立方向。需要最终由一个 Agent 统一裁剪、综合、归因。
核心代码抽象如下：
这个架构最重要的是
Task 必须结构化。很多 Multi-Agent 系统失败，不是因为模型不够强，而是 Supervisor 只给子 Agent 一句模糊指令，例如“去研究一下这个问题”。Anthropic 也提到，如果 lead agent 给 subagent 的任务描述不够详细，就会出现重复搜索、任务误解和覆盖缺口；每个 subagent 需要明确目标、输出格式、工具/来源建议和边界。(Anthropic)5.2 Router 模式
Router 模式适合“任务类型明确，但入口统一”的场景。
适合：
企业内部 AI 助手。客服机器人分流。开发者平台助手。多业务线统一入口。不同任务需要不同工具权限。
Router 模式的核心代码如下：
Router 模式的优点是成本低、链路短；缺点是很依赖分类质量。如果分类错了，后面的 Agent 再强也会跑偏。
5.3 Handoff / Swarm 模式
Handoff 模式不是始终由中心节点控制，而是当前 Agent 根据状态把任务交给下一个 Agent。
适合：
客服流程。销售流程。审批流程。多轮对话中用户意图会变化的场景。当前 Agent 能判断下一个最合适角色的场景。
Handoff 的风险是对话控制权可能来回跳，导致状态不一致。所以生产系统一般要有一个共享状态对象：
Multi-Agent 系统一定要避免“口口相传”式的信息损失。Anthropic 在复盘中也建议让 subagent 的输出写入文件系统或外部 artifact，主协调者只传轻量引用，避免所有信息都通过 lead agent 复述，从而减少信息失真。(Anthropic)
6. Multi-Agent 与 RAG 的关系
很多人会问：既然 RAG 已经可以检索知识，为什么还要 Multi-Agent？
可以这样理解：
RAG 解决的是“如何从知识库中找相关信息”。Agent 解决的是“如何围绕目标持续行动”。Multi-Agent 解决的是“当任务太宽、太长、太复杂时，如何并行探索、分工执行、隔离上下文”。
传统 RAG 通常是：
Multi-Agent + RAG 则更像：
Anthropic 明确对比过传统 RAG 和其 Multi-Agent Research 架构：传统 RAG 通常是静态检索相似 chunks，而他们的架构是多步搜索，会根据新发现动态寻找相关信息、调整策略并分析结果。(Anthropic)
所以，在复杂知识任务中，Multi-Agent 可以看作 RAG 的上层调度器：
单次检索不够，就让多个检索 Agent 从不同方向搜索。一个知识库不够，就让不同 Agent 使用不同来源。一个 query 不够，就让 Agent 根据观察结果不断改写 query。生成答案不够可信，就增加 citation / verifier Agent 做核验。
7. Multi-Agent 系统的典型适用场景
7.1 深度研究与调研报告
这是最适合 Multi-Agent 的场景之一。原因是研究任务天然具有宽搜索特征：
需要查多个来源。需要比较不同观点。需要验证事实。需要引用归因。需要根据新线索继续追查。
Anthropic 的 Research 系统就是典型案例：Lead Agent 规划研究，多个 subagent 并行搜索，最后再汇总和引用。(Anthropic)
7.2 大型代码库分析与开发
代码任务不一定总适合 Multi-Agent。Anthropic 也指出，很多 coding task 的可并行空间比 research 小，而且当前 LLM Agent 还不擅长实时协调和委派。(Anthropic)
但在以下代码场景中，Multi-Agent 很有价值：
一个 Agent 探索代码结构。一个 Agent 制定修改计划。一个 Agent 执行 patch。一个 Agent 运行测试和定位失败。一个 Agent 做安全/性能 review。
Claude Code 和 OpenCode 的 subagent / Plan / Build / Reviewer 设计，本质就是把代码任务中的“探索、规划、修改、审查”拆开处理。Claude Code 的 Explore subagent 是只读、低延迟、用于代码搜索和代码库理解；Plan subagent 用于计划模式下收集上下文；general-purpose 则适合复杂多步任务。(Claude API Docs)
7.3 企业内部助手与多系统自动化
企业场景里，一个 Agent 往往要面对 CRM、工单、知识库、邮件、日历、数据库、BI、代码仓库、云平台等多个系统。把所有工具都给一个 Agent，风险会很高：
工具太多，Agent 选择困难。权限太大，误操作风险高。上下文太杂，回答质量下降。不同业务规则混在一起，难维护。
更合理的做法是：
HR Agent 只能访问 HR 知识库和审批系统。Finance Agent 只能访问财务报表和预算工具。DevOps Agent 可以访问日志和部署系统，但高危操作需要审批。Support Agent 可以访问工单和 FAQ，但不能访问敏感财务数据。Supervisor Agent 负责路由、汇总和升级人工。
7.4 个人助理与多渠道入口
OpenClaw 这类系统体现了另一个方向：Agent 不只是一个网页对话框，而是可以接入 Slack、Discord、Telegram、移动端语音等多个入口，并按渠道、账号、联系人路由到隔离的 Agent 和 workspace。(GitHub)
这类系统适合：
私人助理。团队机器人。长期运行的工作流 Agent。多设备、多渠道统一入口。不同身份上下文隔离，例如个人、工作、开源项目。
8. 哪些场景不适合 Multi-Agent？
Multi-Agent 并不是银弹。以下场景优先用单 Agent：
8.1 任务很短、路径很明确
例如：
“解释这段代码。”“把这段 SQL 优化一下。”“写一个正则表达式。”“根据这段日志判断报错原因。”
这些任务用单 Agent 更快、更便宜、更稳定。
8.2 子任务强依赖，无法并行
如果每一步都必须依赖上一步结果，那么拆多个 Agent 可能只会增加沟通成本。
例如：
严格线性的表单填写。小范围 bug fix。一个函数内部的局部重构。必须共享完整上下文的复杂推理题。
8.3 没有清晰权限边界
如果你无法定义每个 Agent 能做什么、不能做什么，就不要急着做 Multi-Agent。
一个危险设计是：
每个 Agent 都能读写文件。每个 Agent 都能执行 Shell。每个 Agent 都能访问所有外部系统。每个 Agent 都能继续创建更多 Agent。
这会让系统不可控。OpenCode 的
allow / ask / deny permission 模型就是非常值得借鉴的工程约束。(OpenCode)8.4 成本敏感但收益不明显
Multi-Agent 消耗更多 token、更多工具调用、更多调度逻辑。Anthropic 的数据也显示，multi-agent systems 可能使用约 15 倍于普通 chat 的 token，因此只有高价值任务才值得付出这类成本。(Anthropic)
9. 一个生产级 Multi-Agent 系统应该怎么设计？
我建议从以下 8 个模块入手。
9.1 Agent Registry：定义 Agent 能力
9.2 Task Contract：每个子任务必须有契约
不要让 Supervisor 只说：
“你去查一下。”
应该说：
“你负责检索 2024-2026 年 Agent 框架中 subagent / tool permission 的设计。只返回官方来源。输出字段包括：项目名、机制、证据链接、可借鉴点。最多 8 次搜索。不写最终结论。”
9.3 Artifact Store：不要只靠自然语言传递
子 Agent 的产物应该写入 artifact store，Supervisor 只拿引用和摘要。这样可以避免：
子 Agent 说 A，Supervisor 复述成 B。审查 Agent 找不到 coder 的完整 patch。引用 Agent 无法定位 researcher 的原始来源。最终答案无法追溯。
9.4 Verifier：必须有审查或验证环节
在生产系统里，Multi-Agent 最容易出现“大家都很自信，但整体是错的”。因此至少要有一个 verifier：
9.5 Human-in-the-loop：高风险动作必须人工确认
高风险动作包括：
删除文件。执行部署。发送邮件。修改数据库。访问敏感数据。调用付费或不可逆 API。
对于这些动作，Agent 应该只能生成计划，由人确认后再执行。
10. Multi-Agent 的常见失败模式
10.1 过度拆分
最典型的错误是：一个简单问题也创建十几个 Agent。
Anthropic 提到早期系统出现过类似问题：简单查询也创建 50 个 subagent，或者为了不存在的来源持续搜索。(Anthropic)
解决方法：
给 Supervisor 设置 effort budget。简单任务最多 1 个 Agent。中等任务 2-4 个 Agent。复杂研究任务才允许更多 Agent。每个 Agent 设置最大工具调用次数和超时。
10.2 子 Agent 重复劳动
如果任务边界不清晰，多个 Agent 会查同一个问题。
解决方法：
每个任务必须有明确 scope。Supervisor 先生成任务矩阵。子 Agent 输出“已覆盖范围”和“未覆盖范围”。汇总阶段做 coverage check。
10.3 信息冲突无法收敛
不同 Agent 得出不同结论时，不能简单投票。
解决方法：
按证据质量排序。按来源权威性排序。按时间新旧排序。让 verifier 单独判断冲突。无法判断时明确标注“不确定”。
10.4 工具权限过大
这是 Agent 系统最危险的问题。
解决方法：
默认 deny。只给最小工具集。写操作 ask。外部系统分 scope。高风险操作人工确认。对每次工具调用做 trace。
10.5 评估困难
传统评估通常假设“输入 X，走路径 Y，输出 Z”。但 Multi-Agent 每次可能走不同路径，只要结果正确，路径可以不同。Anthropic 也指出，多 Agent 系统评估的难点在于，同一个起点可能通过不同有效路径达成目标，因此不能只检查是否走了预设步骤，而要判断结果是否达成、过程是否合理。(Anthropic)
评估指标建议分成三类：
类别 | 指标 |
结果质量 | 正确率、完整率、引用准确率、代码测试通过率 |
过程质量 | 工具调用成功率、重复调用率、越权调用率、冲突解决率 |
工程成本 | token 成本、延迟、并发数、失败重试次数、人工介入次数 |
11. 单 Agent 到 Multi-Agent 的演进路径
不要一开始就做复杂 Multi-Agent。推荐按下面路径演进：
阶段 1：单 Agent + 工具
先验证核心任务能否跑通。
阶段 2：单 Agent + Skills
把可复用提示词、流程说明、领域知识拆成 skills，而不是马上拆 Agent。
阶段 3：Router
当任务类型明显不同，再引入 Router。
阶段 4：只读 Subagent
先引入低风险 subagent，例如 researcher、reviewer、explorer。
阶段 5：Supervisor + Worker
当任务确实需要并行、分工和多上下文窗口，再上完整 Multi-Agent。
阶段 6：Artifact + Verifier + Human Approval
进入生产前，必须补齐可观测性、审查、权限和人工确认。
12. 最终判断标准：什么时候该用 Multi-Agent？
可以用下面这个判断清单。
适合 Multi-Agent：
任务需要多个独立方向并行探索。单个上下文窗口容易被污染或不够用。不同子任务需要不同工具和权限。需要多个专业角色协作，例如检索、编码、审查、验证。任务价值足够高，可以接受更高 token 成本和延迟。结果需要汇总、引用、交叉验证。系统需要长期运行，并面对多个入口、多个工作区、多个身份。
不适合 Multi-Agent：
任务短、简单、线性。子任务高度依赖，无法并行。成本和延迟非常敏感。没有权限隔离设计。没有 trace、日志、评估和人工兜底。团队还没有把单 Agent 做稳定。
一句话总结：
单 Agent 适合“一个人能做完”的任务；Multi-Agent 适合“需要团队协作、上下文隔离、并行探索和权限边界”的任务。
13. 工程落地建议
最后给一个实践建议：
不要为了“Multi-Agent”而 Multi-Agent。先把你的系统拆成：任务类型、工具权限、上下文来源、风险等级、输出契约。如果这些边界天然存在，再把它们映射成 Agent。如果边界不存在，先用单 Agent、skills、router、workflow 就够了。
成熟项目给我们的共同启发是：
Claude Code 证明了 subagent 对上下文隔离和工具权限很重要。OpenCode 证明了 primary agent、subagent、permission 可以配置化。OpenClaw 证明了长期运行的个人/企业助手需要渠道路由、workspace 隔离和 skills。Anthropic Research 证明了 Multi-Agent 在宽搜索、复杂研究和并行探索中能显著提升能力，但成本也会显著上升。LangChain / LlamaIndex 证明了 Multi-Agent 本质是一组编排模式，而不是固定产品形态。
真正生产级的 Multi-Agent 系统，本质上不是“多个 LLM 对话”，而是：
可观测的调度系统 + 最小权限工具系统 + 结构化任务契约 + 独立上下文窗口 + 可追溯 artifact + 验证与人工兜底。
分享