一句话定义：JSON-RPC 是一种用 JSON 编码的远程过程调用（Remote Procedure Call）协议——双方事先约好格式，一方发出「调用哪个方法、传什么参数」的消息，另一方回一条「结果或错误」的消息。
一条消息长什么样
请求只有四个字段：jsonrpc（协议版本）、method（方法名）、params（参数）、id（本次调用的编号）。响应带回同一个 id，外加 result 或 error。
打个生活化的比方：这像一张标准化的点菜单。桌号是 id，菜名是 method，「少放辣、加个蛋」是 params。后厨做好后端出来的盘子上贴着同一个桌号，前台就知道这盘菜属于哪桌，不会串台。如果压根没有 id，那就是「顺手帮我带杯水」——这类消息叫通知（notification），不需要回应。
和相邻概念的区别
REST 的思路是「我这里有哪些资源，你用 GET/POST 去操作」；JSON-RPC 的思路是「我这里有一张方法表，你喊名字、给参数」。更关键的是，JSON-RPC 不关心传输层：可以走 HTTP，可以在标准输入输出（stdio）上一来一回，也可以走 WebSocket。
| JSON-RPC | REST | gRPC | |
|---|---|---|---|
| 抽象单位 | 方法 | 资源 | 方法 |
| 数据格式 | JSON 文本 | JSON/文本为主 | Protocol Buffers 二进制 |
| 传输 | 任意（HTTP/stdio/WebSocket） | 通常 HTTP | 通常 HTTP/2 |
| 能否直接人读 | 能 | 能 | 不能，需工具解码 |
为什么 AI 从业者绕不开它
两个绕不开的协议直接建在 JSON-RPC 2.0 之上。一个是编辑器生态里的 LSP（Language Server Protocol），你在 IDE 里敲代码时的补全、跳转定义、报错红波浪线，底下全是这些消息在跑。另一个是 MCP（Model Context Protocol），也就是让模型接上外部工具和数据源的协议：初始化握手、列出有哪些工具、真正调用某个工具，每一步都是一条 JSON-RPC 消息。
所以当模型说「我要调用 write_file」，线上真正流过的通常是类似这样的东西：
```json
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"write_file","arguments":{"path":"a.txt"}}}
```
对普通人的意义
AI 能读文件、改代码、查数据库，并不是魔法，而是一次次带编号的方法调用。它失败时返回的也是结构化 JSON，比如错误码 -32601 表示「方法不存在」，往往意味着两边对工具名的理解对不上；id 对不上，响应就会被直接丢弃，表现为「调用发出去了却没反应」。
调这类问题的第一现场，永远是原始的请求/响应日志。理解这四个字段，你就拿到了看懂 MCP、LSP 和各类工具调用框架的钥匙。协议规范细节以官方页面为准。