为什么需要动态组合？

一句话版：软件越来越需要"运行中装上、拆下、替换组件"，但现在的软件大多做不到——要么装了就拆不掉，要么一拆就要重启整个程序、丢掉所有状态。动态组合就是让这件事安全发生的能力，而它正是 DSH 和那篇 Cordis 论文要解决的核心问题。

先讲一个程序员的一天

小李维护着一个聊天机器人平台，用户装了几十个插件（天气、翻译、记账……）。

• 下午 2 点：用户反馈"翻译插件变慢了"。小李想换个翻译服务。
• 现实是：他必须停掉整个机器人（所有插件一起下线），改配置，重启。
• 重启后：用户 3 分钟没法用；之前缓存的热数据全没了；其他 29 个插件也被迫"陪跑"重启。

小李心想："我只是想换一个插件而已，为什么要把整个系统都拆一遍？"

这个问题，就叫"缺少动态组合"。

场景 1：插件系统（你天天在用，但你被它坑过）

拿全世界最流行的代码编辑器 VSCode 举例（论文里的真实数据）：

VSCode 把所有扩展（插件）装在一个共享进程里运行。想卸载其中一个含代码的扩展？只能重启整个编辑器。按安装量排前 100 的扩展里，有 87 个含可执行代码——也就是说，87% 的常用扩展卸载时都要重启。

为什么拆不掉？因为插件会"动过环境"：注册命令、监听事件、改设置。VSCode 不知道怎么把这些改动撤销，所以只能"眼不见为净"——重启，一切归零。

🎁 还记得第一章的厨房比喻吗？换厨师却要关店重新装修，这就是现状。

场景 2：自演化智能体（未来的常态）

上一节我们聊过，未来的智能体会自己写工具、自己装、自己卸，而且是在运行中、几乎没有人工盯着的情况下。

这意味着：

• 不能每次改动都重启——智能体可能一分钟改一次，重启 = 反复丢状态 + 反复宕机
• 不能装错了就炸——如果智能体装上一个有问题的模块，还把它自己的"恢复机制"弄坏了，那就真的叫天天不应了
• 不能悄悄破坏别人——新组件替换旧组件时，依赖它的其他组件必须自动适应，而不是悄悄出错

自演化不是科幻，它是 AI 发展的明确方向。而它能否安全落地，完全取决于动态组合做得够不够好。

拆解问题：两个维度

论文把"动态组合"拆成两个互不相关的（正交的）维度：

维度一：时间可组合性（装得上去，拆得下来）

把组件移除时，它之前对环境做的所有修改都必须完整撤销——就像拔掉一个插头，电路要恢复原样。

• 问题：组件"装"的时候改了一堆东西（注册、监听、缓存），"拆"的时候谁来负责还原？
• 现状：没人负责 → 只能重启兜底
• 目标：装上时自动记录，拆下时自动还原

维度二：空间可组合性（我需要什么，系统给我什么）

组件之间要能声明依赖、自动协调——依赖齐了才启动，依赖没了自动停。

• 问题：翻译插件需要"翻译服务"和"数据库"，如果只装了插件没装服务，怎么办？
• 现状：插件自己检查，检查不到就报错崩溃，或者互相等死
• 目标：系统盯着依赖变化，自动激活/停用组件，组件自己什么都不用管

💡 一句话记忆：时间维度管"拆了之后环境干不干净"，空间维度管"组件之间怎么协调"。两个维度互相独立，可以分开研究。

现有"土办法"：重启和容器

有人会说："重启就重启呗，现在的云服务不都这样吗？"没错，但代价很大：

论文管这叫粒度不匹配（granularity mismatch）：

我们只是想换一个"插件"，但重启是"杀鸡"，容器重启是"杀猪"。现代系统越来越多地在组件这个细粒度上进行组合——需要在和组件本身一样细的层次上管理效应和依赖。

如果有了动态组合，小李的一天会怎样？

同一个场景，有了动态组合（比如 DSH/Cordis）：

1. 小李在控制台点一下"翻译插件 → 切换服务商"
2. 系统自动：卸载旧翻译插件（它注册的命令、缓存全部还原）→ 安装新翻译插件
3. 依赖翻译服务的其他插件自动重启适配，不依赖它的插件纹丝不动
4. 全程没有重启，其他用户完全无感

这就是论文（和我们网站）想带你实现的目标。

关键点回顾

• 动态组合 = 运行中安全地装上 / 拆下 / 替换组件
• 两个维度：时间（拆了能还原）与空间（依赖自动协调）
• 现状的土办法（重启、容器）粒度太粗、代价太大
• 动态组合是插件系统和自演化智能体的共同刚需

🚀 下一章（第二章 · 论文研读），我们就正式进入那篇论文，看看用什么数学工具让"装上拆下"从"祈祷不出错"变成"结构性保证"。如果你还没接触过"效应/余效应"这两个词——别怕，第 5 课会从零讲起。