AI Agent 监控：探针发 1 个 token，任务发 9000 个

昨天下午四点，我们的监控面板是绿的，四个生产任务一个都没跑完。两件事同时为真，因为面板测的和任务花的，根本不是同一种东西。

全绿的失败

探针没有坏。它按固定间隔向服务商发一次请求，返回 200，一整天没有断过。真正干活的任务不是这样：它一条会话要发大约九千个输入 token，在同一个小时里被拒了 17 次，返回 429。

这就是问题所在。服务是活着的，额度已经不够它干活了。而我们的面板只回答前半个问题，因为它的量纲是请求次数，不是 token。

我把这件事写下来，不是要抱怨服务商。我想说的是，agent 上生产之后，「服务通不通」和「我还能不能干活」变成了两个不同的问题，而且这两个问题的答案可以完全相反。大多数团队的仪表盘还停在上一代，测的是第一个。

额度按 token 计，探针不是

这不是某一家服务商的怪癖，而是行业口径。OpenAI 的接口文档写得很直白：同步接口有两条彼此独立的限速，每分钟请求数（RPM）和每分钟 token 数（TPM），两条线都会单独触发 429。（OpenAI 官方文档：Rate limits）

我们习惯用请求数当可用性的量纲，是因为过去十年的服务基本是这么工作的：一个健康检查返回 200，意思是这台机器还在。但一个返回 429 的请求，意思是这台机器在，它只是拒绝为你干活。

换个说法：前者测可达性，后者测容量。把这两件事塞进同一个探针，得到的必然是一个会撒谎的绿灯——它每次说真话，只是说的是一件跟你的业务无关的事。

我们做了直接验证。同一把 key，发一个 token 的请求，返回 200；发一条 agent 尺寸的会话（约九千输入 token），返回 429 AccountQuotaExceeded，服务商给出的重置点是下一个周一零点。这不是偶然一次，我们在两次独立事件里复现了同样的结果。

值得强调：这两种请求走的是同一个域名、同一把凭证、同一份限速规则。差别只在载荷大小。所以「探针绿灯」不是弱证据，它是零证据。

同一份文档里还有一个更少被读到的细节：单次请求占用多少限额，是按 max_tokens 和「按字符数估算的 token 数」两者取大来计算的。也就是说，一个探针不但载荷小，连它给自己留的输出上限都可以设得很小，于是它在限额账本上几乎不留痕迹。文档给的建议是对齐真实补全长度——这条建议是写给省额度的，同时也是写给监控盲区的。

探针载荷怎么定

这件事不需要新的系统，只需要从日志里取三个数，然后把探针改成两步。

1. 第一个数：真实会话输入 token 的 p50 和 p90。不要估，去日志里取，因为 agent 的请求大小分布很宽——同一条任务第一次跑和重试三次之后，可能差两个数量级。
2. 第二个数：会话数峰值。容量探针要能在峰值时段跑得动，否则它测的是闲时的额度。
3. 第三个数：单次任务重跑的成本。它决定你愿意为探针付多少钱——只要探针一天的消耗明显小于一次重跑，这笔账就是划算的。

拿到这三个数之后，探针就是两层的：一条轻探针保持高频，负责发现网络和可用区级别的中断；一条容量探针按 p50 到 p90 之间的固定载荷，低频（每十五分钟到一小时一次）验证额度与席位。两条探针的告警分开配置，不要合并。

还有一个工程细节：容量探针的载荷要用固定内容（例如同一段长文本重复拼接），不要用随机内容。固定内容才可能命中提示词缓存，成本更低，而且每天的消耗可比——不然你会看到一条自己都解释不了的额度曲线。

agent 的请求大小本身就是变量

传统服务的请求大小几乎固定，所以一个固定大小的探针足以代表真实流量。agent 不是。同一条任务，第一次跑可能是三十个请求、几万 token；中间重试几次，就变成八十万 token。工具定义、多轮上下文、失败重试，都会成倍地抬高单次会话的 token 数。

这意味着固定探针采到的不是平均值，而是一个极低点。我们此前统计过失败的工具调用分布：中位 1.6 秒返回，p90 直接顶到超时上限——同一条任务的耗时和 token 消耗都能差两个数量级。用一个 1 token 的探针去代表这种分布，等于用体温计量血压。

所以探针要换的不是频率，是载荷。把间隔从五分钟缩到一分钟，只会让一个测错东西的探针跑得更勤。

三种失败被监控合并成了一类

我们在同一个服务商下维护了一个三把 key 的凭证池，用意是冗余。实测下来只有两把可用，账面冗余度和实际冗余度差了一档——这本身是另一个话题。更值得写下来的是：这两把不可用的 key，坏的方式完全不同。

• 一把返回 429 AccountQuotaExceeded：额度花完了，等到重置日会自己恢复，不需要动手。
• 另一把返回 400 InvalidSubscription：订阅席位本身失效了，等到重置日永远不会恢复，需要人去续订或换席位。

