CORDISDSH 的心脏第 01 章 · 由来全书目录术语表读论文原文 ↗
第一章 · 由来

一颗跑了快七年的心脏

dsh 七周拿下 24 万 star。可它最硬的那块地基,是 2019 年从一个聊天机器人框架里长出来的。这一章讲清四样东西的关系:论文、Cordis、Koishi、dsh。

约 5 分钟 · 上一章 开篇 · 下一章 02 问题

题图一张插线板,挂着一屋子电器。

DeepSeek 又出手了,这次不是模型

2026 年 8 月 13 日,DeepSeek 悄悄开源了一个新项目。(对,就是那个 DeepSeek。)没开发布会,没晒跑分,仓库名叫 deepseek-harness,大家顺口叫它 dsh。简介只有一句:Everything is a Plugin,一切皆插件。

然后它就停不下来了。七周之后,star 数是 241,568,PR 编号排到了五千多号,最近五条提交都落在同一天。那段时间,你的群里多半有人转过它。

harness 这个词可能有点陌生。它指包在 AI 模型外面的那层骨架:给模型装工具、管权限和沙箱、记下每一轮对话。模型负责想,harness 负责让它能动手。你用过的 AI 编程助手,外面都有这么一层。

「一切皆插件」到底有多狠

很多软件都说自己支持插件,意思通常是:核心是核心,插件挂在边上。dsh 的说法狠得多。按它的 README,产品的每个部分都是插件:模型适配器是插件,工具注册表是插件,会话记录是插件,连让 AI「想一步、做一步」的那个主循环,也是插件。

全都能靠改配置换掉,没有哪一块是需要打补丁的特权核心。想加功能,就在别的插件旁边再插一个。

这就引出一个懂行的人会愣一下的问题:

一个所有零件都能随时拔、随时换的程序,
一边跑一边换,凭什么不散架?

dsh 的 README 自己给了答案:它由 Cordis 驱动。

心脏的由来:一个聊天机器人框架

2019 年底,开发者 Shigma(石逸凡)开源了 Koishi:一个跨平台的聊天机器人框架,QQ、Telegram、Discord 上的机器人都能用它来写。

聊天机器人听着是个小东西,难题却一点不小。越来越多互不相识的人给 Koishi 写插件,这些插件塞在同一个进程里,随时装上、随时卸下,还互相调用。谁也不认识谁,谁也不能把别人弄坏。

这个难题你其实见过。给编辑器或浏览器装个插件,用腻了想卸,它说「请重启」。你只是想拿走一个零件,它却要整栋楼断电重来。Koishi 想做的,是让「拔掉一个零件」这件事平常到不值一提。

2022 年,Shigma 把 Koishi 里最硬的那块内核拆出来单独开源,取名 Cordis,来自拉丁语的「心脏」。此后四年多,Koishi 一直跑在这颗心脏上,攒下了 4000 多个社区插件 p.69。

图 1.1 · 一张插线板

谁都能插,谁都能拔

Koishi 的 4000 多个插件,像插在同一张插线板上的电器:出自不同的人,跑在同一个进程里,彼此只认插座上写的名字。

插线板要是做不到「拔一个不影响别的」,这个生态一天都撑不下去。论文里有句话写得很实在:哪怕是没经验的作者,不写一行卸载代码,也能得到有序的清理 p.69。

心脏的图纸:一篇 92 页的论文

2026 年,石逸凡(北京大学 & DeepSeek-AI)和合作者把这套跑了好几年的做法写成了论文:《A Programming Paradigm for Spatiotemporal Composability》,直译是《时空可组装性的一种编程范式》,全文 92 页。

「时空可组装性」听着吓人,意思很朴素:软件一边跑一边换零件,时间上要拆得干净,空间上要接得稳 p.4。下一章专门讲这两道题。

同一个月,DeepSeek 把 Cordis 连同它的加载器、热重载这些配套,整个搬进了 dsh 的仓库,不跟外部版本走,直接当成自家地基。这颗心脏,开始给一个 agent 供血。

论文 · 2026.08理论
《时空可组装性的一种编程范式》92 页
把跑通的做法写成理论
Koishi先例
2019 · 聊天机器人框架
4000+ 社区插件
拆出内核 · 2022
Cordis心脏
论文的实现
TypeScript 元框架
整体搬进仓库 · 2026
dsh新用法
DeepSeek 的 agent harness
一切皆插件
图 1.2四者的关系:先有跑了几年的 Koishi,从里面拆出 Cordis,再把 Cordis 的道理写成论文;dsh 是它最新、也最出名的用户。
时间 发生了什么
2019.12 Koishi 开源,聊天机器人的插件生态起步
2022.05 内核拆出来,单独开源为 Cordis
2026.08 论文挂上 arXiv;dsh 开源,地基是 Cordis
2026.10 dsh 241,568 star;Koishi 插件 4000 多个

为什么偏偏是 agent 用上了它

Koishi 的插件是人写的,装卸是人的节奏:一天几次,顶多几十次。agent 不一样。论文结尾点名了下一个验证场:自进化的 agent harness,也就是 AI 持续生成、替换自己运行环境里的组件,而且几乎没有人盯着 p.83。

换零件的节奏一快,「拆得干净」就从加分项变成生死线。假如一天替换几百次、每次漏一点,系统很快就会被残渣塞满。依赖关系频繁变动,「接得稳」也是一样。

所以这篇论文值得你花一个小时:它讲的不是某个框架怎么用,而是任何「边跑边换零件」的系统都绕不开的两道题。如果你在做 agent、做插件系统,或者只是想让自己的项目改一块不用重启全部,这本书接下来的规矩,都已经在 4000 多个真实插件身上跑过。