DeepSeek Harness发布，爆肝实测一天，夯爆了还是拉完了？ — AI 开发教程

最近两天，AI 开发者圈子里几乎被同一个名字刷屏——DeepSeek Harness，社区里更习惯叫它 dsh。这东西开源才短短 2 天，就拿下了近 100k 个 Star，按这个增速下去，说不定真有机会去追一追 OpenClaw 的 Star 数。但我更关心的不是数字，而是一个问题：DeepSeek 为什么要自己做一套 Harness？它和我用惯的 Claude Code、Codex 有什么本质区别？为了回答这个问题，我爆肝实测了整整一天，从安装、配 Key、选目录、调权限，到盯着任务轨迹看它一步步干活，踩的坑和爽点都记了下来。这篇教程面向刚入门的应用开发者，我会把「一切皆插件」这套设计理念拆开讲，把 dsh web 的完整上手路径一步步走通，也会告诉你哪几个地方最容易把人劝退。看完你至少能独立把 dsh 跑起来，并且知道每个开关背后到底动的是什么。

从「模型是大脑」说起：为什么 DeepSeek 要自己做 Harness

要理解 DeepSeek Harness 的意义，先得把「Harness」这个词讲清楚。很多初学者第一次看到这个词会一头雾水，因为它既不像框架、也不像 SDK。其实可以用一个非常直白的类比：模型是大脑，Harness 就是模型的身体。大脑再聪明，没有手去敲命令、没有眼睛去读文件、没有记忆去记住前面发生了什么，它也只是一个会聊天的思考机器。Harness 要做的，就是把这具身体配齐：给它能调用工具的双手、能读取文件和目录的眼睛、能管理上下文的记忆系统，以及一套约束它行为的护栏。

在这个类比之上，我们把已经熟悉的 Agent 概念重新拆一遍，会得到一个很清爽的公式：Agent = LLM + Harness。这里的 LLM 负责「想」，Harness 负责「做」。想的部分是模型权重里的事，做的部分则是工程的事——工具怎么注册、结果怎么回填、上下文超了怎么压缩、危险操作要不要拦一下。过去我们做 AI 应用开发，绝大部分精力其实都花在「做」这一半，也就是自己写 Harness。这也解释了为什么 dsh 这套框架一出来大家这么兴奋：它把 Harness 这一层直接开源了，还留了足够大的改造口子。

再说 DeepSeek 这次的角色转变。以前我们用 DeepSeek 模型，路径基本是把它接入别人做好的 Agent——不管是开源的 Agent 框架，还是某款 Coding Agent，DeepSeek 在里面扮演的都只是「被调用的那个大脑」，身体是别人给的。模型厂商的处境其实有点被动：自家的模型能力再强，最终跑出来的效果也要受制于宿主 Harness 的工具设计和上下文策略，用户骂卡顿的时候，锅可能根本不在模型身上。这次 DeepSeek 自己下场，做了一套专门给自家模型用的 Agent 框架，等于把「大脑」和「身体」的适配权拿回了自己手里。官方入口就在 https://www.deepseek.com/harness/，从这里进去能看到安装方式和文档。

而它最酷的地方，用五个字就能概括：一切皆插件。这不是一句营销口号，而是一套非常具体的架构决策。在 dsh 里，模型、工具、策略、存储、沙箱、上下文管理，甚至 UI，都被抽象成可以像积木一样拆装的插件。你可以只换工具不动模型，也可以只换上下文策略不动 UI。这种自由度的价值在于：它让「重新组装一个 Agent」变成了一件可配置的事，而不是一次重写工程。对于入门开发者来说，你甚至可以先不写代码，通过配置和组合就理解一个 Agent 的各个组成部件是怎么咬合的。

为了把「一切皆插件」说得更具体，我把它拆成几个可替换的部件维度，对照一下传统做法和 dsh 的思路：

部件维度	传统自建 Harness 的做法	dsh「一切皆插件」的思路
模型（Model）	在代码里硬编码某家 API 和参数	作为可替换插件，换模型不改其他部分
工具（Tool）	手写函数注册表和 JSON Schema	内置 100 多个插件，按需启用或替换
策略（Policy）	权限判断散落在各工具实现里	集中为策略插件，权限档位统一管理
存储（Storage）	自己接数据库或本地文件	抽象为存储插件，实现可换
沙箱（Sandbox）	自己上容器或虚拟机隔离	沙箱能力插件化，隔离强度可调
上下文管理	自己写截断或摘要逻辑	上下文管理插件化，压缩策略可换
UI	自研前端或只提供 CLI	UI 也是插件层，官方直接给了 Web UI

这张表其实回答了一个常见疑问：为什么 dsh 值得单独学一遍，而不是继续用现成 Agent 就好。因为你学到的不只是「怎么用一个工具」，而是「一个 Agent 是由哪些部件拼出来的」。这套心智模型换个框架也一样能用。

dsh web 不是 CLI：一条命令打开 Web UI 的安装路径

接下来进入实操。先说安装，我这次用的是一种比较「AI Native」的方式：能让 AI 动手的就让 AI 动手。我没有去看安装文档一行行敲，而是直接打开我常用的 Agent，把下面这句自然语言提示发给它：

帮我安装 DeepSeek Harness https://www.deepseek.com/harness/

这句话的关键是带上官方链接，让 Agent 自己去读页面上的安装说明，然后决定该执行什么命令。整个过程我大概花了 5 分钟就装好了，中间基本没怎么干预。这个体验本身就挺有象征意义：dsh 的安装可以由另一个 Agent 完成，说明它对外暴露的接口是足够清晰、可被程序理解的。

装完之后，执行下面这条命令：

dsh web

然后浏览器会直接自动打开一个网页。说实话，我一开始是有点懵的。因为在我的预期里，dsh 要么像 Claude Code 那样是个 CLI Coding Agent，要么像 Codex 那样是个桌面端应用，结果它打开的却是一个 Web UI。这一点确实有点出乎意料，也算是 DeepSeek 在交互形态上又创新了一波。

这里有必要把三种形态的差异讲清楚，因为形态直接决定了你能怎么用它、以及它适合谁：

形态	代表	交互入口	上手门槛与适合人群
CLI 命令行	Claude Code	终端里敲命令	门槛偏高，重度开发者顺手
桌面端	Codex	独立 App 窗口	门槛中等，适合习惯图形界面的开发者
Web UI	DeepSeek Harness（dsh web）	浏览器打开的本地页面	门槛较低，页面即工作台，但设置项偏硬核

选 Web UI 有个容易被忽略的好处：它天然适合把「对话历史」「任务区」「任务轨迹」这些信息铺开在同一屏里，信息密度比终端里滚动输出高得多。但它同时也是把双刃剑——页面上的元素一多，初学者反而容易不知道从哪下手。所以下一节我先把最关键的连通性打通。

还有个工程上的小提醒：dsh web 本质上是启动了一个本地服务，浏览器只是个前端外壳。这意味着页面能不能用，取决于背后的 dsh 进程还活着没有。这一点后面我会专门讲一个坑，这里先记下：任务卡住时，第一反应应该是去看终端里的进程，而不是盯着网页上的计时器发呆。

