1. 从一次线上故障说起模型调用远不止“发个请求”那么简单去年冬天我负责的一个智能问答服务在凌晨两点突然开始大面积超时。监控面板上invoke调用的 P99 延迟从 800ms 飙到 12s错误日志里刷屏的是stream disconnected before completion: idle timeout waiting for sse。当时我的第一反应是模型服务端挂了但排查后发现模型本身健康得很——问题出在我们自己的调用层一个没设超时的流式请求在弱网环境下把连接池占满了。这件事让我彻底意识到模型调用这四个字看着简单背后却是一整套工程问题。你写下一行llm.invoke(prompt)背后发生的是消息对象序列化、HTTP 连接建立、请求体编码、服务端排队、token 逐个生成、流式分块回传、客户端拼接、异常重试、超时控制……任何一环出问题用户看到的就是“转圈”或者“报错”。这篇内容我想聊的就是围绕invoke、stream、LangChain、消息对象这几个关键词把模型调用这件事从“会用”讲到“用稳”。不管你是刚接触 LangChain 的新手还是已经在生产环境跑 Agent 的老手我都会尽量把那些文档里不写、但踩过才知道的细节摊开讲。核心会覆盖三块同步 invoke 与流式 stream 的本质区别与选型、消息对象体系的设计逻辑、调用链路上的超时/重试/断流处理。这些内容不绑定某个具体模型厂商换成任何一家兼容 OpenAI 协议的服务都适用。先说结论模型调用不是“发请求收响应”而是“管理一个可能随时中断的长连接会话”。理解这一点后面所有的坑都好解释了。2. invoke 与 stream两种调用范式的本质差异2.1 invoke 是“等结果”stream 是“看过程”很多人第一次用 LangChain写的都是这样的代码from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o-mini) resp llm.invoke(用一句话解释什么是向量数据库) print(resp.content)这就是典型的invoke模式你把消息发出去然后阻塞等待直到模型把整段话生成完一次性拿到完整结果。它的心智模型是“请求-响应”跟调用一个普通 REST 接口没区别。而stream模式是这样的for chunk in llm.stream(用一句话解释什么是向量数据库): print(chunk.content, end, flushTrue)它拿到的是一个生成器模型每生成一小段 token就通过 SSEServer-Sent Events推回来一块你边收边渲染。用户看到的是文字一个个蹦出来而不是等三秒后整段出现。这两者的差异表面看是“打字机效果”本质上是连接生命周期的管理方式不同。invoke 的连接是短命的发完、收完、关掉。stream 的连接是长命的从第一个 token 到最后一个 token中间可能持续几十秒这期间网络抖动、服务端限流、客户端超时任何一个都可能让连接断掉。2.2 什么时候必须用 stream我的经验是只要满足下面任意一条就该上 stream响应内容长超过 200 字用户等 invoke 会明显感到卡顿。需要实时反馈对话类、代码生成类场景用户期待“边想边说”。服务端有首 token 延迟有些模型排队久但一旦开始生成就很快stream 能让用户尽早看到东西。要处理超长输出invoke 模式下如果输出超过客户端读取超时整个请求就废了stream 只要 token 在流动连接就活着。反过来如果只是做分类、抽取、打分这种短输出任务invoke 反而更省事——不用处理分块拼接错误处理也简单。2.3 一个容易被忽略的点stream 的“假流式”这里要提醒一个坑。有些服务端虽然返回的是 SSE但其实是攒够一批才发甚至等全部生成完才一次性推。你在客户端看到的“流式”只是被切成了几块而已。判断方法很简单看首 token 时间TTFT。真正的流式TTFT 通常在几百毫秒假流式的 TTFT 接近总耗时。我在选型时会专门测这个指标。如果 TTFT 超过 2 秒那 stream 的意义就大打折扣还不如老老实实用 invoke 加个 loading 动画。3. 消息对象模型调用的“通用语言”3.1 为什么要有消息对象这层抽象早期调模型大家都是拼字符串把 system prompt、历史对话、用户输入用\n连起来塞进去。这么做的问题是不同模型的格式要求不一样换个模型就得重写拼接逻辑。LangChain 的消息对象体系就是为了解决这个。它把对话拆成几种角色明确的对象消息类型角色典型用途SystemMessage系统设定人设、规则、输出格式HumanMessage用户用户输入AIMessage助手模型回复可携带 tool_callsToolMessage工具工具执行结果回传给模型FunctionMessage函数旧版函数调用结果逐步被 ToolMessage 取代你只管构造这些对象LangChain 负责把它们翻译成各家模型要的格式。这就是“通用语言”的价值。3.2 消息对象的隐藏字段比 content 更重要的是 metadata新手往往只关注content但真正决定调用行为的是那些隐藏字段。我列几个关键的tool_calls挂在AIMessage上表示模型想调用哪些工具。Agent 循环就是靠它驱动的。tool_call_idToolMessage必须带上用来和对应的tool_call配对。这个 ID 对不上模型会报错或者忽略工具结果。response_metadata包含 token 用量、finish_reason、模型名等。做成本核算和调试时必看。usage_metadata新版 LangChain 里更规范的用量字段input/output/total tokens 都在里面。我踩过一个坑手动构造ToolMessage时忘了填tool_call_id结果模型一直重复调用同一个工具陷入死循环。排查了半天才发现是配对失败模型以为工具没返回结果。3.3 消息裁剪别让上下文无限膨胀对话轮次一多消息列表会越来越长token 成本飙升还可能超出模型上下文窗口。这时候需要消息裁剪。LangChain 提供了几种策略trim_messages按 token 数或消息条数裁剪可以保留 system message 和最近 N 轮。ConversationSummaryBufferMemory把早期对话总结成一段摘要压缩 token。自定义裁剪按业务规则丢弃不重要的历史。我的做法是system message 永远保留最近 3 轮完整保留更早的按 token 预算裁剪。裁剪时要注意别把tool_call和对应的ToolMessage拆散否则模型会困惑。from langchain_core.messages import trim_messages trimmed trim_messages( messages, max_tokens4000, strategylast, token_counterllm, include_systemTrue, allow_partialFalse, )allow_partialFalse很关键它保证不会把一条消息从中间截断。4. 调用链路上的断流、超时与重试4.1 “stream disconnected before completion” 到底是谁的锅这个报错我在热词里看到好几次也亲自遇到过。它的字面意思是“流在完成前断开了”但根因可能有很多种网络层客户端到服务端的连接被中间设备掐断或者本地网络抖动。服务端模型服务过载主动断开连接热词里our servers are currently overloaded就是这种。客户端超时读超时设得太短token 还没流完就断了。SSE idle timeout中间有代理层空闲超过阈值就关连接。排查顺序我一般是这样先看错误发生的时间点是首 token 之前还是之后再看是偶发还是必现然后抓包看 TCP 层是谁先发的 FIN。这套流程能快速定位到是网络、服务端还是客户端的问题。4.2 超时参数怎么设才合理超时是模型调用里最容易设错的地方。设太短长输出必断设太长故障时连接池被占满。我的经验值参数建议值说明连接超时5-10s建立 TCP 连接的时间首 token 超时30-60s从发请求到收到第一个 token读超时stream60-120s两个 token 之间的最大间隔总超时300s整个请求的上限注意stream 模式下读超时是“token 间隔超时”不是总时长。只要 token 在持续流动连接就不该断。很多库默认的读超时是 60s对于慢速模型可能不够。4.3 重试策略不是所有错误都值得重试无脑重试是灾难。我的原则是可重试连接超时、5xx 错误、限流429、stream disconnected。不可重试4xx 参数错误、内容审核拒绝、token 超限。谨慎重试已经收到部分 token 的 stream 中断——重试会导致用户看到重复内容。对于 stream 中断我的做法是记录已收到的内容重试时把已生成部分作为上下文传回去让模型接着写。这比从头再来体验好得多。import time def call_with_retry(llm, messages, max_retries3): for attempt in range(max_retries): try: return llm.invoke(messages) except Exception as e: if attempt max_retries - 1: raise wait 2 ** attempt time.sleep(wait)指数退避是标配但别忘了加抖动jitter否则多个客户端会同时重试把服务端打垮。4.4 连接池被低估的性能杀手invoke 模式下如果每次调用都新建 HTTP 连接开销很大。用连接池复用是常识但有个坑连接池大小要和并发数匹配。我见过一个服务连接池设了 10但并发请求有 50结果大量请求在排队等连接表现为“莫名其妙的慢”。后来把池子调到 100问题消失。另一个坑是连接泄漏。stream 模式下如果异常退出没正确关闭连接连接会一直占着。一定要用try/finally或者上下文管理器确保释放。5. LangChain 调用层的工程化实践5.1 封装一个健壮的调用器直接裸调llm.invoke在生产环境是不够的。我通常会封装一层把超时、重试、日志、用量统计都收进去class RobustLLMClient: def __init__(self, llm, timeout60, max_retries3): self.llm llm self.timeout timeout self.max_retries max_retries def invoke(self, messages, **kwargs): start time.time() try: resp self.llm.invoke(messages, timeoutself.timeout, **kwargs) self._log_usage(resp, time.time() - start) return resp except Exception as e: self._log_error(e, time.time() - start) raise def stream(self, messages, **kwargs): buffer [] try: for chunk in self.llm.stream(messages, timeoutself.timeout, **kwargs): buffer.append(chunk.content) yield chunk except Exception as e: # 记录已生成内容便于断点续传 self._save_partial(.join(buffer)) raise这层封装的价值在于所有调用都走同一条路径监控、限流、降级都能统一处理。5.2 用量统计别等账单来了才后悔模型调用是要花钱的。response_metadata里的 token 用量必须落库按用户、按接口、按天维度统计。我见过团队因为没做统计某个月账单翻了三倍才发现是某个接口被刷了。LangChain 的 callback 机制可以帮你自动收集这些from langchain_core.callbacks import BaseCallbackHandler class UsageTracker(BaseCallbackHandler): def on_llm_end(self, response, **kwargs): usage response.llm_output.get(token_usage, {}) # 写入监控系统 record_usage(usage)5.3 降级与熔断模型挂了怎么办模型服务不是 100% 可用的。当错误率超过阈值应该触发熔断暂时不再调用直接返回兜底结果或提示用户稍后再试。我一般用pybreaker或者自己实现一个简单的计数器连续 5 次失败 → 熔断 30 秒。熔断期间请求直接走降级逻辑。30 秒后放一个探针请求成功则恢复。降级策略要看业务问答类可以返回“服务繁忙”代码生成类可以返回缓存的历史结果。5.4 日志出问题时能救命日志要记什么我的清单是请求 ID贯穿全链路模型名、消息条数、总 token 数首 token 时间、总耗时finish_reason是正常结束还是被截断错误类型和堆栈特别提醒不要把完整的 prompt 和响应明文打进日志涉及用户隐私。可以记 hash 或者脱敏后的摘要。6. 那些热词背后的真实问题6.1 “cannot invoke ... because ... is null”这个报错来自 Java 生态本质是空指针。在模型调用场景里常见于工具返回结果解析时字段缺失。比如你定义了一个工具返回 JSON但某个字段是 null代码直接.getContent()就炸了。防御性写法是解析前先校验结构用 Optional 或者默认值兜底。别假设模型或工具一定返回完整字段。6.2 “stream disconnected before completion: transport error”这是网络层错误。我遇到过一次原因是客户端和模型服务之间有个负载均衡器空闲 60 秒就断连接。而我们的模型在长思考时首 token 要等 70 秒正好被掐。解决办法有两个一是调大 LB 的空闲超时二是发心跳在等待期间定期发个空注释行保持连接活跃。SSE 协议支持注释行以:开头不会影响内容解析。6.3 “idle timeout waiting for sse”跟上面类似是 SSE 空闲超时。区别在于这个通常是客户端或 SDK 层面的配置。检查你的 HTTP 客户端有没有设read_timeout以及它是不是被应用到了流式读取上。6.4 本地模型调用如 LM Studio热词里提到用 Claude Code 调用本地模型。本地模型的调用协议通常兼容 OpenAI但有几个差异要注意并发能力弱本地模型往往单并发多个请求会排队。上下文窗口小别指望塞几万 token。首 token 慢冷启动时尤其明显超时要放宽。我本地调试时会把超时设到 120s避免误判为失败。7. 我踩过的坑与总结出的检查清单7.1 三个印象最深的坑坑一stream 中断后重试导致内容重复。用户看到同一段话出现两遍。后来改成记录已生成内容重试时带上让模型续写。坑二连接池耗尽。一个没设超时的 stream 请求卡住占着连接不放后续请求全部排队。加了总超时后解决。坑三消息裁剪把 tool_call 拆散。裁剪时把AIMessage带 tool_calls留下了但对应的ToolMessage被裁掉了模型报错说找不到工具结果。后来在裁剪逻辑里加了配对保护。7.2 上线前的检查清单[ ] invoke 和 stream 的超时都设了吗[ ] 重试策略区分了可重试和不可重试错误吗[ ] 连接池大小和并发数匹配吗[ ] token 用量有统计吗[ ] 有熔断和降级吗[ ] 日志脱敏了吗[ ] 消息裁剪保护了 tool_call 配对吗[ ] stream 中断有断点续传吗7.3 最后分享一个小技巧调试 stream 问题时我会在客户端加一个“token 到达时间戳”记录把每个 chunk 的到达时间打出来。这样一眼就能看出是首 token 慢、还是中间卡顿、还是末尾断流。比看总耗时有用得多。模型调用这件事写起来一行代码用稳了却要一整套工程。希望这些经验能帮你少走点弯路。
LangChain模型调用实战：invoke与stream的工程化避坑指南
1. 从一次线上故障说起模型调用远不止“发个请求”那么简单去年冬天我负责的一个智能问答服务在凌晨两点突然开始大面积超时。监控面板上invoke调用的 P99 延迟从 800ms 飙到 12s错误日志里刷屏的是stream disconnected before completion: idle timeout waiting for sse。当时我的第一反应是模型服务端挂了但排查后发现模型本身健康得很——问题出在我们自己的调用层一个没设超时的流式请求在弱网环境下把连接池占满了。这件事让我彻底意识到模型调用这四个字看着简单背后却是一整套工程问题。你写下一行llm.invoke(prompt)背后发生的是消息对象序列化、HTTP 连接建立、请求体编码、服务端排队、token 逐个生成、流式分块回传、客户端拼接、异常重试、超时控制……任何一环出问题用户看到的就是“转圈”或者“报错”。这篇内容我想聊的就是围绕invoke、stream、LangChain、消息对象这几个关键词把模型调用这件事从“会用”讲到“用稳”。不管你是刚接触 LangChain 的新手还是已经在生产环境跑 Agent 的老手我都会尽量把那些文档里不写、但踩过才知道的细节摊开讲。核心会覆盖三块同步 invoke 与流式 stream 的本质区别与选型、消息对象体系的设计逻辑、调用链路上的超时/重试/断流处理。这些内容不绑定某个具体模型厂商换成任何一家兼容 OpenAI 协议的服务都适用。先说结论模型调用不是“发请求收响应”而是“管理一个可能随时中断的长连接会话”。理解这一点后面所有的坑都好解释了。2. invoke 与 stream两种调用范式的本质差异2.1 invoke 是“等结果”stream 是“看过程”很多人第一次用 LangChain写的都是这样的代码from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4o-mini) resp llm.invoke(用一句话解释什么是向量数据库) print(resp.content)这就是典型的invoke模式你把消息发出去然后阻塞等待直到模型把整段话生成完一次性拿到完整结果。它的心智模型是“请求-响应”跟调用一个普通 REST 接口没区别。而stream模式是这样的for chunk in llm.stream(用一句话解释什么是向量数据库): print(chunk.content, end, flushTrue)它拿到的是一个生成器模型每生成一小段 token就通过 SSEServer-Sent Events推回来一块你边收边渲染。用户看到的是文字一个个蹦出来而不是等三秒后整段出现。这两者的差异表面看是“打字机效果”本质上是连接生命周期的管理方式不同。invoke 的连接是短命的发完、收完、关掉。stream 的连接是长命的从第一个 token 到最后一个 token中间可能持续几十秒这期间网络抖动、服务端限流、客户端超时任何一个都可能让连接断掉。2.2 什么时候必须用 stream我的经验是只要满足下面任意一条就该上 stream响应内容长超过 200 字用户等 invoke 会明显感到卡顿。需要实时反馈对话类、代码生成类场景用户期待“边想边说”。服务端有首 token 延迟有些模型排队久但一旦开始生成就很快stream 能让用户尽早看到东西。要处理超长输出invoke 模式下如果输出超过客户端读取超时整个请求就废了stream 只要 token 在流动连接就活着。反过来如果只是做分类、抽取、打分这种短输出任务invoke 反而更省事——不用处理分块拼接错误处理也简单。2.3 一个容易被忽略的点stream 的“假流式”这里要提醒一个坑。有些服务端虽然返回的是 SSE但其实是攒够一批才发甚至等全部生成完才一次性推。你在客户端看到的“流式”只是被切成了几块而已。判断方法很简单看首 token 时间TTFT。真正的流式TTFT 通常在几百毫秒假流式的 TTFT 接近总耗时。我在选型时会专门测这个指标。如果 TTFT 超过 2 秒那 stream 的意义就大打折扣还不如老老实实用 invoke 加个 loading 动画。3. 消息对象模型调用的“通用语言”3.1 为什么要有消息对象这层抽象早期调模型大家都是拼字符串把 system prompt、历史对话、用户输入用\n连起来塞进去。这么做的问题是不同模型的格式要求不一样换个模型就得重写拼接逻辑。LangChain 的消息对象体系就是为了解决这个。它把对话拆成几种角色明确的对象消息类型角色典型用途SystemMessage系统设定人设、规则、输出格式HumanMessage用户用户输入AIMessage助手模型回复可携带 tool_callsToolMessage工具工具执行结果回传给模型FunctionMessage函数旧版函数调用结果逐步被 ToolMessage 取代你只管构造这些对象LangChain 负责把它们翻译成各家模型要的格式。这就是“通用语言”的价值。3.2 消息对象的隐藏字段比 content 更重要的是 metadata新手往往只关注content但真正决定调用行为的是那些隐藏字段。我列几个关键的tool_calls挂在AIMessage上表示模型想调用哪些工具。Agent 循环就是靠它驱动的。tool_call_idToolMessage必须带上用来和对应的tool_call配对。这个 ID 对不上模型会报错或者忽略工具结果。response_metadata包含 token 用量、finish_reason、模型名等。做成本核算和调试时必看。usage_metadata新版 LangChain 里更规范的用量字段input/output/total tokens 都在里面。我踩过一个坑手动构造ToolMessage时忘了填tool_call_id结果模型一直重复调用同一个工具陷入死循环。排查了半天才发现是配对失败模型以为工具没返回结果。3.3 消息裁剪别让上下文无限膨胀对话轮次一多消息列表会越来越长token 成本飙升还可能超出模型上下文窗口。这时候需要消息裁剪。LangChain 提供了几种策略trim_messages按 token 数或消息条数裁剪可以保留 system message 和最近 N 轮。ConversationSummaryBufferMemory把早期对话总结成一段摘要压缩 token。自定义裁剪按业务规则丢弃不重要的历史。我的做法是system message 永远保留最近 3 轮完整保留更早的按 token 预算裁剪。裁剪时要注意别把tool_call和对应的ToolMessage拆散否则模型会困惑。from langchain_core.messages import trim_messages trimmed trim_messages( messages, max_tokens4000, strategylast, token_counterllm, include_systemTrue, allow_partialFalse, )allow_partialFalse很关键它保证不会把一条消息从中间截断。4. 调用链路上的断流、超时与重试4.1 “stream disconnected before completion” 到底是谁的锅这个报错我在热词里看到好几次也亲自遇到过。它的字面意思是“流在完成前断开了”但根因可能有很多种网络层客户端到服务端的连接被中间设备掐断或者本地网络抖动。服务端模型服务过载主动断开连接热词里our servers are currently overloaded就是这种。客户端超时读超时设得太短token 还没流完就断了。SSE idle timeout中间有代理层空闲超过阈值就关连接。排查顺序我一般是这样先看错误发生的时间点是首 token 之前还是之后再看是偶发还是必现然后抓包看 TCP 层是谁先发的 FIN。这套流程能快速定位到是网络、服务端还是客户端的问题。4.2 超时参数怎么设才合理超时是模型调用里最容易设错的地方。设太短长输出必断设太长故障时连接池被占满。我的经验值参数建议值说明连接超时5-10s建立 TCP 连接的时间首 token 超时30-60s从发请求到收到第一个 token读超时stream60-120s两个 token 之间的最大间隔总超时300s整个请求的上限注意stream 模式下读超时是“token 间隔超时”不是总时长。只要 token 在持续流动连接就不该断。很多库默认的读超时是 60s对于慢速模型可能不够。4.3 重试策略不是所有错误都值得重试无脑重试是灾难。我的原则是可重试连接超时、5xx 错误、限流429、stream disconnected。不可重试4xx 参数错误、内容审核拒绝、token 超限。谨慎重试已经收到部分 token 的 stream 中断——重试会导致用户看到重复内容。对于 stream 中断我的做法是记录已收到的内容重试时把已生成部分作为上下文传回去让模型接着写。这比从头再来体验好得多。import time def call_with_retry(llm, messages, max_retries3): for attempt in range(max_retries): try: return llm.invoke(messages) except Exception as e: if attempt max_retries - 1: raise wait 2 ** attempt time.sleep(wait)指数退避是标配但别忘了加抖动jitter否则多个客户端会同时重试把服务端打垮。4.4 连接池被低估的性能杀手invoke 模式下如果每次调用都新建 HTTP 连接开销很大。用连接池复用是常识但有个坑连接池大小要和并发数匹配。我见过一个服务连接池设了 10但并发请求有 50结果大量请求在排队等连接表现为“莫名其妙的慢”。后来把池子调到 100问题消失。另一个坑是连接泄漏。stream 模式下如果异常退出没正确关闭连接连接会一直占着。一定要用try/finally或者上下文管理器确保释放。5. LangChain 调用层的工程化实践5.1 封装一个健壮的调用器直接裸调llm.invoke在生产环境是不够的。我通常会封装一层把超时、重试、日志、用量统计都收进去class RobustLLMClient: def __init__(self, llm, timeout60, max_retries3): self.llm llm self.timeout timeout self.max_retries max_retries def invoke(self, messages, **kwargs): start time.time() try: resp self.llm.invoke(messages, timeoutself.timeout, **kwargs) self._log_usage(resp, time.time() - start) return resp except Exception as e: self._log_error(e, time.time() - start) raise def stream(self, messages, **kwargs): buffer [] try: for chunk in self.llm.stream(messages, timeoutself.timeout, **kwargs): buffer.append(chunk.content) yield chunk except Exception as e: # 记录已生成内容便于断点续传 self._save_partial(.join(buffer)) raise这层封装的价值在于所有调用都走同一条路径监控、限流、降级都能统一处理。5.2 用量统计别等账单来了才后悔模型调用是要花钱的。response_metadata里的 token 用量必须落库按用户、按接口、按天维度统计。我见过团队因为没做统计某个月账单翻了三倍才发现是某个接口被刷了。LangChain 的 callback 机制可以帮你自动收集这些from langchain_core.callbacks import BaseCallbackHandler class UsageTracker(BaseCallbackHandler): def on_llm_end(self, response, **kwargs): usage response.llm_output.get(token_usage, {}) # 写入监控系统 record_usage(usage)5.3 降级与熔断模型挂了怎么办模型服务不是 100% 可用的。当错误率超过阈值应该触发熔断暂时不再调用直接返回兜底结果或提示用户稍后再试。我一般用pybreaker或者自己实现一个简单的计数器连续 5 次失败 → 熔断 30 秒。熔断期间请求直接走降级逻辑。30 秒后放一个探针请求成功则恢复。降级策略要看业务问答类可以返回“服务繁忙”代码生成类可以返回缓存的历史结果。5.4 日志出问题时能救命日志要记什么我的清单是请求 ID贯穿全链路模型名、消息条数、总 token 数首 token 时间、总耗时finish_reason是正常结束还是被截断错误类型和堆栈特别提醒不要把完整的 prompt 和响应明文打进日志涉及用户隐私。可以记 hash 或者脱敏后的摘要。6. 那些热词背后的真实问题6.1 “cannot invoke ... because ... is null”这个报错来自 Java 生态本质是空指针。在模型调用场景里常见于工具返回结果解析时字段缺失。比如你定义了一个工具返回 JSON但某个字段是 null代码直接.getContent()就炸了。防御性写法是解析前先校验结构用 Optional 或者默认值兜底。别假设模型或工具一定返回完整字段。6.2 “stream disconnected before completion: transport error”这是网络层错误。我遇到过一次原因是客户端和模型服务之间有个负载均衡器空闲 60 秒就断连接。而我们的模型在长思考时首 token 要等 70 秒正好被掐。解决办法有两个一是调大 LB 的空闲超时二是发心跳在等待期间定期发个空注释行保持连接活跃。SSE 协议支持注释行以:开头不会影响内容解析。6.3 “idle timeout waiting for sse”跟上面类似是 SSE 空闲超时。区别在于这个通常是客户端或 SDK 层面的配置。检查你的 HTTP 客户端有没有设read_timeout以及它是不是被应用到了流式读取上。6.4 本地模型调用如 LM Studio热词里提到用 Claude Code 调用本地模型。本地模型的调用协议通常兼容 OpenAI但有几个差异要注意并发能力弱本地模型往往单并发多个请求会排队。上下文窗口小别指望塞几万 token。首 token 慢冷启动时尤其明显超时要放宽。我本地调试时会把超时设到 120s避免误判为失败。7. 我踩过的坑与总结出的检查清单7.1 三个印象最深的坑坑一stream 中断后重试导致内容重复。用户看到同一段话出现两遍。后来改成记录已生成内容重试时带上让模型续写。坑二连接池耗尽。一个没设超时的 stream 请求卡住占着连接不放后续请求全部排队。加了总超时后解决。坑三消息裁剪把 tool_call 拆散。裁剪时把AIMessage带 tool_calls留下了但对应的ToolMessage被裁掉了模型报错说找不到工具结果。后来在裁剪逻辑里加了配对保护。7.2 上线前的检查清单[ ] invoke 和 stream 的超时都设了吗[ ] 重试策略区分了可重试和不可重试错误吗[ ] 连接池大小和并发数匹配吗[ ] token 用量有统计吗[ ] 有熔断和降级吗[ ] 日志脱敏了吗[ ] 消息裁剪保护了 tool_call 配对吗[ ] stream 中断有断点续传吗7.3 最后分享一个小技巧调试 stream 问题时我会在客户端加一个“token 到达时间戳”记录把每个 chunk 的到达时间打出来。这样一眼就能看出是首 token 慢、还是中间卡顿、还是末尾断流。比看总耗时有用得多。模型调用这件事写起来一行代码用稳了却要一整套工程。希望这些经验能帮你少走点弯路。
