API 参考

流式响应

边生成边读取内容，正确处理事件、超时与中途中断。

什么时候适合流式#

聊天界面和编程助手需要尽早展示输出时，可使用流式响应。流式让应用逐段接收内容，不必等整段生成完毕；它改变展示和读取方式，不保证总生成时间一定更短。

先使用一个简单的 Chat Completions 请求#

以下 Bash 示例使用 Codex-Pro Key。先按认证教程设置环境变量，然后在同一终端运行。-N 让 curl 不缓冲输出，便于观察收到的数据。

curl -N --connect-timeout 15 --max-time 180 \
  https://lensapi.top/v1/chat/completions \
  -H "Authorization: Bearer $LENSAPI_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{"model":"gpt-5.5","messages":[{"role":"user","content":"用三句话解释流式输出。"}],"stream":true}'

示例中的超时是客户端本次测试设置，不代表站点承诺的最大请求时长。慢任务需要按你的工作流评估等待时间，并结合日志检查结果。

应用中要按事件读取#

不要把整个流式响应交给一次性的 JSON 解析。Chat Completions 和 Responses 的事件结构不同，应使用匹配协议的客户端或解析器，并正确处理结束事件、错误事件和断开连接。工具调用还可能跨多个片段到达，必须等待字段完整后再执行。

没有立即显示内容时#

先确认请求确实启用 stream，再检查客户端是否一边读取一边显示。某些应用会等请求完全结束才渲染，看起来仍像非流式；网络代理缓冲也可能导致内容成批出现。模型开始输出前的排队和推理仍会影响等待时间。

断开后不要直接从头重发#

保存已收到的内容和任务状态，核对使用日志后再决定重试。中断不代表原请求没有执行或不会产生费用，也不保证可从断点恢复。涉及工具外部动作的应用，应由业务逻辑避免重复执行。

如果连续出现长时间停顿，按延迟排查记录首次内容时间和中断时间，再结合错误排查处理。