API Key 到手之后：填 Key、充余额、跑通第一次对话

Web 页面打开了，但这时候还没法干活。要让 dsh 真正跑起来，必须按顺序完成下面三步，缺任何一步都跑不通：

去 DeepSeek 官方 API 平台创建一个 API Key。这是 dsh 调用 DeepSeek 模型的身份凭证，没有它就等于大脑没接通。
把 Key 复制粘贴进 dsh 的网页里。页面会提供填写入口，粘贴后保存，dsh 就拿到了调用模型的凭据。
提前往 DeepSeek 账户里充点钱。调用模型消耗的 Token 是需要计费的，余额不足时请求会失败。

我用文字把页面上这几个关键位置描述一下，方便你对照着找：进入 dsh 页面后，左侧是大家很熟悉的对话历史区域；中间是任务区，可以选工作目录和运行模式；填 API Key 的入口就在页面的设置相关区域里。填好 Key 之后，dsh 就可以正常使用了。

这三步里，最容易被忽略的是第三步。很多人 Key 填完就以为万事俱备，结果一发任务就报错，排查半天以为是网络问题，其实是账户余额归零。所以我的建议是：先把充值这件事做完，再去点第一次对话，能省掉很多无谓的自我怀疑。

另外提醒一句，API Key 属于敏感凭据，建议在官方平台上为它设置好权限范围和额度上限，不要随手贴到公开的地方。dsh 把 Key 保存在本地配置里，你要养成不要把配置文件提交到 Git 仓库的习惯——这一点和任何接入第三方模型 API 的项目都一样。

先选工作目录再开口：dsh 的任务区三件套

第一次打开 DeepSeek Harness，我建议先看两个地方，把页面的空间结构记住：左边是对话历史，中间是任务区。任务区里可以做两件最重要的事——选工作目录、选运行模式。这三样东西（历史、目录、模式）构成了 dsh 的基本操作框架，我把它叫「任务区三件套」。

这里有个硬性前提必须强调：dsh 必须先选择一个工作文件夹，才能进行对话。也就是说，它不像普通聊天机器人那样打开就能问。这个设计其实是 Harness 的本质决定的：Agent 要有「身体」，身体得有活动范围，工作目录就是它手脚能够触及的那片地。你不对它指定范围，它就不知道该在哪儿读文件、在哪儿写文件。

正确的顺序是这样的：

先在电脑上新建一个工作目录，比如给这次任务单独建一个文件夹，避免污染主项目；
再在 dsh 的任务区里让 dsh 打开这个目录；
目录加载完成后，才开始正常对话、发起任务。

如果你是从命令行环境过来的，用下面这段命令准备一个干净的工作目录会比较顺手：

mkdir -p ~/workspace/dsh-demo && cd ~/workspace/dsh-demo
git init
echo "# dsh demo workspace" > README.md
git add . && git commit -m "chore: init dsh demo workspace"

这么做的理由很实在：一是把试验环境和真实项目隔离开，就算 Agent 误改了文件，损失也可控；二是提前 git init 之后，任何改动都能用 git diff 追回来，等于给 Agent 的操作上了一层可回滚的安全垫。等到你对 dsh 的行为足够熟悉、足够放心了，再让它直接开你的主项目也不迟。

顺带说一下，任务执行完之后，dsh 会把本次任务的 Token 消耗和缓存命中等信息列出来。这个反馈闭环很重要，它让你能直观看到「这一次想法值多少钱」，也能帮你判断是不是上下文膨胀得太厉害导致缓存命中变低、花费变高。养成每次任务后扫一眼这些数字的习惯，比事后翻账单有用得多。而且它不只是给汇总，还会展示本次任务的完整轨迹，可以回看它到底是怎么一步步干活的——模型收到了什么提示词、调用了哪些工具、改了什么文件、怎么压缩上下文，全都留在里面。对想学习 Agent 执行过程的人来说，这基本等于浏览器开发者工具里的请求追踪，只不过追踪对象换成了 Agent 的思考与行动。

权限三档怎么选：Read Only / Workspace Write / Full Access

工作目录选好之后，紧接着就要面对对话框左下角的权限控制。这三档权限决定了 dsh 到底能不能动你的文件，是安全性上最关键的一个开关，务必看懂再动。

我把三个档位的边界逐个拆开：

权限档位	能做什么	越界时会发生什么	推荐使用场景
Read Only（只读）	默认只能读文件，不能修改	任何写操作都被拦下	只想让它看看代码、做代码审阅或答疑
Workspace Write（工作区写入）	可以修改当前工作目录里的文件	遇到超出工作目录范围的操作，会先问你一声	日常最常用的一档，改项目首选
Full Access（完全访问）	工作目录内外的文件都能改	不再弹出确认，直接执行	仅在你完全清楚它接下来要做什么时使用

这么一对比就很清楚了：Read Only 适合「看了再说」的探索型任务，比如让它读一遍代码库、帮你定位某个函数在哪；Workspace Write 是平时最常用的一档，它能帮你直接修改项目文件，同时保留了越界询问这道闸门，安全感比较足；Full Access 就相当于把护栏拆了，工作目录内外的文件它都能改，而且不会再弹确认。

关于 Full Access，我的态度很明确：这个权限别随手开。只有当你能清楚预判它接下来要做什么、并且已经做好了备份或版本控制保护时，才考虑切到这一档。原因很简单——dsh 的强项是自主执行，自主执行一旦配合「无确认 + 全盘可写」，出错时你连提醒的机会都没有。对入门者来说，绝大多数任务停在 Workspace Write 就足够了，需要读目录外的文件时再临时调整，而不是一上来就全放开。

除了权限，对话框右下角还能选择 DeepSeek 模型和推理等级，我在页面上看到的默认选项有 DeepSeek V4 Pro 和 DeepSeek V4 Flash。同时任务区还多了一组运行模式的选择。这些模式的名字听起来唬人，但四种模式的区别其实没那么复杂，我先把它们和权限的关系理一下，方便你建立整体认知：

标准模式：平时用这一档就够了。看文件、改代码、跑命令、查资料、调用 Skills、安排子 Agent，这些常见操作它都能做。
PTC 模式：适合步骤多、流程长的任务。它拥有标准模式的全部能力，区别是会把多次工具操作写成一段 TypeScript 程序再串起来执行。
极简模式：只给模型留下两件基础工具，一个执行 Bash 命令，一个修改文件，其他能力全部拿掉。
创造模式：给想自己定制 Agent 的人准备的，可以查看当前运行环境、试验不同插件，再把需要的工具和能力组合成一套新的 Agent 模式。

这里面最值得展开的是 PTC 模式，因为它体现了 dsh 在上下文管理上的一个巧妙设计。普通模式下，模型每调用一次工具，结果都要作为新一轮输入塞回模型，来回沟通次数一多，上下文就容易被撑大，既费 Token 又容易丢重点。PTC 模式的做法是：把多次工具操作写成一段 TypeScript 程序再串起来执行，这样中间数据不用一轮轮塞回模型，最后只把结果送回上下文。碰到工具调用特别多的任务，既能少几次来回沟通，也不容易把上下文越撑越大。比如批量处理文件、连续查询数据，或者跑一整套操作流程，用这个模式会更合适。

