6 篇博文 含有标签「async」

大多数团队都以相同的方式发现了同步 UI 的问题：用户点击"生成报告"，然后浏览器标签页陷入沉默长达四十秒。没有加载动画，没有进度提示，只有一个冻结的按钮。一半用户刷新页面并重复提交。另一半用户认为产品出了故障，直接关掉标签页。

根本问题不在于智能体的延迟——而在于 LLM 驱动的智能体所处的时间尺度，打破了同步请求-响应 UX 所有内置的假设。单次 GPT-4o 调用平均需要 8–15 秒。一个搜索网页、读取三份文档、写初稿再格式化输出的多步智能体，可能需要两到四分钟。你无法通过优化智能体来让这感觉变快，必须重新设计后端与 UI 之间的契约。

一个需要 90 秒才能完成任务的后台智能体，其操作基于的是 90 秒前的世界快照。当它返回结果时，用户可能已经导航到了不同的视图，开始了一个新的对话，归档了原始请求，或者完全关闭了标签页。大多数智能体框架无论如何都会交付结果，修改状态以反映结果，并将这次往返视为成功。但这并不是成功。这是智能体在一间空屋子中结束。

这种失败模式比直接丢弃结果更糟糕。丢弃结果只是一次投递失败——虽然烦人但可以恢复。而应用陈旧的结果则是对一个用户不再提出的问题的回答，它是针对不再匹配的状态编写的，往往会覆盖用户已经开始的新工作。用户会注意到发生了他们没有要求的事情，却无法重构原因，从而对系统失去信任，这种信任损失是简单的超时永远不会造成的。

解决办法不是更快的智能体，而是一个交付时的相关性门控，它将返回的时刻视为一个全新的决定，而不是派发时刻预设的定论。

你发布的每一个 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 相比，面临着完全不同的一类系统问题。大多数团队在最糟糕的时间点撞上了这堵墙：在他们已经发布了用户依赖的产品之后。