多 Agent（Multi-Agent）是什么？原理、主流框架、适用场景、优劣势与真实案例

多 Agent（Multi-Agent System，多智能体系统）是由多个具备独立角色、上下文、工具和决策能力的 AI Agent 共同完成一个目标的系统。它的核心价值不是“多调用几次大模型”，而是把可以拆分的复杂任务交给不同专业单元，并通过编排、消息契约、共享状态和结果验证形成协作闭环。

多 Agent 并不天然优于单 Agent。它更适合任务可并行、专业边界清晰、上下文可以隔离、子任务能够独立验收的场景；如果步骤固定、依赖紧密、所有角色都需要完整共享同一上下文，单 Agent 加确定性工作流通常更便宜、更稳定。LangChain 的官方文档也明确提醒：很多复杂任务仍可由一个拥有合适工具和提示词的 Agent 完成，不应为了架构新颖而强行拆分。

一句话结论：多 Agent 的本质是“受控的任务分解与专业协作”，不是多个机器人自由聊天；决定系统效果的关键，是分工是否必要、交接是否结构化、状态是否可恢复、结果是否可验证，以及增加的质量能否覆盖额外成本。

图 1：多 Agent 系统由协调器分解任务，专业 Agent 独立执行，运行时统一负责状态、权限、预算、工具和结果验证。

一、多 Agent 到底是什么，它不是什么

一个可工程化的多 Agent 系统，至少包含三个相互独立的决策单元，以及一个约束它们协作方式的运行环境：

• 协调单元：理解总目标，决定是否拆分、分给谁、并行还是串行，以及何时停止。
• 专业 Agent：拥有明确职责、有限工具和局部上下文，产出可验证的子任务结果。
• 验证单元：检查事实、Schema、测试结果或业务终态，避免让生成结果的 Agent 同时充当唯一裁判。
• Agent Runtime：维护任务状态、消息、检查点、预算、超时、权限、追踪和人工审批。

从实现上看，每个 Agent 可以抽象为：

Agent_i = {
  role,             # 角色与职责边界
  objective,        # 当前子目标与完成条件
  context,          # 局部上下文与证据
  tools,            # 可调用工具及权限
  memory,           # 短期状态与长期记忆
  budget,           # token、时间、工具调用次数
  output_schema     # 结构化交付契约
}

多 Agent 的“多”，不是角色名称多，而是决策边界真实分开。例如，一个提示词依次要求模型扮演“分析师、审核员、写作者”，仍然只是一次模型调用；一个工作流调用三次相同提示词，也不必然构成有意义的多 Agent。只有当各单元拥有独立目标或上下文，并通过明确的路由、交接或聚合机制协作时，多 Agent 架构才有实际价值。

多 Agent、单 Agent 和传统工作流有什么区别

方案	谁决定下一步	上下文形态	适合场景	主要风险
单 Agent	一个模型动态决策	共享上下文	工具有限、目标统一的开放任务	上下文膨胀、职责过宽
确定性工作流	代码预先规定	节点状态	路径固定、规则清晰、强审计任务	遇到长尾情况不灵活
多 Agent	协调器与专业 Agent 共同决策	分区上下文 + 共享状态	可分解、可并行、跨专业任务	协调成本、错误传播、难评估
混合架构	代码控制主流程，模型处理不确定节点	状态机 + 局部上下文	大多数企业生产场景	设计和治理要求较高

企业通常不应在四者中“选一个到底”，而应采用混合结构：确定性工作流负责权限、顺序、预算和状态；Agent 负责理解、搜索、判断和生成；只有真正需要独立专业推理的部分才拆成多个 Agent。

二、多 Agent 的运行原理是什么

多 Agent 的运行过程可以归纳为“分解—分派—执行—交接—验证—聚合—再规划”七步循环。

1. 分解目标：协调器把总目标拆成具有明确输入、输出和完成条件的子任务。
2. 选择 Agent：根据能力描述、工具权限、数据边界、成本和当前负载选择执行者。
3. 构建局部上下文：只给专业 Agent 完成当前任务所需的目标、证据和工具，避免复制全部历史。
4. 执行并产生工件：Agent 调用搜索、数据库、代码执行或业务 API，输出报告、代码、表格或结构化事件。
5. 结构化交接：子 Agent 返回结果摘要、证据引用、置信度、未解决问题和工件地址，而不是整段聊天记录。
6. 独立验证：规则、测试、业务回执、另一个 Agent 或人工审核结果。
7. 聚合或再规划：协调器合并结果；发现缺口时重新分派，达到验收条件、预算上限或停止条件时结束。

