我們拆了 1.1 萬個 DeepSeek Harness 插件，發現官方几乎沒有建立插件治理機制

距離 DeepSeek Harness 開源已經有一段時間，「Everything is a Plugin」的口號也已經在各種領域開枝散葉，坊間湧現出了特別多的插件和社區。（）十幾天後的現在，GitHub 上【 dsh-plugin 】標籤下有一萬多個倉庫。我們花了幾天時間，把這一萬多個倉庫拆開數了一遍，寫了一個探針插件裝進去試探，又裝了二十幾個下載量最高的插件跑了一夜。「一切皆插件」是把內核的每一顆螺絲都交到你手裡。但實際上絕大多數人對螺絲毫無興趣；而整個插件生態沒人管理也沒人負責。（注：整個生態數據變化很快，本文中所有數據僅截至 2026 年 8 月 25 日實查。011.

1 萬個插件，到底有多少是真的？不同的統計方式差挺多同一天，同一個生態，不同網站統計的插件數量是這樣的：造成這個現象的原因是「插件」這個詞在這個生態裡還沒有公認的定義，誰都可以合理地說自己那個數是對的。如果把整個 dsh 的插件生態做成漏斗大概是這樣的：從第一層到第三層掉了 81%，從第三層到第五層又掉了 55%。也就是說 DeepSeek Harness 插件生態目前有 1.1 萬個插件，或者說目前僅用不到一千個插件，這兩種說法都對，無非是看用什麼統計口徑。為什麼每一層漏洞能差這麼多？

DeepSeek 官方關於插件生態的全部指引，就只有 README 和 CONTRIBUTING 裡各一句話：給你的倉庫打上 dsh-plugin 這個 GitHub 標籤，方便別人發現你。【出自 https://github.com/deepseek-ai/deepseek-harness/blob/master/README.zh.md】也就是說要想被記為一個 dsh 的插件極其簡單，幾乎沒有任何成本。

我們把倉庫和文檔全站搜了一遍，缺少的東西包括：沒有插件目錄沒有搜索沒有版本兼容矩陣沒有簽名或校驗沒有安全上報通道沒有官方推薦清單而 GitHub 標籤的准入門檻是零，也就是說任何人可以給任何倉庫打任何標籤，不需要審批，也不需要跟 dsh 有任何關係。那可想而知，將會有多少水軍和不懷好意的人湧進來濫竽充數亦或者別有所求。比如說官方 README 裡那個鏈接點過去，GitHub 默認按“最佳匹配”排序，而最佳匹配高度相關於 star 數。然後你會發現排名第四是一個 20 年就做好的簡歷生成器。它建於 2020 年，比 dsh 早了六年。

它目前在 dsh 插件社區排第四隻是因為加了一個蹭熱度的 tag。【dsh 插件 top5 】一萬多個插件有多少能用？有人把這一萬多個倉庫逐個打開篩了一遍，並公開了 1,883 條拒稿記錄（含理由與複查日期）。我們把這份數據下載下來自己聚合了一遍發現：93%（1,752 條）的拒絕理由是“按 dsh 的規矩裝不上”，沒有 dsh.bundle 聲明、沒有 dsh 依賴、也沒有 dsh 能發現的技能佈局。但裝不上不等於是空的假倉庫。

我們又隨機抽了 50 個被拒倉庫看體積：只有 1 個在 5KB 以下（約等於只有個 README）中位數 407KB12 個超過 5MB，最大的 336MB語言五花八門：TypeScript、JavaScript、Python、Rust、PowerShell、C、C++、Swift、Go、Shell 都有。其中三成用的語言根本做不成插件。因為插件走的是 npm 那條路，Node 之外的語言進不來。所以這一萬多個插件真實構成是三類：第一類，真的是空殼。數量很少，50 個裡只有 1 個：一個 2KB 的倉庫，描述吹自己是“擴展插件全家桶，6 個插件加一鍵安裝腳本”。