用个具体的对比来感受一下两种模式的差别。假设任务是对一个目录下的一批文件做统一处理，标准模式下的路径大致是「调一次工具 → 结果回模型 → 再调一次 → 再回模型」，循环往复；而 PTC 模式更接近下面这种把多步串成一段程序的形态：

// PTC 模式的思路示意：把多次工具操作串成一段程序统一执行
// 中间结果留在程序内部，只把最终结果回填上下文
type Step = { name: string; run: () => Promise<unknown> };

async function runPipeline(steps: Step[]) {
  const results: Record<string, unknown> = {};
  for (const step of steps) {
    // 每一步在程序内完成，不逐条回灌模型上下文
    results[step.name] = await step.run();
  }
  // 只把汇总后的结果送回上下文
  return results;
}

// 使用示例
export async function main() {
  const steps: Step[] = [
    { name: "scan", run: async () => "扫描目标目录文件列表" },
    { name: "filter", run: async () => "筛出需要处理的文件" },
    { name: "transform", run: async () => "批量执行转换操作" },
    { name: "summary", run: async () => "生成处理结果汇总" },
  ];
  const out = await runPipeline(steps);
  console.log(out);
}

main();

这段代码不是 dsh 的内部实现，而是帮你理解 PTC「把多步工具操作收敛成一段程序」的思维模型。关键点在于中间结果的处理位置：它在程序内部流转，而不是在模型和工具之间来回搬运。理解了这一点，你就能判断什么任务该切 PTC、什么任务留在标准模式就好。

至于极简模式，它更像是给模型做「裸机测试」——只靠命令行和文件编辑两件工具，看看模型到底能做到什么程度。日常使用不用特意选它，但如果你想观察模型的「基础体力」，这个模式很有意思。创造模式则是留给定制派的，前面三种模式是拿来干活的，这一种是拿来「造模式」的。如果你想配置插件，可以去设置页面里找，目前官方内置插件已经有 100 多个，后续数量还会继续增加。

最后再回到那个我实测踩到的坑，因为它和权限、模式一样属于「不看就会中招」的类型。如果发现 dsh 卡在某个任务上很久，先别傻等，最好打开终端看一眼，确认 dsh web 到底还在不在运行。我当时就踩过这个坑：明明已经把 dsh web 进程关掉了，但页面里的「Deep diving」还在继续计时，看起来就像 DeepSeek 还在后台疯狂思考，极具迷惑性。也就是说，你看到页面上的时间一直增加，不一定代表任务还活着。这个体验就挺割裂的。解决办法很简单——把「看终端进程状态」作为排查第一步，而不是盯着网页计时器。

权限搞清楚、模式选明白、进程状态会看，到这里你其实已经能把 dsh 跑起来并完成一轮真实任务了。但真正让这套框架区别于其他 Agent 的，是它在一轮任务背后留下的那些可观测信息：完整的执行轨迹、Token 消耗分布、上下文压缩过程。这些信息怎么读、读出来能解决什么问题，以及我用 dsh + DeepSeek V4 Pro 跑出来的实际效果到底「夯爆了还是拉完了」——我们放到下一部分继续拆。

上一段我们把 dsh 从安装到 API Key 配置、工作目录选择、权限三档（Read Only / Workspace Write / Full Access）全部走了一遍，你应该已经能在浏览器里正常发起任务了。但真正决定「同一个模型为什么有人跑得又快又省、有人却一直烧 Token」的，其实是接下来这两组开关：模型与推理等级，以及运行模式。这一段我们就一个一个掰开讲。

模型与推理等级：DeepSeek V4 Pro 与 V4 Flash 怎么挑

在 dsh 的对话框右下角，有两个联动下拉框：一个是模型选择，一个是推理等级。素材里明确提到，页面上默认可见的模型选项是 DeepSeek V4 Pro 和 DeepSeek V4 Flash 两个。这两个名字不是随便起的，它们的定位差异非常大，用错了代价也很直接——要么慢，要么贵，要么答不准。

先讲清楚一个前提：模型是大脑，Harness 是身体。dsh 改变不了 V4 Pro 和 V4 Flash 这两个「大脑」本身的参数规模与训练方式，它做的是把身体搭好，让大脑能用上工具。所以你选的模型，是本次任务智力上限的天花板；你选的模式，是本次任务身体能做出多少动作的上限。这两个维度是乘法关系，不是替代关系。

那具体怎么挑？我按最常见的几类场景拆一下：

DeepSeek V4 Pro：能力更强，适合需要多步推理、跨文件理解、复杂重构、排查疑难 bug 的任务。实测中我所有偏「深水区」的测试都是跑在 V4 Pro 上——因为它能把上下文里的多条线索串起来，不容易在中途跑偏。
DeepSeek V4 Flash：响应更快，适合那些「我知道要干什么，只需要它快速执行」的任务。比如批量改一批文件的命名、把一段确定的逻辑套用格式、跑一条你已经想清楚的命令、整理一段已知结构的数据。

至于推理等级，它控制的是模型在给出答案前「想多久」。等级越高，模型在内部展开的推理步骤越多，适合难题；等级越低，直接吐答案越快，适合简单任务。工程上最容易犯的错，是用 Pro + 高推理等级去干一件 Flash + 低等级就能秒完的事，结果是钱花了好几倍，速度还慢半拍。

我整理了一张选择对照表，可以直接照着选：

任务特征	推荐模型	推荐推理等级	理由
单文件小改动、命名替换、格式化	V4 Flash	低	任务确定、步骤短，不需要长推理
批量文件处理、连续数据查询	V4 Flash 或 V4 Pro	中	配合 PTC 模式把多步工具操作压成一段程序
跨文件重构、架构级改动	V4 Pro	中到高	需要理解全局依赖关系，Flash 容易只看局部
疑难 bug 定位、日志反推根因	V4 Pro	高	线索散落在多处，需要长链条推理
观察模型「裸能力」下限	V4 Pro	按需	配合极简模式做对照实验

这里要额外提醒一句：模型选择不是一次性设置。同一个会话里你完全可以先用 V4 Pro 读代码、理清思路，再切到 V4 Flash 做后续的重复劳动。这比从头到尾用一个模型更经济。反过来，如果你一开始用 Flash 发现它反复改错文件、来回打转，别硬撑，切到 Pro 重开一次，浪费的时间比省下的 Token 更贵。

顺便说一下，Token 消耗和缓存命中情况，dsh 会在任务结束后列出来。这个数据非常关键——它是你判断「我这次模型选对了没有」的唯一客观依据。如果你发现某次任务缓存命中低得离谱、Token 消耗却很高，通常说明你的对话上下文被频繁重写了，这时候要么换模式，要么把任务拆小。

标准模式：看文件、改代码、跑命令、调 Skills 的默认档

