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 基礎設施臺前：

時間線	事件	為什麼重要
2016	Microsoft 釋出 LSP（Language Server Protocol），底層通訊選 JSON-RPC 2.0 over stdio/ TCP	所有現代 IDE（VS Code、Neovim、JetBrains）的程式碼智慧都走這條路；AI 程式設計助手（Copilot、Cursor）依賴 LSP
2022-2024	Ethereum 生態持續擴充套件，執行層客戶端（Geth、Erigon 等）標準 API 為 JSON-RPC	鏈上 AI Agent 與智慧合約互動的橋樑
2024-2025	Anthropic 釋出 MCP（Model Context Protocol），顯式基於 JSON-RPC 2.0	LLM 與外部工具/資料來源連線的事實標準開始成型

產業意義：

AI Agent 通訊的最低公約數：當多個 Agent 架構（LangChain、AutoGPT、CrewAI 等）需要互操作時，JSON-RPC 提供了最輕量、最無依賴的呼叫約定。
MCP 生態的承載協議：Anthropic MCP 定義了 tools/list、tools/call、resources/list、prompts/list 等標準 method，底層就是 JSON-RPC 2.0 的 request/response/notification 三種訊息型別。
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]：

Code	Meaning	說明
-32700	Parse error	JSON 解析失敗
-32600	Invalid Request	不是合法的 Request 物件
-32601	Method not found	方法不存在
-32602	Invalid params	引數無效
-32603	Internal error	內部錯誤
-32000 to -32099	Server error (保留區間)	服務端自定義

在 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) │
   └──────────┘     └────────────┘    └──────────────┘

關鍵設計決策與技術權衡

設計決策	原因	代價
JSON 文本編碼	可讀、零依賴、全語言支援	效能開銷（解析慢、體積大），不適合高頻 RPC
無 schema 強制	降低接入門檻	介面契約需外部文件維護（MCP 用 JSON Schema 補充）
傳輸無關	最大靈活性	需要各傳輸層自行解決連線管理、分幀、重連
id 型別允許 string/number/null	相容不同場景	增加了實現的邊界情況處理
批次呼叫中允許混合 Request/Notification	靈活性	部分實現未完整支援批次中的 Notification

關鍵引數與效能特徵

以下為行業經驗性資料，非 Spec 定義，標 [估算]。

指標	典型值	備註
單條訊息編碼開銷	JSON 文本，典型 Request 100-500 位元組	取決於 method 名和 params 複雜度 [估算]
序列化/反序列化延遲	10-100μs（單條）	取決於 JSON 庫和 payload 大小 [估算]
與 gRPC Protobuf 對比	體積 2-10x，編碼/解碼延遲 3-10x	JSON vs Protobuf 的固有差距 [估算]
最大批次請求大小	Spec 未定義，由傳輸層/實現決定	MCP 典型實現限制各異 [未充分揭露]

技術演進史

時間	里程碑	關鍵變化
2005	JSON-RPC 1.0 草案	最初由 JSON 之父 Douglas Crockford 推動；僅支援 Request、Response、Notification 三種訊息；params 只支援陣列（By-Position）
2006	JSON-RPC 1.1 社群釋出	非正式規範，引入型別化引數改進；未經過 W3C 標準化流程
2010-2013	JSON-RPC 2.0 草案迭代	社群（json-rpc@googlegroups）長期討論；引入 `jsonrpc: "2.0"` 版本標識、By-Name params、批次呼叫、標準錯誤碼
2010-03-26	JSON-RPC 2.0 Specification 釋出	成為事實標準至今
2016	Microsoft LSP 1.0 釋出	JSON-RPC 2.0 被選為 LSP 的基礎協議，執行在 stdio/TCP 上；大幅提升了 JSON-RPC 在 IDE 生態的採用率
2020-2023	Ethereum JSON-RPC API 持續擴充套件	eth_getBalance、eth_call、eth_sendRawTransaction 等成為鏈上互動事實標準
2024-11	Anthropic MCP 正式釋出	JSON-RPC 2.0 成為 LLM 工具呼叫標準協議層；傳輸層支援 stdio + Streamable HTTP
2025 Q1-Q2	MCP 生態爆發	OpenAI、Google、Microsoft 相繼宣佈支援 MCP；JSON-RPC 在 AI Agent 基礎設施中地位確立

技術路線對比

RPC 協議選型矩陣（面向 AI 場景）

維度評分: ★★★★★ 最優   ★ 最低   — 不適用

┌─────────────────┬──────────┬──────────┬──────────┬──────────┐
│ 協議             │JSON-RPC 2│ REST/HTTP│  gRPC    │  SOAP    │
│                 │          │          │          │(已邊緣化)│
├─────────────────┼──────────┼──────────┼──────────┼──────────┤
│ 輕量級/易接入    │ ★★★★★   │ ★★★★    │ ★★       │ ★        │
│ 人類可讀/可除錯  │ ★★★★★   │ ★★★★★   │ ★★       │ ★★★     │
│ 傳輸層靈活性     │ ★★★★★   │ ★★★     │ ★★       │ ★        │
│ 強型別/Schema    │ ★★       │ ★★★     │ ★★★★★   │ ★★★★★   │
│ 高效能/低延遲    │ ★★       │ ★★       │ ★★★★★   │ ★★       │
│ 雙向流式通訊     │ ★★★(依賴傳輸)│ ★(SSE有限)│ ★★★★★  │ ★        │
│ 瀏覽器原生支援   │ ★★★★★   │ ★★★★★   │ ★★(需grpc-web)│ ★★★ │
│ AI生態採用度     │ ★★★★(MCP)│ ★★★★★   │ ★★★★    │ ★        │
│ 區塊鏈生態採用度 │ ★★★★★   │ ★★★     │ ★★       │ —        │
│ 學習曲線(低=好)  │ ★★★★★   │ ★★★★    │ ★★       │ ★        │
└─────────────────┴──────────┴──────────┴──────────┴──────────┘

