「萬物皆插件
。」
。」
這句話放在模型、工具、技能上，聽起來還算容易理解；但如果我告訴你，會話、沙箱、文件系統也都被列進了插件的範圍——等一下，這些東西怎麼也能叫插件？
一直以來我們最熟悉的「插件」，大概還是 Chrome 擴展。瀏覽器已經是一款完整的軟體，我們再往裡面安裝廣告攔截、翻譯、截圖等插件，讓它多出一些原來沒有的功能。插件卸載了，Chrome 依然是 Chrome，也依然知道怎麼打開網頁。
現在，這個詞已經被 DeepSeekHarness 重新定義了，是時候換個角度理解它。
Harness 重新定義了，是時候換個角度理解它。讓模型「上崗」，也需要「配套」
首先得從今年以來 AI 業界越來越常見的另一個詞講起：Harness。
假設一家公司招來了一個能力很強的新員工。
人招進來了，不代表就能立刻原地馬上開始工作，還得給他安排工位和電腦，開通郵箱、內部系統和資料庫賬號，發門卡，告訴他共享的網盤、文件、工作流程怎麼走、哪些操作需要審批，甚至還要留下過去的項目記錄，讓他知道同事之前已經做到哪一步。
如果把這個新員工看成一個大模型，那麼圍繞它準備的這一整套工作條件，就很接近 Harness。
模型決定了這個「員工」本身大概有多聰明、會不會推理、會不會寫代碼；Harness 則負責把這些能力接進真實環境。它可能包括模型能夠調用哪些工具、能讀寫哪些文件、當前任務的上下文如何保存、不同權限怎樣管理、程序在哪裡運行、一次任務失敗以後應該怎樣繼續，以及模型在「看資料—採取行動—觀察結果—再決定下一步」之間如何循環。
這也是為什麼同一個模型，放進不同 Agent 產品里，實際使用感受可能差很多。員工還是同一個員工，但一邊給的是一台配置完整的電腦、清楚的權限和成熟的工作流程；另一邊連賬號都沒開齊，最後做出來的事情當然不一樣。
從這個角度看，Harness 可以有一個非常樸素的解釋：它就是讓模型從「有能力」變成「能上崗」所需要的一整套配套系統。
普通插件=添磚加瓦
理解了 Harness，再回頭看我們熟悉的 Chrome 插件，會發現傳統插件通常有一個很穩定的前提，軟體主體已經存在，插件負責在主體之上增加能力。
Chrome 本來就能瀏覽網頁，翻譯插件只是讓它多一個翻譯功能；Photoshop 本來就能編輯圖片，第三方插件可以增加一種濾鏡或工作流。即使沒有這些插件，軟體最核心的運行方式並不會消失。
如果繼續用「員工上崗」來打比方，這種插件有點像公司已經準備好了辦公室，又因為增員，往裡面添了一台印表機、一塊白板或者一個新的顯示器，這些是錦上添花、添磚加瓦。
其實很多 Agent 的擴展也符合這種直覺。給 Agent 接一個搜索工具、一個 GitHub 工具或者一個資料庫接口，本質上都是在現有 Harness 上增加一種新的能力。因此我們看到 Tool、MCP、Skill 經常和「插件」一起出現，並不奇怪。
、Skill 經常和「插件」一起出現，並不奇怪。
以 Claude Code、Codex 這類成熟產品為例，基於 Harness 的擴展，基本集中在幾處：
Tool / MCP：註冊一個新的函數調用接口，讓模型多一個可執行動作，工具 schema 會進入系統提示；
Skill 與指令文件：往上下文裡加一段可按需加載的說明，例如項目根目錄里的約定文件；
Hook：在工具執行前後插入校驗、日誌或審批；
Subagent：把一部分任務派給子智能體，主流程只接收結構化結果。
這些擴展有一個共同前提：很多東西都屬於產品內部的實現。主循環怎麼輪轉、上下文如何組裝、會話怎麼存、沙箱如何隔離、模型適配層怎麼寫……這些你可以讓模型「多會一件事」，但很難改變它「怎麼決定下一步」。
就好像，你能添一台印表機、發一份操作手冊，甚至安排一個實習生分擔工作；但打卡制度、審批流程、檔案怎麼歸檔，都已經由公司定死。
在 DeepSeek Harness 里，插件不只是一個功能，它更接近一種技術理念：「萬物皆插件」，把模型、會話、沙箱、文件系統這些通常更接近 Harness 基礎設施的部分也放了進去。
這時「插件」這個詞，就不能再簡單理解成給軟體增加功能的小東西了。
DSH 的「插件」，更像可以隨時替換的辦公室模組
給 Chrome 上裝插件好理解，一整個辦公室怎麼可能變成插件？
舉個例子：打卡。打卡在以前，是簽到表，是打卡機；到後來，有了指紋打卡、人臉識別；到現在用 app 就能打卡。無論技術怎麼變化，打卡的核心是不變的：識別人員、記錄時間、地理定位。
這時候，打卡就從一套寫死的基礎設施，變成了一個可以替換的模組。只要能實現這些功能，究竟是打卡機還是企微釘釘，都沒關係，也隨時可以替換。文件系統也是一樣。對於上層 Agent 來說，它真正需要關心的未必是文件究竟存放在本地磁盤、遠程空間還是某個隔離沙箱裡，而是「我能不能讀」「能不能寫」「路徑怎麼表示」「出了錯誤會返回什麼」。如果不同實現，都遵守同樣的接口，Harness 就可以用相似的方式去調用它們。
因此，DSH 所謂的「一切皆插件」，從原來在一個已經固定下來的 Agent 外面繼續安裝新功能的思路中跳脫出來，試圖把 Harness 里的不少能力都進一步拆解、細分成可以替換和組合的模組。
在這條路線上，之前有 Pi 這個先行者，Pi 的核心負責人之一，也在第一時間發文表示 DSH 帶來的啟發。
Pi 的確和 DSH 的出發點很像，但最後停在了不同的位置。Pi 的做法是把核心縮到極小：模型只拿到四個工具——讀文件、寫文件、改文件、跑命令（`read`、`write`、`edit`、`bash`）。子智能體、計劃模式、待辦清單、MCP，這些別的產品通常會內置的功能，Pi 乾脆一個都不做，全部交給擴展。而它的擴展就是一段 TypeScript，可以註冊工具、命令、快捷鍵和事件監聽，也可以接管終端界面；官方示例里就包括子智能體、計劃模式、權限閘門、路徑保護、SSH 遠程執行和沙箱。
回到上面辦公室的說法，這像是公司提供了一間空房間和幾件基本工具，剩下的桌椅、流程和制度，都可以自己製作。
但即便如此，Pi 和 DSH 仍然不是同一件事。Pi 縮小的是核心的體積，擴展依然掛在這個核心留出的口子上。會話怎麼存（Pi 存成一棵可以分叉的樹）、主循環怎麼跑，仍然由 Pi 自己決定。DSH 想做的則是讓核心的構成可替換：會話日誌、主循環、提示詞組裝本身也只是插件，理論上可以整個換掉。
一個是把地基砌得儘量薄，一個是把地基也拆成磚。前者更克制，也更容易穩定；後者自由度更大，代價是每一塊磚都有不穩定性。
「可插拔」、「可組合」是怎麼做到的
DSH 的底座是一個叫 Cordis 的插件元框架，基於這個框架，一個正在運行的 dsh，本質上是啟動時立時組合出來的一棵服務樹：所有能力都掛在共享上下文 `ctx` 上，用穩定的 key 對外暴露。
插件通過 `inject` 聲明自己依賴哪些服務，依賴滿足才會激活；更關鍵的是，註冊行為被設計成可撤銷的——插件卸載時，它註冊過的工具、事件監聽、提示詞片段和服務實現會一併回收。官方架構文檔有這樣的表述，「沒有一個需要打補丁的特權核心」，擴展 dsh 的方式，是在其他插件旁邊再掛一個插件。
真正承擔「替換」的結構，官方叫 seam，由三個角色組成：聲明接口的 Service Definition、實現接口的 Service Provider，以及使用它的 Consumer——後者通常就是模型可見的那個工具。三者齊全才算一個 seam，只寫一個實現不算。
這也解釋了為什麼換掉一個 provider 會改變整個產品的行為：文件系統和子進程共享同一個執行世界，把它們指向遠程沙箱，Bash、PTY、LSP 會跟著一起搬過去，不需要為每個工具各 fork 一份實現。
在實現「可組合」上，DSH 把執行過程分成兩級，step 是一次模型請求加上它觸發的工具調用；turn 從領取輸入開始，到不再欠任何後續工作為止，可能包含零個或多個 step。
一次 step 的事件順序大致是：
agent/pre-step → step/start → agent/request → llm/stream→ assistant/chunk → tool/call→ tools/pre-execute → tools/execute → tools/post-execute→ step/end
其中 `agent/pre-step`、`agent/request`、`llm/stream` 和三個 `tools/*` 是瀑布式事件，監聽者必須調用 `next()` 才會繼續往下傳遞。也就是說，插件可以在這裡改寫模型即將看到的消息，甚至直接拒絕這一次輸入——被拒絕的輸入仍然會關閉一個沒有消耗 step 的 turn，日誌里留下這次嘗試。審批策略、上下文注入、工具改寫都發生在這一層，而不是產品源碼里。
會話日誌是另一條硬約束。它是僅追加的事件流，模型看到的歷史由 `deriveMessages()` 從日誌投影出來，文檔把規則壓成一句話：model-visible means logged——任何進入模型請求的內容都必須能從日誌重建，運行時會對此做斷言。恢復、分叉、回放、遙測和持久化因此消費同一份事件流；想新增一種模型可見的輸入，就得擴展 `SessionEventMap`，而不是私下往提示詞裡塞一段字符串。
最後，組合發生在配置層，而不是代碼層。bundle 是一批 Cordis 配置行加上它們掛載的代碼，profile 是按順序疊起來的 bundle 再加用戶自己的 `cordis.patch.yml`；加載順序為 bundle、profile 補丁、home 級補丁，最後是命令行 `--patch`，後面的層可以按 id 覆蓋前面任意一行配置。想知道自己機器上究竟啟動了什麼，可以把這棵樹直接打出來：
bashdsh --profile web --dump-config
「可組合」之所以是一個可驗證的說法而不只是宣傳，很大程度上就是因為最終組合可以被看見。
真正被「插件化」的，也不是電腦、門禁或文件系統這些東西本身，而是 Harness 與這些東西連接的方式。只要連接方式足夠標準化，背後的具體實現就有機會更換。
DSH 如何重寫定義
在「插件」的維度和在「harness」的維度，DSH 都有很大的思路創新，把兩種 harness 的可替換範圍攤開來看，差別會更清楚。
需要補充的是，這種徹底的可替換性並不自動等於更好用。v0.1 的倉庫已經明確提示後續會有破壞兼容性的改動，而把接口拆得越細，也越容易遇到版本錯配、依賴衝突和更難定位的調試問題。
當然，這並不意味著兩種「插件」之間存在一道絕對的技術分界。不同 Agent 框架會把 Extension、Plugin、Skill、Tool、MCP 劃在不同位置，有些插件也可以深入修改軟體內部行為。真正值得注意的，不是某個模組最後被叫作 plugin 還是 extension，而是它到底可以介入系統的哪一層。
DSH 的反常識之處就在這裡，它把「插件」這個過去經常位於軟體外圍的概念，推到了 Agent Harness 更靠近內部的位置。
為什麼 Agent 時代會出現這樣的設計，也並不難理解。模型越來越像一個通用但可替換的「員工」，真實工作環境卻千差萬別。有人需要本地文件，有人需要遠程沙箱；有人想接 DeepSeek，有人也可能測試其他模型；不同團隊對工具、權限、記憶和工作流程的要求都不一樣。如果這些配套被牢牢寫死在同一個 Harness 里，每改變一項，都可能意味著重新改造整個系統。把它們變成可插拔組件，則給開發者留下了重新組合的空間。
所以，DeepSeek Harness 的範式創新，並不只是「DeepSeek 也開始做插件生態了」，更準確地說，它在嘗試回答一個更基礎的問題：當模型越來越容易被替換以後，圍繞模型搭起來的那套工作配套，能不能也變得更靈活、更模組化？
這不是沒有代價，對於普通用戶來說，開箱即用仍然是一個合理到不能再合理的需求——就像去公司上班，誰願意總是背自己的電腦？但對於極客程序員、工程師來說，從鍵盤到顯示器到人體工學椅，都有自己的講究，那花時間甚至是自費上班，是一件有樂趣的事。
DSH 想做的，是一種技術思路的創新，也讓人看到，哪怕是辦公室里，許多東西從一開始就不必被釘死。
