Agent 为一个问题连续查询几次工具，看起来只是多走了几个步骤。真正记账时，每轮模型判断、工具服务、重试和人工复核都有可能产生独立成本。如果只看最后一句答案对应的模型用量，就无法解释为什么同类任务的费用差异很大。

成本设计先回答一个问题：一次用户任务从开始到终止，实际执行了哪些操作？不要先假定每个任务都应该有固定调用次数。链路可能因证据不足、权限边界或工具失败提前结束，也可能多轮收集信息后再继续。

用任务树保留调用关系

给用户任务一个稳定标识，每次模型调用和工具调用各有操作标识，并保留父操作。重试指向原操作，不能只在日志中留一个“重试次数”。这样可以把费用归集到任务，也能定位哪个决策引发了后续开销。

区分计划调用和实际调用。模型输出了三个待调用工具，不代表三个工具已经执行；执行器拒绝了其中一个，也不应给它记一笔假费用。实际调用记录来自执行器和服务返回，不能从自然语言总结中反推。

每一轮记录原始用量

模型调用记录实际输入、输出及供应商提供的适用使用量字段；工具调用记录服务的计费单位和实际消耗。具体价格随合同和计费规则变化，保留费率版本、币种及对账状态，不在代码里散落一组难以维护的固定单价。

如果工具背后又调用模型，应明确它的费用是否已经包含在工具单价中。不能既按工具服务全额计费，又把内部模型调用完整加一次。对于内部自建服务，资源成本与对外结算口径可以分别记录，报表中说明选用哪一种。

多轮模型调用往往不断携带历史。上下文裁剪、工具结果摘要和缓存策略都可能改变使用量。记录上下文策略版本与实际用量，比只记录“第几轮”更有利于解释成本变化。

失败、超时和取消分别处理

工具超时后，服务可能没有执行，也可能已经执行但响应丢失。成本状态先保留未知，根据调用记录或账单核对。对于写操作，还应先确认业务结果，不能为了补齐回复立即重试。

取消任务也不意味着前面的费用消失。已经完成的调用、进行中的调用和未发出的计划分开记录。对账时把已确认费用归集，未确认项目保留待核对，避免报表先把它们视为零，月底又突然增加。

一个示意事件可以是：

{
  "task_id": "task-42",
  "operation_id": "tool-read-2",
  "parent_operation_id": "reasoning-2",
  "retry_of": "tool-read-1",
  "execution_state": "result_unknown",
  "billing_state": "pending"
}

字段需要来自执行器和计费系统。模型可以解释成本摘要，但不能替这些系统确认费用。

人工与共享资源要另列

人工复核、失败排查和客户支持属于任务的实际服务成本。可以记录真实处理时长，再按团队选定的成本口径计算。不要让模型估算一个“本次节省人工时间”，直接从账单中抵扣。

共享资源包括工具服务基础设施、索引维护和长期存储。它们可以按租户、周期或使用量分摊，但规则应稳定且可说明。任务直接成本与共享分摊成本分列，才能看出方案优化真正改变了哪个部分。

用结果约束成本优化

可以按成功完成、转人工、拒绝执行和失败终止切分任务成本。一次调用很少却没有完成任务，不一定比多轮完成更便宜；如果后续人工处理增加，总服务成本可能反而上升。

比较策略时，使用相近任务集合和相同质量标准。检查高成本任务是因为重复读取、上下文膨胀、校验失败，还是任务本身需要多步证据。针对原因优化，避免简单限制轮数以后把复杂任务提前丢给用户。

成本账本首先需要可信的事件关系：任务是谁、操作是否实际执行、费用是否确认、重试属于哪次调用。把这些关系留下来，后续的预算、定价和架构取舍才有可以讨论的依据。