DeepSeek的「自进化」蓝图,曝光了
2 小时前 / 阅读约10分钟
来源:36kr
DeepSeek与北大合作论文提出Cordis编程范式,解决插件系统时间与空间可组合性问题,通过可逆效应和反应式余效应实现插件动态加载与卸载,已在Koishi框架验证。

DeepSeek与北大合作的最新论文,掀开了Harness版鲸鱼的面纱。

名叫《A Programming Paradigm for Spatiotemporal Composability》,中文译为《一套处理时空可组合性的编程范式》。

听上去有点绕,你只需要记住一句话就好——

全文围绕Cordis展开,这是黑鲸的核心,一个可以随意插拔的「乐高底板」。

在这里,万物皆插件,万物可重组

这也解释了为什么「黑鲸」的开放程度如此之高,官方也如此鼓励大家搓插件、魔改Harness。

信息量爆炸的一篇论文,也是DeepSeek Harness团队蓄力这么久的集大成之作吧,最终以大黑鲸的形式打了一场漂亮仗。

值得注意的是,这是DeepSeek今年的第七篇论文,也是第N次和北大合作

总共八十多页,我抱着论文从头到尾啃了一遍,大概整理出了几点Takeaway——

1、Cordis提供一套通用的动态组合语义。经过Context管理的组件可以动态加载、卸载,并自动回收其受管理的副作用。

2、数学根基来自类型论里两个经典概念,效应和余效应。

3、并非实验室玩具。这套设计已经在Koishi聊天机器人框架上跑了四年,超过4000个社区插件在生产环境里验证过。

而这一切的一切,都服务于同一个野心——

自进化。

时间与空间,Harness自进化的两道坎

软件世界有一个反直觉的现实:大多数支持插件系统,卸载一个插件后,需要重启整个宿主进程。

这意味着,删掉的可能只是一个插件,陪着它一起重启的,却是所有已经加载的插件。

是的,「插」件,实际上插上去就拔不下来。

VSCode是典型案例。

论文表示,截至2026年6月9日,VSCode Marketplace排名前100的扩展中,87个包含可执行代码,一旦激活就无法在运行时单独卸载,禁用或删除后必须重启整个扩展宿主。

这不是VSCode一家的问题。论文指出,几乎所有的插件架构都存在这类缺陷,只不过程度不同。

这事儿放在普通插件系统里,已经够麻烦了,但如果成本只是重启的话,也还可以接受。

但在Agent的语境下,完全是另一个问题。

一个常规的马鞍,里面通常塞满了一堆东西:工具集、执行环境、权限控制、沙箱、会话状态、记忆系统……本身就是极度复杂的工程系统。

而如今,又遇上了「自进化AI」这个孙悟空,一不留神可能就自己给自己改没了。

这也是DeepSeek这篇论文切入自进化的角度:

未来的Agent可能会根据任务,自己生成一个工具,自己把工具装进运行时,发现有问题以后,再自己把它替换掉。

如果每次改一行代码,都要把整个进程重启,那之前积累的上下文、缓存,全部可能崩掉。

这叫时间可组合性

如果模块之间的依赖靠每个模块自己打补丁,今天检查一下有没有A,明天猜一下B……一不留神就会引入循环依赖,等到重新加载时,就会爆雷。

这叫空间可组合性

而这两个难点,也正是Cordis要解决的两个问题。

DeepSeek的解法

首先要补充两个数学知识点,也是这篇论文的两大理论支柱——

效应和余效应。

简单来说,效应刻画「程序对世界的影响」;余效应刻画「世界对程序的约束」。两者是对偶关系:效应系统丰富的是类型,余效应系统丰富的是上下文。

但有个问题,自进化AI语境下,框架是动态加载的。

经典效应/余效应是静态类型系统工具。

为了同时迈过时间与空间两道坎,团队将这两个概念,针对Agent运行时进行了一次适配升级——「可逆效应」和「反应式余效应」。

可逆效应(revertible effects),剑指时间维度。

核心定义只有一句话:每个对上下文的修改,都必须配一个显式的逆函数,这样,副作用就是可逆的。

加载插件时,每次修改状态都会把对应的逆函数记录下来,按顺序叠加成一条「撤销链」。

卸载插件时则反向执行这条链,系统状态就能精确恢复到插件加载之前的样子。

可以理解为一摞盘子,最后放上去的那只,先拿走。

这样,时间顺序就不会乱了。

反应式余效应(reactive coeffects)则负责空间维度。

在Cordis里,组件可以声明自己需要哪些依赖,从而实现依赖要可解析。

比如一个聊天插件说,我需要一个消息适配器和一个数据库。两个依赖都满足,它才进入ACTIVE。缺一个,它保持INACTIVE,不急着启动,也不先跑起来再因为空引用报错。

