JSON-RPC

3 秒看懂

JSON-RPC 是一种用 JSON 编码的远程过程调用（RPC）协议，设计极简——一个请求只需 method + params + id 三个字段，一个响应只需 result 或 error + id。传输层无关，可跑在 HTTP、WebSocket、TCP、Unix Socket 乃至 stdio 上。2.0 版（2010 年定稿）是当前事实标准。

一句话定位：AI 时代的”毛细血管协议”——Anthropic MCP、LSP、Ethereum JSON-RPC、多数 Agent 框架的底层通信层都选了它。

3 分钟产业解释

为什么 AI 行业突然关心一个 2005 年就诞生的协议？

三个关键事件把 JSON-RPC 推到 AI 基础设施台前：

产业意义：

1. AI Agent 通信的最低公约数：当多个 Agent 框架（LangChain、AutoGPT、CrewAI 等）需要互操作时，JSON-RPC 提供了最轻量、最无依赖的调用约定。
2. MCP 生态的承载协议：Anthropic MCP 定义了 tools/list、tools/call、resources/list、prompts/list 等标准 method，底层就是 JSON-RPC 2.0 的 request/response/notification 三种消息类型。
3. LLM 训练/推理基础设施的胶水层：部分推理服务编排系统（如 vLLM 的某些部署模式、Ray Serve 的 HTTP adapter）也暴露 JSON-RPC 接口用于内部调度。

一句话：JSON-RPC 不性感，但它是 AI 工具链连接层的”USB-C”——简单、通用、到处都有现成实现。

15 分钟专家深入

核心架构

JSON-RPC 的设计哲学可概括为 “最小可行 RPC”：

• 编码层：纯 JSON（UTF-8）
• 调用层：Request 对象包含 jsonrpc（版本标识 "2.0"）、method（字符串）、params（数组或对象，可选）、id（字符串/数字/null）
• 响应层：Response 对象包含 result 或 error（二选一，互斥）、id（与 Request 对应）
• 通知：Request 中省略 id 字段即为 Notification，服务端不返回响应[JSON-RPC 2.0 Spec]
• 批量调用：可将多个 Request 打包为 JSON 数组发送，服务端返回对应数量的 Response 数组[JSON-RPC 2.0 Spec]
• 传输无关：Spec 本身不绑定任何传输协议——这是它能适配 stdio（LSP）、HTTP（Ethereum）、WebSocket（实时 Agent）、TCP 的根本原因

与 gRPC/REST 的本质差异

┌──────────────┬─────────────────┬─────────────────┬──────────────────┐
│              │   JSON-RPC 2.0  │    REST/HTTP    │     gRPC         │
├──────────────┼─────────────────┼─────────────────┼──────────────────┤
│ 编码格式      │ JSON            │ JSON/XML/...    │ Protobuf (二进制) │
│ 通信模式      │ 请求-响应 +     │ 请求-响应       │ 四种流模式        │
│              │ 通知 + 批量     │                 │ (Unary/Stream)   │
│ 接口定义      │ 无强制 schema   │ OpenAPI (可选)  │ .proto 文件       │
│ 传输层        │ 无关(任意)      │ HTTP/HTTPS      │ HTTP/2           │
│ 浏览器原生    │ ✅ (JSON+HTTP)  │ ✅              │ ⚠️ 需 grpc-web    │
│ 依赖轻重      │ 极轻            │ 轻              │ 重(需Protobuf+HTTP2)│
│ 二进制效率    │ 低(JSON文本)    │ 低              │ 高               │
│ AI生态采用    │ MCP/LSP/Ethereum│ 通用API         │ TensorFlow Serving│
└──────────────┴─────────────────┴─────────────────┴──────────────────┘

选型逻辑：JSON-RPC 胜在”零门槛 + 传输无关 + JSON 天然可读”，在人类可调试性和跨语言兼容性上碾压 gRPC；在性能和强类型上远不如 gRPC。

JSON-RPC 2.0 消息格式详解

Request 对象 [JSON-RPC 2.0 Spec]：

{
  "jsonrpc": "2.0",        // 必填，固定值 "2.0"
  "method": "tools/call",  // 必填，字符串，以 "rpc." 开头的为保留方法名
  "params": {              // 可选，By-Name 对象或 By-Position 数组
    "name": "read_file",
    "arguments": {"path": "/tmp/foo.txt"}
  },
  "id": 42                 // 可选；省略则为 Notification
}

Response 对象 [JSON-RPC 2.0 Spec]：

// 成功
{"jsonrpc": "2.0", "result": {"content": "..."}, "id": 42}

// 失败
{"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": 42}

标准错误码 [JSON-RPC 2.0 Spec]：

在 MCP 中的映射

Anthropic MCP 对 JSON-RPC 2.0 的使用方式：