权限解决的是「能不能动你的文件」，模式解决的是「它以什么姿势干活」。dsh 给的运行模式不止一个，但如果你只想记住一个，那就是标准模式。

标准模式覆盖的操作集合，按素材里的描述可以归纳成这几类：

看文件：读取工作目录里的源码、配置、文档，建立对项目的理解。
改代码：直接编辑文件内容，落地具体改动。
跑命令：执行 shell 命令，比如跑测试、跑构建、装依赖、看进程状态。
查资料：检索外部信息来补充上下文。
调用 Skills：把预置的技能作为工具来用，扩展它的能力边界。
安排子 Agent：也就是子 Agent 编排，把一个大任务拆成若干小任务分发出去。

判断标准非常直白：如果你只是想让 dsh 完成一个正常的开发任务，直接选标准模式。读代码、改 bug、跑命令验证、装依赖、调技能、拆子任务，这些常见动作它全都在能力范围内，不需要你再额外配置什么。

标准模式为什么能成为默认档？核心在于它是「能力全覆盖、行为可预期」的那一档。它不像极简模式那样刻意砍掉工具，也不像 PTC 模式那样把执行方式改写成程序，它的交互节奏就是最符合直觉的那一种：模型思考一步，调用一次工具，看结果，再思考下一步。

这个节奏的代价是：每一步的中间结果都要回灌进模型上下文。任务步数一多，上下文就会像滚雪球一样变大，既拉高 Token 消耗，也更容易触发上下文压缩，压缩过程中还有可能丢掉关键信息。所以标准模式最舒服的区间，是「步骤适中、需要模型随时根据中间结果调整策略」的任务。

给你一个可以直接粘贴运行的例子，用来看标准模式下 dsh 的典型工作流——它会在你指定的工作目录里读文件、跑命令、再改文件。先建一个工作目录，写一个带 bug 的脚本：

mkdir -p ~/dsh-demo && cd ~/dsh-demo
cat > stats.py << 'EOF'
def average(nums):
    total = 0
    for n in nums:
        total += n
    return total / len(nums)

if __name__ == "__main__":
    print(average([10, 20, 30]))
    print(average([]))
EOF
python3 stats.py

跑一下你就会发现第二行直接抛 ZeroDivisionError，因为空列表做除法。这时候在 dsh 里把工作目录指向 ~/dsh-demo，权限选 Workspace Write，模式选 标准模式，然后给它一句足够明确的指令：

请阅读 stats.py，跑一遍确认它的报错原因，
给出修复方案并直接修改文件：当输入为空列表时返回 0，
最后重新运行一次确认两条输出都正常。

你会看到它按「读文件 → 跑命令复现错误 → 修改文件 → 再跑命令验证」的顺序走完整流程。任务结束后，右下角会列出本次的 Token 消耗与缓存命中信息。这种任务就是标准模式的甜区：步骤不多，但每一步都需要看到结果再决定下一步。

有一个工程细节值得注意：在标准模式下，把你的验收标准写进提示词能显著减少来回。上面那句「最后重新运行一次确认两条输出都正常」就是验收标准。dsh 拿到明确标准后，会自己完成自检闭环，而不是改完就停在那里等你反馈。

PTC 模式：把多次工具调用写成一段 TypeScript 再执行

PTC 模式是全篇最值得花时间理解的一档。先说结论：它拥有标准模式的全部能力，两者在「能做什么」上没有差距，差距在「怎么做」。

标准模式的执行循环是：模型思考 → 调用工具 A → 结果回灌模型 → 模型思考 → 调用工具 B → 结果回灌模型……每一步的中间结果都要塞回上下文。PTC 模式则换了一条路：它把多次工具操作写成一段 TypeScript 程序，然后串起来执行。中间数据不需要一轮一轮塞回模型，程序跑完之后，只把最终结果送回上下文。

这个差异带来的好处非常实在：

少几次来回沟通：原本需要 N 轮「模型—工具—模型」的往返，被压缩成一次程序执行。
上下文不容易被撑大：中间过程留在程序内部，不进模型上下文，也就不容易触发压缩、不容易丢信息。
执行更稳定：批量操作写进代码里，顺序和条件都是确定的，不会因为某一轮模型的随机判断而跑偏。

素材里点名的典型场景是批量处理文件、连续查询数据，或者跑一整套操作流程。这三类任务的共同点是：工具调用次数多，但每一步的逻辑本身并不需要模型反复决策。把它们交给标准模式，模型会因为中间结果不断进入上下文而被干扰；交给 PTC 模式，模型只需要在开头把程序写好，剩下交给确定性执行。

给一个对比表，把两者的机制差异摊开看：

维度	标准模式	PTC 模式
能力集合	看文件、改代码、跑命令、查资料、调 Skills、子 Agent	与标准模式完全相同
执行形态	一次工具调用一轮往返	把多步操作编译成一段 TypeScript 串行执行
中间结果去向	逐轮回灌模型上下文	留在程序内部，不回灌，只回传最终结果
上下文压力	随工具调用次数增长	显著更低
适合任务	需要边看结果边调整策略	批量文件处理、连续查询、整套流程执行

下面是一个可直接粘贴运行的例子。假设你有一个目录里塞了几百个日志文件，想把它们统一清洗、按日期归类。用标准模式，这会产生几百轮工具调用来回；用 PTC 模式，你只需要把这段 TypeScript 脚本的意图交给它，它会负责把多步操作串起来执行，最后只把「处理了多少个文件、归到哪几个目录」这样的汇总结果带回上下文：

import { readdir, readFile, mkdir, writeFile } from "fs/promises";
import { join } from "path";

const SRC = "./logs";
const OUT = "./logs-cleaned";

async function main() {
  await mkdir(OUT, { recursive: true });
  const files = await readdir(SRC);
  let moved = 0;

  for (const f of files) {
    if (!f.endsWith(".log")) continue;
    const raw = await readFile(join(SRC, f), "utf8");
    // 去掉空行与行首时间戳噪声
    const cleaned = raw
      .split("\n")
      .filter((line) => line.trim().length > 0)
      .filter((line) => !/^\d{4}-\d{2}-\d{2}/.test(line))
      .join("\n");
    // 按文件名里的日期前缀归类到子目录
    const date = f.slice(0, 10);
    const dir = join(OUT, date);
    await mkdir(dir, { recursive: true });
    await writeFile(join(dir, f), cleaned, "utf8");
    moved++;
  }
  return { moved, out: OUT };
}

main().then((r) => console.log(JSON.stringify(r)));

注意这段代码的关键点：整个循环里的 readFile / mkdir / writeFile 都在程序内部完成，模型全程不需要看到每一个文件的内容。它最后拿到的只有 {"moved": 312, "out": "./logs-cleaned"} 这样一行汇总。这就是 PTC 省 Token 的根本原理——把「过程」留在程序里，只把「结果」带回上下文。

什么时候不该用 PTC？如果任务本身需要模型根据中间结果做判断——比如「先看看测试挂在哪，再决定改哪块代码」——那标准模式更合适。因为 PTC 的前提是你在动手前就能把步骤写清楚；写不清楚的任务，硬套 PTC 反而会得到一个跑完才发现逻辑错的程序。

