为什么极简模式是评测模型工具调用能力的“干净画布”
DeepSeek Harness 提供了四种运行模式，其中极简模式（Minimal）被官方专门用于 Terminal Bench 等基准测试场景。这个设计思路很直接：当你想评估模型“纯粹”的工具调用能力时，必须把变量控制到最少。
标准模式加载了完整的插件生态——联网搜索、多智能体编排、外部技能调用，这些能力固然强大，却会让评测结果变得难以解释。模型表现好，到底是因为推理能力强，还是因为某个工具插件的兜底？极简模式只保留两个基础工具：Shell 命令执行与文件编辑。这意味着模型必须直接面对操作系统环境，没有捷径可走，评测者也能获得更干净的基线数据。
更深一层看，这种“做减法”的思路对应了 Harness 的插件化架构。基于 Cordis 框架，所有能力都是可插拔的。极简模式本质上是一份精简的插件清单，它排除了会话管理、子 Agent 调度等可能引入噪声的模块，让 Trajectory 日志里只保留模型与工具的核心交互轨迹。
环境准备：从启动到配置 API Key
如果你已经用过 Harness 的标准模式，切换到极简模式几乎零成本。最快的方式是通过 npx 启动：
npx @deepseek-ai/dsh web服务默认运行在http://127.0.0.1:3080。首次启动后，进入 Settings → Models 配置你的 API Key。这里有个细节：Harness 本身免费，但调用模型按 Token 计费，建议评测前确认账户余额或速率限制。
切换到极简模式需要在配置层面指定。Harness 的运行模式由加载的插件集合决定，你可以在项目根目录或工作区配置中，选择仅加载shell和file-edit两个核心插件。具体而言，检查你的配置文件或启动参数，确保没有额外加载web-search、multi-agent等扩展插件。
对于批量评测场景，更推荐源码安装方式，方便在packages/config中固化极简模式的插件清单，避免每次手动切换：
git clone https://github.com/deepseek-ai/deepseek-harness.git cd deepseek-harness pnpm install pnpm run build测试数据集的配置与批量运行
评测模型工具调用能力，核心在于设计能覆盖典型场景的任务集。Terminal Bench 这类基准测试通常包含以下维度：
- 文件系统操作：创建目录、写入配置、追加日志
- 文本处理：查找替换、格式转换、内容提取
- 命令组合：管道操作、条件判断、错误处理
- 环境感知：读取当前路径、检查依赖版本
在 Harness 中，你可以将这些任务整理为结构化的测试用例。每个用例包含初始状态（如预置的文件结构）、用户指令（自然语言描述的任务目标）以及预期结果（文件内容校验或命令输出匹配）。
批量运行的关键在于利用 Harness 的轨迹（Trajectory）机制。每次运行产生的完整事件流——包括系统提示词、思维链、工具调用请求、执行结果——都会以仅追加格式写入日志。你不需要自己搭建复杂的记录系统，只需在评测脚本中指定输出目录，事后统一解析这些 JSONL 格式的轨迹文件即可。
一个实用的技巧是：为每个测试用例单独创建工作区（Workspace），避免状态污染。Harness 的 Trajectory 日志天然支持按会话隔离，这让并行跑多个模型、多个任务变得安全可控。
从 Trajectory 日志中提取关键指标
轨迹日志的价值在于它是原始事件级记录，而非经过润色的摘要。这意味着你可以精确还原模型每一步的决策过程，并从中提取量化指标。
重点关注以下几类数据：
工具调用成功率
解析 Trajectory 中的tool_call和tool_result事件对。一次成功的工具调用需要满足：模型正确构造了参数、工具执行未抛出异常、返回结果符合预期。对于 Shell 工具，还需额外检查命令退出码。
Token 消耗结构
Harness 的日志会记录每次上下文注入的 Token 数。在极简模式下，由于没有其他插件的提示词干扰，你可以清晰看到：系统提示词占多少、用户指令占多少、工具返回结果又占多少。这对分析模型的“上下文利用效率”很有帮助——有些模型会在多轮工具调用后迅速耗尽上下文窗口，导致后续任务失败。
思维链长度与收敛性
Trajectory 中的reasoning或thought事件反映了模型的中间推理过程。观察模型在失败任务中的思维链，往往能发现两类典型问题：一是“过度思考”，在简单任务上消耗过多轮次；二是“过早放弃”，遇到首次错误就停止尝试而非修复。
建议编写一个轻量的解析脚本，批量处理 Trajectory 日志并生成 CSV 报表。这比肉眼逐个检查高效得多，也便于后续做跨模型对比。
跨模型对比：相同极简环境下的表现差异
极简模式的最大优势，在于它为不同模型提供了公平的竞技场。当你把模型 A 和模型 B 放在完全相同的工具集合、系统提示词和初始环境下运行时，性能差异才真正具有可比性。
实际评测中，常见的差异模式包括：
参数构造准确性
面对sed或awk这类复杂命令，部分模型会生成语法错误的表达式。极简模式下没有“智能修复”插件兜底，这些错误会直接暴露。观察 Trajectory 中工具调用的重试次数，能直观反映模型对 Shell 语法的掌握程度。
文件操作的精细度
编辑文件时，模型需要精确指定行号或匹配模式。有的模型倾向于“安全但低效”的策略——先读取整个文件、修改后再完整写入；另一些则尝试更精确的局部编辑，但可能因边界条件处理不当而破坏文件结构。通过对比同一任务下不同模型的文件操作序列，可以评估其“工程直觉”。
错误恢复策略
故意在测试环境中预置一些陷阱，比如不存在的依赖、权限不足的文件。表现好的模型会在 Trajectory 中展现出清晰的诊断-修复循环：读取错误信息、分析原因、调整命令、重新执行。而较弱的模型可能陷入重复尝试相同命令的死循环。
需要强调的是，这种对比的可信度建立在控制变量的基础上。如果在标准模式下对比，模型 A 可能恰好更擅长调用某个外部搜索工具，从而掩盖了其原生工具调用能力的不足。极简模式强制所有模型站在同一起跑线，结果更具参考价值。
结果解读的局限性与注意事项
尽管极简模式提供了干净的评测环境，解读结果时仍需保持审慎。
工具集的代表性局限
只测 Shell 和文件编辑，无法推断模型在更复杂场景（如 API 调用、数据库操作）中的表现。如果你的实际应用场景需要这些能力，极简模式的评测结果只能作为必要而非充分条件。
环境依赖的不可完全消除
即使插件极简，底层操作系统、Shell 版本、文件编码等仍可能引入差异。建议在评测报告中明确记录运行环境，并在多次重复中观察结果的稳定性。
“能通过测试”不等于“能做好工程”
Terminal Bench 验证的是模型在受控任务中的工具调用正确性，但真实软件开发涉及需求理解、架构权衡、长期维护等维度。极简模式的评测结果应当作为模型能力的一个切面，而非全面评价。
DeepSeek 官方选择极简模式作为基准测试的默认配置，正是看中了它在可解释性与可重复性之间的平衡。对于评测者和研究者而言，理解这一设计背后的考量，比单纯追求高分更有价值。
