DeepSeek Harness 很妙：这不是一个产品，而是一个战略
广纳天下之 Harness 贤才，共同探索未至之境。
👦🏻 作者: Dekox
🥷 编辑: Koji
🧑🎨 排版: NCon
Codex 有自己的 Harness，Claude Code 有自己的 Harness，OpenCode 有自己的 Harness，连 Kimi 都有了自己的 Harness。
DeepSeek 却一直没有给出自己的答案。
直到 8 月 13 日，它终于发布了第一个版本：DSH，也就是 DeepSeek Harness，代码以 MIT 协议开源在 GitHub 上[1]。
但如果只把 DSH 理解成"DeepSeek 版 Claude Code"，可能就把这件事看窄了。
DSH 当然长得像一个产品：它有 Web UI，可以读写代码、运行 Shell、搜索文件和网页、加载 Skills、制定计划、调用子 Agent，也提供标准、PTC、极简和创造等多种运行模式。
可 DeepSeek 自己毫不避讳地说，这是一个"开发者预览版"，未来会出现破坏兼容性的变更。仓库里的版本号甚至还停留在 0.1.0-rc[2]。
一个真正以销售和交付为中心的产品，通常会努力隐藏自己的不确定性；DSH 却把不确定性直接写在了门口。
因为它真正想发布的，可能不是一个完成的产品，而是一套让所有人共同探索 Harness 的机制。
Harness 已经成为模型能力的一部分
DeepSeek 在 DSH 的发布页面上写了一个很简单的公式：
Agent = Model + Harness
模型负责理解、推理与生成，Harness 则给模型提供上下文、工具、文件系统、记忆、权限、沙箱、Agent Loop 和与真实世界交互的接口。
模型像大脑，Harness 像身体、神经系统和工作环境。
到了 Agent 阶段，模型能力已经不能脱离 Harness 被单独评价。同一个模型，放在不同的上下文管理策略、工具定义、系统提示词和 Agent Loop 里，最终表现可能完全不同。模型决定能力上限，Harness 决定有多少能力能够真正进入现实任务。
问题是，我们今天其实并不知道最好的 Harness 应该长什么样。
应该给模型几十个原子工具，还是让它写一段代码组合多轮工具调用？应该尽可能保留完整上下文，还是频繁压缩？应该坚持单 Agent，还是把任务拆给多个子 Agent？交互入口应该是 CLI、IDE、桌面应用，还是完全无界面的后台进程？
这些问题都没有收敛。
最妙的五个字：一切皆插件
DSH 的核心口号是"一切皆插件"。
这里的"一切"相当彻底：模型、工具、Skills、会话、沙箱、存储、文件系统、Agent Loop、调度乃至 UI，全部由插件提供，可以在配置层被替换、重组和扩展。
在 DSH 的架构文档[3]里，甚至连 Agent Loop 都不是一个不可触碰的核心。系统不存在一个必须反复修改的"特权内核"；开发者可以把自己的插件挂载在现有组件旁边，替换某一种能力，而不必 Fork 整个项目。
它底下的 Cordis 内核只负责三件事：插件的加载、卸载和依赖关系，不承载任何具体的 Agent 能力。
这是一种很适合不确定时代的架构。
Cordis 团队为此还发布了一篇题为 《A Programming Paradigm for Spatiotemporal Composability》[4] 的论文，讨论所谓"时空可组合性"：组件不仅要能够自由建立依赖，还要能够在被移除时完整撤销自己带来的影响。
翻译成更直白的话就是：
今天认为正确的答案，明天可以被完整拔掉，换上一个更好的答案，而不会把整个系统一起拆毁。
当技术路线已经收敛时，一个高度可替换的系统未必最有效率；但在模型和 Agent 能力都尚未收敛的时期，"随时替换答案"的能力，可能比"现在就选对答案"更重要。
所以，"一切皆插件"不只是一种工程审美。它是 DeepSeek 面对不确定性的战略选择。
把全世界变成一个分布式 Harness 团队
DeepSeek 自己是一支很小的团队。
无论多强，它都不可能同时探索上下文管理、工具协议、Agent Loop、沙箱、记忆、调度、多 Agent 协作、垂直行业工具和各种交互界面的全部可能性。
但开源一个插件化的 Harness，就可以把这个搜索空间交给全世界。
有人可以做更好的记忆插件，有人可以重新设计工具调用，有人可以试验新的多 Agent 调度，有人可以接入远程沙箱，有人可以做视觉能力、终端界面、工作流引擎或者垂直行业 Agent。
每一个插件，实际上都是一个可以运行、比较和淘汰的 Harness 假设。
DeepSeek 的贡献指南[5]里有一句非常值得注意的话：
官方仓库里的软件包，并不天然比社区创建的软件包更重要。
DeepSeek甚至建议大家把官方仓库理解成"一种想法、一个官方示范和一份灵感来源"，而不是必须遵守的标准答案。
目前主仓库因为团队规模和开发速度，暂时还不接收外部 Pull Request。DeepSeek给社区安排的参与方式，是报告问题、开发独立插件、撰写教程，以及帮助其他用户。
这意味着它没有把所有人的创造力都挤进一个主仓库，而是试图形成一种"内核集中、创新分布"的生态：DeepSeek 维护组合机制，社区在边缘同时试验数百种可能性。
截至 8 月 14 日，DeepSeek 官方指定的 GitHub dsh-plugin[6]话题页[6]已经聚集了六百多个公开仓库。里面当然会有蹭标签、重复建设和质量参差的项目，但这反而说明了一件事：这个机制正在快速吸附开发者。
对于一个刚刚开放的开发者预览版来说，最重要的指标未必是现在有多少成熟插件，而是全世界的开发者是否觉得，自己的想法值得接到这套系统上。
这就是它作为战略的价值
如果把 DSH 当作产品，我们会问：
它现在有没有 Claude Code 好用？UI 是否成熟？Token 消耗高不高？子 Agent 会不会报错？文档是否足够清楚？
这些问题当然都重要。
但如果把它当作战略，应该问的是另外几个问题：
它把哪些人动员了进来？它允许多少种技术路线同时存在？全世界对 Harness 的探索，最后会沉淀在哪里？
在模型能力高速变化、Harness 范式尚未收敛的阶段，过早押注一个封闭产品，相当于用一家公司的判断，去猜一个仍在快速移动的终局。
DeepSeek 的做法，是保留尽可能多的选择权。
如果某种上下文策略胜出，它可以成为默认插件；如果 PTC 比传统工具调用更有效，它可以被进一步强化；如果未来模型已经强到不再需要复杂的多 Agent 编排，那些组件也可以被卸掉；如果某个垂直社区创造出更好的工作流，DSH 可以直接吸收其经验，而不需要推倒重来。
更重要的是，这会形成一个模型与 Harness 共同进化的回路。
社区公开的问题、插件和运行经验，会不断暴露模型在真实任务中的摩擦点。
这些摩擦点既可以推动 Harness 迭代，也能反过来告诉模型团队：下一代模型应该在哪些 Agent 能力上继续训练。
DeepSeek 开放的，因此不只是代码、不只是插件平台。
它开放的是自己的问题空间。
争夺 Agent 时代的演化权
产品的逻辑，是给用户一个答案。平台的逻辑，是让更多人来提供答案。
而战略的逻辑，是让未来无论出现哪一个答案，都尽可能在自己的坐标系里发生。
从这个角度看，DeepSeek Harness 很妙。
它没有等到所有问题都想清楚以后，端出一个号称完美的 DeepSeek 版 Claude Code；它选择在模型能力和 Harness 范式都没有收敛的时候，把大家都动员起来、都 involve 进来，广纳天下之 Harness 贤才，共同探索未至之境。
DSH 今天当然只是一个 0.1 阶段的产品。
但 DeepSeek 真正试图争夺的，是 Agent 时代的演化权。
十字路口将在8.20(周四)晚上举办Agent Harness 线上闭门分享会，从DeepSeek Harness 带来发观察与思考聊起。欢迎对 Agent Harness 领域感兴趣的研究员、工程师、创业者参与。扫码报名。
参考资料
**[1]**代码以 MIT 协议开源在 GitHub 上：https://github.com/deepseek-ai/deepseek-harness
**[2]**0.1.0-rc：https://github.com/deepseek-ai/deepseek-harness/blob/master/package.json
**[3]**架构文档：https://github.com/deepseek-ai/deepseek-harness/blob/master/docs/architecture.md
[4]《A Programming Paradigm for Spatiotemporal Composability》：https://github.com/cordiverse/paper
**[5]**贡献指南：https://github.com/deepseek-ai/deepseek-harness/blob/master/CONTRIBUTING.md
**[6]**dsh-plugin：https://github.com/topics/dsh-plugin