深度拆解 DeepSeek Harness 架构：AGI 的自进化，终于有了「后悔药」

DeepSeek：一切皆插件，包括 Harness

作者丨樊天骄

编辑丨岑 峰

8 月 13 日，DeepSeek 正式开放 DeepSeek Harness v0.1 Developer Preview。项目非常火热，截至 8 月 14 日下午，DeepSeek Harness 在Github 上已经获得了4.5 万星。

不过这次比较值得讨论的倒不是 DeepSeek 又做了一个 Coding Agent，而是它对Harness 提出了一个明确概念：

一切皆插件。

过去的 Harness 像一个固定浇筑的大楼，遵循一个相对固定的结构：核心 Harness + 外挂插件。

用户可以在外围增加 Skill 或者接入 MCP 等其他工具，但工具调用、会话管理、沙箱、存储以及 Agent Loop 等底层运行机制，通常已经由厂商提前搭好并封装在产品内部，普通用户无法直接修改。

这次 DeepSeek Harness 把这栋“固定的大楼”拆成了一盒乐高：

不只是外围能力可以插件化，连 Model Adapter、Tool Registry、Session Log，甚至 Agent Loop 这样的核心组件，也都可插拔。

也就是说，没有什么核心 Harness 或者外挂插件的分别了，Harness 自己就是由插件拼出来的。

01

核心架构 Cordis

为什么 DeepSeek 连核心都要插件化？

Deepseek 给出的答案是：实现 Self-Evolving Agent Harness 。

Harness 不只是调用固定能力，而是能够在运行过程中生成、替换自己的组件。这样 Agent 不只是调用 Harness 提供的能力，它甚至可以开始检查、挂载和修改自己的 Runtime。

也正因为如此，Runtime 本身需要先被拆成可以动态组合的对象。

不过这时候有个问题：如果所有东西都能动，怎么保证不把系统搞爆炸？

对此，DeepSeek-AI 与北京大学研究者联合发表了一篇名为《A Programming Paradigm for Spatiotemporal Composability》的论文，并提出了一套名为Cordis的动态组件框架。

这套机制曾经长期运行在Koishi里——这是一个高度插件化的开源聊天机器人框架，拥有数千个社区插件；

而 Cordis 位于它更底层，最初解决的是普通软件中的插件卸载问题：插件安装后会留下监听器、服务、定时器等副作用，而 Cordis 负责记录这些变化，并在插件卸载时完整撤销。

Cordis 核心要做到两件事：

第一个是Temporal Composability，时间可组合性。简单来说，就是一个组件被卸载以后，它此前对系统产生的影响能不能一起撤销。

比如一个 Plugin 注册了事件监听、占用了资源或者修改了某些运行状态，那么 Plugin 消失之后，这些“副作用”也应该被完整清理，让系统尽可能恢复到它加入之前的状态。

第二个是Spatial Composability，空间可组合性。

它解决的是组件之间的依赖问题：一个组件可以声明自己需要哪些能力，当提供这些能力的其他组件出现、消失或者被替换时，Runtime 如何能够重新处理这条依赖关系，并协调相关组件的生命周期。

在 Koishi 里，这套机制解决的是一个复杂插件生态如何动态运行的问题：插件可以被拔掉，但它留下的影响也要跟着消失；一个 Provider 被替换以后，依赖它的其他插件也要知道自己接下来该怎么办。

所以 Cordis 在 DSH 里的意义就比较清楚了：

如果 Agent 未来真的要修改自己的 Harness，“自定义”只是第一步。更重要的是，修改之后还能撤回，以及被修改组件背后的依赖关系还能继续正常工作。

02

DeepSeek 做了什么新的扩展

那么，Cordis 如何解决时间可组合性和空间可组合性两大议题？这就要说到：Revertible Effects 和 Reactive Coeffects：

Revertible Effects，我们可以称它为“可撤销副作用”。它解决的是组件修改 Runtime 之后，怎么把这些修改再撤回来。

Cordis 要求所有对 Context 的修改都通过ctx.effect进行。每执行一次修改，组件都需要同时留下一个对应的 inverse，也就是“撤销方法”。

比如，注册监听器时留下注销方法，启动定时器时留下关闭方法。而 Runtime 会把这些 inverse 按顺序记录下来，当组件被卸载时，系统会按照相反顺序逐一执行。

