1. 从一次 elo_bt.py 的 401 说起
上周把测试时算力（test-time compute）的评估脚本接进 CI 做回归，文件叫elo_bt.py，干的活并不复杂：对同一批任务，用不同采样预算（n=1/4/8/16）跑同一个 Agent，把每个任务内的候选答案排序后喂给 Bradley-Terry 模型，聚合成跨任务 Elo 分。第一轮本机跑通，第二轮换到构建机直接吃了一个 401——日志里 base_url 还指着上一位同事本地起的代理端口，Key 也是他个人环境变量里的，换台机器就彻底失效。
排查时先把两件事拆开，避免互相甩锅：
- 凭据与出口层：Agent 只该关心「用哪个 Key、打哪个 base_url」。这部分到 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=key_setup 拿一个 Key，把客户端 base_url 指向
https://taotoken.net/api即可，一步到位； - 评测口径层：Elo-per-token 才真正回答「这套算力策略值不值」。它不随供应商切换而改变，换 Key 不该换结论。
换句话说，TaoToken 的 Key 在这条流水线里只承担一件事——「这次调用是谁发的」，而不是「这个模型值多少分」。新手常犯的错就是把这两件事揉在一起：一出 401 就去怀疑评测代码，一出分数波动就去怀疑供应商。把凭据配置钉死在版本化文件里、把评测逻辑单独版本管理，回归才有意义。下面把这两层彻底解耦，给出可复制的 Agent 调用配置、token 统计命令，以及一张 Elo 评分与收益递减的对照表。
2. Elo-per-token 的评测骨架：谁在排序，谁在聚合
2.1 为什么不能直接比平均分
一套测试时算力策略，比如「多采样取多数」「best-of-n 加验证器重排」「树搜索加剪枝」，单独看每个任务的准确率很难横向比：任务难度不同、打分尺度不同、采样次数带来的 token 开销也不同。更麻烦的是，「多花 8 倍 token 换来 3 个点的准确率」这种结论，在另一个任务集上可能完全反过来。
Elo-per-token 的思路是把「排序」和「成本」同时纳入一个可比尺度：
- 任务内排序：对同一个任务，把不同策略（或同一策略的不同采样预算）产出的答案放在一起，做成对比较，得到「谁更好」的局部顺序；
- Bradley-Terry 聚合：用 BT 模型把一堆成对比较拟合成每个策略的强度参数 θ；
- 跨任务合并：把每个任务拟合出的 θ 归一化后汇总，得到全局 Elo 分；
- 除以 token 成本：用
ΔElo / Δtoken刻画边际收益，观察它怎么随预算增长而衰减。
2.2 Bradley-Terry 的拟合公式
对两个策略 i 和 j，BT 模型假设：
P(i 击败 j) = exp(θ_i) / (exp(θ_i) + exp(θ_j))拟合成对比较数据通常用最大似然，加上 L2 正则防止某些策略全胜或全负导致 θ 发散：
import numpy as np from scipy.optimize import minimize def bt_fit(wins, n_models, l2=1e-3): """ wins: list[(i, j)] 表示 i 击败 j 的一次观测 n_models: 策略数量 返回: 长度 n_models 的 θ 数组，均值为 0 """ def neg_log_likelihood(theta): ll = 0.0 for i, j in wins: s = theta[i] - theta[j] # log sigmoid(s) ll += -np.logaddexp(0.0, -s) reg = l2 * np.sum(theta ** 2) return -ll + reg theta0 = np.zeros(n_models) res = minimize(neg_log_likelihood, theta0, method="L-BFGS-B") theta = res.x - res.x.mean() # 中心化，便于跨任务合并 return theta def theta_to_elo(theta, base=1000.0, scale=400.0 / np.log(10)): return base + scale * theta这段代码可以在本地直接跑，数据完全来自你自己的评测日志，不涉及任何在线服务。
2.3 跨任务合并的坑
跨任务合并时最容易踩的坑是「任务难度漂移」。同一个策略在 A 任务上 Elo=1150、在 B 任务上 Elo=1050，直接把 Elo 平均是错的，因为两个任务里的对手集合不一样。正确做法是先把每个任务内的 θ 中心化（均值归零），再按任务权重加权合并：
task_weights = {"math": 0.4, "code": 0.4, "tool_use": 0.2} theta_global = sum(task_weights[t] * theta_centered[t] for t in task_weights) elo_global = theta_to_elo(theta_global)中心化之后，跨任务 Elo 才具备「同尺度可加」的性质，也才能做下面这张收益递减表。
3. 把 TaoToken Key 接进 Agent 调用链：三套配置
评测脚本本身不关心 Key 从哪来，但它调的 Agent 需要一个稳定的出口。这里按三种常见客户端分别给配置，全部用YOUR_API_KEY占位，换成你在控制台生成的真实 Key 即可。生成入口统一在 TaoToken 官网（UTM 已带）：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=api_keys
3.1 Python Agent 调用片段（OpenAI 兼容）
import os from openai import OpenAI client = OpenAI( api_key=os.environ.get("TAOTOKEN_API_KEY", "YOUR_API_KEY"), base_url="https://taotoken.net/api", timeout=120.0, max_retries=3, ) def run_agent_step(messages, budget_n=1): """budget_n: 采样次数，直接对应测试时算力预算""" outputs = [] for _ in range(budget_n): resp = client.chat.completions.create( model="your-agent-model", messages=messages, temperature=0.7 if budget_n > 1 else 0.0, ) usage = resp.usage outputs.append({ "text": resp.choices[0].message.content, "in_tokens": usage.prompt_tokens, "out_tokens": usage.completion_tokens, }) return outputs注意base_url只写https://taotoken.net/api，不要带 UTM 参数——UTM 是给文档和落地页用的，接口路径上加查询串会让某些客户端把参数混进请求体。
3.2 Claude Code：settings.json
Claude Code 走 Anthropic 协议，配置文件放~/.claude/settings.json（项目级可放.claude/settings.json）：
{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_MODEL": "your-claude-model", "ANTHROPIC_SMALL_FAST_MODEL": "your-claude-haiku-model" } }三件套ANTHROPIC_BASE_URL/ANTHROPIC_AUTH_TOKEN/ANTHROPIC_MODEL缺一不可。只改 base_url 不改 model，Claude Code 会用默认模型名去请求，很可能撞上 404。
3.3 Codex：config.toml
Codex 用的是 TOML，不要套 Anthropic 那套变量名，否则它读不到：
model = "your-codex-model" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api/v1" env_key = "TAOTOKEN_API_KEY" wire_api = "chat"对应地，在 shell 里导出：
export TAOTOKEN_API_KEY="YOUR_API_KEY"3.4 CC Switch 三件套
CC Switch 这类切换工具，本质就是在多个配置档之间切同一组三件套。维护三个字段就够了：
| 字段 | 值 |
|---|---|
| BASE_URL | https://taotoken.net/api |
| API KEY | YOUR_API_KEY |
| MODEL | 具体的模型名 |
把这三项写成 profile，评测脚本启动前先按 profile 注入环境变量，就不会再出现「换台机器 base_url 还指着老端口」这类问题。
4. token 统计命令：从日志到每任务成本
Elo-per-token 的分母必须是自己实测的 token，不能靠估。最稳的做法是在 Agent 的每次调用日志里落一条 JSONL，字段至少包含task_id、strategy、budget_n、prompt_tokens、completion_tokens。
4.1 用 jq + awk 快速聚合
# 假设 agent_run.jsonl 每行形如： # {"task_id":"math-001","strategy":"best_of_n","budget_n":4, # "usage":{"prompt_tokens":900,"completion_tokens":380}} jq -r 'select(.usage != null) | [.task_id, .strategy, (.budget_n|tostring), (.usage.prompt_tokens|tostring), (.usage.completion_tokens|tostring)] | @tsv' agent_run.jsonl \ | awk -F'\t' ' { key = $2 in_tok[key] += $4 out_tok[key] += $5 n[key] += 1 } END { printf "%-14s %10s %10s %12s %8s\n", "strategy","in_tok","out_tok","total_tok","calls" for (k in in_tok) { total = in_tok[k] + out_tok[k] printf "%-14s %10d %10d %12d %8d\n", k, in_tok[k], out_tok[k], total, n[k] } }' \ | sort -k4 -n4.2 用 Python 做每任务归一化
import json, collections per_task = collections.defaultdict(lambda: collections.defaultdict(int)) with open("agent_run.jsonl", "r", encoding="utf-8") as f: for line in f: rec = json.loads(line) u = rec.get("usage") or {} if not u: continue k = (rec["task_id"], rec["strategy"]) per_task[k]["in"] += u.get("prompt_tokens", 0) per_task[k]["out"] += u.get("completion_tokens", 0) # 每个策略的「每任务平均 token」 agg = collections.defaultdict(lambda: [0, 0, 0]) for (task_id, strategy), v in per_task.items(): total = v["in"] + v["out"] agg[strategy][0] += total agg[strategy][1] += 1 for strategy, (total, tasks) in sorted(agg.items(), key=lambda x: x[1][0]): print(f"{strategy:14s} tasks={tasks:4d} " f"avg_tokens_per_task={total/tasks:9.1f}")跑完这一步，把avg_tokens_per_task填进下一节的表里，Elo-per-token 的分母就实锤了。
5. Elo 评分与收益递减对照表
下面这张表是结构示例（数值仅示意，跑你自己的任务集时请用第 4 节的统计结果替换）。它想表达的不是具体数字，而是边际 Elo 随 token 增长掉得多快这件事：
| 策略 | 采样/搜索预算 | 每任务 token（示意） | 跨任务 Elo（示意） | ΔElo | ΔElo / 千 token |
|---|---|---|---|---|---|
| greedy | n=1 | 1.2k | 1000 | — | — |
| best-of-4 | n=4 | 4.6k | 1078 | +78 | 22.9 |
| majority@8 | n=8 | 9.3k | 1121 | +43 | 9.2 |
| best-of-16 | n=16 | 18.7k | 1141 | +20 | 2.1 |
| tree-search d=3 | 约 40k | 41.0k | 1152 | +11 | 0.5 |
读表的三条经验：
- 甜点区通常在 4～8 倍预算。从 n=1 到 n=4，每千 token 还能换回 20 分以上；再往上加，边际掉到个位数、甚至 1 分以下；
- ΔElo 单调递减但不为零，说明算力策略确实有上限，只是接近上限的速度比很多人预期得快。做评测报告时，把「每千 token 的 ΔElo」单独列一列，比只报最终 Elo 更有决策价值；
- 跨任务 Elo 的方差要一起看。同一策略在 math 上可能吃到 60 分，在 tool_use 上只吃 10 分，加权前先看每个任务中心化 θ 的分布，避免被单一任务带偏。
把这张表和第 2 节的 BT 拟合脚本接起来，就是一条完整的、可复现的 Elo-per-token 流水线：Agent 调用 → JSONL 日志 → token 聚合 → 成对比较 → BT 拟合 → 跨任务合并 → 收益递减判断。
6. 常见报错与排查顺序
把踩过的坑按出现频率排一下：
- 401 / invalid api key：优先看客户端读的是哪个环境变量。Claude Code 读
ANTHROPIC_AUTH_TOKEN，Codex 读env_key里指定的名字，两边不通用的。Key 在 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=troubleshoot 生成后，先echo $TAOTOKEN_API_KEY确认注入成功； - 404 model not found：base_url 写错（多写或少写
/v1），或者 model 名没换。Anthropic 系客户端 base_url 一般到/api，OpenAI 兼容系常需要/api/v1，按客户端文档确认； - 连接超时：
timeout设太短。跑 n=16 的多采样，单次请求可能叠加排队，建议客户端 timeout 加到 120s 以上，同时在 CI 里加 retry； - token 计数对不上：
prompt_tokens一般包含系统提示和工具定义，以为「只统计对话内容」会低估。评测里统计分母要按返回的 usage 原样相加，别自己重算； - Elo 不收敛：某个策略全胜或全负，θ 会发散。加 L2 正则，或者对全胜策略先做一次平滑处理。
排查时永远先分清是「凭据/出口」问题还是「评测策略」问题。前者改动配置就能解决，后者要回到数据本身，两者混在一起查最耗时间。
7. 收尾：凭据归凭据，算力归算力
回到开头那个 401。真正解决它的不是改评测脚本，而是把 base_url 和 Key 从「某台机器上的个人环境变量」挪进了版本化配置：base_url 固定指向https://taotoken.net/api，Key 用占位符 + CI secret 注入，客户端只负责发请求。这样做完，脚本在任何机器上都跑得通，Elo-per-token 的结论也不会因为换了个出口就漂移。
如果你的团队也在做测试时算力策略的横向评测，建议按下面的顺序走一遍，全部是可跟做的动作：
- 先拿一个 Key：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=create_key
- 想先在对话里验证模型是否连通：https://taotoken.net/models/detail/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat
- 评测任务量大、想按套餐走：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan
- Claude Code 环境的完整配置说明：https://taotoken.net/doc/ClaudeCodeAnthropic?utm_source=taotoken_aicg_blog_end&utm_content=claude_code_doc
配置抄完、日志落完、BT 拟合跑完，你手里就有了一条能长期复用的 Elo-per-token 曲线。它不依赖某个具体供应商，也不会因为换 Key 就失效——凭据归凭据，算力归算力，评测结论才站得住。
