原標題：《DeepSeek的「自進化」藍圖，曝光了》

Jay 發自凹非寺量子位 | 公眾號 QbitAI

DeepSeek與北大合作的最新論文，掀開了Harness版鯨魚的面紗。

名叫《A Programming Paradigm for Spatiotemporal Composability》，中文譯為《一套處理時空可組合性的程式設計範式》。

聽上去有點繞，你只需要記住一句話就好——

全文圍繞Cordis展開，這是黑鯨的核心，一個可以隨意插拔的「樂高底板」。

在這裡，萬物皆插件，萬物可重組。

這也解釋了為什麼「黑鯨」的開放程度如此之高，官方也如此鼓勵大家搓插件、魔改Harness。

資訊量爆炸的一篇論文，也是DeepSeek Harness團隊蓄力這麼久的集大成之作吧，最終以大黑鯨的形式打了一場漂亮仗。

值得注意的是，這是DeepSeek今年的第七篇論文，也是第N次和北大合作。

總共八十多頁，我抱著論文從頭到尾啃了一遍，大概整理出了幾點Takeaway——

1、Cordis提供一套通用的動態組合語意。經過Context管理的元件可以動態載入、卸載，並自動回收其受管理的副作用。

2、數學根基來自型別論裡兩個經典概念，效應和餘效應。

3、並非實驗室玩具。這套設計已經在Koishi聊天機器人框架上跑了四年，超過4000個社群插件在生產環境裡驗證過。

而這一切的一切，都服務於同一個野心——

自進化。

01 時間與空間，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的核心。

論文標題裡「時空可組合性」的直觀含義，就在這。

02 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 的升級版。

03論文作者介紹

最後照例聊聊論文作者。

共有三位，橫跨北大和 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/paper

Koishi：https://github.com/koishijs/koishi

OpenAI已於上月解散Preparedness團隊

熱門文章