1. 为什么 Agent 通信协议突然成了热门话题如果你最近半年在关注 AI Agent 相关的开发会发现一个很有意思的现象几乎每隔几周就会冒出一个新的通信协议标准。MCP、A2A、ACP、ANP……名字一个比一个抽象文档一个比一个长但真正落到代码里很多人第一反应是——我直接用 HTTP 加 JSON 不就行了吗为什么还要搞这么多层这个问题我在实际做多 Agent 系统集成的时候被问过不下十次。刚开始我也觉得这些协议是过度设计直到我试着把一个本地工具调用 Agent、一个云端推理 Agent、一个企业内部知识库 Agent 串起来跑一个完整任务流才发现如果没有统一的通信约定光是字段命名和错误码对齐就能耗掉一整天。Agent 通信协议要解决的核心问题其实很朴素让不同的 Agent 能够互相理解对方在说什么、能做什么、需要什么。听起来简单但一旦涉及跨进程、跨网络、跨厂商、跨信任域复杂度就指数级上升。JSON-RPC 是最早被拿来用的方案因为它足够简单、足够通用但它在描述能力、流式传输、能力协商这些方面很快就碰到了天花板。于是 MCP 从工具调用切入A2A 从 Agent 间协作切入ACP 从消息语义切入各自试图在某个维度上做得更好。这篇文章适合三类人看一是正在做 Agent 系统架构、纠结选哪个协议的技术负责人二是写过简单 Agent 调用、想理解协议层设计逻辑的开发者三是被各种协议名词搞晕、想搞清楚它们之间到底什么关系的学习者。我会从实际使用角度出发把 JSON-RPC、MCP、A2A、ACP 这几条线串起来讲清楚包括它们各自解决什么问题、核心机制怎么运作、实际落地时要注意什么。2. 从 JSON-RPC 说起最朴素的 Agent 通信起点2.1 JSON-RPC 为什么会被 Agent 开发者选中JSON-RPC 本身不是为 Agent 设计的它是一个很古老的远程调用规范核心思想就一句话用 JSON 格式描述一次方法调用包含方法名、参数和请求 ID。2.0 版本规范定义了请求对象、响应对象和通知对象三种结构请求必须有jsonrpc、method、params、id四个字段响应必须有jsonrpc、result或error、id。Agent 开发者选它的理由很直接轻量、无状态、语言无关。你不需要引入 gRPC 那一套 protobuf 编译流程也不需要理解 REST 的资源语义只要双方约定好方法名和参数结构就能跑起来。我最早做的一个本地 Agent 调用链就是用 JSON-RPC over stdio 实现的主进程通过标准输入输出和子进程 Agent 通信代码量不到两百行。但用久了问题就暴露出来了。JSON-RPC 只规定了“怎么调用”没规定“调用什么”。方法名是自定义的参数结构是自定义的错误码也是自定义的。两个不同团队写的 Agent即使都用 JSON-RPC也没法直接互通因为一方叫get_weather另一方叫fetchWeatherInfo参数一个用city一个用location。这就像两个人都说中文但一个说方言一个说普通话沟通成本极高。2.2 JSON-RPC 在 Agent 场景下的三个硬伤第一个硬伤是能力描述缺失。JSON-RPC 没有内建的服务发现或能力声明机制。Agent A 想知道 Agent B 能做什么只能靠外部文档或者硬编码。在实际多 Agent 系统里Agent 是动态加入和退出的靠人工维护能力清单根本不现实。第二个硬伤是流式传输支持弱。大模型推理天然是流式的token 一个一个往外吐。JSON-RPC 的请求-响应模型是同步的虽然可以通过通知机制模拟流式但没有标准化的流式语义每个实现各搞一套互操作性很差。第三个硬伤是错误语义不统一。JSON-RPC 定义了错误码范围但 Agent 场景下的错误类型远比“方法不存在”“参数无效”复杂得多。工具调用超时、模型拒绝回答、权限不足、上下文超长这些都需要结构化的错误信息而 JSON-RPC 的 error 对象只有一个 code 和 message表达能力不够。实操心得如果你只是做单机、单团队、Agent 数量少于五个的简单场景JSON-RPC 完全够用不要为了追新而过度设计。但一旦涉及跨团队协作或者 Agent 动态注册就要考虑更上层的协议了。3. MCP从工具调用切入的标准化尝试3.1 MCP 的核心设计思路MCP 全称 Model Context Protocol它的切入点非常明确解决大模型如何标准化地调用外部工具和数据源。在 MCP 出现之前每个模型厂商都有自己的 function calling 格式OpenAI 一套、Anthropic 一套、开源模型又一套开发者要写适配层写到崩溃。MCP 试图做一层抽象让工具提供方只需要实现一次 MCP Server就能被所有支持 MCP 的客户端调用。MCP 的架构是典型的客户端-服务端模型。MCP Host 是运行大模型的宿主环境MCP Client 是 Host 内部负责和 Server 通信的组件MCP Server 是暴露工具能力的服务。通信层支持两种传输方式stdio 用于本地进程通信HTTP with SSE 用于远程通信。消息格式基于 JSON-RPC 2.0但在此基础上定义了标准化的方法集。MCP 定义了三类核心原语Tools可调用的函数、Resources可读取的数据、Prompts预定义的提示模板。Tools 是最常用的每个工具包含名称、描述和 JSON Schema 格式的输入参数定义。这个设计的好处是大模型可以直接读取工具描述和参数 schema自动生成符合格式的调用请求。3.2 MCP 的能力协商与生命周期MCP 相比裸 JSON-RPC 最大的进步是引入了能力协商机制。客户端和服务端在连接建立时会交换各自支持的能力集包括支持哪些原语、是否支持通知、是否支持日志等。这个握手过程通过initialize方法完成客户端发送协议版本和自身能力服务端返回协议版本、自身能力和服务器信息。连接建立后进入正常操作阶段客户端可以调用tools/list获取工具列表调用tools/call执行具体工具。服务端可以主动发送通知比如工具列表变更、资源更新等。最后通过shutdown和exit方法优雅关闭连接。这个生命周期设计看起来简单但实际用起来有几个细节要注意。协议版本协商如果双方不一致需要有一方降级或者拒绝连接。能力协商的结果决定了后续哪些方法可以调用如果客户端没声明支持 resources服务端就不应该主动推送资源更新通知。3.3 MCP 实际落地时的坑我在实际接入 MCP 的时候踩过几个坑。第一个是工具描述的质量直接决定调用准确率。MCP 把工具描述暴露给大模型模型根据描述决定调不调、怎么调。如果描述写得含糊模型就会乱调。我见过一个工具描述写的是“获取信息”模型完全不知道这个工具是查天气还是查股票调用成功率极低。后来改成“根据城市名称查询当前天气状况返回温度和天气描述”准确率立刻上去了。第二个坑是stdio 传输的进程管理。MCP Server 作为子进程启动如果 Server 崩溃了Client 需要有重启机制。如果 Server 输出大量日志到 stderr可能阻塞管道导致通信卡死。实际部署时建议把日志重定向到文件stdout 只用于协议消息。第三个坑是大参数传输。有些工具需要传入大段文本或者二进制数据JSON-RPC 的 params 字段会变得非常大影响传输效率。MCP 目前没有标准化的分块传输机制实际使用时要控制单次调用参数大小或者改用 Resources 原语来传递大数据。对比维度裸 JSON-RPCMCP能力描述无标准靠约定标准化 Tools/Resources/Prompts能力协商无initialize 握手交换能力集流式支持需自行实现支持通知机制流式语义较清晰错误语义通用错误码可扩展的结构化错误适用场景单团队简单调用跨厂商工具生态4. A2AAgent 之间如何平等对话4.1 A2A 要解决的问题和 MCP 完全不同MCP 解决的是“模型怎么调工具”本质上是主从关系模型是主工具是从。但多 Agent 系统里还有另一类通信Agent 和 Agent 之间的协作。这种场景下没有绝对的主从每个 Agent 都有自己的目标、能力和状态需要协商、委派、反馈。A2A 就是针对这个场景设计的。A2A 全称 Agent-to-Agent Protocol核心抽象是Agent Card。每个 Agent 通过 Agent Card 描述自己名称、描述、支持的技能、认证方式、通信端点。这有点像 MCP 的 tools/list但描述的是 Agent 整体而不是单个工具。Agent Card 通常放在一个众所周知的路径下比如/.well-known/agent.json其他 Agent 可以通过这个路径发现它。A2A 的通信模型是任务导向的。客户端 Agent 向服务端 Agent 发送任务请求服务端 Agent 返回任务状态和结果。任务可以长时间运行支持流式更新和推送通知。这个设计比简单的请求-响应更适合 Agent 协作场景因为很多 Agent 任务需要几分钟甚至几小时才能完成。4.2 A2A 的任务生命周期管理A2A 定义了一套完整的任务状态机submitted、working、input-required、completed、canceled、failed、rejected、auth-required、unknown。这个状态机是 A2A 相比其他协议最有价值的部分之一因为它把 Agent 协作中常见的中间状态都考虑进去了。input-required状态特别值得说。在多 Agent 协作中一个 Agent 执行任务到一半发现缺少关键信息需要向发起方或者用户请求补充。如果没有这个状态要么任务直接失败要么 Agent 只能阻塞等待。A2A 允许 Agent 主动进入input-required状态附带需要补充的信息说明发起方可以异步响应后再继续任务。流式更新通过 SSE 实现服务端 Agent 可以在任务执行过程中持续推送状态变更和中间结果。这对于需要展示推理过程的场景很有用比如一个研究 Agent 在搜集资料时可以实时把找到的每条信息推送给前端展示。4.3 A2A 和 MCP 的关系不是替代而是互补很多人第一次接触这两个协议时会困惑既然有了 MCP为什么还要 A2A答案很简单它们解决的是不同层次的问题。MCP 管的是 Agent 内部怎么调工具A2A 管的是 Agent 之间怎么协作。一个完整的系统可能同时用到两者Agent A 通过 A2A 把任务委派给 Agent BAgent B 在执行过程中通过 MCP 调用各种工具。实际架构中A2A 通常作为上层协作协议MCP 作为下层工具接入协议。A2A 的 Agent Card 里可以声明该 Agent 支持哪些 MCP 工具这样其他 Agent 在委派任务时就能知道对方的能力边界。这种分层设计让系统既有灵活的协作能力又有标准化的工具接入方式。注意事项A2A 的 Agent Card 发现机制依赖网络可达的 well-known 路径在内网或者隔离环境中需要额外配置服务发现。另外 Agent Card 里的认证信息要小心处理不要暴露敏感凭证。5. ACP消息语义层的另一种思路5.1 ACP 关注的是消息本身的结构ACP 全称 Agent Communication Protocol它的切入点和前两者又不一样。MCP 关注工具调用A2A 关注任务协作ACP 关注的是消息本身的语义结构。它试图定义一套通用的消息格式让 Agent 之间的所有通信——不管是请求、响应、通知还是流式数据——都遵循统一的结构。ACP 的消息模型包含几个核心字段消息 ID、会话 ID、发送方、接收方、消息类型、负载内容、时间戳、关联 ID。这个结构比 JSON-RPC 丰富得多特别是会话 ID 和关联 ID 的设计让多轮对话和请求-响应关联变得很自然。ACP 还定义了消息的优先级和过期时间。在实际 Agent 系统中有些消息是紧急的比如任务取消有些是可以延迟的比如状态同步。有了优先级字段传输层可以根据优先级做调度。过期时间则避免了过期消息占用处理资源。5.2 ACP 的会话管理机制ACP 把会话作为一等公民。一个会话可以包含多轮消息交换会话有明确的生命周期创建、活跃、挂起、关闭。这个设计对于需要多轮交互的 Agent 任务很友好比如一个谈判 Agent 和另一个 Agent 来回协商参数整个过程在一个会话里完成上下文不会丢失。会话状态可以持久化这意味着 Agent 重启后可以恢复之前的会话。这对于长时间运行的任务很重要。我见过一个场景一个数据分析 Agent 处理大批量数据需要几个小时中间服务重启了如果没有会话持久化所有中间状态都丢了只能从头再来。ACP 的会话管理还支持会话迁移。一个会话可以从一个 Agent 实例迁移到另一个实例这在负载均衡和故障转移场景下很有用。不过会话迁移的实现复杂度较高需要解决状态同步和消息重放的问题实际落地时要谨慎评估。5.3 三种协议的实际选型建议说了这么多实际做项目时到底怎么选我的经验是看你的核心需求是什么。如果你的主要场景是让大模型调用各种外部工具和数据源MCP 是最成熟的选择生态支持也最广。如果你的场景是多 Agent 协作完成复杂任务Agent 之间有明确的分工和委派关系A2A 的任务模型更合适。如果你需要精细控制消息语义、做复杂的会话管理ACP 提供了更丰富的原语。但现实项目往往是混合的。我做过的一个项目就是 A2A 做 Agent 间协作MCP 做工具接入内部消息格式参考 ACP 的设计。协议之间不是互斥的关键是理解每个协议解决的核心问题然后按需组合。协议核心抽象主要解决典型场景JSON-RPC方法调用远程过程调用简单 Agent 调用MCPTool/Resource/Prompt工具标准化接入模型调工具A2AAgent Card/TaskAgent 间协作多 Agent 任务委派ACPMessage/Session消息语义与会话复杂对话与状态管理6. 协议背后的设计权衡与实操避坑6.1 为什么不能有一个统一协议每次聊到这个话题总有人问为什么不能有一个协议把所有事情都干了这个问题我在设计内部系统时也想过但实际做下来发现不同场景的约束条件差异太大强行统一会导致协议臃肿。工具调用场景要求低延迟、高并发、schema 严格因为模型要频繁调用工具每次调用都要快速返回。Agent 协作场景要求状态可追踪、支持长任务、支持异步因为任务可能跑很久。消息语义场景要求灵活、可扩展、支持多种消息类型。把这些需求塞进一个协议结果就是每个场景都用不到一半的功能但都要承担全部的实现复杂度。另一个原因是演进速度不同。工具调用协议随着模型能力变化快速迭代Agent 协作协议相对稳定消息协议则变化最慢。分开设计可以让各自独立演进不会互相拖累。6.2 实际集成时的常见问题排查问题一协议版本不匹配导致握手失败。这是最常见的问题。MCP 和 A2A 都有版本协商机制如果客户端和服务端支持的版本范围没有交集连接就会失败。排查方法是先看双方声明的版本号确认是否有重叠区间。实际部署时建议在配置里显式指定协议版本不要依赖自动协商。问题二流式传输中断。SSE 连接可能因为网络波动、代理超时、服务端重启等原因中断。如果没有重连机制任务就卡住了。我的做法是在客户端实现指数退避重连同时服务端要支持从断点继续推送。A2A 的任务状态机在这里很有用重连后先查任务当前状态再决定从哪继续。问题三工具调用参数校验失败。MCP 工具的参数 schema 如果写得太严格模型生成的参数可能因为格式微差被拒绝。比如 schema 要求integer模型给了5字符串。实际使用中建议在服务端做一层宽松校验能转换的自动转换只对真正非法的参数报错。问题四Agent Card 发现失败。A2A 的 Agent Card 放在 well-known 路径如果服务部署在子路径下或者有反向代理路径可能不对。排查时先用 curl 直接访问 Agent Card 的完整 URL确认返回的是合法 JSON。另外注意 Content-Type 要正确有些实现只接受application/json。问题五会话状态不一致。ACP 的会话状态如果客户端和服务端不一致会导致消息处理混乱。比如客户端认为会话已关闭服务端还在等待消息。解决方法是引入会话状态同步机制定期或者关键操作前做一次状态对齐。实操心得协议集成时一定要先写一个最小可用的连通性测试不要一上来就集成完整业务逻辑。我通常的做法是先跑通握手、再跑通一个最简单的工具调用或任务委派、最后才接入真实业务。这样出问题时排查范围小定位快。6.3 性能优化的几个关键点协议层的性能优化主要围绕三个方向减少往返次数、压缩消息体积、并行化处理。减少往返次数方面MCP 的批量调用和 A2A 的任务批处理都能显著降低网络开销。如果一次需要调用十个工具逐个调用和批量调用的延迟差距可能达到十倍。实际使用中要尽量把能合并的请求合并。压缩消息体积方面JSON 本身比较冗余字段名重复出现。如果传输量大可以考虑在传输层做 gzip 压缩或者使用更紧凑的序列化格式。不过要注意压缩会增加 CPU 开销在低延迟场景下要权衡。并行化处理方面多个独立的工具调用或者任务委派可以并行发起。但要注意并发控制避免压垮下游服务。我通常会给每个下游服务设置并发上限超过上限的请求排队等待。7. 我对 Agent 协议演进的一点观察做了一年多 Agent 系统集成我最大的体会是协议的价值不在于技术多先进而在于有多少人用。JSON-RPC 技术上很简单但因为它足够通用成了很多协议的基础层。MCP 能快速铺开很大程度上是因为它背靠的生态有足够多的工具提供方愿意接入。A2A 和 ACP 还在演进中生态成熟度还需要时间验证。另一个观察是协议之间的边界正在模糊。MCP 最新版本开始支持一些 Agent 协作相关的原语A2A 也在考虑如何更好地集成工具调用。未来可能会出现某种程度的融合但短期内多协议并存仍是常态。对于开发者来说与其纠结选哪个协议不如先把核心业务逻辑和接口抽象做好。协议只是通信层业务逻辑才是核心价值。我见过太多项目在协议选型上花了大量时间结果业务逻辑写得一塌糊涂。先把业务跑通协议层可以后续替换和优化。最后分享一个实际项目中的小技巧在协议层之上加一个薄薄的适配层把不同协议的消息统一转换成内部格式。这样即使底层协议换了上层业务代码不用动。这个适配层的成本很低但带来的灵活性很高值得在项目初期就考虑进去。
