⚙️

dsh-workbuddy-stack

工作流更新于 2026.10.22

在终端中运行以下命令：

dsh plugin install kangjiazhen/dsh-workbuddy-stack

将以下提示词粘贴到 DeepSeek Harness 对话框中：

在 DeepSeek Harness 中执行 dsh plugin install kangjiazhen/dsh-workbuddy-stack，即可从 https://github.com/kangjiazhen/dsh-workbuddy-stack 安装并启用 WorkBuddy 网关、Responses 桥接与提供商委托监督。

插件介绍

在 Harness 里用 WorkBuddy 当本地模型源时，真正跑起来的往往不只是一个「提供商插件」：wb2api 网关、给 OpenAI Codex CLI 用的 Responses 桥接，以及模型选择器里的 workbuddy 路由，三者必须同时在线。它们默认都不会像系统服务那样随开机自启，重启后界面仍能列出模型，第一次请求却会撞上死端口——这种「看起来正常、用起来断链」的体验，正是本插件要消除的。

dsh-workbuddy-stack 做的是进程监督与编排，而不是再写一套网关或复制上千行的适配器。加载后它会探测各健康检查端点，缺什么就拉起什么，并按定时器复查，崩溃的进程会被重新拉起；提供商路由通过 ctx.plugin() 委托给 dsh-llm-workbuddy，配置与签到逻辑仍由那个包负责，避免双份实现日后漂移。插件内还自带与 codex-chat-bridge 同源的桥接层，把 Codex 只支持的 Responses API 转成网关能理解的 Chat Completions，并默认处理 conversation_id 等上游硬性要求，降低因缺头信息而被网关判为账号故障、整池禁用的风险。

适合已经在 profile 里接 WorkBuddy、希望「装一次就覆盖提供商 + 网关 + 桥接」的用户，尤其是要用 Codex CLI 走本地链路的开发者。若你仍单独启用 dsh-llm-workbuddy，两者可以并存：先注册路由的一方生效，另一方会安静退让；从旧布局迁移时，只需把 bundle 里的重复启用收拢到本插件即可。需要完全由外部任务或容器托管进程时，也可关掉自动拉起，只保留探测与状态上报。