Agent 单位经济学：如何评估落地环境真实任务成本

先说结论

Agent 并不是一次输入对应一次输出的普通模型调用，而是一个会规划、检索、调用工具、检查结果、失败重试，并且可能需要人工复核的工作系统。如果只看 Token，尤其是主流的输入输出价格，我们很容易把“调用便宜”误认为“完成工作便宜”。

真正值得计算的指标是：一个达到质量要求、最终被业务接受的结果，究竟花了多少钱。这就是 Cost per Accepted Outcome，简称 CPAO——每个被接受结果的成本。

如果只保留一条原则，我会写成：优化 Agent 成本，并不是让每一步执行都尽可能便宜，而是在保证质量、安全和稳定性的前提下，让每一个真正有效的结果以更少的资源消耗、更低的返工成本以及更可控的尾部风险完成。

为什么 Agent 需要新的成本指标

假设有两个负责处理退款申请的客服 Agent。

Agent A 每次运行平均花费 0.08 元，Agent B 每次运行花费 0.13 元。只看单次成本，A 显然更便宜。

但进一步观察会发现：

• Agent A 的成功率只有 50%。它经常因为找错订单、参数不完整或接口调用失败而重新运行，部分结果还需要人工纠正。Agent B 的成功率则达到 95%，大多数任务一次就能完成。
• 要成功处理 100 个退款任务，Agent A 可能需要执行约 200 次；Agent B 只需要执行约 105 次。即使暂时不计算人工返工成本，B 的总成本也可能更低。

因此，模型价格、单次调用成本和单个 Run 的平均成本，都不能直接代表 Agent 的真实效率。OpenAI 在近期的 AI 投资管理建议中也提出，应关注“cost per accepted outcome”，并把重试、人工审核和返工计入完整成本，而不是只计算模型账单。《How to manage AI investments in the agentic era》

可以把 CPAO 写成一个简单公式：

CPAO = (模型成本 + 工具成本 + 基础设施成本 + 重试成本 + 人工复核与返工成本)
      / 通过业务验收的任务数

公式本身并不复杂，困难在于两个问题：哪些成本属于同一个任务，以及什么样的结果才算“被接受”。

一个 Agent 任务，可能包含许多次运行

想象一个负责处理供应商发票的 Agent。

它需要读取发票、识别字段、查找采购订单、核对金额，最后把数据写入 ERP 系统。

第一次运行时，OCR 把订单号中的字母 O 识别成了数字 0。Agent 查询 ERP 没有找到结果，于是把它判断为临时接口故障，连续重试三次。

第四次查询时，Agent 换了一种订单号格式，终于找到了采购订单，却又把含税金额和未税金额进行了比较。它最后生成了一份格式完整、措辞自信的核对报告，但财务人员复核后发现数据错误，拒绝接收。

从模型账单看，这次任务可能只花了 0.2 元。可是从业务角度看，它没有交付任何有效结果，还消耗了 OCR 服务、ERP API、运行资源和人工复核时间。那 0.2 元并不是“完成一张发票的成本”，而是一笔失败成本。

第二次运行可能消耗了 0.35 元。它正确识别订单号，使用确定性代码校验税额，成功写入 ERP，并从系统中回读最终状态。虽然这次运行使用了更多 Token，却真正完成了任务。

这意味着成本不能只归因到 run_id，而应归因到更上层的 task_id：

task_id: invoice-1842
 ├─ attempt 1
 │   ├─ 模型调用
 │   ├─ OCR 与 ERP 查询
 │   ├─ 多次重试
 │   └─ 人工复核后拒绝
 │
 └─ attempt 2
     ├─ 模型调用
     ├─ 工具调用
     ├─ ERP 写入
     └─ 验收通过

一次业务任务可能包含多个 Run、多个模型调用和几十次工具调用。只有把这些消耗全部挂到同一个任务上，才能知道完成这项工作究竟花了多少钱。如果将每次重试都单独计入一个新的“任务”，实际的失败成本就会被人为稀释，最终统计结果中的成本指标也会呈现出比真实情况更乐观的表现。

“Agent 说完成了”不等于任务完成

CPAO 的另一个关键是分母。

什么叫“通过业务验收的任务”？

模型输出一句“任务已完成”，显然不能算。HTTP 请求返回 200，也只能说明服务没有崩溃，不能证明 Agent 做对了事情。甚至最终生成了一份内容完整的报告，也不代表外部系统已经进入正确状态。

在发票处理场景中，可以把验收规则定义为：