极简模式：只留 Bash 执行与文件修改两件工具

极简模式的定位和前面几种完全不同。它只给模型留两件基础工具：一个用来执行 Bash 命令，一个用来修改文件，其他能力全部拿掉。没有 Skills，没有子 Agent，没有额外的查资料工具，什么都没有。

为什么要做这么一档？素材的说法是，它更像给模型做「裸机测试」——适合观察模型只靠命令行和文件编辑能做到什么程度。换句话说，前面几种模式考验的是「Harness 这套身体搭得好不好」，极简模式考验的是「这个大脑本身有多强」。

它不适合日常使用，这点素材讲得很明确。日常开发的绝大多数任务，你都不应该选它，因为你会白白损失 Skills、子 Agent 编排这些已经帮你省事的能力。它的价值在实验场景：

想知道 V4 Pro 和 V4 Flash 在「只有命令行 + 文件编辑」条件下差距多大，用极简模式跑同一组任务做对照。
想验证某个问题是模型能力不足，还是 Harness 的工具设计拖了后腿。把能力砍到最少，如果问题依旧，锅就在模型那边。
想研究 Agent 的最小执行循环长什么样，极简模式给出的就是最朴素的那个版本。

有一个容易踩的坑：在极简模式下，模型能用 Bash 和文件编辑达成很多事，但它的每一步都需要自己用命令行拼出来。这意味着它对命令的依赖度极高，稍复杂的操作就会变成一长串 shell 拼接，出错概率相应上升。这不是 bug，而是你主动选择「裸机」的必然代价。所以做实验时，建议把任务拆小，一次只观察一个变量，否则结果很难归因。

创造模式：查看运行环境、试插件、拼出你自己的 Agent 模式

如果说标准、PTC、极简这三种是拿来干活的，那创造模式就是拿来「造模式」的。它给想自己定制 Agent 的人准备。

创造模式里你能做三件事：

查看 dsh 当前的运行环境：搞清楚当前这套 Harness 到底加载了什么、能访问什么。
试验不同插件：素材里提到，官方内置插件目前已经有一百多个，后续数量还会继续增加。这些插件可以在创造模式里逐个试。
把需要的工具和能力组合成一套新的 Agent 模式：试出来哪些插件好用、哪些组合有效之后，把它们拼装起来，形成属于你自己的模式。

这一步要放在「一切皆插件」这个设计理念下来理解。dsh 把模型、工具、策略、存储、沙箱、上下文管理和 UI 这些能力都做成了像积木一样可拆装的东西。创造模式，就是给你一个拼积木的工作台。前面三种模式本质上是官方预先拼好的三套积木方案；创造模式则把积木倒在你面前，让你自己拼。

想配置插件，可以去设置页面里找。一个建议是：不要一上来就堆插件。每多挂一个插件，模型看到的可用工具就多一分，选择成本也随之上升。先用标准模式摸清一个任务真正需要哪几种能力，再回到创造模式里做减法而不是加法——只挂真正用得上的那几个，拼出来的模式往往比堆满插件的更稳。

创造模式还有一个隐性价值：它是理解「一切皆插件」最快的入口。你在标准模式下看到的所有行为——包括上下文怎么压缩、工具怎么被调用——在创造模式里都能找到对应的可配置项。如果你打算长期用 dsh，这一块迟早要摸。

总结与最佳实践

把这一段的要点压缩成一份可以直接照着执行的清单：

先定权限，再定模式。只想让它看代码用 Read Only；常规改项目用 Workspace Write；Full Access 只在完全清楚它要做什么时才开。
模型按任务难度选。单文件小改、命名替换、格式化用 V4 Flash；跨文件重构、疑难 bug 定位用 V4 Pro；同一会话中可以中途切换，前半段用 Pro 理思路，后半段用 Flash 做重复劳动。
推理等级不要一律拉满。任务越确定，等级越低；只有线索分散、需要长链条推理时才调高。
普通开发任务直接用标准模式。它覆盖看文件、改代码、跑命令、查资料、调 Skills、子 Agent 编排，是最贴合直觉的默认档。
把验收标准写进提示词。例如「最后重新运行一次确认两条输出都正常」，让 dsh 自己完成自检闭环，能显著减少来回沟通。
工具调用多、步骤长的任务改用 PTC 模式。批量文件处理、连续查询数据、整套流程执行，都适合把多步操作编译成一段 TypeScript 串行跑，中间数据不回灌模型，只回传最终结果，上下文压力显著更低。
需要边看结果边改策略的任务，继续用标准模式。写不清楚步骤的任务硬套 PTC，只会得到一个跑完才发现逻辑错的程序。
极简模式只用于观察模型下限。它只留 Bash 执行与文件修改两件工具，是「裸机测试」，不要拿来做日常开发。
创造模式用来拼自己的模式。在里面查看 dsh 运行环境、试插件（官方内置已有一百多个，还在增加），再把能力重新组合成新模式；拼的时候做减法，别堆满插件。
每次任务结束后看 Token 消耗与缓存命中。这是判断模型和模式选得对不对的唯一客观依据；命中低、消耗高，通常意味着上下文被频繁重写，考虑换模式或拆小任务。
用「轨迹」复盘执行过程。模型收到什么提示词、调用了哪些工具、改了什么文件、怎么压缩上下文，都能顺着轨迹往回找，哪一步出错、Token 花在哪都能定位。

把这几件事做对，同一个 V4 Pro 在你手里和在新手手里，跑出来的效率差距会是数量级的。下一段我们进入真实任务的实测环节，看看这些模式组合在实际工程里到底表现如何，以及那个「关掉进程页面还在计时」的坑该怎么避开。

上一段我们把 DeepSeek Harness 的定位、安装路径、权限档位和四种运行模式都拆了一遍，也聊了它到底适合谁、不适合谁。这一段我们继续往深处走：聊聊「一切皆插件」背后的可拆装结构、任务轨迹该怎么读、Token 账单怎么对、踩坑清单怎么排，最后给出一套可以直接照着做的实践清单。

100+ 内置插件与「一切皆插件」：模型、工具、策略、存储、沙箱、上下文、UI 全可拆装

先说最容易被人忽略、但其实最能决定 DeepSeek Harness 天花板的一件事：它的设计理念只有五个字——一切皆插件。这五个字听起来像营销口号，但落到工程上，它意味着 dsh 里几乎所有你能看到、能调用的东西，都是可替换的积木。

如果你之前用过 Claude Code、Codex 这类工具，会发现它们大多把「模型接入」「工具调用」「上下文管理」这几个环节焊死在一套固定流程里，你只能在有限的配置项里做取舍。dsh 走的是另一条路：它把一整条 Agent 流水线拆成若干类可替换组件，每一类都有自己的插件位。

具体拆到什么粒度？结合实测的页面结构和素材信息，可以这样归纳：

