Deadline与剩余预算

把任务的总时限转换为每个下游操作可用时间。

Deadline是整个任务的时间上限，不是每个组件各自默认等待十秒。一次Agent可能经过检索、模型、多个工具和重试；若每层独立使用完整超时，累计时间会远超用户预期。剩余预算应沿调用链传播，并在每次新动作前重新判断。

Task保存绝对截止时间或明确时间窗口，Run和工具执行器计算剩余时长。模型调用、退避、连接重建和验证都消耗这份预算；不能只给主模型设置timeout，却让后台工具无限等待。跨服务传播时使用可信时间源与适当余量，避免依赖客户端时钟。

人工审批等待与活跃计算可分开管理。一个允许跨天等待的流程，不代表sandbox要持续运行三天；恢复后仍检查批准、资源和业务时效。行情或报价任务在排队后可能已失去价值，调度前应重新确认适用窗口，而非只要没执行过就继续。

接近deadline时采用明确策略：停止新搜索、缩小范围、输出已验证部分，或在用户授权下延长。不能为了准时而把未验证内容标成功。已发出的写操作即使超过时限，也要记录最终或unknown状态；timeout不是业务撤销。

重试只使用剩余预算，429的等待建议也需与截止条件协调。若外部系统需要更长完成时间，可转为异步Task并展示状态，而非保持一个即将断开的同步请求。每个子Agent分配的预算还应为父级合并和验证留出时间。

测试慢工具、连续429、队列积压、审批延迟和取消竞态。检查系统能否及时停止新增工作，保留可用产物并解释未完成原因。deadline治理减少不可控等待，也让成本与任务价值的取舍变得可见。

实践重点：模型、工具和重试共享剩余deadline；人工等待与计算执行分别处理。

验证抓手：模拟慢外部工具，检查停止、降级和剩余成果。

常见误区：每个组件独立10秒重试，累计突破用户时限。

OpenAI：Latency optimization；Temporal：执行状态与外部副作用。