那个批准了“单次调用成本”却从未衡量“单次解决任务成本”的智能体预算

在部署后的一个季度，AI 团队报告单次 API 调用平均成本降低了 25%。支持团队报告 AI 分流工单的平均处理时间从 4 轮增加到了 7 轮。这两个数字都是正确的。两个团队都在测量他们被要求优化的系统。夹在中间的财务团队无法核对仪表盘，因为这两个指标都不是以客户实际支付的东西来衡量的：一个已解决的工单。单次调用成本下降了，而单次任务解决成本上升了 40%。由于没有团队负责这个指标，所以没人注意到它的变动。

这是我在智能体（agentic）部署中见到的最常见的单位经济效益（unit-economics）失败，而且这不是一个测量上的 Bug，而是一个定义上的 Bug。供应商的价格页面展示了单次调用成本，因为这是他们计费的单位。由于电子表格的单元格刚好放得下，这个单位就被继承到了表格中。工程团队针对给定的单位进行优化。等到 API 经济与业务经济之间的鸿沟变得清晰可见时，这种影响已经累积了一个季度，而智能体整个时间都在基于错误的损失函数（loss function）被悄悄训练。

供应商 SKU 并非工作单位

客户支付的工作单位很少是模型提供商计费的单位。客户为已解决的工单、被接受的建议、完成的预订、或无需重写即可发布的生成简报付费。而供应商按 Token、席位或模型调用收费。这些并非相同的单位，它们之间的转换比例决定了智能体是否具有正向的单位经济效益。

业务案例中通常采用的朴素计算逻辑是：每个工单的平均 Token 数乘以每个 Token 的价格等于每个工单的成本。在实践中，这个数字往往偏差了 3 到 8 倍。一个现实的支持解决方案如果需要 2 到 3 个工具调用，则会触发 5 到 8 次 LLM 推理，每一次都带有累积的对话上下文。到了第 7 轮，每次调用的输入 Token 数量已经比第 1 轮增加了两倍。一个运行轮数翻倍的会话，其成本很容易达到原来的三到四倍，因为后期的每一轮都比前期昂贵。这些都不会在单次调用成本仪表盘上显示出来，因为单次调用成本是一个平均值，而其分布具有长尾效应。

这种模式的表现是：供应商的计费模式决定了形状，而团队的优化目标继承了这一形状。如果形状是按 Token 计费，团队就会优化更短的输出。如果形状是按调用计费，团队就会优化更少的调用。如果形状是按席位计费，团队就会优化更高的席位利用率。这些目标并不一定与客户付费的单位一致，而且在许多部署中，其中至少有一个目标是处于完全错位状态的。更短的输出可能会让用户产生后续问题；更少的调用可能会跳过解决问题所需的工具；更高的席位利用率可能是智能体以更低的单张工单质量处理了更多的工单。

分子中包含的、没人放进去的内容

当团队尝试计算单次任务解决成本时，第二个错误通常出现在分子上。直觉是只计算产生解决结果的 Token：成功的路径、被接受的输出、关闭工单的调用。其他一切——被放弃的对话、触发重试的失败工具调用、超时、以及在消耗了半个模型上下文后转人工的运行——都被归类为间接费用或被悄悄忽略。

正确的分子应该是该期间内该工作流的总投入（fully loaded spend），包括每一次失败的尝试、每一次重试、每一个被放弃的会话、每一次转人工、以及该工作流触发的每一次影子模式（shadow-mode）评估。分母仅包含被接受的结果。一个消耗了 4 万个 Token 并以转人工告终的运行会贡献分子，但不会贡献分母。用户在第 9 轮放弃的运行也是如此。内部评估标记为低质量并重新运行的也是如此。结果是一个最初看起来高得惊人的数字，而这正是重点。当团队第一次诚实地计算单次接受结果成本时，这个数字通常是 API 数学计算得出的 3 到 8 倍。这个差距就是每一个没有让业务得到其所付费内容的路径成本。

一个有用的改进是按失败模式拆分分子。为每次运行标记一组结果状态——接受、拒绝、放弃、超时、工具错误、转人工——并将其成本归入相应的类别。现在，你可以在报告单次结果成本的同时报告失败成本占比（Failure Cost Share）：即没有产生业务可接受结果的总工作流支出百分比。当失败成本占比发生变动时，它会告诉你本季度是哪类失败驱动了单位经济效益，而优化讨论也会从“让 Token 更便宜”转向“让这类特定的失败模式更少见”。

你在无意中训练的优化闭环

加载中…