可以把一次子任务交接设计为稳定的数据契约：

{
  "task_id": "research-2026-001-03",
  "parent_task_id": "research-2026-001",
  "agent_role": "security_researcher",
  "objective": "核验三个安全风险及其原始来源",
  "input_refs": ["artifact://outline/v2"],
  "allowed_tools": ["web_search", "paper_reader"],
  "budget": {"max_turns": 8, "max_tokens": 24000},
  "status": "completed",
  "output_refs": ["artifact://security-findings/v1"],
  "evidence": [{"source": "official", "claim_ids": ["c12", "c18"]}],
  "open_questions": ["是否存在2026年后的修订版本"]
}

这类契约解决三个问题：协调器知道子任务是否真正完成；后续 Agent 不必阅读全部对话；运行平台可以独立执行重试、审计和成本统计。

三、多 Agent 有哪些主流协作模式

协作模式决定控制权放在哪里，也决定系统的成本、可预测性和故障半径。OpenAI Agents SDK 把常用方式概括为“由 LLM 编排”和“由代码编排”，并支持管理者调用专业 Agent、Handoff 交接、串行链、评审循环和并行执行。

图 2：串行、并行、主管—执行者、Handoff 和群组协作的控制权、通信方式与适用任务不同。

1. 串行流水线：上一步输出成为下一步输入

需求分析 Agent → 检索 Agent → 写作 Agent → 审核 Agent

串行模式最容易理解和测试，适合内容生产、合同审查、数据清洗等阶段边界明确的任务。缺点是总延迟相加，前一步错误会直接污染后续步骤。因此，每一步都应输出结构化结果并设置局部验收，而不是把未经检查的自然语言继续传递。

2. 并行扇出与聚合：多个 Agent 同时探索

                 ┌→ 市场 Agent ─┐
总任务 → 分解器 ─┼→ 技术 Agent ─┼→ 聚合与去重 → 最终结果
                 └→ 风险 Agent ─┘

这种模式适合彼此独立的搜索、对比、仿真和多方案生成。它能够缩短墙钟时间并扩大覆盖面，但会消耗更多 token，还需要处理重复结论、相互矛盾的证据和慢任务拖尾。

3. Supervisor-Worker：主管动态分解并调度执行者

主管 Agent 根据中间结果动态创建或选择 Worker，最适合步骤无法预先完全确定的研究、故障诊断和复杂决策支持。Anthropic 的 Research 系统就是典型的 Orchestrator-Worker 架构：Lead Agent 制定计划并并行创建子 Agent，子 Agent 独立搜索，再由主 Agent决定是否继续研究，最后交给 Citation Agent 处理引用。

Supervisor-Worker 的难点是主管本身会成为单点：分解错误会让所有 Worker 一起做错；过度分派会引发成本失控；聚合能力不足会丢失关键细节。

4. Handoff：根据上下文把控制权交给专业 Agent

Handoff 更像业务转接。分诊 Agent 识别用户意图后，把当前会话交给退款、技术支持或账户安全 Agent，接手者成为新的活动 Agent。它适合客服路由、分级诊疗和内部服务台。

Handoff 必须明确传递什么、隐藏什么以及谁拥有最终回复权。OpenAI SDK 将 Handoff 表示为模型可调用的工具，并支持结构化交接参数和输入过滤；如果专业 Agent 只需完成一个局部任务而不应接管会话，则更适合使用“Agent as Tool”。

5. 群组对话或黑板模式：多个 Agent 围绕共享空间协作

多个 Agent 把观点、候选答案或工件写入共享消息流或“黑板”，由主持者选择下一位发言者并判断何时收敛。这适合头脑风暴、辩论式评审和多专家会诊，但也是最容易出现循环争论、内容重复和责任不清的模式。

生产系统不应让群组对话无限进行。至少要设置主持规则、最大轮次、发言资格、工件版本、冲突解决方式和最终决策人。

一张表看懂五种多 Agent 模式

模式	控制权	并行性	可预测性	典型任务
串行流水线	代码或固定编排器	低	高	内容加工、分阶段审查
并行扇出	分解器 + 聚合器	高	中	调研、搜索、多方案比较
Supervisor-Worker	主管 Agent	中到高	中低	开放研究、动态诊断
Handoff	当前 Agent 选择接手者	低	中	客服分诊、专家转接
群组/黑板	主持者或共享规则	可变	低	辩论、评审、协商

