Agent 通信协议解析：从 JSON-RPC 到自然语言交互的演变

二、 摘要/引言

核心概念（前置锚点：先给Agent下简化但核心的定义）

自主Agent（Autonomous Agent）：具备感知环境、推理决策、执行动作闭环能力的软件实体。

Agent通信协议（Agent Communication Protocol, ACP）：定义Agent之间（Agent-to-Agent, A2A）、Agent与用户（Agent-to-Human, A2H）、Agent与工具/系统（Agent-to-Tool/System, A2T/S）之间传递消息的格式、编码、语义解析、交互规则的规范集合，是Agent生态的“通用语言语法书+对话手册”。

问题背景

想象一下，你正在搭建一个由3个Agent组成的小团队：

  1. 需求收集Agent（Agent A）：从你输入的自然语言中拆解成结构化的功能点；
  2. 代码生成Agent（Agent B）：接收功能点生成Python FastAPI后端代码；
  3. 代码部署Agent（Agent C）：把生成的代码推送到GitHub并触发GitHub Actions部署到Vercel。

如果这三个Agent各说各的“方言”——比如Agent A输出XML格式的需求树，Agent B只能接受纯文本，Agent C要求YAML配置清单——那整个团队根本无法协作。

更糟的是，当你想让Agent帮你买咖啡时：传统的命令式API（比如OpenAI Function Calling v1的强制JSON格式）可能会严格要求你输入{"name": "buy_coffee", "parameters": {"size": "medium", "type": "latte", "sugar": "2 pumps"}}；但你只想说“给我带杯中杯半糖（不对，等下刚才写的是2 pumps香草浓缩，应该是‘中杯香草拿铁加2泵糖不加冰’）”——这就是A2H交互的结构化刚性痛点。

问题陈述

本博客将系统性解决以下3组核心问题：

A2A/A2T/S方向的“结构化刚性与灵活性”问题
  1. 早期的A2A协议（比如FIPA ACL、KQML）为什么没能大规模普及？
  2. 为什么JSON-RPC、gRPC这类通用RPC协议（非专门ACP）反而成为了当前非LLM Agent生态和早期LLM Agent生态的主流选择？它们的核心优势、劣势是什么？
  3. 如何在RPC协议的基础上做轻量级改造，提升LLM Agent之间的协作效率？
A2H/A2A通用的“自然语言到结构化语义的双向桥接”问题
  1. OpenAI Function Calling/Assistant API、LangChain Tools这类当前主流的“结构化需求前置+语义后置约束”的方案有什么局限？
  2. 什么是“自然语言交互（Natural Language Interaction, NLI）主导的ACP”？它的核心架构是什么？
  3. 如何实现自然语言与结构化RPC/消息的无损双向转换？
未来Agent生态的“协议标准化与个性化”问题
  1. 当前LLM ACP领域有哪些主流的探索方向（比如OpenAI Assistants API、Anthropic Claude 3 Tools + Prompt Engineering、Google PaLM API、Microsoft Semantic Kernel、开源的AutoGen/Multi-Agent System协议）？它们的对比维度是什么？
  2. 未来的ACP会不会出现像HTTP/2→HTTP/3那样的标准化协议？还是会走“协议框架+个性化插件/指令库”的路线？
  3. 对于小型团队或个人开发者，如何选择适合自己的ACP？

核心价值

读完这篇10000字左右的博客，你将：

  1. 建立完整的ACP知识体系：从早期的FIPA/KQML到当前的通用RPC→Function Calling→NLI主导的ACP，掌握每一代协议的诞生背景、核心设计、优劣势、适用场景；
  2. 掌握核心ACP的实操能力：
    • 用Python实现一个基于JSON-RPC 2.0的简单A2A协作系统（比如“计算器Agent+存储Agent”）；
    • 用LangChain和FastAPI实现一个Function Calling的NLI→RPC双向转换系统；
    • 用OpenAI Assistants API和OpenAI Function Calling v2探索NLI主导的ACP边界；
  3. 形成自己的ACP选型方法论：根据你的Agent数量、协作复杂度、A2H/A2A占比、实时性要求、LLM能力预算等维度，选择或改造适合的ACP；
  4. 了解ACP的未来发展趋势：提前布局下一代ACP的探索。

