DeepSeek Harness

deepseek harness官网下载,网页版desktop,桌面版,插件市场,安装,github

DeepSeek Harness是什么?

DeepSeek Harness是DeepSeek推出的开源Agent框架，基于Cordis的“一切皆插件”架构构建，以开发者预览版面向全球开放测试并同步开源，既可下载桌面端应用，也能通过代码启动网页版，开箱即用。它既能辅助日常工作，如整理资料、分析表格、撰写文档与制作汇报，也能理解项目、修复问题、开发功能、运行测试，还能搜索资料、交叉查证并标注来源，同时支持后台执行脚本与批量处理文件并随时查看进度。其最大特色是插件化：用户可安装现有插件，也能在“创造模式”中通过对话直接编写并安装自定义插件，扩展工具、技能与界面。此外它还提供自动化任务、智能体团队、子智能体、语音输入与终端等能力，并支持开发者查看执行轨迹与详细运行信息，便于排查问题。项目采用MIT协议开源，命令即可启动，倡导在开放、可复用、可组合的基础设施上共探智能上限。

DeepSeek Harness官网: https://www.deepseek.com/harness/

DeepSeek Harness github项目地址: https://github.com/deepseek-ai/deepseek-harness

DeepSeek Harness 深度测评：当 Agent 循环本身变成插件，”一切皆插件”到底意味着什么？

一、引言

2026 年的开发者圈子里，一个越来越普遍的困惑是：AI 编程助手已经足够聪明，但我越来越不知道它在干什么。

你发出一个指令，屏幕开始滚动，模型读了十几个文件、跑了三次测试、改了五个文件。可是为什么？它读的那个文件真的有必要吗？它为什么重试了三次？这次任务到底烧掉了多少 token？这些问题，在大多数工具里没有答案——你能看到的只有最终结果，以及账单。

与此同时，另一个问题同样扎眼：这些工具的工作流是写死的。你想让它在每次提交前自动跑一遍自定义的检查脚本，想让它接上公司内部的代码审查流程，想把某个环节换成另一个厂商的模型，甚至想把它当”总包工头”去调度其他 Agent——通常得到的答案是”暂不支持，可以提个需求”。

2026 年 8 月，DeepSeek 给出了另一种答案。

DeepSeek Harness 面向全球开放测试并同步开源，采用 MIT 许可，以可自由组合的插件拓展 Agent 能力。它提出的核心公式只有一句：模型 + Harness = Agent。发布数日内，它在 GitHub 上的星标数迅速突破 5.5 万，社区插件目录里已经聚集了三百多个第三方项目。

它做的其实是两件事。

第一件事，把 Agent 的执行过程完全打开。每一次模型请求、每一次工具调用、每一个 token 的输入输出、每一次缓存命中，都被记录成可审计的事件流。运行轨迹不再是”调试模式”，而是主界面本身。

第二件事，把 Harness 本身彻底拆开。工具、技能、会话、存储、沙箱、审批、编排、界面，乃至最核心的 Agent 循环——全部是插件。同一个运行时，换掉一个提供者，整个产品的行为就会跟着改变。

换句话说，它把 R1 时期”公开思维链”的那套逻辑，往上抬了一层：不再只是让模型的”思考”可见，而是让 Agent 的”行动”可见、可查、可替换、可组合。

这篇文章会讲清楚六件事：DeepSeek Harness 到底是什么、它最适合谁、它的核心功能如何拆解和使用、真实体验如何、和主流竞品相比处于什么位置，以及最常见的那些疑问。如果你正在评估把 Agent 引入日常工作流或研发流程，这篇内容应该能帮你做出判断。

---

二、什么是DeepSeek Harness

DeepSeek Harness（简称 dsh）是 DeepSeek 官方开源的 Agent 运行框架，也是一款开箱即用的桌面应用与网页应用。它的核心主张是”一切皆插件”：工具、技能、会话、存储、沙箱、权限、编排，甚至连 Agent 循环本身，都以插件形式存在，可以自由安装、替换和组合。

用它，你可以整理资料、分析表格、撰写文档、制作汇报；可以理解代码仓库、修复问题、开发功能、运行测试；可以搜索资料、交叉查证、给出带来源的结论；可以把脚本和批量任务丢到后台执行、随时查看进度。它还内置”创造模式”，用几句对话就能给自己造一个新插件——官网演示里，一个带悬浮窗的番茄时钟插件从描述到安装验证，只花了 5 分 24 秒。

它把每一次模型请求、每一次工具调用、每一个 token 的开销，都写进追加式的会话日志。你看到的运行轨迹不是事后重建的”尽力还原”，而是模型真实消费过的那份事件流的投影。它既可以是桌面应用，也可以用一行命令启动为网页，还允许被自托管到你能访问的任何地方。

它目前是预览版，已经可用、可扩展、可审计，MIT 许可让代码完全可读、可改、可再分发。

1. 它和普通 AI 助手的区别

普通的对话式 AI 助手，交互边界是”你问—它答”。它能给你一段代码、一份分析、一个方案，但它看不到你的项目结构，也动不了你的文件系统。

DeepSeek Harness 把交互边界推到了”工作区”这一层。你可以 @ 一个文件或一段会话，可以让它直接在工作区里做修改——官网展示的那段 diff 就很典型：function label(name: string) 从直接返回 name，改成先 trim() 再返回 text || 'Untitled'。这不是给建议，而是把改动落进文件。它还能直接预览任务成果：Word 文档、Excel 表格、HTML 页面、TypeScript 代码、Python 脚本、PDF 文档、Markdown 文档，全都可以在界面里打开查看，并继续通过对话迭代。

2. 它和编程 Agent 的区别

市面上的编程 Agent 大多是”焊死的一体机”：模型适配器、工具分发、沙箱、会话存储、Agent 循环全在一个进程里，想扩展通常意味着魔改或者 fork。

DeepSeek Harness 走的是相反的路。它明确认为”不应该存在一个必须打补丁的特权核心”。它基于 Cordis 的「一切皆插件」架构构建，一个运行实例在运行时其实就是一棵分层的插件树：dsh-base 提供模型、工具、持久化、沙箱、审批、设置、凭证、遥测；上面叠 dsh-web-app 或 dsh-headless；再叠 profile 的 cordis.patch.yml、机器级的 cordis.patch.yml，最后是命令行传入的 --patch 覆盖层。任何一层都能被替换或插入新条目。

3. 它的三种使用形态

