1. 为什么评测模型要先把环境“削”到只剩 shell 和 file_editTerminal Bench 是一套专门考察模型在终端环境里“动手能力”的基准测试集它不问你模型会不会聊天而是把模型丢进一个近乎裸机的终端只给它 shell 和文件编辑两个工具看它能不能读懂报错、定位问题、改对文件、跑通验证脚本。适合谁适合需要横向对比不同模型工具调用能力的评测者、做 Agent 研究的开发者以及想搞清楚“模型到底是真会干活还是靠环境兜底”的技术团队。我最初跑 Terminal Bench 的时候用的是 Harness 的标准模式结果跑出来的分数忽高忽低同一道题换个时间跑工具调用序列能差出三四步。后来才意识到问题不在模型而在环境标准模式里带了智能路由、自动重试、外部技能调用这些机制在真实产品里是加分项但在基准测试里全是噪声。你测的已经不是模型本身而是“模型 一整套工程兜底”的混合体。极简模式minimal mode就是为解决这个问题设计的。它只保留两个工具shell 和 file_edit。没有网络搜索没有多轮子 Agent 调度没有额外的上下文注入策略。模型拿到的就是原始系统提示词执行的就是基础文件操作。这种裁剪不是偷懒而是把变量控制到最少。同一道题跑十遍轨迹日志里的工具调用序列应该基本一致这对需要严格对照的评测场景至关重要。Terminal Bench 的题型大致分三类文件诊断类给定报错项目定位并修复、功能实现类从零创建文件、写代码、跑测试、环境配置类装依赖、调配置、验证服务。难度通过代码库规模、依赖复杂度、验证方式三个维度分层。初级题可能只改一个函数参数高级题要求理解整个项目构建流程甚至处理跨文件引用。这种设计覆盖了从“会写脚本”到“能维护项目”的能力光谱而不是所有题目挤在同一难度区间变成抽奖。和 SWE-bench 相比Terminal Bench 极简模式的环境假设更苛刻SWE-bench 给你完整开发环境含 Git 历史任务来自真实 GitHub Issue成功标准是测试用例通过且不破坏原有功能Terminal Bench 极简模式只给最小化终端题目是构造型的成功标准按题目要求的输出或状态判定模型可见信息仅当前终端输出与文件内容。SWE-bench 更像“招一个能干活的工程师”Terminal Bench 极简模式则是“测一个候选者的基本功”。前者模型可以依赖丰富环境信息和工具链后者把模型扔到近乎裸机的环境里看它用多快速度、多少试错次数完成任务。对于研究模型作为 Agent 的核心能力边界而非系统工程能力的场景Terminal Bench 的隔离性更有价值。但这里有个现实问题Harness 默认走的是官方 API endpoint国内开发者直接跑经常遇到网络抖动、超时、Key 管理分散的问题。一旦评测过程中 API 通道不稳定轨迹日志里就会出现大量重试和超时事件直接污染工具调用准确率和任务完成步数这两个核心指标。所以我在搭评测环境时第一步就是把 API endpoint 统一改到 TaoToken用一条 Key 通道管住所有模型的请求把网络变量从评测里剥离出去。2. TaoToken 接入前置把 API endpoint 统一到一条 Key 通道TaoToken 在这里的角色是统一 API 通道。你不需要为每个模型单独申请 Key、单独配 endpoint而是把所有请求指向同一个 Base URL用同一个 Key 管理。对 Terminal Bench 评测来说这解决了一个很实际的问题当你横向对比多个模型时如果每个模型走不同通道网络延迟、限流策略、超时行为都不一样跑出来的步数和 Token 消耗根本没法直接比。统一通道之后这些外部变量被拉到同一水平线上剩下的差异才更接近模型本身的能力差异。接入前你需要准备三样东西Base URL、API Key、Model ID。Base URL 用https://taotoken.net/api注意这个地址不带任何查询参数是纯 API 入口。API Key 在控制台的 API Keys 页面创建创建后只显示一次建议直接写进环境变量而不是硬编码到配置文件里。Model ID 取决于你要评测的模型比如deepseek-chat、claude-sonnet-4-20250514这类标识具体以模型对话页面或接入文档里列出的为准。我试过把 Key 直接写进 Harness 的配置文件结果有一次误提交到 Git 仓库虽然及时删了但还是很惊险。后来改成统一走环境变量配置文件里只引用变量名这样既安全又方便在不同机器上切换。你可以这样操作export TAOTOKEN_API_KEYsk-你的实际Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api然后在 Harness 的配置里引用这两个变量。Harness 的插件化架构允许纯配置切换模式不需要改源码。极简模式的启动命令是npx deepseek-ai/dsh web --mode minimal但这条命令默认走官方 endpoint你需要额外指定 API 配置。更稳妥的做法是先在项目目录下建一个配置文件把 endpoint、Key、Model ID 三件套写清楚再启动。这样每次跑评测不用重复输入参数也方便把配置快照存档半年后别人拿到你的配置能复现出一致结果。这里要提醒一点TaoToken 是统一 Key 通道不是让你绕过什么限制而是把多模型请求收敛到一条可管理的通道上。评测场景下通道稳定性直接决定轨迹日志的干净程度。如果通道本身抖动你会看到大量local proxy failed或超时重试事件混在轨迹里这些事件会让工具调用准确率这个指标失真——模型可能只是被网络拖慢却被记成“反复试错”。配置写完后建议先用一条最简单的请求验证通道是否通。不要一上来就跑完整测试集那样一旦配置有错你会在几十道题里反复看到同样的报错浪费时间。验证方法在下一节展开。3. 可复制配置Harness 极简模式 TaoToken 三件套这一节直接给可复制的配置片段。Harness 的配置支持 JSON 和 TOML 两种格式我用的是 JSON因为和后续轨迹日志的格式更一致。在你的评测工作目录下创建harness.config.json{ mode: minimal, api: { baseUrl: https://taotoken.net/api, apiKey: ${TAOTOKEN_API_KEY}, model: deepseek-chat, timeoutMs: 120000, maxRetries: 2 }, tools: { enabled: [shell, file_edit], shell: { timeoutMs: 30000, maxOutputBytes: 65536 }, file_edit: { maxFileSizeBytes: 1048576 } }, trajectory: { record: true, outputDir: ~/.dsh/trajectories, includeToolArgs: true, includeToolResults: true }, seed: 42, maxTurns: 50 }几个关键参数说明。mode设为minimal是核心它决定只加载 shell 和 file_edit 两个工具。api.baseUrl指向 TaoToken 的 API 入口注意不要加尾部斜杠也不要带任何查询参数。api.apiKey用${TAOTOKEN_API_KEY}引用环境变量这样配置文件可以安全地提交到版本库。api.model填你要评测的 Model ID换模型时只改这一行。timeoutMs设 120 秒给模型足够的推理时间但不要设太大否则单题卡死会拖慢整个评测。maxRetries设 2极简模式下重试次数不宜多否则会掩盖模型本身的失败。tools段里显式列出enabled为[shell, file_edit]这是双保险即使mode配置被误改工具集也不会意外扩大。shell.timeoutMs设 30 秒防止某条命令挂死。maxOutputBytes限制终端输出大小避免模型被超长输出淹没。trajectory.record设为true是必须的没有轨迹日志就没法做可复现性分析。outputDir默认在~/.dsh/trajectories按时间戳命名。seed设固定值 42消除采样随机性。maxTurns设 50这是单题最大交互轮数上限防止模型暴力枚举。如果你更习惯 TOML等价配置如下mode minimal seed 42 maxTurns 50 [api] baseUrl https://taotoken.net/api apiKey ${TAOTOKEN_API_KEY} model deepseek-chat timeoutMs 120000 maxRetries 2 [tools] enabled [shell, file_edit] [tools.shell] timeoutMs 30000 maxOutputBytes 65536 [tools.file_edit] maxFileSizeBytes 1048576 [trajectory] record true outputDir ~/.dsh/trajectories includeToolArgs true includeToolResults true配置写好后启动命令带上配置文件路径npx deepseek-ai/dsh web --config ./harness.config.json如果你用的是 Claude Code 这类工具做辅助调试它的 settings 文件里也可以配同样的三件套。Claude Code 的配置文件通常在~/.claude/settings.json加上{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: ${TAOTOKEN_API_KEY}, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }注意 Claude Code 用的是ANTHROPIC_BASE_URL这个变量名和 Harness 的baseUrl不同但值都指向同一个 TaoToken API 入口。Model ID 换成你要用的 Claude 系列标识。这样你在调试评测脚本时Claude Code 和 Harness 走的是同一条 Key 通道不会出现“调试时通、评测时不通”的割裂。Cline 的 MCP 配置也是类似逻辑。在 Cline 的 MCP settings 里把 provider 的 base URL 指向 TaoTokenKey 用同一个环境变量Model ID 按需填。三件套Base URL Key Model ID在哪个工具里都是这三样只是变量名和文件路径不同。记住这个对应关系换工具时不会迷路。配置完成后先别急着跑完整测试集。下一节用一道最小题目验证整条链路是否通。4. 验证请求跑通一道最小题目并检查轨迹日志验证阶段的目标不是拿高分而是确认三件事API 通道通、极简模式生效、轨迹日志正常落盘。我建议用一道文件诊断类的简单题来验证因为这类题步骤少、验证快出问题时容易定位。先建评测工作目录和题目目录mkdir -p ~/terminal-bench-eval/problems/001 cd ~/terminal-bench-eval/problems/001一道标准题目包含三个部分task.md题目描述与成功标准、initial/初始文件状态、check.sh验证脚本。验证用的最小题目可以这样构造cat task.md EOF # 任务修复 Python 脚本中的类型错误 当前目录下有一个 calc.py运行时会抛出 TypeError。 请定位问题并修复使 python3 calc.py 能正常输出结果 42。 成功标准python3 calc.py 退出码为 0且输出包含 42。 EOF mkdir -p initial cat initial/calc.py EOF def add(a, b): return a b result add(40, 2) print(result) EOF cat check.sh EOF #!/bin/bash cd $(dirname $0) python3 calc.py /tmp/calc_out.txt 21 if [ $? -ne 0 ]; then echo FAIL: 脚本执行失败 cat /tmp/calc_out.txt exit 1 fi if grep -q 42 /tmp/calc_out.txt; then echo PASS exit 0 else echo FAIL: 输出不含 42 cat /tmp/calc_out.txt exit 1 fi EOF chmod x check.sh这道题的初始状态是calc.py里把字符串40和整数2相加会抛 TypeError。模型需要把40改成40或者做类型转换。验证脚本检查退出码和输出内容。现在把题目目录复制到 Harness 的工作区启动评测。Harness 的 Web UI 启动后在界面里选择极简模式确认 API 配置加载的是harness.config.json里的 TaoToken endpoint。提交任务后模型会通过 shell 读取calc.py用 file_edit 修改再跑python3 calc.py验证。跑完后检查轨迹日志ls -lt ~/.dsh/trajectories/ | head -5找到最新那个时间戳目录里面会有events.jsonl文件每行一个事件。用jq看工具调用序列cat ~/.dsh/trajectories/最新时间戳/events.jsonl | jq -r select(.typetool_call) | .tool (.args | tostring)正常输出应该类似shell {command: cat calc.py} file_edit {path: calc.py, old: add(\40\, 2), new: add(40, 2)} shell {command: python3 calc.py}如果看到shell和file_edit交替出现且没有web_search、sub_agent这类工具说明极简模式生效了。如果轨迹里出现大量重试事件或者工具调用之间间隔异常长检查 API 通道是否稳定。再确认 Token 消耗和步数cat ~/.dsh/trajectories/最新时间戳/summary.json | jq {turns, inputTokens, outputTokens, toolCalls}一道这样的简单题正常应该在 3 到 5 轮内完成工具调用 3 到 4 次Token 消耗在几百到一千多。如果步数超过 10 轮要么是模型理解有问题要么是通道超时导致重试。这时候先看轨迹里有没有timeout或local proxy failed事件有的话优先排查通道而不是急着换模型。验证通过后你就可以把测试集批量放进problems/目录用脚本循环跑。每道题跑完自动执行check.sh把结果汇总成表格。极简模式的可复现性优势在这里体现出来同一道题跑三遍工具调用序列基本一致通过率波动很小。如果某道题三次结果差异很大单独把三次轨迹拉出来对比看是模型采样不稳定还是题目边界条件设计有问题。5. 常见报错排查401、local proxy failed、reading choices、OAuth评测过程中最容易卡住的不是模型能力而是配置和通道问题。这一节按真实报错逐条排查。401 Unauthorized。这是最常见的问题九成是 Key 没传对。先确认环境变量是否真的导出echo $TAOTOKEN_API_KEY如果输出为空说明当前 shell 会话没加载。检查你是不是在~/.bashrc或~/.zshrc里写的 export但当前终端是另一个会话。临时解决直接export一次长期解决写进 shell 配置文件后source一下。如果变量有值但还是 401检查 Key 是否被复制时带了空格或换行用echo -n $TAOTOKEN_API_KEY | wc -c看字符数是否和预期一致。还有一种情况是配置文件里写了${TAOTOKEN_API_KEY}但 Harness 不解析环境变量这时候要么改成直接填值不推荐要么确认 Harness 版本支持变量插值。local proxy failed。这个报错通常出现在请求发出但连接没建立起来的时候。先确认 Base URL 写对了https://taotoken.net/api不要写成https://taotoken.net/api/尾部斜杠也不要带任何查询参数。然后确认本机网络能访问这个地址curl -sS -o /dev/null -w %{http_code}\n https://taotoken.net/api如果返回 401 或 404说明网络通只是没带认证或路径不对这是正常的。如果直接连接超时或 DNS 解析失败检查本机 DNS 和网络配置。注意不要用任何网络代理工具那会引入额外变量评测场景下通道必须干净。reading choices 报错。这个报错一般出现在模型返回格式不符合预期的时候。极简模式下模型应该返回工具调用或最终答案但如果模型返回了自然语言描述而没有实际调用工具Harness 解析时会报reading choices相关错误。排查方法看轨迹日志里模型返回的原始内容确认是不是模型没理解工具定义。如果是检查task.md的题目描述是否清晰成功标准是否明确。有时候题目描述太模糊模型会倾向于“解释”而不是“动手”。另一个可能是 Model ID 填错了导致请求发到了不支持工具调用的模型上。确认harness.config.json里的api.model是支持 function calling 的模型标识。OAuth 相关报错。如果你在 Claude Code 或类似工具里看到 OAuth 报错通常是因为工具默认走 OAuth 流程而不是 API Key。这时候需要在 settings 里显式配置ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY把认证方式从 OAuth 切到 API Key。Claude Code 的 settings.json 里加上前面那三件套后重启工具OAuth 报错应该消失。如果还报检查是不是有多个配置文件冲突比如项目级 settings 覆盖了用户级 settings。轨迹日志不落盘。跑完题目发现~/.dsh/trajectories/是空的。检查harness.config.json里trajectory.record是否为trueoutputDir路径是否存在且可写。如果路径用了~确认 Harness 是否展开波浪号有些版本不展开需要写绝对路径。另外如果题目在check.sh之前就失败了轨迹可能只记录了部分事件确认题目目录结构完整。工具调用被拒绝。极简模式只允许 shell 和 file_edit如果模型尝试调用其他工具会被 Harness 拒绝并记录。这本身不是 bug而是极简模式的预期行为。但如果你发现模型频繁尝试调用被禁用的工具说明系统提示词里可能残留了标准模式的工具描述。检查 Harness 版本和配置文件确认mode确实是minimal且没有其他配置覆盖它。排查顺序建议先看 401认证再看 local proxy failed通道再看 reading choices模型返回格式最后看 OAuth工具认证方式。大部分问题集中在前两类把 Key 和 Base URL 确认清楚能解决八成以上的报错。6. 把评测跑稳之后下一步做什么验证跑通、报错排查清楚之后你手里就有了一套可复现的 Terminal Bench 极简模式评测环境。接下来可以做的事把测试集按难度分层先跑初级题建立基线再逐步加高级题对同一模型跑三遍取平均记录通过率、平均步数、Token 消耗三个指标换不同 Model ID 做横向对比因为通道统一差异更接近模型本身能力。如果你要长期做模型评测或 Agent 开发建议把配置和轨迹日志纳入版本管理。harness.config.json提交到 Git轨迹日志压缩存档每次评测记录 Model ID、Harness 版本、测试集版本。这样半年后别人拿到你的配置能复现出一致结果。需要管理多个模型的 Key 和通道时可以在控制台创建不同的 API Key按项目或按模型分组避免一条 Key 到处用。跑评测的过程中如果遇到通道层面的问题优先看接入文档里的说明想先确认某个 Model ID 是否可用可以在模型对话页面直接发一条测试请求如果是长期编码或 Agent 场景需要更稳定的调用配额可以了解 Coding Plan 的配置方式。把通道这层管住评测的变量就只剩模型本身跑出来的数据才有对照价值。
极简模式跑 Terminal Bench：Harness 基准测试入门与 TaoToken 接入
1. 为什么评测模型要先把环境“削”到只剩 shell 和 file_editTerminal Bench 是一套专门考察模型在终端环境里“动手能力”的基准测试集它不问你模型会不会聊天而是把模型丢进一个近乎裸机的终端只给它 shell 和文件编辑两个工具看它能不能读懂报错、定位问题、改对文件、跑通验证脚本。适合谁适合需要横向对比不同模型工具调用能力的评测者、做 Agent 研究的开发者以及想搞清楚“模型到底是真会干活还是靠环境兜底”的技术团队。我最初跑 Terminal Bench 的时候用的是 Harness 的标准模式结果跑出来的分数忽高忽低同一道题换个时间跑工具调用序列能差出三四步。后来才意识到问题不在模型而在环境标准模式里带了智能路由、自动重试、外部技能调用这些机制在真实产品里是加分项但在基准测试里全是噪声。你测的已经不是模型本身而是“模型 一整套工程兜底”的混合体。极简模式minimal mode就是为解决这个问题设计的。它只保留两个工具shell 和 file_edit。没有网络搜索没有多轮子 Agent 调度没有额外的上下文注入策略。模型拿到的就是原始系统提示词执行的就是基础文件操作。这种裁剪不是偷懒而是把变量控制到最少。同一道题跑十遍轨迹日志里的工具调用序列应该基本一致这对需要严格对照的评测场景至关重要。Terminal Bench 的题型大致分三类文件诊断类给定报错项目定位并修复、功能实现类从零创建文件、写代码、跑测试、环境配置类装依赖、调配置、验证服务。难度通过代码库规模、依赖复杂度、验证方式三个维度分层。初级题可能只改一个函数参数高级题要求理解整个项目构建流程甚至处理跨文件引用。这种设计覆盖了从“会写脚本”到“能维护项目”的能力光谱而不是所有题目挤在同一难度区间变成抽奖。和 SWE-bench 相比Terminal Bench 极简模式的环境假设更苛刻SWE-bench 给你完整开发环境含 Git 历史任务来自真实 GitHub Issue成功标准是测试用例通过且不破坏原有功能Terminal Bench 极简模式只给最小化终端题目是构造型的成功标准按题目要求的输出或状态判定模型可见信息仅当前终端输出与文件内容。SWE-bench 更像“招一个能干活的工程师”Terminal Bench 极简模式则是“测一个候选者的基本功”。前者模型可以依赖丰富环境信息和工具链后者把模型扔到近乎裸机的环境里看它用多快速度、多少试错次数完成任务。对于研究模型作为 Agent 的核心能力边界而非系统工程能力的场景Terminal Bench 的隔离性更有价值。但这里有个现实问题Harness 默认走的是官方 API endpoint国内开发者直接跑经常遇到网络抖动、超时、Key 管理分散的问题。一旦评测过程中 API 通道不稳定轨迹日志里就会出现大量重试和超时事件直接污染工具调用准确率和任务完成步数这两个核心指标。所以我在搭评测环境时第一步就是把 API endpoint 统一改到 TaoToken用一条 Key 通道管住所有模型的请求把网络变量从评测里剥离出去。2. TaoToken 接入前置把 API endpoint 统一到一条 Key 通道TaoToken 在这里的角色是统一 API 通道。你不需要为每个模型单独申请 Key、单独配 endpoint而是把所有请求指向同一个 Base URL用同一个 Key 管理。对 Terminal Bench 评测来说这解决了一个很实际的问题当你横向对比多个模型时如果每个模型走不同通道网络延迟、限流策略、超时行为都不一样跑出来的步数和 Token 消耗根本没法直接比。统一通道之后这些外部变量被拉到同一水平线上剩下的差异才更接近模型本身的能力差异。接入前你需要准备三样东西Base URL、API Key、Model ID。Base URL 用https://taotoken.net/api注意这个地址不带任何查询参数是纯 API 入口。API Key 在控制台的 API Keys 页面创建创建后只显示一次建议直接写进环境变量而不是硬编码到配置文件里。Model ID 取决于你要评测的模型比如deepseek-chat、claude-sonnet-4-20250514这类标识具体以模型对话页面或接入文档里列出的为准。我试过把 Key 直接写进 Harness 的配置文件结果有一次误提交到 Git 仓库虽然及时删了但还是很惊险。后来改成统一走环境变量配置文件里只引用变量名这样既安全又方便在不同机器上切换。你可以这样操作export TAOTOKEN_API_KEYsk-你的实际Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api然后在 Harness 的配置里引用这两个变量。Harness 的插件化架构允许纯配置切换模式不需要改源码。极简模式的启动命令是npx deepseek-ai/dsh web --mode minimal但这条命令默认走官方 endpoint你需要额外指定 API 配置。更稳妥的做法是先在项目目录下建一个配置文件把 endpoint、Key、Model ID 三件套写清楚再启动。这样每次跑评测不用重复输入参数也方便把配置快照存档半年后别人拿到你的配置能复现出一致结果。这里要提醒一点TaoToken 是统一 Key 通道不是让你绕过什么限制而是把多模型请求收敛到一条可管理的通道上。评测场景下通道稳定性直接决定轨迹日志的干净程度。如果通道本身抖动你会看到大量local proxy failed或超时重试事件混在轨迹里这些事件会让工具调用准确率这个指标失真——模型可能只是被网络拖慢却被记成“反复试错”。配置写完后建议先用一条最简单的请求验证通道是否通。不要一上来就跑完整测试集那样一旦配置有错你会在几十道题里反复看到同样的报错浪费时间。验证方法在下一节展开。3. 可复制配置Harness 极简模式 TaoToken 三件套这一节直接给可复制的配置片段。Harness 的配置支持 JSON 和 TOML 两种格式我用的是 JSON因为和后续轨迹日志的格式更一致。在你的评测工作目录下创建harness.config.json{ mode: minimal, api: { baseUrl: https://taotoken.net/api, apiKey: ${TAOTOKEN_API_KEY}, model: deepseek-chat, timeoutMs: 120000, maxRetries: 2 }, tools: { enabled: [shell, file_edit], shell: { timeoutMs: 30000, maxOutputBytes: 65536 }, file_edit: { maxFileSizeBytes: 1048576 } }, trajectory: { record: true, outputDir: ~/.dsh/trajectories, includeToolArgs: true, includeToolResults: true }, seed: 42, maxTurns: 50 }几个关键参数说明。mode设为minimal是核心它决定只加载 shell 和 file_edit 两个工具。api.baseUrl指向 TaoToken 的 API 入口注意不要加尾部斜杠也不要带任何查询参数。api.apiKey用${TAOTOKEN_API_KEY}引用环境变量这样配置文件可以安全地提交到版本库。api.model填你要评测的 Model ID换模型时只改这一行。timeoutMs设 120 秒给模型足够的推理时间但不要设太大否则单题卡死会拖慢整个评测。maxRetries设 2极简模式下重试次数不宜多否则会掩盖模型本身的失败。tools段里显式列出enabled为[shell, file_edit]这是双保险即使mode配置被误改工具集也不会意外扩大。shell.timeoutMs设 30 秒防止某条命令挂死。maxOutputBytes限制终端输出大小避免模型被超长输出淹没。trajectory.record设为true是必须的没有轨迹日志就没法做可复现性分析。outputDir默认在~/.dsh/trajectories按时间戳命名。seed设固定值 42消除采样随机性。maxTurns设 50这是单题最大交互轮数上限防止模型暴力枚举。如果你更习惯 TOML等价配置如下mode minimal seed 42 maxTurns 50 [api] baseUrl https://taotoken.net/api apiKey ${TAOTOKEN_API_KEY} model deepseek-chat timeoutMs 120000 maxRetries 2 [tools] enabled [shell, file_edit] [tools.shell] timeoutMs 30000 maxOutputBytes 65536 [tools.file_edit] maxFileSizeBytes 1048576 [trajectory] record true outputDir ~/.dsh/trajectories includeToolArgs true includeToolResults true配置写好后启动命令带上配置文件路径npx deepseek-ai/dsh web --config ./harness.config.json如果你用的是 Claude Code 这类工具做辅助调试它的 settings 文件里也可以配同样的三件套。Claude Code 的配置文件通常在~/.claude/settings.json加上{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: ${TAOTOKEN_API_KEY}, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }注意 Claude Code 用的是ANTHROPIC_BASE_URL这个变量名和 Harness 的baseUrl不同但值都指向同一个 TaoToken API 入口。Model ID 换成你要用的 Claude 系列标识。这样你在调试评测脚本时Claude Code 和 Harness 走的是同一条 Key 通道不会出现“调试时通、评测时不通”的割裂。Cline 的 MCP 配置也是类似逻辑。在 Cline 的 MCP settings 里把 provider 的 base URL 指向 TaoTokenKey 用同一个环境变量Model ID 按需填。三件套Base URL Key Model ID在哪个工具里都是这三样只是变量名和文件路径不同。记住这个对应关系换工具时不会迷路。配置完成后先别急着跑完整测试集。下一节用一道最小题目验证整条链路是否通。4. 验证请求跑通一道最小题目并检查轨迹日志验证阶段的目标不是拿高分而是确认三件事API 通道通、极简模式生效、轨迹日志正常落盘。我建议用一道文件诊断类的简单题来验证因为这类题步骤少、验证快出问题时容易定位。先建评测工作目录和题目目录mkdir -p ~/terminal-bench-eval/problems/001 cd ~/terminal-bench-eval/problems/001一道标准题目包含三个部分task.md题目描述与成功标准、initial/初始文件状态、check.sh验证脚本。验证用的最小题目可以这样构造cat task.md EOF # 任务修复 Python 脚本中的类型错误 当前目录下有一个 calc.py运行时会抛出 TypeError。 请定位问题并修复使 python3 calc.py 能正常输出结果 42。 成功标准python3 calc.py 退出码为 0且输出包含 42。 EOF mkdir -p initial cat initial/calc.py EOF def add(a, b): return a b result add(40, 2) print(result) EOF cat check.sh EOF #!/bin/bash cd $(dirname $0) python3 calc.py /tmp/calc_out.txt 21 if [ $? -ne 0 ]; then echo FAIL: 脚本执行失败 cat /tmp/calc_out.txt exit 1 fi if grep -q 42 /tmp/calc_out.txt; then echo PASS exit 0 else echo FAIL: 输出不含 42 cat /tmp/calc_out.txt exit 1 fi EOF chmod x check.sh这道题的初始状态是calc.py里把字符串40和整数2相加会抛 TypeError。模型需要把40改成40或者做类型转换。验证脚本检查退出码和输出内容。现在把题目目录复制到 Harness 的工作区启动评测。Harness 的 Web UI 启动后在界面里选择极简模式确认 API 配置加载的是harness.config.json里的 TaoToken endpoint。提交任务后模型会通过 shell 读取calc.py用 file_edit 修改再跑python3 calc.py验证。跑完后检查轨迹日志ls -lt ~/.dsh/trajectories/ | head -5找到最新那个时间戳目录里面会有events.jsonl文件每行一个事件。用jq看工具调用序列cat ~/.dsh/trajectories/最新时间戳/events.jsonl | jq -r select(.typetool_call) | .tool (.args | tostring)正常输出应该类似shell {command: cat calc.py} file_edit {path: calc.py, old: add(\40\, 2), new: add(40, 2)} shell {command: python3 calc.py}如果看到shell和file_edit交替出现且没有web_search、sub_agent这类工具说明极简模式生效了。如果轨迹里出现大量重试事件或者工具调用之间间隔异常长检查 API 通道是否稳定。再确认 Token 消耗和步数cat ~/.dsh/trajectories/最新时间戳/summary.json | jq {turns, inputTokens, outputTokens, toolCalls}一道这样的简单题正常应该在 3 到 5 轮内完成工具调用 3 到 4 次Token 消耗在几百到一千多。如果步数超过 10 轮要么是模型理解有问题要么是通道超时导致重试。这时候先看轨迹里有没有timeout或local proxy failed事件有的话优先排查通道而不是急着换模型。验证通过后你就可以把测试集批量放进problems/目录用脚本循环跑。每道题跑完自动执行check.sh把结果汇总成表格。极简模式的可复现性优势在这里体现出来同一道题跑三遍工具调用序列基本一致通过率波动很小。如果某道题三次结果差异很大单独把三次轨迹拉出来对比看是模型采样不稳定还是题目边界条件设计有问题。5. 常见报错排查401、local proxy failed、reading choices、OAuth评测过程中最容易卡住的不是模型能力而是配置和通道问题。这一节按真实报错逐条排查。401 Unauthorized。这是最常见的问题九成是 Key 没传对。先确认环境变量是否真的导出echo $TAOTOKEN_API_KEY如果输出为空说明当前 shell 会话没加载。检查你是不是在~/.bashrc或~/.zshrc里写的 export但当前终端是另一个会话。临时解决直接export一次长期解决写进 shell 配置文件后source一下。如果变量有值但还是 401检查 Key 是否被复制时带了空格或换行用echo -n $TAOTOKEN_API_KEY | wc -c看字符数是否和预期一致。还有一种情况是配置文件里写了${TAOTOKEN_API_KEY}但 Harness 不解析环境变量这时候要么改成直接填值不推荐要么确认 Harness 版本支持变量插值。local proxy failed。这个报错通常出现在请求发出但连接没建立起来的时候。先确认 Base URL 写对了https://taotoken.net/api不要写成https://taotoken.net/api/尾部斜杠也不要带任何查询参数。然后确认本机网络能访问这个地址curl -sS -o /dev/null -w %{http_code}\n https://taotoken.net/api如果返回 401 或 404说明网络通只是没带认证或路径不对这是正常的。如果直接连接超时或 DNS 解析失败检查本机 DNS 和网络配置。注意不要用任何网络代理工具那会引入额外变量评测场景下通道必须干净。reading choices 报错。这个报错一般出现在模型返回格式不符合预期的时候。极简模式下模型应该返回工具调用或最终答案但如果模型返回了自然语言描述而没有实际调用工具Harness 解析时会报reading choices相关错误。排查方法看轨迹日志里模型返回的原始内容确认是不是模型没理解工具定义。如果是检查task.md的题目描述是否清晰成功标准是否明确。有时候题目描述太模糊模型会倾向于“解释”而不是“动手”。另一个可能是 Model ID 填错了导致请求发到了不支持工具调用的模型上。确认harness.config.json里的api.model是支持 function calling 的模型标识。OAuth 相关报错。如果你在 Claude Code 或类似工具里看到 OAuth 报错通常是因为工具默认走 OAuth 流程而不是 API Key。这时候需要在 settings 里显式配置ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY把认证方式从 OAuth 切到 API Key。Claude Code 的 settings.json 里加上前面那三件套后重启工具OAuth 报错应该消失。如果还报检查是不是有多个配置文件冲突比如项目级 settings 覆盖了用户级 settings。轨迹日志不落盘。跑完题目发现~/.dsh/trajectories/是空的。检查harness.config.json里trajectory.record是否为trueoutputDir路径是否存在且可写。如果路径用了~确认 Harness 是否展开波浪号有些版本不展开需要写绝对路径。另外如果题目在check.sh之前就失败了轨迹可能只记录了部分事件确认题目目录结构完整。工具调用被拒绝。极简模式只允许 shell 和 file_edit如果模型尝试调用其他工具会被 Harness 拒绝并记录。这本身不是 bug而是极简模式的预期行为。但如果你发现模型频繁尝试调用被禁用的工具说明系统提示词里可能残留了标准模式的工具描述。检查 Harness 版本和配置文件确认mode确实是minimal且没有其他配置覆盖它。排查顺序建议先看 401认证再看 local proxy failed通道再看 reading choices模型返回格式最后看 OAuth工具认证方式。大部分问题集中在前两类把 Key 和 Base URL 确认清楚能解决八成以上的报错。6. 把评测跑稳之后下一步做什么验证跑通、报错排查清楚之后你手里就有了一套可复现的 Terminal Bench 极简模式评测环境。接下来可以做的事把测试集按难度分层先跑初级题建立基线再逐步加高级题对同一模型跑三遍取平均记录通过率、平均步数、Token 消耗三个指标换不同 Model ID 做横向对比因为通道统一差异更接近模型本身能力。如果你要长期做模型评测或 Agent 开发建议把配置和轨迹日志纳入版本管理。harness.config.json提交到 Git轨迹日志压缩存档每次评测记录 Model ID、Harness 版本、测试集版本。这样半年后别人拿到你的配置能复现出一致结果。需要管理多个模型的 Key 和通道时可以在控制台创建不同的 API Key按项目或按模型分组避免一条 Key 到处用。跑评测的过程中如果遇到通道层面的问题优先看接入文档里的说明想先确认某个 Model ID 是否可用可以在模型对话页面直接发一条测试请求如果是长期编码或 Agent 场景需要更稳定的调用配额可以了解 Coding Plan 的配置方式。把通道这层管住评测的变量就只剩模型本身跑出来的数据才有对照价值。