文章概述

本文将分为以下8个核心章节（严格控制每个章节1200-1500字，总字数约10000字）：

  1. Agent通信协议的基础概念与历史演变：从定义、作用、分类讲起，用markdown表格梳理从1990年到2024年的4代ACP演变历史；
  2. 通用RPC协议在LLM Agent时代的应用与改造：重点解析JSON-RPC 2.0的核心规范（用mermaid架构图展示请求-响应流程），用Python实现一个简单的A2A系统，分析其改造思路；
  3. Function Calling：从通用RPC到LLM友好协议的过渡：解析OpenAI Function Calling v1/v2的核心设计（用markdown表格对比两代差异），用mermaid流程图展示Function Calling的交互流程，用LangChain和FastAPI实现一个NLI→RPC的单向转换系统；
  4. NLI主导的ACP：Agent交互的终极形态？：解析NLI主导的ACP的核心架构（用mermaid ER实体关系图展示核心组件，用mermaid交互关系图展示组件之间的协作），用OpenAI Assistants API和LangGraph实现一个无损双向转换的A2A/A2H系统；
  5. 当前主流LLM ACP的对比与选型：用markdown表格从标准化程度、LLM友好度、A2A协作能力、A2H交互体验、实时性、扩展性、开源性、学习成本8个维度对比OpenAI Assistants API、Anthropic Claude 3 Tools、Microsoft Semantic Kernel、LangChain Tools/LangGraph、AutoGen Core Protocol这5个主流方案；
  6. NLI主导的ACP的数学模型与核心算法：用latex公式描述语义相似度匹配（用于工具/Agent发现）、结构化信息提取（用于NLI→RPC转换）、**结构化信息到自然语言的生成（用于RPC→NLI转换）**这3个核心模型，用mermaid流程图展示这3个模型的协作流程，用Python实现一个简化版的结构化信息提取模型；
  7. 最佳实践Tips与常见坑点：分享10个以上的ACP最佳实践（比如“分层设计消息格式”、“给工具/Agent加清晰的元数据标签”、“设置交互超时与重试机制”）和5个以上的常见坑点（比如“JSON-RPC的错误码使用不规范导致LLM无法理解”、“Function Calling的参数描述过于模糊或过于冗余”、“NLI主导的ACP的幻觉问题”）；
  8. 本章小结与未来展望：总结本文的核心内容，展望下一代ACP的5个发展方向（比如“多模态ACP”、“分布式区块链化的ACP”、“自适应学习的ACP”、“隐私保护的ACP”、“跨生态兼容的标准化ACP”）。

三、 正文

第一章：Agent通信协议的基础概念与历史演变

核心概念

我们先把之前前置锚点的Agent和ACP的定义再细化一下，补充一些分类和核心设计原则：

自主Agent的4个核心能力（Wooldridge-Jennings定义）

Wooldridge和Jennings在1995年发表的论文《Intelligent Agents: Theory and Practice》中提出了自主Agent的弱定义和强定义：

  • 弱定义（当前工程化的LLM Agent基本都满足这个定义）：具备以下4个核心能力的软件实体：
    1. 自主性（Autonomy）：无需人类或其他实体的直接干预，即可自主执行动作；
    2. 反应性（Reactivity）：能够感知环境（包括其他Agent、用户、工具/系统的状态变化），并在一定时间内做出响应；
    3. 主动性（Pro-activity）：不仅仅是被动响应环境，还能主动设定目标，并采取行动实现目标；
    4. 社会性（Social Ability）：能够与其他Agent或用户进行交互协作；
  • 强定义（当前工程化的LLM Agent还在探索中）：除了弱定义的4个核心能力外，还具备心理状态（Mental State），比如信念（Belief）、愿望（Desire）、意图（Intention）——即BDI模型。
Agent通信协议的4个核心设计原则（FIPA定义）

