LLM 交互协议基础：协议是什么

概览

概念

件事

层拆解

金句

项目	说明
本卡定位	LLM 协议系列入门页 · 后续页面将沿此页往下展开
前置知识	无（会写 `json.loads` 即可）
读完去哪儿	llm-chat-protocol-guide.html 7 讲协议讲义 / llm-api-schema-reference.html 三协议 Schema 参考

第一讲 · 协议是什么

第 1 讲 · 1 概念 + 0 实验

协议是什么：一次完整推理回合的契约

很多人把 LLM 协议理解为"聊天的格式"——你发一句，它回一句。其实一轮交互至少要装下五件事、两层结构。所谓协议，不是消息长什么样，是一次完整推理回合的契约。

5 件事（一次完整交互的最小集合）

请求-响应骨架：你按格式发 JSON，服务端按约定回 JSON
工具调用：你声明 tools 列表，模型选一个执行，结果塞回 messages 继续推
流式输出：模型 token-by-token 推过来（SSE），不是一次吐完
状态延续：多轮对话靠 messages 列表把上文捎带过去
错误与终止：finish_reason 告诉你为什么停、超时/截断如何处理

两层拆解（结构 vs 传输）

消息结构层：JSON 是事实标准（OpenAI / Anthropic / Ollama / 几乎所有开源推理服务）
传输层：HTTP（同步） / SSE（流式） / WebSocket（双向长连接） / gRPC（高性能场景）

教学金句：所谓协议，不是聊天的格式，是一次完整推理回合的契约。

协议讲义主页三协议 Schema 参考

第 1 讲 · 1 图示 + 0 实验

一轮交互的循环结构

把"5 件事"按时间顺序画出来，核心只有两条路径：需要 tool 就回到 A 重新组装请求，不需要就一路推到 finish_reason 终止。流式输出只是在"返回内容"这一步换 SSE 推 token，不改变循环形状。

flowchart TB A["组装 JSON 请求
含 messages + 可选 tools"] --> B["HTTP POST 到推理服务"] B --> C["服务端读 + 模型推理"] C --> D{"需要 tool?"} D -- "是" --> E["返回 tool_calls"] E --> F["客户端执行 tool"] F --> G["结果作为 message 塞回"] G --> A D -- "否" --> H["返回 finish_reason + 内容
（流式时 SSE 逐 token 推）"]

图 1 · 一次完整推理回合的两条路径：tool 循环（外环） / 终止（内收）

看图要点：循环的"返回点"是 A 不是 B —— 你重新组装的是整个 messages 列表（包含 tool 的执行结果），不是只把结果塞回服务端。这正是"状态延续"机制的核心。

下一篇：tool_calls 全链路 Schema 参考

第 1 讲 · 1 图示 + 1 表 + 1 收口

传输层 4 种变体：HTTP / SSE / WebSocket / gRPC 怎么选

消息结构层（message-structure）解决了"消息长什么样"，传输层解决"消息怎么送"。4 种变体不是"谁替代谁"的关系，是"不同场景用不同"的关系。下面 2 张图 + 1 张对比表，是整组讲义的心智模型插图——可以下载下来贴桌面或分享给团队。

图 2 · 4 种变体的时序对比（"是什么"——协议在时间轴上长什么样）

sequenceDiagram autonumber participant C as 客户端 participant S as 推理服务 rect rgb(238, 241, 248) Note over C,S: HTTP 同步（最简单） C->>S: POST + JSON S-->>C: 200 OK + JSON（含 finish_reason） end rect rgb(238, 241, 248) Note over C,S: SSE 流式（最常用 · 99% 场景） C->>S: POST + JSON（stream: true） loop 逐 token 推 S-->>C: data: {chunk}\n\n end S-->>C: data: [DONE]\n\n end rect rgb(238, 241, 248) Note over C,S: WebSocket 双向（少见） C->>S: HTTP/1.1 Upgrade: websocket S-->>C: 101 Switching Protocols Note over C,S: 全双工长连接 C->>S: {message} S-->>C: {message} end rect rgb(238, 241, 248) Note over C,S: gRPC + Protobuf（内部英雄） C->>S: HTTP/2 + protobuf S-->>C: protobuf binary Note over C,S: 4 种 RPC 模式（unary / server-stream / client-stream / bidi） end

图 2 · 4 种变体的时序对比：客户端与推理服务之间的 4 种"送消息"方式（看 协议签名）

图 3 · 选型决策树（"怎么选"——给定场景该用哪种）

flowchart TB Start["你要选哪种传输层？"] --> Q1{"需要流式输出？"} Q1 -- "否" --> Http["HTTP 同步
一次请求 / 一次响应
→ 简单问答 / 工具调用 / 批处理"] Q1 -- "是" --> Q2{"需要双向通信？"} Q2 -- "否" --> Sse["SSE 流式
服务端→客户端流
→ 99% 的 LLM 流式场景"] Q2 -- "是" --> Ws{"高 QPS / 内部 RPC？
或需要强 Schema？"} Ws -- "是" --> Grpc["gRPC + Protobuf
HTTP/2 + 4 RPC 模式
→ 推理服务内部 / Agent ↔ Agent"] Ws -- "否" --> Ws2["WebSocket
升级握手 + 全双工
→ 实时对话 UI / 多人协作"]

图 3 · 选型决策树：3 个判断点收敛到 4 种变体（看 决策路径）

4 种变体对比（4 个维度）

变体	形态	双向	典型 LLM 场景
HTTP Hypertext Transfer Protocol，超文本传输协议	一次性请求-响应	否	简单问答、工具调用、批处理
SSE Server-Sent Events，服务器单向推送	一次性建立，服务端→客户端流	否	流式输出（99% 场景）、打字机效果
WebSocket 浏览器与服务端的全双工长连接协议	升级握手，全双工长连接	是	实时对话 UI、多 Agent 协作
gRPC + Protobuf Google 开源 RPC 框架 + 二进制序列化格式	HTTP/2 + 4 种 RPC 模式	是	推理服务内部、Agent ↔ Agent RPC

心智模型一句话：消息结构层 = 装什么（JSON vs Protobuf）；传输层 = 怎么送（HTTP / SSE / WS / gRPC）——两层正交，组合出 4×2 = 8 种可能。LLM 公开 API（Application Programming Interface，应用程序接口）99% 落在"JSON + SSE"那一格里。

姊妹：消息结构层下一篇：协议讲义 MDN · SSE

读完去哪儿

这一页是整个 LLM 协议系列的入口与底层定义。读完协议是什么之后，可以从两条路径往下走：

心智模型路径（推荐先走）：llm-chat-protocol-guide.html —— 7 篇讲义，以 Chat Completions 为主线，对照 Responses / Messages，建立"协议怎么用"的心智
字段参考路径（查结构时翻）：llm-api-schema-reference.html —— 三套协议的完整 Schema 定义 + 翻译词典