1. 在 Pi harness 里逐个换模型先把 Base URL 这件事定死在 Pi harness 里复现 7 个模型的编码表现最容易踩的坑不是模型本身而是供应商入口没对齐——同一个模型名走不同 Base URL拿到的可能是不同版本、不同上下文窗口、不同计费口径。我这次的做法是所有模型统一从 TaoToken 官网 申请一把 KeyBase URL 固定写https://taotoken.net/api然后只在 Pi 的模型字段上做替换harness 侧不做任何魔改。原始评测的场景是 Arena 实习生 melissapan 做的 7 模型 × 3 harnessClaude Code、Codex、Pi对照共 21 个模型-harness 组合。它给出的核心观察是换 harness 对成功率的扰动其实不大真正被拉开的是成本。这句话听着像结论其实是个提醒——如果你只盯着通过率挑 harness很可能白花掉一大截 Token如果你只盯着便宜挑 harness又可能把失败重试的成本算漏。所以本文不复述结论而是给一套能自己跑出来的东西Pi harness 的配置片段、21 组成功率表的记录模板、21 组成本表的计算口径以及 Claude Code / Codex 的对照配置。整条链路里去 TaoToken 官网 拿 Key 是第一步Key 占位符统一写YOUR_API_KEY。有一点先说清楚Pi 调用 7 个模型时消耗 Token 的是模型推理本身不是 harness。harness 只决定往上下文里塞了多少东西——系统提示、工具 schema、历史轮次、重试时的重复输入。这正好解释了为什么成功率差异小、成本差异大成功率取决于模型能力下限成本取决于 harness 的上下文胃口。2. 21 组对照表怎么设计把变量钉死在 harness 上复现评测最大的敌人是变量漂移。同一个任务第 1 组跑的时候你手动补了一句提示第 17 组忘了补那这 21 组数据就不能横向比。下面是我用的固定项。固定项全 21 组一致任务集同一批仓库级修改任务任务描述文本原文不动不做人工润色。判定方式任务自带的测试用例是否全绿全绿记 1否则记 0不做人工主观打分。重试次数失败后最多自动重试 1 次重试也算进成本但成功率只看首次结果。计时口径从提交任务到 harness 返回终态超时按失败计。供应商全部走https://taotoken.net/api只用一把 Key避免不同 Key 的配额/限流差异污染成本数据。变化项3 个 harness × 7 个模型 21 组7 个模型建议按你账号里实际可见的清单替换本次复现用的是这一类组合主力推理模型 2 个、快速小模型 2 个、代码特化模型 2 个、长上下文模型 1 个。不要为了凑数把同一模型的两种别名算成两个模型那样 21 组会虚高。成功率表按 harness 分三张每张 7 行| 模型 | 任务数 | 首次通过 | 成功率 | 重试后通过 | 平均耗时(s) | |------|-------|---------|--------|-----------|------------| | 模型A | 20 | __ | __% | __ | __ | | 模型B | 20 | __ | __% | __ | __ | | 模型C | 20 | __ | __% | __ | __ | | 模型D | 20 | __ | __% | __ | __ | | 模型E | 20 | __ | __% | __ | __ | | 模型F | 20 | __ | __% | __ | __ | | 模型G | 20 | __ | __% | __ | __ |三张表跑完你会得到一个 3×7 的矩阵。判断harness 影响成功率的方法是对同一个模型纵向比三个 harness 的成功率看波动是否落在任务噪声范围内。如果波动只有几个百分点而成本差出两三倍那结论就跟原评测一致。3. Pi 的 Base URL 指向 TaoToken配置片段与 Key 获取Pi harness 的 provider 配置不同版本字段名会有差异但有两个锚点是不会变的baseURL和apiKey。把这两个对齐剩下的模型字段就是纯替换。先拿 Key打开 TaoToken 官网注册后在控制台创建一把 Key复制出来只显示一次记得存好。配置片段按你本地 Pi 版本的 schema 对齐字段名锚点字段保持不变{ provider: { type: openai-compatible, baseURL: https://taotoken.net/api, apiKey: YOUR_API_KEY, timeout: 300 }, models: [ { id: MODEL_A, alias: a }, { id: MODEL_B, alias: b }, { id: MODEL_C, alias: c }, { id: MODEL_D, alias: d }, { id: MODEL_E, alias: e }, { id: MODEL_F, alias: f }, { id: MODEL_G, alias: g } ] }切模型时只动models里当前生效的那一项provider 块完全不动。这样 21 组跑下来环境差异只剩模型本身。配置写完先做一次连通性验证别急着开跑curl -sS https://taotoken.net/api/v1/models \ -H Authorization: Bearer YOUR_API_KEY \ -o /tmp/models.json -w %{http_code}\n # 200 说明 Key 和 Base URL 都对上了401 查 Key404 查路径拼接 head -c 300 /tmp/models.json如果客户端会自动在 Base URL 后面拼/v1那baseURL就保持https://taotoken.net/api不动如果客户端要求你显式写全再按它的规则补。这两个情况在排障时经常被混为一谈——明明 Key 没问题却因为多写了一层/v1/v1报 404。4. Claude Code、Codex 与 CC Switch三套配置别串味同一批模型在 Claude Code 和 Codex 下的表现是这次 21 组里的另外两列。但配置写法完全不同绝对不能把ANTHROPIC_*系列变量塞进 Codex那是最常见的串味错误。Claude Codesettings.jsonANTHROPIC_*{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: MODEL_A, ANTHROPIC_SMALL_FAST_MODEL: MODEL_D } }ANTHROPIC_SMALL_FAST_MODEL影响的是后台小任务补全、摘要、标题生成走哪个模型。做成本对照时这一项必须固定否则小模型换一次成本曲线就整体平移跟 harness 的差异混在一起就分不出来了。Codexconfig.tomlmodel MODEL_A model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chatKey 通过环境变量注入不要硬编码进config.tomlexport TAOTOKEN_API_KEYYOUR_API_KEY # 验证变量已生效再启动 Codex [ -n $TAOTOKEN_API_KEY ] echo key ok || echo key missingCC Switch 三件套要在三个 harness 之间来回切靠手改配置文件迟早出错。我用一个最小的切换脚本管住三件事写入配置、激活配置、校验连通。#!/usr/bin/env bash set -euo pipefail TAOTOKEN_BASEhttps://taotoken.net/api KEY${TAOTOKEN_API_KEY:?请先 export TAOTOKEN_API_KEY} switch_claude() { cat ~/.claude/settings.json EOF { env: { ANTHROPIC_BASE_URL: ${TAOTOKEN_BASE}, ANTHROPIC_AUTH_TOKEN: ${KEY}, ANTHROPIC_MODEL: $1 } } EOF echo claude - $1 } switch_codex() { cat ~/.codex/config.toml EOF model $1 model_provider taotoken [model_providers.taotoken] name TaoToken base_url ${TAOTOKEN_BASE} env_key TAOTOKEN_API_KEY wire_api chat EOF echo codex - $1 } check() { code$(curl -sS ${TAOTOKEN_BASE}/v1/models \ -H Authorization: Bearer ${KEY} -o /dev/null -w %{http_code}) echo connectivity: ${code} } case ${1:-} in claude) switch_claude $2 ;; codex) switch_codex $2 ;; check) check ;; *) echo usage: $0 {claude|codex|check} model ;; esac每次切换后跑一次check确认返回 200 再开始任务。这一步能挡掉绝大多数看起来在跑其实没连上的假数据。5. 成功率怎么看才不被噪声骗成功率是离散指标样本量小的时候波动极大。20 个任务里通过 15 个和通过 16 个看起来差 5 个百分点实际上完全可能是随机波动。所以做 harness 对比时别用绝对值下判断用同一模型在三个 harness 之间的排序一致性。具体做法先看三张表里同一个模型的最强 harness 和最弱 harness 差多少。如果普遍在个位数百分点说明 harness 对成功率的影响确实弱。再看失败原因分布。harness 引起的失败通常长一个样工具调用参数格式不合法、上下文被截断导致读了半截文件、多轮重试后跑偏。模型能力引起的失败是另一副样子逻辑写错、边界条件漏掉、API 用错。把因为 token 超限被截断的任务单独标出来。这类失败如果一个 harness 明显更多那它不是成功率问题是上下文预算问题应该归到成本表里去讨论。记录时给每个失败任务打一个标签三种就够MODEL、HARNESS、BUDGET。21 组跑完统计标签分布比看成功率数字有用得多。6. 成本表怎么算Token 到底花在哪成本这块最省事的算法是直接用账单总额除以任务数但那样你没法解释为什么同模型跨 harness 会差出几倍。要做归因至少拆成三项输入 Token系统提示 工具 schema 历史轮次 文件内容。这部分随 harness 的设计变化最大。有的 harness 一上来就把工具定义全量塞进去有的按需注入有的每一轮都重发完整历史有的做摘要压缩。输出 Token模型生成的代码和解释。这部分主要由模型风格决定跨 harness 差异相对小。重试 Token失败后重跑带来的重复输入。成功率低的模型重试成本会放大——这也是为什么便宜模型 高重试有时反而比贵模型 一次过更贵。记录模板| harness | 模型 | 输入Token | 输出Token | 重试Token | 单任务成本 | 总成本 | |---------|------|----------|----------|----------|-----------|--------| | Pi | 模型A | __ | __ | __ | __ | __ | | Pi | 模型B | __ | __ | __ | __ | __ | | ClaudeCode | 模型A | __ | __ | __ | __ | __ | | Codex | 模型A | __ | __ | __ | __ | __ |注意一个口径问题如果你在 Pi 里跑模型时开了缓存输入 Token 的单价会和不缓存时不一样这时候要么全程统一开要么全程统一关不要中途改。中途改一次前面几组的数据就废了。巴菲特的搭档查理·芒格有句话常被引用反过来想总是反过来想。放到这里就是——别只算成功的成本把失败和重试的成本一起算进去账才算完整。7. 常见报错与快速定位跑 21 组报错一定会有。按出现频率从高到低401 / 403Key 没读到。先echo $TAOTOKEN_API_KEY确认变量在当前 shell 里再确认配置文件里没有把变量名拼错。Codex 用的是env_key指定的变量名不是直接把值写进去。404路径拼接问题。Base URL 是https://taotoken.net/api客户端如果自己拼/v1最终请求就是/api/v1/...如果你手写全路径又多写了一层就会变成/api/v1/v1/...。模型名不存在模型 ID 必须和 provider 返回的清单完全一致大小写、连字符、版本后缀都不能差。跑之前先拉一次 models 清单核对curl -sS https://taotoken.net/api/v1/models \ -H Authorization: Bearer YOUR_API_KEY \ | grep -o id:[^]* | head -50超时仓库级任务本来就慢默认超时太短会把正常任务判成失败污染成功率。统一把超时放到 300 秒以上并且三个 harness 用同一个值。上下文超限报错信息通常带 token 数。这类任务标成BUDGET标签不要算进模型能力对比。8. 结论与下一步把 21 组跑完之后大概率会落到和原评测一样的形状同一模型换 harness成功率变化有限但输入 Token 的差异会实打实体现在账单上。这意味着选 harness 的时候第一优先级是它的上下文管理策略第二才是工具调用的顺手程度。如果你也想自己复现这套对照路径是这样的先去 TaoToken 官网 建账号。如果想先在网页里确认目标模型是否可用、响应是否符合预期可以直接用模型对话试跑几个短任务确认没问题后看Coding Plan选适合跑批量任务的档位然后到API Keys创建 Key填进上面第 3 节的配置里如果你主用 Claude Code 做对照Claude Code 文档里把ANTHROPIC_*的字段说明列得很细照着填就行。最后提醒一句21 组数据是用来给你自己的仓库和任务集做决策的不是通用排名。任务集一换、仓库规模一换最优 harness 可能就变了。所以要保留的不是结论是这套记录模板和切换脚本——下次换个任务集重跑一遍就有新答案。