FIPA（Foundation for Intelligent Physical Agents，智能物理代理基金会）在1996年成立，是早期ACP标准化的主要推动者，它提出了ACP的4个核心设计原则：

  1. 开放性（Openness）：协议应该是公开的、可扩展的，允许不同厂商、不同平台的Agent进行交互；
  2. 互操作性（Interoperability）：协议应该定义明确的消息格式、编码、语义解析、交互规则，确保不同Agent之间能够“听懂”对方的话；
  3. 可扩展性（Scalability）：协议应该能够支持从2个Agent的简单协作到数千个Agent的复杂分布式协作；
  4. 隐私性与安全性（Privacy & Security）：协议应该支持消息加密、身份认证、授权访问等功能，保护Agent和用户的隐私与安全。
Agent通信协议的3种分类方式

我们可以从交互对象、消息格式、交互模式3个维度对ACP进行分类：

  1. 按交互对象分类：
    • A2A（Agent-to-Agent）：Agent之间的交互协作，比如之前提到的需求收集Agent→代码生成Agent→代码部署Agent；
    • A2H（Agent-to-Human）：Agent与用户的交互，比如ChatGPT、Siri、小爱同学；
    • A2T/S（Agent-to-Tool/System）：Agent与工具/系统的交互，比如OpenAI Function Calling调用第三方API（比如天气API、股票API）、AutoGen调用Python解释器。
  2. 按消息格式分类：
    • 结构化消息格式：消息的格式、字段、类型都是严格定义的，比如XML、JSON、YAML、Protobuf、Thrift；
    • 半结构化消息格式：消息的格式有一定的规范，但字段、类型可以灵活扩展，比如FIPA ACL、KQML；
    • 非结构化消息格式：消息的格式没有严格定义，主要是自然语言文本、图像、音频、视频等多模态内容，比如NLI主导的ACP。
  3. 按交互模式分类：
    • 同步交互（Synchronous Interaction）：发送方发送消息后，必须等待接收方的响应才能继续执行后续动作，比如HTTP请求-响应、JSON-RPC请求-响应；
    • 异步交互（Asynchronous Interaction）：发送方发送消息后，不需要等待接收方的响应，可以继续执行后续动作，接收方处理完消息后，会通过回调函数、消息队列等方式通知发送方，比如MQTT、WebSocket、FIPA ACL的异步交互模式。
问题背景（从Agent的发展历史看ACP的需求演变）

Agent的发展历史可以分为以下3个阶段，每个阶段对ACP的需求都不一样：

  1. 早期探索阶段（1990-2015年）：这个阶段的Agent主要是基于规则的、弱AI的Agent，比如专家系统、聊天机器人ELIZA的改进版、多Agent系统（Multi-Agent System, MAS）的研究原型。这个阶段的需求是实现严格的A2A语义互操作性，因为基于规则的Agent对消息的语义要求非常高——如果消息的语义有一点点偏差，Agent就无法执行动作。
  2. 通用RPC主导阶段（2015-2022年）：这个阶段的Agent主要是基于API的、非自主的Agent（其实更像是“API调用的包装器”），比如早期的Siri、小爱同学、聊天机器人微软小冰的部分功能。这个阶段的需求是实现简单的A2T/S调用和A2H交互，因为基于API的Agent不需要复杂的A2A协作，主要是调用第三方API完成用户的请求。
  3. LLM Agent爆发阶段（2022年至今）：这个阶段的Agent主要是基于大语言模型（Large Language Model, LLM）的、弱自主到强自主探索的Agent，比如OpenAI GPTs、LangChain Agent、AutoGen、Microsoft Copilot Studio。这个阶段的需求是实现灵活的A2A协作、无损的NLI→结构化信息双向转换、一定程度的语义容错能力，因为LLM Agent具备一定的自然语言理解和推理能力，对消息的语义要求不是那么严格，但需要灵活的协作机制和良好的A2H交互体验。
问题描述（为什么早期的ACP没能大规模普及？为什么通用RPC反而成为了主流？）
早期ACP（FIPA ACL、KQML）的问题

