AI Agent成本黑洞：三分之一的调用花在了崩溃恢复上，却没有一个仪表盘在统计

一位开发者在 Linux 容器内跑手机 Agent，用自己的实际数据揭示了一个行业盲区：三分之一的 AI Agent 消息调用都花在了崩溃恢复上，而市面上所有主流成本工具对此视而不见。

被标准机构点名、却被所有仪表盘跳过的指标

FinOps 基金会发布的 AI 工具成本指南中，明确点出了关键指标：开发者应当强制关注每个用例的成本（而非总支出）、Token 消耗明细、GPU 利用率，以及错误率和重试率。

每个用例的成本——不是每个请求，不是每千 Token，而是每个产出结果的成本。

问题在于，几乎所有成本工具都在统计 Token 数量，因为机器能直接看到这个数字。但"产出结果"是看不见的：判断一个研究任务是否真正成功，需要人的主观判断，没人愿意去写那个决定"完成"的函数。

于是，标准机构认定的核心指标，被市面上每一块仪表盘跳过了。不是因为技术上做不到，而是因为这是整个技术栈中唯一需要有人承认"哪些运行什么都没产出"的数字。

FinOps 基金会（FinOps Foundation）是 Linux 基金会旗下的非营利组织，致力于制定云与新兴技术成本管理的行业标准与最佳实践，其发布的《FinOps for AI》等指南被大量企业采纳为成本治理框架。FinOps 的核心理念是打破财务、工程与业务之间的壁垒，让成本数据可归因、可问责。在 AI 场景中，它特别强调"单位经济性"——即把成本绑定到业务成果上，而非仅仅统计基础设施消耗。正因如此，指南将"每个用例的成本"列为首要指标，它要求团队回答的是"生成一份报告花多少钱"，而不是"这个月烧了多少 Token"。这一转变看似微小，实则把成本治理从基础设施层拉到了产品与业务层，也是本文所讨论"被跳过的分母"的制度背景。

164 条消息 vs 18 条消息：被尾部掩盖的真相

这位开发者在 56 天、64 个会话中记录了自己 Agent 的每一条消息，总计 19,090 个消息片段，全部存在一个 SQLite 文件里。他的中位数会话是 18 条消息，而最大的一次会话有 1,327 条——典型的重尾分布。

真正让他意外的是，按会话实际目的分类后：

• 崩溃恢复类会话：10 个会话，共 1,636 条消息
• 真正产出内容的"发布类"会话：3 个会话，共 536 条消息

崩溃恢复的平均会话长度是 164 条消息，是 18 条中位数的一个数量级。这意味着，即使分类存在少量误差，这个比例也不会大幅偏移。最终，全部消息中有三分之一花在了从失败中恢复上。

有个重要的局限值得说明：这些分类来自标题关键词匹配，而标题是开发者自己在选择菜单里写的，并非系统字段。但尾部数据足够扎实——11% 的"发布类"会话产出了 24 篇文章，其余花销换来的是一个能持续运行的系统。

重尾分布（heavy-tailed distribution）是统计学概念，指概率分布的尾部比正态分布衰减得慢得多，意味着极端值出现的概率远高于直觉预期。在 Agent 场景中，中位数会话只有 18 条消息，但最大值可达 1,327 条，二者相差两个数量级以上。这种分布的危险在于：平均值会被少数极长会话显著拉高，而基于平均值的成本估算会系统性低估真实支出。更关键的是，重尾分布中的尾部往往由失败与重试主导，而非正常产出，因此"用平均值做预算"的团队通常会同时错估总量和错判成本结构。识别重尾是采用分位数（如 P50、P95、P99）而非均值来汇报成本的前提，也是本文"能说出月账单却看不出分布"这一诊断的统计学根源。

为什么成本工具永远不会告诉你这些

作者有一块支出仪表盘，它准确地显示：上下文里 63% 是 bash 输出，一次网络搜索消耗 27,000 个字符。这些数字确实改变了他的写作策略。

