VSCode的top 100扩展中，87个包含可执行代码，但卸载时几乎都需要重启整个extension host。只有7个声明了依赖关系。

这意味着当前最流行的插件系统，在"动态卸载"和"依赖管理"两个方向上基本是放弃状态。装插件容易，卸插件靠重启。

2026年8月13日，DeepSeek开源了Agent运行时框架Harness（dsh），同步发布一篇88页的技术论文。论文不讲模型能力，不讲产品功能，只解决一个问题：当一个系统的所有组件都是插件，且插件可以在运行时被动态加载、替换、卸载，怎么保证每一次操作都能安全撤回。

这不是抽象的学术问题。如果未来Agent要能在运行中修改自己的组件——换一个工具、加载一个新能力、替换一段推理逻辑——那么"修改后能不能完整恢复"就是工程上的一票否决项。

一、插件卸载：一个被回避了二十年的工程难题

1.1 副作用残留

插件不是孤立存在的。一个插件被加载后，它通常做了三件事：

• 注册了事件监听器
• 分配了系统资源（内存、连接池、定时器）
• 修改了全局状态或上下文

当你卸载这个插件时，这三件事的"痕迹"并不会自动消失。监听器还在监听，定时器还在跑，全局状态还是被改过的值。

主流解法是让开发者手动写清理逻辑——类似C++的析构函数或React的useEffect cleanup。但这依赖开发者的自觉和记忆力。一个复杂系统有几十上百个插件，每个插件都靠人肉写dispose，遗漏是必然的。

1.2 依赖断裂

更棘手的是依赖关系。插件B依赖插件A提供的服务。A被卸载后，B还在运行，但它调用的服务已经不存在了。

轻则空指针异常，重则整个系统状态不一致。现有工程实践对此的回答通常是：不允许运行时卸载，或者卸载后重启整个进程。

1.3 Agent场景的特殊性

这个问题在Agent场景下被放大了。

传统软件的插件由人类开发者编写和管理，变更频率低。但Agent框架的设计目标是让Agent自身具备动态加载和替换组件的能力——一个AI Agent在执行任务过程中，可能需要临时加载一个新工具、替换一个推理策略、甚至修改自己的执行循环。

如果每次修改都不可逆，或者修改后的状态无法恢复，系统就会在反复试错中积累"垃圾状态"，最终崩溃。论文称之为"屎山上叠屎山"。

自演化Agent的前提不是"能改"，而是"改了能撤"。

二、DeepSeek Harness的架构选择：没有特权内核

2.1 一切皆插件

DeepSeek Harness（dsh）的核心设计原则是"Everything is a Plugin"。这不是说外围能力可以插件化——很多框架都做到了——而是说连最核心的组件都是插件：

• 模型适配器是插件（DeepSeek官方模型只是众多选项之一）
• 工具注册表是插件
• 会话日志是插件（append-only事件流，Resume/Fork/Replay共享同一事件流）
• 沙箱策略是插件（默认workspace-write，失败关闭）
• 审批策略是插件（决定哪些操作需要人工确认）
• Agent Loop本身也是插件（可以被整体替换）
• UI也是插件（默认Web UI，可换成CLI/TUI）

没有"核心Harness + 外挂插件"的分层。Harness自己就是由插件拼出来的。

2.2 Cordis微内核

支撑这套架构的是一个叫Cordis的插件微内核，核心源码只有9个文件。Cordis的作者是Koishi框架的创建者——Koishi是一个高度插件化的聊天机器人框架，社区生态中已有超过4000个插件在运行时验证过这套架构。

Cordis解决的不是"怎么装插件"，而是"怎么卸插件"——以及卸载之后，怎么保证系统状态干净。

一个标准部署包含133个插件，每个都能独立启停。这意味着在任何时刻，系统状态都是133个插件副作用的叠加。要安全地卸载其中任何一个，需要知道它到底做了什么。

三、两个正交维度：时间可组合性与空间可组合性

论文将插件卸载问题拆解为两个正交维度，并给出了各自的解法。

3.1 时间可组合性：可逆副作用

问题：插件被移除时，它做过的所有事情必须被完全回滚。

解法：Cordis要求所有对Context的修改都通过ctx.effect进行。每次修改，组件必须同时留下一个对应的inverse（逆操作）。

比如：

• 注册监听器时，同时留下注销方法
• 启动定时器时，同时留下关闭方法
• 修改全局状态时，同时记录旧值

Runtime把这些inverse按顺序记录。当组件被卸载时，系统按相反顺序逐一执行。

这类似于RAII或useEffect cleanup，但被提升为运行时强制机制，而不是靠开发者自觉。你不写inverse，框架就不让你注册effect。

3.2 空间可组合性：响应式协效应

问题：插件之间的依赖关系必须被结构化声明和动态解析。

解法：组件提前声明"我依赖什么"。当Context发生变化时，Runtime重新检查依赖是否还成立，并将变化分为三种状态：

• activating：原本缺失的依赖出现了，组件可以激活
• deactivating：依赖消失了，组件进入停用
• neutral：变化与该组件无关，保持不变

比如一个会话日志插件依赖数据库服务。数据库出现时，插件启动；数据库被卸载后，Cordis检测到依赖失效，让插件自动退出——而不是继续访问一个不存在的服务。