我们先看一下FIPA ACL和KQML这两个早期最著名的ACP的核心设计：

  1. KQML（Knowledge Query and Manipulation Language，知识查询与操作语言）：诞生于1992年，是第一个专门为MAS设计的ACP。KQML的消息分为3层：
    • 通信层（Communication Layer）：定义消息的发送者、接收者、时间戳、消息ID等元数据；
    • 消息层（Message Layer）：定义消息的语用力（Speech Act），比如“ask-if”（询问是否）、“tell”（告诉）、“request”（请求）、“achieve”（要求实现某个目标）、“subscribe”（订阅）；
    • 内容层（Content Layer）：定义消息的具体内容，内容层的格式可以是任意的，比如KIF（Knowledge Interchange Format，知识交换格式）、XML、JSON。
  2. FIPA ACL（FIPA Agent Communication Language）：诞生于1996年，是FIPA在KQML的基础上改进的标准化ACP。FIPA ACL的消息结构和KQML类似，也分为3层，但它的语用力定义更严格（有20多个标准语用力），内容层推荐使用FIPA SL（Semantic Language，语义语言）——一种基于一阶逻辑的语言。

早期ACP的核心问题可以总结为以下5点：

  1. 语义过于复杂，学习成本极高：FIPA SL是基于一阶逻辑的语言，需要开发者具备深厚的数理逻辑和人工智能理论基础，普通的软件工程师根本无法使用；
  2. 实现复杂度极高，没有成熟的开源框架：FIPA ACL的规范非常详细（有几十份文档），但早期的开源框架（比如JADE、JACK）都非常复杂，部署和调试成本极高；
  3. 应用场景过于狭窄，主要集中在学术研究领域：早期的MAS研究主要集中在学术领域（比如机器人协作、供应链管理的研究原型），没有大规模的工业应用，导致早期ACP的生态非常薄弱；
  4. 没有考虑到后来的互联网和云计算的发展：早期ACP的设计主要是为了局域网内的MAS协作，没有考虑到互联网的延迟、丢包、分布式部署等问题；
  5. 隐私性与安全性的实现成本极高：FIPA ACL虽然定义了隐私性与安全性的规范，但实现起来非常复杂，普通的开发者根本无法使用。
通用RPC（JSON-RPC、gRPC）的优势

我们再看一下JSON-RPC和gRPC这两个当前主流的通用RPC协议的核心设计：

  1. JSON-RPC（JavaScript Object Notation Remote Procedure Call）：诞生于2005年，是一种基于JSON的轻量级同步RPC协议。JSON-RPC 2.0（2010年发布）的核心规范非常简单，只有10页左右。它的消息分为请求消息和响应消息两种：
    • 请求消息：包含jsonrpc（必须为"2.0"）、method（要调用的远程方法名）、params（远程方法的参数，可以是数组或对象）、id（请求的唯一标识符，可以是字符串、数字或null——如果是null，表示是通知消息，不需要响应）；
    • 响应消息：包含jsonrpc（必须为"2.0"）、result（远程方法调用成功时的返回值，必须与error互斥）、error（远程方法调用失败时的错误信息，必须与result互斥——包含code（错误码）、message（错误消息）、data（可选的错误详细信息））、id（必须与对应的请求消息的id一致）；
  2. gRPC（Google Remote Procedure Call）：诞生于2015年，是一种基于HTTP/2和Protobuf的高性能通用RPC协议。gRPC支持同步交互和异步交互，支持4种交互模式：
    • 一元RPC（Unary RPC）：客户端发送一个请求，服务器返回一个响应（类似JSON-RPC 2.0）；
    • 服务器流式RPC（Server Streaming RPC）：客户端发送一个请求，服务器返回多个响应；
    • 客户端流式RPC（Client Streaming RPC）：客户端发送多个请求，服务器返回一个响应；
    • 双向流式RPC（Bidirectional Streaming RPC）：客户端和服务器可以同时发送和接收多个响应。

