Agent Token 强度指标调研

1. 为什么输入 + 输出 token 不够

把一次 LLM 调用的账单简化为「输入 token 数 + 输出 token 数」，本质上假设两种 token 是同质可加的。但在 agent 场景里，这个假设会丢失大量信息。

首先，两类 token 的经济权重不同。主流 API 的输出 token 单价通常是输入的 4–8 倍¹，把两者直接相加会低估生成成本。其次，信息内容不同：输入端往往是上下文、历史记录、工具返回的重复灌注；输出端才是推理痕迹与最终答案。最后，agent 行为会放大这种不对称：多轮反思、代码审查、工具调用会把同一段上下文反复塞回输入，导致输入 token 激增，而真正的「思考强度」并不与输入量成正比。

因此，研究者开始从三个维度寻找更精细的指标：

结构维度：输入/输出比、输出/输入比、缓存命中比；
质量维度：每 token 智能（OckScore）、深度思考比率（DTR）；
任务维度：任务级成本（CPST）、通信税、token 生命周期分解。

本节注释

Glean, "Key metrics for evaluating token efficiency in AI systems", 2026；OpenAI / Anthropic 等 2026 年定价页亦显示输出 token 单价显著高于输入。↩

2. 单一模型层的强度指标

2.1 输入/输出比（I/O Ratio）与输出/输入比

最直接的改进是把输入与输出分开看。学界常用两种形式：

输入/输出比

I/O Ratio = Input Tokens / Output Tokens

高比值意味着 agent 在「吃」大量上下文后才产生少量输出，典型场景是代码审查、RAG 检索后的总结。AgentTaxo 在 MetaGPT、CAMEL、AgentVerse 三种拓扑中测得输入/输出比在 2:1 到 3:1 之间，说明上下文加载是多 agent 系统的主要成本¹。

输出/输入比

Output / Input = Output Tokens / Input Tokens

商业监控更常用这个方向。Glean 将其列为检测「冗长回复」和「上下文膨胀」的核心指标：分类任务应低，内容生成自然偏高²。

不同任务形态的 I/O 比示意

基于文献中观察到的区间，非实测数据。

图 1不同任务 I/O 比的典型区间。agent 编程场景下输入 token 可能远超输出。

2.2 每 token 智能：OckBench 与 OckScore

OckBench（Du et al., 2025）提出把准确率和输出 token 数 jointly 评估。其核心指标 OckScore 的定义为：

OckScore

S_Ock = Accuracy − λ · log(T / C)

其中 T 为平均输出 token 数，λ 为惩罚系数，C 为归一化常数。原论文取 λ=10、C=10,000³。

该指标把 token 当作成本而非免费资源：正确性优先，但过度冗长会被对数惩罚。OckBench 发现，开源模型与闭源模型在准确率上接近，但 token 效率可相差 26 倍；更小的模型为了补偿能力往往产生更长的推理链，反而形成「过度思考税」（Overthinking Tax）⁴。

2.3 推理深度：Deep-Thinking Ratio

如果输出 token 数本身不可靠，能不能直接测量模型「思考」的强度？《Think Deep, Not Just Long》（2026）提出 Deep-Thinking Ratio（DTR），不数 token，而是观察每个生成 token 在模型内部各层的预测分布何时收敛。

Deep-Thinking Ratio

DTR(S) = (1/T) Σ_t 𝟙[c_t ≥ ⌈(1−ρ)L⌉]

对序列 S 的每个位置 t，计算中间层预测与最终层预测的 Jensen-Shannon 散度，找出预测分布「稳定下来」的层 c_t；若稳定点落在较深区域，则该 token 被计为 deep-thinking token。DTR 与准确率的相关性显著高于长度或置信度⁵。

DTR 的优点是与任务无关，不需要人工标注推理结构；缺点是需要访问模型内部 hidden states，对 API 用户通常不可用。它更适合自托管模型或作为训练/蒸馏时的反馈信号。

2.4 可控推理强度：reasoning_effort

工业界给出的工程化杠杆是 reasoning_effort 参数。OpenAI 的 o1/o3/gpt-5.6 系列支持 low / medium / high / xhigh / max 等档位，更低档位响应更快、token 更少，更高档位让模型「想得更完整」⁶。这相当于把「强度」暴露为可调控制变量，而非仅从事后统计中推断。

本节注释

Chen et al., "Token Economics for LLM Agents: A Dual-View Study", arXiv:2605.09104, 2026.↩
Glean, "Key metrics for evaluating token efficiency in AI systems", 2026.↩
Du et al., "OckBench: Measuring the Efficiency of LLM Reasoning", arXiv:2511.05722, 2025.↩
同注 3。↩
"Think Deep, Not Just Long: Measuring LLM Reasoning Effort via Deep-Thinking Tokens", arXiv:2602.13517, 2026.↩
OpenAI API docs, "Reasoning models"; OpenRouter docs, "Reasoning Tokens". 2025–2026.↩

