用每任务成本衡量智能体投入产出

单个 token 更便宜，Agent 完成一件事却可能更贵。AWS ML Blog 这篇文章把成本核算单位从「模型调用」改成了「成功完成的任务」，再进一步追问：即便账单降下来了，它是否真的比原来的人工作业更有价值？

值得读的是两套相互衔接的方法：用 token、调用轮次和失败成本解释钱花在哪，再用人工基线、对照实验和业务结果判断钱花得值不值。但文中的价格算例是示意数据，并不是两个真实模型的实测排名。

为什么单价贵一倍，完成任务反而便宜 65%

任务指的是从请求发起到拿到可用结果的完整过程。例如处理一封客服邮件，包括读邮件、提取信息、调用账户 API、返回结果，期间所有模型调用都要计入。

作者列出了四个容易被单价掩盖的成本来源。

首先是分词器（tokenizer）。相同文本在不同模型里会拆成不同数量的 token。假设模型单价低 15%，处理同一份数据却多用 40% 的 token，价格优势就可能消失。原文还指出，部分分词器处理非拉丁文字时，token 数可能达到对应英文的 2–3 倍；这个比例不能直接套到所有中文任务上。

其次是输出。输出 token 的价格通常是输入的 3–5 倍，具体取决于模型系列。要求返回原始 JSON，模型却补上解释和客套话，这些内容也按输出价格收费。

第三是工具调用循环。模型调用工具后，需要带着历史对话和工具结果继续推理。多一次纠错，不只是多一次请求，还可能重新发送更长的上下文。

第四是推理开销。模型先生成 2,000 个推理 token，再输出 200 个答案 token，计费量可能是 2,200 个输出 token。部分模型隐藏推理内容，但依然收费。

原文用一个处理 750 词客户邮件的任务演示这种叠加效应，价格均为示意值：

• Model A：(6,150 × $0.50 + 750 × $1.50) / 1,000,000 = $0.0042。
• Model B：(1,000 × $1.00 + 150 × $3.00) / 1,000,000 = $0.00145。

Model B 的输入、输出单价都是 A 的两倍，总成本却低约 65%。原因是 A 的分词量多 50%，输出量达到三倍，还因为工具 schema 不匹配增加了两轮纠错。

选模型时，应比较同一任务的成功成本，而不只比较 token 单价。

失败后的处理方式也要进入公式。原文给出两种口径：

cost per successful task = cost per attempt / success rate

cost per successful task = cost per attempt + (1 - success rate) x escalation cost

第一行适用于失败后持续重试，第二行适用于失败后转交人工等处理路径。要留意第二行的统计前提：转交成本已被纳入，但最终是否完成、结果是否合格，仍需业务自己定义。

先把每次任务记清楚，再决定怎么省

Amazon Bedrock model evaluation 负责评估质量，可以使用提示数据集、自动指标和可选的人工评审。但质量分数不能直接换算成账单，还需要记录用量。

CountTokens 可以在不运行推理的情况下，比较不同模型处理同一输入需要多少 token。正式调用后，响应的 usage 中包含：

• inputTokens：未命中缓存的输入量。
• outputTokens：输出量。
• cacheReadInputTokens：缓存读取量。
• cacheWriteInputTokens：缓存写入量。

启用缓存时，总输入量是三个输入字段之和，费用却必须分别计算：未缓存输入按基础价格，缓存读取低于基础价格，缓存写入高于基础价格。把总输入量统一乘一个单价，会算错。

生产环境可以通过 model invocation logging，把调用数据写入 Amazon S3 或 Amazon CloudWatch Logs，再按任务汇总轮次和 token。请求 metadata 能用于区分团队、功能和实验，但它们是日志字段，不会自动进入 AWS Cost Explorer 或 Cost and Usage Report。Application inference profiles 可以进入两者，不过粒度是每天每种 usage type，适合分摊账单，难以直接核算单次任务。

因此，日志乘费率得到的是估算值。承诺用量、批处理价格和预置吞吐等因素还要另行建模，最后与 Cost and Usage Report 对账。

有了这些数据，再选择优化手段：

缓存适合减少多轮任务中重复发送的上下文，但要持续检查命中情况。原文提醒，应用和工具变化后，缓存检查点可能漂移，三个月后可能出现更多缓存写入，不能配置一次就长期不管。

