Agent 降本应看任务成功成本

Token 账单降了，Agent 就更省钱了吗？作者给出的答案是：未必。便宜模型可能把省下的调用费，变成人工接管、返工和错误赔付。真正该比较的，是完成一件经过验证的正确任务，总共花了多少钱。

这篇文章的价值，在于把模型选型、失败重试、人工审核和结果验证放进同一本账。对正在接入 AI 编程或搭建业务 Agent 的团队，这比单看每百万 Token 报价更接近实际。不过，文中的客服案例是演算假设，不能当成生产实测。

为什么调用更便宜，完成任务反而更贵

作者设想了一个处理退款和账单工单的 Agent：读取工单、查询订单、执行政策，最后退款或解释拒绝原因，再关闭工单。

团队把它换成每 Token 价格便宜 5 倍的模型。Token 账单下降了 75%，但人工升级处理量约增至原来的 4 倍，还有错误退款和错误拒绝需要事后修复。把这些成本加回来，每张工单的解决成本反而翻倍。

这里要区分三个数：Token 单价、实际支出、每个成功结果的完整成本。单价由供应商决定；支出记录用了多少资源；最后一个数才回答业务是否划算。

Agent 尤其容易把它们混在一起。一次任务可能包含多轮模型调用、工具 API、浏览器或沙箱运行、检索、验证、人工审核和返工。失败任务消耗了资源，却没有交付正确结果。

作者引用 Anthropic 于 2025 年 6 月 13 日发布的研究系统文章：Agent 通常消耗聊天交互约 4 倍的 Token，多 Agent 系统约为 15 倍。同一研究评估中，仅 Token 用量就解释了约 80% 的性能差异。多花 Token 有时确实能换来更好的结果，不能直接视作浪费。

上下文还会逐步累积。如果每一步都重新发送历史消息和工具结果，又没有缓存或压缩，40 步任务可能远不止 10 步任务的 4 倍成本。不可见的 reasoning tokens 通常也要计费，不能只按最终回答长度估算。

作者建议统一使用下面这个指标：

                      model + tools + compute + retrieval + review + rework + incidents
cost per success  =  -------------------------------------------------------------------
                                number of tasks verified as successful

要盯住分母里的 verified：成功必须由测试、审核、对账或后续业务结果确认，不能由 Agent 自己宣布。

便宜模型能不能赢，关键看错误是否漏检

先看最简单的重试模型。每次尝试成本为 c，成功概率为 p，持续重试直到成功时，平均每次成功的支出约为 c / p。

一次花 $0.20、成功率 40%，平均每次成功约花 $0.50；一次花 $0.40、成功率 90%，平均约花 $0.44。调用价格翻倍，结果成本反而更低。

但这个公式有前提：失败能被识别，而且重试成本、成功概率大致稳定。业务里更麻烦的是「已经被接受，后来才发现错了」。作者把这类错误的比例称为 escape rate，也就是错误漏检率。

客服演算规定：每张工单最多自动尝试两次，都失败就交给人工；每次工具和计算费用 $0.05，人工解决一张工单 $8.00，一次漏检错误的发现、修复和补偿成本 $40.00。

作者给出的结果是，Token 成本从每张 $0.69 降到 $0.17，下降约 75%；完整解决成本却从 $1.32 升到 $3.14，增加约 138%。所有工单最终都由 Agent 或人工解决，因此比较的是同一种交付结果。

不过，提供的原文缺少模型参数表，无法完整复算这些结果。它适合说明成本如何转移，不能证明某个模型一定更贵。

如果人工接管换成 $0.50 的自动兜底，或者漏检错误只需 $1 修复，而非 $40，便宜模型就更有竞争力。低风险分类和路由，往往更符合这个条件。

先试便宜模型，失败后切强模型的级联方案也一样。作者按每次验证 $0.01 演算，暂不计便宜模型漏检错误时，每张工单约花 $1.17。要低于强模型方案的 $1.32，便宜模型的漏检率必须从 4% 降到约 0.7% 以下。

便宜模型能否省钱，取决于验证器能否拦住足够多的错误。