四、多 Agent 如何通信，MCP 和 A2A 有什么区别

多 Agent 通信不应依赖自然语言“互相喊话”。生产系统需要区分三条通道：控制消息、共享状态和业务工件。

• 控制消息：任务创建、分派、取消、超时、重试和完成通知。
• 共享状态：任务图、检查点、预算、权限、执行进度和版本。
• 业务工件：文档、代码、数据集、测试报告、引用清单等可持久化结果。

长内容最好存入对象存储、数据库或文件系统，消息只传递引用、摘要和校验信息。Anthropic 在多 Agent Research 系统中也建议让子 Agent 直接把大型结果写入文件系统，再向协调器返回轻量引用，以减少“传话游戏”造成的信息损失和 token 开销。

图 3：MCP 主要标准化 Agent 与工具、数据和资源的连接；A2A 主要标准化独立 Agent 之间的发现、任务和工件交换。

MCP 解决 Agent 如何连接工具和数据

MCP（Model Context Protocol，模型上下文协议）是连接 AI 应用与外部系统的开放标准。MCP Server 可以暴露工具、资源和提示模板，使 Agent 以统一方式访问文件、数据库、搜索、GitHub 或企业系统。

它关注的是“Agent 怎样获得能力”，不是完整定义两个独立 Agent 如何协商任务。

A2A 解决独立 Agent 如何互操作

A2A（Agent2Agent Protocol）面向可能由不同语言、框架或厂商实现的独立 Agent。它提供能力发现、消息、任务生命周期、流式更新、异步订阅和 Artifact 交换等机制。A2A 官方规范强调，其目标是让相互独立、内部实现可以保持不透明的 Agent 建立共同交互模型。

A2A 并不替代企业内部编排器，也不自动解决身份、授权、数据分类和业务事务。跨边界调用时，仍要给每个远程 Agent 建立服务身份、最小权限、超时、配额、审计和数据出境策略。

对比项	MCP	A2A
主要关系	Agent/AI 应用 ↔ 工具与数据	Agent ↔ Agent
核心对象	Tools、Resources、Prompts	Agent Card、Message、Task、Artifact
典型用途	接数据库、文件、搜索、业务 API	跨团队、跨语言、跨厂商委派任务
是否负责业务编排	否	提供交互协议，但不替代业务编排
可以组合吗	可以，Agent 通过 MCP 用工具，再通过 A2A 对外协作	可以

五、2026 年主流多 Agent 技术框架有哪些

截至 2026 年 7 月，多 Agent 技术栈已经分成三类：代码编排框架、轻量 Agent SDK 和云端托管平台。它们解决的问题并不相同，不能只按 GitHub Star 或示例代码长短选型。

框架或平台	当前定位	主要多 Agent 能力	更适合
LangGraph / LangChain	状态图运行时 + Agent 生态	子 Agent、Handoff、路由、自定义图、检查点、人工中断	需要显式状态、复杂分支和可恢复执行
Microsoft Agent Framework	AutoGen 与 Semantic Kernel 经验汇合后的生产框架	串行、并行、Handoff、Group Chat、Magentic、HITL	.NET/Python、微软生态、企业治理
Google ADK	开源、代码优先、模型与部署相对解耦	LLM Agent、Sequential/Parallel/Loop、层级 Agent、A2A	Gemini/Google Cloud，也需跨框架协作
OpenAI Agents SDK	轻量 Python SDK	Agent as Tool、Handoff、代码/LLM 编排、Guardrails、Tracing	OpenAI 技术栈、希望少抽象快速开发
CrewAI	角色化 Crew + 事件驱动 Flow	Agent、Task、Crew、Flow、委派与企业部署	业务自动化、快速搭建角色团队
Amazon Bedrock Agents	托管式多 Agent 协作能力	Supervisor、Routing、追踪、权限与云上部署	AWS 企业、希望减少运行基础设施建设

LangGraph：适合把多 Agent 当作有状态程序

LangGraph 是低层编排运行时，强调 durable execution、持久化、流式执行和 human-in-the-loop。团队可以把 Agent、工具、验证器和人工节点建成图，并在节点边界保存检查点；这对长任务、失败恢复和人工审批尤其重要。

它的优势是控制力强，代价是团队必须自己设计状态 Schema、路由、错误策略和图结构。若只是简单路由，使用更高层的 LangChain Agent 或单 Agent 往往更合适。

