前言¶
在 DeepSeek Harness（DSH）裏接 WorkBuddy，常見做法是把 wb2api 網關、模型選擇器裏的 workbuddy provider，以及給不同 CLI 用的協議轉換層分開維護。這些進程默認不會註冊成系統服務，重啓後 provider 仍能加載、模型列表仍能刷出來，第一次真正發請求卻連不上端口，排查往往要從「誰沒起來」開始。
kangjiazhen/workbuddy2everything（npm 包名 dsh-workbuddy-codex）面向同一套鏈路：用 DSH 插件在加載時探測健康端點、拉起缺失進程、定時複查崩潰，並內置 Responses 與 Anthropic Messages 兩座橋，讓 Codex CLI、Claude Code、Claude 桌面端 3p 都能指向同一條 WorkBuddy 網關。下面介紹它的定位、能力與可復現的接法。
這是什麼¶
維護者 kangjiazhen，分類爲模型推理，在 GitHub 上以 workbuddy2everything 發佈，許可證 MIT，要求 Node.js >= 18。
插件自述：把本地 WorkBuddy 網關變成「任何客戶端都能用的模型後端」——包括 DSH 模型選擇器的 provider 路由、背後的 wb2api 網關，以及兩條內置協議橋（Codex 用的 Responses、Claude 用的 Anthropic Messages）。provider 路由通過 ctx.plugin() 委派給 dsh-llm-workbuddy 掛載，插件本身不重寫網關、也不 fork 適配器代碼。
核心功能¶
端口與角色¶
在 WorkBuddy 能應答之前，下列環節需同時對齊（資料中的默認端口如下）：
| 端口 | 服務 | 作用 |
|---|---|---|
127.0.0.1:7863 |
wb2api 網關 |
OpenAI 兼容的 /v1/chat/completions |
127.0.0.1:7864 |
Responses 橋（內置） | Responses API → chat/completions，供 Codex CLI |
127.0.0.1:7865 |
Anthropic Messages 橋（內置） | Anthropic /v1/messages → chat/completions，供 Claude Code / Claude 桌面端 3p |
| — | workbuddy provider |
模型選擇器路由，由 dsh-llm-workbuddy 提供 |
進程監護¶
插件在 apply() 之後異步做首次監管：探測各服務的 health 端點，缺什麼就 spawn 什麼，並按 intervalMs 定時複查。dispose 時只終止本插件自己拉起的子進程；加載前已在運行的服務只探測、不接管。
網關在無可用賬號時 /healthz 可能返回 503（進程活着但上游不可用）。默認 gateway.acceptStatus: [200, 503]，避免監管器誤判爲未啓動而重複拉起。
內置橋的原因¶
codex-cli 0.1xx 起只講 OpenAI Responses（POST /v1/responses），而 WorkBuddy 網關只實現 Chat Completions。Codex 直連 7863 會得到 /v1/responses 的 404，且加載階段已無法使用 wire_api = "chat"。內置橋與 codex-chat-bridge 同源， vendored 爲 bridge/codex-chat-bridge.mjs，零依賴。
Claude 側同理：客戶端講 Anthropic Messages，第二條內置橋監聽 7865 並完成協議轉換。
配置入口¶
配置位於 profile 的 cordis.yml 中 workbuddy-codex 條目的 config；隨包發佈的 cordis.patch.yml 含完整默認值。常用鍵包括：
gatewayDir：網關config.json所在目錄，其中的api_key同時用於橋與 provider。provider.enabled/provider.discovery/provider.autoCheckin：是否註冊路由、拉取/v1/models、每日簽到。bridge.conversationId：默認auto；對着 WorkBuddy 網關不可留空，否則上游400 / 11-128，網關可能禁用賬號。bridge.maxPromptTokens：默認1200000，本地超限回413，避免上游prompt_too_long且無usage導致客戶端無法壓縮上下文。anthropicBridge.*：Anthropic 橋的監聽地址、上游與默認模型等。
若未安裝 dsh-llm-workbuddy，插件仍監護網關與橋，並在日誌中提示 dsh plugin add dsh-llm-workbuddy，不會拋錯。
安裝與啓用¶
官方安裝命令如下（不要用未在文檔中出現的 github:owner/repo 形式拼接）：
dsh plugin add git+https://github.com/kangjiazhen/workbuddy2everything.git
本地檢出時：
dsh plugin add file:/path/to/workbuddy2everything
插件自帶 cordis.patch.yml，成爲 profile 依賴後會自動寫入 workbuddy-codex 條目。
從 dsh-llm-workbuddy 遷移¶
若 profile 的 package.json 裏同時在 dsh.profile.bundles 啓用了舊包，應去掉 bundle 裏的 dsh-llm-workbuddy，保留 dsh-workbuddy-codex，但 dsh-llm-workbuddy 仍須留在 dependencies（本插件 import 它來掛載 provider）：
"dsh": { "profile": { "bundles": [
// "dsh-llm-workbuddy", <- 刪掉這一行
"dsh-workbuddy-codex"
] } }
git 安裝失敗時的常見處理¶
pnpm 可能把 git+https 改寫成 SSH，無 GitHub 密鑰時會 Permission denied (publickey)：
npm config set git-protocol https
走代理時需單獨配置 git（pnpm 不會轉發自己的代理）：
git config --global http.proxy http://127.0.0.1:7890
典型用法¶
配合 Codex CLI¶
橋在 7864 提供 Responses API。在 ~/.codex/config.toml 中指向該地址，並設置 wire_api = "responses"：
model = "global:gpt-5.3-codex"
model_provider = "wb"
[model_providers.wb]
name = "workbuddy"
base_url = "http://127.0.0.1:7864/v1"
wire_api = "responses"
experimental_bearer_token = "anything"
request_max_retries = 2
stream_max_retries = 2
experimental_bearer_token 橋不校驗，上游認證使用網關 config.json 中的 key；Codex 要求非空即可。之後可正常執行，例如：
codex exec "list the files in this directory"
務必保持 bridge.conversationId 爲 auto（或等價有效值）。若賬號被網關因非法請求禁用，可按文檔通過面板 revive 接口解凍，不必重新登錄。
若 Codex 需要圖片輸入，還需在 ~/.codex/models.json 裏爲對應模型聲明 input_modalities 含 image，否則 Codex 會在本地省略附件，橋收不到圖。
配合 Claude Code¶
export ANTHROPIC_BASE_URL=http://127.0.0.1:7865
export ANTHROPIC_API_KEY=anything
claude
配合 Claude 桌面端（3p）¶
修改 %LOCALAPPDATA%\Claude-3p\configLibrary\<appliedId>.json（appliedId 見同目錄 _meta.json），示例：
{
"inferenceGatewayBaseUrl": "http://127.0.0.1:7865",
"inferenceGatewayApiKey": "anything",
"modelDiscoveryEnabled": true,
"inferenceProvider": "gateway",
"inferenceCredentialKind": "static"
}
文檔建議不要手寫非空的 inferenceModels，否則會繞過 /v1/models 發現；留空並開啓 modelDiscoveryEnabled，下拉框才反映網關目錄。橋會把非 Anthropic 形態的模型 id 改寫爲 claude-wb-<hash> 以通過桌面端過濾器，顯示名走 display_name。
DSH 內狀態¶
掛載 tools 後會註冊 workbuddy_codex_status，彙總 gateway / bridge / anthropicBridge 的探測結果與 pid，便於區分「列表空」與「端口掛了」。
適用場景與注意¶
適合已經在本地跑 WorkBuddy wb2api、又希望 DSH 模型選擇器、Codex、Claude 系客戶端共用同一網關與密鑰 的開發者。一次安裝覆蓋 provider 委派、網關監護與兩座協議橋，避免手動開四個窗口、重啓後 silent failure。
使用前請注意：
- 插件以當前 DSH 進程權限運行，會 spawn 網關與橋子進程；安裝前應閱讀倉庫源碼與 MIT 許可證，確認路徑與命令符合你的環境（默認
cordis.patch.yml路徑偏 Windows，Linux/macOS 需在cordis.yml覆蓋gateway.command等）。 - 模型能否調用取決於 WorkBuddy 賬號檔位，與插件無關；網關返回
11158 model not allowed for user type屬於賬號限制。可用bridge.modelAllowlist讓已知不可達模型在橋側快速失敗，避免網關把拒絕歸類爲賬號故障。 - 文檔說明上游 WorkBuddy 項目已停止維護並收緊反代檢測；插件維持本地鏈路，不保證上游通道長期可用。
- DSH 生態是「一切皆插件」；社區目錄 skillhub.cn 爲獨立站點，與 DeepSeek / 幻方無官方從屬關係。
結尾¶
經過上面的步驟，workbuddy2everything 的價值可以概括爲：在 DSH 裏用一套監護與內置橋，把 WorkBuddy 網關穩定地暴露給多協議客戶端，並與 dsh-llm-workbuddy 的 provider 能力疊加而不重複維護適配器。
- 目錄頁：https://www.skillhub.cn/plugins/kangjiazhen/workbuddy2everything
- 源碼與完整說明：https://github.com/kangjiazhen/workbuddy2everything