原文提到 Jev 这类决策模型可以承担判断，但没有给出它在该流程中的实测效果，不能直接推导出采购结论。

怎样把一次任务的完整账单串起来

落地的关键是统一 taskId。模型调用、工具调用、计算会话、检索和人工审核都带上它，再记录 workflow、agentRelease、模型和步骤。已有分布式追踪时，可以沿用 trace ID，或在根 span 上挂稳定的任务属性。

Token 还要按输入、输出、缓存输入、缓存写入和推理分别记录，并使用调用发生时的价格计算。否则跨模型、跨时间比较容易失真。

下面这条原文记录展示了如何把成本和验证结果关联：

{
  "taskId": "task_01JD2M...",
  "workflow": "support.refund_resolution",
  "agentRelease": "support-agent@4.2.0",
  "attempts": 2,
  "models": ["premium-model-2026-09"],
  "cost": {
    "tokensUsd": 1.14,
    "toolsUsd": 0.04,
    "computeUsd": 0.06,
    "humanReviewMinutes": 0,
    "humanReviewUsd": 0.00,
    "totalUsd": 1.24
  },
  "outcome": {
    "status": "resolved_by_agent",
    "verifiedBy": "policy_check+no_reopen_7d",
    "verifiedAt": "2026-11-14T09:00:00Z",
    "escaped": false
  }
}

要注意 verifiedBy：no_reopen_7d 要等 7 天观察期结束才能确认，不能在工单关闭时就把报表定稿。记录中的版本、模型和日期是示例字段，不是产品能力证明。

报表也不能只看平均值。作者建议同时追踪成功率、漏检率，以及单任务成本的 p95、p99，给步骤数、Token、金额和运行时间设置硬上限。触顶就停止并升级处理，避免少量失控循环吃掉大量预算。

优化顺序也因此改变：先提高首次成功率，再提前发现失败、降低漏检，之后才是按任务难度路由、缓存稳定前缀、压缩历史、调整各步骤的推理强度，最后讨论 Token 单价。

我的判断

我认同把 Token 当成本输入，把经过验证的结果当核算单位。尤其是会修改代码、操作业务系统的 Agent，人工返工和下游事故不能因为落在别的团队预算里，就从账上消失。

但作者说「先提高首次成功率通常更省钱」，仍属于经验判断，文中没有提供这些优化手段的统一对照实验。缓存和压缩也应检查命中条件及信息损失，不能默认质量完全不受影响。

研究数据同样要守住适用范围。2024 年的《AI Agents That Matter》主张同时优化准确率和成本；HAL 在 2025 年论文、ICLR 2026 工作中统计了 9 个模型、9 个基准上的 21,730 次运行，总成本约 $40,000，并发现提高推理强度在多数运行中降低了准确率。这支持按任务实测推理参数，不能推出所有任务都该少思考。

Gartner 于 2025 年 6 月 25 日预测，到 2027 年底超过 40% 的 Agentic AI 项目会取消。这是涉及成本、价值和风险控制的预测，不是已经发生的统计。

此外，「7 天没重开」只是成功的代理信号，用户不反馈不代表结果正确。相较于只统计调用费，完整成本更接近业务；相较于真实世界的全部损失，它仍可能漏项。团队应明确哪些已计入、哪些只能估算。

能拿来做什么

• 给现有前端或 Node Agent 选一个边界清楚的工作流，先定义成功标准和验证窗口，再用同一个 taskId 串起调用、工具执行及人工处理，避免一开始铺满所有流程。
• 对 AI 编程任务，把测试结果、代码审核和后续返工关联到任务记录；如果暂时无法准确折算人工金额，先记录审核分钟数与返工次数。
• 换便宜模型前，同时比较首次成功率、人工接管率和漏检率。试级联方案时，先验证检查器能否识别错误，不能只看它多收了多少调用费。
• 按作者的 30 天节奏推进：第一周定义成功，第二周接通成本与结果，第三周检查最贵的 1% 任务并设置上限，第四周只改一个变量；确认每次成功成本下降且漏检率没有上升，再保留改动。