VSCode的top 100扩展中87个包含可执行代码但卸载时几乎都需要重启整个extension host。只有7个声明了依赖关系。这意味着当前最流行的插件系统在动态卸载和依赖管理两个方向上基本是放弃状态。装插件容易卸插件靠重启。2026年8月13日DeepSeek开源了Agent运行时框架Harnessdsh同步发布一篇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 Harnessdsh的核心设计原则是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页论文证明的不是一个产品功能而是一个工程底线。
VSCode的top 100扩展中87个包含可执行代码但卸载时几乎都需要重启整个extension host。只有7个声明了依赖关系。这意味着当前最流行的插件系统在动态卸载和依赖管理两个方向上基本是放弃状态。装插件容易卸插件靠重启。2026年8月13日DeepSeek开源了Agent运行时框架Harnessdsh同步发布一篇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 Harnessdsh的核心设计原则是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页论文证明的不是一个产品功能而是一个工程底线。