开发者不需要轮询依赖是否可用，也不需要处理"依赖突然消失"的边界情况。Runtime在notify()和refresh()两个方法中完成了全部协调。

3.3 汇合性：不同路径，相同终态

论文给出了一个关键性质——Confluence（汇合性）：

假设系统最终需要A、B、C三个组件。它可以一开始就加载A、B、C；也可以先装A，再装D，后来卸掉D，替换B，最后得到A、B、C。

只要可组合条件成立，两条完全不同的运行路径，最终得到的系统状态是等价的。

这意味着Agent可以不断试错——加载新组件、卸载旧组件、替换策略——但试错历史不会永久污染Runtime。每一次"折腾"之后，系统都能回归到一个确定的纯净终态。

这是自演化Agent的工程基础：进化不需要从零开始，但每一步进化都必须可回溯。

四、从架构到实践：四种预设模式

DSH内置了四种预设模式，每种加载不同的插件集合：

标准模式：日常开发，文件编辑、Shell、检索、Skills、计划、子代理全开。适合大多数Agent任务。

PTC模式（Program-The-Computer）：通过Code Mode SDK让模型生成TypeScript代码编排多轮工具调用。关键设计是中间数据留在运行环境中，只有最终结果进入上下文，大幅降低Token消耗。适合复杂多步任务。

极简模式：仅保留持久bash和str_replace_editor两个工具。适合基准测试，剥离多余能力后评估模型裸能力。

创造模式：在标准能力外开放运行时检查与插件实验能力，让Agent反向帮你设计和创建新preset。用Agent造Agent。

换模式等于换一份插件清单。这不是配置参数层面的切换，而是整个Runtime组件组合的重组。因为Cordis的可逆副作用保证了这种重组的安全性——卸载旧插件集的副作用会被完整回滚，加载新插件集从干净状态开始。

五、争议与边界

5.1 组件细化的O(n²)膨胀

论文自己承认了一个风险：当组件进一步细化、彼此之间存在大量交互时，为了保持组件独立性而额外引入的integration component，可能呈O(n²)级增长。

插件粒度越细，单插件越简单，但插件间的协调成本越高。这不是Cordis独有的问题——所有微内核架构都面临这个权衡。区别在于Cordis用形式化证明保证了"不会因为协调而出错"，但"协调本身的性能开销"是证明不了的。

5.2 学习曲线

Cordis的核心概念——效应、协效应、时空可组合性——对不熟悉OSGi、React useEffect的开发者来说有学习曲线。88页论文的学术密度不低。

但如果目标真的是自演化Agent——让AI自己修改自己的组件——那么这种形式化保证就不是过度设计，而是必需品。一个会自我修改的系统，如果不能用数学证明"每次修改都是安全的"，就是定时炸弹。

5.3 早期阶段

DSH目前是v0.1 Developer Preview。团队负责人坦承"还很不完善"。如果用Claude Code的产品完成度来衡量，DSH还有明显差距。但它的定位不是产品，而是底座——官方提供的Coding Agent只是一套预置preset，开发者可以拆开重组。

六、对Agent架构设计的工程启示

启示一：Agent框架的核心难题是状态管理，不是模型调用

大部分Agent框架把精力放在"怎么让模型调用工具"上。但实际工程中，真正出问题的是状态管理——上下文怎么传、副作用怎么管、组件怎么换。

DSH把这个问题摆到了架构层面用运行时机制解决，而不是靠开发者纪律。这个思路值得所有Agent框架借鉴。

启示二：自演化的前提是可回滚

"Agent修改自己"听起来很科幻，但工程上只分解为两个问题：修改后的状态能不能恢复？依赖关系能不能自动调整？

Cordis用可逆副作用解决前者，用响应式协效应解决后者。两个解法都不依赖AI的"智能"，而是依赖运行时的机制保证。这意味着即使Agent做出了错误的自我修改，系统也能安全回退。

启示三：插件化不是万能药

"一切皆插件"的代价是组件间的协调成本。在简单场景下，单体架构的效率远高于插件化架构。插件化只在需要动态扩展、运行时重组、多团队协作的场景下才有价值。

对企业来说，如果你的Agent应用场景固定、工具集稳定、不需要运行时动态调整，那么一套硬编码的Agent框架可能比插件化的DSH更实用。插件化是手段，不是目的。

收尾：Agent的"操作系统"时刻

88页论文的核心贡献不是发明了新概念——可逆副作用和响应式依赖管理在软件工程中都有先例。它的贡献在于把这些机制统一为一个形式化框架，并用数学证明了五个关键性质：保持性、时间可组合性、空间可组合性、进展性、汇合性。

这些证明指向一个具体目标：让Agent在运行中修改自己的组件，且每次修改都能安全撤回。

当AI Agent从"执行固定流程"走向"动态调整自身架构"，运行时的可组合性就不再是锦上添花，而是地基。

这个地基打好了，自演化Agent才有工程上的可能性。打不好，每一步"进化"都是在屎山上加层。

DeepSeek选了一条难路：不是做一个更好的Agent产品，而是做一个Agent能安全修改自己的运行时底座。这条路能不能走通，取决于Cordis的形式化保证在真实大规模插件生态中是否成立。

但方向是对的。Agent的竞争正在从"谁的模型更强"转向"谁的运行时更可靠"。88页论文证明的不是一个产品功能，而是一个工程底线。