DeepSeek Harness（DSH）这个刚开源不到一个月的智能体框架，正在以一种近乎“自毁”的方式重写自己的地基——而你的插件，可能明天就全废了。
2026年8月，DeepSeek在开源自家Agent框架DeepSeek Harness（简称DSH）之后不到三周，就连续发布了两个alpha版本。这不是普通的修修补补，而是一次从底层开始的重构——APIProxy没了，插件通信方式换了，会话被重新定义为“可回放的事件流”，就连插件作者自己写的自定义事件都可能让整个会话恢复不了。
事情没那么简单。
先搞清楚：Harness到底是什么
要理解这次更新有多狠，你得先知道DeepSeek Harness是干什么的。
DeepSeek Harness不是模型。DeepSeek V4是模型，Harness是让模型干活的那套“操作系统”。官方给的定义很直白：Agent = Model + Harness。模型负责思考和生成，Harness负责把模型接入现实世界——文件系统、终端、网页、API、权限、上下文。
你可以这么理解：模型是大脑，Harness是身体——手、脚、工具，全在这儿了。
DSH基于一个叫Cordis的微内核构建，核心理念是“一切皆插件”。模型适配器是插件，工具是插件，会话管理是插件，连主循环都是插件。这意味着你可以把任何一个组件拔下来换掉，不用重启整个系统。
这个设计本身很漂亮。但漂亮的设计和稳定的产品之间，隔着一道叫“开发者预览版”的鸿沟。
DSH从开源第一天就被明确标记为developer preview，官方白纸黑字写着“会有破坏兼容性的变更”。这不是客套话，是实打实的警告。
8月13日开源，8月17日出rc.7，8月19日出rc.8，8月28日出alpha.1，8月30日出alpha.2。三周之内，版本号从rc.5一路冲到alpha.2。每次更新都可能把你的插件炸掉。
这就怪了——一个刚开源的项目，为什么要这么急着拆自己房子？
APIProxy没了，插件通信一夜之间全换
alpha.1最大的变动，是把APIProxy彻底移除了。
APIProxy是什么？它是DSH旧架构里负责插件之间通信的传输层。插件A要跟插件B说话，得通过APIProxy中转。alpha.1把这个层整个砍掉，换成了Remote Gateway加一次性Token的机制。
这不是改个接口名，是整个通信协议的底层替换。以前插件作者写代码的时候依赖的那套API调用方式，一夜之间全废了。所有基于旧APIProxy写的插件，在alpha.1上直接跑不起来。
更麻烦的是，alpha.1还把SessionEvent.ignorable给移除了。
SessionEvent是DSH里记录会话状态的基本单元——每一次工具调用、每一条消息、每一个状态变化，都是一个SessionEvent。ignorable这个字段的作用是告诉系统：“这个事件如果丢了也没事，不用强行恢复。”
有些插件作者会用自定义的SessionEvent来记录一些辅助信息——比如“用户刚才鼠标划过了一个按钮”这种不重要的交互痕迹。这些事件被标记为ignorable，丢了就丢了，不影响会话核心状态。
alpha.1把ignorable整个删了。这意味着所有带自定义SessionEvent的插件，在升级之后产生的会话，可能再也恢复不了了。因为系统会把每一个事件都当作必须恢复的核心数据来对待，而插件自定义的事件格式可能跟新系统不兼容。
到了alpha.2，DeepSeek又把ignorable加回来了。但这件事本身已经说明了一个残酷的事实：DSH的底层架构还在剧烈晃动，插件作者连“这个字段下个版本还在不在”都说不准。
子代理可以换模型了——这是好事，但问题也在这儿
alpha版本里最让人兴奋的变化，是子代理（Subagent）终于可以独立配置模型了。
在alpha之前，DSH的子代理只能用主会话的全局模型配置——主会话用DeepSeek V4，子代理也得用DeepSeek V4，改不了。alpha之后，每个子代理可以单独指定provider、模型和推理力度。
这意味着什么？你可以在同一个会话里，让主代理用DeepSeek V4做全局规划，让Claude Code子代理写代码，让Codex子代理做代码审查。每个子代理用自己的模型、自己的推理参数、自己的token预算。
DSH正在从一个“模型调用工具”的简单框架，长成一个“多模型、多代理协同”的完整运行时。Subagent、Claude Code、Codex这些子代理，每个都可以有自己的模型provider、自己的推理力度、自己的最大输出长度。
但问题来了：子代理功能越强，对底层架构的依赖就越深。alpha.1把APIProxy拆了，子代理的通信路径也跟着变了。那些依赖旧通信方式写的子代理插件，一样会炸。
你以为它停了，其实它在狂奔
alpha发布之前，有一段时间DSH的npm包确实没动静。8月13日开源之后，到8月17日左右，公开仓库零提交、没有新release、没有新tag。有人开始嘀咕：这项目是不是没人管了？
实际情况正好反过来。DeepSeek团队不是不更新了，而是在做一个从rc到alpha的大版本跳跃——底层架构改得太快，连npm包的分发节奏都跟不上代码的变更速度。
alpha.1在8月28日发布，alpha.2在8月30日发布。两天一个alpha版本，每次都在动最底层的东西。Remote网关、RemoteError封装、插件作用域、重连机制——每一个改动都在重新定义DSH的“地基”长什么样。
DSH团队在做的不是加功能，是在重新打地基。他们把过去几年行业里关于“Agent运行时应该长什么样”的共识拆开，用“一切皆插件”的方式重新拼一遍。
这种重构方式带来的直接后果是：插件生态跟不上了。alpha.2发布当天，就有插件作者报告“所有插件都在出问题，有些直接让DSH起不来”。有插件不得不紧急发布alpha通道版本，声明“仅支持DSH 0.1.2-alpha.2，不再支持rc.8到rc.2的任何版本”。
一个刚开源三周的项目，插件已经超过5100个
说到这里，有个数字你得知道：截至2026年8月中旬，DSH的插件生态已经累积了超过5100个插件，作者超过3500人。
一个开源不到一个月的项目，插件数量到了这个量级，说明什么？说明社区的热情极高，也说明插件的质量参差不齐。很多插件是在rc版本上写的，用的还是旧APIProxy那套通信方式。alpha一出来，这些插件要么得重写，要么直接报废。
有开发者做了一个插件兼容性检测工具，专门用来“避免装上与当前Harness不兼容的版本”。这个工具的出现本身就是一种信号：兼容性问题已经严重到需要专门写工具来规避了。
更狠的是，有人专门建了一个仓库，用来测试“把插件放进一棵最小的Cordis树里能不能启动”——结论由DSH自己的启动审计给出。翻译成人话就是：你的插件能不能用，让DSH自己说了算，它说不行就是不行。
事情还没完
alpha.2恢复SessionEvent.ignorable这个改动，本身就很值得琢磨。
一个字段，alpha.1删了，alpha.2又加回来。这不是bugfix，这是设计决策的摇摆。说明DSH团队自己对“会话应该怎么恢复”“哪些事件该丢哪些不该丢”这些问题还没有完全想清楚。
而alpha.2在连接恢复方面的改动也暗示了同一个方向：会话被重新定义为“可回放的事件流”。传输连接重新建立不等于会话状态已经完整恢复——浏览器显示“Connected”只能说明WebSocket通了，不能证明所有被中断的事件都已经补齐。
DSH还在开发者预览阶段，官方明确说“会有破坏兼容性的变化”。这不是一句免责声明，是对现状的准确描述。
你的插件今天能用，明天可能就废了。这不是bug，是feature——在DSH的架构稳定下来之前，每一次更新都是一次抽奖。
而alpha.2发布时，npm的latest标签指向的还是rc.2。alpha版本要通过alpha通道才能获取。这说明什么？说明DeepSeek自己都知道，alpha这东西还不适合放进默认安装里。
但alpha.3什么时候来？又会拆掉什么？没人知道。