但把自己留下的东西收拾干净还不够。组件之间往往存在依赖关系：如果它依赖的 Provider 被移除、替换或重新注册，Runtime 还需要及时感知这种变化，并重新调整相关组件的状态。这正是 Reactive Coeffects 要解决的问题。

Reactive Coeffects，我们可以暂且称它为响应式协同依赖。它解决的是：组件之间的依赖关系，如何随着 Runtime 的变化自动调整。

Cordis 的做法是让组件提前声明“我依赖什么”。当 Context 发生变化时，Runtime 会重新检查并判断这些依赖是否还成立。Deepseek 团队将其分为了三种情况：activating、deactivating 和 neutral。

如果原本缺失的依赖出现了，组件就可以激活；原本存在的依赖消失了，组件就会进入停用；而如果变化与它无关，则保持不变。

比如，一个聊天记录插件依赖数据库服务：数据库出现时，它可以启动；数据库被卸载后，Cordis 会发现依赖已经失效，并让这个插件随之退出，而不是继续访问一个已经不存在的服务。

在实现上，这套机制对应notify( )和refresh( )：当某个依赖被增加或删除时，Cordis 会找出受影响的组件，并重新判断它们是否应该继续运行。

此外，Cordis 还有一个很有意思的结论：Confluence，合流性。

假设一个 Runtime 最终需要 A、B、C 三个组件。它可以一开始就直接加载 A、B、C；也可以先装 A，再装 D，后来卸掉 D，替换一次 B，最后重新得到 A、B、C。只要论文规定的可组合条件成立，并且系统最终稳定下来，那么这两条完全不同的运行路径，最终得到的系统状态应该是等价的。

这就是 Cordis 面向 Self-Evolving Harness 的核心愿景：试图让 Agent 可以不断试错，但不让试错历史永久污染 Runtime。这一机制确保了 AI 的进化过程不再是“屎山上叠屎山”，而是每一次重启都能回归纯净的终态。

03

插件化了，代价是什么？

关于 DSH, 争议是在所难免的。

首先是价格。DSH 本身虽然开源，但真正运行仍然依赖模型 API。

而从 8 月 17 日开始，DeepSeek 将全面上调 V4 API 价格。以 DSH 默认的 V4 Flash 为例，空闲时段缓存未命中输入上涨 50%，输出上涨 125%；高峰时段则分别涨至原来的 3 倍和 4.5 倍。V4 Pro 的缓存命中价格在高峰期甚至达到原来的 12 倍。

这对 Harness 尤其敏感，因为 Agent 并不是一次问答，而是不断携带上下文并且调用工具继续推理。模型单价上涨之后，一个需要几十轮甚至更多调用的长任务，成本会被进一步放大。

另一方面，则是“一切皆插件”可能带来的组件膨胀。关于这方面有网友质疑，DSH 将一些原本可以直接通过脚本或代码修改完成的能力，也统一包装进 Plugin 体系，是否增加了不必要的抽象成本。

这种担忧并非毫无依据。Cordis 论文自己也承认，当组件进一步细化、彼此之间存在大量交互时，为了保持组件独立而额外引入的 integration component，在一般情况下甚至可能呈 O(n²) 级增长。

当插件细化到原子级，组件间的交互成本可能呈平方级爆炸，这或许是 DeepSeek 这种追求工程极致的公司面临的最大挑战。

而这种平方级膨胀带来的影响也不只体现在组件数量上。随着组件越来越多，配置项、依赖关系以及整个 Runtime 的理解和维护成本，都可能随之上升。

因此，DSH 最终是否成立，不能只看 Agent 能不能修改自己的 Harness，还要看这种修改是否真的能持续提升任务表现。

如果 Agent 改错后无法完整恢复、长期运行产生状态残留，或者自修改带来的复杂度和成本超过性能收益，那么它仍然只是一套很有想象力的软件架构实验，而非已经成熟的自进化方案。

参考链接：https://x.com/0xcherry/status/2087915568716566636

https://github.com/cordiverse/paper/blob/main/paper.pdf

上车，带你看遍全球 AI 顶会精华

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

未经「AI科技评论」授权，严禁以任何方式在网页、论坛、社区进行转载！

公众号转载请先在「AI科技评论」后台留言取得授权，转载时需标注来源并插入本公众号名片。