Microsoft Agent Framework：新项目不应再默认从 AutoGen 开始

AutoGen 对多 Agent 研究和社区普及影响很大，但其官方仓库已明确进入维护模式，并建议新项目使用 Microsoft Agent Framework。后者面向 Python 和 .NET，支持顺序、并行、Handoff、Group Chat 与 Magentic 等模式，并加入检查点、可观测性和人工介入能力。

这意味着技术文章仍可以用 AutoGen 解释多 Agent 历史与经典模式，但企业的新项目选型应评估 Microsoft Agent Framework 的长期支持和迁移路线。

Google ADK：层级 Agent、工作流 Agent 与 A2A 结合

Google Agent Development Kit（ADK）提供 LlmAgent、SequentialAgent、ParallelAgent、LoopAgent 等构件，可通过父子 Agent 形成层级结构，并能与 A2A 远程 Agent 集成。它强调代码优先、可评测、可部署，也支持 MCP 工具和人工确认。

ADK 适合希望把固定工作流 Agent 与动态 LLM Agent 组合起来的团队；如果需要跨语言、跨组织协作，可在内部 ADK 编排之外使用 A2A 暴露远程能力。

OpenAI Agents SDK：用少量原语表达管理者和转接模式

OpenAI Agents SDK 的核心原语较少：Agent、Tool、Handoff、Guardrail、Runner 和 Trace。管理者可以把专业 Agent 暴露为工具并保留最终回答权，也可以通过 Handoff 把会话转给专业 Agent。对于需要精确控制的流程，官方建议直接使用 Python 编排串行、并行和评审循环。

CrewAI：用 Crew 组织角色，用 Flow 控制业务过程

CrewAI 把专业 Agent 和任务组织为 Crew，同时用 Flow 表达事件驱动、可控的业务路径。这种抽象对市场调研、内容生产和运营自动化比较直观；进入生产时仍需重点补齐状态恢复、幂等、评测、权限和全链路观测。

Amazon Bedrock Agents：云端托管的 Supervisor 协作

Amazon Bedrock 多 Agent 协作支持 Supervisor 和 Supervisor with Routing 两种模式，负责子任务委派、执行跟踪和结果聚合，并与 AWS 的监控与部署体系结合。它适合已经采用 AWS、希望以托管方式建设多 Agent 的企业，但会增加对特定云服务和计费模型的依赖。

六、哪些场景适合多 Agent，哪些不适合

判断是否需要多 Agent，可以先问四个问题：

1. 子任务是否能够独立执行和独立验收？
2. 子任务是否可以并行，或需要明显不同的工具、权限和上下文？
3. 单 Agent 是否已经因为上下文过大、工具过多或职责过宽而不稳定？
4. 任务价值是否足以覆盖额外模型调用、编排和治理成本？

四个问题多数回答“是”，多 Agent 才值得进入方案设计。

适合多 Agent 的典型场景

复杂研究与情报分析。 不同 Agent 并行搜索市场、技术、政策和风险，最后进行证据去重和引用核验。任务天然可以横向拆分，且信息量可能超过单个上下文窗口。

软件研发与质量评审。 规划、实现、测试、安全审查和文档可以由不同 Agent 承担，但主流程必须由代码仓库、测试和 CI 作为共享事实源。不是所有编码任务都适合多 Agent；模块高度耦合时，协调开销可能大于收益。

跨部门业务流程。 销售、法务、财务和交付 Agent 分别访问不同数据和工具，通过审批与事件驱动完成报价、合同和履约协同。这里的价值主要来自权限隔离和专业边界，而不只是并行。

供应链与运营决策。 需求预测、库存、定价、物流和风险 Agent 分别分析局部问题，由协调器综合建议，并在关键动作前引入人工审批。

客服与内部服务台。 分诊 Agent 将订单、退款、技术、安全问题转给专业 Agent。若请求涉及多个领域，主管 Agent 可以协调多个专业结果后再统一回复。

不适合多 Agent 的场景

• 流程固定、规则清楚，传统工作流或 RPA 已能稳定完成；
• 所有步骤都依赖同一份巨大上下文，无法有效隔离；
• 子任务强串行，几乎没有并行收益；
• 结果缺少客观验收标准，只能让多个模型互相“认可”；
• 单次任务价值低，却需要多轮模型调用；
• 涉及不可逆高风险动作，但尚未建立权限、审批和审计机制。

七、多 Agent 的优势和劣势是什么

多 Agent 的主要优势

