四种运行模式横向对比，极简模式为什么能跑基准测试

四种模式的设计初衷DeepSeek Harness 把 Agent 的运行方式拆成四种预置模式不是简单的功能开关而是对「模型能力边界」与「工具复杂度」之间 trade-off 的系统性回答。标准模式堆满工具PTC 模式让模型自己写代码调度极简模式只剩 Shell 和文件编辑创造模式则把运行时本身暴露给模型去改造。理解这四条路径的分野才能选对场景、少踩坑。下面我用一个具体任务贯穿对比让 Agent 生成一个可运行的贪吃蛇游戏。这个任务足够典型——涉及代码生成、文件操作、依赖安装、运行验证能清晰暴露不同模式的差异。标准模式全工具链的「重装备」打法标准模式加载 Harness 的完整插件集合模型能调用的工具包括文件读写、Shell 执行、代码搜索、联网检索、甚至子 Agent 调度。面对贪吃蛇任务它的典型流程是分析需求判断需要 HTML5 Canvas JavaScript 实现创建项目目录写入index.html、game.js、style.css检测到需要本地服务器自动执行python -m http.server或npx serve运行后若报错读取浏览器控制台日志定位问题循环修复直到可运行必要性成本在这里体现得很明显。完整工具链带来了极高的灵活性模型可以像人类开发者一样「见招拆招」——需要 HTTP 请求就调fetch需要画图就写 Canvas API遇到依赖问题直接npm install。但代价是上下文窗口被大量工具描述占据每次决策的候选空间膨胀模型更容易在「选择用哪个工具」上犹豫或出错。实测中标准模式完成贪吃蛇平均需要 8-12 轮交互Token 消耗是四种模式中最高的。更隐蔽的成本在于调试路径的不可预测性。模型可能先写了个基础版本发现蛇不能正确增长于是尝试添加console.log调试又发现需要浏览器 DevTools转而搜索如何启用 headless Chrome……这种「发散式排查」在复杂任务中是优势在目标明确的基准测试里却是噪音。PTC 模式代码即控制流的得与失PTCProgrammatic Tool Calling模式的核心变化是模型不再逐轮选择工具而是生成一段代码来编排多轮调用。面对同样的贪吃蛇任务模型会输出类似这样的伪代码def build_snake_game(): create_file(index.html, generate_html()) create_file(game.js, generate_js_logic()) result run_shell(node -e \require(http).createServer(...).listen(8080)\) if result.exit_code ! 0: return retry_with_fix(result.stderr) return verify_gameplay(http://localhost:8080)准确率是 PTC 模式的亮点。把工具调用结构化为代码后模型的推理从「每步选动作」变成「写程序解决问题」更符合预训练时的代码 completion 范式。DeepSeek 的内部测试显示PTC 模式在需要多步工具协作的任务上成功率比标准模式高出 15-20%。但调试复杂度也随之上升。当 PTC 生成的代码执行失败时错误可能来自三个层面模型生成的业务逻辑如蛇的移动算法、工具调用的参数格式、或者编排代码本身的控制流如忘记处理异步。排查时需要同时看「生成的代码」和「代码执行时的工具轨迹」两层抽象叠加对 Trajectory 日志的阅读能力要求更高。用贪吃蛇案例来说PTC 模式可能在verify_gameplay环节失败原因是生成的 HTTP 检测代码没处理 404 重试而根本原因是game.js里的路径写错了。这种「远端错误、近端表现」的错位让调试比标准模式更考验经验。极简模式基准测试的「标准化」哲学极简模式只保留两个工具Shell 和文件编辑。没有联网搜索没有子 Agent没有浏览器自动化——模型能用的只有最原始的计算环境。这种「自断双臂」的设计恰恰是为了可控性。Terminal Bench 这类基准测试的核心诉求是排除一切外部变量纯粹衡量模型在代码生成和基础工具使用上的能力。如果允许联网模型可能直接搜索「贪吃蛇完整代码」复制粘贴如果允许子 Agent任务可能被拆成不可比较的子任务。极简模式强制模型从零开始构建测试结果才能反映真实的代码理解与生成能力。在贪吃蛇任务中极简模式的表现往往最「笨拙」但也最透明。模型需要用cat game.js或文件编辑工具逐段写入代码用node game.js测试根据终端报错手动修复没有浏览器只能用curl或自己写简单的 HTTP 验证逻辑甚至直接在终端用 ASCII 渲染验证这种受限环境逼出了模型的「基本功」。有趣的是一些在标准模式下依赖丰富工具「取巧」的模型在极简模式中会暴露真实短板——比如生成语法正确的代码却不懂如何组织多文件项目或者面对简单的ReferenceError不会用 Shell 查看文件内容定位问题。极简模式的标准化价值在于结果的可复现与可比性。同一道题不同模型在完全相同的工具集上作答差异只来自模型本身的推理与代码能力。这对评测者比对模型迭代、或者研究者定位能力瓶颈至关重要。创造模式元编程的边界试探创造模式是四种模式中最特殊的。它不直接执行任务而是让模型检查当前 Harness 的运行时状态、在内存中加载和调试 Cordis 插件甚至组合出新的运行模式。面对贪吃蛇任务创造模式不会生成游戏本身而是可能检查当前加载了哪些插件分析标准模式的工具组合是否合理尝试写一个自定义插件把「Canvas 渲染」封装成新工具供后续使用或者基于极简模式的配置微调出一个「带自动调试的极简变体」元编程能力边界在这里变得具体。模型需要理解 Cordis 的插件生命周期、服务注册与依赖注入机制这远超普通代码生成的要求。实测中创造模式更适合作为「模式开发者」而非「任务执行者」——它帮你造工具而不是直接拿工具活。一个有趣的观察是创造模式下模型偶尔会「过度设计」。比如为了贪吃蛇任务它可能先花大量篇幅设计一个通用的「游戏引擎插件框架」最后发现时间/Token 耗尽游戏还没开始写。这提示我们创造模式的真正价值在基础设施层面的迭代而非单次任务的快速交付。模式选择的实践建议回到贪吃蛇案例的对比维度标准模式PTC 模式极简模式创造模式完成速度中等工具选择开销较快结构化编排较慢从零构建极慢先造工具调试难度中等路径发散较高两层抽象低透明直接高运行时层面结果可预测性低中等高低适用场景探索性开发复杂自动化流水线基准测试、能力评估框架定制、插件开发日常开发中标准模式仍是默认选择——工具多意味着兜底能力强。PTC 模式适合已经把任务流程梳理清楚的场景比如 nightly CI 里的自动化测试流水线。极简模式是评测者的利器也是检验模型「真功夫」的试金石。创造模式则留给那些需要深度定制 Harness 本身的高级用户。四种模式并非互斥。实际工作中你可能会用创造模式调试出一个新插件把它注册到标准模式里再用 PTC 模式编排调用逻辑——这种组合使用才是 Harness「一切皆插件」设计的完整图景。