前言¶
用 dsh（DeepSeek Harness）做智能體工作流時，常會遇到這樣的需求：主智能體想找一個外部編碼智能體出第二意見，或者把一段編碼任務並行交出去。如果走 Kimi CLI，手工做法是自己 spawn kimi -p、捕獲輸出流、輪詢狀態、再把結果接回 dsh 會話——這類腳手架代碼重複且容易出錯，正是 harness 插件該替你消掉的東西。
下面介紹的 dsh-kimi-bridge 做的就是這件事：把 Kimi CLI 變成 dsh 裏可直接調用的工具，並在 WebUI 裏提供對應的觀察界面。
這是什麼¶
dsh-kimi-bridge 由 pandashere 維護，許可證爲 MIT，當前版本 0.1.0。一句話定位：這是一個 host + browser 雙面的 DeepSeek Harness 插件，把 Kimi CLI（kimi-code）橋接進 harness，是 dsh-codex-bridge 的 Kimi 對應版本，兩者架構相同。
「雙面」指插件同時覆蓋兩端：host 端向 dsh 註冊工具，瀏覽器端由 /plugins/dsh-kimi-bridge/client.js 提供界面。DSH 的理念是「一切皆插件」，外部 CLI 的能力就是通過這個機制接進會話的。
四個工具¶
call_kimi¶
call_kimi 在當前會話的工作目錄運行 kimi -p <prompt> --output-format stream-json，支持兩種模式：
async：立即返回，多次調用可以並行；block：等待最終答案；傳入kimi_session_id時改爲等待一個先前啓動的會話，取消阻塞等待會中止對應的 kimi 會話。
參數結構如下：
call_kimi: { prompt, mode?: async|block, model?, timeout_ms?, kimi_session_id? }
每次 call_kimi 都是一次性運行全新的 kimi -p。CLI 本身不支持運行中的即時 steering；kimi-code 的思考過程不寫入 stream-json，插件也不會從 stderr 猜測推理內容。
kimi_status 與 kimi_abort¶
kimi_status 列出當前 dsh 會話的全部 kimi 會話，包括狀態、prompt 預覽和進度。kimi_abort 接收 { kimi_session_id }，對進程組先發 SIGTERM，超過 killGraceMs 後升級爲 SIGKILL。
kimi_steer¶
kimi_steer 用 kimi -S <session_id> -p … 繼續一個已結束（settled）的父會話：
kimi_steer: { kimi_session_id, prompt, mode?: async|block, model?, timeout_ms? }
新記錄通過 parent 鏈接回父會話，並繼承父會話的模型。Kimi 會話綁定工作目錄：插件把 cwd 鎖定到會話工作目錄，保證續接發生在同一目錄。會話是線性的——父記錄必須是最新記錄，一個會話同一時間只能有一個活動續接。
WebUI：Kimi 標籤頁¶
插件在會話面板裏註冊一個 Kimi 標籤頁，位於 Codex 之後。
左列是當前 dsh 會話的全部 kimi 會話，帶狀態點、prompt 預覽和相對時間，點擊選中。右列顯示狀態徽章、meta（id/kimiId/cwd/model/duration/exit/error）、prompt，以及 Activity | Text 兩個視圖：
- Activity：Agent Loop 瀑布圖，包含消息、帶參數的工具行、可摺疊的工具輸出和 turn 分隔符；
- Text：流式 transcript 與最終答案。
狀態變化通過會話投影通道即時推送（kimi/session 事件、kimi/sessions 投影），標籤頁隨之即時更新；刷新頁面後通過歷史回放恢復。
reviewOnly：默認只讀白名單¶
先說清設計立場：這是一個 UX 通道，不是安全邊界。kimi -p 內部以 permission:"auto" 運行，CLI 沒有沙箱標誌可用。
因此插件默認 reviewOnly: true：kimi 在一個受管 home 下運行，其 [tools] 白名單隻含只讀工具——Read、ReadMediaFile、Grep、Glob，沒有 Bash/Write/Edit/MCP——並且在工具執行前再次強制。把它改成 false 意味着切換到用戶不受限的 home，這是顯式的運維選擇，不應被稱作沙箱。reviewOnly 是工具白名單，不是沙箱；真正沙箱化的 workspace-write 需要 OS 級隔離（container/namespace）。
憑據方面：插件不把憑據複製進倉庫或 dsh telemetry；reviewOnly 模式下，受管 Kimi home 通過符號鏈接指向 CLI 現有的認證文件，CLI 仍是憑據的所有者。Kimi 自身的遙測通過子進程環境變量 KIMI_DISABLE_TELEMETRY=1 禁用。
安裝與啓用¶
先確認環境：Node.js 22 或更新（engines: node >=22）、@deepseek-ai/dsh@0.1.0-rc.6，以及一個已認證、可用的 kimi CLI（或在配置裏設置 kimiPath）。
第一步，在插件目錄裏構建、校驗並打包：
npm install
npm run check # typecheck + tests + compliance
npm pack
npm run check 依次跑類型檢查、測試和合規校驗；npm pack 生成獨立 bundle 的 tarball dsh-kimi-bridge-0.1.0.tgz。如果你要改源碼，npm run build 會分別用 tsc 編譯 host 端、用 esbuild 打包瀏覽器端。
第二步，把 tarball 安裝進 web profile 並重啓 dsh web：
npx @deepseek-ai/dsh@0.1.0-rc.6 plugin --profile web add ./dsh-kimi-bridge-0.1.0.tgz
npx @deepseek-ai/dsh@0.1.0-rc.6 web
第三步，驗證瀏覽器端已就位。瀏覽器側代碼由 /plugins/dsh-kimi-bridge/client.js 提供，可以對照運行中的默認 Web profile 檢查：
curl -s http://127.0.0.1:3080/plugins/dsh-kimi-bridge/client.js | head
經過上面的步驟，會話面板裏應能看到 Kimi 標籤頁。注意不支持以源碼目錄 link 方式安裝，因爲 host 端的 peer 依賴由 DSH profile 提供。更新時用新的 package version 重新打包，移除已安裝的 bundle，加入新 tarball 並重啓。卸載命令如下：
npx @deepseek-ai/dsh@0.1.0-rc.6 plugin --profile web remove dsh-kimi-bridge
配置項¶
README 明確列出以下配置項及默認值：
| 配置項 | 默認值 | 含義 |
|---|---|---|
kimiPath |
kimi |
kimi 可執行文件（絕對路徑或 PATH 查找） |
reviewOnly |
true |
在 [tools] 白名單爲只讀的受管 home 下運行 kimi |
kimiHome |
'' |
配置與認證的來源 home（'' = KIMI_CODE_HOME，否則 ~/.kimi-code） |
reviewHomeDir |
'' |
受管 review home（'' = $DSH_HOME/kimi-review-home） |
maxTimeoutMs |
1800000 |
任何會話超時的硬上限（30 分鐘） |
defaultTimeoutMs |
600000 |
每個 kimi 會話的默認存活時間（10 分鐘） |
maxParallel |
3 |
併發 kimi 進程的全局上限 |
maxSessionsPerSession |
8 |
每個 dsh 會話的活動 kimi 會話上限 |
maxRetained |
16 |
每個 dsh 會話保留的已結束記錄數（最舊淘汰） |
maxPromptChars |
16384 |
prompt 長度上限（argv prompt；拒絕 NUL，超長 prompt 直接拒絕） |
maxTranscriptChars |
16384 |
事件與投影中記錄的 transcript 上限 |
maxLoopSteps |
32 |
Agent Loop 窗口保留的步數 |
maxLoopBytes |
16384 |
Loop 窗口的序列化字節上限（UTF-8，淘汰最舊的已完成步驟） |
allowedAgents |
roots |
誰可以調用 call_kimi：roots 或 all |
killGraceMs |
10000 |
SIGTERM 到 SIGKILL 的寬限期 |
兩個超時項值得單獨說明：kimi 的 print 模式可能出現長等待，所以插件用 defaultTimeoutMs（默認 10 分鐘）約束單個會話的默認存活時間，用 maxTimeoutMs（默認 30 分鐘）作爲任何會話的硬上限。allowedAgents、maxParallel、maxSessionsPerSession 則用來約束資源放大。
已知限制¶
- Agent Loop 窗口是近期活動而非審計記錄：超過
maxLoopSteps（32）/maxLoopBytes（16384）時物理淘汰舊步驟，標籤頁只顯示保留窗口（dsh 會話日誌本身仍保留完整快照）。 reviewOnly是工具白名單，不是沙箱；真正的 workspace-write 沙箱需要 OS 級隔離。- 僅支持 POSIX 進程組（
detached+ 負 pidkill）；Windows 移植需要 Job Object /taskkill /T樹終止。
適用場景與注意¶
適合的場景很具體：你想讓 dsh 主智能體把 Kimi 用作第二意見或並行的編碼通道；或者你已經在用 dsh-codex-bridge，想以同樣的架構接入 Kimi。
幾點注意：
1、插件以當前 dsh 進程的權限運行。安裝任何第三方插件前，都應先檢查源碼與許可證——本項目爲 MIT。
2、環境要求：Node.js 22 或更新、@deepseek-ai/dsh@0.1.0-rc.6、已認證且可用的 kimi CLI（否則設置 kimiPath）。
3、reviewOnly 默認爲 true，屬於工具白名單而非沙箱；需要更大自由度時改爲 false 是顯式的運維選擇。
小結¶
回到開頭的問題：讓 dsh 智能體用上 Kimi，原本需要一套 spawn、抓流、輪詢、回填的手工腳手架；dsh-kimi-bridge 把它收斂爲四個工具加一個標籤頁——調用可異步並行，會話可續接，Agent Loop 可觀察，默認只讀白名單兜底。源碼與文檔在 GitHub：https://github.com/pandashere/dsh-kimi-bridge，許可證 MIT。社區的 DSH 插件目錄（獨立站點，與 DeepSeek、幻方沒有官方從屬關係）也可以按插件名檢索。
