67 篇博文 含有标签「infrastructure」

你的 Agent 在预发布环境中通过了每一项测试。然后它进入了生产环境，发送了 4,000 封电子邮件，向一名客户收取了两次费用，并删除了一条本不该触碰的记录。预发布测试没有错 —— 它们只是测试了错误的东西。预发布环境让 Agent 看起来很安全，因为所有它可能破坏的东西都以错误的方式被伪造了：Mock 得足以不崩溃，但也真实得足以让你误以为测试是有意义的。

这就是“模拟保真度陷阱”。这与普通的软件测试失败不同。对于确定性函数，镜像生产环境 Schema 和 API 的预发布环境通常就足够了。对于 Agent 来说，行为产生于推理、工具输出以及跨多步轨迹的累积状态之间的相互作用。如果在这些维度中的任何一个上与生产环境存在偏差，预发布环境都会产生对其实际行为过度自信的 Agent。

一个带有精简 Python 处理程序的标准 Lambda 函数冷启动大约需要 250 毫秒。而你的 AI 智能体，在调用相同的运行时并添加了一些 SDK 导入后，冷启动需要 8-12 秒。如果再加上本地模型推理，时间将达到 40-120 秒。第一个触发已缩容部署的用户，在智能体响应之前需要等待一条电视广告的时间。这种差距——不是单次推理 Token 的延迟，也不是吞吐量，而是初始启动成本——正是大多数 Serverless AI 部署在用户体验上悄然失败的原因。

这个问题并非 Serverless 所特有，但 Serverless 让它变得显而易见。当你在常驻（always-on）基础设施上运行智能体时，你是在为闲置容量付费，且冷启动永远不会发生。当你为了降低成本而采用缩减至零（scale-to-zero）的策略时，每一个低流量时期都成为了等待下一个请求的陷阱。

大多数智能体流式实现都会在以下四个方面出错：代理静默地吞掉了流、用户关闭标签页而智能体却在后台运行导致持续消耗 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 相比，面临着完全不同的一类系统问题。大多数团队在最糟糕的时间点撞上了这堵墙：在他们已经发布了用户依赖的产品之后。