这两件事在我们的监控里落在同一个格子里，因为它只报「通」或「不通」。处置动作却是相反的：一个是等，一个是立刻动手。我们第一版结论就把席位失效读成了额度耗尽，差点把它养到下一个重置日。等到那天发现额度恢复了、席位还是失效，你会以为是新的故障。

这就是失败分类的价值所在。分类不是为了告警好看，是因为不同的失败对应不同的时间尺度：额度耗尽以周计，席位失效以配置变更计，限速以分钟计，上游故障以小时计。合并成一类的监控，会把一周能修好的配置问题拖成看起来像容量规划的问题。

为什么这个坑总是被踩到

这不是技术难度问题，是分工问题。可用性监控大多挂在运维或平台团队名下，而「这个月的额度够不够跑完这批任务」属于采购和业务负责人。前者关心服务在不在，后者关心交付能不能按时出。两个角色都以为对方在盯这件事，于是没有人盯。

结果就是一套从虚拟机时代继承下来的探针，被原样用在了按 token 计费的 agent 负载上。它不报错，因为对它来说没有异常发生；它也不该被责怪，因为它从来没被要求回答容量问题。

请求成功，不是健康证据

第三个坑更隐蔽，也更容易让人对自己的系统过度自信。凭证池在遇到 429 时会中途轮换：先标记当前那把耗尽，再换下一把；池内全部耗尽时，会话会落到按量计费的备用通道上——而这一切结束时，任务正常完成，返回一份正常的回答，输出里没有任何一行字说明发生过什么。

于是「任务跑完了」这个事实，只能证明链路有兜底，不能证明被选中的那把 key 健康，也不能证明这次跑的是哪个模型。要判断具体某一环的状态，只有两条路：用真实尺寸的载荷直接探它，或者去读那次会话的运行记录里有没有轮换行。

其次，一次运行留下的记录至少要能回答四个问题：这次用的是哪个通道、哪个模型、消耗了多少输入和输出 token、中途有没有发生过轮换。缺了最后一项，前面三项都可能是错的。我们在补这一项的时候发现，日志里最难找的不是失败，而是「看起来一切正常但其实是备通道干的活」。

静默兜底还有一个代价，不在这一轮的账单上，在可比性上。备用通道是另一个模型的时候，同样的任务产出的结果跟主通道不再可比。工作照常交付，但那段产出已经不能跟历史批次放在同一张表里比了。这种不可比不会立刻报警，它会等到你下一次做对比评测或者复盘决策时才咬你一口，而那时你已经拿它做过判断了。

我们的判断

三句话。

第一，agent 的可用性口径要分成两层：可达性探针可以留，但必须再加一条用真实任务量级载荷的容量探针。只留前者，你监控的是一台机器在不在，而不是它能不能干活。

第二，失败必须分类报。额度耗尽、席位失效、限速、上游故障各自对应不同的处置和时间尺度，合并成一类等于自愿放弃判断力。这一条比第一条例省钱得多，也是我们这次事故里真正付了学费的部分。

第三，兜底可以留，但不能静默。换通道要写进运行记录；当它换了模型、影响了结果可比性时，要在结果里标出来。宁可交付一份标注了「本次由备用通道完成」的产出，也不要一份看起来干净、却跟历史批次不可比的产出。

给 AI App lead 的检查清单

边界条件

这套做法有它不适用的地方，写清楚比藏起来更有用。

• 按量计费的通道不会因为 token 花完而拒绝请求，它只会让账单变贵。容量探针的价值主要在套餐和席位制通道上，也就是企业最常用的那种采购方式。
• 上下文很小的任务（千 token 以下）里，1 token 探针和真实载荷的差异有限，改造收益也有限。
• 单通道、没有池、没有兜底的应用，池成员探测无意义，但失败分类同样必要——尤其是套餐席位失效这一类，它不会自愈。
• 容量探针会占用限额，在额度已经紧张的时刻，探测本身可能挤掉一次真实任务。要么给它留独立配额，要么在告警态下降频。

下一个决定

回到昨天下午四点那个绿灯。它没有说谎，它在回答一个我们十年前提出的问题。真正需要我们回答的是另一个问题：如果额度、席位和模型今天全部换了一遍，我的面板能告诉我吗？

如果答案是不能，那么下一次全绿的失败不是会不会发生，而是什么时候被发现的区别。你可以现在花一小时把探针载荷换掉，也可以等到某一批交付物静默地降级完成之后，再花一周去查它到底用的哪个模型。

参考来源：OpenAI 接口文档 Rate limits（RPM 与 TPM 为两条独立限速）： platform.openai.com/docs/guides/rate-limits。文中探针与凭证池的数据来自 OOMeta 自身生产环境的运行记录（服务商侧返回码与按小时聚合的 429 事件计数）， 已于 2026-09-23 与 09-24 两次独立核验。