Skip to main content

多智能体怎么分工

单个 Agent 变大之后会遇到一个很具体的问题：工具越来越多，系统提示词越来越长，每轮请求的上下文里塞着几十个工具定义，而其中大部分这次根本用不上。

先别急着拆。 这个问题现在有机制解：tool search / deferred loading——工具定义不一次性塞进上下文，而是按需检索加载（Anthropic 侧单请求可以 defer 上万个工具，官方给出的数据是 token 大降、选择准确率反而上升）。拆系统是有代价的：多一层网络、多一份状态、多一种失败模式。

真的需要拆（工具归属不同团队、权限边界不同、上下文确实放不下），才会遇到下一个问题——它们怎么互相说话。

A2A（Agent2Agent）就是为这件事定的标准。时间线要说全，否则容易误读成"某家公司的新协议"：Google 在 2025 年 6 月把 A2A 捐给了 Linux 基金会（中立化从那时就开始了）；2026 年 3 月 12 日发布 v1.0（第一个稳定版）；同年 8 月转入 Agentic AI Foundation（AAIF，2025 年 12 月成立），与 MCP 并列为该基金会下的项目。

总控 Agent研究 AgentMCP 接搜索报告 AgentMCP 接文档库执行 AgentMCP 接业务 API外部 Agent另一家组织A2A 横向Agent 之间怎么发现、委派、跟踪MCP 纵向每个 Agent 自己怎么连工具与数据两者不互相替代：常见的系统是 MCP 在 Agent 内、A2A 在 Agent 间
图：一个 Agent 内部用 MCP，Agent 之间用 A2A

1. 两个协议在两个层上​

这是最容易被混淆的地方，而且 v1.0 的官方博客专门澄清过一次：

MCPA2A
层级垂直整合层水平协作层
解决一个 Agent 怎么连自己的工具和数据不同 Agent 之间怎么发现、委派、交换结果
边界Agent 内部Agent 之间

它们不互相替代。 常见的系统是：每个 Agent 内部用 MCP 接工具，Agent 之间用 A2A 协作。

之所以要区分，是因为这两层的信任模型完全不同。给你的 Agent 接一个工具，你能控制它的实现和权限；让两个不同组织的 Agent 互相委派任务，你控制不了对方内部——所以 A2A 有一条原则叫 Opaque Execution（不透明执行）：Agent 之间只根据对方公开声明的能力协作，不需要也不应该打开对方的黑盒。

2. 核心对象​

2.1 Agent Card​

一份 JSON 元数据，由被调用方公开声明：我是谁、我有哪些技能、我的端点在哪、客户端该怎么验证我的身份。惯例是放在该 Agent 域名下的固定路径。

v1.0 相对 v0.3 的几个变化值得单独看，因为它们都指向生产环境：

  • endpoints 从单个字段变成数组，支持三种等价协议绑定（JSON-RPC 2.0 / gRPC / HTTP+JSON），由 supportedInterfaces 协商——不是"首选与降级"的关系，客户端按自己的能力挑一个
  • 可选签名，用密码学方式验证 Agent 身份与元数据
  • 原生多租户，一个端点可以安全地托管多个 Agent
  • 显式版本声明，且可以同时声明兼容 v0.3 与 v1.0，让客户端渐进迁移而不是一次性切换

签名这一条对应的是跨组织场景的真实需求：你打算把任务委派给一个你不控制的 Agent，至少要先确认"它是它声称的那个"。

2.2 Task、Message、Part​

一次协作围绕任务展开：客户端创建 Task，通过 Message 发送任务请求，跟踪 Task 状态变化，最后取回 Artifact（结果）。消息里的内容是 Part，可以带不同类型。

Task 这个抽象很关键——它意味着任务是长生命周期的对象，可以被查询、被跟踪、在断连后恢复。这跟"发一个 HTTP 请求等响应"的模型不一样。

2.3 结果怎么拿​

三种方式可选：轮询、流式、Webhook。按场景选，不是必须流式。

3. 一次协作的四个阶段​

发现 → 客户端拿到对方的 Agent Card 决策 → 解析卡片，判断对方是否具备需要的能力 委派 → 创建 Task，发送 Message 跟踪 → 监控 Task 状态，取回结果

工程上最容易出问题的是第二和第四阶段。

决策阶段的坑：卡片上写了技能名，不代表它的输入输出约定和你的一致。跨组织之前要先统一技能命名、输入输出格式、错误码——这属于你们自己的约定，协议不管。

跟踪阶段的坑：长任务必须可查询、可恢复。网络断了、进程重启了，任务状态不能丢。所以幂等重试和状态查询是必须实现的，不是可选优化。

