4 篇博文 含有标签「async」

你发布的每一个 AI 功能，在成为产品决策之前，都首先是一个架构选择：这个模型调用是发生在用户的请求链路中，还是在用户无需等待的地方运行？这个选择通常由编写第一个原型的人做出，之后便不再被审视，并默默地决定了该功能在余下生命周期中的 p99 延迟。当事后分析（Post-mortem）询问为什么生产环境仪表盘在每周一上午 10 点变得无法使用时，答案几乎总是：某些本应属于冷路径（Cold-path）的东西被焊死在了热路径（Hot-path）中——而在 p50 时表现良好的模型，在流量扇出（Fan out）时，其 p99 的表现会变得极具灾难性。

热路径与冷路径的区别比 LLM 还要早。CQRS、流式架构、Lambda 架构——它们都在“必须立即响应”和“可以最终送达”之间划定了相同的界限。AI 工作负载的不同之处在于，走错方向的代价比以前高出了一个数量级。一个耗时 50 ms 的同步数据库查询变成 200 ms 是一次回归（Regression）。而一个在 p50 时耗时 1.2 秒的同步 LLM 调用在 p99 时变成 11 秒，则是你无意中做出的一项商业决策。

当 LLM 在单次响应中返回三个工具调用时，最显而易见的方法是并行运行它们。你会想到 asyncio.gather()，分发调用，收集结果，然后将它们返回给模型。代码在测试中运行正常，在预发环境中也表现良好。但在生产环境运行六周后，你开始注意到应用程序持有本应释放的 HTTP 连接。Token 配额的消耗速度快于使用指标所显示的。偶尔，一个发送电子邮件的工具会触发两次。

根本问题不在于 LLM 或工具 —— 而在于并发原语。asyncio.gather() 并非为多步智能体管道产生的故障模式而设计，将其作为并行工具执行的核心，会产生在问题复合之前难以察觉的问题。

大多数 AI agent 演示都在单个 HTTP 请求中运行。用户发送消息，agent 推理几秒钟，然后返回响应。干净、简单、易于理解。接着，有人要求 agent 执行需要 8 分钟的操作——运行测试套件、从 20 个网页起草报告、处理一批文档——于是整个架构悄然崩溃。

30 秒壁垒是真实存在的。云函数会超时。负载均衡器会断开空闲连接。移动端客户端会进入休眠。标准的 agent 框架都没有记录当你的任务生命周期超过传输层时该怎么办。它们中的大多数都会静默失败。

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

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

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