导读：这不是「怎么用 Cursor」的功能教程，而是一篇传输层选型笔记。我们不聊快捷键，也不重讲整套 IDE 架构，只回答一个更窄的问题——当你在 Network 里看到长时间 pending、h2 被降成 http/1.1、Agent 中途哑火时，到底该怀疑哪一层协议？
全文脉络：抓包现象 → 四种协议对照 → 双向会话卡点 → 分道与超时 → 失败模型 → 选型清单。读完你会得到一张 REST / SSE / WebSocket / HTTP/2 怎么选的对照表，以及一套可自己验收的抓包步骤。
架构总图可先看上一篇：深入 Cursor 架构：一个 AI 编辑器是如何被「流式」重塑的。本文默认你已有那张总图，只往通信协议再钻一层。
若你更想先上手排查国内链路，可直接从这几篇实操文进场：代理超时与 HTTP/1.1、Tab 补全变慢排查、Chat / Composer / Agent 区别。
一、先从抓包读现象，别先猜模型
多数人排障会先换模型。更省时间的入口是打开开发者工具 Network，先分清你看到的是哪类流量：
| 你看到的现象 | 更可能落在哪一层 | 不该先做的事 |
|---|---|---|
请求长时间 pending，响应体持续增长 | 真·服务端流 / 长连接 | 先骂模型变笨 |
| 数秒后一次性 200，正文整包出现 | 假流式（整包 REST 或伪流） | 继续加 prompt |
协议列从 h2 变成 http/1.1 | 代理 / 中间盒降级 | 先换更贵模型 |
| 只有 Tab 钝、对话还行 | 轻通道被拖死或超时过短 | 在重通道上狂改 Rules |
| Agent 跑到一半突然停 | 流中断或工具回传失败 | 直接重开十次同一会话 |
flowchart TD
A[打开 Network] --> B{请求形态}
B -->|持续 pending| C[按长连接流排查]
B -->|整包一次性返回| D[怀疑假流式]
B -->|h2 变 http1.1| E[查代理与中间盒]
B -->|仅补全慢| F[查轻通道超时]
图 1 · 先读 Network 现象，再决定查协议还是查模型
这张表的用处很简单：协议问题长得像模型问题。分不清，就会在错误的层浪费下午。
国内链路里，代理超时与 HTTP/2 降级是高频坑；可对照这篇逐步自查：Cursor 代理超时怎么排查：从 Network 诊断到 HTTP/1.1。
二、四种协议对照：谁能把「流」当一等公民
下面按「能不能把流式当第一性假设」来比，不按时髦排名。
| 协议 | 擅长 | 短板 | 更适合 |
|---|---|---|---|
| REST | 拉配置、查账单、一次算完的短任务 | 整包才返回；「边出边看」只能轮询或自拼分片 | 旁路，不扛 Agent 主会话 |
| SSE | 服务端单向推 token；实现成本低，防火墙友好 | 半双工；工具结果通常另开请求 | 只要下行推字的对话 |
| WebSocket | 真正双向帧；自定义事件协议灵活 | 多路复用、背压、鉴权刷新、代理兼容都得自己扛 | 团队能维护会话协议时 |
| HTTP/2 流语义 | 一条连接多条 stream；补全与长对话可共存 | 具体 path 以官方与抓包为准，别把推测当规范 | 编辑器这类「多交互并存」场景 |
常见翻车：❌ 业务先按 REST 写完，最后「接个 SSE」——重试、半包、工具回传全线另起炉灶。WebSocket 也别当银弹：双向强，运维成本也强。
flowchart LR
A[只要单向推字] --> B[SSE 往往够]
C[模型说话加工具回传] --> D[需要双向会话]
E[补全与对话共存] --> F[还要分道或多路复用]
图 2 · 协议能力对照：单向推字、双向会话、多路复用不是同一档需求
一张决策直觉：
| 你的数据流形态 | 更贴的协议取向 |
|---|---|
| 只要单向推字 | SSE 往往够用 |
| 模型输出 + 本地工具来回，同属一次回答 | WebSocket 或 HTTP/2 双向流 |
| 还要高频补全不拖垮对话 | 还必须分道（独立连接或独立 stream 预算） |
三、双向会话：卡的是「回传」，不是「第一个字」
很多人以为流式 = 能看到第一个 token。对聊天可以；对 Agent 不够。
Agent 真正吃协议的地方是：下行事件（继续生成 / 调工具）和上行结果（文件内容 / 命令输出）必须落在同一次会话语义里。若下行走 SSE、上行拆成一串互不相关的 REST：
- 断线后不知道重放到哪一步；
- 工具副作用可能跑两遍；
- UI 很难区分「模型还在想」还是「结果没传回来」。
flowchart TD
A[一次回答] --> B[下行 文本或工具调用]
A --> C[上行 工具执行结果]
B --> D[同一会话语义]
C --> D
D --> E[可取消 可恢复 可幂等]
图 3 · Agent 卡点在工具回传，不在首字延迟
所以选型时先问：我有没有「必须回传」的本地动作？有，就别用半双工硬拼。
BYOK / 自定义 API 往往只覆盖允许外接的对话通道，并不自动等于「所有能力都换了协议路径」。边界可看：Cursor BYOK 怎么配置：自带 API Key 的边界与省钱账。
四、分道与超时：为什么「对话还行、Tab 很钝」
补全和对话对延迟的要求差一到两个数量级。成熟做法不是「所有 AI 流量进一个接口」：
- **轻通道：**补全；超时短、payload 小、失败快放弃；
- **重通道：**对话 / Agent；允许长时流与工具往返；
- **旁路：**索引、埋点；异步批量。
flowchart LR
UI[编辑器] --> L[轻通道 补全]
UI --> H[重通道 对话]
L --> T1[短超时]
H --> T2[长超时]
图 4 · 轻通道与重通道各设超时，避免互相拖死
落地现象：
- ❌ 共用一个 60s 网关超时 → 按键补全被长任务拖死；
- ✅ 各通道各预算；代理出问题时先问「哪条通道在报错」。
若你遇到的是「只有 Tab 慢」，优先按轻通道排查，而不是先改 Agent prompt。可对照：Cursor Tab 补全很慢国内：五类原因与排查清单。Chat / Composer / Agent 用法边界见：Chat、Composer、Agent 到底啥区别。
五、失败模型：断流、半包、降级
流式难点不在「推得出第一个 token」，而在中途出事：
| 故障 | 用户体感 | 优先动作 |
|---|---|---|
| 中途断流 | 模型突然哑了 | 看是否可恢复；查休眠 / 代理 idle |
| 半包乱序 | 工具边界错乱 | 按事件流解析，别当整包 JSON |
| 盲目重试 | 命令跑两遍 | 会话 / 步骤幂等，或只重连不重放 |
| 协议降级 | 突然变慢易超时 | 查 h2→http/1.1 与中间盒 |
flowchart TD
A[长连接异常] -->|断流| B[可恢复提示]
A -->|半包| C[按事件边界重解析]
A -->|降级| D[检查代理]
A -->|重复副作用| E[补幂等]
图 5 · 流式失败清单：先定故障类型，再定动作
怎么验收（可执行）
- 触发一次对话 / Agent：确认请求是持续
pending，不是整包秒回； - 看协议列：优先确认是否仍是
h2； - 有工具调用时：确认回传发生在同一会话，不是新开聊天；
- 断网再恢复：看客户端是提示重试，还是静默卡死；
- 对比 Tab 与对话：只慢一边时，按分道查对应通道。
验收通过的标志：你能指出「哪条连接 / 哪类请求」在承载当前交互，且超时策略与该通道延迟预算一致。
六、给自建 AI 功能的选型清单
抛开具体编辑器品牌，做自己的 AI 功能时可以按这张清单过一遍：
- ✅ 先画数据流：单向推字，还是必须双向回传；
- ✅ 先定延迟预算：有没有「几十毫秒级」的高频路径要单独分道；
- ✅ 协议服务于约束：别先选时髦协议再倒逼产品形态；
- ✅ 失败模型写进设计：断流、半包、幂等、降级都有着落；
- ✅ 用 Network 验收，别用感觉验收；
- ✅ 需要排障手册时，优先查通道与代理，再换模型。
flowchart LR
A[数据流形态] --> B[延迟预算]
B --> C[协议选型]
C --> D[失败模型]
D --> E[Network 验收]
图 6 · 选型顺序：数据流 → 延迟预算 → 协议 → 失败模型
小结
传输层选型的关键不是背名词，而是把三类问题分开：
- 假流式还是真长连接——看 pending 还是整包；
- 单向推字还是双向会话——看有没有工具回传；
- 单通道还是分道——看补全与对话是否互相拖死。
架构总图仍建议回看：深入 Cursor 架构：一个 AI 编辑器是如何被「流式」重塑的。若你正在排国内链路、代理降级或 Tab 变慢，可以直接从这些实操文继续：代理超时与 HTTP/1.1、Tab 补全变慢排查、BYOK 边界。