Client → Server: {"jsonrpc":"2.0","method":"initialize","params":{...},"id":1}
Server → Client: {"jsonrpc":"2.0","result":{...},"id":1}

Client → Server: {"jsonrpc":"2.0","method":"notifications/initialized"}
                  (Notification, 无 id, 无响应)

Client → Server: {"jsonrpc":"2.0","method":"tools/call",
                  "params":{"name":"web_search","arguments":{"query":"..."}},"id":7}
Server → Client: {"jsonrpc":"2.0","result":{"content":[...]},"id":7}

MCP 还利用了 JSON-RPC 2.0 的双向通信能力——Client 和 Server 都可以发起请求和通知，这是在 HTTP 之上用 Streamable HTTP 传输层实现的（MCP 2024-11 spec 之后的方案）。

技术原理

协议状态机

                    ┌─────────────┐
                    │   Client    │
                    └──────┬──────┘
                           │
         ┌─────────────────┼─────────────────┐
         ▼                 ▼                  ▼
   ┌──────────┐     ┌────────────┐    ┌──────────────┐
   │  Request  │     │Notification│    │ Batch Request│
   │(有 id)    │     │(无 id)     │    │(JSON Array)  │
   └─────┬────┘     └─────┬──────┘    └──────┬───────┘
         │                 │                   │
         ▼                 ▼                   ▼
   ┌──────────┐     ┌────────────┐    ┌──────────────┐
   │ Response │     │ 无响应返回  │    │ Response Array│
   │(对应 id) │     │(Fire&Forget)│   │(可能含Error) │
   └──────────┘     └────────────┘    └──────────────┘

关键设计决策与技术权衡

关键参数与性能特征

以下为行业经验性数据，非 Spec 定义，标 [估算]。

技术演进史

技术路线对比

RPC 协议选型矩阵（面向 AI 场景）

维度评分: ★★★★★ 最优   ★ 最低   — 不适用

┌─────────────────┬──────────┬──────────┬──────────┬──────────┐
│ 协议             │JSON-RPC 2│ REST/HTTP│  gRPC    │  SOAP    │
│                 │          │          │          │(已边缘化)│
├─────────────────┼──────────┼──────────┼──────────┼──────────┤
│ 轻量级/易接入    │ ★★★★★   │ ★★★★    │ ★★       │ ★        │
│ 人类可读/可调试  │ ★★★★★   │ ★★★★★   │ ★★       │ ★★★     │
│ 传输层灵活性     │ ★★★★★   │ ★★★     │ ★★       │ ★        │
│ 强类型/Schema    │ ★★       │ ★★★     │ ★★★★★   │ ★★★★★   │
│ 高性能/低延迟    │ ★★       │ ★★       │ ★★★★★   │ ★★       │
│ 双向流式通信     │ ★★★(依赖传输)│ ★(SSE有限)│ ★★★★★  │ ★        │
│ 浏览器原生支持   │ ★★★★★   │ ★★★★★   │ ★★(需grpc-web)│ ★★★ │
│ AI生态采用度     │ ★★★★(MCP)│ ★★★★★   │ ★★★★    │ ★        │
│ 区块链生态采用度 │ ★★★★★   │ ★★★     │ ★★       │ —        │
│ 学习曲线(低=好)  │ ★★★★★   │ ★★★★    │ ★★       │ ★        │
└─────────────────┴──────────┴──────────┴──────────┴──────────┘

JSON-RPC 1.0 vs 2.0

上下游

上游依赖（JSON-RPC 消费什么）

┌─────────────────────────────────────────────────┐
│              JSON-RPC 2.0 协议层                 │
├─────────────────────────────────────────────────┤
│ 依赖层                │ 说明                     │
├───────────────────────┼─────────────────────────┤
│ JSON 规范 (RFC 8259)  │ 消息编码格式              │
│ 传输层                │ HTTP / WebSocket /       │
│                       │ TCP / stdio / Unix Socket│
│ UTF-8 (RFC 3629)      │ 字符编码                 │
└───────────────────────┴─────────────────────────┘

下游影响（谁依赖 JSON-RPC）

┌─────────────────────────────────────────────────────────┐
│                   JSON-RPC 2.0 消费者                     │
├──────────────────┬──────────────────────────────────────┤
│ 领域             │ 具体消费者                             │
├──────────────────┼──────────────────────────────────────┤
│ AI Agent/工具    │ MCP (Anthropic), LangChain 工具层,    │
│                  │ CrewAI, AutoGPT 部分通信层             │
│ IDE/开发工具     │ LSP (Language Server Protocol),       │
│                  │ VS Code, Neovim, JetBrains            │
│ 区块链           │ Ethereum (Geth/Erigon/Nethermind),    │
│                  │ Bitcoin Core, Solana (部分API),       │
│                  │ EVM-compatible chains                 │
│ 桌面应用         │ Electron IPC (部分插件架构)             │
│ 嵌入式/IoT       │ 轻量设备管理 API [估算]                │
└──────────────────┴──────────────────────────────────────┘