Intelligent prompt routing 把简单请求交给同一模型系列中更便宜的模型；工具 schema 配合 maxTokens 限制输出；extended thinking 则按作者建议，先关闭，再通过基准测试证明开启后的质量收益。

Batch inference 可以让适用的批量单轮任务费率减半，但原文明确指出，它不支持工具调用和多轮交互，不能直接替代交互式 Agent。

Agent 有没有价值，要把人工复核也算进去

省钱只证明流程更便宜，不能证明值得部署。

作者要求先描述人工流程：谁触发、谁处理、在哪里交接、怎样算完成。随后在 Agent 上线前测量完成时间、排队时间、实际投入、重开率、升级率、任务成本和结果质量。上线后再凭记忆补基线，容易得到偏向 Agent 的比较。

Agent 流程则从第一天按实验记录。每次运行有 trace ID，并记录实验分组、提示词版本、策略版本、重试、工具调用、人工审批和结果。原文示例中的 humanMinutes: 35 尤其关键：机器返回了答案，不代表人工审核的 35 分钟可以从成本里消失。revenueEventId 则为后续关联营收事件提供入口。

下面这段原始 SQL，把按运行汇总的调用成本与业务结果关联，计算成功成本及人工投入：

SELECT
  w.workflow,
  w.variant,
  COUNT(*) AS runs,
  SUM(IF(w.outcome_status = 'success', 1, 0)) AS successes,
  ROUND(SUM(c.est_cost_usd) /
    NULLIF(SUM(IF(w.outcome_status = 'success', 1, 0)), 0), 2)
    AS cost_per_success,
  ROUND(SUM(w.retries) * 1.0 /
    NULLIF(SUM(IF(w.outcome_status = 'success', 1, 0)), 0), 2)
    AS retries_per_success,
  ROUND(SUM(w.human_minutes) /
    NULLIF(SUM(IF(w.outcome_status = 'success', 1, 0)), 0), 1)
    AS human_min_per_success
FROM workflow_runs w
JOIN invocation_costs_by_run c ON c.run_id = w.run_id
GROUP BY w.workflow, w.variant
ORDER BY cost_per_success DESC

要看的是分母使用成功次数，以及 GROUP BY w.workflow, w.variant 按实验组拆分结果。表名、列名和关联键都是示意，落地前必须匹配实际日志结构。

实验设计上，面向客户的流程可按访客、线索、账户或工单随机分组；内部支持和编程助手可以比较匹配的团队、仓库组或工作小组。比较同时覆盖效率、质量、成本和业务价值，避免把季节变化或团队调整造成的收益归给 Agent。

我的判断

我认同这篇最关键的取舍：先定义成功，再谈降本；先量人工基线，再谈替代收益。它比只展示调用次数、token 消耗或生成速度，更接近日常业务决策。

但文中没有提供真实模型的对照数据，也没有给出客户实验的样本量、观察周期和统计结果。便宜 65% 是算例，「先关推理」是优化起点，都不能当成适用于所有任务的实测结论。

公式也有前提。持续重试时用「单次成本除以成功率」，隐含每次尝试的成本和成功概率相对稳定。实际纠错可能增加上下文，也可能重复遇到同一种失败，应优先统计真实的累计成本。

原文开头承诺了五维评分卡，后文明确展开的比较维度只有效率、质量、成本、业务价值四项；提供的内容里没有完整列出第五维或具体阈值。绿灯扩量、黄灯调优、红灯退役，是决策框架，不能直接当验收标准。作者关于客户实践的描述，也仍属于经验之谈。

能拿来做什么

• 给 Node 工具调用流程建立任务级记录，把重试、缓存、人工复核和最终结果挂到同一个运行 ID，再计算每次成功的总成本。
• 比较模型时使用同一批真实输入，纳入中文文本、JSON 和实际工具 schema，同时记录成功率、调用轮次与输出量。
• 优化多轮 Agent 时先查重复上下文和纠错循环，再决定是否使用缓存、路由或更强模型，每次调整都复测质量。
• 评估 AI 编程助手时保留可比较的团队或仓库组，把代码审查与返工时间纳入人工投入，避免只用生成速度证明收益。