第二類，代碼是真的，只是沒按 dsh 的規矩打包。有兩個倉庫裡躺著寫好的插件，宿主端和瀏覽器端兩半都齊了，就是沒加那句聲明、也沒發佈到 npm，於是官方的安裝命令認不出它（很奇怪為啥做了但沒做完，理論上這 vibe coding 就一句話的事）第三類，完全是別的東西掛了這個標籤。我們抽了 50 個樣本里有 5 個 Windows 啟動器、一個 macOS 狀態欄小組件、幾個桌面客戶端還有一大堆亂七八糟的東西實在不想說了。

還有 505 個倉庫的名字裡帶著 deepseek-harness-desktop，三個團隊做桌面客戶端，其中兩個都叫 dsh-desktop，兩個都叫 deepseek-harness-desktop，域名一個 .com 一個 .cn。對新用戶來說這就是純噪音。甚至社區有人專門弄了個插件，把 dsh 界面裝扮成 2005 年的中文門戶：側欄廣告、信息流、角落彈窗，還有點不掉的假關閉叉。我不知道作者是想嘲諷門戶時代的廣告，還是嘲諷現在插件社區的現狀。我們讀了它的源碼。那些假廣告位裡展示的確實是它實時從 dsh-plugin 標籤里拉回來的真實倉庫，按最近推送時間挑新鮮的，還特意把自己排除掉。

02DeepSeek 開放了內核，但大家只想裝工具依然是賣鏟子和娛樂賺翻了註冊表裡那 2,143 條可以按三類來分：賣鏟子的，比如市場、用量計費、文檔、開發輔助娛樂體驗的，比如主題、桌寵、界面增強真擴能力的，比如工具、記憶、視覺、語音、工作流下載量前三名全是市場和界面類。第四名 modlens（視覺）才是擴能力（而且是剛需能力）。這當然不是 dsh 一家的偶然。我們把同一套分法套到 Anthropic 官方運營的那 2,282 個 Claude Code 插件上，擴能力插件也是 55.0%，鏟子+娛樂也是 40.2%，兩個生態幾乎完全一致。

面對一個新東西，市場最缺的從來不是怎麼用它產出，而是我先得找到它。所以做商店的、做教陪的，是最快也最持久的剛需。這門生意會從一個東西誕生那天開始，做到它死的那天為止，就像今天網上還有人在賣怎麼用 Excel。這解釋了為什麼全生態下載量第一的插件，做的就是幫你找插件。這個 dsh-market，2,331 star，周下載 159,327，約等於官方入口包周下載（662,397）的 24%。裝上之後 dsh 的設置頁裡就多出一個「插件市場」，能搜、能篩、能看截圖、一鍵裝、一鍵更新、兩步確認卸載。

而做插件市場/管理器的插件有 60 個，第一名比第二名多 14 倍（189,798 vs 13,678）。官方最自豪的那一層幾乎沒人碰官方最驕傲的賣點是沒有特權內核，連 agent 主循環都能換。我們把 2,143 條的名稱和中英描述全搜了一遍，又去 GitHub 做代碼搜索雙查。真正以插件形態換掉主循環的，我們只找到兩個。一個是 dsh-frostfin，把主循環換成 Kimi Code 走 ACP 直連。周下載 438,5 個 star。另一個叫 dsh-session-pause，它禁用官方 loop、掛上自己改造的版本，為的是實現“暫停當前回合、重啟之後接著跑”。

它連 npm 都沒發，註冊表裡也沒收錄，4 個 star。也就是說另一個願意動主循環的人，動它不是為了換腦子而是為了補一個官方沒做的功能。但同時換模型這個接口被用爆了：69 個插件，頭部的做法是把 Codex、Claude、Grok、Kimi 的訂閱額度接進 DeepSeek 自己的 harness，單個周下載六千上下。不知道 ds 怎麼看待這個現象，也許這和他們認知的世界不太一樣，他們可能認為我把最核心的東西都給你改，但絕大多數人根本就對這個毫無興趣。03裝一個插件的代價是什麼？

