复现微软那篇工具接口论文时最先炸的不是 harness 逻辑而是凭据Bash 组读OPENAI_API_KEYOPENAI_BASE_URL类型化接口组读ANTHROPIC_AUTH_TOKENANTHROPIC_BASE_URL切一次接口就 401 一次。为了把 TheAgentCompany 和 APEX-Agents 两个环境、Opus-4.8 与 GPT-5.5 两个模型族、Bash 与 typed 两种接口的 2×2×2 矩阵跑完我把所有模型出口统一收敛到 TaoToken官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbash2typed_leadBase URL 固定写成https://taotoken.net/api。下面这篇不是论文解读而是一份复现者的工程笔记怎么拿 Key、怎么把 Claude Code 和 Codex 的配置改对、怎么用一个切换脚本让两种接口共用同一套凭据以及最关键的——怎么把两类接口下的 Token 消耗记成能对照的表。1. 先搞清楚论文在比什么Bash 接口与类型化接口的成本结构完全不同论文的结论方向是在企业级 Agent 任务上让模型直接调用 Bash 的接口形态表现优于把每个能力封装成带 schema 的类型化工具接口。这个结论容易引发误读所以复现前必须先把接口这个词拆开。Bash 接口的本质是给模型一个受限但通用的 shell 通道工具集被压缩成一份命令说明 少量帮助文本。模型输出的是命令行字符串执行结果以 stdout/stderr 文本回到上下文。它的上下文占用是说明文档 实际输出不随工具数量线性增长。类型化接口的本质是每个工具都有名称、描述、JSON Schema 参数。模型通过结构化的 function call 触发。它的优势是参数校验严格、调用意图明确代价是工具定义本身要进上下文工具一多schema 就变成固定的 prompt 开销而且每次请求通常都要重复携带。复现时关注的不是谁得分高而是谁的 Token 花在哪里。这两类接口的消耗曲线形状不一样Bash 的输入 Token 相对平稳但命令写错、路径不存在、权限不足会触发重试输出 Token 和轮次会被推高。typed 的输入 Token 起点更高schema 常驻但单次调用成功率高轮次可能更少。论文在 TheAgentCompany 这类仿真企业环境里任务往往需要跨多个子系统操作Bash 的组合能力会被放大而 typed 接口在任务边界清晰时更稳。这就是为什么同一份 harness 必须支持两种模式并记录同样的字段否则你只会得到哪个跑分高得不到哪个更省。2. 拿到 Key 并固定 Base URL复现的第一步是消除凭据变量在论文复现里最不该出现的就是凭据不一致导致的失败。所以第一步不是改 harness而是把所有模型访问收敛到一个出口。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentbash2typed_key 在控制台里创建 API Key然后把 Key 放进环境变量不要写进任何会被提交的脚本文件。约定一个统一变量名比如TAOTOKEN_API_KEY后续两个模型族都从它派生。# 写入当前 shell不要写进仓库里的 .env 后 commit export TAOTOKEN_API_KEYYOUR_API_KEY # OpenAI 兼容侧Bash harness 常用 export OPENAI_API_KEY$TAOTOKEN_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api # Anthropic 兼容侧Claude 系 harness 常用 export ANTHROPIC_AUTH_TOKEN$TAOTOKEN_API_KEY export ANTHROPIC_BASE_URLhttps://taotoken.net/api注意这里有两个容易踩的点第一ANTHROPIC_API_KEY和ANTHROPIC_AUTH_TOKEN在部分客户端里优先级不同同时设置可能互相覆盖只保留一个。第二Base URL 必须是https://taotoken.net/api不要自己补/v1或去掉路径段客户端通常会在其之上拼接具体端点。先做一次最小连通性验证再动 harness# OpenAI 兼容端点探活 curl -sS https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d {model:gpt-5.5,messages:[{role:user,content:ping}],max_tokens:16}# Anthropic 兼容端点探活 curl -sS https://taotoken.net/api/v1/messages \ -H x-api-key: $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -H Content-Type: application/json \ -d {model:claude-opus-4-8,max_tokens:16,messages:[{role:user,content:ping}]}两条命令都返回正常结构说明 Key 与 Base URL 这一层已经稳定。具体可用的模型 ID 以控制台模型列表为准论文里用的 Opus-4.8、GPT-5.5 只要在列表里能选到就可以作为复现的两条主线。这一步做完后面所有失败都可以归因到 harness而不是凭据。3. Claude Code 侧settings.json 里的 ANTHROPIC_* 三件套复现 Agent 任务时很多人会用 Claude Code 作为交互式调试入口先在真实目录里手动跑一遍任务再把它固化成 harness 用例。Claude Code 的配置走settings.json不是config.toml两者不能混。推荐用环境变量块的方式写在项目级或用户级配置里{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: claude-opus-4-8, ANTHROPIC_SMALL_FAST_MODEL: claude-haiku-latest } }放置位置建议用户级~/.claude/settings.json适合放 Base URL 和 Key 这类全局信息。项目级repo/.claude/settings.json适合放模型名、权限白名单这类随仓库走的信息。项目级会覆盖用户级里同名的键所以不要把 Key 写在项目级文件里再提交。更稳的做法是ANTHROPIC_AUTH_TOKEN不写进任何文件只在启动 shell 时 exportsettings.json里只保留ANTHROPIC_BASE_URL和模型名。启动前做一次自检确认 Claude Code 实际读到的出口是自己期望的那个env | grep -E ^ANTHROPIC_ | sed s/\(TOKEN\).*/\1***/如果输出里同时出现ANTHROPIC_API_KEY和ANTHROPIC_AUTH_TOKEN先unset ANTHROPIC_API_KEY再启动。这个细节在复现论文两类接口时特别重要typed 接口 harness 往往自己会注入一份凭据如果外部环境里残留了另一份就会出现同一个任务两次跑出不同模型的诡异现象Token 对照表直接失真。4. Codex 侧config.toml 用 model_provider别把 ANTHROPIC_* 套过来这是我看过最多的配置错误把 Claude Code 的三件套原样复制到 Codex 上然后疑惑为什么连不上。Codex 走的是config.toml provider 机制凭据通过env_key间接引用环境变量完全不需要ANTHROPIC_*系列。一个可用的最小配置model gpt-5.5 model_provider taotoken model_reasoning_effort medium [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat对应地shell 里只需要保证TAOTOKEN_API_KEY存在。wire_api的取值要与所选模型和端点协议匹配切换模型时如果报协议不兼容先检查这一项而不是去改 Base URL。如果你同时用 Claude Code 和 Codex 做交叉验证建议引入 CC Switch 这类切换器来管理三件套避免手工改文件改漏。它需要维护的核心就是三个字段字段Claude Code 侧Codex 侧说明出口地址ANTHROPIC_BASE_URLbase_url统一填https://taotoken.net/api凭据ANTHROPIC_AUTH_TOKENenv_key指向的变量都派生自同一个 Key模型ANTHROPIC_MODELmodel分别对应论文里的两条模型主线把这三件事固化成配置模板后切模型只是换一个 profile不会再出现改了 Claude Code 忘了改 Codex的情况。需要查 Claude Code 侧的完整接入说明时可以直接看官方文档https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentbash2typed_doc 。5. 接口切换脚本让 Bash harness 与 typed harness 共用一套凭据复现论文的核心工程产出是一个能按参数切换接口形态、并强制记录 Token 用量的启动脚本。目标很明确同一份任务清单分别以bash和typed两种模式跑输出格式完全一致的结果文件。#!/usr/bin/env bash set -euo pipefail : ${TAOTOKEN_API_KEY:?请先 export TAOTOKEN_API_KEY} # 统一出口 export OPENAI_API_KEY$TAOTOKEN_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKEN$TAOTOKEN_API_KEY export ANTHROPIC_BASE_URLhttps://taotoken.net/api unset ANTHROPIC_API_KEY || true IFACE_MODE${1:-bash} # bash | typed MODEL_ALIAS${2:-opus48} # opus48 | gpt55 ENV_NAME${3:-theagentcompany} case $MODEL_ALIAS in opus48) MODEL_IDclaude-opus-4-8 ;; gpt55) MODEL_IDgpt-5.5 ;; *) echo 未知模型别名: $MODEL_ALIAS 2; exit 2 ;; esac RUN_ID$(date %Y%m%d-%H%M%S)-${IFACE_MODE}-${MODEL_ALIAS} OUT_DIRruns/${RUN_ID} mkdir -p $OUT_DIR echo run_id${RUN_ID} | tee $OUT_DIR/meta.txt echo interface${IFACE_MODE} | tee -a $OUT_DIR/meta.txt echo model${MODEL_ID} | tee -a $OUT_DIR/meta.txt echo env${ENV_NAME} | tee -a $OUT_DIR/meta.txt echo base_url${OPENAI_BASE_URL} | tee -a $OUT_DIR/meta.txt # 具体 harness 入口按你自己的仓库替换 python -m harness.run \ --interface $IFACE_MODE \ --model $MODEL_ID \ --env $ENV_NAME \ --tasks tasks/${ENV_NAME}.jsonl \ --max-turns 40 \ --timeout-sec 600 \ --out $OUT_DIR/trajectory.jsonl \ 21 | tee -a $OUT_DIR/run.log脚本里有几个刻意的设计一个是unset ANTHROPIC_API_KEY。这不是洁癖而是为了消除上一节说的双凭据干扰。一个是RUN_ID里带上了接口模式和模型别名后面做对照表时可以纯靠目录名聚合不需要人工标注。另一个是--max-turns和--timeout-sec必须显式给死。Bash 模式在命令失败时容易陷入重试—失败—换个写法再试的循环如果不设上限单条任务的 Token 消耗会发散跨组对照就没有意义。6. 把 Token 消耗记成可对照的表字段设计与采集方式论文比较两种接口最有价值的复现产出不是总分而是同等任务完成度下的 Token 结构。所以采集字段要围绕这一点设计。按任务粒度记录一行至少包含run_id,interface,model,env,task_id,status,turns,prompt_tokens,completion_tokens,total_tokens,tool_calls,failed_calls,wall_time_sec其中prompt_tokens/completion_tokens从每次模型响应的 usage 字段累加不要用日志字符数估算。turns是模型调用次数不是工具调用次数两者在 Bash 模式下差异很大。failed_calls记录非零退出码、参数校验失败、超时三类它直接解释 Bash 模式的额外开销。status区分success/partial/fail否则省 Token可能只是没做完。采集侧建议在 harness 的模型客户端包一层把每次响应的 usage 原样落到 jsonl再由后处理脚本聚合。用jq做一次快速校验jq -r [.usage.prompt_tokens, .usage.completion_tokens] | tsv \ runs/${RUN_ID}/trajectory.jsonl | awk {i$1; o$2} END {print ini, outo}跑完四组两种接口 × 两个模型后把结果整理成一张对照表接口形态模型任务完成率平均轮次平均输入 Token平均输出 Token失败调用占比BashOpus-4.8待填待填待填待填待填typedOpus-4.8待填待填待填待填待填BashGPT-5.5待填待填待填待填待填typedGPT-5.5待填待填待填待填待填表格本身不承载结论它的作用是把论文说了什么变成我这边测出来什么。表里最值得盯的两列是平均输入 Token和失败调用占比如果 typed 的输入明显更高而完成率没有同步提升说明 schema 常驻成本没有被工具调用的收益覆盖如果 Bash 的输出明显更高说明重试循环才是主要开销来源优化方向应该是改进命令说明和错误回传而不是加工具。7. 复现过程中最容易让结果失真的六个坑第一模型名写成别名。opus和claude-opus-4-8在部分客户端里会被解析成不同模型两个接口组就可能跑在能力不同的模型上。模型 ID 要在启动脚本里硬校验。第二两套 harness 各自读取不同的超时参数。Bash 组的默认超时往往更短导致失败更多但那是配置差异不是接口差异。第三缓存干扰。同一任务连续跑两次第二次的输入 Token 可能因为服务端缓存而下降。对照实验要么打乱组间顺序要么用不同任务批次。第四把工具定义的开销算到模型头上又算到 harness 头上重复计数。typed 接口的 schema 是在请求里发送的它体现在prompt_tokens里不要在脚本里再单独统计一遍。第五只统计成功任务的 Token。这会造成失败越多看起来越省的反向偏差正确做法是失败任务的消耗也计入只是单独一行标注状态。第六凭据混用。前面反复强调的ANTHROPIC_API_KEY残留问题一旦发生整批数据的模型归属都不可信。把这些坑堵住之后你会发现复现的价值不在于验证Bash 是否更强而在于你能画出两条成本曲线一条是工具数量增加时 typed 接口的固定开销增长另一条是 Bash 接口随任务复杂度上升的重试开销增长。这两条线的交叉点才是工程上真正要回答的问题——你的 Agent 在这个任务分布上该用哪种接口。8. 小结与下一步把凭据层和应用层彻底解耦这次复现给我最大的工程启示不是接口之争而是分层凭据与出口地址必须是一个可以被脚本一键固定的层否则任何 A/B 对照都会被环境噪声污染。把 Base URL 统一成https://taotoken.net/api、Key 统一从一个环境变量派生之后Claude Code、Codex 和自研 harness 三者才能真正共享同一套实验条件。建议的推进顺序是先用对话界面把几条典型任务手工跑通确认模型在两类接口提示下的行为差异再用 Coding Plan 把批量任务跑起来压一压并发和超时参数最后固化 Key 管理与脚本把对照表变成每次改动都能重跑的回归数据。相关入口整理如下模型对话先手动验证任务行为https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentbash2typed_chatCoding Plan用于批量跑接口对照实验https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentbash2typed_plan创建并管理 API Keyhttps://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentbash2typed_keysClaude Code 接入文档含 settings.json 完整字段https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentbash2typed_doc_end把接口切换脚本、Key 环境变量和结果对照表这三样东西沉淀下来论文里的结论对你就从读到的变成了测出来的而这两者之间的差距往往正是下一次优化的起点。