近期关于AI Agent的讨论中，一个术语频繁出现：A2A（Agent-to-Agent，即智能体间通信协议）。不少人将其视为“智能体协作的下一代标准”，仿佛只要引入A2A，企业的多智能体系统就能瞬间打通任督二脉，实现高效协同。

然而，冷静审视后会发现，这套看似宏大的叙事，是否有些过度复杂化了？

事实上，过去一个系统调用另一个系统，我们称之为API调用；一个服务将任务委托给另一个服务，称为RPC；一个耗时任务需要查询进度，我们返回一个 task_id；一个服务需要向调用方持续推送结果，我们使用SSE、WebSocket或消息队列。这些工程实践已稳定运行十余年，可靠且成熟。

如今，只要调用链路两端都接入了大模型，这些原本成熟的操作似乎突然需要一套更宏大的语言：它们不再是服务，而是智能体；不再是接口调用，而是智能体协作；不再是任务状态，而是智能体间的长期委托；不再是服务发现，而是智能体发现（Agent Discovery）。最终，我们得到了一套全新的Agent-to-Agent协议，即A2A。

A2A的设计确实完整。它定义了Agent Card（智能体名片）、Skill（技能）、Message（消息）、Task（任务）、Artifact（产物）、流式更新、任务状态和认证方式，仿佛为“智能体社会”准备了一整套外交制度。

但问题在于：今天绝大多数所谓的智能体，真的已经发展到需要外交协议的地步了吗？

核心判断是：对于绝大多数企业级智能体系统，Agent不需要A2A。它们需要的是稳定的接口、确定性的编排、清晰的状态管理，以及一套已经被软件工程验证过的服务治理体系。

A2A并非完全没有价值，而是它试图标准化的场景，远没有行业宣传中那么普遍。许多团队引入A2A，并非因为现有技术无法解决问题，而是因为“两个智能体在通信”听起来比“一个服务调用另一个服务”更符合AI原生架构的想象。

这很像给公司里的每一个部门都发放一本外交护照。部门之间确实需要沟通，但未必需要建立联合国。

智能体首先是软件，其次才是智能体

讨论A2A之前，必须先回答一个经常被忽略的问题：什么是智能体？

一个典型的智能体可能包含大模型、提示词（Prompt）、工具调用、短期记忆、长期记忆、规划器、工作流和若干业务规则。它可以根据输入判断下一步动作，也可能在执行过程中进行多轮推理。

但这些特征描述的是它的内部实现，而非它对外暴露的接口形式。

假设有一个市场研究智能体。它收到一个行业名称，搜索公开信息，调用内部数据库，分析竞争格局，最后生成一份报告。从它自身的视角看，它可能是一个复杂的自主智能体：

理解任务 → 制定检索计划 → 调用搜索工具 → 提取竞争对手 → 补充行业数据 → 生成报告 → 自我检查

但从调用方的视角看，它完全可以只是一个接口：

report = research_agent(
    topic="AI survey software",
    depth="deep",
    output_format="markdown"
)

调用方通常不需要知道它内部使用了几个模型、执行了几轮反思、是否建立了计划，也不需要知道它究竟算不算“真正的智能体”。调用方真正关心的是：输入是什么，输出是什么，什么时候完成，失败后怎么重试，是否具有幂等性，消耗了多少资源，以及出现问题时如何追踪。这正是软件接口一直在解决的问题。

因此，智能体是否具有自主性，并不能自动推出“它需要一套新的通信协议”。内部复杂性，不等于外部必须复杂。

将智能体视为工具（Agent as Tool）已覆盖大多数协作场景

A2A的支持者经常强调，工具与智能体不一样。工具通常是确定性的，而智能体具有自主性；工具执行一次明确的操作，而智能体可能自主规划多个步骤；工具返回一个结果，而智能体可能要求补充信息、持续更新任务状态，甚至在较长时间后才完成工作。