提供者出现,依赖者自动激活。提供者撤走,依赖者先停下来,等它把自己的effect撤回之后,提供者再完成卸载。

依赖提供方卸载了,依赖方自动停用;依赖重新上线,依赖方自动恢复。这个拓扑编排不靠开发者手写,从声明里自动推导。

两者结合,构成了Cordis的核心。

论文标题里「时空可组合性」的直观含义,就在这。

Koishi

所以,刚刚说的这些,有经过实践验证码?

有。

而且体量还不小。

论文用来做实验验证的,是一个叫Koishi的聊天机器人框架。

Koishi基于Cordis构建,四年积累了超过4000个社区插件,覆盖即时通讯适配器、数据库驱动、管理控制台和各类用户功能。

GitHub显示,Koishi是一个跨平台、可扩展、高性能的聊天机器人框架。

它的名字和图标设计来源于来源于东方Project中的角色古明地恋(Komeiji Koishi)。

古明地恋是一个会做出无意识举动的角色,取这个名字既象征着聊天机器人的主题,也蕴含了开发者为之倾注的热爱。

也是挺有意思的一份README了。

那Cordis是什么?

Koishi作者表示,Cordis的名字来源于拉丁语的心,Koishi的一切都从Cordis开始。

作为一个元框架,Cordis并不耦合任何具体的领域或场景。

它所提供的能力是大多数框架都不足为奇的——插件系统,但在这个系统背后却是大多数框架都没有达成的目标:可逆性。

还留下了这么一句话:

我希望它能成为未来软件(至少是我开发的软件)的核心。

四年过去,DeepSeek这篇论文,给出了验证。

首先是时间维度的验证。

在Koishi里,管理员可以从控制台禁用一个插件,插件对系统的影响会原地撤回,其他插件继续工作。

开发时,插件修改并保存后,会重新应用被修改的插件,缓存和连接保持不动。

接着是空间维度的验证。

Koishi生态里,IM适配器提供消息平台接入,数据库驱动提供持久化存储,功能插件声明这些为依赖直接访问。

实际运行过程中,切换存储后端或重连适配器时,只有依赖发生了实际变化的插件才会被重新激活,依赖没变的插件纹丝不动。

要知道,这些插件通常是不同作者独立开发的,彼此之间唯一的协调就是Cordis强调的那个反应式余效应。

这说明,一套动态组合规则,确实能在由不同作者贡献的开放插件生态里工作。

但论文也没有把这个案例包装成一个完美demo。

团队承认,目前只有Koishi单一生态、TypeScript单一语言的验证数据,缺乏与替代架构的受控对比……

但最重要的还是指出了一条新方向吧,一套服务于自进化的Agent Harness基础施。

而今发布的DeepSeek Harness,正是Koishi Cordis的升级版。

论文作者介绍

最后照例聊聊论文作者。

共有三位,横跨北大和DeepSeek

一作叫Yifan Shi,来自北京大学,同时也是DeepSeek成员。

一通深挖后发现,原来早在DeepSeek V3 Technical Report的中,便曾出现过他的名字。

这篇新论文里那个用来验证的项目——Koishi——也是出自他之手。

看得出来对「shi」有很强执念了,本名叫Yifan Shi、项目叫Koishi、GitHub名叫Shigma。

(doge)

回归正题。

Koishi是个四年前的仓库,如今已有5.7K星星。可以说,这是一切的源头。

因为Cordis的概念,也是在Koishi里提出来的。

2023年,Shigma给Koishi官方文档写了一篇设计文章,题目叫可逆的插件系统,几乎就是这篇新论文的祖宗。

张伟(Wei Zhang),同样来自北京大学,是北大计算机学院软件研究所的副教授。

学院官网显示,张伟的研究领域主要涵盖软件工程、程序设计语言。

1999年,他从南京航空航天大学工程热物理专业本科毕业。随后转向计算机方向,2002年获得南京航空航天大学计算机科学硕士学位。

硕士毕业后,张伟进入北京大学继续攻读博士,并于2006年获得计算机软件与理论博士学位。

博士毕业之后,他直接留在北京大学任职,此后一直从事软件工程、程序设计语言等方向的研究和教学工作。

值得注意的是,早在2021年的ASE,张伟便和Yifan Shi合作过。

2024年,两人又一起发了ICSME 论文Focused: An Approach to Framework-oriented Cross-language Link Specification and Detection。

最后就是老熟人了。

崔添翼DeepSeek Harness团队负责人。本科毕业于浙江大学计算机系,梁文锋学弟。

上学期间,崔添翼曾因NOIP/信息学竞赛保送浙大,还6次拿下ACM国际大学生程序设计竞赛亚洲区域赛金牌。

毕业后,他又先后在Jane Street香港和纽约办公室工作9年。

论文链接:https://github.com/cordiverse/paperKoishi:https://github.com/koishijs/koishi