安全：read-only 管不了插件dsh 有三檔文件權限：read-only（只能讀）workspace-write（只能改當前工作區）danger-full-access（完全放開）我相信幾乎所有人看到這三個詞，都會理解成安全等級。我們寫了一個最小的探針插件，用正常流程裝進去，然後在三檔權限下各跑一遍九項試探。結果是九項試探在三檔權限下全部成功，也就是說任何一檔都無法約束插件行為。（下圖根據實測結果整理得到。）在最嚴的 read-only 檔下，探針列出了 ~/.ssh/ 裡的文件、從環境變量裡讀到了我的 API key、往 /tmp 寫了文件並讀回、連上了外網。你肯定想問，為啥會這樣啊？

因為模型想對你的機器做任何事，只能請求 dsh 幫它做：比如幫我讀這個文件、幫我跑這條命令。那三檔設置就是 dsh 用來審查這些請求的。但是最關鍵的來了，插件不需要請求，因為它自己就是 dsh。類比一下就好像那個設置是門口的保安，檢查訪客。但插件不是訪客，插件是我同事，所以保安不會查他。最壞結果具體是什麼？一個插件能做的事，等於你這個電腦賬號能做的一切：讀 SSH 私鑰、雲平臺憑據、其他項目的源碼；往任何地方寫文件；連外網。所以能把上面這些發出去。而這一切不需要你同意任何東西，裝上就有了。（或者說安裝即同意）還記得那句經典臺詞嗎：這不是 bug，這就是一個 feature。

官方在一篇設計筆記裡明確寫過“安全與權限不是設計目標”，那個自指工具集的 README 也自稱“沙箱不是安全邊界，請把這套工具當作 bash 權限對待”。出自2026-07-08-agent-scope-contexts.zh.md出自 deepseek-harness-repo/packages/extensions/tool-cordis/README.md問題是誰真的會在安裝一個插件的時候去讀這些說明，去看源碼。可能有人會說那 app 的授權也是這樣啊，但大家別忘記了 app 是有監管的，背後是一整個互聯網規則、工信部兜底/定期審查，廠商校驗。

而 dsh 的插件生態啥都沒有，用戶必須得自己負責。一旦有這種空子可以鑽，那對於心懷不軌的人這種敞開的大門就遲早會被攻陷。我們裝完 10 個下載量最高的插件後，把配置導出來跟出廠狀態做了個 diff。發現一個叫 dsh-tui 的插件，這是個終端界面皮膚。但他會改寫沙箱策略，並且在 Windows 下把權限強制拉到最高那一檔 danger-full-access。（非作者故意，並且作者把理由寫在緊鄰的註釋裡：Windows 上官方沒有沙箱後端，不設成 danger-full-access，bash 命令根本跑不了。而且非 Windows 平臺它保持官方默認。

）在 AI 時代，沒有人會去核實每一個插件裡到底寫了什麼規則。比方說有人覺得官方「只能改當前工作區」和「完全放開」這兩檔之間落差太大，做了個插件說加了中間一檔，叫 auto。我們把它的源碼讀了一遍，實際邏輯是：先過一個確定性的危險命令正則黑名單→ 命中就轉人工沒命中的，交給一個 AI 分類器判斷放行還是轉人工。而那個分類器的提示詞裡明寫著 "Default to approve"（默認同意）分類器超時、出錯、返回非法 → 兜底轉人工它沒有加任何權限檔。它註冊的那個 auto 只是一個審批預設名，沙箱模式仍然是官方的三檔，一檔沒變。

我以為裝上之後會多加一層保護，實際上是開了默認檔，減少了一層複核。而這件事只有讀源碼才能發現。但正經人誰會裝一個插件的時候都去複核源碼？難道我們在裝一個 skill 的時候也會去做一層安全校驗嗎？我不認為作者有惡意，他大概真心覺得自己在幫人省事，而且他在分類器失敗時兜底轉了人工。這時候再看安裝插件時候的這個提示，會有一種錯愕感，之前覺得也就是個免責什麼而已，現在覺得這行字裡面透露的東西有點恐怖。成本：裝一個插件，緩存可能整段失效DeepSeek 千方百計做的緩存命中策略在插件這件事上直接回到解放前。