第一种是桌面端，面向 macOS（Apple silicon，macOS 13 或更高）和 Windows，主打后台运行、编辑本地文件、处理长而复杂的任务。第二种是网页端，装好 Node.js 后用 npx @deepseek-ai/dsh web 一行启动，浏览器打开即用，端口可配置，因为你跑的是本地服务，所以也可以选择把它部署到能远程访问的机器上。第三种是源码形态，把整个仓库克隆下来按说明安装，适合要深入改造插件或接入自己基础设施的团队。

---

三、目标客户和应用场景

1. 核心目标客户画像

DeepSeek Harness 的用户画像相当清晰，基本可以归为四类人：需要 Agent 干真活的工程师、需要 Agent 可被审计的技术负责人、需要构建自己 Agent 产品的开发者，以及需要处理大量文档与表格的知识工作者。

先看工程师。他们的痛点不是”AI 不会写代码”，而是”AI 写完我不知道它改了什么、为什么改、跑没跑过测试”。DSH 把每一次工具调用、每一条模型请求、每一个 token 都摊在轨迹视图里，这让工程师第一次可以像 review 同事的 PR 一样 review Agent 的工作。Reddit 上一位使用者提到，在 2017 年的 MacBook Pro 上，它依然”快、可靠、完全可定制，缓存命中 95–99%，UI 简洁好看”。

再看技术负责人。他们关心的是能不能把公司内部规范”塞进”Agent 的工作流。DSH 的插件架构让这件事变得自然：可以写一个插件挂到 agent/pre-step 上做输入审查，挂到 tools/pre-execute 上做权限拦截，挂到 agent/request 上做请求改写。这些钩子不需要改动 Agent 循环本体，也不会产生 import 循环。

第三类是 Agent 开发者。他们不需要又一个成品工具，需要的是一个可以站在上面构建产品的运行时。DSH 的能力接缝（capability seam）结构，把模型、文件系统、子进程、Shell、终端、沙箱、审批、Web 搜索与抓取、子智能体、工作流引擎、LSP、上下文压缩、技能目录、目标状态、溢出存储、后台任务、代码运行时——每一个都定义成一个可替换的服务定义。换一个提供者，整个产品的能力族就会跟着迁移。

第四类是知识工作者。整理资料、分析表格、撰写文档、制作汇报、查资料核对信息、批量处理文件——这些任务不需要懂代码，但需要 Agent 能真正操作文件、能后台跑、能给出带来源的结论。

目标客户群体	典型岗位	核心需求	推荐指数
全栈 / 独立开发者	软件工程师、独立开发者	改仓库、修 Bug、跑测试、控制成本	★★★★★
AI / Agent 开发者	AI 工程师、平台工程师	需要可替换、可组合的运行时来构建产品	★★★★★
技术团队负责人	研发经理、架构师	把团队规范、审查流程、权限策略编进 Agent	★★★★☆
数据 / 办公自动化人群	分析师、运营、咨询顾问	表格分析、文档撰写、批量文件处理	★★★★☆
研究 / 内容创作者	研究员、记者、内容策划	资料搜索、交叉查证、标注来源	★★★★☆
重度终端用户	DevOps、SRE	后台任务、脚本调度、终端与 LSP 集成	★★★★☆

2. 典型应用场景一：多步骤代码仓库改造

这是 DSH 最直接、也是最能体现价值的场景。

具体来说，你把一个项目目录添加为工作区，选择模型（DeepSeek-V4 Flash 或 Pro），按需要把权限范围从只读调到完整访问，然后给出一个任务，比如”这套表单创建系统存在重复逻辑，帮我收敛掉，同时保持现有行为”。接下来的过程，可以在轨迹视图里被完整看到：第 1 轮它先并行读取若干文件建立上下文，第 2 轮用 grep 定位重复模式的分布情况，第 3 轮开始提交补丁，第 4 轮跑构建和测试验证。

官网展示的那段修改，就是这种工作方式的缩影。diff 面板里，src/label.ts 第 1 轮改动被标得清清楚楚：加号是新增的 const text = name.trim(); 和 return text || 'Untitled';，减号是被删除的 return name;。你不需要相信它”改好了”，你直接看它改了什么。

Reddit 上一位日常使用另一款 Agent 工具的开发者做过对照测试，让 DSH 用 DeepSeek-V4 Flash 做同一套”重构表单创建系统”的任务。他的评价是：结果与另一款主流模型在低推理档位下的表现相当，模式遵循到位，把不正确的写法纠正了，没有引入安全问题。同时他特别提到，缓存命中率长期稳定在极高水平。

场景环节	使用方式	预期效果	难度等级
建立项目上下文	添加工作区目录，@ 关键文件	Agent 读到真实项目状态而非薄提示	★☆☆☆☆
定位问题	用 grep / read 逐步收敛范围	修改有据可依，不是猜测式改动	★★☆☆☆
提交修改	直接在工作区写入补丁	产出真实 diff，可 review、可回滚	★★☆☆☆
验证结果	让 Agent 跑测试、跑构建、跑浏览器检查	用真实反馈闭合循环	★★★☆☆
复盘过程	打开轨迹视图逐轮复盘	可审计、可复现、可归因	★★★☆☆

3. 典型应用场景二：定时自动化任务

有些工作不该被”想起来了才做”。启用自动化任务插件之后，你可以直接在对话里创建定时任务。

官网给了一个很典型的例子：每周五 17:00（北京时间）整理本周项目记录、生成周报。创建过程本身也在对话里完成——输入 schedule_create，参数是 prompt、title 和 weekly，其中 weekly 里带 time: 17:00:00、time_zone: Asia/Shanghai、weekdays: 。创建完成后，任务卡片会显示计划时间、重复规则（每周五 17:00，Asia/Shanghai）和状态（等待触发）。到了时间它自己跑，你回来看结果就行。

这个场景的价值，在于它把”重复劳动按计划执行”这件事从人工议程里彻底摘了出去。周报、日志归档、数据同步、批量文件整理、定期巡检——凡是节奏稳定的工作，都可以交给它。

4. 典型应用场景三：把 Harness 当”总包工头”编排多 Agent

这是 DSH 最有想象力的一层，也是它和其他工具最不一样的地方。

因为子智能体本身就是一个可替换的能力接缝，同一个 tool-subagent 消费者，背后可以接五种不同的提供者：进程内生成、进程内 fork、ACP、Codex、Claude Code。这意味着”把这一个环节转交给另一个产品”是一个配置项，而不是重写代码。

实际用法是这样的：你在 DeepSeek Harness 里设定目标，让它负责拆分任务、调度子智能体、汇总结果；具体的某一步——比如前端 UI 还原——可以交给长于视觉的工具；某一步需要严格的代码审查习惯，可以交给另一款 Agent；某一步需要跑长时间的后台脚本，就让它挂到后台任务注册表上去。Harness 在这一整条链路上扮演胶水和调度层。DeepSeek 自己的论文把这种思路称为”时空可组合性的编程范式”——把 Agent 能力当作可互换的零件，而不是一个焊死的流水线。