专业化。 每个 Agent 只保留必要工具和领域提示词，减少一个 Agent 面对几十种工具时的选择混乱。

上下文隔离。 子 Agent 在独立窗口中处理局部证据，再把压缩结果交回主 Agent，能够延缓上下文膨胀。

并行扩展。 可独立的搜索、仿真和分析可以并行执行，以更多计算换取覆盖面和速度。

权限隔离。 财务 Agent、法务 Agent 和运维 Agent 可以使用不同身份和工具白名单，降低单个 Agent 的权限半径。

组织协作。 不同团队可以维护各自 Agent、工具和评测集，通过稳定协议组合，而不必共享同一套内部实现。

多 Agent 的主要劣势

成本显著增加。 Anthropic 披露，其多 Agent Research 系统在内部研究评测中相对单 Agent 提升了 90.2%，但多 Agent 的 token 使用量约为普通聊天的 15 倍。该数字来自特定模型、任务和内部评测，不能直接外推到所有业务。

错误会复合传播。 分解、路由、执行、交接和聚合中的任一错误，都可能改变后续轨迹。增加 Agent 数量也增加故障点。

延迟与长尾。 并行系统的完成时间往往由最慢子任务决定；串行系统则累加每一步延迟。

调试更困难。 相同输入可能形成不同任务图和消息路径，需要跨 Agent Trace、事件时间线和工件版本才能还原问题。

评测更复杂。 不能只看最终回答，还要评估分解覆盖率、路由准确率、重复劳动率、交接完整性、聚合质量、成本和失败恢复。

安全边界增多。 一个 Agent 接收到的恶意内容可能通过摘要或工件传播给其他 Agent；跨 Agent 的信任不能默认继承。

八、公开的多 Agent 真实案例有哪些

案例一：Anthropic Research 的主管—执行者架构

Anthropic 的 Research 功能是已经进入产品的多 Agent 系统。Lead Agent 根据用户问题制定研究策略，并行创建专业 Subagent；子 Agent 独立搜索和分析，将结果交回 Lead Agent；主 Agent 判断是否继续研究，最后由 Citation Agent 对报告和来源进行引用定位。

这一案例最重要的不是“用了多少 Agent”，而是四项工程经验：

1. 子任务必须写清目标、边界、来源偏好和输出格式，否则会重复搜索或遗漏。
2. 简单问题少分派，复杂问题才扩大 Agent 和工具调用预算。
3. 中间成果保存为可引用工件，避免长文本在层层转述中损失。
4. 用任务终态和证据质量评估结果，而不是要求每次都走同一路径。

Anthropic 报告称，并行化改造使复杂研究任务的时间最多缩短 90%；这同样是其特定系统的工程数据，应理解为架构案例，而不是行业通用承诺。

案例二：Syngenta Cropwise AI 的农业专业 Agent 协作

AWS 公开的 Syngenta Cropwise AI 案例中，多 Agent 系统把数据聚合、农业建议和多语言交互拆给不同专业 Agent。数据聚合 Agent 整合长期天气、土壤和作物生长数据；推荐 Agent 生成种子、投入品和病虫害策略；对话 Agent 把结果转化为用户可理解的自然语言。

AWS 披露，该系统使用超过 20 年的天气历史和 8 万多条作物生长阶段观察；基于 Syngenta 的种子推荐模型，Cropwise AI 帮助种植者把产量提高最多 5%。这些结果来自厂商与客户案例，适用范围受地区、作物、数据和模型条件限制。

这个案例说明，多 Agent 在企业中的真实价值往往来自三点：专业数据边界、差异化模型或工具、以及结果最终进入具体业务决策，而不是让多个通用大模型讨论同一个问题。

九、企业怎样建设可生产运行的多 Agent 系统

图 4：企业应先验证单 Agent 基线，再按任务边界拆分；运行时统一控制状态、权限、预算、评测和人工审批。

第一步：先建立单 Agent 基线

用单 Agent 或确定性工作流完成同一任务，记录任务成功率、质量、P95 延迟、token、工具调用和人工接管率。没有基线，就无法证明多 Agent 增加的复杂度是否带来真实收益。

第二步：按“能力与上下文边界”拆分，而不是按部门名称拆分

一个好 Agent 边界应满足：输入明确、工具有限、输出可验证、失败可局部恢复。不要简单复制组织架构，也不要创建“负责一切”的主管 Agent。

第三步：为交接和工件建立统一 Schema