比如說固定任務、固定倉庫、全新會話，跑熱之後除了費錢還有三個後果：首輪變慢；工具越多模型越容易選錯工具（這是官方自己在文檔裡承認的問題，他們做 Code Mode 就是為了治它）；上下文被工具說明書吃掉。DeepSeek 對省緩存這件事極其上心，但在整個插件生態裡，沒有一個地方告訴你裝插件會讓緩存作廢。我不認為這是它沒為插件做準備。恰恰相反，它做了大量準備：profile 和 preset 機制齊全，每個會話可以掛不同的插件組合；Code Mode 可以把二十個工具說明書換成一個 runcode。

真正的問題是他把一個工程製品當做產品發佈了，或者說不管他怎麼強調開發版本，用戶依然會當做成熟產品來使用機制全在，但你得自己知道去用，並且得自己負全責。那這到底是技術上辦不到嗎還是主觀上不願意做？緩存歸零確實躲不掉。緩存是按前綴命中的，工具說明書就排在前綴裡，你裝一個插件等於往前綴裡插進 14 段新說明，從變動那個字往後全部作廢。換誰來做都一樣。但用戶告知是選擇。解法它做了：profile 和 preset 能讓你按會話掛不同的插件組合，Code Mode 能把二十份說明書壓成一個 runcode。

可這些都要你自己知道、自己去配，而整個插件生態裡沒有一處提示你裝插件會讓緩存作廢，也沒有一處告訴你這一下花了多少錢。一家把對 KV 緩存的影響寫成 223 個包 README 必答章節的公司，不可能不知道這件事。它只是把答案留在了工程師那一側，默認他的用戶都是工程師。兼容性：插件相互衝突的現象非常嚴重我們把按倉庫去重後下載量前十的插件裝進同一個配置，起不來。【實測報告中 LLM 的返回部分截圖】衝突涉及的正好是下載量第 2、3、6 名。必須禁掉其中兩個之後才起得來。原因是那個 UI 全家桶的依賴清單裡明寫著它自己帶了一個側邊欄組件。你再單獨裝一個側邊欄插件，兩個就搶同一個界面路徑。

所以我們發現 dsh 缺的其實是一個仲裁者，或者說一個管理者。它有配置層、有加載順序、有能力接縫。官方文檔甚至把“後面的層按行整行覆蓋前面的、不是深度合併”這個語義寫得很清楚。他們知道會有衝突，還把怎麼衝突的講明白了，但沒做任何工具去檢測它。04它對行業的影響star 爆炸不等於出圈我們來拿 OpenClaw 做對照。也就是說 dsh 在開發者圈裡火得比 OpenClaw 快十倍，但僅限於開發者圈子。這倒是和他們的定位非常一致，普通人很難上手這個工程產品，也很難自己負責這麼大的自由度。

不過有意思的是 fork 和 star 的比例上看 OpenClaw 要高一倍多，不過 dsh 才建倉沒多少天，究竟有多少人願意 fork 下來改代碼還需要時間的驗證。它吸引了誰：拉來了新人，但新人做的東西沒被看見我們做了一輪非常詳細的普查。註冊表裡全部 1,446 位可查作者，加上 dsh 開源後新建、且至少有一個 star 的打標籤倉庫的 5,032 位作者，合併去重 5,192 人，逐個查了賬號創建時間、歷史倉庫、以及“在 dsh 之前有沒有做過 AI/agent 項目”。一共跑了 4 小時 6 分。先說結論：2024 年及更早註冊的老賬號佔 67–69%，8 月當月新註冊的只有 3.

9%–4.4%followers 中位數是 1，四成作者零粉絲，組織賬號只佔 4–5%把那 5,032 位作者按他們最高 star 的那個倉庫分三檔：所以答案是：dsh 確實吸引來了大量新人，但新人的作品集中在無人問津的低 star 區間，被看見的那些仍然由老 AI 玩家把持。另一個角度的對照方向一致但更弱：做出了真有人下載的插件的那 694 位作者裡，63.7% 在之前就開發過 AI 相關的項目；所以這暴露出 dsh 這套遊戲規則的另一個弊端，缺乏官方分發管理的時候，那些優質的個人開發者和新項目沒辦法得到良好的激勵，這個生態會迅速被老登佔據，那幾乎就離成為一攤死水不遠了。

