DeepSeek Harness

DeepSeek 的 V4 系列模型在推理能力和性价比上已经证明了自己，但一个模型再强，如果缺少合适的”脚手架”，它也只能停留在聊天框里。2026年8月，DeepSeek 把这个脚手架开源了——DeepSeek Harness，简称 dsh。它不是又一个聊天界面，而是一个 agent 运行时框架，用他们自己的话说：Agent = Model + Harness。模型负责思考，Harness 负责把思考变成动作。

这个项目在 2026 年 8 月 13 日正式放到 GitHub 上，MIT 协议，TypeScript 写成。发布后的 star 增长速度确实夸张：两小时内破万，十二小时到五万，两天左右突破十万。虽然 star 数不能说明一切，但至少说明开发者对这个方向的需求是真实存在的。

它不是 Claude Code，它是 Claude Code 的”反面”

很多人第一反应是把 dsh 和 Claude Code 或者 OpenAI Codex 做对比，但这种对比其实不太准确。Claude Code 是一个开箱即用的产品——你安装它，配置 API key，它就能帮你改代码、跑测试、查文档。而 dsh 更像是一堆乐高积木，官方只提供了最基础的连接件，具体搭成什么样，得你自己决定。

这种差异在架构上体现得很彻底。dsh 的底层是一个叫 Cordis 的框架，核心理念用四个字概括就是一切皆插件。模型适配器是插件，工具注册表是插件，会话日志是插件，甚至那个最核心的”决定-执行-观察”循环本身也是插件。官方文档里有一句话挺有意思：”没有特权核心需要打补丁”——你想扩展功能，不是去改核心代码，而是挂载一个新插件上去。

这种设计的好处显而易见。比如你想换一个模型后端，不需要等官方支持，换个模型适配器插件就行；你想给团队定制一套只读的安全策略，写个插件覆盖默认的审批逻辑；甚至你觉得官方的 agent 循环不够好，也可以自己写一个替换掉。代价也同样明显：灵活性越高，出问题的表面就越大，而且官方已经明确说了，目前还是开发者预览版，会有破坏性变更。

四种预设模式，从极简到创造

虽然强调自定义，DeepSeek Harness还是提供了四种开箱即用的预设，降低上手门槛。

Standard 是最完整的模式，文件系统操作、shell 执行、网页搜索、子 agent 委派、计划模式，该有的都有。如果你只是想找个类似 Claude Code 的体验，选这个。

Minimal 则走到了另一个极端，只保留 bash 和 str_replace_editor 两个工具。这个模式适合那些对 agent 能力持怀疑态度的人——工具越少，模型出岔子的空间就越小。

Code 模式比较有意思。它不再把工具暴露成一个个独立的函数调用，而是生成一套 TypeScript SDK，让模型直接写一段程序来调用这些能力。原本需要五轮交互才能完成的操作，可能一次就搞定了。这对延迟敏感的场景很实用。

Creator 模式则是给想深度定制的人准备的。它继承了 Standard 的全部能力，但额外增加了运行时检查、插件实验和预设编写引导。你可以让 agent 帮你设计一个新的预设，比如”一个只读代码审查员”，它会帮你把配置草稿写出来。

可重放的会话日志

DeepSeek Harness的会话系统也值得提一句。所有的交互——用户输入、模型输出、工具调用、上下文注入、子 agent 活动——都被记录成一条追加式的事件流。这意味着你可以随时回到某个时间点重新分叉会话，或者把完整的执行轨迹导出给别人复盘。对于调试 agent 行为来说，这比看一堆分散的日志要直观得多。

生态已经长出来了

开源不到两周，社区已经开始围绕 dsh 构建工具链。有人做了桌面封装，把 Web UI 包成跨平台的独立应用；有人写了评估平台 dsh-eval，可以用一份 YAML 配置文件跑完整的 benchmark；还有人做了 dsh-benchmark，专门做确定性的回归测试。官方默认安装就带了上百个插件，内测阶段社区插件据说已经有三百个左右。

这种生态速度很大程度上得益于 npm。因为 dsh 本身是基于 Node.js 的，插件就是普通的 npm 包，安装和管理都很自然。你只需要给 GitHub 仓库打上 dsh-plugin 标签，就能被社区索引到。

现在能用来做什么

上手比想象中简单。装个 Node.js，然后一行命令 npx @deepseek-ai/dsh web 就能在本地 3080 端口启动 Web 界面。填上 DeepSeek API key，选一个工作区，就可以开始发任务了。如果你更喜欢命令行，dsh --profile headless "你的任务" 可以直接跑单次任务。

对于有二次开发需求的人，从源码运行也很直接：clone 下来，pnpm install，build，然后启动。官方还提供了一个 Python SDK，方便把 Harness 的能力嵌入到自己的脚本里。不过目前 Python SDK 的示例主要支持 Linux 和 macOS，Windows 用户可能需要借助 WSL。

一些现实的顾虑

当然，现在就把DeepSeek Harness塞进生产环境可能还为时过早。开发者预览版的标签不是白贴的，官方 README 用大写字母警告会有兼容性破坏的变更。插件生态虽然热闹，但质量参差不齐，毕竟每个插件都运行在本地权限下，能访问文件、网络和凭证。

另一个需要理解清楚的点是，agent 的 benchmark 分数是模型和 harness 绑定的结果。DeepSeek 之前公布的 DeepSWE 成绩是用他们自己的 harness 跑出来的，在 harness 开源之前，第三方没法复现，也没法单独评估模型的贡献到底有多少。这不是 DeepSeek 的问题，而是整个 agent 领域的现状——只不过 dsh 把这个事实摆到了台面上。

DeepSeek Harness 的出现，某种程度上标志着开源 AI 的竞争从”谁的模型更强”转向了”谁的 agent 基础设施更开放”。V4 模型已经证明了 DeepSeek 在权重层面的实力，而 dsh 则是在补齐”模型变成 agent”的最后一块拼图。

对于开发者来说，它提供了一种可能性：不用等厂商更新，自己就能调整 agent 的行为逻辑。对于研究团队来说，它提供了一个可控的实验平台，可以隔离变量去测试不同的 harness 配置。至于它能不能真的撼动 Claude Code 的地位，可能取决于社区插件的质量和官方对稳定性的承诺——但至少在”开放”这个维度上，DeepSeek Harness已经给出了一个足够有诚意的起点。