四种模式的设计初衷DeepSeek Harness 把 Agent 的运行时拆成了可替换的插件组合而四种模式本质上就是四套预设的插件加载方案。标准模式走「全功能」路线PTC 模式让模型自己写代码来编排工具调用极简模式只留最基础的 Shell 和文件编辑能力创造模式则把运行时本身开放给你折腾。这个设计思路很符合 Harness「一切皆插件」的底层逻辑——模式不是硬编码的代码分支而是配置层面对插件集合的选择。理解这一点后面看实测数据时就不会觉得奇怪了。模式切换与插件加载差异切换模式的方式比想象中简单。启动 Web UI 后在设置里下拉选择即可如果走命令行可以在启动参数里指定或者修改工作区的配置文件。四种模式加载的插件差异可以用一张表概括模式核心插件保留裁剪掉的典型能力设计目标标准模式模型适配、工具注册表、联网搜索、多 Agent 调度、沙箱、UI无通用开发功能完整PTC 模式模型适配、代码生成器、工具调用执行器联网搜索、多 Agent 调度模型生成代码来编排多轮工具调用极简模式仅 Shell 工具、文件编辑工具联网搜索、代码生成器、多 Agent 调度、沙箱最小化环境基准测试创造模式运行时检查器、内存调试器、插件热加载器预置工具集被清空按需手动加载自定义新运行模式这里有个细节值得注意极简模式不是「简陋版」而是有意做减法。Harness 团队用它来做 Terminal Bench 这类基准测试目的是排除其他插件干扰单纯衡量模型在基础工具环境下的原生能力。同一任务实测贪吃蛇游戏生成我用生成贪吃蛇游戏这个任务跑了四遍记录了下述数据。任务描述统一为「在当前目录创建一个可运行的贪吃蛇网页游戏」模型选用 DeepSeek-V4-Pro。标准模式的表现最稳。它会先分析目录结构然后依次创建 HTML、CSS、JavaScript 文件中间还会主动询问是否需要添加计分功能。整个过程耗时约 52 秒Token 消耗在 4.2 万左右成功率最高三次测试全部一次通过。PTC 模式的行为特征很有意思。它不会直接调用文件工具而是先写一段 JavaScript 代码这段代码内部再调用 Harness 的工具 API 来完成文件创建。你可以理解为「模型写了个脚本让脚本去干活」。这种模式在复杂任务上优势更明显但贪吃蛇这种简单任务反而多了层间接性耗时约 61 秒Token 消耗 4.8 万左右。不过它的价值在于可复现性——生成的代码本身就是一份可保存、可修改的「操作记录」。极简模式下模型只有 Shell 和文件编辑两个工具可用。它选择用cat命令直接写入文件内容或者调用编辑器插件逐行写入。整个过程更「原始」耗时约 48 秒Token 消耗最低仅 3.6 万左右。但代价是如果任务需要联网查资料或调用外部 API极简模式会直接失败。三次测试中有一次因为模型想引用 CDN 链接但无法验证可用性导致生成的游戏运行异常。创造模式的体验最特殊。启动后界面会多出一个「插件控制台」你可以看到当前加载了哪些插件、每个插件的依赖关系还能在内存中临时加载或卸载插件。我用它把标准模式的工具注册表插件动态加载进来相当于「手动拼装」了一个介于标准和极简之间的混合模式。这个过程本身就需要对 Harness 的插件机制有一定理解不适合新手但自由度确实最高。极简模式的基准测试价值前面提到极简模式被用于 Terminal Bench 测试这里展开说一下。Terminal Bench 是一类评估模型在纯终端环境下能力的基准核心假设是如果模型只有ls、cat、sed这类基础工具还能不能完成指定任务Harness 的极简模式恰好提供了这个「干净」的运行时。测试时除了 Shell 和文件编辑其他插件全部卸载模型无法借助联网搜索「偷懒」也无法通过多 Agent 调度把任务甩给子代理。这种设定下测出的数据更能反映模型对基础工具链的理解深度。从实际测试看DeepSeek-V4-Pro 在极简模式下的表现不错但确实比标准模式更容易出现「幻觉」——比如假设某个文件存在、或者误用不存在的命令参数。这也说明极简模式对模型的指令遵循能力要求更高。PTC 模式的完整链路拆解PTCProgrammatic Tool Calling模式是四种模式里设计最精巧的。它的核心链路可以拆解为需求理解模型接收用户任务分析需要哪些工具操作代码生成模型生成一段 JavaScript 代码代码内部调用 Harness 的 API代码执行Harness 在沙箱中运行这段代码工具调用代码运行时按需触发工具调用结果返回给代码结果汇总代码处理完所有工具调用后向用户输出最终结果这个模式的优势在于「可编程性」。标准模式里模型每步操作都是一次独立的 LLM 调用上下文容易碎片化而 PTC 模式把多轮工具调用封装进同一段代码模型可以在代码里使用变量、循环、条件判断逻辑更紧凑。实测中我让它批量修改一个项目里的多个文件PTC 模式生成的代码用了一个for循环遍历文件列表而标准模式是逐个文件询问确认。效率差异在 5 个文件以内不明显超过 10 个文件时 PTC 模式的优势就体现出来了。创造模式的热插拔实战创造模式最吸引人的是「运行时插件热插拔」。我试了一个场景先用极简模式跑基准测试发现需要联网查文档时不重启服务直接在插件控制台加载web-search插件继续任务。具体操作是在创造模式的控制台里执行类似这样的配置{ action: load, plugin: deepseek-harness/web-search, version: latest }加载成功后当前会话立即获得联网能力已执行的上下文不受影响。如果之后想卸载同样一条配置改action为unload即可。这种「会话级」的插件生命周期管理对调试和实验非常友好。不过要注意热插拔不是完全无感的。某些插件如果已经被当前会话中的任务依赖卸载时会有依赖检查提示强制卸载可能导致正在进行的任务异常终止。选择决策树综合以上实测四种模式的适用场景可以总结如下选标准模式你不确定该用哪个模式或者任务涉及多步骤、需要灵活调整。这是默认的安全选择功能最全容错最高。选 PTC 模式任务需要批量、重复、有条件的工具调用或者你希望保存一份可复现的「操作脚本」。适合自动化流水线场景。选极简模式你在做模型能力评测或者运行环境极度受限比如离线、安全沙箱。也适合想纯粹观察模型原生能力的场景。选创造模式你需要深度定制 Harness 的运行时或者在调试插件、开发新插件。这是给「玩框架」的人准备的不是给「用框架」的人。最后提一句目前 v0.1 版本的四种模式切换还需要手动操作未来如果支持根据任务特征自动推荐或动态切换体验会更上一层楼。但就现在而言理解每种模式的插件加载逻辑和适用边界已经能帮你避开不少坑。