20—Token 计量与效率优化：每次测评消耗了多少 token

前面几篇分别解决了"跑得慢""切换贵""入口散""状态不明"的问题。工程效率最后还要落到一个更现实的指标上：每次测评到底消耗了多少 token，哪个步骤最值得优化。

资源计量在 SkillSentry 里属于诊断能力，具体字段可能落在 session.json、diagnostics、timing 或报告产物中。本文用 cost 结构示意计量方式；发布和自动化判断仍以 grading-summary.json、verdict、authoritative_pass_rate 等质量字段为准。

问题：测评消耗了多少 token？

在早期版本里，跑完一次 full 测评后，你只知道：

最终通过率是多少
大概花了 30-45 分钟

但不知道：

总共消耗了多少 token
哪个步骤最费 token
相比上次测评，资源消耗是涨了还是降了
smoke 模式和 full 模式的 token 用量差异有多大

后续版本引入 Token 计量机制，并把字段命名和 pipeline step 收敛到统一 contract。

计量机制

原理

每次 spawn subagent 前后记录 token usage 差值：

ini 复制代码

spawn 前：before_usage = session_status().usage.total_tokens
subagent 完成后：after_usage = session_status().usage.total_tokens
差值：cost[step_name] = after_usage - before_usage

可以写入 cost 诊断结构（具体落点以当前实现产物为准）：

json 复制代码

{
  "cost": {
    "static": 12340,
    "cases": 28500,
    "sync-pull": 890,
    "executor-with_run-1": 45200,
    "executor-with_run-2": 43800,
    "executor-with_run-3": 44100,
    "grader-report_run-1": 18700,
    "grader-report_run-2": 19200,
    "grader-report_run-3": 18900,
    "sync-push-results": 1200,
    "total": 232830
  }
}

计量边界

计量的是完整的 subagent 交互 token，包括：

subagent 读取的 SKILL.md、transcript 等输入
subagent 的推理和输出
主编排器的调度 prompt

不包括：

主编排器自身的思考（不作为 subagent 执行）
文件 I/O（读写文件不计 token）
等待时间（yield 期间不消耗 token）

典型 token 分布

基于 20+ 次测评的内部统计数据：

smoke 模式（4-5 eval, 1 run）

步骤	Token 占比	典型值
static	8%	~5K
cases	20%	~12K
executor (1 run)	55%	~35K
grader-report	15%	~10K
sync + 其他	2%	~1K
总计		~63K

这一模式的 token 用量主要集中在 executor，适合日常快速确认核心路径。

full 模式（33 eval, 3 runs）

步骤	Token 占比	典型值
static	3%	~12K
cases	8%	~28K
executor (3 runs)	60%	~210K
grader-report (3 runs)	22%	~77K
comparator + analyzer	5%	~18K
sync + 其他	2%	~5K
总计		~350K

这一模式的 token 用量明显更高，适合高风险或正式发布前的完整验证。

关键发现

Executor 占绝对大头------无论什么模式，executor 都消耗 55-60% 的 token。

原因很直观：executor 需要让 AI 完整地执行用户 prompt（模拟真实交互），而其他步骤都是分析性质的（读文件 → 做判断 → 输出结论）。

报告中的 token 展示

报告中可以展示 token 用量章节：

erlang 复制代码

┌─────────────────────────────────────────┐
│ Token 用量概览                           │
│                                         │
│ 总 Token：232,830                        │
│ 每 eval 平均：7,055 token                │
│                                         │
│ ┌──────────────────────────────────┐     │
│ │ ▓▓▓▓▓▓▓▓▓▓▓▓▓░░ executor 60%  │     │
│ │ ▓▓▓▓▓░░░░░░░░░░ grader-report 22% │  │
│ │ ▓▓░░░░░░░░░░░░░ cases      8%  │     │
│ │ ▓░░░░░░░░░░░░░░ static     3%  │     │
│ └──────────────────────────────────┘     │
└─────────────────────────────────────────┘

让用户一目了然：token 主要消耗在哪些步骤。

五种 token 优化方式

策略一：用 smoke 替代 full（减少完整流程开销）

大多数场景不需要 full 模式：

场景	适用模式	资源消耗
日常开发中验证改动	smoke	低
PR 合并前确认	quick	中
版本发布前完整验证	full	高

80% 的回归问题在 smoke 模式就能发现------因为核心路径的覆盖优先级最高。

策略二：利用缓存复用（避免重复执行）

SkillSentry 的缓存机制：

bash 复制代码

SKILL.md hash 一致 + 产物存在 → 复用，不重跑