通用RPC的核心优势可以总结为以下5点：

  1. 语义非常简单，学习成本极低：JSON-RPC 2.0的核心规范只有10页左右，普通的软件工程师只需要1-2个小时就能完全掌握；gRPC的核心规范虽然比JSON-RPC复杂，但Protobuf的学习成本也很低，普通的软件工程师只需要1-2天就能完全掌握；
  2. 实现复杂度极低，有成熟的开源框架：JSON-RPC 2.0有几乎所有编程语言的开源框架（比如Python的jsonrpcserver、jsonrpclib-pelix，JavaScript的jsonrpc-lite、jayson）；gRPC也有几乎所有编程语言的官方开源框架，部署和调试成本极低；
  3. 应用场景非常广泛，生态非常成熟：通用RPC协议不仅仅用于Agent通信，还用于几乎所有的互联网应用（比如微服务之间的通信），生态非常成熟；
  4. 充分考虑了互联网和云计算的发展：JSON-RPC 2.0可以基于HTTP/1.1或WebSocket传输，gRPC基于HTTP/2传输，充分考虑了互联网的延迟、丢包、分布式部署、负载均衡等问题；
  5. 隐私性与安全性的实现成本极低：JSON-RPC 2.0和gRPC都可以基于HTTPS/TLS传输，支持身份认证、授权访问等功能，普通的开发者只需要几行代码就能实现。
概念结构与核心要素组成
通用ACP的概念结构

不管是早期的专门ACP（FIPA ACL、KQML），还是当前的通用RPC，还是未来的NLI主导的ACP，它们的概念结构都可以分为以下5个核心层次：

  1. 传输层（Transport Layer）：负责消息的物理传输，比如HTTP/1.1、HTTP/2、HTTP/3、WebSocket、MQTT、TCP、UDP；
  2. 编码层（Encoding Layer）：负责消息的编码和解码，比如JSON、XML、YAML、Protobuf、Thrift、MessagePack；
  3. 消息格式层（Message Format Layer）：负责定义消息的结构和字段，比如JSON-RPC 2.0的请求/响应消息结构、FIPA ACL的3层消息结构；
  4. 语义层（Semantic Layer）：负责定义消息的语义，比如JSON-RPC 2.0的method和params的语义、FIPA ACL的语用力和FIPA SL的语义、LLM的自然语言语义；
  5. 交互规则层（Interaction Rule Layer）：负责定义Agent之间的交互规则，比如JSON-RPC 2.0的同步请求-响应规则、FIPA ACL的合同网协议（Contract Net Protocol, CNP）、NLI主导的ACP的多轮对话规则。
通用ACP的核心要素组成

不管是哪种ACP，它们的核心要素都可以分为以下4个部分：

  1. 消息元数据（Message Metadata）：描述消息本身的信息，比如发送者、接收者、时间戳、消息ID、消息类型（请求/响应/通知）、消息优先级、消息过期时间；
  2. 消息内容（Message Content）：消息的具体内容，比如JSON-RPC 2.0的method、params、result、error，FIPA ACL的语用力和内容层，LLM的自然语言文本；
  3. Agent元数据（Agent Metadata）：描述Agent本身的信息，比如Agent的ID、Agent的类型、Agent的能力、Agent的位置、Agent的状态；
  4. 交互规则（Interaction Rules）：Agent之间的交互规则，比如请求-响应规则、合同网协议、拍卖协议、多轮对话规则。
概念之间的关系：早期专门ACP vs 当前通用RPC的核心属性维度对比

我们用markdown表格从核心设计目标、学习成本、实现复杂度、A2A语义互操作性、A2A协作能力、A2H交互体验、A2T/S调用能力、实时性、扩展性、生态成熟度、隐私性与安全性、适用场景12个维度对比早期专门ACP（FIPA ACL）和当前通用RPC（JSON-RPC 2.0）：