3. 多 Agent / 工作流层的指标

3.1 通信税与 AgentTaxo

多 agent 系统的成本不只在每个 agent 的生成，还在于 agent 之间反复同步状态。AgentTaxo 把 agent 角色抽象为 Planner / Reasoner / Verifier 三类，并测得线性、扁平、层级三种拓扑的输入/输出比约为 2:1–3:1¹。这说明多 agent 的「强度」不能单看某个模型调用，而要看协作结构引入的通信税（communication tax）。

在 ChatDev 的 30 个软件开发任务中，迭代代码审查阶段消耗了 59.4% 的 token，初始代码生成仅占 8.6%²。也就是说，agent 的「强度」大量花费在互相检查、修正、同步，而不是一次性产出。

3.2 任务级成本：CPST 与 Cost per Resolved Task

比「每次调用」更高一层的是「每次成功任务」。Digital Applied 提出 Cost-Per-Successful-Task（CPST）：

CPST

CPST = 总花费（输入 + 输出 + 工具 + 重试 + 缓存摊销） / 成功交付的任务数

它把失败尝试、重试、工具调用都计入分母，直接对应生产预算³。

Glean 的等价表述是 Cost per Resolved Task：完成一个支持工单、准确回答一个问题、生成并获批一篇文档所需的总 token 成本⁴。

3.3 Token 生命周期分解

《Token Economics for LLM Agents》把 token 按生命周期分为五类，可作为分析强度的细粒度框架⁵：

表 1：Token 的经济分类
类别	含义	经济属性
Input Token	用户提示、上下文	中间产品
Reasoning Token	链式思考 / hidden CoT	中间产品
Communication Token	多 agent 间共享状态	中间产品
External Token	RAG / API / 工具返回	中间产品
Output Token	最终交付给用户的内容	最终产出

对 agent 强度的衡量，本质上是在这五类 token 之间做成本归因：哪些花在「思考」，哪些花在「沟通」，哪些才是真正的交付。

本节注释

AgentTaxo, ICML 2025；亦见 Chen et al., "Token Economics for LLM Agents" 中的综述。↩
Salim et al., "Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering", arXiv:2601.14470, 2026.↩
Digital Applied, "Cost-Per-Successful-Task: A New AI Evaluation Metric", 2026.↩
Glean, "Key metrics for evaluating token efficiency in AI systems", 2026.↩
Chen et al., "Token Economics for LLM Agents: A Dual-View Study", arXiv:2605.09104, 2026.↩

4. 对词元账房的可行建议

基于上述研究，可以在现有 rt_usage.db 的 session_model_usage 表基础上，增量引入以下指标，而无需改变采集层：

立即可做：在 dashboard 中拆分 Input / Output / Cache Read / Cache Write，并计算加权成本与 I/O 比。

表 2：建议在词元账房中追踪的指标
指标	计算方式	用途
输出/输入比	output / input	检测单次调用是否过度冗长或上下文膨胀
缓存依赖比	cache_read / (input + cache_read)	衡量系统提示/历史上下文的复用效率
加权成本	input·p_in + output·p_out + cache_read·p_cache	反映真实经济开销，而非原始 token 数
每任务 token	session / task 内总 token ÷ 任务数	把强度落到业务单元
推理 token 占比	reasoning_tokens / output_tokens	对显式返回 reasoning 的模型衡量思考深度

更进一步，可仿照 CPST 在 dashboard 增加一个「每成功任务成本」视图：把失败调用、重试、工具调用开销都摊到最终成功交付的任务上。这需要 agent 在 extra 字段中标记 task_id 与 success/fail，但计算口径本身不复杂。

对于 DTR 这类需要模型内部状态的指标，目前只能应用于本地可获取 hidden states 的模型；对 API 调用，可退而用 reasoning_tokens 或输出长度作为代理指标。

5. 结论

输入 token 与输出 token 的简单相加，确实无法刻画 agent 的「使用强度」。学界和工业界正在从三个方向补全这个缺口：

结构指标：I/O 比、缓存比、加权成本，帮助识别上下文膨胀和通信税；
质量指标：OckScore、DTR，把 token 效率与正确性/推理深度挂钩；
任务指标：CPST、生命周期分解，把成本归因到实际业务产出。

对现有词元账房而言，最务实的下一步是：先区分输入/输出/缓存并计算加权成本与比率，再逐步引入任务级归因。这样既能回答「用了多少 token」，也能回答「这些 token 花在了哪里、值不值」。

zigzagYang

ArtiPig · 2026 年 8 月 20 日

ZP-TOKEN-METRICS-20260820

—— 全文完 ——