很多团队接入 AI API 时第一阶段的问题通常很直接Base URL 对不对、API Key 有没有权限、模型 ID 是否可用、curl 能不能跑通。等这些都解决以后新的问题才真正出现明明接口已经接通为什么回答到一半突然断了前端已经打开流式输出为什么还是等很久才出现第一个字接上知识库之后为什么以前 5 秒能回现在经常 30 秒超时日志里没有明显报错只看到timeout、connection reset或stream interrupted到底该查哪里用户看到的是“AI 没答完”但后端看起来请求似乎已经成功了这算谁的问题这类问题最麻烦的地方在于它们看起来像“接口不稳定”但根因可能分散在流式传输、向量检索、上下文长度、网关超时、客户端解析、模型服务限流、浏览器连接保持等多个位置。所以排查时不要只问一句“API 为什么断了”。更准确的问题应该是这次请求是在生成前卡住了还是生成中被切断了是在模型侧慢还是在 RAG 检索侧慢是服务端没有继续输出还是中间代理没有继续转发一、先区分三种“答到一半”用户说“答到一半”实际可能是三类完全不同的问题。第一类是模型确实生成到一半停止。后端日志里能看到请求进入了模型服务也收到了部分 token但最终没有finish_reason或者返回了截断、取消、超时、限流等错误。这通常和模型服务、输出长度、超时设置、供应商侧限流有关。第二类是模型已经生成完但传输链路中断。例如服务端收到了完整响应但前端 SSE 连接被网关断开或者反向代理缓冲了流式内容导致浏览器没有及时显示。用户看到的是“没答完”但模型侧可能已经完成。第三类是回答内容被上下文或检索结果拖偏用户以为它没答完。比如 RAG 召回的片段不完整模型只拿到了流程的前半段于是回答也只覆盖前半段或者上下文太长关键材料被挤掉模型输出看似中断实际是输入信息本来就不完整。二、流式输出不是“打开开关”这么简单很多人以为只要请求里加上stream: true前端就一定能逐字显示。实际链路通常比这长得多浏览器 - 业务前端 - 业务后端 - API 网关 / Nginx / 负载均衡 - AI 网关或代理服务 - 模型供应商只要中间任何一层没有正确处理流式响应用户看到的就不是稳定的流式输出。常见问题有几种服务端虽然请求了流式但业务后端把上游流读完后再一次性返回给前端。反向代理启用了响应缓冲SSE 或 chunked response 被攒到一定大小才吐出去。前端把流式响应当普通 JSON 解析必须等完整响应结束才处理。网关、Serverless、浏览器代理或企业安全网关对长连接设置了固定上限。所以流式排查时不要只看请求体有没有stream: true。要确认每一层是否都在“边收边转发”。三、为什么开了流式还是很久没有第一个字流式只能改善模型开始输出之后的体验不能缩短模型开始输出之前的链路。对于接了知识库的 RAG 请求首 token 之前可能包括用户问题 - 问题改写 - Embedding - 向量检索 - 元数据过滤 - Rerank - 上下文拼接 - 调用 LLM - 模型输出首 token如果向量检索、Rerank 或上下文拼接已经消耗了 8 秒那么即使模型流式输出很快用户也要等 8 秒后才看到第一个字。建议把耗时拆成至少四段记录request_in_ms业务端到 AI 服务入口的耗时retrieval_ms知识库检索、向量召回、Rerank 的耗时first_token_ms从调用模型到收到第一个 token 的耗时completion_ms从第一个 token 到完整输出结束的耗时只记录总耗时没有太大价值。只有分段耗时才能定位问题。四、向量上下文为什么会让回答“断在半路”接入知识库以后回答到一半的问题不一定是传输中断也可能是上下文本身出了问题。最常见的是召回片段不完整。用户问“退款申请完整流程是什么”知识库只召回了“提交申请”和“主管审批”两个片段漏掉了“财务复核”和“到账时间”。模型就只能回答前半段看起来像答到一半没继续说。第二种是切片太小。流程型、制度型、排障型文档如果被切得太碎单个 chunk 缺少上下文。第三种是切片太大。一个 chunk 里混了多个主题向量检索看起来命中了实际给模型的是一段噪声很大的材料。第四种是上下文超长。召回片段、系统提示词、历史对话、工具结果一起塞进模型上下文如果接近窗口上限关键内容可能被裁剪。排查 RAG 场景时一定要看三份材料1. 用户原始问题 2. 实际召回的知识片段 3. 最终送给模型的上下文如果召回片段本来就缺关键步骤不要先调超时先修知识库切片、元数据、topK、score threshold 和 Rerank 策略。五、timeout 要按链路看不要只改一个数“答到一半断了”经常和超时有关但 AI 链路里的 timeout 不是一个配置而是一串配置。常见超时点包括浏览器请求超时前端框架或请求库超时业务后端 HTTP client 超时API 网关超时Nginx / 负载均衡读取超时AI 网关上游超时RAG 检索服务超时Embedding / Rerank 服务超时模型供应商生成超时Serverless / 容器平台最长执行时间这些 timeout 是串联关系最短的那个会先切断请求。不要一上来把所有超时都调大。超时调大只能让慢请求等得更久不能让慢请求变快。正确做法是先找出哪一段慢再决定是优化检索、减少上下文、降低输出长度、调整网关还是改成异步任务。六、生成参数也会导致“没答完”如果传输链路没有中断RAG 上下文也正常就要看模型生成参数。第一是max_tokens或输出 token 上限太小。模型不是不想继续而是已经达到输出上限。表现通常是回答戛然而止没有自然收尾。第二是 stop 序列配置不当。有些系统会设置stop字符串来让模型在遇到特定标记时停止。如果 stop 命中了普通文本回答就会提前结束。第三是客户端主动取消。用户切换页面、关闭浏览器、前端组件卸载、请求库超时、AbortController 触发都可能让后端看到连接中断。第四是供应商侧限流或排队。高峰期模型服务可能先返回一部分 token然后因为内部错误、限流、连接重置而中断。建议在日志中记录trace_id model stream max_tokens input_tokens output_tokens finish_reason first_token_ms total_ms upstream_status upstream_error_code client_aborted其中finish_reason很关键。如果是length大概率是输出上限如果是正常 stop说明模型认为自己完成如果没有 finish reason就要查连接中断、上游错误或客户端取消。七、流式接口要看“结束事件”很多团队只处理增量文本不处理结束事件和错误事件。这样一旦流中断前端只能停在半句话上用户也不知道是完成、失败还是可重试。一个健壮的流式接口至少要区分四种状态generating正在生成 completed正常完成 interrupted连接中断或上游异常 cancelled用户主动取消 timeout超过业务允许时间如果使用 SSE可以约定类似事件event: delta data: {text:这一段是增量文本} event: done data: {finish_reason:stop} event: error data: {code:UPSTREAM_TIMEOUT,message:模型服务响应超时}这样用户至少能看到明确状态研发也能从日志里知道是正常结束还是异常中断。八、一个实用排查顺序线上遇到“AI API 已经接通但回答到一半断了”建议按下面顺序排查。第一步用非 RAG 的最小请求验证模型流式输出。只发一句ping或一个短问题确认模型服务、API Key、Base URL、流式解析都正常。第二步用同一个问题分别测试阻塞模式和流式模式。阻塞模式完整、流式模式断说明问题多半在 SSE、代理、前端解析或连接保持。第三步关闭知识库再测一次。无知识库正常接知识库后变慢或中断重点查向量检索、Rerank、上下文长度和知识库切片。第四步记录首 token 时间。如果首 token 前已经很慢流式救不了需要优化检索链路、模型排队或提示词长度。第五步看finish_reason和输出 token 数。如果经常因为长度停止就调整max_tokens和回答格式。第六步检查代理是否缓冲流式响应。Nginx、API 网关、云函数、企业网关都可能影响 SSE。第七步检查前端是否能处理异常结束。不要让半句话静静停在那里至少要提示“生成中断可重试”。第八步做并发下的 p95 / p99 测试。单次请求正常不代表线上稳定。九、工程上该怎么改如果要把这类问题从“偶发玄学”变成可治理问题建议做四件事。第一所有 AI 请求都生成trace_id并贯穿业务后端、AI 网关、RAG 检索、模型服务和前端错误上报。第二把耗时拆段记录。至少记录入口耗时、检索耗时、首 token 耗时、生成耗时、总耗时。第三对 RAG 上下文做预算。限制 topK、Rerank 数量、单片段长度、历史消息轮数和最终上下文 token。上下文不是越多越好越多越容易慢、贵、乱。第四把流式结束状态协议化。前端必须知道一次生成是正常完成、用户取消、超时、上游错误还是网络中断。十、结论AI API 接通只是第一步稳定回答才是生产可用的开始。“答到一半”通常不是一个单点故障而是一条链路的综合表现流式输出有没有真正透传首 token 前是不是被 RAG 拖慢向量上下文是不是完整输出上限是不是太小代理有没有断开长连接前端有没有正确处理结束事件。排查时记住一个原则先判断断在哪里再决定改什么。如果断在生成前就查检索、上下文和模型排队如果断在生成中就查输出上限、上游错误和连接保持如果模型已完成但前端没显示完就查流式转发、代理缓冲和客户端解析。