05DeepSeek 為什麼把插件分發留給了社區？DeepSeek 做過分發機制，然後主動刪掉了我在倉庫的設計記錄裡翻到一篇 2026 年 8 月 9 日的筆記，距離公開發布還有 4 天。被移除的東西逐項列著：@deepseek-ai/dsh-repository-plugin 包、.dsh-plugin 專用編寫格式、dsh-plugin-prepare 可執行文件、生成的包裝層、不可變 repository 緩存、base 裡的 repository-plugins 配置項、repository 專用的 skill 與 MCP 適配器、以及一條專用的 GitHub 驗收流水線。

並且明確不保留兼容解析器或遷移機制。【出自.agents/notes/implemented/simplification/2026-08-09-remove-repository-plugin.zh.md】官方給的理由：這條路徑與 profile 組合包路徑重複實現了第三方包的安裝與組合，而且它能提供的配置反而更少，repositories 列表只能選源字符串，生成的包裝層掛載代碼入口時無法傳入用戶提供的插件配置。說白了就是它增加了大量代碼和 CI 工作，卻沒有成為通用的外部插件分發機制。但是呢，你會發現被刪掉的是分發路徑。

而「發現」和「信任」這兩層其實從來沒有被實現過，也壓根沒有出現在這篇取捨記錄裡。他們討論的全部內容是裝的機制有兩套，太重複了，那乾脆別幹了。一個寫了 1,372 篇設計記錄、連 22 篇被否決的方案都留檔公開的團隊，在關於插件分發的那篇取捨記錄裡，沒有一個字討論用戶怎麼找到它們和用戶憑什麼信它們。還是那句話，都丟給用戶自己決定。從行業和歷史找答案三家的路子不一樣，但沒有一家把這層留空。Claude Code 和 Figma 是官方自己下場做，MCP 是社區目錄先行、官方後補。區別在什麼時候做和誰來做，不在做不做。也許有人會說 dsh 是開放協議不是產品，憑什麼要求它開商店。

那 MCP 也是開放協議，也是社區先跑起來的，Anthropic 最後還是把官方 registry 補上了。所以真正的問題不是 dsh 會不會補上這一層，而是它會被什麼推著補。我猜應該很快了，否則遲早出問題。06往後會怎樣四個歷史劇本太陽底下無新事。npm、vs code、figma 都面臨過這些問題，也都演化出了自己的解決路子。我們抽了 12 個註冊表上“沒發佈正式包”的插件去 npm 查同名，5 個有同名包，逐個比對倉庫和維護者，全部是另一個作者的另一個項目。（樣本稍微有點小，當做個信號看就行。）假如你要裝，那因為註冊表上那個 dsh-hud 是某位作者的，得從 GitHub 裝。

但是你順手敲 dsh plugin add dsh-hud，裝到的是另一個人的另一個 dsh-hud。【同一個名字，兩個作者，兩個項目。】但嚴格說，dsh 的開局比 npm 早期還要更亂一點。npm 早期的毛病是名字先到先得，可它至少只有一套名字。你敲 npm install foo，裝到的就是註冊表裡那個 foo。dsh 是兩套：發現靠 GitHub 標籤和那份社區清單，安裝靠 npm，中間沒有映射，也沒有誰負責對齊。所以真正的問題是目前它連 npm 早期的地基都還沒有。dsh 插件生態的價值到底在哪?連主循環也是插件這件事，用別的開源 harness 自己搓還真做不到。

如果去 fork 一個項目自己改，改的是它的源碼，上游更新的話得手動合。dsh 是改一行配置，升級的時候不衝突。這是fork 一個項目和給一個項目掛東西的區別，對長期維護的人來說這個區別還是很大的。競品做成了可插拔後端。內置了起一個真正的 Claude Code 子進程、起一個 Codex 子進程，還有兩套競品的 hook 協議橋，開發者為 Claude C