一棵目錄樹先被排好了：DeepSeek Harness 的插件機制，是一套被設計出來的閱讀結構

2026 年 10 月 16 日，掘金上出現了一篇標題為「DeepSeek Harness 進階，認識 DeepSeek Harness 插件機制，並從 0 到 1 實現一個插件」的長文，作者署名「大模型真好玩」。文章本身是技術教學，但其中一段原始碼目錄結構的展示，值得用設計的眼光多看一眼：一套智慧體工具的架構哲學，往往先被寫進一棵目錄樹裡，然後才被寫進說明文件。

先從那棵樹的一個分支看起。packages/core 底下並列著六個名字：session、system-prompt、tools、agent、agent-loop、scope。這六個詞各自對應一項能力，事件溯源的會話日誌、系統提示詞的組裝、工具註冊表、Agent 型別定義、驅動迴圈、作用域隔離。命名全部是單字或複合字，沒有編號，沒有縮寫，也沒有廠商前綴。讀者即使不懂 Cordis 框架，光看這六個名字，也能大致拼出這套系統運作時的先後關係：先有 session 記錄，再有 prompt 組裝，然後工具進場，agent-loop 把整件事轉起來。

這是目錄命名作為介面的典型案例。與之對比的是 packages/core 之外的分組方式：llm、shell、client 這類目錄本身不含程式碼，只負責把相關插件聚在一起。核心與周邊的差別，就被這層「目錄是否裝東西」的安排悄悄表達出來了。

文中最關鍵的一段事實，是 DeepSeek Harness 的插件能力並非自研，而是建立在 Cordis 這個 TypeScript 插件框架之上。Cordis 最初為 Koishi 聊天機器人服務，在這裡的職責被切得很乾淨：只管插件的載入、卸載、依賴與生命週期，完全不過問智慧體怎麼運作。而會話管理、工具使用、智慧體循環，乃至 UI 介面，全部交給插件實現。

這種分工讓「一切皆插件」從口號變成可以指認的結構。插件把自己提供的服務註冊進共享上下文，其他插件再依賴這些服務長出更多能力。文舉的例子是 tool-skill 相關插件依賴 tools、session 等核心服務。換句話說，整個系統的擴充性被設計成一種疊層關係，而不是中心化的功能清單。這與我們先前觀察過的DeepSeek Harness 與 ZCode 的選型介面屬於同一條線索：這套工具被討論的方式，越來越取決於它的底層結構有多容易被讀懂。

包名規範也值得看一眼。@deepseek-ai/dsh-<name> 這個命名式，把 scope、品牌縮寫與插件名壓進同一串字元裡。對 npm workspace 的使用者來說，這是慣例；對一個想從 0 到 1 寫插件的開發者來說，這是入場券，照著格式命名，你的插件就會被框架當成自己人。命名的約束力在這裡展現得相當務實：它不靠文件說服你，而是靠載入機制本身。

從設計的角度，這篇文章真正展示的是架構文件的排版選擇。作者用目錄樹、包清單、依賴例子三種層次的素材，把一個抽象的插件體系疊成可讀的剖面。這種寫法本身也是一種介面設計：把工程結構翻譯成認知結構。

回到觀點。DeepSeek Harness 的插件機制好看的地方，在於它把「誰管什麼」畫得異常清楚：Cordis 管生死，插件管一切。一棵目錄樹、六個核心包、一條命名規範，這些看似工程細節的安排，決定了這套工具有沒有長出生態的條件。結構先於功能被設計好，功能才有地方落腳。