DeepSeek 最近连续发布了两项重量级成果。
最新的旗舰 Pro 模型，把模型能力再次拉到了行业焦点；DeepSeek Harness（运行框架），则让国内也有了一个可以跟 Codex、Claude Code 放在同一张桌子上讨论的 Agent 框架，而且它是开源的。
但随着这两项发布一起出现的，还有一个很容易被忽略、却更值得讨论的东西：一篇近百页的论文。
它不是模型报告，不是训练论文，更不是模型卡。
那它到底在讲什么？DeepSeek 团队为什么要发这样一篇论文？
它真正讨论的不是模型。 在这篇论文他们讨论了一个 Runtime（运行时）框架叫 Cordis。它不负责让模型更会回答问题，而是负责管理 Agent 系统里的插件、服务、依赖和卸载。 当模型可以不断升级，工具可以不断增加，权限可以不断调整，子代理可以不断组合。当这些变化开始持续发生，决定系统能不能长期稳定运行的，就不再只是模型，而是背后的软件架构。 而论文指出：Agent Harness——也就是承载 Agent 运行的那层框架——如果要从一次性脚本变成长期运行的智能软件系统，就不能只会加载组件，还要能解释组件被卸载、替换、重排以后，系统为什么还能回到一个可理解的状态。
所以它尝试做的，不是再造一个更强的模型或系统，而是为这类持续演化的 Agent 系统建立一套软件架构，并用形式化方法和数学证明描述系统在运行过程中如何组合、替换、回滚，以及如何在变化中维持可控性。
要理解这篇论文，可以先从一个更具体的问题进入：一个正在运行的系统，拔掉一个插件以后，凭什么不崩？
这不是普通插件系统的问题，而是运行时换件的问题。等这个问题立住以后，再看论文怎么回答它。
一、这不是插件系统的问题，是运行时换件的问题
论文先用了两个场景说明传统插件系统的边界。
第一个场景是 VS Code。
论文的批评点不是 VS Code 做得不好，而是它代表了一类常见插件系统：扩展可以动态安装，但运行中的单个扩展很难像进程一样被组件级卸载。
很多时候，禁用或卸载扩展之后，要让系统接近干净状态，仍然需要重启宿主进程。
第二个场景是自我演化的 Agent Harness。
Agent 运行时不是一次性脚本，而是一个持续服务请求的系统。它可能要在不中断会话的情况下加载新工具、换模型适配器、替换 Prompt（提示词）模板、调整子代理策略。
如果每次换件都要停机重启，Agent 就很难变成长期运行的工作系统；如果每个插件都要自己手写清理和依赖适配，系统也很容易堆出一层没人敢碰的隐式状态。
所以论文真正问的不是”插件怎么写”，而是：
一个运行中的系统，能不能在组件级别做到加载、卸载、替换，并且尽量不把一致性完全交给开发者自觉？
这就是本文说的运行时换件：系统不停止，组件在变化，运行时还要说得清变化前后发生了什么。
论文把这个问题称为动态组合问题，并拆成两个正交维度：一个管”卸载以后能不能回去”，一个管”依赖变化以后谁会知道”。接下来分别看。
二、时间可组合性（temporal composability）：卸载以后能不能回去
先看一个粗线条的比喻：一艘潜水器正在深海执行长期任务，不能浮出水面，却要在任务途中拆掉一只老机械臂，再接上一只新钻探模块。
难点不在于新模块有多强，而是在旧机械臂被卸下时，液压管、通信线和控制接口能不能被干净切断，不留下漏油和悬空信号；新模块接上后，中央控制系统能不能重新识别它、分配电力和指令。
论文的时间维度处理的就是这个：系统已经在运行，能力还在变化。每次热插拔之后，旧组件走得干净，新组件接得平稳。
这不是说今天的 Agent 运行时已经普遍做到不停机演化。现实里很多软件更新仍然要停机重启，不少 Agent 桌面端产品也不例外。
一个插件加载后，会对环境做很多修改：注册一个工具、挂一个事件监听、启动一个后台任务、添加一个服务。卸载时，这些修改通常要按相反方向撤回。论文把这件事形式化为 revertible effects（可逆副作用）：每次修改环境，都要同时记录可以撤销它的反向操作。运行时负责追踪，卸载时按反序执行。
用人话说：不要只写”我装了什么”，还要把”我怎么拆掉它”和安装动作绑在一起。
这就是时间维度的账本：谁改了什么，怎么撤回来。
三、空间可组合性（spatial composability）：依赖变化以后谁会知道
插件不只修改环境，也会依赖环境。
比如一个工具插件需要 LLM 服务，一个子代理插件需要会话服务，一个 UI 插件需要状态服务。
时间维度管的是”拆得干净”，空间维度管的是”接得稳”。
一个插件依赖的服务如果变了，依赖方不能等到下一次调用才发现。论文把依赖声明变成系统可检查的东西：服务变化时，依赖方要自动进入更新流程。
论文把这件事形式化为 reactive coeffects（反应式余效应，可以粗略理解为“组件对上下文的需求”）：插件声明自己需要什么，运行时在上下文变化时重新检查这些声明。
用人话说：不要靠启动顺序猜依赖，要让依赖本身变成系统能看见的东西。
这就是空间维度的账本：谁需要谁，变化了怎么通知。
这两个维度互相独立。一个系统可以卸载干净，但不知道依赖是否还成立；也可以感知依赖变化，但卸载后留下残余。
这张图用换模型适配器的场景把两本账放在一起：时间维度把旧适配器的注册按反序撤干净，空间维度让依赖它的组件感知变化、重新接上新的。
四、它证明的是账本，不是产品成熟
理解这些定理的边界，比记住结论本身更重要。
论文确实给了形式模型、操作语义和定理。但这些定理不是在说”现实世界里任何插件都不会出问题”。它讨论的是：在论文定义的模型和条件下，如果组件用可逆副作用描述自己对环境的修改，用反应式余效应描述自己对环境的需求，那么生命周期规则可以把单个组件的约束扩展到整个系统。
翻译成三句话：
第一，副作用要可逆。
插件注册能力时，运行时记录对应的撤销动作。卸载时不完全靠插件作者临时记忆，而是按运行时已经收集的撤销链条回滚。
第二，依赖要能反应式更新。
插件声明需要哪些服务。服务提供者变化时，运行时重新解析依赖，让消费者进入合适的生命周期状态，而不是等到某次调用才炸。
第三，最终状态可以像静态装配一样推理。
论文的结论不是”任何历史都无差别”。
在满足论文设定的一组条件下，比如外部编排输入一致、无失败发生、依赖声明完整等，不同的生命周期调度最终会到达等价状态。论文把这称为合流性（confluence）定理。
换句话说，一组组件交错加载、卸载、重载以后，只要最后进入满足条件的静止状态，就有机会像一开始就按最终配置装好那样被推理。
这才是它对工程的价值：它不是消灭复杂性，而是给复杂性划边界。
对做技术选型的人来说，这意味着：选择”一切皆插件”的 Harness，不能只看它能不能装，还要看它有没有这套账本。没有账本的插件系统，规模越大，隐性成本越高。
但这也必须说清楚：论文里的保证不是产品成熟度证明。更准确的说法应该是：
Cordis 论文没有证明 DSH 已经适合所有生产场景；它说明的是，DSH 选择”一切皆插件”背后，不只是工程口味，而是一套可以被形式化讨论的运行时模型。
五、DSH 真正押注的是运行时账本
DeepSeek Harness 的官方 README 写得很直接：它是 DeepSeek AI 开源的 Agent Harness，采用”everything is a plugin”（一切皆插件）架构，并由 Cordis 驱动。
DeepSeek 的 Harness 官网也把模型、工具、技能、会话、沙箱、存储、循环、调度和 UI 都列为可替换、可重组的插件能力；仓库架构文档进一步把模型适配器、工具注册表、会话日志、Agent 主循环这些最底层组件都写进插件树。
这意味着，至少在官方设计口径里，DSH 不是在一个固定核心旁边挂几个扩展点，而是把运行时本身拆成可组合能力。
这时 Cordis 的意义就变了。它不是一个普通的 DI（依赖注入）容器，也不是为了让代码看起来更优雅。它提供的是一套运行时纪律：
- 能力通过上下文暴露，而不是到处 import 具体实现；
- 依赖通过
inject声明，减少单纯靠启动顺序赌运气； - 适合回滚的注册通过
ctx.effect()/ctx.on()一类机制进入可释放链条，而不是散落在各处； - 服务、事件和生命周期都进入同一套插件系统，而不是每个模块自己发明一遍扩展机制。
这也解释了为什么 DSH 会把 Agent Harness 做得这么”重”——有人直接说这是过度设计，是技术自嗨。如果目标只是跑一次代码生成任务，手写一个循环确实就够了；但如果目标是在运行中换模型、换工具、换权限、换子代理、换 UI，框架就绕不开一个问题：“换了以后系统还算不算干净”。
DSH 甚至把”运行中改写自己”做成了一个官方预设：Creator Mode（创造模式）允许 Agent 检查运行时插件树，动态挂载或卸载临时插件——正是前面说的那种自我演化场景。
但它默认关闭，信任等级等同于 shell 访问权限，临时插件只存在进程内存里，重启即清空。这份克制恰好说明：在把改写自己的权力交给 Agent 之前，运行时先得有一本可追踪、可撤销的账。
六、总结：模型回答问题，Harness 管住运行时
模型负责回答问题。
Harness 负责管住运行时。
状态、依赖、生命周期，这些都不是模型自己会处理的事。
很多时候，决定一个 Agent 能不能在真实系统里长期活下来的，不是它用了多聪明的模型，而是它的 Harness 有没有一本清晰的账：谁安装了什么，谁依赖什么，谁退出时清理了什么。
一切皆插件，从来不是一句设计口号，而是运行时账本的承诺。