但它从未显示过，三分之一的支出是用来买回自己的错误。

这不是工具的问题——一个崩溃的会话同样产生 Token，而 Token 正是工具所统计的对象。被浪费的工作不会留下借方记录，它留下的是一片空白。

这正是问题的核心：成本核算只能看到发生了什么，而 Agent 的大部分支出都花在了没有发生的事情上。 FinOps 指南也指出，可观测性工具"往往是最后一个获得预算的"，而预算控制和迭代限制"不是可选的保障措施"。

可观测性（observability）指通过日志、指标与链路追踪等手段，从系统外部推断其内部状态的能力。在 AI Agent 中，可观测性通常覆盖三个维度：模型调用（Token、延迟、错误码）、工具执行（网络请求、文件操作）以及编排逻辑（重试、分支、终止条件）。然而传统可观测性工具的关注点是"系统是否健康"，而非"这次运行是否产生了价值"。二者的差异造成本文指出的盲区——崩溃会话在指标上完全正常（Token 有消耗、调用有返回、错误被重试掩盖），却没有任何一条指标记录它"什么都没产出"。FinOps 指南特别提到可观测性工具"往往是最后一个获得预算的"，正是因为它的收益是间接的、防御性的，难以在季度汇报中量化，于是成本黑洞被反复推迟处理。

三个信号，帮你判断是否也在"无统计"状态

如果你符合以下任意一条，你就存在"每产出成本"的问题，不管你有没有用过这个词：

能说出月账单，但说不出最贵的那一周。 所有人都汇报总额，但几乎没人看过分布——而分布才是故事所在。一个月里有一次运行花费是正常值的八倍，和每次运行都稳定在中间值，是完全不同的两个月，但发票看起来一样。

团队里没人能说清哪个任务最贵。 无法归因到具体工作的支出，不产生任何问责机制。这是最常见的失败模式：仪表盘存在，数字也对，但数字指向不了任何人的决策。

最贵的那次运行，是你最记不住的那次。 你记得发布成功的那一次，但不记得之前的四次尝试、两条死分支、那次把上下文翻倍的重试。记忆由结果塑造，于是被放弃的路径的成本，从你对工作量的感知中消失了。

如何构建那个被跳过的分母

这个指标买不到，你必须自己定义"完成"。作者的建议是从一小块切片开始，而不是全部：

1. 把产出命名为机器可校验的形式。 不是"好的研究"，而是"这个路径下存在一个文件，包含生成该数字的查询"。
2. 同时统计两半。 支出是容易的分子，运行次数是容易的分母。产出结果是这里唯一真正困难的数字，也是所有人跳过的那个。
3. 让比例结果刺痛你。 如果运行了 200 次、发布了 4 个结果，你的每产出成本就是每次运行成本的五十倍。这不是测量缺陷，这就是测量结果，也是下一次架构讨论应该围绕的数字。

人们会质疑第一步，理由总是"感觉过度工程化"，而且"错误的启发式比没有启发式更糟"。这两点都对，所以第一块切片应该小到人能手动验证。自己验证 20 个，你就能知道"完成"的定义能否经受现实检验，然后再自动化。

作者的亲身经历是：定义"完成"的迭代速度远超预期。最初定义为"发表了文章"，四天里有三次判断错误，因为它把修正也算作胜利。加上"且事后没人发现错误"后，标准更苛刻也更准确。一个需要调优的分母，不是测量的弱点，而是测量开始起作用的信号。

尚未解决的问题

作者坦承这并非完整方案。他能定位崩溃恢复的切片，但仍无法给出金额数字——因为他用的是订阅制而非按 Token 付费。下一步是给运行定价，看看三分之一的消息是否也对应三分之一的支出。

工具在容易统计的那一半上表现出色，却在昂贵的那一半上保持沉默。这个问题值得每个运行 Agent 的团队认真面对。