JSON-RPC：
你点发送后，两个程序怎样对话？
它是一套让程序用固定格式“提出请求、返回结果”的通信约定。可以把它看作程序之间通用的办事单格式。[规范]
Remote Procedure Call，通常译为“远程过程调用”。直白说，就是这个程序请另一个程序执行一个操作。
“远程”不一定是另一台电脑。两个程序也可以在你的同一台电脑上。
回到你最熟悉的操作：在旧 Thread 里发送新问题
你已经知道这会开始一个新 Turn。接下来看看界面和后台如何用消息协调这件事。这里的后台是 Codex 的 App Server——接收界面操作请求的程序部分。[Codex 生命周期]
{
"id": 42,
"method": "turn/start",
"params": {
"threadId": "thread_abc",
"input": [{ "type": "text", "text": "帮我检查这段代码" }]
}
}
人话：这是第 42 号请求。请在 thread_abc 这段对话里，用这条输入开始一轮工作。
本页只是演示，不发送任何真实请求。假设已有可用 Thread 且连接已初始化；ID 为虚构值，响应和结束通知只展示重点字段。
这张办事单，先认四个位置
| 位置 | 人话 |
|---|---|
method | 要对方执行的操作名。turn/start 是 Codex 定义的操作，不是 JSON-RPC 自带的操作。 |
params | 做这件事需要的资料：在哪个 Thread、处理什么输入。 |
id | 这次请求的编号；响应用同一个编号对应回来。它和 threadId 不是同一个东西。 |
result / error | 响应里的成功结果或错误信息。 |
请求字段 · 响应字段 · Codex 的操作名
turn/start 的直接响应说明这轮已创建，不代表工作已完成。运行过程中的文字、工具进度和结束状态，通过后续 Notification 继续传回来。Notification 就是“单向告诉你一件事”，没有顶层请求 id，接收方不为它发送 JSON-RPC 响应。不过它的内容仍可以带 threadId、turnId，说明是哪段对话、哪一轮的变化。[通知规则]
为什么这里没有标准里的 "jsonrpc": "2.0"？
标准 JSON-RPC 2.0 消息要求携带这个版本字段。本地学习的 Codex App Server 版本采用了一个明确约定：在线路消息中省略它。因此这里展示 Codex 格式，不把它冒充成未经改动的标准格式。
它就是 HTTP、或者模型 API 吗？
不是。JSON-RPC 约定消息怎么组织；消息可以经不同通道传递。这里讲的是 Codex 界面与 App Server 的交互，不是 Codex 向模型请求答案时的全部接口。也不是让你在聊天框手写 JSON：通常由界面程序负责组织。
立即试一下
第 42 号请求的响应，顶层 id 应该是什么？
收到 turn/start 的成功响应，就说明代码已经检查完了吗？
已答对 0 / 2。理解后，再用自己的话告诉我 JSON-RPC 在这里负责什么。