模型（Model）：底层用哪个 DeepSeek 模型，由插件层决定。页面上默认能选到 DeepSeek V4 Pro 和 DeepSeek V4 Flash，这只是当前内置选项，模型侧本身是插件位。
工具（Tool）：模型能调用哪些能力，比如读写文件、执行命令、查资料、调 Skills，都挂在工具插件上。极简模式之所以能只留下 Bash + 文件修改两件工具，正是因为工具本身就是可以整体抽掉的积木。
策略（Policy）：包括权限档位、运行模式这类「决策规则」。Read Only / Workspace Write / Full Access 三档权限，以及标准 / PTC / 极简 / 创造四种模式，本质是不同的策略组合。
存储（Storage）：对话历史、任务记录、执行轨迹这些数据的落盘方式，同样属于插件位，可以按需替换。
沙箱（Sandbox）：模型执行代码和命令时的隔离环境，也是可拆装的，决定了它能碰哪些文件、能跑什么命令。
上下文管理（Context）：提示词怎么组装、上下文何时压缩、压缩后保留什么，这一整套逻辑也是插件化的，后面读轨迹时会特别明显地看到它的痕迹。
UI：最外层那套 Web 界面，也属于插件范畴。这也是为什么 dsh 打开的形态是 Web UI，而不是像 Claude Code 那样偏 CLI，也不是 Codex 那种桌面形态——界面本身就是组装出来的一层壳，DeepSeek 在这一轮做了一次形态上的选择。

理解这张清单之后，你就能明白为什么 dsh 敢说「自由度很高」：它不是给你一个固定 Agent，而是给你一套 Agent 装配线。你想换模型、换工具组合、换上下文策略，本质是在换插件，而不是在改源码。

那这些插件去哪儿看、去哪儿配？答案是设置页面。素材里提到的一个关键数字是：目前官方内置插件已经有 100 多个，而且后续数量还会继续增加。这个数字的意义不在于「多」，而在于它已经跨过了「开箱够用」的门槛——你不必一上来就自己写插件，光靠内置的 100 多个，就足以拼出相当多不同的 Agent 形态。

为了把「同一套底座、不同插件组合」这件事讲清楚，我把四种运行模式和它们对应的插件取舍整理成一张表：

运行模式	工具插件保留范围	上下文与执行特征	典型适用场景	是否适合日常
标准模式	看文件、改代码、跑命令、查资料、调用 Skills、安排子 Agent	常规工具调用，一轮轮与模型交互	正常开发任务，日常主力档	适合，默认首选
PTC 模式	拥有标准模式全部能力	把多次工具操作写成一段 TypeScript 程序再串起来执行，中间数据不回塞模型，只把结果送回上下文	步骤多、流程长、工具调用密集的任务，如批量处理文件、连续查询数据	适合特定重流程任务
极简模式	只留两件基础工具：一个执行 Bash、一个修改文件，其他能力全部拿掉	近似「裸机测试」，只靠命令行与文件编辑	观察模型在最小能力集下的表现	不适合，日常不用特意选
创造模式	开放运行环境查看、插件试验、工具组合	面向「造模式」本身，可组合出新的 Agent 模式	自定义 Agent 的人，试验不同插件	面向定制，不面向干活

这张表里最值得多看一眼的是 PTC 模式。它和标准模式的区别不在「能不能干」，而在「怎么干」：标准模式下，模型调一次工具、拿一次结果、再想下一步，中间数据会一轮轮塞回上下文；PTC 模式则把多次工具操作先写成一段 TypeScript 程序，串起来执行，中间数据不来回搬运，最后只把结果送回上下文。这个设计的直接好处有两个：一是少几次来回沟通，二是不容易把上下文越撑越大。对批量处理文件、连续查询数据、跑一整套操作流程这类任务，效果尤其明显。

如果你已经装好 dsh，想亲眼看看插件位长什么样，可以直接在终端里执行下面这段命令，把 dsh 的安装目录结构列出来，对照着找插件相关目录：

# 查看 dsh 全局安装位置与插件目录结构
# 第 1 步：确认 dsh 命令本身是否可用
dsh --version

# 第 2 步：列出全局 npm 包目录下 dsh 的安装路径
npm ls -g --depth=0 | grep -i dsh

# 第 3 步：进入 dsh 包目录，翻出插件与配置相关文件夹
# 注意把 <你的全局 node_modules 路径> 替换成上一步输出的真实路径
ls -la <你的全局 node_modules 路径>/deepseek-harness

# 第 4 步：查看包内是否有 plugins / skills / policies 之类目录
find <你的全局 node_modules 路径>/deepseek-harness -maxdepth 2 -type d | sort

跑完这几条，你基本能把「插件到底装在哪一层」这件事摸清楚。点开设置页面配合看，就能对上号：页面上看到的模型下拉、模式选择、权限档，背后都对应着某一类插件配置。

还有一个细节值得强调：能让 AI 动手的就让 AI 动手。素材里给出的安装方式本身就体现了这个思路——直接在常用的 Agent 里发一句话，让它去装：

帮我安装 DeepSeek Harness https://www.deepseek.com/harness/

实测下来，大概 5 分钟就装好了。装完之后执行 dsh web，浏览器会直接打开 Web UI。这里有个很多人第一反应都会愣一下的点：本以为 dsh 会像 Claude Code 那样是 CLI Coding Agent，或者像 Codex 那样是桌面 Agent，结果它给了一个 Web UI。这不是随便选的形态，而是「UI 也是插件」这个理念的自然结果——既然界面能拆装，那它当然可以选择以网页这一层壳出现。

接下来的初始化动作也很简单：去 DeepSeek 官方 API 平台创建一个 API Key，把 Key 复制进 dsh 网页填好，就能正常用了。唯一要提前留意的是，使用前记得先往 DeepSeek 账户里充点钱，调用模型消耗的 Token 是需要计费的。这一点跟后面要讲的「账单视图」直接相关。

任务轨迹怎么读：提示词、工具调用、文件改动、上下文压缩全留痕

如果只能从 dsh 里挑一个功能推荐给想学 Agent 的人，我会选任务轨迹。

先说它长什么样、为什么好读。素材里的类比非常准确：它有点像浏览器开发者工具里的请求追踪。你在 DevTools 的 Network 面板里看一次页面加载，能看到每个请求的发起时间、参数、响应、耗时；轨迹面板给你的，是 Agent 执行一次任务的同款视角——只不过被追踪的对象从 HTTP 请求换成了模型的每一步动作。

关键在于，轨迹记录的不只是最后的聊天内容。这一点很多人第一次用会低估它。它真正留下的东西包括：

模型收到了什么提示词：也就是每一轮送进模型的完整输入，包含系统级提示、上下文拼装结果、当前任务描述。
调用了哪些工具：每一步选了哪个工具、传了什么参数。
改了哪些文件：写操作落在哪个路径、动了哪部分内容。
怎么压缩上下文：上下文在什么节点被压缩、压缩后保留了哪些信息。

把这四类信息串起来看，等于给整条执行链路装了一层可回放的日志。于是两个最让人头疼的问题就都有了解法：哪一步出错了，顺着轨迹往回找；Token 花在哪里了，同样顺着轨迹往回找。素材里的原话说得很到位——基本都能顺着轨迹往回查。

