本文要处理的问题当团队已经开始用 Agent 承接日常任务用量该怎么计量才能让「这项投入值不值」变成一个可以复算的问题。一、问题定位总量指标解释不了产出多数团队目前的计量方式停留在两个数上调用次数和 Token 总量。这两个数都有用但都回答不了「值不值」。原因在于它们度量的是消耗不是产出。同一个任务配置合理的 Agent 可能两轮就收敛配置不当的会反复自查、绕远路总量翻几倍而任务仍然没有完成。如果只盯总量这种浪费会被读成「业务量在涨」。行业侧的一组信号也印证了分化的存在头部企业与非头部企业之间的输出量差距在扩大而在企业侧宣称完成部署的组织中长期追踪明确指标的比例仍然很低。度量消耗的指标解释不了产出的问题。二、方案把计量拆成三层工程上的做法是把一次 Agent 运行拆成三层每层只对上一层负责。| 层次 | 计量对象 | 关键字段 | 失败表现 || 调用层 | 单次模型请求 | tokens_in、tokens_out、model、latency | 只有总量无法归因 || 任务层 | 一次业务任务 | task_id、steps、retry、total_tokens | 任务边界模糊无法对比 || 产出层 | 任务结果 | outcome、verified、cost_per_task | 有结果但无法核对 |三层里任务层容易被省略但它决定了能否算出单任务成本。任务边界的定义方式也很关键如果按部门汇总返工会被平摊进总量如果按 task_type 汇总同一类任务的重复执行会立刻显形。建议在任务发起时就写入 task_id而不是事后按时间切片反推。单任务成本的写法不复杂cost_per_task Σ(tokens_in * price_in tokens_out * price_out) tool_cost它比「每百万 Token 单价」更有意义因为便宜模型一旦推理效率低单次总消耗可能是更贵模型的数倍还没有计入返工。还要注意一点自动化调用正在成为主要消耗方。今年 2 月初起自动化产生的调用量已超过人机对话产生的量到 8 月自动化调用的日均量达到 7.3 万亿一年增长 14 倍。这个量级下计量口径的误差会被直接放大。三、可直接抄走的配置片段1事件埋点每次任务结束写一条记录{“task_id”: “job-20261006-0001”,“task_type”: “doc_summary”,“agent_id”: “agent-a”,“steps”: 3,“retry”: 1,“tokens_in”: 12840,“tokens_out”: 2210,“model”: “your-domain.test”,“outcome”: “accepted”,“verified_by”: “manual”,“started_at”: “2026-10-06T10:00:0008:00”,“duration_ms”: 18420}2口径表把算法与责任人固定下来fact_key: cost_per_tasklabel: 单任务成本unit: 元/任务formula: tokens_in * price_in tokens_out * price_out tool_costscope: 按 task_type 分组owner: 平台组review_cycle: quarterlysource: 计量库导出3核对脚本对同一 task_type 做前后对比python tools/compare_cost.py–task-type doc_summary–baseline 2026-07–current 2026-09–metric cost_per_task三个片段分工不同埋点回答「记什么」口径表回答「按谁算」核对脚本回答「怎么比」。还有一处细节值得注意单价字段不要写死在采集脚本里。价格调整在供应侧属于常规动作一旦写死历史数据的可复算性就会断掉。把单价放进独立的映射表按生效日期取用回算历史时才有依据。四、验证用固定任务集做回归改动前后要用同一批任务跑一遍不能只看总量。| 指标 | 计算方式 | 观察重点 || 任务完成率 | 通过校验的任务数 ÷ 提交任务数 | 有没有变差 || 单任务成本 | 该批任务总消耗 ÷ 任务数 | 是否真的降了 || 返工率 | 需要重跑的任务数 ÷ 总任务数 | 浪费藏在哪里 |三项里返工率容易被忽略但它往往解释了成本上升的大部分原因。回归的频率不必很高口径或采集逻辑有实质变动时跑一轮即可平时按月一次足够。跑得太勤会积累大量无差异数据反而看不出问题。五、踩坑记录坑一只统计总量不划分任务边界。 总量上涨既可能是业务增长也可能是效率退化。没有 task_id两种原因永远分不开。坑二把单次调用价格当成成本。 便宜的模型如果推理绕远总消耗可能反而更高。单价低不等于单任务成本低。坑三口径写在文档里不落在字段上。 口径一旦只存在于文档采集脚本就不会按它执行三个月后没人能复现当时的结论。坑四只改采集端不回改历史数据。 新旧口径混在一张表里趋势图会出现断层看起来像业务突然变化。变更时至少要标注生效时间。六、小结整套链路的投入并不高难点在顺序先确定任务边界再固定口径之后才谈优化。跳过任何一步后面的数据都只能参考不能用来做判断。如果只能先做一件事建议从任务边界开始。它不需要任何新采购只需要在发起任务时补一个标识却决定了后面所有指标能不能对上。