本文是一份 DeepSeek Harness 的实战记录把 DSH 从零跑起来再用两份对照实验把它拆开看。与常见安装教程不同本文包含三样东西两套可复现的对照实验方法、官方源码v0.2.0-rc.2的逐文件解剖、以及在同一台机器上真实跑出来的 8 次运行数据4 个会话 × 两份对照实验。全文命令与数据均可复现实测环境Windows Node 24 dsh 0.2.0-rc.2。一、先搞清楚要干什么本文的目标不是装完能用就结束而是建立一个可观察的 DSH 环境然后用对照实验把它的运行机制拆开看。正确的打开方式是三段跑起来装环境、启动 Web UI、接一个模型、选工作区做两个对照实验实验 1创建 4 个会话分别用 4 套 Preset问同一个问题——“你当前可以使用哪些能力不要执行任何操作只按类别说明。”关键用 UI/Trace 取证不能拿模型自述当证据实验 24 套 Preset 跑同一个任务——“读取当前目录创建 3 个文本文件统计总行数然后给出摘要。除完成任务外不做额外修改。”——比较执行轨迹想一个更大的问题官方 Benchmark 为什么选 Minimal结论后面第八章展开三个环节环环相扣下面逐个给结果。二、环境准备与安装含国内网络三大坑要求就一条Node.js^22.19.0或24.0.0装 Node 24 准没错。node-v# v24.12.0 ✅三种安装方式按需选择# 方式一免安装直接跑官方推荐npx deepseek-ai/dsh web# 方式二全局安装长期使用npminstall-gdeepseek-ai/dsh dsh--version# 0.2.0-rc.2# 方式三从源码改代码/写插件才需要gitclone https://github.com/deepseek-ai/deepseek-harness.gitcddeepseek-harnesscorepackenablepnpminstallpnpmrun buildpnpmdsh web⚠️国内网络三大坑全部实测踩过坑现象解决GitHub 直连clone 超时地址前加镜像https://ghproxy.net/https://github.com/...npm 官方源慢npx 卡在依赖解析前加npm_config_registryhttps://registry.npmmirror.com实测 538 个依赖包从卡几分钟到39 秒Windows corepackcorepack enable报 EPERM要写 Node 安装目录需管理员终端不走源码路线可跳过三、启动与第一次配置dsh web# 终端输出dsh web: http://127.0.0.1:3080/?token一串字符必须带?token访问——那是本次启动的临时钥匙浏览器用它换取签名的会话 cookie。直接开127.0.0.1:3080会返回 401这不是故障是设计。接下来三步配置模型设置 → 模型 → DeepSeek (deepseek-official)填入 platform.deepseek.com 申请的 API 密钥。默认模型DeepSeek-V4.1-Flash推理等级 High上下文窗口 100 万 token支持图片。选择工作区。选模式Preset输入框上方有标准模式按钮点开就是 4 套模式。⚠️ 关于工作区一个真实踩坑记录很多教程包括我会以为从哪个目录启动默认工作区就是哪。实测发现不是DSH Web 界面里的默认工作区是它自动注册的C:\Users\你\Documents\deepseek-harness\default-workspace跟启动目录无关。而添加工作区按钮会触发服务端弹 Windows 原生文件夹对话框——如果你的 dsh 是在后台/非交互终端里启动的这个对话框弹不出来报win32 folder dialog worker exited before reporting a result前端表现为无法打开文件夹 / directoryPicker failed。结论做实验直接用默认工作区即可它天然是个空目录正适合要加自定义目录请在普通终端启动 dsh 后手动选择。四、认识 4 套 Agent Preset界面 源码逐文件解剖界面上有四种模式点输入框上方的模式按钮可见界面名称官方描述实测截图原文标准模式处理代码、文件和资料适合大多数任务。Agent 会按需使用检索、编辑和终端等工具。PTC 模式包含标准模式的所有能力更适合批量调用工具、并对结果进行筛选、整理、去重、统计或汇总的任务。极简模式Agent 仅使用终端工具完成任务适合测试和对比其基础表现。创造模式用对话定制 DSH让 Agent 编写插件添加新功能或界面也能组合工具和提示词创建自己的模式。光看描述不够直接看源码。4 套 Preset 在官方仓库里的位置是packages/bundle/web-app/presets/ ├── standard.patch.yml # 标准 ├── ptc.patch.yml # PTC ├── minimal.patch.yml # 极简 └── cordis.patch.yml # 创造目录名 cordis界面叫创造模式⚠️ 版本说明早期资料里第四套常被称作Creative目录cordis/、PTC 的呈现模式写作mode: code当前 0.2.0-rc.2 代码里呈现模式已是mode: ptc界面名是创造模式。版本敏感内容以你安装的版本为准。至于默认进哪个模式——由packages/bundle/web-app/cordis.patch.yml第 574 行的agent-preset-registry决定default: standard。4.1 Standard能力基线standard.patch.yml 就是一份插件清单全文约 137 行挂载的东西包括身份persona“You are a coding agent powered by the {{model}} model.”、agent-instructions、time-context执行tool-bashWin 禁用/ tool-pwsh非 Win 禁用、tool-fs、tool-fs-search任务tool-jobs、tool-schedule、command-goal、tool-goal规划plan-modeisolate: planMode上下文compaction压缩 tool-result-pruner阈值 8192 字符头 4096/尾 1024委派tool-subagentspawn、tool-subagent-forkfork、workflow-ptc、tool-workflow交互tool-ask-user、tool-todo、tool-web、present4.2 PTC和 Standard 只差三行把两个文件 diff 一下这是全文最震撼的一个事实# 差异一、二关掉 workflow 相关工具 - id: workflow-ptc disabled: true - id: tool-workflow disabled: true # 差异三新增工具呈现插件 - id: tool-presentation name: deepseek-ai/dsh-agent-tool-presentation config: mode: ptc三行。没有第二套工具实现、没有第二套循环——PTC 改变的只是工具呈现给模型的方式从逐个原生调用变成模型写一段 TypeScript 程序批量调用。这就是Capability ≠ Presentation能力 ≠ 呈现的直观含义。这个结论一会儿会被实验直接验证。4.3 Minimal61 行的极限瘦身minimal.patch.yml 全文只有 61 行整个 Preset 只有两项-id:personaname:deepseek-ai/dsh-personaconfig:prefix:You are a helpful software engineer assistant.complete:trueincludeRuntimeContext:false# ← 关键不注入运行时上下文-id:persistent-shell# 组pty 持久 bash/pwsh翻译成人话一个人设 一个持久终端。没有文件工具、没有技能、没有子代理、没有压缩而且连运行时上下文都不注入——这条includeRuntimeContext: false就是极简最狠的一刀实验中它会带来断崖式差异。4.4 cordis创造模式把 Runtime 变成可操作对象相对 Standard 的差异集中在技能组-id:tool-cordisname:deepseek-ai/dsh-tool-cordis# 只读运行时 API 查询-id:skill-filesystemconfig:customSkillDirs:[.../dsh-agent-preset/skills]# 4 个专属技能-id:tool-skill专属技能目录里是 4 个包agent-experience、cordis-composition-reference、cordis-plugin-development、editing-cordis-compositions——从名字就能看出主题读 Cordis 组合、写 Cordis 插件、编辑组合。再叠加 Host 侧的插件管理器Agent 就能在授权范围内观察甚至修改承载自己的运行时组合cordis_mount的典型流程检查运行时 → 生成临时插件 → 挂载 → 会话获得新能力 → 验证 → 卸载。同理这也是信任边界而非沙箱——能力越强越需要外层的权限、审查与恢复机制。五、实验 14 个会话问同一句话方法要点问完之后模型的自述不能当证据——它可能遗漏工具、把能力合并成模糊概念、甚至说错。正确做法是打开会话的轨迹面板看运行时实际注入的上下文和工具调用。先学会读轨迹面板第一次打开轨迹可能有点懵它其实长这样以本机实测的布局为准顶部列时长 / 轮次 / 调用——一眼看出这轮跑了几步、调了几个工具、快不快消息条目按时间顺序用户你发的那句话上下文运行时实际注入的东西——第一条是 runtime context文件策略、审批策略、工作区路径第二条常是 skills 清单available_skills...的 system-reminder助手模型的思考和输出工具工具的调用参数JSON与返回值PTC 模式下会显示为工具 run_code嵌套的子工具pwsh、write 等非常直观地展示程序化调用底部用量栏轮/步、tok/s、缓存命中、上下文占比。一句话轨迹面板 模型这轮到底看到了什么、做了什么的全记录。实验 1 的结论全部从这里取证而不是从模型的回答里取证。实测数据同一模型 DeepSeek-V4.1-Flash仅 Preset 不同观测项标准模式PTC 模式极简模式创造模式首轮用量8.5K tok9.4K tok1.8K tok10.2K tok轮 / 步1 / 11 / 11 / 11 / 1缓存命中10%0%0%17%轨迹里的上下文段✅ 有✅ 有❌整段消失✅ 有模型自述的关键句列出 8 类具体工具“run_code 是唯一可直接调用的工具”泛泛而谈、无具体工具名还误判没有互联网访问标准能力 运行时检查Inspect Provider 插件/bundle 管理三条硬结论都由 Trace 佐证极简模式的薄是断崖式的用量 1.8K vs 8.5~10.2K差 5~6 倍轨迹里连上下文段都没有——因为includeRuntimeContext: false。模型连自己有哪些工具都说不上来。PTC 把呈现方式的变化做到了极致模型自述run_code 是唯一可直接调用的工具。底层工具一个没少diff 只有三行但模型的视角里只有一个入口。能力存在 ≠ 能力以什么形式被看到。创造模式真实暴露了运行时工具模型说自己能查询 Inspect Provider服务方法、事件、配置 Schema、工具 Schema、能管理 profile 的插件与 bundle——这不是提示词里写的话术而是 trace 里可查、源码里可对的真实暴露。技能目录也是可组合项标准/PTC 会话的 skills 清单来自机器上已有的通用技能创造模式会话的清单开头换成了agent-experience、cordis-composition-reference等预设专属技能——同一套技能机制不同 Preset 挂不同的目录。六、实验 2同一任务四条轨迹方法控制变量 每跑复位同一个模型、同一个空工作区、同一句任务指令每跑结束把工作区清空复位保证 4 次运行的初始状态完全一致。观测表观测项标准模式PTC 模式极简模式创造模式模型可见工具形态原生工具逐个调用仅 run_code子工具经程序调用仅持久 pwsh原生工具 运行时工具Model Request 次数4 步4 步5 步6 步工具调用/派发数5 次run_code×3内含 7 次子工具4 次9 次总用量34.1K tok37.4K tok9.4K tok58.9K tok速度222 tok/s239 tok/s206 tok/s235 tok/sSubagent/Workflow 出现否否否否Cordis Runtime 工具暴露否否否是未用但已暴露最终结果文件✅ 行数❌文件✅ 行数❌文件✅ 行数✅文件✅ 行数✅四跑详情每条结论都有三重证据轨迹 用量 文件系统复核① 标准模式列目录 → 并行写 3 个文件 → pwsh 统计 → 总结。产物note-alpha/beta/gamma.txt。它报告27 行9108——实际 41 行151610wc -l 复核❌② PTC 模式全程只发run_code子工具pwsh、cmd、write由程序内部调用。一个细节它前两次列目录被沙箱部分拦截轨迹原文 “File sandbox enforcement is partial on this host”多花一步探查。产物note-1/2/3.txt。报告6 行222——实际 9 行342❌③ 极简模式只有一个持久 pwsh全程用命令行完成Set-Content -Encoding UTF8。报告6 行——实际 6 行✅④ 创造模式列目录 → 写 3 个文件 → pwsh 统计 →read 三个文件交叉验证→ 发现计数不对轨迹原文“它报每文件 2 行而 read 显示为 3/5/2 行”→换[System.IO.File]::ReadAllText 正则重算→ 报告10 行——实际 10 行✅七、那个行数不对是 bug 吗——一个真实的编码陷阱标准/PTC 数错行我一开始以为是 Harness 的问题于是做了复现在同一个文件上Get-Content默认数出 9 行Get-Content -Encoding UTF8数出 15 行wc -l数出 15 行。原因本机没有 PowerShell 7DSH 的 pwsh 工具实际执行的是Windows PowerShell 5.1。它读取UTF-8无 BOM中文文件时默认按 ANSIGBK解码会把一部分字节两两配对成双字节字符顺带吞掉夹在中间的换行符——中文行越多少算越多。所以这不是 DSH 的 bug是一个经典的 Windows 编码坑。而这段插曲反而贡献了实验里最有趣的一组对照标准/PTC 都直接采信了错误计数极简模式因为内容用 ASCII 显式-Encoding UTF8恰好绕开了它自己都没意识到创造模式主动交叉验证发现了不一致并修正——多花了 2 步和约 2 万 token把数数对了。同一个模型、同一个任务仅仅换一套 Harness 组合数得对不对都变了。这是Agent Model × Harness 共同作用最生动的一手证据。八、为什么官方 Benchmark 选 Minimal实验做完之后再来看官方 Benchmark 的设计会特别有感。官方BENCHMARK.md用的是 Python SDK 里jsonrpc-agent 的 Minimal variant并且为不同任务使用独立的 Workspace 和 Session ID。目的只有一个尽量减少额外 Harness 能力对实验的影响让测量更接近模型的基础任务能力。原因就是我们实验 2 里眼睁睁看到的Runtime 里的能力越多变量越复杂——Skills、Planner、Workflow、Subagent、动态 Context 都可能改变模型的执行路径我们的四条轨迹就是活例子步数 4/4/5/6、工具调用 5/7/4/9。变量不固定结果就无法只归因于模型本身。但有一个重要提醒Minimal 下测到的不是纯模型能力。只要模型跑在 Agent Runtime 里结果永远是 Model 与 Harness 共同作用的——同一模型在 Standard 下表现更好提升可能来自更丰富的工具与上下文反过来复杂 Harness 引入多余的工具调用、过量的上下文、更长的执行链性能下降也不能只怪模型。所以评价要分两类类型关注点Model Benchmark模型本身的能力Agent Benchmark模型接入具体 Harness 之后Agent 系统的整体表现“一个模型在纯模型 Benchmark 上很强并不意味着放进任何 Agent Runtime 都同样强。研究 Agent 时除了问用了什么模型”还要继续问“这个模型运行在什么样的 Harness 中它获得了哪些工具、上下文和执行策略”DSH 把 4 套 Preset 预置在脸上恰恰就是把这些原本容易被忽略的 Harness 变量显式暴露出来——这也是我们做这两个实验的全部意义。九、回到源码这 4 套模式是怎么装进会话的实验现象背后的机制源码里写得清清楚楚。打开packages/bundle/web-app/cordis.patch.yml能看到一段注释# ── the agent plane moves behind agent presets ──# Web surface disables them here and lets each session mount a preset instead.# agent 平面搬到 agent preset 之后Web 表层在这里禁用它们# 改为让每个会话自行挂载一个 preset。三个层次的机关Host Plane宿主层整进程一份的共享基础设施Tool Registry、Model Route、持久化、沙箱/审批、子 Agent 注册——在 web patch 里挂载Agent Plane会话层每个会话按所选 Preset 挂载一份子插件树——即上面 4 个 patch 文件的内容组合的叠加Profileweb→ Bundledsh-base、dsh-web-app→ Home patch →--patch覆盖层逐层 patch 成最终插件树。不信可以打印整棵树dsh--profileweb --dump-config我实测输出1263 行、183 条插件并且能清楚看到 4 个 preset 各自作为声明行存在preset-standard/preset-ptc/preset-minimal/preset-cordis文件里还有分层注释标明这一条来自哪一层、被谁改过。所以 4 套 Preset 不是 4 个 Agent而是同一棵运行时树上的 4 种挂载方案——这在实验 1 里的直接体现就是会话间共享同一个模型路由和存储但每个会话的上下文段、工具清单、技能目录都不同。十、结论与心得预期结论在实验里全部复现PTC 只改了呈现模型只见 run_codeMinimal 真的薄无上下文段、1.8K 用量创造模式真的能看运行时。PTC 不是无条件更快本跑 PTC 37.4K tok比标准模式 34.1K 还多——因为沙箱探查多花了步骤。减少 round trip是设计目标不是性能保证收益取决于任务是否适合程序化编排。Minimal 便宜且在本任务里准但有运气成分ASCII 内容恰好躲开编码坑——这正说明官方 Benchmark 选它做基线的意义变量最少最容易把模型本身从Harness 加成里分出来。取证意识是这次实验的最大收获模型自述 ≠ 事实轨迹 用量 文件系统才是证据。这条方法论比任何一个具体结论都值钱。十一、常见问题FAQQ1打开127.0.0.1:3080提示 401A少了启动时打印的?tokenxxx。用终端给出的完整链接访问默认工作区和会话数据都在C:\Users\你\.dsh\。Q2极简模式为什么连上下文都没有A源码里写了includeRuntimeContext: false且不启用压缩。它就是刻意做成Model 极简 Harness的观察基线——少就是它的设计目的不是配置错误。Q3PTC 到底快不快、省不省A不一定。它的设计目标是减少模型与工具的多次往返round trip但收益取决于任务是否适合程序化编排、模型生成代码的质量、工具返回的数据量。我这次实测甚至比标准模式略贵——它是一种更适合批量的工作方式不是性能承诺。Q4为什么数行数三种模式结果不一样A见第七节——PowerShell 5.1 的 GBK 编码陷阱。中文文件 默认Get-Content 少算。写脚本统计时请显式-Encoding UTF8或改用 ASCII 内容或用File.ReadAllText原始层计数。Q5点添加工作区报directoryPicker failed/ 无法打开文件夹A服务端弹原生对话框失败常见于后台/非交互启动的 dsh。用默认工作区做实验或在普通终端重启 dsh 后再添加。Q6我复现出来数值不一样A正常。模型版本、推理等级、机器速度都会影响数值。看差异的方向比如极简模式用量断崖式下降、PTC 模型只见 run_code而不是盯绝对数字。十二、自己复现这两个实验步骤清单装好 dsh第二节任一方式dsh web启动配好模型在默认工作区或任意空目录里做实验别拿生产目录冒险实验 1新建 4 个会话 → 各选一种模式 → 问同一句话 → 打开每个会话的轨迹截图上下文段和用量实验 2确认工作区为空 → 4 个会话各跑一次任务 →跑完清空工作区再跑下一个→ 记录 7 项观测步数、工具调用、token、是否正确并到文件系统里wc -l复核行数对比你的数据和本文数据你的模型/版本不同数值会有差异但差异的方向应该一致。附本文证据截图清单发布/存档时可对照实验 1 创造模式轨迹(Creative轨迹)实验 2 四跑轨迹参考DeepSeek Harness 官方仓库github.com/deepseek-ai/deepseek-harness源码引用基于 v0.2.0-rc.2preset 文件在packages/bundle/web-app/presets/官方 BENCHMARK.md 与 Python SDK 文档Minimal variant 的设计说明官方文档站deepseek-harness.github.io/deepseek-harness/本文全部数据来自作者本机 2026-10-14 的真实运行Windows Node 24 dsh 0.2.0-rc.2 DeepSeek-V4.1-Flash实验工作区每跑后已复位。DSH 迭代很快版本敏感内容请以你安装的版本为准。