4. 先问一句：真的要拆吗​

拆之前先看一遍《编排画布的适用边界》里那张需求分类表——如果"多智能体"只是想把流程画出来给人看，那是画布的需求，不是 A2A 的需求。A2A 解决的是运行时两个自治进程怎么对话，静态可视化一针一线都在本地。

多智能体是 2026 年最被过度使用的架构之一。拆之前值得先考虑不拆：

拆的代价是实的：

  • 每个 Agent 都要独立部署、独立观测、独立设权限
  • 跨 Agent 的调试难度显著上升——一个错误散在三个 trace 里
  • 错误会复合：一个 Agent 的幻觉变成另一个的输入（ASI08 级联失败，见《Agentic 的十类风险》）
  • 延迟叠加，成本叠加

值得拆的三个理由：

  • 职责确实不同：研究和写报告是两件事，混在一起会让系统提示词互相干扰
  • 信任边界不同：有的 Agent 能碰生产数据库，有的只能读公开文档——权限必须分开
  • 组织边界不同：不同团队、不同公司各自维护自己的 Agent

如果没有这三条里的任何一条，拆开通常只是把复杂度从一个地方搬到另一个地方。

5. 按什么维度拆​

三个可选维度，优先级从高到低：

按信任边界拆（最重要）。 能写生产的和只能读文档的，必须是不同的 Agent、不同的凭证。这个边界如果混在一起，一次注入就全暴露了。

按组织边界拆。 谁维护谁负责，也决定了谁能改它的提示词和工具。

按职责拆（最弱）。 只是"这两个任务不一样"通常不足以支撑一次拆分——同一个 Agent 用不同的工具集处理两类任务，往往就够了。

一个判断方法：如果两个 Agent 需要共享同一份记忆或同一套权限，它们大概不该被拆开。

6. 工程落地的五条​

  1. 先定 Agent Card 的规范——技能命名、输入输出约定、错误码统一。跨组织调用时，签名机制保证可信度
  2. 任务要可恢复——幂等重试 + 状态查询，长任务的必需品
  3. 协议协商用默认值——首选 HTTP+JSON，客户端不支持时降级 JSON-RPC
  4. 多租户前置——如果系统要服务多个团队或客户，从第一天就用 v1.0 的多租户能力，后加很痛苦
  5. 可观测性前置——记录 task id、调用链、耗时、失败原因。HTTP+JSON 绑定让标准 Web 观测工具可直接复用（见《给大模型链路装仪表》）

7. 多出来的风险面​

拆成多个 Agent 之后，攻击面从"一个 Agent 加它的工具"变成"N 个 Agent 加它们之间的通信"。多出来的主要是三条：

ASI07 不安全的 Agent 间通信。 消息被伪造、篡改、重放。多 Agent 工作流默认参与者互信，这个假设在攻击者能冒充其中一个时就崩了。缓解手段是消息认证与身份校验，而不是"我们内网很安全"。

ASI03 身份与权限滥用。 一个 Agent 持有所有分配给它的凭证的全部权限，成为权限聚合点；跨 Agent 的 confused-deputy 问题（A 让 B 做事，用的是 B 的权限）。

ASI08 级联失败。 误差沿管线累积且不会自动暴露。

对应的做法和单 Agent 时是同一套——最小代理权、独立身份、动作级审计、步数与预算上限——只是现在要按 Agent 逐个落实（见《护栏要做在基础设施层》）。

8. 什么时候用不上 A2A​

一个很实际的问题：如果你的多个 Agent 都在同一个进程里、同一个团队维护、同一套凭证，那么用进程内的函数调用就够了。

A2A 的价值在于跨边界——跨技术栈、跨团队、跨组织。在同一个代码库里给 Agent 之间套一层 HTTP 协议，通常只是给自己增加延迟和故障点。

反过来，如果确实要跨组织协作，自己发明一套接口协议的长期成本，远高于适配一个已经被八家公司（AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNow）的技术指导委员会维护的标准。

9. 清单​

  • 先确认有拆分理由（职责 / 信任边界 / 组织边界）
  • Agent Card 的命名与错误码先统一
  • Task 可查询、可恢复、幂等
  • 每个 Agent 独立身份与最小权限
  • Agent 间消息有认证，不依赖"内网可信"
  • trace 能跨 Agent 串起来（task id 贯通）
  • 级联失败的熔断：某个 Agent 挂了要有明确的失败，不是无限重试
  • 确认不是在同一个进程里硬套协议

最后一条值得再强调：多智能体不是默认更好的架构。它是一个在边界真实存在时才成立的架构。边界不存在时，它只是把简单的东西变复杂。