那实际操作中该怎么读一条轨迹？我把它拆成一套四步法，按顺序走基本不会迷路：

先定位失败点，再看成功路径。任务失败了，别从头读到尾，先找最后一步报错或产物不对的位置，锁定节点之后再往上看它的输入是哪来的。
看提示词拼装。同一个工具调用失败，往往不是模型不行，而是它这一轮拿到的提示词里缺了关键信息。核对送进模型的完整输入，能快速判断是「模型判断失误」还是「上下文没喂到」。
看工具参数。文件路径写错、命令参数拼错，这类低级但高频的问题，在工具调用节点上一眼就能看出来。
看上下文压缩节点。长任务里最容易出玄学问题的地方就在压缩附近：压缩前模型还记得的信息，压缩后可能就丢了。如果任务在某个节点之后突然「失忆」，优先怀疑这里。

为了让这套读法更具体，我把它和浏览器 DevTools 的追踪能力做个对照，顺便把「轨迹里有什么字段」这件事说清楚：

对照维度	浏览器 DevTools 请求追踪	DeepSeek Harness 任务轨迹
被追踪对象	HTTP 请求 / 响应	模型每一轮的提示词、工具调用、文件改动
核心用途	定位接口报错、性能瓶颈	定位执行出错步骤、Token 去向
是否含最终产物	含响应体	不只是最后聊天内容，还含中间过程
关键记录项	URL、Method、Headers、Payload、Status、Timing	提示词、工具名与参数、文件改动、上下文压缩记录
典型排查场景	接口 500、请求超时	任务卡死、结果不对、Token 异常偏高
学习价值	理解前后端交互	理解 Agent 执行逻辑与工具调用顺序

对想学 Agent 执行过程的同学来说，这张表的右列其实就是一份现成的教材。模型收到什么、怎么决定、调了什么、改了什么、怎么压缩，全部留痕。你看得多了，自然会对「Agent 为什么这么干」形成直觉，这比只看最终回答要值钱得多。

这里再补一个工程上的实用建议：把轨迹当回归测试用。同一个任务，今天跑一遍、明天改了插件或换了模式再跑一遍，对比两条轨迹，能非常直观地看出「是插件变了导致行为变了，还是模型本身波动」。这在调试自定义插件时特别有用——你总得有个能对照的基线。

Token 消耗与缓存命中：每次任务结束后的账单视图

轨迹解决的是「怎么跑的」，账单视图解决的是「花了多少」。这两件事在 dsh 里是分开呈现的，但应该连着看。

素材里明确提到的一点是：任务执行之后，dsh 会把本次任务的 Token 消耗和缓存命中等信息列出来。这是每次任务结束后自动给的一份账单，不用你额外去 API 平台翻记录。

别小看这份账单。它出现的时机很妙——正好是你对这次任务印象最深的时候。你可以立刻把三件事对上：

消耗了多少 Token：本次任务整体用量。
缓存命中情况：有多少输入是命中缓存复用的。命中部分和未命中部分在成本上差别很大，所以这个数字直接决定你这次任务贵不贵。
任务复杂度是否匹配成本：一个看起来很简单的小任务，如果 Token 消耗异常高，通常意味着上下文被反复搬运、或者压缩策略没生效。

而这份账单和上一节的轨迹是能互相印证的。如果你发现某次任务 Token 消耗偏高，别干瞪眼，回到轨迹里找：是不是同一份内容被反复塞进上下文？是不是压缩节点来得太晚？是不是某个工具调用循环了好几轮？这些在轨迹里都有痕迹。

这也是为什么前面讲 PTC 模式时要特别强调「中间数据不用一轮轮塞回模型」。从账单的视角看，PTC 模式的价值不只是「少几次来回沟通」，更是直接把 Token 花在结果上，而不是花在中间搬运上。对工具调用密集的长流程任务，这个差别会实打实地体现在账单里。

另外提醒一句和钱直接相关的：使用前记得先往 DeepSeek 账户里充点钱，Token 消耗是计费的。这不是可选项，是前置条件。账单视图能帮你建立成本感知，但账户余额该充还得充。

卡住不动先别等：dsh web 进程与「Deep diving」计时不一致的排查清单

接下来是这段实测里最值得单独拎出来讲的一个坑，因为它极具迷惑性。

场景是这样的：你发起一个任务，页面显示 「Deep diving」 在持续计时，时间一直往上走，看起来 DeepSeek 还在后台疯狂思考。你等啊等，可能等了很久。但实际情况是——素材里的实测亲历是：dsh web 进程早就已经被关掉了，页面里的「Deep diving」还在继续计时。

这个现象说穿了不复杂，但杀伤力不小。页面计时和后台任务是否存活，是两回事。进程没了，前端计时器还在跑，于是你看到的「一直在思考」其实是个假象。素材里对它的评价是「体验就挺割裂的」，这个描述很准确。

所以第一条纪律就是：如果发现 dsh 卡在某个任务上很久，先别傻等。等下去不等于有结果。

正确的动作顺序，我整理成下面这份排查清单，照着做基本能排除掉绝大部分「假卡死」：

打开终端，确认 dsh web 到底还在不在运行。 这是第一动作，也是素材里明确给出的建议。别在浏览器里刷新页面求解，先看进程。
如果进程没了，直接重启 dsh web，任务多半需要重新发起。 因为页面计时并不代表任务真的活着，等下去也不会有产物。
如果进程还在，再判断是不是真的在跑长任务。 这时候结合轨迹看，比盯着计时器有用得多——轨迹里有没有新的工具调用、有没有新的文件改动，才是任务活着的证据。
如果进程在、轨迹也不动，那才是真卡。 这时再考虑换模式、缩小任务范围，或者检查是不是上下文里塞了太多东西。
养成习惯：长任务别只信页面。 页面计时增长 ≠ 任务存活，这个等式在 dsh 里不成立。

把进程存活状态和页面表现做个对照，会更清楚：

终端侧 dsh web 进程	页面「Deep diving」计时	任务真实状态	你该做什么
仍在运行	持续增长	大概率真实执行中	配合轨迹确认有无新动作，耐心等
已被关闭	仍在继续计时	任务实际已不存在（极易误判为仍在思考）	重启 dsh web，重新发起任务
仍在运行	增长但轨迹无新动作	疑为真卡死	检查模式与上下文，考虑缩小任务或换档位

这张表的核心结论只有一句：页面上的时间一直增加，不一定代表任务还活着。记住这一点，能帮你省下大量无效等待。

要快速确认进程状态，可以用下面这几条命令。别用「看起来像在跑」来判断，用命令输出判断：

# 排查 dsh 是否还在运行：先看进程，再看端口

# 1. 查 dsh 相关进程是否存活
ps aux | grep -i "dsh" | grep -v grep

# 2. 如果 dsh web 会监听本地端口，确认端口上还有没有进程在听
# 把 3000 换成你实际看到的端口号
lsof -i :3000

# 3. 单纯想快速确认一次：有输出=进程在，没输出=进程已经没了
# 这一步的输出结果，才是判断任务是否存活的依据

