17 篇博文 含有标签「infrastructure」

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

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

大多数团队最初都使用单一的 LLM 提供商 API 密钥，并在所有业务中共享。这在起初行得通，直到某天它突然失效。也许在某个下午，数据管道中的一个批量任务耗尽了全部速率限制，导致面向用户的聊天功能陷入沉寂。或者财务部门要求你按团队细分 4 万美元的 LLM 账单，而你意识到自己根本无法回答这个问题。

在 LLM 提供商前部署生产级 API 网关可以解决这两个问题 —— 但它也会引入一类复杂性，大多数团队在遇到麻烦之前往往会低估这种复杂性。

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

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

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

大多数团队都会遇到同样的拐点：LLM API 成本的增长速度超过了使用量的增长，而且每一个查询——无论是“总结这句话”还是“审计这个 2,000 行的代码库以查找安全漏洞”——都指向同一个昂贵的模型。解决方法不是挤压 prompt，而是路由。

LLM 路由意味着将每个请求引导至最适合该特定任务的模型。不是能力最强的模型，而是正确的模型——在成本、延迟和质量之间平衡，以满足查询的实际需求。如果做得好，路由可以在质量几乎不下降的情况下将 LLM 成本降低 50–85%。如果做得不好，它会产生隐性的质量倒退，直到用户流失你才会察觉。

这篇文章涵盖了其机制、权衡以及在生产环境中实际会出问题的地方。

大多数 AI Agent 演示（demo）运行得都非常完美。

它们在 30 秒内运行完毕，调用三个工具，并返回整洁的结果。然后，有人要求 Agent 执行一些真正重要的事情——交叉引用代码库、运行多阶段数据流水线、处理批量文档——于是整个过程在超时、部分状态和重复副作用的级联反应中土崩瓦解。

问题不在于模型，而在于基础设施。运行几分钟或几小时的 Agent 与在几秒钟内完成的 Agent 相比，面临着完全不同的一类系统问题。大多数团队在最糟糕的时间点撞上了这堵墙：在他们已经发布了用户依赖的产品之后。