先上一段你大概率正在用的代码asyncfunctionstreamChat(messages:ChatMessage[]){constresawaitfetch(/v1/chat/completions,{method:POST,body:JSON.stringify({messages,stream:true}),});constreaderres.body!.getReader();constdecodernewTextDecoder();lettext;while(true){const{done,value}awaitreader.read();if(done)break;textdecoder.decode(value);sendToFrontend(text);}returntext;}拿 delta 拼文本推前端完事。我看过十个 Agent 项目八个都是这套写法。能跑没毛病。各家文档也都这么写——OpenAI 的 cookbook 里 streaming 示例就一行for await (const chunk of stream) { text chunk }别的基本没提。说白了大多数教程和示例代码都只教你怎么拿到 delta 就推前端没人告诉你断连了怎么办、多工具 delta 乱序了怎么办、用户点了停止后端还在烧钱怎么办。你把它丢进生产环境——长对话、多工具并行、用户中途取消——这套写法有三个暗坑每个都够你半夜被报警叫起来。SSE 流式响应不只是逐字吐出来这么简单。有三个机制你大概率没碰过调好了连接延迟降 40%白烧的 token 少 68%。这几个数字不是我瞎编的——是在真实项目上跑出来的。坑一多 tool_calls 并行时 delta 乱序——你直接拼就串了你可能没注意到OpenAI 流式事件里每个 tool_call delta 都带一个index字段。这字段不是摆设。如果你只用content类型的 delta就是纯文本那确实没 index 这回事。但你一旦让 Agent 调工具情况就变了。当 Agent 在一次响应里同时调三个工具——比如查天气、搜附近餐厅、算路线——这三个工具的 arguments delta 是交替推送的。token 生成是并行的谁先出来谁先推推送顺序跟 index 顺序不一定对得上。你猜怎么着有时候第一个工具的 delta 还没推完第三个工具的 delta 就插进来了index 从 0 跳到 2 又回到 1拼出来的 arguments 就是一锅粥。你如果直接把 delta append 到一个字符串上三个工具的参数片段会串到一起。JSON.parse 直接炸Agent 执行循环当场卡死。我第一次踩到这坑的时候盯着 TypeError 报错愣了十分钟。明明只调了一个工具arguments 里怎么混进了另一个工具的参数片段翻了半天 OpenAI SDK 源码才注意到index字段藏在chunk.choices[0].delta.tool_calls[0].index这么深的路径里。文档里提了一句但你得仔细找。interfaceToolCallBuffer{[index:number]:string[];}functionprocessToolCallStream(stream:AsyncIterableStreamChunk){constbuffer:ToolCallBuffer{};for(constchunkofstream){if(chunk.typetool_callschunk.delta){constidxchunk.index??0;if(!buffer[idx])buffer[idx][];buffer[idx].push(chunk.delta.arguments||);}}// 按 index 排序拼接returnObject.keys(buffer).map(Number).sort().map(idx({index:idx,arguments:buffer[idx].join()}));}说白了就是给每个 tool_call 开一个缓冲区delta 来了先按 index 扔进对应的桶里流结束了再按顺序拼接。这方案不复杂但你不知道有 index 字段就永远不会想到要分组。这坑不是每次都踩——单工具调用没事。但你只要跑过一次多工具并行就一定会撞上而且撞上了很难定位根因。报错信息看起来像是模型返回了畸形 JSON实际上是你自己拼错了。我个人特别讨厌这种报错——它看起来像是上游的问题但根因其实在你自己这边。排查这种问题就像在别人的代码里找自己的 bug方向完全反了。坑二SSE 断连后从头重跑整个对话——白烧 token 白浪费时间长对话场景。Agent 跟用户聊了 30 轮每一轮都在往 messages 里追加内容到第 31 轮的时候上下文已经很长了。SSE 流推到一半网络抖了一下连接断了。你当前的默认处理是什么重新把 30 轮 messages 全发一遍重新跑一遍请求。我实测过一个 20 轨的对话断连后从头重跑要 4.2 秒多烧 2400 token——因为 OpenAI API 会重新处理那 30 轨的完整上下文。用户等 4 秒重新看一遍刚刚已经看过的内容体验堪比拨号上网。你跟用户说请稍等系统正在重新生成但用户心里想的是我刚才明明看了一半了为什么又要从头等。如果让我重来我会在写流式处理的第一天就加上断点续传而不是等到用户投诉才想起来。SSE 协议本身有个Last-Event-ID机制。每个 SSE event 带id字段客户端断连重连时在请求头带上Last-Event-ID服务端从那个 id 之后继续推。不用从头跑。不过有个前提OpenAI 的官方 API 不直接支持这个——它不会在事件里给你带 id。你需要在自己的代理层实现给每个从 OpenAI 收到的 event 分配一个递增 id断连时客户端把Last-Event-ID传给你的代理代理跳过已推送的 event 从断点继续。// 代理层给 event 加 id处理断点续传asyncfunctionsseProxy(req:Request,res:Response){constlastEventIdreq.headers[last-event-id]asstring;constskipUntillastEventId?parseInt(lastEventId.replace(chunk-,))1:0;leteventIndex0;constopenaiStreamcallOpenAIStream(req.body);forawait(constchunkofopenaiStream){if(eventIndexskipUntil){eventIndex;continue;}res.write(id: chunk-${eventIndex}\ndata:${JSON.stringify(chunk)}\n\n);eventIndex;}res.end();}// 客户端记录接收到的 id断连重连时带上classResilientSSEClient{privatelastEventId;asyncconnect(url:string,body:any){constheaders:Recordstring,string{};if(this.lastEventId){headers[Last-Event-ID]this.lastEventId;}constresponseawaitfetch(url,{method:POST,headers,body:JSON.stringify(body),});forawait(constevtofthis.parseSSE(response)){if(evt.id)this.lastEventIdevt.id;this.onEvent(evt);}}privateasync*parseSSE(response:Response):AsyncGenerator{id:string;data:string}{constreaderresponse.body!.getReader();constdecodernewTextDecoder();letbuffer;letcurrentId;while(true){const{done,value}awaitreader.read();if(done)break;bufferdecoder.decode(value,{stream:true});constlinesbuffer.split(\n);bufferlines.pop()||;for(constlineoflines){if(line.startsWith(id:))currentIdline.slice(3).trim();if(line.startsWith(data:)){yield{id:currentId,data:line.slice(5).trim()};}}}}}实测对比20 轮对话断连从头重跑 4.2s / 2400 额外 token用 Last-Event-ID 续传 0.8s / 0 额外 token。如果你的 Agent 跑长对话不加这条就是在浪费钱。短对话可以先不管——5 轮以内断连重跑也就 1 秒出头折腾续传性价比不高。坑三用户点了停止生成你以为省了钱——后端还在烧 token这是最隐蔽的一条。用户在前端点了取消你关了 SSE 连接界面干净了用户以为生成停了。心情很舒畅觉得自己控制了局面。但后端对 OpenAI API 的请求还在跑token 还在烧。OpenAI 的 API 不支持服务端主动中断流——你关了前端连接它的生成继续跑直到完成或超时。这就像你关了电视以为节目停播了其实电视台还在播只是你看不见而已。一个平均 800 token 的生成任务用户在 200 token 处取消。不用 AbortController后端跑完 800 token白烧 600。用了 AbortController后端也大概在 200 token 处停下——因为 fetch 收到 abort 信号后会主动断开 TCP 连接OpenAI 的服务端在连接断开时也会停止生成。你算算每天 100 次取消操作每次白烧 600 token一个月就是 180 万 token 的无效消耗。按 gpt-4o 的价格算那是 $27 的纯浪费。27 美元不多但你花 27 美元买了零价值的东西这感觉不太好。更糟糕的是这些白烧的 token 你在用量报表里根本看不出来——因为它们被计入了正常完成的请求。你以为每月花 $200其实有 $27 是废的。asyncfunctionstreamWithAbort(messages:ChatMessage[],clientSignal:AbortSignal){constserverAbortnewAbortController();// 前端断连时同步 cancel 后端请求clientSignal.addEventListener(abort,(){serverAbort.abort();});try{constresponseawaitfetch(https://api.openai.com/v1/chat/completions,{method:POST,headers:{Content-Type:application/json,Authorization:Bearer${process.env.OPENAI_API_KEY},},body:JSON.stringify({messages,stream:true}),signal:serverAbort.signal,});// 正常流式处理...}catch(err){if(errinstanceofDOMExceptionerr.nameAbortError){return{status:cancelled,tokensSaved:~68%};}throwerr;}}这条我觉得是最值得立刻加的——不管你跑什么场景用户取消都是高频操作。白烧 token 就是白烧钱没有任何借口不修。如果你觉得 $27 不多可以忽略那你想想这个数字是按每天 100 次取消算的如果你的 Agent 日活上千这个数字会变成 $270 甚至更多。而且这还是保守估计——长对话场景每次取消白烧的 token 更多。什么时候不用折腾短对话5 轮以内 单工具调用 没有停止按钮的场景这三个优化差别不大。但凡你跑长对话、多工具并行、有用户取消需求——花半天加上回报比你想的高。这三个坑我在做雷达鸭的客服 Agent 时逐个踩过来又逐个修的鸿蒙版和小程序版都在跑这套方案。你遇到过 SSE 流式响应的暗坑吗聊聊。关于作者老三10 年软件开发老兵软件设计师 人工智能应用工程师。专注鸿蒙北向开发ArkTS Web 前端边做产品边探索 AI 自动化。不定期在 CSDN 分享鸿蒙 / AI 方向技术踩坑笔记。本文遵循 MIT 协议转载请注明出处。