这是什么

开发者给 AI Agent 配置「超时 30 秒」，通常指外层 Promise 的计时器。但 Agent 实际跑起来，模型调用、工具执行、重试退避、数据库写入是层层嵌套的。常见错误是每一层都从零开始计时——模型 10 秒、工具 10 秒、重试再加 10 秒，结果用户等了 60 秒。更隐蔽的问题是：前端已经显示「已停止」，后台工具仍在花钱、调接口、写数据。

文章作者用一个通过 7 项测试的 TypeScript 实验验证了一个核心判断：超时不应该是一个「相对数字」，而应该是一条「绝对截止时间」（deadlineAt）。入口处算一次，后续每一层只能消费剩余预算，不能重新开始。

这周三个框架的更新方向印证了这个判断：Vercel AI SDK 7.0.58 修复了 ToolLoopAgent 不遵守外层超时的 bug；Pydantic AI 2.26.0 把「取消」提升为一级 Runtime 事件；Google GenAI Python 2.17.0 新增了 TOO_MANY_TOOL_CALLS 终态。三家不约而同在补同一个漏洞。

行业怎么看

支持的声音认为，这是 Agent 工程化必须补的基础课。Agent 调用链比传统 Web 请求更长、更异步，简单的外层计时器根本兜不住底层。一个框架作者在社区里写道：「如果你只在外层 Promise.race 一个计时器，通常不会停止底层工作——你以为停了，其实它在花钱。」

反对的意见来自更务实的一派：有人认为，对 90% 的内部工具和原型来说，纠结 deadlineAt 和六种终态属于过度工程。多写一层计时器、多分类一个失败原因，对一个每周只跑几十次的内部脚本没意义。「先让 Agent 能跑通，再谈超时设计」是这一派的立场。

中间立场更值得注意：超时问题的本质不是「代码写得不对」，而是 Agent 第一次让「调用链」具备了支付成本（调用模型花钱、写库产生副作用）。传统 Web 请求超时只是用户体验问题，Agent 超时是真金白银和真实副作用。这是软件工程范式的迁移，不是某个框架的 bug。

对普通人的影响

对企业 IT：年底前如果有外包团队交付 Agent 项目，要求对方在合同里写清「单次会话最长执行时间」和「中途取消时后台如何处理」。这是过去 SaaS 合同里从没出现过的新条款。

对个人职场：用 Cursor、Devin、Manus 这类 Agent 工具时，遇到「卡住」不要反复点取消然后重试——你的预算可能被悄悄刷新，月底账单会很难看。建议手动记录每个任务的最大等待时长。

对消费市场：未来半年会看到越来越多 AI 产品宣传「30 秒完成任务」，但你需要知道这个数字通常只指外层计时。如果产品涉及支付、发布、写入数据库等动作，「超时」不等于「没执行」，可能产生重复扣费等副作用。