大多数构建语音 AI 的团队都会以同样的方式发现延迟问题：在生产环境中，面对真实用户。演示 (Demo) 感觉不错。原型 (Prototype) 听起来也令人印象深刻。但当有人在实际通话中使用它时，会觉得它很机械——不是因为声音不好听，而是因为每次回复前的微小停顿让整个交互感觉像是和卫星信号不好的人在说话。
这种停顿几乎总是在 600 毫秒到 1.5 秒之间。而目标是低于 300 毫秒。这两个数字之间的差距解释了语音 AI 系统实际构建方式的一切。
第一个出问题的迹象：你的测试环境流式传输完美，但在生产环境中，每个用户都会看到一个空白屏幕，接着整个响应一次性出现。你检查了 LLM 提供商 —— 没问题。你检查了后端 —— 没问题。服务器正在流式传输 Token，但它们就是没能到达浏览器。
90% 的情况下，罪魁祸首是：NGINX 正在缓冲你的响应。
这是最常见的流式传输故障模式，而且除非你知道要去寻找它，否则它完全是不可见的。它还反映了生产环境流式传输中更广泛的问题：问题通常不在 LLM 集成上，而在于模型和用户之间的所有基础设施中。
你已经发布了一个性能卓越的 Agent。底层模型很强大 —— 它能检索到正确的上下文，调用正确的工具，并生成连贯的输出。然后你观察一个用户第一次尝试它，整个会话就崩溃了。他们不知道 Agent 什么时候在工作，看不出它是否理解了自己的意思。他们会在任务执行中途打断它，因为长时间的沉默感觉像是死机了。他们最终选择了放弃，并拨打你的支持热线。
模型不是问题所在，界面才是。
这是工程师在构建第一个 Agent 产品后不断重新发现的模式：人机交互（human-agent interaction）层本身就是一门工程学科，而大多数团队都将其视为事后才考虑的事情。他们在检索质量和工具准确性上花费了数月时间，然后直接接一个聊天框作为界面，并奇怪为什么即使后端日志显示成功，产品用起来还是感觉不可靠。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
