1. 从 Elo-per-token 到可复现的 Agent 算力账本如果你正在用 Bradley-Terry 把 LLM Agent 的评测结果聚合成跨任务 Elo却被 token 消耗和收益递减曲线卡住可以先从 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentelo_per_token_intro 获取 API Key再把客户端 base_url 指向 https://taotoken.net/api。这样做的目的不是换一个“跑分入口”而是让评测链路里的每一次模型调用都有统一计费口径、统一 Base URL、统一 Key 管理后面做 Elo-per-token 分析时才能把“分数提升”和“Token 花销”放到同一张表里。Elo-per-token 的核心不是单次跑分而是把同一任务内的排序结果用 Bradley-Terry 聚合成跨任务 Elo再除以 token 消耗看扩展规律。实际工程里Agent 的测试时算力策略通常包括多次采样、并行投票、多轮反思、工具调用重试、结果重排等。每加一层策略Elo 可能上升但 token 也会非线性增长。问题在于很多评测脚本只记录最终准确率或排名不记录 prompt_tokens、completion_tokens、缓存命中、重试次数。最后你看到“某个策略更强”却说不清它每提升 1 个 Elo 点多花了多少 token也无法判断是否已经进入收益递减区间。这篇文章从 LLM Agent 评测与推理成本工程师的视角给出一条可复现路径在 TaoToken 上准备 Key把 Claude Code、Codex 等客户端的 base_url 指到 TaoToken API用本地命令统计每次调用的 token用 Bradley-Terry 脚本把任务内排序聚合成跨任务 Elo最后用 Elo-per-token 对照表决定算力策略是否值得继续加码。全文命令都在你本地执行不涉及任何生产库直连也不建议把 Agent 直接挂到关键数据源上。2. 为什么先把 base_url 指向 TaoTokenKey、模型与计费口径在做 Agent 评测时最容易被忽略的是“调用入口一致性”。如果 A 策略走一个供应商B 策略走另一个供应商或者同一策略里不同模型走不同 Key那么 token 统计、限流行为、模型版本都会成为噪声。Elo-per-token 分析要求你把模型调用尽量收敛到同一入口至少在同一轮评测里保持 base_url、Key、模型 ID、超时策略一致。推荐的做法是在准备调用模型前到 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentelo_per_token_setup 注册并创建 API Key然后把所有评测客户端的 base_url 指向https://taotoken.net/api注意Base URL 在工具配置里不要加 UTM 参数保持干净的 API 入口。Key 用占位符YOUR_API_KEY表示实际使用时换成你在控制台创建的 Key。创建 Key 的入口在文末 CTA 里也会给出但配置阶段先把三件事固定下来每个评测策略使用独立 Key 或至少独立标签便于事后按策略统计消耗。所有模型调用统一走https://taotoken.net/api不要在不同脚本里混用多个 Base URL。日志里同时记录模型 ID、请求时间、prompt_tokens、completion_tokens、total_tokens、重试次数和策略名称。如果你用 CC Switch 管理多套客户端配置可以把“三件套”拆成三个落点Claude Code 的settings.json、Codex 的config.toml、以及 shell 环境变量。三者都指向 TaoToken 的 Base URL但环境变量命名不要混用Claude Code 用ANTHROPIC_*Codex 用独立的TAOTOKEN_API_KEY或它自己的 provider 配置。混用会导致某些客户端读不到 Key或者把 Anthropic 的变量误塞给 Codex。3. Claude Codesettings.json 与 ANTHROPIC_* 的最小配置Claude Code 的配置可以落在settings.json里也可以由 shell 环境变量提供。为了让评测脚本可复制建议把 Base URL、认证 Token、默认模型写进项目级或用户级settings.json。下面是一个最小示例把ANTHROPIC_BASE_URL指向 TaoToken APIKey 用占位符{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-sonnet-4-20250514, ANTHROPIC_SMALL_FAST_MODEL: claude-3-5-haiku-20241022 } }如果你不想把 Key 写进文件可以在 shell 里导出export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKENYOUR_API_KEY export ANTHROPIC_MODELclaude-sonnet-4-20250514然后在 Claude Code 启动前确认环境变量已经生效env | grep -E ANTHROPIC_(BASE_URL|AUTH_TOKEN|MODEL)这里的关键点是Claude Code 使用ANTHROPIC_*变量Codex 不要复用这一套。很多评测脚本为了让两个客户端都能跑直接把ANTHROPIC_BASE_URL写进 Codex 配置结果 Codex 读取的是自己的 provider 字段最终仍然走默认端点token 统计也就丢了。正确做法是分别配置分别记录。在 Agent 评测里Claude Code 常被用来做代码修复、命令执行、文件编辑类任务。这类任务的 token 消耗不仅来自对话还来自工具调用前后的上下文注入。建议在每轮任务结束后把 Claude Code 的会话日志导出为 JSONL至少包含{ strategy: reflexion_4, task_id: repo_fix_001, model: claude-sonnet-4-20250514, prompt_tokens: 0, completion_tokens: 0, total_tokens: 0, retry: 0, success: true }实际数值由你的调用返回填充。不要手工估算后面 Bradley-Terry 聚合和 Elo-per-token 计算都依赖这些字段。4. Codexconfig.toml 独立配置不要混用 ANTHROPIC_*Codex 的配置应落在config.toml。它和 Claude Code 的配置体系不同不要把ANTHROPIC_*套到 Codex 上。下面是一个面向 TaoToken Base URL 的 provider 配置示例Key 通过独立环境变量传入model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [model_providers.taotoken.http_headers] X-API-Key YOUR_API_KEY在 shell 中设置export TAOTOKEN_API_KEYYOUR_API_KEY如果你的 Codex 版本要求使用Authorization头也可以在本地配置里改成对应字段但核心原则不变Base URL 指向https://taotoken.net/apiKey 使用你在 TaoToken 控制台创建的值配置变量名与 Claude Code 保持隔离。在 Agent 评测中Codex 常被用于多步代码生成、补丁应用、测试修复等任务。它的 token 消耗特点是输入上下文可能很长输出相对短但工具调用结果会反复拼进下一轮上下文。为了做 Elo-per-token你需要在日志里区分首次请求的 prompt_tokens每一轮工具调用后追加的 prompt_tokens最终 completion_tokens失败重试产生的额外 token是否命中缓存。如果 Codex 客户端不直接暴露这些字段可以在外层包一层代理脚本把所有请求和响应写入本地 JSONL。代理只做记录不修改请求内容。这样 Aggregator 拿到的就是原始 token 账本。5. Token 统计命令把输入、输出、缓存与总消耗逐次落盘下面给出一个本地可执行的 curl 示例用于验证 TaoToken API 是否连通并打印 usage 字段。请把YOUR_API_KEY替换为真实 Key把your-model-id替换为你实际要评测的模型 ID。export TAOTOKEN_API_KEYYOUR_API_KEY curl -sS https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer ${TAOTOKEN_API_KEY} \ -H Content-Type: application/json \ -d { model: your-model-id, messages: [ {role: system, content: You are an agent.}, {role: user, content: Return a short JSON object.} ], stream: false } | jq { model: .model, prompt_tokens: .usage.prompt_tokens, completion_tokens: .usage.completion_tokens, total_tokens: .usage.total_tokens }如果返回结构里包含缓存字段也一并记录curl -sS https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer ${TAOTOKEN_API_KEY} \ -H Content-Type: application/json \ -d { model: your-model-id, messages: [{role: user, content: ping}], stream: false } | jq .usage对于批量评测不建议每次手工看输出。更稳的方式是写一个包装脚本把每次调用的 strategy、task_id、model、usage、latency、retry 写入agent_runs.jsonl#!/usr/bin/env bash set -euo pipefail STRATEGY${1:-single} TASK_ID${2:-task_001} MODEL${3:-your-model-id} OUT_FILE${OUT_FILE:-agent_runs.jsonl} response$(curl -sS https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer ${TAOTOKEN_API_KEY} \ -H Content-Type: application/json \ -d { \model\: \${MODEL}\, \messages\: [{\role\: \user\, \content\: \Solve task ${TASK_ID}\}], \stream\: false }) echo $response | jq -c \ --arg strategy $STRATEGY \ --arg task_id $TASK_ID \ { strategy: $strategy, task_id: $task_id, model: .model, prompt_tokens: .usage.prompt_tokens, completion_tokens: .usage.completion_tokens, total_tokens: .usage.total_tokens, created: .created } $OUT_FILE执行方式chmod x record_agent_run.sh ./record_agent_run.sh single task_001 your-model-id ./record_agent_run.sh self_consistency_4 task_001 your-model-id ./record_agent_run.sh reflexion_4 task_001 your-model-id这样你得到的是原始 JSONL 账本。后续按strategy分组求和就能得到每个算力策略的总 token 消耗。注意命令中的 Base URL 是https://taotoken.net/api/v1/chat/completions不要在 Base URL 里加 UTM 参数UTM 仅用于官网入口和控制台跳转。6. Bradley-Terry 聚合从任务内排序到跨任务 Elo 的可运行脚本有了 token 账本下一步是把每个任务内的多次运行结果转成排序。比如同一道题跑 4 次策略 A 赢 3 次、策略 B 赢 1 次就可以构造胜负矩阵。Bradley-Terry 模型可以把这种任务内 pairwise 比较聚合成全局能力参数再线性映射到 Elo 分。下面是一个可运行的 Python 示例使用numpy和scipy。矩阵W[i, j]表示策略 i 击败策略 j 的次数。实际使用时把示例矩阵替换为你的胜负统计。import numpy as np from scipy.optimize import minimize def fit_bradley_terry(win_matrix, base_elo1000.0, scale400.0): win_matrix[i, j] 策略 i 击败策略 j 的次数 返回每个策略的 Elo 分 win_matrix np.asarray(win_matrix, dtypefloat) n win_matrix.shape[0] def negative_log_likelihood(theta): # 固定尺度避免参数漂移 theta np.exp(theta - np.max(theta)) loss 0.0 for i in range(n): for j in range(n): wins win_matrix[i, j] if wins 0: p theta[i] / (theta[i] theta[j]) loss - wins * np.log(p 1e-12) return loss result minimize( negative_log_likelihood, np.zeros(n), methodBFGS, options{maxiter: 2000} ) if not result.success: raise RuntimeError(fBradley-Terry 拟合失败: {result.message}) elo base_elo scale * result.x / np.log(10.0) return elo # 示例4 个策略在多个任务上的累计胜负 # 行胜者列败者 W np.array([ [0, 5, 3, 1], [1, 0, 4, 2], [2, 1, 0, 3], [4, 3, 2, 0], ], dtypefloat) strategy_names [single, sample_2, sample_4, reflexion_4] scores fit_bradley_terry(W) for name, score in zip(strategy_names, scores): print(f{name:14s} Elo{score:8.2f})这个脚本只做一件事把任务内排序聚合为跨任务 Elo。它不依赖任何远端服务矩阵由你本地日志生成。要生成W你需要先定义“谁赢”可以是任务成功率可以是裁判模型打分也可以是测试通过率。关键是同一任务内的比较要成对、可重复并且每个策略的 token 消耗单独记录。Bradley-Terry 的一个工程细节是不同任务的难度不同。如果你把所有任务的胜负直接混在一起高难度任务可能淹没低难度任务。更稳的做法是分层聚合先在任务内得到 pairwise 胜负再按任务维度加权汇总。权重可以用任务重要性、样本量或 token 成本。Elo-per-token 关心的是“每单位 token 带来的 Elo 变化”所以权重里不要直接把 token 放进去否则会循环解释。7. Elo 评分与收益递减对照表用 token 维度做决策把 Elo 和 token 放在一起后你会得到类似下面的对照表。注意下表是复现实验模板不是某个固定论文的数值。你需要用自己的agent_runs.jsonl和 Bradley-Terry 输出填充。表格的价值在于强制你把“策略更强”翻译成“边际 Elo / 1K Token 是多少”。策略档位单任务额外采样/反思轮数总 Token 消耗以日志为准跨任务 Elo边际 Elo / 1K Token决策建议single0基线基线基线先建立基线不要跳过sample_22约 2x待实测待计算若边际值高于阈值可保留sample_44约 4x待实测待计算观察是否开始递减reflexion_44约 4x待实测待计算反思轮数增加时重点看 tokensample_8 rerank8约 8x待实测待计算若边际值接近 0应停用sample_16 rerank16约 16x待实测待计算除非评测目标极高否则不划算计算边际 Elo / 1K Token 的公式可以写成边际 Elo / 1K Token (Elo_strategy - Elo_baseline) / ((TotalTokens_strategy - TotalTokens_baseline) / 1000)如果策略 B 相比策略 A 的 Elo 只提升了很小一截但 token 翻了数倍那么这条策略在成本侧就不适合默认开启。收益递减通常出现在两个位置一是并行采样数继续增加但投票结果已经趋同二是反思轮数继续增加但模型开始重复之前的错误只是把上下文拉得更长。工程上可以设三个阈值边际 Elo 下限低于该值不进入默认配置只保留实验开关。总 token 上限单任务超过预算直接截断避免长尾任务拖垮整轮评测。收益递减告警当连续两档策略的边际 Elo / 1K Token 下降超过设定比例时触发告警而非自动扩容。这三个阈值不需要一次定准可以在小样本评测里先跑 20 到 50 个任务得到初步曲线再扩展到全量。关键是每次实验都保留原始 JSONL不要只存汇总值。8. 自动化门禁把 Elo-per-token 阈值写进 CI当你已经能稳定产出agent_runs.jsonl和 Elo 表后下一步是把 Elo-per-token 做成 CI 门禁。比如每次修改 Agent 的采样策略、提示词或工具调用逻辑时自动跑一轮小规模评测如果边际 Elo / 1K Token 低于阈值就让流水线失败或给出警告。下面是一个本地 CI 脚本示例读取 JSONL、按策略汇总 token再调用 Elo 脚本输出对比结果。实际使用时把eval_elo_per_token.py替换为你自己的聚合脚本。#!/usr/bin/env bash set -euo pipefail LOG_FILE${LOG_FILE:-agent_runs.jsonl} MIN_MARGINAL_ELO${MIN_MARGINAL_ELO:-0.8} if [ ! -f $LOG_FILE ]; then echo 缺少日志文件: $LOG_FILE exit 1 fi python3 - PY import json from collections import defaultdict log_file agent_runs.jsonl totals defaultdict(lambda: {tokens: 0, runs: 0}) with open(log_file, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue row json.loads(line) strategy row.get(strategy, unknown) totals[strategy][tokens] int(row.get(total_tokens, 0)) totals[strategy][runs] 1 for strategy, item in sorted(totals.items()): runs max(item[runs], 1) print(f{strategy:18s} runs{runs:4d} total_tokens{item[tokens]:10d} avg_tokens{item[tokens]/runs:10.2f}) PY python3 eval_elo_per_token.py \ --log $LOG_FILE \ --baseline single \ --min-marginal-elo $MIN_MARGINAL_ELO这个门禁的意义不是阻止所有高消耗策略而是让“加算力”变成显式决策。默认配置应该只保留边际收益为正且稳定的策略高算力策略放在实验分支或手动触发。对于 LLM Agent 评测来说最贵的情况不是单次调用贵而是你不知道为什么贵。Elo-per-token 就是把这个问题变成可计算的指标。在接入层面CI 里的调用仍然建议走统一入口。你可以再次从 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentelo_per_token_ci 获取 Key并把 CI runner 的环境变量设为export TAOTOKEN_API_KEYYOUR_API_KEY export TAOTOKEN_BASE_URLhttps://taotoken.net/api不要在 CI 日志里打印完整 Key也不要把它写进可提交的配置文件。用 CI secret 注入脚本里只引用变量。9. 从模型对话到 Claude Code 文档把评测链路跑通如果你还没有开始第一轮评测建议按下面顺序把链路串起来先用模型对话验证 TaoToken API 是否可达确认https://taotoken.net/api能正常返回 usage 字段。再决定是否需要 Coding Plan尤其是你准备用 Claude Code、Codex 做多轮代码 Agent 评测时。然后创建独立 API Key按策略或按 runner 区分。最后对照 Claude Code 文档完成settings.json和ANTHROPIC_*配置并把评测日志接入 Bradley-Terry 脚本。对应入口如下模型对话https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentelo_per_token_ctaCoding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentelo_per_token_cta创建 Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentelo_per_token_ctaClaude Code 文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentelo_per_token_cta回到 Elo-per-token 本身最值得坚持的习惯是每次实验都同时保存三样东西——任务内排序、每次调用的 token usage、策略配置。排序用来做 Bradley-Terry 聚合token usage 用来算 Elo-per-token策略配置用来解释为什么某一档算力开始收益递减。只要这三样都在你就能把“某个 Agent 策略更强”变成“它在每千 token 上多得了多少 Elo”再据此决定是否继续加采样、加反思、加投票。对于推理成本工程师来说这比单纯追一个更高的 Elo 分数更有决策价值。