JSON-RPC 1.0 vs 2.0

特性	1.0	2.0
版本標識欄位	無	`"jsonrpc": "2.0"` 必填
params 支援	僅陣列 (By-Position)	陣列 + 物件 (By-Position + By-Name)
批次呼叫	不支援	支援（JSON 陣列）
錯誤碼規範	無標準	定義 -32700 到 -32099 標準碼
Notification	有	有（明確語義：無 id 則無響應）
id 為 null	不合法	可用於錯誤響應（解析失敗時無法關聯 id）

上下游

上游依賴（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 實現質量的維度

指標	說明	行業基準參考
Spec 合規度	是否完整支援 2.0 的 Request/Response/Notification/Batch/Error	多數主流庫合規 [估算]
批次呼叫深度	單次 Batch 最大支援多少條 Request	Spec 未限，由實現決定
傳輸層適配數	支援幾種傳輸層（HTTP/WS/TCP/stdio…）	多數庫 2-3 種 [估算]
雙向呼叫能力	Client/Server 是否都能發起 Request	MCP 要求雙向；基礎庫多數僅 Client→Server
序列化效能	單條訊息編解碼吞吐	JSON 庫效能差異顯著（simdjson > rapidjson > 標準庫）[估算]
併發模型	單連線複用 / 多路複用 / 連線池	Spec 不涉及，由傳輸層決定
錯誤處理完備性	是否實現全部標準錯誤碼 + Server Error 區間	[未充分揭露]

供需與市場資料

JSON-RPC 直接市場規模

JSON-RPC 是開放協議，本身不產生直接營收。其產業價值體現在上層生態的市場規模。

生態	相關市場規模	資料來源
MCP 生態	MCP 伺服器/工具市場尚處早期，無獨立市場資料	[未充分揭露]
LSP 生態	全球 IDE 與開發者工具市場 2024 年約 $XXB（JSON-RPC 是底層協議之一）	[行業報告-待確認]
Ethereum JSON-RPC	Ethereum 生態 TVL、RPC 節點服務（Infura/Alchemy/QuickNode）營收規模與 JSON-RPC 使用量直接掛鉤	[廠商財報] Alchemy 2021 估值 $3.5B; Infura 獨立營收未揭露
AI Agent 通訊	全球 AI Agent 市場 2025 年預估數十億美元，JSON-RPC (via MCP) 為主要通訊協議之一	[行業報告-待確認]

開源實現生態

語言	主流 JSON-RPC 庫	GitHub Stars (近似)
Python	`json-rpc`, `python-jsonrpc`	數百至數千 [估算]
JavaScript/TS	`jayson`, `json-rpc-2.0`	數百至千級 [估算]
Go	`go-ethereum/rpc` (Geth 內建), `gorilla/rpc`	Geth 極高,獨立庫數百 [估算]
Rust	`jsonrpsee` (Parity 出品)	數百級 [估算]
Java	`jsonrpc4j`	數百級 [估算]
C#	`StreamJsonRpc` (Microsoft 出品, LSP 使用)	數千級 [估算]

代表公司與資本對映

公司/組織	與 JSON-RPC 的關係	資本關注度
Anthropic	MCP 協議的定義者和推動者，MCP 基於 JSON-RPC 2.0	$60B+ 估值 (2025)
Microsoft	LSP 的創始者（底層為 JSON-RPC 2.0）；StreamJsonRpc 庫維護者；VS Code 核心架構	萬億市值
Ethereum Foundation / Consensys	Ethereum JSON-RPC API 標準維護	Consensys 估值約 $7B (2022)
Alchemy / Infura (Consensys) / QuickNode	提供 JSON-RPC 節點即服務（Blockchain RPC Provider）	Alchemy ~$10.2B (2022), QuickNode ~$800M (2024)
Geth 核心團隊	Go-Ethereum 客戶端，其 `rpc` 包是最廣泛使用的 JSON-RPC 實現之一	開源社群
Parity (now part of Polkadot)	`jsonrpsee` Rust 庫，用於 Substrate 區塊鏈節點	Polkadot 生態

投資邏輯

核心觀點

JSON-RPC 本身不是投資標的，但它是 三個高增長敘事的通訊底層：

AI Agent 工具連線層：MCP 生態正在快速擴張，JSON-RPC 2.0 是其指定協議。投資邏輯是”MCP 協議棧”——類比 2015 年投資 REST API 生態。
- 產業觀察方向：MCP 伺服器聚合平台、MCP 工具市場、MCP 閘道器安全產品
鏈上基礎設施：Ethereum L1/L2 的 RPC 節點服務是區塊鏈基礎設施中最穩定的營收來源之一（按請求量計費）。
- 產業觀察方向：RPC Provider（Alchemy、QuickNode）、去中心化 RPC 網路（Pocket Network、Lava Network）
開發者工具鏈：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 小時）

閱讀 JSON-RPC 2.0 Specification（短，約 30 分鐘可讀完）