关键指标

评估 JSON-RPC 实现质量的维度

供需与市场数据

JSON-RPC 直接市场规模

JSON-RPC 是开放协议，本身不产生直接收入。其产业价值体现在上层生态的市场规模。

开源实现生态

代表公司与资本映射

投资逻辑

核心观点

JSON-RPC 本身不是投资标的，但它是 三个高增长叙事的通信底层：

1. AI Agent 工具连接层：MCP 生态正在快速扩张，JSON-RPC 2.0 是其指定协议。投资逻辑是”MCP 协议栈”——类比 2015 年投资 REST API 生态。

   • 产业观察方向：MCP 服务器聚合平台、MCP 工具市场、MCP 网关安全产品

2. 链上基础设施：Ethereum L1/L2 的 RPC 节点服务是区块链基础设施中最稳定的收入来源之一（按请求量计费）。

   • 产业观察方向：RPC Provider（Alchemy、QuickNode）、去中心化 RPC 网络（Pocket Network、Lava Network）

3. 开发者工具链：LSP 让 AI 编程助手（Copilot、Cursor、Devin 等）能理解代码语义，JSON-RPC 是其中的通信骨干。

   • 产业观察方向：AI-native IDE、AI 编程 Agent

风险因素

• 性能瓶颈：JSON 文本编码在超高频 RPC 场景下可能被二进制协议（gRPC、FlatBuffers）替代
• 协议演进不确定性：MCP 规范仍在快速迭代，传输层从 stdio 向 Streamable HTTP 迁移中可能出现不兼容变更
• 安全暴露面：JSON-RPC over HTTP 天然暴露在网络攻击面下，注入/伪造请求是持续风险

常见误读纠偏

❌ 误读 1：“JSON-RPC 只能跑在 HTTP 上”

纠偏：JSON-RPC 2.0 Spec 明确声明传输无关（transport agnostic）。实际上：

• LSP 跑在 stdio 上（进程间通信）
• MCP 支持 stdio 和 Streamable HTTP（2024-11 spec 之后的方案）
• Ethereum 跑在 HTTP/HTTPS 和 WebSocket 上（ws 支持订阅）
• 部分嵌入式场景 跑在 Unix Socket 或 TCP 上

HTTP 只是最常见的暴露方式，不是唯一选择。

❌ 误读 2：“JSON-RPC 是 REST 的替代品”

纠偏：两者根本不是同一层面的东西。

• REST 是一种架构风格（面向资源、利用 HTTP 动词语义、无状态）
• JSON-RPC 是一种RPC 协议（面向方法调用，传输无关）

实际上两者可以共存：同一个服务可以同时暴露 RESTful API（面向 CRUD）和 JSON-RPC API（面向复杂操作）。Ethereum 就是典型——大部分 API 走 JSON-RPC，但部分场景（如 EIP-4844 blob 交易）需要不同的接口模式。

❌ 误读 3：“JSON-RPC 2.0 比 1.0 只多了版本号”

纠偏：2.0 是重大升级。关键差异包括：

• 新增 By-Name params（1.0 仅支持 By-Position 数组）
• 新增 批量调用（Batch）
• 新增 标准错误码（-32700 到 -32099）
• Notification 语义更明确（无 id = 不期望响应）
• 新增 jsonrpc: "2.0" 版本标识，允许 1.0/2.0 协议共存

❌ 误读 4：“JSON-RPC 性能太差，不适合生产环境”

纠偏：需要分场景看。

• 对于工具调用频率在每秒数十到数百次的 AI Agent 场景，JSON-RPC 的性能完全足够
• 对于高频交易、实时数据推送等场景，JSON 文本编码确实是瓶颈
• Ethereum 全网 JSON-RPC 请求量级为每天数十亿次（仅 Infura 一家，据 Consensys 公开信息），证明在有合理基础设施支撑下可扩展性不是问题

❌ 误读 5：“MCP 只是包装了一层 JSON-RPC，没有技术含量”

纠偏：JSON-RPC 只是传输层约定，MCP 的核心价值在于：

• 标准化的 能力协商（initialize 握手，动态发现 server 支持的 tools/resources/prompts）
• 工具描述的 JSON Schema 标准
• 采样（sampling） 能力——Server 可以反向请求 Client 端的 LLM 完成推理
• 根目录（roots）、资源订阅（resource subscriptions） 等生命周期管理

把 MCP 等同于 JSON-RPC，就像把 HTTP 等同于 TCP——忽略了上层协议的设计。

学习路径

入门（1-2 小时）

1. 阅读 JSON-RPC 2.0 Specification（短，约 30 分钟可读完）