• 必填字段完整；
• 发票金额计算正确；
• 采购订单匹配；
• ERP 写入成功；
• 从 ERP 回读的最终状态符合预期；
• 整个任务在规定时间内完成。

只有全部条件成立，这张发票才能计入一个 accepted outcome。

这让 CPAO 与 Agent 评测系统发生了直接联系。成本指标负责回答“花了多少钱”，评测和验收系统负责回答“是否真的完成”。

Langfuse 最近公开的一套金融 Agent 部署实践，就使用黄金数据集、领域评分器和明确的 PASS/FAIL 门槛来决定系统能否发布。这个案例的重要之处不在于使用了哪个评测工具，而在于它把“可以接受”变成了有证据、可复查的工程判断。《Building Deployment Gates for LLMs and AI Agents in Financial Services》

实际落地成本远不止模型账单

一项 Agent 任务的完整成本通常包括五部分。

1. 01 / 模型成本

   输入、输出、推理 Token，以及主 Agent、子 Agent、路由器和评审模型的全部调用。

2. 02 / 工具成本

   搜索、OCR、数据库、浏览器、代码沙箱、地图、支付或其他第三方 API。

3. 03 / 运行成本

   计算资源、存储、向量数据库、队列、日志、追踪和网络费用。

4. 04 / 失败成本

   超时、无效循环、重复检索、错误工具调用，以及失败后的重新运行。

5. 05 / 人工成本

   审核、纠错、补录、重新沟通和异常处理——往往被忽略，却可能远高于模型费用。

人工成本尤其容易被忽略。

假设一名财务复核人员的完全成本为每小时 180 元，一次 Agent 结果需要额外复核 35 秒，那么这次任务可归因的人工成本约为：

180 ÷ 3600 × 35 = 1.75 元

它可能远高于本次模型调用的费用。

这并不意味着所有员工时间都要归给 Agent。合理的做法是只计算由 Agent 输出直接引起、并且可以归因的复核和返工时间。例如原有流程本来就要求的合规审核，不应全部算成 Agent 的新增成本；但因为 Agent 经常填错字段而增加的二次检查，则应该计算。

OpenAI 在另一份成本计分卡中同样指出，业务的完整 AI 成本应包含员工时间、人工审核、重试和返工。最低的 Token 单价，并不一定产生最低的结果成本。《A scorecard for the AI age》

平均值会掩盖昂贵的失败循环

只报告平均 CPAO 仍然不够。

许多 Agent 的运行成本并不是均匀分布的。大多数任务可能只消耗几分钱，但少数任务会陷入循环，反复搜索、调用工具和生成新计划，最终花费数十倍成本后仍然失败。

Matt King 在关于 Agent 单位经济学的独立实践文章中描述了一个典型现象：大多数 Run 很便宜，但少量失控的重试循环会消耗大量预算。只看平均 Run 成本，很难发现这种尾部风险。《AI agent unit economics: why cost per successful run is the metric》

因此，一份实用的 Agent 成本报告至少应该同时展示：

1. 01 / 接受率

   结果接受率：多少任务真正通过业务验收。

2. 02 / 平均 CPAO

   每个被接受结果的平均成本。

3. 03 / 分位数

   CPAO 的 p50 与 p95，暴露尾部失控任务。

4. 04 / 失败占比

   失败任务消耗占总成本的比例。

5. 05 / 人工介入

   人工复核率与返工率。

6. 06 / 失败归因

   各类失败原因的成本贡献。

假如平均 CPAO 是 2 元，但 p95 已经达到 30 元，就说明系统存在一批容易失控的任务。此时最有效的优化可能不是换便宜模型，而是增加循环上限、改善工具错误分类，或者把某类异常任务更早转交人工。

Accepted Outcome Ledger

要落地 CPAO，可以为每个业务任务建立一份“被接受结果账本”，即 Accepted Outcome Ledger。

账本以 task_id 为主键，把所有相关运行、调用、复核和终态连接起来：

{
  "task_id": "invoice-1842",
  "workflow_version": "invoice-agent@3.7",
  "acceptance_rule_version": "invoice-v4",
  "attempts": 2,
  "model_cost": 0.21,
  "tool_cost": 0.06,
  "infrastructure_cost": 0.01,
  "human_review_seconds": 35,
  "terminal_state": "accepted",
  "accepted_at": "2026-08-09T10:18:00+08:00"
}

这里有几个容易遗漏的细节。