这些区别在概念层面成立，但它们没有改变接口设计的基本事实。一个接口背后可以是一行代码，也可以是一个运行数小时的工作流。接口并不要求实现简单，也不要求实现确定。

例如，下面这个工具定义看起来很普通：

{
  "name": "generate_market_report",
  "description": "Generate a market research report",
  "inputSchema": {
    "type": "object",
    "properties": {
      "topic": { "type": "string" },
      "depth": { "type": "string", "enum": ["brief", "standard", "deep"] }
    },
    "required": ["topic"]
  }
}

它背后的实现可以是一个简单函数，也可以是一个具备规划、搜索、反思和多轮工具调用能力的智能体。对于主控智能体来说，这种区别并不重要。主控智能体只需要判断：当前任务是否适合调用 generate_market_report，应该传入什么参数，以及如何处理返回结果。这就是Agent as Tool（智能体即工具）的思想。

有人会认为，把智能体描述为工具是对其自主性的降维。实际上，这是一种非常有价值的工程抽象。一个系统越复杂，越应该在边界处隐藏内部细节。把远程智能体封装成工具，不是说它内部没有自主性，而是说它的自主性不应该泄漏到整个系统。

Task、Artifact 和 Agent Card 并非全新的计算原语

A2A最具代表性的几个概念是Task（任务）、Artifact（产物）和Agent Card（智能体名片）。这些概念确实清晰，但换一个熟悉的软件工程词汇就会发现，它们并不陌生。

这并不是说A2A的抽象没有意义。统一术语本身可以产生价值，但术语统一与必要性是两回事。

假设一个研究任务需要运行二十分钟。服务端可以立即返回：

{
  "task_id": "task_20260724_001",
  "status": "working"
}

调用方随后轮询：GET /tasks/task_20260724_001，或者通过SSE订阅：GET /tasks/task_20260724_001/events。任务完成后返回：

{
  "task_id": "task_20260724_001",
  "status": "completed",
  "result": { "report_url": "https://example.com/report.md" }
}

这已经覆盖了A2A中Task、状态更新和Artifact的核心语义。

多轮交互也并非A2A的专属能力

A2A的另一个卖点是智能体之间可以进行多轮交互。例如，一个旅行智能体委托酒店智能体预订房间，酒店智能体发现用户没有提供入住人数，于是将任务状态设为 INPUT_REQUIRED，要求调用方补充信息。

这听起来很智能体，但在工程上仍然是一个普通的中断恢复流程。服务端可以返回：

{
  "task_id": "booking_001",
  "status": "input_required",
  "required_fields": [
    { "name": "guest_count", "type": "integer", "description": "Number of guests" }
  ]
}

调用方补充信息：{ "task_id": "booking_001", "input": { "guest_count": 2 } }。这既可以通过普通REST API实现，也可以通过MCP Tool的结构化响应实现，还可以放入工作流引擎的Human-in-the-loop节点。

换句话说，A2A为复杂任务准备了一套漂亮的语法，但生产系统真正需要解决的是语义。

不要把编排问题误写成通信问题

支持A2A的一个重要观点是：MCP（Model Context Protocol）主要面向工具使用，却没有解决多智能体编排问题。这个观察是对的，但结论未必成立。

MCP的确不负责完整的多智能体编排。可是，A2A同样不应该负责业务编排。通信协议负责定义消息如何传递，编排系统负责决定谁先执行、谁后执行、失败后如何补偿、哪些步骤可以并行，以及哪些决策必须由确定性规则控制。这两者不应混为一谈。

例如，一个内容生产系统包含以下节点：选题分析 → 资料检索 → 文章生成 → 事实检查 → 风格审校 → 发布审批。这些节点背后可以分别由不同智能体实现，但它们之间的顺序不是一个开放式对话问题，而是一个工作流问题。

A2A可以成为节点之间的一种传输方式，却不能替代编排。把它描述为多智能体编排的答案，很容易再次犯下一个常见错误：把DAG的确定性调度理解成让LLM决定执行顺序。真正成熟的智能体架构，不是让智能体获得更多发言权，而是明确哪些地方允许它发言。