应用场景	使用方式	预期效果	难度等级
定时周报	启用自动化任务插件，创建 schedule_create	重复工作按计划执行，无需人工触发	★★☆☆☆
定时巡检 / 数据同步	配置周期任务 + 后台脚本	长周期任务稳定运行	★★★☆☆
多 Agent 编排	通过子智能体接缝接入不同 Agent	每个环节用最合适的能力，Harness 负责调度	★★★★☆
多步骤工程任务	目标 + 计划 + 子智能体分工	复杂任务被拆解、并行、汇总	★★★★☆
自定义插件生成	创造模式对话描述需求	得到符合自己工作方式的工具	★★★★☆

5. 更适合聚焦特定方向的用户

需要说明的是，DeepSeek Harness 的定位非常明确，它把深度交给你，相应地也就把”配置的自由”交给你。

如果你想要的是一款完全不需要接触任何配置文件、插件面板和技术概念、打开就聊的日常助手，那么 DeepSeek 官方 App（iOS / Android 都可用，与领先模型免费对话）会更贴合你的使用方式。它的交互足够轻，覆盖的日常问答、写作与学习场景也非常广。

如果你只做单一、轻量的任务，完全不涉及本地文件、代码仓库、定时任务，那么 DSH 的插件面板、工作区、权限设置、轨迹视图这些能力，对你来说使用频率会比较低——它们是为”要把它当工作台用”的人准备的。

如果你所在团队倾向于”零配置即用、不鼓励定制”，DSH 的开放架构反而需要一点前置投入：选模式、选模型、选工作区、配权限。这套流程大概几分钟就能走完，但它确实需要你愿意花这几分钟。

换个角度看：DSH 是那种”投入产出比随使用深度提升”的工具。用得越深，它给你的回报越大。

---

四、核心功能深度拆解

1. 杀手级功能一：一切皆插件

这是 DeepSeek Harness 的立身之本，也是最需要掰开讲清楚的一点。

它到底做了什么。 市面上绝大多数编程 Agent，是把模型适配器、工具分发、沙箱、会话存储、Agent 循环全都编译进一个进程里。”扩展”往往意味着 monkey-patch，或者 fork 一份自己维护。DSH 走的是另一条路：它明确主张”不应该存在一个必须打补丁的特权核心”，并且把这个主张做成了可验证的工程约束，而不是宣传口号。

底层是 Cordis 开源插件框架，围绕五个原语构建：服务（Service），是可插拔实现的单元；服务容器即上下文，ctx.tools、ctx.llm、ctx.sessions 都能从上下文里解析出来；inject 依赖声明，插件主动声明自己需要什么，而不是到处查找；类型化事件，插件之间通过类型化事件总线通信，不依赖全局变量；可逆注册，装上的东西能干净卸载，挂载本身是一个可以回滚的副作用。

这五个原语带来的结果是：DSH 里大约 159 个内置插件——模型适配器、工具注册表、会话日志、以及 Agent 循环本身——都可以通过配置替换。负责循环的插件只有一个，叫 agent-loop；其他扩展包依赖的是 dsh-agent 的事件和服务，而不是 agent-loop 这个包。正是这个依赖方向的设计，让”循环可替换”从愿望变成了事实。

怎么用。 打开插件管理页，你会看到一份官方插件列表，以及一个”添加插件”入口。列表里的官方插件包括：智能体团队（实验性）、自动授权审查（实验性）、自动化任务（实验性）、语音输入（实验性）、终端、Agent 循环、子智能体。已安装的插件会单独列出来，比如那个番茄时钟。

操作路径很直白：浏览列表 → 点击添加 → 启用或禁用。不需要重启，也不需要改代码。

使用技巧。 一是”按需启用”：插件越多，Agent 可见的工具越多，上下文就越重，所以只开当前任务真正需要的。二是”实验性插件先在非关键项目上试”：智能体团队、自动授权审查、自动化任务、语音输入这几项都标了实验性标签，功能本身已经可用，先在副项目里跑顺再上主项目更稳妥。三是”自建插件独立命名”：官方演示里的 dsh-plugin-pomodoro-float 就是一个独立包名，自己写插件时建议保持同样的命名习惯，方便管理。

和同类方案的对比。

对比维度	传统单体 Agent 工具	DeepSeek Harness
扩展方式	魔改、Fork、等待官方更新	新增插件，不动核心
Agent 循环	内置、不可替换	本身即插件（agent-loop）
模型适配	固定厂商或有限选择	通过 ctx.llm 适配器自由注册
核心规模	全部耦合在一个进程	约 159 个内置插件，逐项可替换
配置可见性	藏在设置菜单里	YAML 配置 + --dump-config 可打印完整配置树
卸载行为	通常不可逆	可逆注册，挂载可回滚

2. 杀手级功能二：创造模式

如果说”一切皆插件”是架构上的答案，那”创造模式”就是给终端用户的答案——它把”造一个插件”这件事，从写代码变成了说话。

完整流程是长这样的。 官网演示里，用户在创造模式下输入一句：”帮我写一个「番茄时钟」插件”。接下来屏幕上发生的事，值得逐条看：

第一步，Agent 加载技能 cordis-plugin-development。这是关键——它没有直接开写，而是先把这个领域的开发规范读进来。第二步，读取 skills/cordis-plugin-development/SKILL.md，把技能说明装载进上下文。第三步，开始思考技术方案，它判断 shell.overlay 是帧级浮动层，也就是做常亮窗口的正确目标——这是一个需要理解运行时结构才能做出的判断。第四步，检查提供方，一共 9 个。第五步，查询运行时的 Slots.listSubTree，确认要挂载的位置。第六步，写入 dsh-plugin-pomodoro-float/package.json，35 行新增。第七步，写入 dsh-plugin-pomodoro-float/client.js，638 行新增。第八步，调用工具 plugin_manager · install_bundle 完成安装。第九步，编辑 client.js，5 行新增、3 行删除，做修正。第十步，运行命令检查插件的实际运行状态。

用时 5 分 24 秒。最后它的回复是：”番茄时钟悬浮插件已做好、装好并验证通过。”

界面右侧可以看到插件面板里多了一个”番茄时钟”，下面是倒计时 25:00 → 24:59 → 24:58，有”专注 / 短休息”两个状态，还有一个”开始专注”按钮。

