DeepSeek Harness 开源不到一周，star 破了 15 万。“一切皆插件”标语：这到底什么意思？谁在乎？：埋在标题底下的线索是，这东西用的是 Cordis v4，而 Cordis 已经在另一个叫 Koishi 的项目里跑了四年。
有人在议论：Cordis 在这个 harness 出现之前好像根本不存在，谁能讲讲它的演进？
图注：DeepSeek Harness 官网首页，标语”一切皆插件，运行有迹可循”，右侧弹窗是运行中的插件设置面板。图源：deepseek.com/harness，2026 年 8 月
我把 cordis 仓库、那篇 88 页的论文和 DeepSeek Harness（下文简称 DSH）源码都拉下来翻了一遍，想探索两个问题：Cordis 从哪来；它到底解决了 Agent 开发里的哪些问题，值得 DeepSeek 把 219 个包的框架地基压在它上面。
一个跨平台聊天机器人框架
2019 年 12 月，网名 Shigma 的开发者在 GitHub 上创建了 koishijs/koishi。Koishi 是个跨平台聊天机器人框架，主要活跃在 QQ 生态，名字取自东方 Project 里的角色古明地恋。这个仓库如今有约 6000 star，在机器人圈子之外几乎没有存在感。
2022 年 5 月，Koishi 发布 v4.7，官方发布说明里有一句不起眼的话：核心框架迁移并更名为 Cordis，搬到了独立仓库。Koishi 的上下文、插件系统、事件模型等底层能力被抽离出来，形成了 Cordis 这个”元框架”，也就是构建框架的框架。
图注：Koishi v4.7 官方发布说明，“将 Koishi 的核心框架迁命名为 Cordis”的原始出处（“迁命名”为官方原文用词）。图源：koishi.chat
2023 年 12 月，Shigma 在 Koishi 官方文档写了一篇设计文章《可逆的插件系统》。这篇文章系统阐述了 Cordis 的核心追求：一个插件无论加载、卸载多少次，系统行为只跟最终启用的插件有关，跟操作顺序无关。有意思的是，文末”畅想”一节里已经出现了”时间可组合性”和”空间可组合性”这对词。
2026 年 8 月 13 日，两件事同一天发生：deepseek-ai/deepseek-harness 仓库上线，README 第一段的原话是，它采用”一切皆插件”的架构，并由 Cordis 驱动，设计参见论文；同日，cordiverse 组织上传了论文《A Programming Paradigm for Spatiotemporal Composability》，时空可组合性编程范式，88 页，大量形式化证明，自述为持续修订中的预印本。
论文作者是三个人：Yifan Shi（网名 Shigma），挂北大与 DeepSeek-AI 双机构；张伟（Wei Zhang），北大计算机学院软件研究所副教授（北大官网可查）；崔添翼（Tianyi Cui），DeepSeek-AI。
图注：论文首页，三位作者与机构标注。图源：cordiverse/paper 仓库，2026 年 8 月 13 日版
Yifan Shi 是谁？几条证据摆在一起看：cordiverse/paper 仓库仅有的两个提交都来自 Shigma；Shigma 的 GitHub 公司栏现在写着 @deepseek-ai，这是他本人填的；量子位的报道直接确认了本名 Yifan Shi、GitHub 名 Shigma、Koishi 作者是同一个人，还提到他的名字出现在 DeepSeek V3 技术报告的作者列表里（他的中文本名没有可靠公开来源，本文不猜，下文一律用 Shigma 指代）。也就是说，从 Koishi 里沉淀的那套思想，原作者如今就在 DeepSeek，论文的机构栏也同时挂着北大和 DeepSeek-AI。三作崔添翼是竞赛和量化交易圈的老人，在 Jane Street 做了九年，今年加入 DeepSeek（据澎湃、量子位报道），论文发布当天他以 DSH 作者身份在 HN 答疑。
所以这条线索不是”DeepSeek 恰好找到一个合适的开源框架”，而更像：一个在跨平台聊天机器人场景里磨出来的架构思想，等到了它的下一个重量级使用者，而思想的原作者就在那个使用者的团队里。
下面逐一拆解。
问题一：装上去容易，拆下来难
Agent 运行时是个长期驻留的进程，里面塞满了工具注册、事件监听、子进程、网络连接。真正的难题从来不是”把代码加载进来”，而是加载进来之后还能不能安全拿掉。
论文用 VSCode 当反面教材，数据是团队自己从插件市场抓的：安装量前 100 的扩展里，87 个包含可执行代码，这些扩展一旦激活就没有运行时卸载的机制，禁用或删除都要重启整个扩展宿主，所有其他扩展陪着一起重启。论文接着说，这两个限制并非 VSCode 独有，在插件系统里普遍存在，只不过程度不同。
放在 Agent 语境下，代价被急剧放大。论文 1.2.2 节把这个场景叫做自进化的 Agent Harness：未来的 Agent 可能根据任务自己生成一个工具，自己装进运行时，发现问题再自己换掉。如果每次改动都要重启进程，正在执行的任务被打断，进程内积累的上下文和缓存全部丢失；论文里有句很实在的话：一次错误的自修改，可能把恢复它自己所需要的那个进程一起干掉。
Cordis 的解法，是把副作用管理收进上下文。凡是经 Cordis 管理的修改，都通过上下文登记，并自带一个逆操作，运行时把这些逆操作按后进先出的顺序记录成一条撤销链。卸载插件时反向执行这条链，注册的工具被注销、监听的事件被移除、打开的连接被关闭，其他插件不受影响。2023 年那篇设计文章甚至给了数学表述：副作用在函数复合下构成幺半群，配上逆元就构成群。开发者不需要理解这些，只要调用 ctx.effect() 注册副作用并返回清理函数，框架负责回收。这套保护也有边界，Shigma 在同一篇文档里明说：设置全局变量、调用未封装的 API，仍然可以绕过 Cordis，所以严格讲它是机制加纪律，不是语言级保证。
这不是 DSH 的宣传话术，是它的工程铁律。DSH 给贡献者的约定开宗明义：所有注册都是效应，每个贡献都走 ctx.effect() 或 ctx.on()。我在源码里数了数，ctx.effect() 的调用超过一百处，遍布 LLM 运行时、agent 注册表、工具运行时、会话存储、子进程管理、终端、沙箱。比如持久终端插件的清理逻辑就一行：ctx.effect(() => () => this.disposeAll(), 'pty teardown')，PTY 会话在插件卸载时全部回收。
问题二：谁先启动，缺了谁怎么办
Agent 框架的第二个日常难题是依赖编排。工具插件依赖 LLM 服务，LLM 服务依赖凭证插件，浏览器工具依赖沙箱。传统做法要么手写启动顺序，要么靠幸运，缺依赖的时候是当场 crash 还是静默错乱，全看各插件自己怎么写防御代码。
Cordis 把这件事交给声明。每个插件用 inject 声明自己需要哪些服务，声明了就等待，服务全部就位才激活；依赖缺失时保持未激活状态，不报错也不启动，等服务出现。提供者下线时，依赖它的插件先停下来、撤完自己的副作用，提供者再完成卸载。谁先谁后不由加载顺序决定，由依赖关系自动推导。论文把这套机制叫”反应式余效应”（reactive coeffects），余效应这个词太学术，工程上理解成响应式的服务依赖就行。
DSH 源码里这是最普遍的模式：声明 inject 的文件有 364 个。最能说明问题的是 Agent 循环本身，整个框架的心脏，packages/core/agent-loop 的类定义上写着：
static inject = ['agents', 'sessions', 'llm', 'tools', 'systemPrompt']连 Agent 主循环都是一个插件，它声明自己需要会话、LLM、工具、系统提示词五个服务，缺一个就不启动。这就是”一切皆插件”的实际含义：主循环和第三方工具装在同一个容器里，遵守同一套依赖和生命周期规则，谁也不是特权公民。
问题三：自己给自己动手术
前两个问题解决之后，才轮到那个最激进的可能性：Agent 给自己的运行时写插件。
论文把这件事列为 Cordis 的核心动机之一。DSH 里它已经是一个能跑的组件包 tool-cordis，默认不开启，属于刻意设计的选装项，官方目录注明它不在任何出厂组合中，要用 demo 命令或配置手动加载。它给模型提供了七个工具：
cordis_inspect_list/cordis_inspect_query/cordis_inspect_self三个只读检查工具：列出可用的检查 provider，按 provider 查询服务目录、事件、内置 API 和当前 Agent 可见工具，并检查本会话创建的动态插件（包的 README 还写着五个工具，把三个检查工具合成一个，是少见的官方文档滞后于源码）；cordis_define写一个新插件，宿主半边加浏览器半边；cordis_run在沙箱里求值并挂载到活运行时；cordis_stop把它撤回到静止；cordis_undefine彻底删除定义。
也就是说，你可以让 Agent 在对话里现场写一个仪表盘插件，装进自己正在运行的进程里，用完再让它干净地拆掉，全程不重启。tool-cordis 本身也是一个 Cordis 插件，它注册的这七个工具同样受这套生命周期机制管理，等于用自己宣传的规则实现自己。
边界写得很清楚：动态插件只存在于进程内存，不落盘、不改配置文件、重启即消失，官方明说沙箱隔离了全局变量但不是安全边界，想保留成果要走的还是正常的插件开发流程。
这是一个小而完整的自进化样本：生成、部署、验证、撤销，四步都发生在同一个活进程里。能不能走到论文设想的”持续服务中自我修改”还有很长的路，但地基已经在了。
四年4000+插件，和18项加固
一套架构主张值不值钱，要看它在敌对环境里活过多久。论文选的验证场景就是 Koishi：四年，超过 4000 个社区插件，从即时通讯适配器、数据库驱动到管理控制台，由互不相识的作者独立编写，唯一的协调方式就是 Cordis 的依赖声明。
图注：Koishi 插件市场，截图时显示 4141 个可用于 v4 的插件。图源：koishi.chat/market，2026 年 8 月 19 日
论文案例研究给了三个可核实的观察：
- 管理员从控制台禁用一个插件，副作用原地撤回；
- 开发时保存文件，热重载只重新应用被改的插件，缓存和连接保持不动；
- 切换存储后端，只有依赖实际变化的插件被重新激活，其余纹丝不动。
论文也没有把案例包装成完美证明，威胁到效度的部分写得老老实实：单一生态、单一语言、观察性研究而非对照实验，结论是”存在性与采用的结果，而非定量的”。
DSH 这边同样不是拿来主义。九个 Cordis 系包以源码方式 vendor 进仓库，全部改名 @deepseek-ai/*，官方理由是框架层完全自有：可审计、可打补丁、可锁定版本。vendor 记录里列了 18 项本地修改，读起来像一份认真的接管清单：fiber 生命周期加固，关闭了三个重入处置的缺口；Loader 改造成事务性的，插件配置应用失败会回滚到上一个稳定状态；还把上游一个延迟解析配置的 PR 移植了过来。生产用的 Koishi 还停在 Cordis v3，论文和 DSH 用的是重构过的 v4。
判断与边界
为什么是 Cordis？
图注：Agent 开发的三个难题与 Cordis 的三个机制。图源：本文自制，源码统计为 2026 年 8 月本地 clone 后计数
我的判断是，它恰好把 Agent 框架最难啃的三块工程问题各给了一个机制层的答案：能力装卸不可逆，用撤销链解决；依赖编排靠手写，用声明式注入解决；自进化没有地基，用前两者的组合托底。这套机制在聊天机器人场景里被四千个插件用了四年，又在 DSH 的 219 个包底下当承重墙。
DSH 不是贴牌使用，而是深度改造后的重注。
如果你要拿这套东西评估别的 Agent 框架，我提炼出三个检查点：
- 卸载一个组件要不要重启整个进程；
- 依赖缺失时组件是崩溃还是安静等待；
- 注册和清理是不是在同一处成对声明、由运行时统一追踪，而不是靠作者散落在各处的清理函数自觉。
三条里不达标的越多，那个框架的插件化就越停留在组装层面。
最后回到那条线索。2019 年为了跑聊天机器人开的仓库，2022 年抽出底层框架，2023 年写成一篇中文设计文档，2026 年变成超过 15 万 star 的 Agent 框架 DeepSeek Harness 的地基（star 数为 8 月 19 日抓取自 DSH 仓库，还在涨）。
Shigma 在 2023 年那篇文章里写：“Cordis 的名字来源于拉丁语的心。我希望它能成为未来软件 (至少是我开发的软件) 的核心。”
当时读起来像是个人项目的浪漫口号，现在看，这个框架认真照做了。
