自己搭过插件系统的人都懂两个噩梦：卸载不干净，和依赖说不清。
第一个噩梦是，插件注册了一堆回调，卸载时漏掉一个，内存泄漏、事件错乱、behavior 变异。第二个噩梦是，插件 B 依赖插件 A 的某个服务，你得手动保证加载顺序，A 一被卸载，B 当场崩给你看。
这类问题积累几次，大部分项目宁可把模块写死，也不碰插件系统。
cordis 就是冲着这两个噩梦来的。它出自 koishi（6000+ star 的聊天机器人框架）作者 Shigma 之手，koishi 自己从 2022 年用到现在；现在它的 v4 重写，被 DeepSeek Harness 收编为底层插件框架。还配套了一篇正式论文。
它不是又一个插件框架，它在解决"插件为何可信"
普通插件框架的承诺是：你注册一下，它帮你调度。cordis 的核心承诺不一样：它的运行时跟踪每一个副作用，并且保证这些副作用可以完全回收。
这在 cordis 里叫 Time Composability（时间可组合性）：插件卸载 = 回到加载前的状态，一个回调都不剩。它不依赖插件作者自觉写 cleanup，运行时会统一登记事件监听、清理函数与服务注册，再统一处置。
另一个维度是 Space Composability（空间可组合性）：插件声明它依赖哪些服务（inject），运行时保证这些服务就绪后才启动它；被依赖的服务一旦消失，依赖它的插件自动卸载、不再执行。加载顺序写在类型里、由运行时裁决，不用靠 README 里「请先安装 XXX」的君子协定。
这两个维度合起来，就是它论文标题里的 Spatiotemporal Composability。术语唬人，翻译成大白话就是：插件可以即插即用、即拔即净，依赖关系自动维护。
项目卡片
- 项目：cordis[1]
- 状态：v4.0.0-rc.8（API 未冻结，活跃开发中）/ 6.7k Star / 周下载约 2 万（v3 由 koishi 生态贡献）
- 一句话判断：把「卸载副作用、响应依赖变化」做成运行时承诺的插件元框架，论文 + 双实战背书，但 v4 尚在 rc，图纸还没冻结
翻仓库时，我通常会先确认两件事：这套东西有没有被真实项目长期压过，卸载路径有没有自动化测试兜底。这决定了我愿不愿意花时间读它的新架构。
先说第一件：论文背后，是 koishi 四年的实战。
理论归理论，cordis 的 v3 确实在生产里跑了四年。v3 是 koishi 聊天机器人框架的运行时底座， @koishijs/core 至今仍依赖 cordis ^3.18.1 。聊天机器人框架恰好是插件模式的炼狱：几十个插件互相提供服务（数据库、HTTP、定时器、消息平台），用户随时装卸——cordis 在这类场景下周下载量约两万。
第二层背书来自 v4：DeepSeek Harness（agent 运行时项目）把 cordis 以 vendor 方式引入，作为整个 harness 的插件层，项目文档直接教你怎么用 cordis 写工具插件、LLM 插件、agent 编排插件。机器人框架 → AI agent 运行时，两代场景都靠它承载插件。
用起来什么样：建项目、写插件、改配置
实际用起来比想象中轻。 npm create cordis 生成项目（模板自带 CLI、数据库 SQLite/MySQL/PostgreSQL、WebUI、SSO 等全套官方插件），写一个插件就是一段函数：
const plugin = (ctx: Context) => {
const dispose = ctx.on('message', (msg) => ctx.logger.info(msg))
return dispose // 返回清理函数，卸载自动执行
}
await ctx.plugin(plugin)
这套东西最值钱的两个体验：
热更新不甩锅。改完配置或插件代码，HMR 会做依赖分析后只重载受影响的插件，加载失败还能回滚到旧版本、保持原状态，而不是直接崩进程。
配置即代码。项目入口是一份 cordis.yml ，支持表达式和变量插值，插件运行时改配置还能自动写回文件。
再说第二件确认：卸载路径有没有测试兜底。core 的测试里有一类用例叫 compare snapshot——把同一套插件装上、再整体卸下，事件钩子的快照与加载之前逐条相等。卸不干净在这里不是运气问题，是被测试拦住的属性。
边界：它现在还不是"值得梭哈"的状态
判断写在前面：想平替自己手上已在跑的模块架构，先等等。
cordis 仓库 README 第一行就写着「API 尚不稳定，可能不打招呼就变」。v4.0.0 从 alpha 一路测试到现在（rc.8），仍未发布正式版——长期打磨是好事，但也说明这是个耐力项目。生产环境要用，请锁版本、紧跟 changelog。
库主体之外的部分，也远没有 koishi 繁荣：koishi 生态有几百个现成插件，cordis 4 的官方插件虽已齐整（CLI、数据库、WebUI、SSO），第三方生态还在早期。
一句话决策：
- 在搭多插件长生命周期应用、受够了卸载残留与依赖乱序 → 值得现在尝鲜
- 想给产品换引擎且需要稳定 API → 等 4.x 正式版，或者继续用跑的更久的 v3
- 只是写几个脚本，没有插件化的需求 → 别在这棵树上浪费时间，直接用你的 cron
最后说句实在的：cordis 不是一个装上就能跑的库，它是一整套「插件系统应该怎么建」的理论在落地。读懂它，哪怕最终不用它，也会改变你对自己项目里依赖关系与生命周期管理的写法。
我的判断：现在把它放进观察清单，等 4.x 正式版冻结 API 之后，再认真试一轮。工程与论文相结合的框架在开源世界里不多见，这一点光凭 koishi 和 DeepSeek Harness 的背书，就值得它被记住。
引用链接
[1] cordis: https://github.com/cordiverse/cordis
发表于 4 天前
|
查看: 0|
回复: 0
