2026 年 9 月 · 5 分钟阅读
监控层先坏:agent 运维的两类静默故障

关键定义
静默故障 系统不报错、不中断,却产出错误结论的失败形态。它集中在监控、回填与状态同步层,因为这几层缺少明确的失败信号。
原始读数 从被观测对象本身直接取得的当前状态记录,而不是本地缓存、历史记录或上一次成功的结果。负面结论只能由原始读数背书。
agent 上生产之后,最贵的错误结论往往不是 agent 失败,而是 agent 没动。这类结论由监控层自己产出,语气确定,还能被反复升级。我们踩到了它的两种形态。
故障一:探针尺寸不对,健康检查一直是绿的
我们的提供商余额监控此前用一个 1 个 token 的探针做健康检查,它长期返回正常。同一个时间窗内,错误日志里出现 18 次超出每周用量配额的失败记录,持续 6 小时。
原因不在提供商,在探针。套餐按用量计量,1 个 token 的请求几乎不消耗配额,所以它按设计就能通过。把探针换成 agent 真实请求的尺寸,约 9,000 输入 token,也就是一次真实会话的量级,同一个端点立刻返回 HTTP 429。
结论很直接:健康检查必须与真实负载同尺寸。一个比生产流量小三个数量级的探针,测的是连通性,不是可用性。
故障二:读数缺失被读成了负面结论
第二个故障更隐蔽。渠道节奏监控以本地发布记录为唯一口径,它连续输出同一个结论:某社交渠道静默 18 天。这个前提被反复升级,前后 6 次。
平台侧的只读页面显示,该账号当天有发布。差别不在渠道,在仪表。把手工发布回填进本地记录的脚本,在定时任务的解释器环境下缺少依赖,每次都以非零退出码失败,失败只写进日志里的一行警告。本地记录因此停在 9 月 5 日,而它无法区分渠道真的静默与回填失效这两种状态。
修复分三层。根因层固定解释器,让回填脚本不再依赖调用环境。读数层新增平台侧读数落盘:读失败就写错误,绝不写 0 或空值冒充读数。门禁层把最近发布时间改为本地记录与平台侧读数的最大值,并且要求任何静默结论必须由本渠道、日期新鲜的平台侧读数背书,否则降级为未核验。
失败路径被移除的方式不是加提示词,而是让仪表死掉时无法产出确定性结论。
同一类故障的外部证据
这不是我们独有的问题。Gravitee 对 919 名企业从业者的调查显示,88% 的组织在过去一年报告过 AI agent 安全事件,而确认事件率在 agent 规模翻倍的同时反而下降,报告把这归因于漏报与检测失败,而不是安全状况改善。行业观测性分析估计,不到十分之一的企业应用处于完全可观测状态。MLflow 的 2026 生产监控指南把信任 agent 自报列为最危险的盲点:agent 遇到错误时通常产出看起来合理的输出,而不是明确的错误信息。
把这些放在一起,agent 生产化的瓶颈分布就清楚了。模型能力、编排框架与单位成本都在快速被解决,而你怎么知道它现在是对的这一层几乎没有动。
我们的判断:三条规则
三条可以立刻执行的规则:
- 负面结论必须有同一对象的原始读数背书。本地记录、缓存值和上一次成功的结果都不算。没有数据只能输出未核验,不能输出没有发生。
- 探针与生产负载同尺寸。token 数、并发、payload 结构都要对齐,否则健康检查只证明网络通。
- 监控层自己的失败必须触发告警。如果监控挂掉和世界变安静在面板上长得一样,这套监控给出的绿灯值零信息。
留给买家的一个问题
你的 agent 面板能区分今天没有流量和采集器今天挂了吗?如果不能,现在看到的绿灯不是好消息,只是没有坏消息传出来。
参考来源: 本文两起故障均为本公司自建 agent 运维的一手记录(提供商配额探针:错误日志 6 小时内 18 次配额超限事件,1 token 探针返回正常而约 9,000 输入 token 的请求返回 HTTP 429;渠道节奏监控:本地记录停在 2026-09-05 并连续输出静默结论,平台侧只读读数显示当日有发布,根因为回填脚本解释器环境缺依赖),内部证据文件见 operations/scripts/provider_balance_monitor.sh、sales/logs/publish-reconcile.log|Gravitee《State of AI Agent Security 2026》(919 名从业者;88% 的组织报告过 agent 安全事件,确认事件率随 agent 规模翻倍而下降,归因于漏报与检测失败),gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control(curl HTTP 200)|MLflow《Monitoring Agentic AI in Production: 2026 Guide》(把信任 agent 自报列为最危险的盲点),mlflow.org/articles/monitoring-agentic-ai-in-production-2026-guide(curl HTTP 200)|Mastra AI agent observability guide(汇总 Gravitee 数据与可观测性覆盖率估计;二手汇总),mastra.ai/articles/ai-agent-observability(curl HTTP 200)。行业调查数字为厂商委托调查口径,本文只作方向性引用。
常见问题
为什么 1 个 token 的健康检查会长期显示正常?+
因为套餐按用量计量,1 个 token 的请求几乎不消耗配额,按设计就能通过。把探针换成约 9,000 输入 token 的 agent 尺寸请求后,同一个端点立刻返回 HTTP 429。探针的尺寸必须与生产流量对齐。
「渠道静默 18 天」这个结论错在哪?+
错在口径。监控以本地发布记录为唯一口径,而把手工发布回填进记录的脚本在定时任务的解释器环境下缺依赖、每次非零退出,失败只留下一行日志警告。记录停在 9 月 5 日,回填失效被读成了渠道静默。
修复分成哪三层?+
根因层固定解释器,让回填不再依赖调用环境;读数层新增平台侧读数落盘,读失败写错误而不是写 0;门禁层要求任何静默结论必须由本渠道、日期新鲜的平台侧读数背书,否则降级为未核验。
为什么不能把缺失的数据当成负面信号?+
因为缺失同时对应两种状态:对象真的没动,或者采集器坏了。两者的处理方式相反,所以在拿到原始读数之前,唯一诚实的输出是未核验。
外部数据支持这个判断吗?+
Gravitee 对 919 名从业者的调查显示,88% 的组织在过去一年报告过 agent 安全事件,同时确认事件率在 agent 规模翻倍时反而下降,报告归因于漏报与检测失败。MLflow 的生产监控指南也把信任 agent 自报列为最危险的盲点。
这套规则先用在哪些环节?+
先用在任何会产出「X 已死」「X 没动」「X 失败」这类结论的环节:渠道节奏、余额与配额、任务心跳、发布回填。这些结论最容易在数据缺失时被自动生成。
相关文章
Uber 四个月烧完全年 AI 预算:编码 agent 的成本失控是治理问题
Claude Code 采用率从 32% 涨到 84%,约 70% 的提交代码由 AI 生成,2026 全年 AI 预算在 4 月耗尽,人均成本 $150–$2,000/月,内部排行榜把 token 消费变成竞赛。我们的判断:失败模式不是拒绝采用,而是无治理的拥抱——用量计费需要 DevOps 级成本控制。
技能预算该花在模型不会的地方
SkillsBench:84 任务、7 个模型-harness 组合、7,308 条轨迹——人工策划技能平均 +16.2pp,医疗 +51.9pp 而软件工程只有 +4.5pp,模型自生成技能收益为负。我们的判断:agent 能力预算该记在领域程序性知识上,不是模型升级上。
AI 治理检查:发现 12 个影子 Agent——一家制造企业的治理觉醒
50+ AI Agent 在生产环境运行,但 IT 和安全团队都不知道具体有多少。OOMeta 的 Agent 发现扫描找到了 12 个未经授权的影子 Agent。
跨境合规文档审查:从 3 周缩短到 3 天——Agent 原生工作流实战
200+ 份供应商合同的 EU AI Act 合规审查,传统方式 3 周,Agent 原生工作流 3 天完成、准确率 94%。本文拆解三个维度的工作量爆炸与 Sprint 方案,解释为什么 Agent 原生工作流快 7 倍。