前言¶
DeepSeek Harness（dsh）把模型、工具、會話和界面都做成插件，官方倉庫的口號就是「一切皆插件」。實際幹活時，很多人手裏並不只有 dsh：BitFun 是另一套桌面 Agent，能寫代碼、做文檔、操作瀏覽器和桌面。兩邊各自能跑，但默認並不互通——dsh 會話裏想把一段任務交給 BitFun，沒有現成通道。
Agent Client Protocol（ACP）就是爲這類對接準備的協議：本地場景下，客戶端和 Agent 用 stdio 上的 JSON-RPC 通信，思路接近當年的 LSP。dsh 官方已經提供了進程外 ACP subagent 包 @deepseek-ai/dsh-subagent-acp；BitFun CLI 則內置了 bitfun acp 服務端。缺的是把兩者接起來的 bundle。
dsh-acp-for-bitfun 做的就是這件事。本文按社區目錄頁、插件 GitHub 倉庫 README / package.json / index.js，以及 DeepSeek Harness、BitFun 官方倉庫覈對後整理：它是什麼、怎麼裝、怎麼驗、邊界在哪裏。社區插件目錄（deepseek-harness-plugin.com）是獨立站點，和 DeepSeek / 幻方沒有官方從屬關係，不要把它當成官方應用商店。
這是什麼¶
dsh-acp-for-bitfun 是一款開發與運行時類插件，由 bobleer 維護，倉庫在 GitHub bobleer/dsh-acp-for-bitfun，許可證 MIT，當前版本 0.1.0，主要語言 JavaScript。目錄頁和 GitHub 上都顯示 9 star。
它解決的問題很具體：通過 ACP v1 over stdio，把 BitFun 接到 dsh 裏，作爲當前會話的 subagent。裝好之後，dsh 裏任意會話都可以調用模型可見工具 subagent_bitfun，把任務委託給 BitFun 執行。
插件本身是一個 dsh bundle：Cordis 補丁文件 cordis.patch.yml 插入 id 爲 bitfun-acp 的插件行，入口是 index.js。它沒有自己實現一套 ACP 客戶端，而是複用 dsh 官方的兩個包：
@deepseek-ai/dsh-subagent-acp：作爲 ACP 客戶端，按任務拉起子進程@deepseek-ai/dsh-tool-subagent：把 provider 掛成模型能調用的工具
依賴版本與 dsh 對齊，當前是 ^0.1.0-rc.6。
工作原理¶
README 裏的數據路徑可以寫成下面這樣：
dsh 會話 ──subagent_bitfun 工具──▶ dsh-subagent-acp (ACP 客戶端)
│ 每個任務 spawn 一個獨立進程
▼
bitfun acp (ACP server, stdio JSON-RPC)
│
▼
BitFun Agent Runtime
一次委託大致走完：initialize → session/new → session/prompt，並流式收集 agent_message_chunk。任務結束時關閉子進程 stdin，EOF 寬限 6 秒，隨後 SIGTERM，再不行就 SIGKILL。README 寫明：BitFun 子進程在 SIGTERM 下立即退出，會話數據由 BitFun 自身持久化。
官方 dsh-subagent-acp 的實現還補了幾條邊界，寫進文章裏不容易誤解：
- 每個子進程有自己的進程、會話、模型和工具，不繼承父會話的 Cordis 上下文。
- 父側幾乎只把工作目錄（cwd）傳過去；子進程不能按父側的
outputSchema/maxDepth/toolFilter來約束。 - 權限請求不會彈給人看，而是按配置自動應答。本插件默認是
reject。
插件加載時（checkOnStart 默認爲 true）會先跑 bitfun --version。CLI 不在 PATH 上、或探測失敗，會直接讓 profile 啓動失敗，而不是等到第一次委託才報錯。
核心功能¶
把 BitFun 暴露成 subagent 工具¶
對模型來說，見到的工具名默認是 subagent_bitfun，provider 名默認是 bitfun。dsh 會話裏讓模型調用這個工具，任務就會進 BitFun 的 Agent Runtime。工具通過 @deepseek-ai/dsh-tool-subagent 掛載，maxDepth 設爲 provider-managed（遞歸預算由進程外的 BitFun 子進程自己管），並打開了 one-shot 後臺運行。
按任務冷啓動 ACP 子進程¶
每次委託都會 spawn 一個新的 bitfun acp 進程，而不是複用常駐連接。倉庫 TODO.md 裏仍把「連接複用」列爲未做事項：BitFun 的 ACP server 支持多 session，但當前 bundle 選擇每任務冷啓動。隔離更乾淨，代價是啓動開銷。
啓動前探測 CLI¶
index.js 裏用 spawnSync(command, ['--version']) 做探測。失敗時的錯誤信息會提示：從 https://github.com/GCWing/BitFun 安裝 BitFun、用 bitfun acp doctor 自檢，或把 command 配成可執行文件的絕對路徑。
可覆蓋的運行參數¶
插件 id 是 bitfun-acp。可以在 profile 的 cordis.patch.yml 裏按 id 覆蓋命令路徑、工具名、權限策略和環境變量，不必改源碼。
安裝與啓用¶
前置條件¶
倉庫 README 列出了三樣東西，需要先滿足：
- BitFun CLI：ACP server 內置於 CLI，不是隻裝桌面端就夠。安裝後確認
bitfun acp doctor通過。兼容性要求 BitFun>= 0.2.17（提供 ACP v1 的bitfun acp）。截至 2026-08-14，BitFun 已發佈0.2.18。 - dsh：
npx @deepseek-ai/dsh --version，需要>= 0.1.0-rc.6，與依賴的 subagent 包版本匹配。DeepSeek Harness 目前仍是 developer preview，官方 README 寫明會有破壞性變更。 - pnpm：
dsh plugin通過 pnpm 安裝 bundle。
BitFun 0.2.18 的發行說明裏還提到桌面端「原生支持 DeepSeek Harness」，那是 BitFun 作爲 IDE、通過 ACP 去連 dsh 的方向。本插件方向相反：在 dsh 裏把 BitFun 當 subagent 用。兩邊可以同時存在，不要混成同一個功能。
目錄頁給出的安裝命令¶
社區目錄頁上的安裝命令以頁面原文爲準，在 DeepSeek Harness 終端裏運行：
dsh plugin add github:bobleer/dsh-acp-for-bitfun
如需可復現安裝，按目錄頁說明固定 commit 哈希：
dsh plugin add github:bobleer/dsh-acp-for-bitfun#commit
把最後的 commit 換成倉庫裏實際的提交哈希。插件以當前 dsh 進程的權限運行，安裝時可能執行代碼，裝之前應檢查源代碼倉庫和許可證。
README 裏的 profile / 本地寫法¶
插件 README 另外寫了帶 --profile web 的裝法，以及從本地 checkout 安裝：
# 把 bundle 加進 web profile（從 npm 或本地目錄）
dsh plugin --profile web add dsh-acp-for-bitfun
# 從本地 checkout 安裝
dsh plugin --profile web add ./dsh-acp-for-bitfun
# 啓動
dsh web
需要注意：倉庫 TODO.md 裏「發佈到 npm registry」仍未勾選。在 npm 包真正發佈之前，更穩妥的是目錄頁這條 github:bobleer/dsh-acp-for-bitfun，或 README 的本地路徑裝法。不要默認 dsh plugin add dsh-acp-for-bitfun（不帶 GitHub 源）已經能從 npm 解析到。
配置¶
默認配置可以不改。BitFun 不在 PATH 上、或要改工具名、權限策略時，在 profile 的 cordis.patch.yml（路徑形如 $DSH_HOME/profiles/<profile>/cordis.patch.yml）裏按 id 覆蓋。README 給出的示例：
- id: bitfun-acp
name: dsh-acp-for-bitfun
config:
command: /absolute/path/to/bitfun # 默認 'bitfun'（PATH 解析）
providerName: bitfun # 默認 'bitfun'
toolName: subagent_bitfun # 默認 'subagent_bitfun'
permission: reject # 'reject' | 'allow'
acpArgs: ['acp'] # 默認 ['acp']
env: {} # 傳給 BitFun 子進程的額外環境變量
checkOnStart: true # 加載時探測 bitfun，缺失則啓動失敗
配置項和 index.js 裏的 Schema 一致：
command：BitFun CLI 可執行文件，PATH 上的名字或絕對路徑，默認bitfun。providerName：註冊到ctx.subagents上的 provider 名，默認bitfun。toolName：模型可見的工具名，默認subagent_bitfun。permission：BitFun 發起session/request_permission時的自動應答，reject（默認）或allow。官方 ACP 客戶端不會把這類提示交給人點。acpArgs：跟在command後面的參數，默認['acp']，也就是實際拉起bitfun acp。env：傳給 BitFun 子進程的額外環境變量。官方dsh-subagent-acp會在一份清洗過憑據的父進程環境之上再疊加這裏的鍵值。checkOnStart：加載時是否探測command --version，默認true。
bundle 自帶的 cordis.patch.yml 只負責插入這一行插件，不帶自定義 config；覆蓋發生在你的 profile 補丁裏。
典型用法：裝完怎麼驗¶
README 給的驗證步驟可以直接照做。
1、BitFun 側自檢：
bitfun acp doctor
2、確認 dsh 配置樹裏已經有插件行：
dsh --profile web --dump-config | grep -A 2 bitfun
3、啓動會話後，讓模型調用 subagent_bitfun，委託一個簡單任務。README 用的例子是：
用 subagent_bitfun 回覆 hello
能返回 BitFun 的輸出，說明 ACP 握手、session/prompt 和流式收集這一段是通的。更復雜的編碼或桌面操作是否成功，取決於本機 BitFun 的模型配置、工作區和權限策略，那已經超出這個 bundle 的職責。
適用場景與注意事項¶
適合已經在用 dsh、同時又裝了 BitFun CLI 的人：希望主會話仍留在 DeepSeek Harness，只把某一類任務（例如交給 BitFun 的代碼修改、文檔或桌面操作）委託出去。也適合在評估 ACP 互通時，需要一個現成的 dsh ↔ BitFun 樣例，而不是從零寫客戶端。
使用前建議把這幾條看清楚：
- 權限與進程隔離。插件以當前 dsh 進程的權限運行，安裝時可能執行代碼。裝之前檢查 GitHub 源碼和 MIT 許可證。委託出去的 BitFun 子進程是獨立進程，不共享 dsh 的 Cordis 上下文，但會使用父會話的工作目錄；它能在這個目錄裏做什麼，由 BitFun 自己的能力和
permission策略決定。默認reject更保守，改成allow等於自動批准 BitFun 的權限請求。 - 版本綁定。BitFun
>= 0.2.17，dsh>= 0.1.0-rc.6。dsh 仍在 developer preview，插件依賴其 rc 包。README 要求：升級 dsh 時同步升級本 bundle。倉庫 TODO 也寫了要跟隨 rc 節奏升級依賴。 - 每任務冷啓動。當前實現不爲多個任務複用同一個
bitfun acp進程。短任務會感覺多一次進程啓動；這是設計取捨，不是安裝失敗。 - npm 包尚未作爲默認安裝源。目錄頁走 GitHub 源；README 的 npm 包名裝法，在作者自己的 TODO 勾掉「發佈到 npm」之前，不要當成已經可用。
- 倉庫仍標了未完成項。除了 npm 發佈和連接複用，TODO 裏還有「添加自動化冒煙測試」。目前驗證主要靠
bitfun acp doctor、dump-config 和會話裏實際調一次工具。
小結¶
dsh-acp-for-bitfun 不做新的 Agent Runtime，也不改 dsh 核心。它把官方 ACP 客戶端和 BitFun 自帶的 ACP server 接到一起，讓 dsh 會話多一個名爲 subagent_bitfun 的委託入口。協議是 ACP v1，傳輸是 stdio，進程按任務隔離。
目錄頁：https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-acp-for-bitfun/
GitHub：https://github.com/bobleer/dsh-acp-for-bitfun
BitFun：https://github.com/GCWing/BitFun
DeepSeek Harness：https://github.com/deepseek-ai/deepseek-harness
