17 篇博文 含有标签「streaming」

大多数后端工程师能够背诵 REST 契约：客户端发送请求，服务器处理请求，服务器返回状态码和响应体。200 表示成功，4xx 表示客户端出了问题，5xx 表示服务器出了故障。响应是确定性的，超时是可预测的，幂等键保证了安全重试。

而 LLM 后端违背了上述所有假设。一个返回 200 OK 的请求，可能意味着模型对整个响应产生了幻觉。一次成功的请求可能需要十二分钟，而不是十二毫秒。两次参数完全相同的请求会返回不同的结果。如果服务器在推理过程中超时，你根本不知道模型究竟是否已完成。

把 LLM 硬塞进传统 REST API 的团队，最终往往面对一堆补丁：超时杀死了正在运行的 Agent 任务，客户端把带幻觉的 200 当成成功，重试逻辑因为幂等键没有针对概率性操作设计而三次扣了用户的信用卡。本文将梳理这些不匹配最致命的地方，以及真正在生产环境中能站得住脚的接口模式。

大多数智能体流式实现都会在以下四个方面出错：代理静默地吞掉了流、用户关闭标签页而智能体却在后台运行导致持续消耗 token、页面刷新导致任务丢失，或者工具调用在流的中途失败而智能体陷入静默空闲。这些都不是模型问题。它们是基础设施问题，是团队在本地测试良好，但在生产环境中才会发现的问题。

这篇文章讨论的就是这种差距 —— 服务器端架构的决策决定了一个实时智能体 UI 是否真正可靠，而不仅仅是在演示环境中看起来令人惊叹。

大多数构建语音 AI 的团队都会以同样的方式发现延迟问题：在生产环境中，面对真实用户。演示 (Demo) 感觉不错。原型 (Prototype) 听起来也令人印象深刻。但当有人在实际通话中使用它时，会觉得它很机械——不是因为声音不好听，而是因为每次回复前的微小停顿让整个交互感觉像是和卫星信号不好的人在说话。

这种停顿几乎总是在 600 毫秒到 1.5 秒之间。而目标是低于 300 毫秒。这两个数字之间的差距解释了语音 AI 系统实际构建方式的一切。

第一个出问题的迹象：你的测试环境流式传输完美，但在生产环境中，每个用户都会看到一个空白屏幕，接着整个响应一次性出现。你检查了 LLM 提供商 —— 没问题。你检查了后端 —— 没问题。服务器正在流式传输 Token，但它们就是没能到达浏览器。

90% 的情况下，罪魁祸首是：NGINX 正在缓冲你的响应。

这是最常见的流式传输故障模式，而且除非你知道要去寻找它，否则它完全是不可见的。它还反映了生产环境流式传输中更广泛的问题：问题通常不在 LLM 集成上，而在于模型和用户之间的所有基础设施中。

你已经发布了一个性能卓越的 Agent。底层模型很强大 —— 它能检索到正确的上下文，调用正确的工具，并生成连贯的输出。然后你观察一个用户第一次尝试它，整个会话就崩溃了。他们不知道 Agent 什么时候在工作，看不出它是否理解了自己的意思。他们会在任务执行中途打断它，因为长时间的沉默感觉像是死机了。他们最终选择了放弃，并拨打你的支持热线。

模型不是问题所在，界面才是。

这是工程师在构建第一个 Agent 产品后不断重新发现的模式：人机交互（human-agent interaction）层本身就是一门工程学科，而大多数团队都将其视为事后才考虑的事情。他们在检索质量和工具准确性上花费了数月时间，然后直接接一个聊天框作为界面，并奇怪为什么即使后端日志显示成功，产品用起来还是感觉不可靠。