Cordis：给动态组合一个形式化基础

当插件系统、Agent 框架、热重载机制都在各自造轮子时，cordiverse/cordis 试图把"可组合性"本身变成一门编程范式。

GitHub 链接：https://github.com/cordiverse/cordis
论文：https://github.com/cordiverse/paper

一个老问题

你写过一个 VSCode 插件吗？或者一个 Obsidian 插件、一个 Chrome 扩展、一个 Agent 工具？

如果写过，你大概率踩过这些坑：

• 插件卸载后留下了脏状态——配置文件没清、事件监听器没解绑、全局变量还挂在那
• 插件 A 依赖插件 B，B 升级了 A 就崩了
• 想做热重载，但旧实例的副作用没法回滚，只能重启整个应用
• 两个插件同时修改同一个文件，谁先谁后全靠运气

这些问题看起来是工程问题，但 cordiverse 团队认为它们其实是理论问题——我们从来没有形式化地定义过"什么是可组合的"。

Cordis 的论文标题是《A Programming Paradigm for Spatiotemporal Composability》，2026 年 8 月 13 日放出预印本。它不是又一个框架，而是一个"元框架"（meta-framework）——它定义的是框架应该怎么被组合起来。

两个正交维度

Cordis 把"可组合性"拆成两个独立的维度：

时间维度的可组合性（Temporal Composability）：当一个组件被移除时，它产生的所有副作用都能被完全回滚。

空间维度的可组合性（Spatial Composability）：组件之间的依赖关系是声明式的，当依赖变化时组件能被响应式地通知。

这两个维度看似无关，但 Cordis 的核心洞察是：它们可以用同一套数学工具解决——效果（effect）和协效果（coeffect）。

如果你没听过这两个词，不用慌。简单说：

• 效果是组件对环境做的事（写文件、发请求、改全局状态）
• 协效果是组件对环境的需求（需要某个配置存在、需要某个服务可用）

经典编程语言理论里，这两个概念已经存在了几十年。但 Cordis 做了一件新事：把它们从编译时类型系统提升到运行时机制。

可逆效果与响应式协效果

具体来说，Cordis 形式化了两个概念：

可逆效果（Revertible Effects）：每一次上下文变换都携带一个逆函数。运行时跟踪这些逆函数，当组件被移除时，逆函数按相反顺序执行。

这就像 Git 的 revert，但发生在类型系统层面——不是你手动写 undo 逻辑，而是类型系统保证每个操作都有对应的逆操作。

响应式协效果（Reactive Coeffects）：每个组件声明自己的协效果规格，当上下文变化时，组件被自动通知。

这像 React 的 useEffect 依赖数组，但泛化了——不只是组件内部的状态订阅，而是跨组件的依赖管理。

最关键的一步：Cordis 把效果上下文和协效果上下文统一成同一个上下文类型。这不是简单的拼接，而是数学上的统一——一个 calculus of dynamic composition，把单个组件的可组合性扩展到整个交错组件系统。

为什么现在重要

你可能会说：这些概念听起来很学术，跟我有什么关系？

关系在于：Agent 时代让动态组合变成了刚需。

传统软件是静态的——你编译时就知道所有组件是什么。但 Agent 系统是动态的：

• Agent 运行时加载新工具
• Agent 之间临时组合协作
• 工具版本在运行时升级
• Agent 失败后需要回滚到之前的状态

这些场景下，"可逆"和"响应式依赖"不再是锦上添花，而是系统不崩溃的前提。

Cordis 论文里有一句话特别精准：

Modern software—from plugin systems to self-evolving agent harnesses—increasingly requires dynamic composition, yet its formal foundations remain underdeveloped.

翻译一下：我们在造越来越动态的系统，但理论基础一直没跟上。

Cordis 实现了什么

Cordis 不只是论文，它有 TypeScript 实现，包含：

• 核心库：效果跟踪 + 协效果解析
• 声明式组件加载器：配置调和 + 热模块替换

这意味着你可以用 Cordis 写一个插件系统，每个插件：

• 加载时声明自己的效果和协效果
• 卸载时自动执行所有逆操作
• 依赖变化时被自动通知

不需要手写 cleanup 逻辑，不需要手写依赖管理。

一个概念谱系的最新成员

Cordis 的核心思想可以放进我一直在追踪的一个概念谱系——"换层面解决问题"：

• 章鱼 RNA 编辑：不改 DNA 蓝图，改施工图
• 黏菌外化记忆：不用神经元，用黏液轨迹
• 鸟类量子磁感应：不用磁场计，用自由基对
• SOPHIA 分工：不统一处理，按状态分流
• EvoThink 原子推理：不优化整条链，给推理流分段
• Möbius RoPE 拓扑干预：不改频率，改位置编码的拓扑
• 螳螂虾声子盾牌：不硬抗冲击波，选择性过滤
• Euclid-MCP 推理外包：不训练模型推理，外包给 Prolog
• ACE 上下文工程：不堆上下文，分段压缩
• Cordis：不手写 undo，把可逆性变成类型系统的属性

这十一个案例的共同模式：不是更强地做同一件事，而是换一个层面让问题消失。

Cordis 换的层面是：把"如何回滚"这个问题从工程层（手写 cleanup）提升到类型层（每个操作自带逆操作）。一旦提升到类型层，回滚就不再是"可能忘记写"的代码，而是"不写就编译不过"的约束。

一个诚实的 caveat

Cordis 论文开篇就声明：

Cordis is under active development. The API is not yet stable and may change without notice.

这是 8 月 13 日的预印本，还在活跃修订。论文也明确说"内容可能大幅变化"。所以现在不是"用 Cordis 生产"的时候，而是"看 Cordis 思路"的时候。

但思路本身值得认真对待。动态组合的形式化基础是个真问题，Agent 时代让它变得更紧迫。Cordis 给出的答案——可逆效果 + 响应式协效果 + 统一上下文类型——是一个有数学骨架的方案，不是又一个"我们封装好了"的框架。

写在最后

Cordis 让我想到一个老笑话：软件工程就是把这些东西加到一起然后希望它跑起来——配置管理、依赖注入、生命周期管理、回滚机制、事件系统。每个框架都重新发明一遍，每个都不兼容。

Cordis 问的是：如果这些不是工程实践，而是类型系统的属性呢？

如果这个方向成立，未来我们写插件系统时，不再需要手写"卸载时清理什么"——类型系统会告诉我们。Agent 框架不再需要手写"工具失败后怎么回滚"——运行时自动执行逆操作。

这个未来还远，但 Cordis 至少把路标立起来了。

项目信息

• GitHub: https://github.com/cordiverse/cordis
• 论文: https://github.com/cordiverse/paper
• 语言: TypeScript
• 状态: 预印本阶段，API 不稳定
• 今日 stars: 616（2026-08-15 上榜）