背景新闻： 2026年8月13日，DeepSeek 正式开源了 DeepSeek Harness（dsh）——一个“一切皆插件”的智能体（Agent）框架。发布不到一天，GitHub 星标已突破三万。
而就在同一夜，一篇由北京大学与 DeepSeek-AI 联合撰写的 88 页论文也浮出水面。它正是 DeepSeek Harness 的理论基石。Harness 团队负责人坦言，这是一个预览版本，但底层思想——那套让组件随意插拔而不留痕迹的“时空可组合性”范式——已经在这篇论文里被严格定义和证明。
想理解 DeepSeek Harness 为何如此设计？请往下看。
一、一个困扰所有插件系统的问题
想象你正在搭建一个 AI Agent 系统：
Agent Runtime
├── LLM（大模型）
├── Memory（记忆系统）
├── Tools（工具集）
├── Browser（浏览器）
├── Database（数据库）
├── Permission（权限系统）
└── Logging（日志）
今天，Agent 想安装一个新能力——BrowserSearchPlugin。它会注册工具、绑定事件、创建 HTTP 客户端、向上下文注入服务，并依赖日志和权限模块。
一切正常。
但过一会儿，你想卸载这个插件。你希望发生什么？
理想答案是：插件消失，注册的工具消失，监听器消失，提供的服务撤销，依赖它的组件自动停止，其他组件不受影响。
现实答案却是：大多数插件系统只能说一句“请开发者自己写 cleanup() 函数”。漏掉一个清理步骤？内存泄漏。监听器残留？诡异 Bug。依赖它的组件还在运行？一调用就崩溃。
最后，唯一可靠的手段往往是：重启整个进程。
论文将这种粗暴方案称为 “粗粒度的权宜之计”。这就好比为了关掉房间里的一盏灯，你把整栋楼的电闸都拉了。而现代软件（尤其是自进化的 AI Agent）越来越需要的，是组件级别的动态组合，而不是进程或容器级别。
二、拆解问题：两个维度
论文把“动态组合”这个宏大问题，拆成了两个清晰的维度。这构成了 DeepSeek Harness 架构设计的底层蓝图。
维度一：时间可组合性
我今天加载了组件，明天卸载它，系统能不能恢复到加载之前的状态？
加载插件 X 前，系统有路由 A 和 B；加载后多了路由 X；卸载 X 后，路由 X 消失，A 和 B 原封不动。组件移除后，它对共享环境做过的修改必须能够被完整、安全地撤销。
维度二：空间可组合性
组件之间的依赖关系能不能自动建立、变化和拆除？
比如数据库插件提供 DB 服务，业务插件依赖它。若 DB 插件被卸载，业务插件的依赖不再满足——它必须自动停止，而不是等到调用 db.query() 时才发现 db is undefined。
论文将这两者合称为 “时空可组合性”（Spatiotemporal Composability）。这也是 DeepSeek Harness 自诩“一切皆插件”的底气所在。
三、核心机制一：可逆效应——给每个操作配一个“撤销键”
为了在时间维度上做到“无损卸载”，论文提出了 “可逆效应”。
从“做了一件事”到“做了一件事 + 如何撤销”
以前我们只关心做事：
function addRoute(router, path, handler) {
router.add(path, handler); // 我只管加
}
现在，论文要求这样写：
function addRoute(router, path, handler) {
router.add(path, handler);
// 你必须同时返回一个“撤销函数”
return function undo() {
router.remove(path, handler);
};
}
这个 undo 就是 “逆操作”。每一个对环境修改（效应），都绑定了一个用于撤回的 “逆效应”。
自动组合：像叠盘子一样卸载
加载时是：开连接(A) → 建事务(B) → 改数据(C)。卸载时，逆操作自动按后进先出顺序执行：撤数据(C逆) → 回滚事务(B逆) → 关连接(A逆)。
论文称之为 “扭曲组合”。这意味着卸载逻辑不需要你额外写代码，而是从加载过程中自动推导出来的。
四、核心机制二：反应性余效应——让依赖关系像电路一样自动响应
解决了“怎么撤”，还要解决“什么时候撤”。这引出了 “反应性余效应”。
效应 vs 余效应
- 效应：我对环境做了什么（注册路由）。
- 余效应：我向环境要什么（需要数据库）。
传统代码用 global.db.query() 是“隐式依赖”，系统根本不知道。论文要求显式声明：
const BusinessPlugin = {
inject: ['database', 'logger'], // 我明说需要什么
apply(ctx) {
const db = ctx.get('database');
}
};
响应式依赖：变成“智能电路”
当组件声明依赖，系统就能构建依赖图，并像电路一样自动响应：
-
依赖满足：数据库插件加载，提供
database服务。电路接通，依赖它的业务插件自动激活。 - 依赖失效：数据库插件卸载，服务消失。电路断开，所有业务插件自动停用——而不是等到运行时报错。
这种模式，和现代前端框架（如 Vue 3）的响应式系统异曲同工。区别在于：Vue 是数据级响应，而 DeepSeek Harness 的底层是组件级、进程级的响应。
五、双剑合璧：Cordis 框架（理论的“实战化”）
基于这两个机制，论文作者构建了名为 Cordis 的元框架。它是连接理论与 DeepSeek Harness 的桥梁。
核心 API 极其简洁：
-
ctx.effect()：执行可逆操作，返回撤销器。 -
ctx.use()：加载组件，自动管理生命周期。 -
ctx.set()/ctx.get()：提供或消费依赖，自动传播变化。
至此，开发者不再需要手写复杂的 install/uninstall。组件的“卸载”逻辑，完全由加载时产生的“逆操作”组合而成。 这就是论文那句名言的落地：“teardown is derived from loading”（卸载源自加载）。
六、DeepSeek Harness：论文的“亲儿子”与工业级验证
Cordis 框架在 DeepSeek Harness 中得到了终极检验。Harness 的设计原则只有一句话：“一切皆插件”。
在 DeepSeek Harness 里：
- 模型、工具、技能、会话、沙箱、存储、循环、调度、UI……所有 Agent 能力都是插件。
- 每个插件都可以被动态加载、卸载、替换，且系统保证不留垃圾、不崩依赖者。
- 每一次运行都“有迹可循”：所有系统提示词、思维链、工具调用与结果、子 Agent 调度，都写入仅追加的会话日志，确保调试和审计的透明性。
Harness 提供了四种开箱即用的模式：标准、极简、创造、PTC（程序化工具调用），每种默认加载不同的插件集合。开发者可以像搭积木一样，根据场景自由组合。
用 Harness 团队的话说：“每一次运行都有迹可循”。而支撑这种“循迹”能力的，正是底层那套精准的“可逆效应”与“反应性余效应”机制。
七、现实边界：这不是“银弹”
论文和 Harness 非常诚实，指出了这套理论的边界。
1. 外部世界不可逆
Cordis 的可逆性仅限于它能控制和追踪的系统内部上下文。
- 内部：注册路由、启动定时器、提供依赖——可撤销。
- 外部：调用支付接口、发送邮件、写入共享文件——无法“撤销”。你没法通过框架撤回一笔已支付的款项。
对于外部操作，你能做的是“补偿”（如发起退款），但那是业务逻辑，不是框架能自动保证的。
2. 逆操作的真实性无法自动验证
框架虽然强制你提供“逆函数”，但它验证不了这个函数是否真的恢复了状态。
如果你在 effect 里分配了内存，却在 undo 里只打了个 console.log 而没释放——框架发现不了这个错误。保证逆操作的正确性，依然是开发者不可推卸的责任。
八、对你我的工程启示
即使你不用 Cordis 或 DeepSeek Harness，这套思想也能指导我们设计更好的系统。
设计插件、模块或服务时，问自己三个问题：
- 我改变了什么？ —— 列出所有“效应”（注册、监听、分配资源）。
- 我需要什么？ —— 声明所有“余效应”（数据库、日志、配置）。
- 如果我消失了会怎样？ —— 确保每个“效应”有“逆效应”，且依赖者能被通知。
当你设计的系统能清晰回答这三个问题时，你已经向 “时空可组合性” 迈进了一大步。
结语：从论文到产品的完整闭环
这篇论文的价值，远不止于一份 88 页的学术证明。
它从严格的数学定义出发，通过 Cordis 框架 完成理论落地，最终在 DeepSeek Harness 中实现了大规模生产验证——发布不到一天，三万星标，这是开发者社区用脚投票的认可。
这是一个从理论 → 框架 → 爆款产品的完整闭环。
它回答了一个无比工程化的问题：一个正在运行的系统，能不能像搭积木一样，把组件随时装进去、拔出来、换掉，且不留下脏状态，也不拖垮依赖它的邻居？
而现在，这个问题的答案，已经作为开源代码，写在了 DeepSeek Harness 的每一行里，等待着你的检验。
一句话封存这篇论文：
它试图把“插件的动态加入与退出”，从一种依赖开发者个人修为的“手艺活”，提升成一种由运行时、效应、依赖和生命周期语义共同保证的“编程范式”。
