AgentScope 2.0 A2A 协议实战：用 Nacos 构建动态智能体协作网络

一个月前我在内部做了一轮技术分享，主题只有一个：当你的智能体框架开始支持 A2A 协议，服务注册中心 Nacos 到底能帮上什么忙。台下有人问了一句：AgentScope 不是已经有自己的多智能体消息传递机制了吗，为什么还要把 A2A 和 Nacos 引进来？这个问题其实问到了点子上——单个框架内的多智能体协作，和开放生态下的跨框架智能体协作，是两码事。本文就从 AgentScope 2.0 的 A2A 模式讲起，聊聊我们是怎么用 Nacos 把多个 Agent 服务串成一张可动态发现的协作网络。

1. 智能体之间为什么需要 A2A：没有“通用语”之前的协作乱象

1.1 MCP 解决的是“智能体找工具”，不是“智能体找智能体”

过去两年大家聊得最多的协议是 MCP（Model Context Protocol），它的价值在于把工具调用标准化：智能体不需要为每个 API 写一套适配层，统一走 MCP 协议就能访问文件、数据库、第三方服务。但 MCP 的边界很清晰，它描述的是“智能体 -> 工具”这条单向链路。

真正做多智能体系统的时候你会发现，卡脖子的问题不在工具接入，而在智能体与智能体之间怎么互相发现、怎么下发任务、怎么传结果。每个框架都有自己的内部消息格式，AgentScope 的消息是 Message 对象，LangGraph 用的 graph state，AutoGen 走的是 ConversableAgent 的对话流。框架内部跑得再顺，出了框架边界大家都只能说“方言”，没法互通。

我们早期做过一个跨团队的协作场景，A 组用 AgentScope 做了个售前咨询智能体，B 组用自研框架做了个库存查询智能体，两边要协作就得靠人工对接口：A 组给我们拉一个 HTTP 接口文档，我们写调用代码，参数一变又要重新联调。这不叫智能体协作，这叫手工对接。

1.2 A2A 的核心抽象：Agent Card、Task、Artifact

A2A（Agent2Agent）协议要解决的就是这个互操作问题。它把每个智能体看作一个可通过 HTTP 访问的服务，定义了三个核心抽象：

协议的底层传输是 JSON-RPC over HTTP，所以只要你的 Agent 能暴露一个 HTTP 端点，就能接入 A2A 生态，跟你内部用什么框架、什么语言没有关系。Task 的状态机非常明确：submitted -> working -> input-required -> completed / failed / canceled，这让调用方可以稳定地轮询或接收回调，不用猜对方的执行进度。

当初看到这套抽象的时候我最大的感受是：它没有试图去规定“智能体内部该怎么思考”，只管“外部怎么协作”。这个克制感很重要。业界已经有很多血的教训，协议一旦管到内部实现，大家就不愿意接了。

1.3 AgentScope 2.0 对 A2A 的定位：不做封闭平台，做开放协议

AgentScope 本身是个产研落地向的多智能体框架，2.0 最大的变化之一就是原生支持 A2A 模式。它没有把智能体锁在自己的通信层里，而是让你既可以把 Agent 发布成一个符合 A2A 规范的服务端，也可以作为客户端去调用其他符合 A2A 规范的智能体。

这样布局的意义在于：AgentScope 不只是给自己生态里的智能体用，而是能够和 Google 的 GenAI Agents、Salesforce、以及各种支持 A2A 的平台直接互通。对做平台的同学来说，这是个好消息——你不用再为每个上游框架写一次适配，协议兼容一次，后续全通。

2. AgentScope 2.0 的 A2A 实现是怎么落地的

2.1 服务端视角：把任意 Agent 暴露成 A2A 服务

在 AgentScope 2.0 里