首先，账本应保存工作流、模型、提示词和验收规则的版本。否则系统升级后，历史成本无法进行公平比较。

其次，失败任务也必须进入账本。如果系统只记录成功任务，就无法知道多少预算浪费在重试、循环和无效输出上。

再次，成本记录最好是追加式的。模型调用、工具调用、人工审核和终态变化作为独立事件写入，最终再聚合成任务级成本。这样可以避免运行过程中部分失败导致记账丢失。

最后，业务终态需要独立验证。退款应回读支付系统，代码修改应运行测试和 CI，发票录入应查询 ERP，不能直接相信模型输出的完成声明。

例如，你想把部分任务从强模型迁移到便宜模型。不要只拿模型价格表估算，也不要立即切换全部流量：

便宜模型的平均 CPAO 看似略低，但其接受率通常会明显下降，同时带来更高的尾部成本和人工返工成本。表面上看，它降低了模型调用费用，实际上可能只是将成本从模型侧转移到了人工处理环节。

相比之下，混合路由并不是 Token 单价最低的方案，但它能够在基本保持质量稳定的前提下，有效降低平均成本和尾部成本，因此更适合作为逐步扩量的落地方案。

在质量、安全性和响应时效等核心指标不下降的前提下，候选方案必须能够在 CPAO、尾部成本或有效吞吐量等维度带来明确且可量化的收益。

这一原则可以避免团队为了追求账面成本下降，而通过降低质量标准、增加人工兜底等方式隐藏真实成本。

哪些 Agent 任务最适合使用 CPAO

CPAO 最适合具有明确业务终态的任务，例如客服问题解决、发票处理、退款审核、代码修复、内部 IT 工单、销售线索验证和合规资料检查。

开放式研究或创意任务也可以使用，但“被接受”的定义需要更加谨慎。它可以是用户明确采纳、经过少量编辑后采用、达到评分门槛，或者进入下一个正式工作阶段。

关键不是让所有任务使用同一套标准，而是让每类任务拥有稳定、版本化、可审计的验收口径。

当任务类型差异较大时，也不应该把它们混在一个 CPAO 中。例如“查询订单状态”和“处理跨境退款争议”的复杂度完全不同。更合理的方式是按任务类型、风险等级和复杂度分层统计。

从成本优化走向结果优化

Agent 成本优化中最常见的误区，是将目标简单定义为“减少 Token 消耗”。

减少无效上下文、提高缓存命中率、使用更小规模的模型以及压缩工具描述，确实能够降低单次调用成本。但如果这些优化以牺牲任务成功率为代价，导致更多重试、更复杂的失败恢复流程，甚至增加人工介入成本，那么系统的整体成本反而可能进一步上升。

CPAO（Cost Per Accepted Outcome）的核心价值，在于重新定义 Agent 成本优化的目标：优化对象不再是单次模型调用，而是最终被用户或业务真正接受的有效结果。

在这一框架下，模型团队需要关注一次完成率，而不仅仅是 Token 使用量；Agent 工程团队需要优化执行循环、工具调用失败和错误恢复机制；评测团队需要明确什么样的输出才算真正可接受；业务团队需要提供任务价值和验收标准；财务团队也能够获得一个更加合理、可解释的成本衡量方式。

最终，Agent 不应该被视为一系列模型调用的集合，而应该被看作一个能够持续交付业务结果的生产系统。

这也是 Agent 单位经济学最重要的意义：

优化 Agent 成本，并不是让每一步执行都尽可能便宜，而是在保证质量、安全和稳定性的前提下，让每一个真正有效的结果，以更少的资源消耗、更低的返工成本以及更可控的尾部风险完成。

当成本衡量从 Token 转向结果，团队才能真正找到 Agent 规模化落地所需要的优化方向。

延伸阅读

1. How to manage AI investments in the agentic eraOpenAI

   提出关注 cost per accepted outcome，并把重试、人工审核和返工计入完整成本。

2. A scorecard for the AI ageOpenAI

   完整 AI 成本应包含员工时间、人工审核、重试和返工；最低 Token 单价未必带来最低结果成本。

3. Building Deployment Gates for LLMs and AI Agents in Financial ServicesLangfuse · 2026.07.15

   用黄金数据集、领域评分器和明确 PASS/FAIL 门槛，把“可以接受”变成可复查的工程判断。

4. AI agent unit economics: why cost per successful run is the metricMatt King · AgentPing

   大多数 Run 很便宜，少量失控重试循环会吞掉大量预算；平均值难以暴露尾部风险。