核心属性维度 早期专门ACP（FIPA ACL） 当前通用RPC（JSON-RPC 2.0）
核心设计目标 实现严格的A2A语义互操作性，支持复杂的MAS协作（比如合同网协议、拍卖协议） 实现简单的远程过程调用，支持微服务之间的通信
学习成本 极高（需要具备深厚的数理逻辑和人工智能理论基础，掌握FIPA SL、JADE等复杂工具） 极低（只需要掌握JSON格式，普通软件工程师1-2小时就能完全掌握）
实现复杂度 极高（规范有几十份文档，开源框架JADE/JACK非常复杂，部署和调试成本极高） 极低（规范只有10页左右，有几乎所有编程语言的成熟开源框架，部署和调试成本极低）
A2A语义互操作性 极高（基于一阶逻辑的FIPA SL定义了严格的语义，不同Agent之间可以“完全听懂”对方的话） 极低（只定义了消息的格式，没有定义method和params的语义，需要开发者自行约定）
A2A协作能力 极强（内置了合同网协议、拍卖协议等复杂的MAS协作协议） 极弱（只支持简单的同步请求-响应，复杂的协作需要开发者自行开发交互规则）
A2H交互体验 极差（没有考虑A2H交互，用户需要掌握FIPA SL才能与Agent交互） 一般（需要用户输入结构化的请求，或者开发者自行开发NLI→结构化信息的转换层）
A2T/S调用能力 一般（可以调用第三方工具/系统，但需要把工具/系统的API封装成FIPA ACL的格式） 极强（几乎所有第三方工具/系统都提供HTTP API，可以直接或简单封装成JSON-RPC 2.0的格式）
实时性 一般（可以基于TCP/IP或HTTP传输，但早期的开源框架的实时性一般） 极好（基于HTTP/1.1或WebSocket传输，延迟极低）
扩展性 极强（规范非常灵活，支持自定义语用力、自定义内容层格式） 一般（规范比较固定，自定义扩展需要开发者自行约定）
生态成熟度 极差（主要集中在学术研究领域，没有大规模的工业应用，生态非常薄弱） 极好（不仅仅用于Agent通信，还用于几乎所有的互联网应用，生态非常成熟）
隐私性与安全性 极高（规范定义了详细的隐私性与安全性机制，但实现成本极高） 极高（可以基于HTTPS/TLS传输，支持身份认证、授权访问等功能，实现成本极低）
适用场景 学术研究领域的复杂MAS协作（比如机器人协作、供应链管理的研究原型） 工业应用领域的简单A2T/S调用、微服务之间的通信、早期LLM Agent的简单A2A协作
概念之间的关系：通用ACP的5层架构与核心要素的ER实体关系图

我们用mermaid ER实体关系图展示通用ACP的5层架构与核心要素的关系：

承载

编码/解码

提供消息结构

提供语义基础

约束Agent交互

发送/接收

包含

包含

拥有

定义结构

定义语义

约束发送/接收时机

TRANSPORT_LAYER

ENCODING_LAYER

MESSAGE_FORMAT_LAYER

SEMANTIC_LAYER

INTERACTION_RULE_LAYER

AGENT

MESSAGE

MESSAGE_METADATA

MESSAGE_CONTENT

AGENT_METADATA
本章小结

本章我们主要讲了以下内容：

  1. 基础概念：细化了自主Agent的Wooldridge-Jennings定义、ACP的FIPA核心设计原则、ACP的3种分类方式；
  2. 历史背景：梳理了Agent发展的3个阶段（早期探索阶段、通用RPC主导阶段、LLM Agent爆发阶段）以及每个阶段对ACP的需求演变；
  3. 问题分析：分析了早期专门ACP（FIPA ACL、KQML）没能大规模普及的5个核心问题，以及当前通用RPC（JSON-RPC、gRPC）成为主流的5个核心优势；
  4. 概念结构：提出了通用ACP的5层概念结构（传输层、编码层、消息格式层、语义层、交互规则层）和4个核心要素（消息元数据、消息内容、Agent元数据、交互规则）；
  5. 概念对比：用markdown表格从12个维度对比了早期专门ACP（FIPA ACL）和当前通用RPC（JSON-RPC 2.0）；
  6. ER图：用mermaid ER实体关系图展示了通用ACP的5层架构与核心要素的关系。

下一章我们将重点解析JSON-RPC 2.0的核心规范，用Python实现一个简单的基于JSON-RPC 2.0的A2A协作系统（比如“计算器Agent+存储Agent”），分析其改造思路。

# json # rpc # 交互
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

Python asyncio 模块学习总结：从“等着”到“切出去干点别的”

avatar AtomGit开源社区
cover

【技术分享】佬友想知道更多skill转agent方案 - 和解决安全问题

avatar AtomGit开源社区
cover

Users Chat AI全栈项目模块化开发实战解析

avatar AtomGit开源社区