用延迟与Token识别Agent空转

你部署了一个会调用不稳定 API 的 AI Agent。这个 API 有 10% 的概率调用失败。你的 Agent 已配置为失败后重试——这是最佳实践，对吧？

然后，问题发生了。API 持续故障了一个小时，而你的 Agent 一直在重试。每次重试都会消耗 token。循环始终没有抛出错误，只是在不断重复。最终状态仍然是成功，因为 Agent 已经执行完毕（它在重试 N 次后放弃了）。但代价呢？成本直线上升，却没有完成任何实际工作。

这就是无限重试循环：不是崩溃，不是超时，只是悄无声息地消耗 token。日志看起来一切正常，错误率为零，但账单却在不断失血。

大多数监控系统之所以发现不了这个问题，是因为错误率和请求数无法捕捉它。Agent 并没有报错，而是在“成功地重试”。真正能够识别它的，是一种现在就可以测量的模式：延迟和 token 数量同步变化，而且这种变化不符合正常执行时的特征。

这种模式背后的数学原理

健康的 Agent 运行时，执行时长和 token 使用量之间存在一定关系。我们将其称为延迟与 token 比率。

一次正常运行：2 秒，500 个 token。比率：250 token/秒。

另一次正常运行：3 秒，800 个 token。比率：约 267 token/秒。

你的基线范围可能是：200～300 token/秒。

最初 30 秒：15,000 个 token。比率：500 token/秒，远高于基线。

接下来的 30 秒：又消耗了 15,000 个 token，而且还在继续攀升。

信号非常明确：延迟正在飙升，token 消耗速度也在不成比例地加快。Agent 在短时间内进行了大量 token 处理，这正是重试循环的典型特征——模型针对相同或相似的输入被反复调用。

一次正常但缓慢的运行（Agent 正在深入思考）：延迟高、token 数量也高，但比率仍处于正常区间。模型遇到了复杂问题，因此思考时间更长、使用的 token 更多，二者仍然成比例。

循环运行：延迟高，token 数量异常高，出现不成比例的峰值，比率突破基线。模型在同一个时间窗口内被一次又一次地调用，不断在重试周期中消耗 token。

构建这套启发式检测规则

下面是开发者应该采用的阈值模式：

第 1 步：建立基线

执行 20 次正常的 Agent 任务。对每次执行计算：

ratio = output_tokens / (duration_ms / 1000)

记录比率的第 50 百分位数和第 95 百分位数，分别命名为 p50_ratio 和 p95_ratio。

p95：400 token/秒（其中包含了“深入思考”类型的运行）

第 2 步：设置告警阈值

警戒区间：ratio > p95_ratio * 1.5（例如大于 600 token/秒）

告警区间：ratio > p95_ratio * 2.5（例如大于 1000 token/秒）

第 3 步：结合执行时长判断

如果延迟也高于正常范围（例如超过均值 2 个标准差），就应该提高告警权重。一次持续 45 秒、消耗 20,000 个 token 的运行（444 token/秒）可能没有问题。但一次持续 45 秒、消耗 50,000 个 token 的运行（1111 token/秒），几乎可以确定陷入了循环。

第 4 步：关注趋势，而不是单次运行

单次运行可能只是异常值。应该观察 5 分钟窗口内连续 3 次以上运行所呈现的模式：

如果有 2 次或更多运行突破告警阈值，就触发告警。

如果比率持续处于高位，说明循环仍在继续。

为什么它能在成本失控前发现循环

来看一组数字：

正常 Agent：每次运行消耗 500 个 token，按照常见价格计算，每次运行成本为 0.00075 美元。

循环持续 1 小时：重试 150 次，每个周期约消耗 5000 个 token，总计 750,000 个 token，每小时成本约为 1.13 美元。

循环持续 4 小时而未被发现：4.50 美元。金额不大，但仍然是个问题。

循环持续一整天：27 美元。已经大到足以在每周账单审查时被注意到，但这时已经太晚了。

通过延迟与 token 峰值，在 30 分钟时发现循环：成本约为 0.56 美元。问题被发现、循环被终止，也从中获得了经验。

延迟与 token 比率可以在最初的 2～3 次运行中发现循环，而不是等上几小时甚至几天。你能在成本仍然可以忽略不计时及时捕捉到它。

如何接入监控（无厂商锁定）

刚开始时，你不需要任何专用工具。只需为每次执行记录三个数值：

{
"agent_name": "my_agent",
"duration_ms": 45000,
"output_tokens": 22500,
"model": "gpt-4o",
"status": "success"
}

然后，在日志聚合器中计算这个比率——无论使用 Datadog、New Relic、CloudWatch，还是一个简单脚本都可以：

ratio = output_tokens / (duration_ms / 1000)
if ratio > 1000: # or your alert threshold
send_alert(f"High token-per-second ratio: {ratio}")

如果你封装了 LLM SDK（OpenAI、Anthropic 等），那么你已经可以获取 output_tokens 和请求时长。记录这两个数据只需要三行代码。

这套启发式规则之所以有效，是因为无限循环具有一种结构性特征：相对于模型本应花在思考上的时间，它们消耗 token 的速度非常快。模型在思考一个困难问题时，会运行较长时间，并按比例使用更多 token。重试循环则会驱使模型进行一次又一次浅层尝试，以突发方式快速消耗 token。

同时观察这两个维度，就能检测出循环所特有的失衡，而不需要解析日志、理解重试逻辑，也不需要配置复杂的告警规则。

它并不完美，某些极端情况可能会绕过检测。但它能够覆盖 99% 的情况：当你只观察延迟时，这种静默循环完全不可见；而当你什么都不监控时，它又会迅速吞噬预算。

从今天开始记录延迟和输出 token 数量。计算二者的比率，并设置阈值。你会在账单暴露问题之前，率先发现下一次循环。

如果你的 Agent 已经运行在生产环境中，现在就抽取最近 20 次运行并计算 p50 和 p95。这条基线就是你抵御成本缓慢失控的第一道防线。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。