这个功能真正的价值在哪里。 不在于”AI 能写代码”，而在于它写的是正在运行的那个系统的扩展。它读的是这个 Harness 的技能、它查的是这个运行时的插槽、它调的是这个 Harness 的插件管理器、它验证的是这个 Harness 里插件的实际状态。整个闭环都在同一个系统里完成，中间没有”我写完了你自己去装一下”的断裂。

最佳实践。 一是描述要具体：说清楚你要的是”悬浮窗”还是”侧边栏”，是”桌面常驻”还是”会话内面板”。二是让它先加载技能：明确说”先加载 cordis-plugin-development”，它会先读规范再动手，成品质量差别明显。三是让它自己验证：最后一步的”运行命令检查插件运行状态”很关键，它是自我验证，不是自我宣称。四是注意技能的扫描位置：会话级技能目录的目录结构很容易踩坑，如果技能没被加载，先检查目录是不是放对了。

常见误区。 一个常见误解是”创造模式只能做小玩具”。从它的实际能力来看，它覆盖的是工具、技能、界面三个层面的扩展——小到番茄时钟，大到自定义的界面组件，都在射程内。另一个误解是”生成的插件不能改”。实际上生成的是标准的插件包结构，你可以像改任何代码一样改它，改完重新安装即可。

对比维度	传统插件开发	创造模式
前置知识	需读文档、了解 API、掌握框架约定	会用自然语言描述需求即可
开发周期	通常以天为单位	官方演示中为 5 分 24 秒
规范遵循	依赖开发者自觉	先加载 SKILL.md，按规范执行
挂载位置	需要手工查询运行时结构	自动查询 Slots.listSubTree
安装	手工调用安装流程	自动调用 plugin_manager · install_bundle
验证	手工测试	自动运行命令检查插件运行状态

3. 杀手级功能三：运行轨迹与”模型可见即已记录”

这一项功能，是 DSH 和其他工具气质上差别最大的地方。

轨迹视图长什么样。 顶部是几个关键指标：时长、轮次、调用数、搜索。中间按”输入 / 模型 / 工具”分层展示。会话按轮次（turn）组织，每一轮里能看到：系统初始提示词、用户消息、上下文、助手消息、工具调用。颜色上做了分层编码——工具调用是橙色，上下文是绿色，思考与技能调用各有各的泳道。

官网给了一个非常干净的演示。第 1 轮里，用户要求：先用 bash 输出 NAVIGATION_OK，再用两次 read 分别读取 nav-a.md 和 nav-b.md，然后只回复 FIRST_DONE。助手先执行 bash 确认输出，然后并行读取两个文件，最后回复 FIRST_DONE。第 2 轮里，用户要求用 Markdown 回复，二级标题写”Navigation Summary”，并汇总两个文件的内容。助手汇总了 alpha nav、beta nav 和 bash 输出的 NAVIGATION_OK，接着又调用了 bash {"command": "ls -la"}、grep {"pattern": "NAVIGATION", "path": "."}、read {"file_path": "README.md"} 三个工具，核对工作区结构与 grep 结果后才宣告完成。

再往下钻，是单个工具调用的详情面板，标签页有”概述 / 参数 / 结果 / Schema / 计时”。演示里那次 bash 调用的详情是：结果 NAVIGATION_OK，开始时间 2026-08-12 17:30:52.637，时长 34 毫秒，计时来源为会话时间戳，层级为助手消息。

“模型可见即已记录”是一条被运行时强制的不变量。 文档里这句话说得很硬：凡是能到达模型请求的内容，都必须可以从日志里重建，而且运行时有一条断言在管这件事。实际后果是——如果你想加入一种新的、模型可见的输入，就必须新增一种会话事件类型，扩展 SessionEventMap，并且从日志里渲染它。没有旁路通道。

这就是为什么轨迹视图是可信的：它不是”事后尽力还原”，而是模型真正消费过的那份事件流的投影。deriveMessages() 从日志里投影出模型历史，原始的 assistant/chunk 事件保证了重放和界面保真度；fork、resume、会话导出、遥测、持久化，全部从这一条事件流里派生。