服务发现并非智能体的核心竞争力

A2A相对独特的能力是Agent Card（智能体名片）和Agent Discovery（智能体发现）。一个智能体可以公开自己的名称、说明、技能、输入输出形式、认证要求和服务地址。其他智能体获取Agent Card后，可以判断它是否适合当前任务。这看起来像一个开放的智能体市场：智能体可以像人在招聘网站上阅读简历一样，动态寻找合作者。

这是一个很有想象力的场景。问题是，绝大多数企业系统并不希望智能体在互联网上自由寻找合作伙伴。

在这种情况下，企业需要的不是开放式智能体发现，而是一个受治理的服务目录。这个目录完全可以由API Gateway、服务注册中心、内部工具市场、配置中心或者MCP Server Registry来实现。能力元数据也可以使用JSON Schema、OpenAPI扩展字段或内部标签描述。当所有远程智能体最终都必须预先注册并经过审批时，开放发现带来的价值会大幅下降。它最后仍然会变成一个服务注册中心，只是字段名称更智能体化。

A2A会制造第二套状态和治理体系

引入一套协议的成本，从来不只是安装一个SDK。当系统同时使用MCP和A2A时，团队需要维护两套概念模型。MCP中有Tool、Resource、Prompt和Session；A2A中有Agent、Skill、Message、Task、Context和Artifact。二者之间存在重叠，却不是完全一一对应。

于是，工程团队开始编写适配层：MCP Tool Call → 转换为A2A Message → 创建A2A Task → 接收TaskStatusUpdateEvent → 转换为MCP Progress Notification → 把Artifact转换为Tool Result。真正棘手的不是字段转换，而是语义转换。

技术架构有一个朴素规律：每增加一个抽象层，系统就会多一种失败方式。只有当新增抽象带来的收益明显高于其长期维护成本时，这一层才值得存在。对于多数内部智能体系统，A2A提供的能力可以通过现有API、MCP、任务系统和工作流引擎组合完成。此时再增加A2A，往往只是把原来的一种失败方式变成两种。

大多数“多智能体”其实只是一个应用里的多个模块

多智能体系统经常被画成一群拥有不同职业的数字员工：研究智能体负责找资料，分析智能体负责总结，写作智能体负责生成文章，审校智能体负责检查质量，管理智能体负责协调全局。从产品演示上看，它们像一个虚拟团队。但从工程实现上看，它们通常属于同一个代码仓库、共享同一个数据库、运行在同一个Kubernetes集群，甚至由同一个进程中的几个Python对象组成。

在这种场景下使用A2A，就像同一个函数里的两个对象为了交换一个字典，先分别部署成服务器，再通过标准外交电文进行沟通。系统确实变得更“分布式”了，但业务能力没有因此增强。对于同进程智能体，直接函数调用最简单。对于跨进程但同一团队管理的智能体，普通HTTP、gRPC、消息队列或MCP通常已经可以满足需求。

A2A最大的问题不是做不到，而是做得太早

A2A并不是一个糟糕的协议。恰恰相反，它的问题可能是设计得太完整，也太超前。它预设了一个未来：大量独立智能体由不同组织提供，拥有不同框架和模型，通过公开能力描述发现彼此，协商任务，持续交换状态，并交付结构化成果。在这样的未来里，A2A很有意义。它有点像互联网早期的电子邮件协议。只要不同组织都遵守同一个标准，彼此就可以通信，而不需要关心对方内部使用什么系统。

但今天的智能体生态距离这个未来仍然很远。当前多数智能体的能力描述缺乏稳定性。同一个智能体换一个提示词、一个模型版本或者一组工具，行为就可能发生明显变化。技能（Skill）的语义也难以像传统API那样精确定义。“市场分析”“深度研究”“制定策略”都不是可以仅靠JSON Schema完整描述的确定性能力。更关键的是，企业还没有解决如何评估一个外部智能体是否可信、是否稳定、是否会泄露数据，以及输出质量是否达到业务标准。在能力、评测、责任和信任机制都不成熟时，优先标准化智能体之间如何互相发送消息，很可能是在给一座还没建成的城市设计国际机场。