统一任务信封、状态枚举、错误码、证据引用和工件版本。自然语言可以用于解释，但不能成为唯一控制协议。大型结果放到共享工件库，消息只传引用和摘要。

第四步：让代码控制预算、权限和停止条件

最大 Agent 数、最大深度、最大轮次、token、费用、超时、可调用工具和高风险审批都应由运行时执行。模型可以建议扩展任务，但不能自行突破预算和权限。

第五步：建立跨 Agent Trace 与评测

每次运行都应还原：

• 总任务如何分解，为什么选择某个 Agent；
• 每个 Agent 获得了哪些上下文、工具和权限；
• 产生了哪些消息、工件和业务副作用；
• 哪一步重试、超时、降级或转人工；
• 最终结果由什么规则、测试或回执验收。

在这一层，云程智能体开发平台可以统一承接 Agent、工作流、RAG、Skill、MCP 工具和模型配置，并把任务状态、人工审批、链路追踪与评测放进同一治理闭环。平台的价值不是自动把单 Agent 变成“智能体团队”，而是让角色、协议、权限、运行状态和质量证据可以被持续管理。

第六步：用影子模式逐步扩大自主权

先让多 Agent 只生成建议，与人工或原流程结果对比；通过离线评测后，再开放低风险读取和可回滚写入；高风险动作长期保留审批、双重验证和补偿机制。

多 Agent 应重点评估哪些指标

指标	回答的问题
端到端任务成功率	系统是否真正完成业务目标
分解覆盖率	子任务是否覆盖所有必要工作
路由准确率	是否选择了正确专业 Agent
重复劳动率	多个 Agent 是否做了相同工作
交接完整率	目标、证据、状态和未决问题是否完整
聚合正确率	最终结果是否正确合并并处理冲突
恢复成功率	子 Agent 失败后能否从检查点继续
单任务成本与 P95 延迟	额外质量是否值得额外资源
人工接管率	系统在哪些边界仍需要人
安全事件与越权率	权限和信任边界是否有效

十、关于多 Agent 的常见问题

1. 多 Agent 一定比单 Agent 效果好吗

不一定。任务可并行、专业边界清晰、上下文可隔离时，多 Agent 可能提高覆盖面和质量；任务依赖紧密或价值较低时，它通常只会增加成本、延迟和故障点。

2. 两个大模型互相评审就算多 Agent 吗

可以称为最简单的多 Agent 模式，但只有在评审标准、输出契约和停止条件明确时才有工程价值。让两个模型无限互相修改，既不能保证正确，也容易形成高成本循环。

3. 多 Agent 应该共享同一个上下文吗

通常不应完整共享。每个 Agent 应获得完成当前子任务所需的最小上下文，共享事实放在状态库或工件库中，通过引用和摘要传递。只有必须共同理解的目标、约束和验收标准才需要同步。

4. MCP 能不能替代 A2A

不能直接替代。MCP 主要连接 Agent 与工具、数据和资源；A2A 主要连接独立 Agent，并管理能力发现、消息、任务和工件。两者可以在同一系统中组合使用。

5. AutoGen 现在还适合新项目吗

AutoGen 适合学习多 Agent 模式和维护现有项目，但其官方仓库已进入维护模式。新项目应优先评估 Microsoft Agent Framework，并结合团队语言、云平台和迁移成本做决定。

6. 多 Agent 系统怎样控制成本

先用单 Agent 基线证明问题，再设置按任务复杂度动态分派、最大 Agent 数、最大深度、token 和工具预算；简单请求直接路由给单个专业 Agent，只有高价值复杂任务才启动并行团队。

7. 多 Agent 最容易忽视的安全问题是什么

最容易忽视的是“信任传递”。来自外部网页、文件或远程 Agent 的内容不能因为被另一个 Agent 摘要后就自动可信；每次跨边界交接都应保留来源、身份、权限和内容分类，并在工具执行层重新鉴权。

十一、如果只记住五句话

1. 多 Agent 是多个独立决策单元在统一运行时中协作，不是多个角色自由聊天。
2. 只有任务可拆分、可并行、上下文可隔离且子结果可验收时，多 Agent 才可能优于单 Agent。
3. MCP 连接 Agent 与工具，A2A 连接独立 Agent；协议不能替代业务编排、权限和治理。
4. 框架选型应看状态持久化、交接契约、人工介入、追踪、评测和部署，而不是只看示例是否容易运行。
5. 企业应从单 Agent 基线开始，用可量化收益证明拆分价值，再逐步扩大多 Agent 的自主权。