为什么 agent 在生产里失败：2.6 天日志分层

2026 年 9 月 23 日 20:01，我们舰队里一个定时 agent 的工具调用返回了一段 Python traceback。往上翻同一个文件，还躺着 88 次命令超时和 127 次供应商配额超限。三种失败挤在同一份日志里，修法却完全不同。

口径：我们数的是什么

这是 OOMeta 自建 agent 舰队的运行错误日志，保留窗口从 2026 年 9 月 21 日 07:18 到 9 月 23 日 20:01，共 2.6 天、16,787 行、139 个定时会话、1.4 MB。日志按大小轮转，所以这是一个窗口，不是全历史。分类规则是固定字符串匹配，任何人都能复跑。

为什么要把口径写得这么细？因为「agent 失败率」这个数字在不同口径下能差出十倍，而多数团队的面板上没有口径，只有一个百分比。

失败落在五层，不在一个平面

工具层：423 次工具调用返回错误。按工具分，终端命令 267 次，占 63%；代码执行 46 次，文件搜索 36 次，技能维护 29 次，读文件 15 次，补丁 10 次。

传输层：SSL 或连接中断 222 行，HTTP 429 共 80 行。这一层的特点是同一个请求重发往往能过，失败带有随机性。

配额层：127 次超出每周用量配额，分布在 33 个会话里。139 个会话中有 24% 撞过配额墙。这一层不会让连通性探针失败，只会拦住真实尺寸的请求。

脚本层：385 行 Python traceback。这一层最安静，因为它不影响会话继续跑，只是每次都用同一种方式失败，直到有人去读日志。

门控层：13 次命令被安全门控拦下。这不是故障，是策略生效，但它混在错误日志里，容易被当成失败计入分母。

模型层：0 条。

那个 0 才是重点

错误日志里没有一条来自模型输出质量。这不能读成模型没出错，只能读成这一层不在日志的观测面内。同一份数据，只监控模型的人看到 0，只监控工具的人看到 423，两个数字都真实，都不是全貌。

所以「agent 不稳定」这种结论几乎没有信息量。它把五个层的失败平均成一个数，而这五层的责任人、修复方式和预算来源都不一样：传输层该加重试，脚本层该改代码，配额层该谈采购，门控层根本不该进分母。

我们的判断

1. 分层计数器。工具、传输、配额、脚本、门控各留一个数。合成一个失败率，等于把维修单撕掉只留张收据。
2. 模型质量用评测集管，不进错误日志。错误日志管运行故障，评测集管输出对错。两者混在一起，运行团队会去调模型，模型团队会去看超时。
3. 每个计数器要能回答一个问题：这层现在正常吗？答不了的就是装饰，装饰不会在故障发生时叫醒任何人。

留给买家的一个问题

你现在的 agent 面板里，失败率的分母是什么？如果分母是所有请求，那么 63% 的失败来自同一个工具这件事会被平均掉。如果分母是成功任务，你至少知道自己花了多少钱买回一个结果。

口径与来源：本文全部数字来自 OOMeta 自建 agent 舰队的一手运行日志，非二手引用，也无外部厂商数据。复现路径：日志文件 ~/.hermes/logs/errors.log，保留窗口 2026-09-21 07:18 至 2026-09-23 20:01（1.4 MB，16,787 行）；分类采用固定字符串匹配，分别对应 exceeded the weekly usage quota、Command timed out、Tool returned error、Traceback、Blocked；会话数按日志内的会话标识去重；采集时间 2026-09-23 20:10 CST。窗口会随日志轮转变化，重新采集的数字不会与本文完全一致，口径一致。 ｜外部口径对照：退出码 124 的超时语义见 GNU coreutils timeout 手册 gnu.org/software/coreutils/manual/html_node/timeout-invocation.html（curl HTTP 200）；HTTP 429 的定义见 RFC 6585 第 4 节 rfc-editor.org/rfc/rfc6585（curl HTTP 200）。上述两条为术语口径引用，本文数字不依赖外部数据。