MCP也不是唯一答案

认为智能体不需要A2A，并不意味着所有智能体都必须使用MCP。MCP同样不是万能协议。对于简单的内部调用，函数接口可能比MCP更合适；对于高吞吐低延迟服务，gRPC可能更合适；对于可靠的长任务，Temporal或消息队列可能更合适；对于固定业务流程，DAG和状态机可能比任何智能体协议都更重要。

真正应该坚持的不是“MCP战胜A2A”，而是：不要因为参与通信的是智能体，就假设传统软件工程已经失效。协议选择应该由问题决定，而不是由参与者的名字决定。当一个智能体被封装成稳定能力时，它可以是一个函数、一个HTTP API、一个MCP Tool，也可以是一个异步Job。只有在普通接口明显无法表达业务需求时，才需要进一步考虑A2A。这比从“这是两个智能体”直接推导出“它们应该使用Agent-to-Agent Protocol”更加可靠。

哪些情况下A2A才真正值得使用

A2A的价值主要出现在以下特征同时存在时：

• 系统需要调用由其他公司或独立团队运营的智能体。
• 调用方无法控制远程智能体的内部实现和升级节奏。
• 任务可能持续较长时间，并且存在补充输入、认证中断和异步恢复。
• 远程智能体不只是执行一个窄工具，而是接受目标后自主完成一整段工作。
• 不同智能体框架之间需要共享统一的任务和结果语义。
• 生态中已经形成足够多的A2A服务，使用标准协议的收益高于维护适配层的成本。

在这种真正跨组织、跨信任域的协作中，A2A的Agent Card、Task、Artifact、认证和状态模型可以减少重复集成工作。此时，A2A不是为了让几个Python对象互相聊天，而是在尝试建立一种跨企业的智能体服务契约。

一个更务实的技术选型顺序

面对智能体之间的调用需求，可以按照由简单到复杂的顺序选择方案。

• 首先判断是否可以使用函数调用。如果两个智能体运行在同一进程，函数或统一接口通常已经足够。
• 其次判断是否可以作为普通服务。跨进程或跨语言时，HTTP、gRPC和消息队列拥有成熟的治理、监控和部署体系。
• 然后判断是否适合建模为工具。主控智能体只需要调用对方的一项能力时，可以将远程智能体封装为MCP Tool或Function Tool。
• 如果任务耗时较长，则增加任务ID、状态查询、Webhook、SSE或工作流引擎，而不是立即更换整个协议栈。

最后，只有当系统确实涉及跨组织智能体协作、开放能力发现和统一任务语义时，再考虑A2A。这个顺序背后的原则是：

Function → Service API → Tool Protocol → Asynchronous Task → Cross-organization Agent Protocol

复杂性应该随着业务边界逐步增加，而不是因为代码里出现了 Agent 这个类名，就直接跳到最后一层。

先把智能体做成好服务，再考虑让它参与协议

A2A描绘了一个迷人的未来：不同组织、不同模型和不同框架构建的智能体，可以像互联网服务一样自由发现、委托任务和交换成果。这个未来可能会到来。但在那之前，大多数智能体团队面对的现实问题不是“如何让全球智能体互联”。

在这些基础问题没有解决之前，引入A2A，就像一家只有三名员工的创业公司，先制定了一套跨国并购流程。流程很专业，只是暂时用不上。

所以，“智能体不需要A2A”并不是说A2A永远没有价值，而是强调一个更朴素的工程判断：智能体并不会因为具有自主性，就脱离软件系统的基本规律。能用函数解决的问题，不要先部署服务；能用服务解决的问题，不要先发明协议；能把智能体当作工具调用，就不要急着让它们建立外交关系。