前言¶
在 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
