前言¶
DeepSeek Harness（DSH）插件生态强调「一切皆插件」。在本地搭建智能体开发环境时，往往需要组合多个组件：模型选择器、网关、适配器。如果其中某个组件挂了，整个链路就会失效。dsh-workbuddy-codex 专门解决这个稳定性问题，它负责监控并确保本地 WorkBuddy 反向代理链始终可用。
插件定位¶
dsh-workbuddy-codex 是一个 DeepSeek Harness 插件，由 kangjiazhen 维护。它监控本地 WorkBuddy 反向代理链，包括三个组件：
wb2api网关（端口 127.0.0.1:7863）- Responses API 桥（端口 127.0.0.1:7864，插件内置）
workbuddy提供者（挂载自 dsh-llm-workbuddy）
在插件加载时，它会探测每个健康端点，补全缺失的进程，并定时重检，确保崩溃的进程能够自动恢复。插件不会重新实现网关或适配器，而是通过挂载 dsh-llm-workbuddy 的 provider route 来实现模型选择器功能，从而避免代码重复和同步问题。
核心能力¶
监控与自愈¶
插件在加载时会探测以下三个组件的健康状态：
| 端口 | 组件 | 作用 |
|---|---|---|
| 127.0.0.1:7863 | wb2api 网关 | 提供 OpenAI 兼容的 /v1/chat/completions 接口 |
| 127.0.0.1:7864 | Responses 桥（内置） | 将 Responses API 转换为 chat/completions，供 Codex CLI 使用 |
| — | workbuddy 提供者 | 模型选择器路由，挂载自 dsh-llm-workbuddy |
如果某个组件未运行，插件会自动启动。如果组件崩溃，插件会定时重检并重启。插件不会重新实现网关或适配器，而是委托给 dsh-llm-workbuddy，保持两者同步。
与 Codex CLI 的集成¶
codex-cli 0.1xx+ 版本不再支持 wire_api = "chat"，只支持 OpenAI Responses API。而 WorkBuddy 网关只实现了 Chat Completions API。插件内置了一个翻译层，将 Codex 的 Responses API 请求转发到网关的 Chat Completions 接口：
Codex CLI --(Responses)--> bridge :7864 --(ChatCompletions)--> gateway :7863 --> WorkBuddy
该翻译层 vendored 自 codex-chat-bridge，零依赖，在 Harness 的 Node 环境中运行。
配置说明¶
所有配置项位于 profile 的 cordis.yml 中，插件自带 cordis.patch.yml，包含默认配置。关键配置项如下：
| 配置键 | 默认值 | 说明 |
|---|---|---|
workbuddy-codex.config.gatewayDir |
~/Documents/deepseek-harness/default-workspace/workbuddy2api-panel |
网关配置文件所在目录 |
workbuddy-codex.config.provider.enabled |
true |
注册 workbuddy 路由 |
workbuddy-codex.config.provider.baseURL |
(空 → 使用 gateway.baseURL) | 适配器使用的网关地址 |
workbuddy-codex.config.provider.discovery |
true |
从网关 /v1/models 获取模型列表 |
workbuddy-codex.config.provider.autoCheckin |
true |
执行每日签到 |
workbuddy-codex.config.gateway.acceptStatus |
[200, 503] |
网关返回 503 时视为正常（未配置账户） |
workbuddy-codex.config.bridge.conversationId |
auto |
会话 ID，必填否则会禁用账户 |
workbuddy-codex.config.bridge.maxPromptTokens |
1200000 |
本地提示词大小上限，超过则返回 413 而非转发 400 |
如果未安装 dsh-llm-workbuddy，插件仍会监控网关和桥，并记录一条安装命令日志。
安装与启用¶
使用官方安装命令：
dsh plugin add git+https://github.com/kangjiazhen/dsh-workbuddy-codex.git
或从本地目录安装：
dsh plugin add file:/path/to/dsh-workbuddy-codex
插件自带 cordis.patch.yml，安装后 profile 会自动加载 workbuddy-codex 配置项。
从 dsh-llm-workbuddy 迁移¶
如果 profile 中已启用 dsh-llm-workbuddy，现在可以移除它。在 profile 的 package.json 中，从 dsh.profile.bundles 中删除该行：
"dsh": { "profile": { "bundles": [
// "dsh-llm-workbuddy", <- 移除这行
"dsh-workbuddy-codex"
] } }
dsh-llm-workbuddy 仍需保留在 dependencies 中，因为本插件会导入它来挂载 provider。
安装失败处理¶
如果从 git 安装失败，可能需要设置 git 协议：
npm config set git-protocol https
如果通过代理安装，需要配置 git 代理：
git config --global http.proxy http://127.0.0.1:7890
使用示例¶
配置 Codex CLI¶
在 ~/.codex/config.toml 中配置 Codex 使用本地 bridge：
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
注意：
- wire_api = "responses" 必须设置为 responses，否则 Codex 启动时会报错
- experimental_bearer_token 为任意非空字符串即可，插件会从网关配置中读取真实密钥
使用 Codex¶
配置完成后，可以直接使用 Codex：
codex exec "list the files in this directory"
恢复被禁用的账户¶
如果 bridge 未提供 conversation_id，网关会返回 400 {"code":"11-128","msg":"request illegal"} 并禁用账户。可以通过网关面板恢复：
curl -X POST http://127.0.0.1:7863/panel/api/accounts/<uid>/revive
适用场景与注意¶
适合需要本地部署 WorkBuddy 并与 Codex CLI 集成、关注链路稳定性的开发者。插件以当前 DSH 进程权限运行，安装前建议检查源码与许可证（MIT）。
总结¶
dsh-workbuddy-codex 通过监控、自愈和桥接，让本地 WorkBuddy 反向代理链始终可用，同时解决 Codex CLI 与网关 API 不兼容的问题。它将网关、桥和 provider 统一管理，避免代码重复，是本地智能体开发环境的重要组件。
- 目录页：https://www.skillhub.cn/plugins/kangjiazhen/dsh-workbuddy-codex
- GitHub：https://github.com/kangjiazhen/dsh-workbuddy-codex
