8 月 13 日，DeepSeek 正式开放 DeepSeek Harness v0.1 Developer Preview。截至 8 月 14 日下午，该项目在 GitHub 上已获得 4.5 万星，热度可见一斑。不过，这次更值得关注的并非 DeepSeek 又推出了一款 Coding Agent，而是它对 Harness 提出了一个明确概念：一切皆插件。
传统 Harness 架构如同固定浇筑的大楼，遵循“核心 Harness + 外挂插件”的结构。用户可以在外围增加 Skill 或接入 MCP 等工具，但工具调用、会话管理、沙箱、存储以及 Agent Loop 等底层运行机制，通常由厂商提前封装，普通用户无法直接修改。而 DeepSeek Harness 将这栋“固定的大楼”拆成了一盒乐高：不仅外围能力可插件化，连 Model Adapter、Tool Registry、Session Log，甚至 Agent Loop 等核心组件也都可插拔。换言之，Harness 自身就是由插件拼合而成，不再有核心与外挂的严格区分。
这一设计的目标是实现 Self-Evolving Agent Harness——Harness 不只是调用固定能力，而是能在运行过程中生成、替换自己的组件。Agent 甚至可以检查、挂载和修改自己的 Runtime。为此，DeepSeek 与北京大学研究者联合发表论文《A Programming Paradigm for Spatiotemporal Composability》，并提出名为 Cordis 的动态组件框架。Cordis 此前长期运行于高度插件化的开源聊天机器人框架 Koishi 中，最初解决的是插件卸载后的副作用清理问题。
Cordis 核心解决两大问题：时间可组合性与空间可组合性。时间可组合性指组件卸载后，其副作用能否完整撤销；空间可组合性则处理组件间的依赖关系——当提供能力的组件出现、消失或被替换时，Runtime 如何协调相关组件的生命周期。
在实现上，Cordis 引入了 Revertible Effects（可撤销副作用）与 Reactive Coeffects（响应式协同依赖）。前者要求所有对 Context 的修改都通过 ctx.effect 进行，并留下对应的“撤销方法”，卸载时按相反顺序执行；后者则让组件提前声明依赖，当 Context 变化时，Runtime 重新判断依赖是否成立，并分为 activating、deactivating、neutral 三种状态处理。此外，Cordis 还提出 Confluence（合流性） 概念：只要可组合条件成立，不同加载路径最终得到的系统状态等价，从而确保 Agent 可以不断试错而不污染 Runtime。
不过，插件化也带来争议。首先是成本：DSH 虽开源，但运行仍依赖模型 API。自 8 月 17 日起，DeepSeek 将全面上调 V4 API 价格，以默认的 V4 Flash 为例，空闲时段缓存未命中输入上涨 50%、输出上涨 125%，高峰时段分别涨至原来的 3 倍和 4.5 倍；V4 Pro 缓存命中价格在高峰期甚至达到原来的 12 倍。对 Harness 这类需要多轮上下文调用的 Agent 而言，成本压力将被显著放大。
其次是组件膨胀问题。有网友质疑，DSH 将一些本可直接通过脚本修改的能力也统一包装进 Plugin 体系，可能增加不必要的抽象成本。Cordis 论文也承认，当组件细化且交互频繁时，为保持独立性而引入的 integration component 可能呈 O(n²) 级增长，导致配置、依赖及维护成本上升。
因此，DSH 能否真正成功，不仅取决于 Agent 能否修改自己的 Harness，更在于这种修改能否持续提升任务表现。若改错后无法完整恢复、长期运行产生状态残留，或自修改的复杂度与成本超过收益，那么它仍只是一套有想象力的架构实验，而非成熟的自进化方案。