Agent 慢一点没关系？错，尾延迟会把一次工作变成两次事故
聊天机器人慢五秒，大多只是让人皱眉。Agent 慢五秒，可能让上层超时、触发重试，而第一次调用其实已经把数据写进系统。
这就是多步骤 Agent 最容易被低估的风险：延迟不是均匀增加的。它会沿着"读上下文 → 判断 → 调工具 → 写入 → 回读"逐级累积，最后从性能问题变成一致性问题。
一条典型的事故链
- Agent 调用外部系统创建记录；
- 下游已创建成功，但响应卡在网络上；
- 上层 30 秒超时，判断任务失败；
- 调度器自动重试；
- 第二条相同记录被创建；
- 监控只记录"一次重试成功"。
平均响应时间甚至可能仍然正常，事故却已经发生。
OpenAI 在 2026 年 8 月 25 日公布 Jalapeño 首批测量结果时，点出一个与 Agent 工程直接相关的事实：Agent 需要串行完成很多步骤，延迟会在整项任务里累积。官方还把吞吐、每瓦工作量和端到端延迟放在匹配用户体验的条件下比较，而不是只给一个峰值数字。
硬件结果有特定测试条件，不能照搬成你的业务收益。但这个测量思路值得照搬：Agent 性能的单位应该是"在截止时间内完成并验收的一项工作"。
给每次执行一个 deadline
不要让每个 SDK 各自决定 timeout。先给整项任务一个绝对截止时间，再把剩余预算向下传递：
pseudo
deadline = now + 120s
plan(timeout=min(25s, remaining(deadline)))
call_tool(timeout=min(45s, remaining(deadline)))
verify(timeout=min(20s, remaining(deadline)))
if remaining(deadline) < safe_write_window:
stop_at_checkpoint()关键点不是数字本身，而是下游知道整项任务还剩多少时间。没有剩余预算时，宁可停在可恢复检查点，也不要启动一个来不及确认结果的写操作。
把错误分成三种
- 瞬时失败：限流、短暂断网。指数退避，并限制最大次数。
- 确定性失败：权限、参数、业务规则。立即停止，不要拿重试掩盖配置错误。
- 状态不明：请求超时，但副作用可能已经发生。先按幂等键查询目标系统，再决定是否继续。
第三类最危险。所有创建、发布、付款之外的业务写入也应有稳定幂等键。成功标准必须是目标系统回读到最终状态，而不是客户端"没有抛异常"。
监控四个比平均值更有用的数
- 成功交付时长 P95/P99；
- 每次成功交付的尝试次数；
- 状态不明超时占比；
- 重复副作用和人工接管数。
如果只能先做一件事，就找出 P99 路径里最慢且方差最大的外部调用。它通常比换模型、改提示词更接近故障根源。
对于一人公司和小团队，没人能全天盯队列。一个可靠的 AI 员工应该在时限内推进工作，失败时停在安全位置，留下足够证据让人用最小动作接手。
Tipkay 面向小微企业组织垂类 AI 员工，关注的正是这种工作闭环：权限边界、检查点、人工确认与可恢复执行。一句话概括，就是"一个人的企业，也能有一支专业团队"，但这依赖工程边界，不依赖夸张承诺。
最后记住：平均延迟影响观感，尾延迟决定事故。把 deadline、幂等键和回读补齐之后，再谈"更快"。
参考资料：OpenAI《Jalapeño's first results show industry-leading speed and efficiency in AI inference》《The full stack behind abundant intelligence》；InferenceX。