三种事件域，是插件的主要扩展面。 会话事件是追加式事实，写进日志并通过 session/event 广播——用户在什么时候说了什么、助手的分片、工具的结果，这些需要跨重载存活的事实走这里。Agent 事件（agent/*）携带实时的 Agent 句柄：收件箱、步骤、状态、请求、校验、续跑。能力事件让你把策略和适配器挂到某条接缝上（fs/*、tools/*、telemetry/*），而且不会产生循环依赖。

生命周期的划分也很讲究。一个步骤（step）是”一次模型请求 + 它调用的工具”。一个轮次（turn）包含零个或多个步骤：它在第一个输入被认领之前打开，在不再有欠账时关闭。事件流大致是 turn/start → agent/pre-step → step/start → agent/request → llm/stream → assistant/chunk* → assistant/message → tool/call* → tools/pre-execute → tools/execute → tools/post-execute → tool/result* → step/end → agent/turn-stopping → turn/end。

其中 agent/pre-step、agent/request、llm/stream 和三个 tools/ 事件是瀑布（waterfall）事件，监听者必须调用 next() 才能往下传递；而 agent/turn-stopping 是串行（serial）事件，没有 next()。这个区别很重要：它让你可以”拦截一个请求而不拥有整个循环”。

上下文压缩同样遵循这套规则。dsh-compaction-basic 在派生请求构建之前，通过 agent/pre-step 响应上下文压力；agent/request-error 处理硬性的上下文溢出。任一触发后，会先跑一遍可选的工具结果剪枝，再退化为摘要。恢复发生在失败步骤结束之后、轮次关闭之前——而且只有当剪枝或摘要真正推进了内容面，系统才会开启一个新的重试轮次；否则原始错误就保留下来。它拒绝把失败悄悄吞掉。

可观测性维度	常见工具的表现	DeepSeek Harness
是否默认可见	需要开启调试模式	主界面即轨迹视图
工具调用详情	通常只有一行日志	概述 / 参数 / 结果 / Schema / 计时
计时的来源	多为估算	会话时间戳，可追溯到毫秒
上下文来源	不可见	工作区策略、可用技能、环境快照
模型可见内容的保证	尽力还原	运行时强制”可见即已记录”
会话复用	一般不支持	fork、resume、搜索、重放
缓存与成本	藏在账单里	每轮实时显示命中率与 token 数

4. 差异化特色功能：能力接缝与子智能体

能力接缝（capability seam）是什么。 它是把”可插拔”从形容词变成结构约束的机制。一个可替换的能力必须同时具备三个角色：服务定义声明接口（例如 dsh-shell）；服务提供者实现它（例如 bash-local、bash-sandbox、pwsh-local）；消费者使用它，通常是面向模型的工具（例如 tool-bash）。

这个结构的收益非常直接：换掉一个提供者，整个产品就会变。 因为文件系统提供者和进程提供者共享同一个执行世界，所以当你把 ctx.fs 和 ctx.subprocess 一起指向远端沙箱时，bash、PTY、LSP 这些能力会整体迁移过去——不需要给每个提供者写一份 fork。

接缝目录覆盖范围很广，看一眼就知道什么可换：

上下文键	它是什么	提供者示例
ctx.llm	模型适配器接缝	任何在此注册的 LLM 适配器
ctx.tools	作用域工具注册表 + 带门控的执行管线	核心 tools 包
ctx.fs	文件系统访问	fs-local、fs-sandbox、fs-e2b
ctx.subprocess	进程派生（bash、PTY、LSP、子智能体共用）	subprocess-local、subprocess-e2b
ctx.shell	Shell 执行	bash-local、bash-sandbox、pwsh-local
ctx.terminals	持久终端	terminal-bash
ctx.sandbox	派生进程的 argv 包装	sandbox-local
ctx.approval	一次性权限决策	acp（响应者也是监听者）
ctx.web	搜索 + 抓取	web-search-exa、web-search-perplexity、web-search-deepseek、web-fetch-http
ctx.subagents	子智能体委派传输	subagent-spawn-in-process、subagent-acp、subagent-codex、subagent-claude-code、subagent-dsh-sdk
ctx.workflowEngine	工作流运行器	workflow-worker-thread
ctx.lsp	语言服务器协议	lsp-local
ctx.compaction	上下文压缩	compaction-basic（无模型可见工具）
ctx.skills	技能目录	skill-badge、skill-filesystem
ctx.goals	从日志折叠出的目标状态	库实现
ctx.spillStore	超大工具文本存储	spill-local + spill-policy
ctx.jobs	后台工作注册表	jobs-local
ctx.codeRuntime	运行模型编写的程序	code-runtime-worker

这张表里有两点特别值得注意。第一，子智能体这一条接缝，自己就有五个提供者——进程内生成、进程内 fork、ACP、Codex、Claude Code。同一个 tool-subagent 消费者对它们全部生效。这意味着”把这个环节交给另一个产品来做”是配置层面的选择，不是重写。第二，ctx.compaction 被明确标注为没有模型可见的工具——压缩是一条你能替换的接缝，但模型永远不会主动调用它。这种关注点分离，在 Agent 框架里并不多见。

当你写自己的扩展时，你只依赖服务定义，永远不依赖具体提供者。这就在依赖方向上，把”可替换”刻进了代码本身。

插件管线为什么能”挂钩而不耦合”。 工具的执行走一条固定顺序的管线：tools/pre-execute 瀑布（策略、钩子、通过 ctx.approval 的审批）→ 单调守卫（tool-fs 下的”编辑前必先读取”检查、所有者策略）→ tools/execute 和 tools/post-execute 瀑布（两者都能重写调用）→ finalizeContent（由工具定义自己控制）→ tools/result（观察已经不可变、可 JSON 表示的结果）。

审批机制值得单独说一句。一次性的权限决策通过 approval/request 瀑布分发，响应者本身是一个监听者，如果没有响应者存在，这次调用会以 unavailable 关闭而不是挂住。这个小细节很重要：它意味着 Agent 的权限模型本身也是一条接缝，而不是一个写死的对话框。

对比维度	单体 Agent 的审批与钩子	DeepSeek Harness
权限拦截	写死在产品逻辑里	挂在 approval/request 瀑布上
工具前后处理	通常不开放	pre-execute / post-execute 双向可重写
结果观察	无标准位置	tools/result 观察不可变结果
无响应者时的行为	可能挂起	以 unavailable 关闭
跨工具族的钩子	需要耦合到策略服务	无需任何工具耦合到策略服务

5. 针对高级用户的隐藏技巧

官方文档里散落着一批”高手才知道”的用法，值得单独整理出来。

第一个技巧，打印真实配置树。 跑 dsh --profile web --dump-config，它会打印你这台机器实际启动所用的配置树。关键在于——凡是这条命令打印出来的东西，你都能用自己的 patch 覆盖。这份契约是”一切皆插件”不沦为口号的关键：配置目录是从运行时读取的同一份源生成的，所以你能 patch 的范围，恰好就是真实存在的那一层。

第二个技巧，理解覆盖链的顺序。 运行时是一个按固定顺序叠在空条目列表上的覆盖层栈：dsh-base（模型、工具、持久化、沙箱、审批、设置、凭证、遥测）→ dsh-web-app 或 dsh-headless（一次性运行器，无服务器）→ cordis.patch.yml（profile）→ cordis.patch.yml（home，机器级覆盖）→ --patch 覆盖层（来自命令行的额外 patch）。一个 patch 通过 id 定位条目，要么整体替换，要么插入新条目。

第三个技巧，用 YAML 接你自己的模型提供方。 因为项目是 MIT 许可，配置文件又是 YAML，你可以添加 DeepSeek 之外的模型提供方，也可以把 Harness 指向本地托管或自托管的模型。对需要在合规环境里运行、或者想比较不同模型在同一个 Harness 下表现的团队来说，这是最实用的一条。

第四个技巧，四种模式的选择要按任务来。 Minimal 模式是一个持久 bash 加一个 str_replace_editor，整个系统提示只有一句”You are a helpful software engineer assistant.”，适合要求最低干扰的脚本式任务。Standard 模式是全功能编码 Agent：文件编辑、Shell、文件与网络检索、技能、计划、目标、子智能体、工作流。此外还有 Code / PTC 模式和 Creator 模式，分别针对不同的任务剖面调优。模式一变，系统提示、工具集和 Agent 的自我认知都会跟着变。

第五个技巧，用 waterfall 事件做”不拥有循环的拦截”。 想在每次请求发出前改写内容，挂 agent/request；想在工具执行前加一层策略，挂 tools/pre-execute；想观察实时流式输出，挂 llm/stream。这些是 waterfall 事件，你必须调 next() 把控制权传下去，也正因为如此，你可以拦截而不接管。要终止整个轮次，用串行的 agent/turn-stopping。

第六个技巧，用 agent.inject() 注入上下文。 想让某条信息出现在下一轮请求里，直接调 agent.inject()，它会自然落到下一个符合条件的请求中——而不是靠拼字符串。想加持久会话状态，扩展 SessionEventMap，然后从日志渲染和重放。想 fork 一个活跃会话，用 ctx.sessions.fork(source, boundary?, childSessionId?)。想把某次注册限定到单个 Agent，用那个 Agent 自己的 agent.ctx。

第七个技巧，后台任务与溢出存储。 长脚本、批量处理挂到 ctx.jobs 上，job_* 系列工具负责收集或停止它们。超大的工具文本进 ctx.spillStore，由 spill-local 加 spill-policy 管理，不会把上下文撑爆。

隐藏能力	入口	适用场景
打印真实配置树	dsh --profile web --dump-config	想确认到底有哪些配置项可覆盖
多层覆盖链	profile → home → --patch	机器级差异、团队级差异分层管理
自定义模型提供方	YAML 配置	合规环境、本地模型、多模型对照
模式切换	Minimal / Standard / PTC / Creator	按任务剖面选最合适的工具集与提示
请求拦截	agent/request 瀑布	不改循环的前提下改写请求
工具策略	tools/pre-execute 瀑布	加审查、加审批、加守卫
上下文注入	agent.inject()	把信息精确送进下一次请求
会话 fork	ctx.sessions.fork(...)	从某个边界分叉出实验分支
后台任务	ctx.jobs + job_*	长任务、批处理、异步收集
溢出存储	ctx.spillStore	超大工具输出的存储与降噪

6. 功能完整度评估

把 DSH 目前公开的核心能力逐项列出来，可以看得更清楚。

核心功能	支持情况	说明 / 替代方案
桌面应用	已支持	macOS（Apple silicon，macOS 13+）、Windows
网页应用	已支持	npx @deepseek-ai/dsh web 一行启动
源码安装	已支持	完整仓库，按说明安装
一切皆插件	已支持	约 159 个内置插件，含 Agent 循环
创造模式	已支持	对话生成并安装插件，自动验证
运行轨迹视图	已支持	主界面，分层展示，可下钻到单次调用
会话日志	已支持	追加式事件流，模型可见即已记录
会话 fork / resume / 重放	已支持	ctx.sessions.fork 等
上下文压缩	已支持	compaction-basic，含剪枝与摘要
工具执行管线	已支持	前置 / 执行 / 后置三段瀑布
审批机制	已支持	approval/request 瀑布，无响应者以 unavailable 关闭
子智能体	已支持	五种提供者，含 Codex 与 Claude Code
工作流引擎	已支持	workflow-worker-thread
LSP 集成	已支持	lsp-local
技能目录	已支持	skill-badge、skill-filesystem
Web 搜索与抓取	已支持	多个搜索提供者 + HTTP 抓取
后台任务	已支持	jobs-local + job_* 工具
定时自动化任务	已支持（实验性插件）	schedule_create 等
多模型提供方	已支持	通过 ctx.llm 接缝与 YAML 配置
语音输入	已支持（实验性插件）	官方插件列表
智能体团队	已支持（实验性插件）	官方插件列表
自动授权审查	已支持（实验性插件）	官方插件列表
移动端	由 DeepSeek 官方 App 承担	与 Harness 定位不同

---

五、真实使用体验与深度测评

1. 交互体验与UI设计

DSH 的界面设计走的是”极简 + 高信息密度”的路线，而且在同一套视觉语言里同时容纳了”操作”和”观察”两件事。

左侧是会话与工作区，中间是对话与任务面板，右侧或下方是插件、轨迹、文件预览。文件预览支持 Word、Excel、HTML、TypeScript、Python、PDF、Markdown 等多种类型，图标风格统一，一眼能分清是什么文件。

工作区修改以 diff 的形式呈现，新增行和删除行用颜色区分，行号精确到具体位置。开关插件的面板设计得很克制——官方插件、已安装插件分成两栏，每一项只有一个开关。

最有设计感的是轨迹视图。它没有把”思考”藏成一个折叠箭头，而是为了让每一层可分辨，专门做了颜色编码：工具调用橙色、上下文绿色、思考与技能调用各自有泳道。顶部一排指标”时长 / 轮次 / 调用 / 搜索”像仪表盘一样一直挂在那儿，随时可以确认状态。点进去的单次调用详情面板分五个标签页，参数、结果、Schema、计时各归其位。

Reddit 上有用户评价是”UI 很漂亮，简约”，也有人在 2017 年的 MacBook Pro 上使用并称其”快、可靠、完全可定制”。这种评价对于一款信息密度这么大的工具来说，是相当难得的。

2. 性能与响应速度实测

从公开的实测数据看，DSH 在性能上的几个关键指标表现非常稳定。

先看缓存。多位用户的反馈都指向同一个区间：缓存命中率长期在 95% 到 100% 之间。官网展示的 ISS 追踪器案例中，一次运行到结束时缓存命中率达到 100%；Reddit 上有用户在做一个健身追踪 App 时观察到”每次都 100%”，还有人对比另一款工具称”最多只能做到 97–98%”。高缓存命中率意味着重复的上下文前缀被有效复用，这在长循环的 Agent 任务里对稳定性和成本都很有帮助。

一位开发者做过更细致的观察：查看日志后发现，它不把工具返回算作输入，只算用户输入——这解释了为什么缓存数字能长期保持在高位。

再看吞吐。官网展示的案例里，输出 token 约 24 万，速度约 130 token/秒。另一个实测案例中，一次典型运行的数据是：首 token 平均 1.8 秒，53 token/秒，缓存命中 96%，输入 310 万 token，输出 2.61 万 token。这个首 token 延迟和吞吐组合，在长循环场景下体验是比较顺畅的。

最后看响应节奏。工具调用的耗时本身也很短——官网轨迹演示里，一次 bash 调用从开始到返回耗时 34 毫秒，计时来源精确到会话时间戳。这意味着大部分时间花在模型推理上，而不是工具层。

综合这三点，DSH 的响应表现可以概括为：首 token 快、吞吐稳定、缓存高效、工具层几乎无感。对于动辄跑几十分钟、几十轮的多步骤任务来说，这种性能特征比单纯的”跑分快”更实用。

3. DeepSeek Harness核心优势

把前面所有内容收束一下，DSH 的核心优势可以归纳为下面八点。

第一，执行完全透明。 运行轨迹不是调试模式而是主界面，每一次工具调用、每一个 token 都摊开给你看。你不需要”相信”它做对了，你可以直接检查。

第二，可审计有硬保障。 “模型可见即已记录”是一条运行时强制的不变量。轨迹视图不是事后重建，而是模型真实消费的事件流的投影。这在需要复盘、归因、合规的场景里价值很大。

第三，架构彻底可组合。 从模型适配器到 Agent 循环，全部以插件形式存在，约 159 个内置插件逐项可替换。不会有”这个功能我们暂时不支持”的僵局。

第四，扩展门槛极低。 创造模式让”给自己造一个工具”变成了对话。官网演示里那个番茄时钟插件，从一句话需求到安装验证完成，用时 5 分 24 秒。

第五，可编排多 Agent。 子智能体接缝有五个提供者，同一个消费者对它们全部生效。”把这个环节交给另一个产品”是配置项，不是重写。

第六，缓存效率出色。 长期稳定在 95%–100% 的高缓存命中率，让长循环任务的上下文复用效率非常高，首 token 延迟与吞吐也因此保持在良好水平。

第七，技能体系可沉淀。 技能目录加上 SKILL.md 的加载机制，意味着你可以把”这个领域该怎么做事”写下来，让 Agent 每次都先读一遍再动手。官网演示里那个”先加载 cordis-plugin-development 再开始写插件”的行为，就是这个机制在起作用。

第八，开源与可迁移。 MIT 许可意味着代码可读、可改、可自托管，配置写在 YAML 里，可以接自己的模型提供方，也可以指向本地模型。团队不会因为某个厂商的产品决策而被动迁移。

---

六、竞品横向对比

本节聚焦功能与体验维度，帮助你在不同工具之间做出选择。

1. Claude Code vs DeepSeek Harness

Claude Code 是目前知名度最高的终端原生编码 Agent 之一，它的优势在于交互体验打磨得非常成熟，终端里的命令风格、对话节奏、权限确认流程都很顺手，对于已经习惯在终端里工作的工程师来说几乎零学习成本。

对比之下，两者的根本差别在架构取向上。

Claude Code 是一款成品，工作流由厂商设定，扩展主要通过 hooks、MCP 服务器等有限接口。DeepSeek Harness 是一款运行时，工具、技能、会话、存储、沙箱、编排、乃至 Agent 循环本身都是插件。你想要什么工作流，可以自己搭一个。

另一个关键差别在可观测性。Claude Code 的会话是留给你的记录；DSH 的会话是 Agent 消费内容的唯一事实来源，被运行时强制保证——”模型可见即已记录”。这意味着 DSH 的轨迹视图可以被当作审计材料，而不只是阅读材料。

还有一个有趣的互补点：因为子智能体接缝里有 subagent-claude-code，你完全可以在 DSH 里把某个环节委派给 Claude Code，同时用它作为总调度层。它们不是非此即彼的关系。

对比维度	Claude Code	DeepSeek Harness
产品定位	成品级编码 Agent	可组合的 Agent 运行时
工作流定义	厂商设定	插件自由组合
扩展方式	Hooks、MCP 等有限接口	约 159 个插件逐项可替换
Agent 循环	不开放替换	本身即插件
轨迹可见性	会话记录	主界面 + 强制”可见即已记录”
子智能体	不对外开放为插件	五种提供者，含 Claude Code 自身
界面形态	终端优先	桌面 / 网页 / 源码
开源许可	专有	MIT

2. OpenAI Codex 系工具 vs DeepSeek Harness

Codex 系的工具在交互风格上给很多用户留下了深刻印象，DSH 的界面和交互节奏与之有相似之处。但两者的产品哲学不同。

Codex 系工具的强项在于”把一件事做到顺”。你给它一个任务，它按自己的方式推进，体验流畅、结果可靠。但它同样是一个相对封闭的产品，你很难改变它”怎么看仓库、怎么选工具、怎么组织循环”。

DSH 的强项在于”你说了算”。它把 Agent 运行时的每一层都暴露出来：仓库上下文的构建方式、工具的选择与执行管线、循环的组织、状态的存储、失败的恢复，全部可以改写。官网的 ISS 追踪器案例就是很好的说明——Agent 用可见的待办列表推进任务，用基于浏览器自动化的方式做验证，最终产出了一个完成度很高的实时追踪应用。这个案例真正值得看的不是最终成品，而是整个过程都在轨迹视图里。

更进一步，DSH 的子智能体接缝里有 subagent-codex，也就是说你可以把 Codex 作为子智能体接进 DSH 编排的流程中。

对比维度	Codex 系工具	DeepSeek Harness
设计重心	成品体验的流畅度	运行时的可组合性
上下文构建	内部实现	通过接缝与事件开放
工具管线	不开放	前置 / 执行 / 后置三段瀑布
会话状态	记录为主	追加式日志，模型历史的唯一来源
可否作为子智能体被调用	不适用	可以（subagent-codex）
配置可见性	设置项	YAML + --dump-config 完整配置树
开源	否	是（MIT）

3. Cursor vs DeepSeek Harness

Cursor 是编辑器形态 AI 工具的标杆，它最大的优势是”就在你的编辑器里”。补全、内联编辑、多文件改动、对话式修改，这些操作在编辑器语境下极其顺手，对前端和全栈开发者尤其友好。

DSH 的定位不在编辑器之内，而在编辑器之下和之上。往下一层，它管的是进程、文件系统、Shell、终端、LSP、沙箱；往上一层，它管的是任务编排、定时调度、多 Agent 协作。如果你日常主要工作是”在编辑器里写代码”，Cursor 更贴合；如果你日常工作是”让 Agent 完成一整条工程流程”，DSH 更贴合。

值得一提的是，DSH 也集成了 lsp-local，也就是说它有自己的语言服务器协议接入方式。它不是要取代编辑器，而是要让 Agent 具备”理解代码结构”的能力，这一点和编辑器提供的智能提示是不同层面的能力。

对比维度	Cursor	DeepSeek Harness
形态	AI 编辑器	桌面 / 网页 / 源码运行时
交互主场景	编辑器内编码	工作区级任务执行
强项	补全、内联编辑、多文件改动	多步骤任务、编排、调度
进程与沙箱能力	编辑器边界内	ctx.subprocess、ctx.sandbox、ctx.terminal
语言服务	编辑器原生	ctx.lsp 接缝
定时任务	不适用	自动化任务插件
子智能体编排	不适用	五种提供者
开源	否	是（MIT）

4. Cline / Aider 类工具 vs DeepSeek Harness

Cline 和 Aider 代表了另一条路线：开源、轻量、专注在”改代码”这件事上。它们的优势是简单直接——装好、接上模型、开始干活，对个人开发者和小项目非常友好。

DSH 与它们最大的不同在于”范围”。Cline / Aider 关心的是”怎么把这次改动写对”；DSH 关心的是”这一整套工作流程怎么组织”。插件系统、能力接缝、事件域、会话日志、子智能体、工作流引擎、后台任务、溢出存储——这些不是”改代码”需要的，而是”把 Agent 当基础设施用”需要的。

对于只想快速改几行代码的人来说，Cline / Aider 的轻量是优点；对于想长期构建一套 Agent 工作流的团队来说，DSH 的完整度是优点。

对比维度	Cline / Aider 类	DeepSeek Harness
上手门槛	极低	中等（需理解模式、工作区、权限）
代码改动能力	强	强
多步骤任务编排	有限	完整（工作流引擎 + 子智能体）
插件生态	有限	316+ 社区插件
定时 / 后台任务	不适用	支持
会话日志与重放	基础记录	追加式日志 + fork / 重放
可观测性	对话为主	轨迹视图为主界面
开源	是	是（MIT）

5. 选购决策树

下面这棵决策树，可以帮你快速定位。

如果你日常工作是在编辑器里写代码、需要极顺手的补全和内联修改，先考虑 Cursor 这类编辑器形态的工具。

如果你想要的是终端里体验打磨成熟、开箱即用的编码 Agent，Claude Code 是稳妥的选择。

如果你更看重流畅的成品体验、不太想折腾配置，Codex 系工具或 Cline / Aider 这类轻量工具更合适。

如果你需要的是执行过程完全透明、可审计、可复盘，DeepSeek Harness 是目前最彻底的一个。

如果你需要把公司规范、权限策略、审查流程编进 Agent 的工作流，DSH 的瀑布事件和审批接缝是合适的落点。

如果你需要在同一套运行时下比较不同模型，或者需要把 Harness 指向本地托管模型，YAML 配置 + MIT 许可让它成为最灵活的选择之一。

如果你需要把多个不同厂商的 Agent 串成一条流水线，DSH 的子智能体五种提供者是唯一直接支持这件事的选择。

如果你要给 Agent 造一个它原本没有的能力——不论是工具、技能还是界面——创造模式可以让你用对话完成。

---

七、常见问题解答

1. DeepSeek Harness 是免费的吗？

需要区分两件事。项目本身采用 MIT 开源许可，代码可以自由查看、修改、自托管，甚至再分发。这一点是明确的，不存在功能分层收费的问题。

至于使用成本，取决于你接入哪个模型提供方——它既可以是 DeepSeek 自己的模型，也可以是其他提供方，甚至是指向本地托管模型。DeepSeek Harness 官方未公开具体的套餐、定价或计费说明，相关细节需前往官网或联系官方获取最新信息。价格可能随官方调整，请以官网最新公示为准。

2. 它和 Claude Code、Codex 有什么本质区别？

最本质的区别是架构取向：它们都是成品级 Agent，工作流由厂商设定；DSH 是运行时，工具、技能、会话、存储、沙箱、编排乃至 Agent 循环本身都是插件，可以自由替换和组合。

第二个区别是可观测性：DSH 把”模型可见即已记录”作为运行时强制的不变量，轨迹视图是模型真实消费的事件流的投影，可以被当审计材料用。

第三点是互补性：DSH 的子智能体接缝里同时提供 subagent-codex 和 subagent-claude-code 两个提供者，也就是说它可以在编排层把这两个工具当作子智能体调用。

3. 怎么安装 DeepSeek Harness？

有三条路径。

最简单的一条是命令启动：装好 Node.js 之后，运行 npx @deepseek-ai/dsh web，它会启动网页界面，浏览器打开即可使用。

第二条是源码安装：克隆完整项目源码，按仓库说明完成安装。适合需要深入改造插件或接入自有基础设施的团队。

第三条是桌面端：官网提供 macOS（Apple silicon，macOS 13 或更高）和 Windows 两个平台的桌面应用下载。桌面端可以后台运行、编辑本地文件，处理长而复杂的任务。

4. 使用它需要什么账号或密钥？

首次登录网页应用时会要求填写模型提供方的 API 密钥。你可以添加多个提供方——在模型设置里点”添加提供方”，从列表中选择，填入对应的 API 密钥即可。填好之后，在新建会话时就可以从模型下拉框里选择要用的模型。

密钥请自行妥善保管，不要分享给他人。

5. 我能让 DeepSeek Harness 用 DeepSeek 以外的模型吗？

可以。项目是 MIT 许可，配置文件是 YAML，你可以添加 DeepSeek 之外的模型提供方，也可以把 Harness 指向本地托管或自托管模型。

从能力接缝的角度看，模型适配器就是挂在 ctx.llm 上的一条接缝。你写自己的扩展时，只需要依赖服务定义，不依赖具体提供者——这也是”可替换”在依赖方向上被强制保证的方式。

6. 它是稳定版吗？现在用会不会有风险？

它目前是开发者预览版（Developer Preview），MIT 许可，面向全球开放测试并同步开源。官方明确说明核心插件和基础 API 会持续迭代。

从实际体验来看，它现在已经足够好用：桌面端和网页端都可以正常跑，平台生态里已经聚起了三百多个社区插件，GitHub 上的星标数也已突破 5.5 万，社区里不少用户提到自己已经能独立写出三五个插件跑起来。

建议的做法是：把它先用在非关键项目上，把常用的工作流跑顺，再逐步扩展到主项目。

7. 技能（Skills）放在哪才能被加载？

这是一个很容易踩的坑。DSH 默认只扫描两个技能根目录：一个全局目录（~/.dsh/skills）和项目内的 .dsh/skills。另外，技能目录是按会话快照的，所以会话中途新加的技能不会立刻生效，需要新开会话。

如果你发现自己写的技能没有被加载，先检查目录位置对不对，再确认是不是在当前会话之后才添加的。

8. 它适合完全没有编程基础的人使用吗？

要用好它，需要接受几个概念：工作区、模式、模型、权限、插件。这些都不难，几分钟就能理解，但它们确实存在。

如果你的目标是”打开就聊、不想碰配置”，DeepSeek 官方 App 会更贴合——它同样由领先模型驱动，支持 iOS 和 Android，主打日常问答、写作与学习场景。

如果你愿意花一点时间理解这套结构，那么 DSH 的能力边界会大很多：它能操作文件、能跑后台任务、能定时执行、能按你的方式扩展，也能随时把过程摊开给你看。

---

如果你读到这里，大致可以形成这样一个判断：DeepSeek Harness 不是”又一个 AI 编程助手”，而是把 Agent 这个概念的运行时层，完整地、开源地、可审计地交到了使用者手上。

它把模型之上的那一层——仓库上下文的构建、工具的选择与执行、状态的记录与恢复、循环的组织、能力之间的组合——从黑盒变成了插件树。代价是你需要理解它一点；回报是你可以按自己的方式塑造它。

从 2026 年 8 月开放测试到现在，它已经从一个开发者预览版，成长为拥有三百多个社区插件、被大量工程师当作日常工作台使用的系统。而它最核心的那句主张，仍然简单：模型 + Harness = Agent。模型决定了能力上限，Harness 决定了一切能落地的部分——而 Harness，现在握在你手里。