为什么基准测试要选极简模式DeepSeek Harness 提供四种运行模式标准模式功能最全PTC 模式让模型自己写代码编排工具调用创造模式用于调试插件——但如果你是做模型评测极简模式才是正解。极简模式只保留两个工具shell和file_edit。没有网络搜索、没有多轮子 Agent 调度、没有额外的上下文注入策略。这种裁剪不是偷懒而是把变量控制到最少模型拿到的就是原始系统提示词执行的就是基础文件操作测出来的就是模型本身的工具理解与调用能力。标准模式里那些智能路由、自动重试、外部技能调用都会让基准测试变成测系统而非测模型这对需要横向对比不同模型表现的评测者来说是致命的。另一个容易被忽略的优势是可复现性。极简模式的插件集合固定没有随机加载的外部能力同一道题跑十遍轨迹日志里的工具调用序列应该基本一致。这在需要严格对照的学术评测里至关重要。Terminal Bench 的题型设计与难度分层Terminal Bench 是 Harness 社区里较成熟的基准测试集专门考察模型在终端环境下的代码理解与操作能力。它的题目不是简单堆数量而是有明确的维度设计题型分布上大致分为三类文件诊断类给定一个报错的项目让模型定位问题并修复功能实现类从零开始创建文件、写代码、跑测试环境配置类安装依赖、调整配置文件、验证服务可用性难度分层通过三个维度实现代码库规模单行脚本 vs 多模块项目、依赖复杂度纯标准库 vs 需要外部包、以及验证方式直接运行看输出 vs 需要写测试用例通过断言。初级题可能只需要改一个函数的参数类型高级题则要求模型理解整个项目的构建流程甚至处理跨文件引用。这种设计让 Terminal Bench 能覆盖从会写脚本到能维护项目的能力光谱而不是所有题目都挤在同一个难度区间里变成抽奖。与 SWE-bench 的核心差异很多人拿 Terminal Bench 和 SWE-bench 对比两者确实都测代码能力但评测维度有明显区别维度SWE-benchTerminal Bench极简模式环境假设完整开发环境含 Git 历史最小化终端仅 shell 文件编辑任务来源真实 GitHub Issue需理解上下文构造型题目聚焦工具调用本身成功标准测试用例通过 不破坏原有功能按题目要求的输出/状态判定模型可见信息Issue 描述、代码库、测试日志仅当前终端输出与文件内容评测重点端到端软件工程能力工具调用准确性与效率SWE-bench 更像招一个能干活的工程师Terminal Bench 极简模式则是测一个候选者的基本功。前者模型可以依赖丰富的环境信息和工具链后者则把模型扔到近乎裸机的环境里看它能用多快的速度、多少的试错次数完成任务。对于研究模型作为 Agent 的核心能力边界而非系统工程能力的场景Terminal Bench 的隔离性更有价值。测试集配置与运行实战假设你已经通过npx deepseek-ai/dsh web启动了 Harness接下来配置极简模式跑 Terminal Bench。首先确认 Harness 版本支持极简模式然后在项目配置中指定模式。不需要修改源码Harness 的插件化架构允许纯配置切换# 创建评测专用工作目录 mkdir -p ~/terminal-bench-eval cd ~/terminal-bench-eval # 启动时指定极简模式或通过 Web UI 设置中选择 npx deepseek-ai/dsh web --mode minimal测试集通常以结构化目录组织每道题包含task.md题目描述与成功标准initial/初始文件状态可能为空check.sh验证脚本返回 0 表示通过运行单题评测的典型流程# 假设题目在 ./problems/001 目录 cd problems/001 # 查看题目要求 cat task.md # 模型开始执行通过 Harness Web UI 或 API 提交任务 # 完成后运行验证 bash check.shHarness 的轨迹日志会完整记录模型的每一步操作。评测结束后关键文件在~/.dsh/trajectories/下按时间戳命名包含完整的事件流。结果解读与可复现性保障拿到轨迹日志后评测者需要关注几个核心指标工具调用准确率模型是否一次就调对了工具还是反复试错极简模式下 shell 和 file_edit 的参数错误会直接暴露理解缺陷。任务完成步数从接收到完成用了多少轮交互。这个指标比绝对时间更能反映模型的规划效率因为网络延迟等外部因素被剥离了。Token 消耗每道题的输入输出 Token 数这是成本敏感场景的关键参考。可复现性通过三层机制保障固定种子Harness 支持设置随机数种子消除模型采样带来的波动确定性工具输出极简模式的工具实现是纯函数式的同样输入必定同样输出版本锁定测试集、Harness 核心、插件版本都在轨迹日志中记录便于他人复现建议评测时开启--record-trajectory并保留完整的package-lock等价物这样半年后别人拿到你的配置应该能跑出一致的结果。防作弊机制与结果提交基准测试最怕的就是泄题和外挂。Terminal Bench 在这方面的防护设计值得借鉴题目隔离每道题运行在独立的临时目录模型看不到其他题目的文件也无法访问网络下载答案。极简模式本身就去掉了网络工具从根上杜绝了搜索作弊。输出校验check.sh不只是看最终文件内容很多题目会验证操作过程的合理性——比如要求用特定命令生成文件而不是直接写入。轨迹审计Harness 的 Trajectory 机制让每一次工具调用都有据可查。如果某模型的表现好得不正常社区可以要求提交完整轨迹进行人工复核。时间窗口控制部分公开评测会限制单题最大交互轮数防止模型通过暴力枚举撞出答案。完成评测后结果提交到社区排行榜的流程通常如下准备材料模型标识名称、版本、参数量级、完整轨迹压缩包、评测配置快照自检清单确认没有修改 Harness 核心代码、没有额外预加载题目信息、没有人工介入修正提交渠道通过 Harness 官方 GitHub 仓库的 Discussion 区或指定表单提交社区验证维护者会抽样复现确认无误后更新排行榜目前排行榜主要按通过率排序辅以平均步数和 Token 消耗作为参考维度。随着参与方增多可能会引入分难度加权等更精细的计分方式。给评测者的实用建议如果你是第一次跑 Terminal Bench建议从文件诊断类的简单题入手熟悉 Harness 的日志格式和验证逻辑。不要一上来就挑战需要多文件协调的复杂题很容易在环境理解上消耗过多时间。另外不要迷信单次结果。模型采样带来的方差可能比想象中大正式报告前至少跑三遍取平均。如果某道题三次结果差异很大值得单独分析轨迹看是模型本身不稳定还是题目边界条件设计有问题。最后极简模式虽然叫极简但 Harness 的插件架构允许你在保持核心工具不变的前提下微调提示词模板或添加轻量级后处理。这类变体如果和官方极简模式有显著差异提交结果时务必注明配置细节避免排行榜上的数据失去可比性。