这几条命令的用法很直白：第 1 步看进程，第 2 步看端口，第 3 步是懒人版快速判断。养成「先看终端再下结论」的习惯，就不会再被计时器骗。

2026 年 9 月再看 Harness：插件生态膨胀后的三种新用法

站在实测的当下往远一点看，DeepSeek Harness 最让人期待的不是今天能干什么，而是社区插件规模持续扩张之后，它能被组装成什么。素材里的态度很明确：它最有价值的地方，是给社区留下了很大的改造空间；等生态越来越疯狂，后面的样子不太好想象。我把这条线索合理延伸一下，到 2026 年 9 月这个时间点，大概会浮现出三种值得关注的用法方向。

第一种：围绕垂直场景「组装」专属 Agent。 既然模型、工具、提示词、上下文和 UI 都能通过插件调整，那最自然的玩法就是不再将就通用 Agent，而是围绕自己的真实需求，把这几类组件重新拼一遍。同一个底座，拼出来的可能是一个只懂某类代码库的助手，也可能是一个专攻某类数据流程的执行体。前面讲的四种模式已经给了信号：标准模式负责干活，PTC 模式负责密集流程，极简模式负责压能力做测试，创造模式负责造模式——到了插件生态足够丰富的时候，创造模式的产出才会真正发挥价值。

第二种：靠插件解决上下文与成本问题。 上下文管理本身就是插件位，这意味着「什么时候压缩、压缩后留什么、哪些内容常驻」这些策略都可以定制。配合账单视图给出的 Token 消耗与缓存命中信息，你可以针对自己的任务类型专门调一套上下文策略，把成本压下来。这是纯工程收益，比换模型更可控。

第三种：把轨迹当成团队内的调试规范。 轨迹记录提示词、工具调用、文件改动、上下文压缩，这套留痕能力不只是个人学习用。当插件组合变多、行为变复杂之后，「出错先看轨迹」会从个人习惯变成团队规范——因为只有它能同时回答「哪一步错了」和「Token 花哪了」。

但必须同时把门槛讲清楚。素材里对 dsh 的定位说得很直接：它天生偏向开发者。这也决定了它可能不适合普通人——比如你想拿它处理办公事务，大概率会用不习惯，那些硬核设置和功能，看不懂也用不来。再加一条现实约束：目前缺少那种一键安装的 Skill 市场。插件数量虽多，但没有一个「点一下就装好」的统一入口，对非开发者来说就是一道实打实的墙。

把优势和门槛并排放，会更好判断自己该不该上车：

维度	对开发者的意义	对普通用户的现实
一切皆插件	可自由定制，模型/工具/提示词/上下文/UI 都能换	硬核设置多，看不懂也用不来
100+ 内置插件	开箱就有足够素材去拼装	不知道从哪选、怎么配
任务轨迹	调试、学习 Agent 执行逻辑的利器	信息量大，缺乏使用动机
缺乏一键安装 Skill 市场	可接受，自己写或手动配	入门门槛明显抬高
办公类日常事务	通常自己写工具更顺手	大概率用不习惯

所以对 2026 年 9 月的判断其实不复杂：插件生态膨胀会让 dsh 在开发者手里越来越强，但它的开发者向定位和缺失的一键安装市场，短期内不会自动消失。想吃到它的红利，前提是你愿意动手组装。

总结与最佳实践

最后把这篇实测的核心结论压成一份可执行清单。装好之后照着走，能少踩不少坑：

先搞定前置条件。 用常用 Agent 发一句安装指令即可，实测约 5 分钟；执行 dsh web 打开 Web UI；去 DeepSeek 官方 API 平台创建 API Key 填进页面；先往账户充点钱，Token 是计费的。
先建工作目录再对话。 dsh 必须先选一个工作文件夹才能开始，先在电脑上建好目录，再让 dsh 打开它。
权限按需选，别一上来就 Full Access。 只看代码用 Read Only；要改项目用 Workspace Write（日常最常用，超范围会先问你）；Full Access 等于拆掉护栏，只在明确知道它要做什么时再用。
模式按任务选。 日常开发用标准模式；批量处理文件、连续查询数据这类步骤多、调用密集的任务用 PTC 模式；极简模式拿来观察模型的裸机表现；创造模式用来组合自定义 Agent。
把轨迹当第一调试入口。 先定位失败点，再看提示词拼装、工具参数、上下文压缩节点；任务突然「失忆」，优先怀疑压缩。
每次任务结束对一次账单。 看 Token 消耗与缓存命中；消耗异常偏高就回轨迹查上下文搬运和压缩时机。
卡住先开终端。 确认 dsh web 进程是否还在；页面「Deep diving」计时增长不等于任务存活；进程没了就重启重发。
用好插件设置页。 官方内置插件已有 100 多个且会继续增加，先翻一遍再决定要不要自己写。
对自己诚实一点。 如果你是开发者，dsh 的自由度和轨迹能力会很对胃口；如果你主要想处理办公事务，目前缺少一键安装的 Skill 市场加上偏硬核的设置，大概率会用不习惯。

补充三条加分实践：

同一任务跑两遍、比对两条轨迹，用来判断行为变化是插件导致还是模型波动。
长任务优先考虑 PTC，把中间数据留在程序里而不是反复塞回上下文。
把「进程是否存活」当成判断任务状态的第一依据，页面计时只作参考。

整篇实测下来，我的结论是：dsh 值得看好，但它的价值不在「开箱即用有多爽」，而在给社区留下了很大的改造空间。模型、工具、提示词、上下文和 UI 都能通过插件调整，你可以围绕自己的真实需求，重新组装 Agent 的能力和工作方式。它确实很开发者向，也确实有坑——尤其是那个进程已关、计时还在走的割裂体验。但把插件、轨迹、账单这三件事用顺之后，你会开始理解为什么「一切皆插件」这五个字值得被反复讲。

从「模型是大脑」说起：为什么 DeepSeek 要自己做 Harness

dsh web 不是 CLI：一条命令打开 Web UI 的安装路径

API Key 到手之后：填 Key、充余额、跑通第一次对话

先选工作目录再开口：dsh 的任务区三件套

权限三档怎么选：Read Only / Workspace Write / Full Access

模型与推理等级：DeepSeek V4 Pro 与 V4 Flash 怎么挑

标准模式：看文件、改代码、跑命令、调 Skills 的默认档

PTC 模式：把多次工具调用写成一段 TypeScript 再执行

极简模式：只留 Bash 执行与文件修改两件工具

创造模式：查看运行环境、试插件、拼出你自己的 Agent 模式

总结与最佳实践

100+ 内置插件与「一切皆插件」：模型、工具、策略、存储、沙箱、上下文、UI 全可拆装

任务轨迹怎么读：提示词、工具调用、文件改动、上下文压缩全留痕

Token 消耗与缓存命中：每次任务结束后的账单视图

卡住不动先别等：dsh web 进程与「Deep diving」计时不一致的排查清单

2026 年 9 月再看 Harness：插件生态膨胀后的三种新用法

总结与最佳实践

相关阅读

每日精选 Skill 推荐，免费送到你邮箱