如果你只改了 SKILL.md 的注释，hash 变了但逻辑没变------此时 cases 可以复用（用例与注释无关），只需要重跑 executor + grader-report。

手动指定方式：

xml 复制代码

测评 <Skill名> 用现有用例

跳过 static + cases，直接从 executor 开始，token 用量会明显下降。

策略三：减少 eval 数量

测评用例不是越多越好。根据收益递减规律：

bash 复制代码

5 个 eval：覆盖核心路径，置信度 ~70%
10 个 eval：覆盖主要场景，置信度 ~85%
15 个 eval：覆盖边界情况，置信度 ~92%
33 个 eval：完整覆盖，置信度 ~98%

从 33 减到 15 个 eval，token 减少 ~55%，置信度只降 6%。

适合的做法：full 模式跑一次 33 eval 确定基线，之后 regression 模式只跑失败过的 + 核心路径的子集。

策略四：Batch 控制

Grader v3.0 的 batch 机制（每批 8 个 eval）有一个隐含的 token 效率点：

ini 复制代码

batch size 8：每个 batch 需要加载 assertions 列表 + 评审指令 = ~2K token 固定开销
33 eval / 8 = 5 个 batch → 5 × 2K = 10K 固定开销

如果 batch size 改为 12：
33 eval / 12 = 3 个 batch → 3 × 2K = 6K 固定开销
但评审质量会下降（上下文过载）

当前 batch size 8 是质量和 token 用量之间的平衡点------不建议只为了减少 token 而增加 batch size。

策略五：预编译优化

当前 grader-report 有一个预编译优化：主会话在 spawn 前预读 evals.json，将 assertions 列表注入 subagent task prompt。

好处：subagent 不需要自己读 evals.json，减少重复上下文输入，也不会误读错误版本。

量化：减少的 token 规模取决于 evals.json 的大小、run 数量和 grader-report subagent 数量。用例越多，重复读取带来的上下文开销越明显。

不大，但属于额外优化------架构层面已经做了，使用时不需要增加操作。

Token 趋势追踪

结合 history.json，可以追踪 token 用量趋势：

json 复制代码

[
  {"run_at": "2026-05-01", "mode": "full", "total_tokens": 320000, "pass_rate": 0.82},
  {"run_at": "2026-05-05", "mode": "full", "total_tokens": 350000, "pass_rate": 0.87},
  {"run_at": "2026-05-11", "mode": "full", "total_tokens": 232830, "pass_rate": 0.92}
]

第三次 token 大幅下降的原因：Skill 改进后 executor 的重试减少了（更清晰的指令 → AI 一次做对 → 不需要多轮工具调用来纠错）。

反直觉发现：更好的 Skill 不仅通过率更高，token 用量也可能更低。因为 AI 一次做对的概率提高了，不需要反复试错消耗 token。

Token 计量与 CI 的结合

sentry_ci.py / CI 侧通常更关注通过率和 exit code，不一定直接报告 token 用量。但如果当前实现产物里保留了 cost 诊断结构，就可以被额外的监控脚本提取：

bash 复制代码

# 提取本次 CI 测评的 token 消耗
python3 -c "
import json, sys
session = json.load(open(sys.argv[1]))  # session/diagnostics/report 任选当前实现产物
cost = session.get('cost', {})
print(f'Total tokens: {cost.get(\"total\", \"N/A\")}')
" "$SESSION_DIR/session.json"

可以设置告警：如果某次测评的 token 消耗突然增加 50%，可能意味着 Skill 引入了死循环或冗余操作。

内部核算方式

本文只讨论 token 记录方法。不同运行环境、不同调用方式、不同 input/output 比例都会影响最终核算，直接在文章里写死数值很容易过期。

更稳妥的做法是只记录 token 用量，把后续核算留到内部报表或资源统计系统里处理：

text 复制代码

资源核算 = input_tokens × input 系数 + output_tokens × output 系数

如果当前系统只记录 total tokens，也可以先用粗略比例估算量级；正式做预算时，再拆分 input/output。

FAQ

Q：Token 计量会影响测评性能吗？

不会。计量是读取 session_status().usage------这是一个已有的计数器，不产生额外 API 调用。

Q：如果 subagent 超时重试，token 怎么算？

重试产生的 token 计入同一个 step。例如 executor-with_run-1 如果重试了一次，最终显示的是两次加总的 token 数。

Q：能否设置 token 预算上限，超了自动停止？

当前版本不支持自动停止。报告中展示 token 消耗后，使用者可以再决定是否调整下一轮模式。自动停止可能导致测评不完整，产生误导性的部分结果，因此这里保持人工决策。

来源：SkillSentry contract、session.json schema、历史测评 cost 数据。