DeepSeek Harness 接入 WorkBuddy 的那条路，两天后就没了
DeepSeek Harness 刚出不久，我就刷到可以把 WorkBuddy 的模型接进 DSH 的教程。但一直拖着，没去实践。
现在终于要动手了，访问了项目仓库，才知道要下线了。但我还有一天的体验时间，学习一下吧。
写下这段话的时候，我盯着仓库首页的「停止维护公告」，有一种很具体的感觉——这条刚摸到手的路，还有 48 小时就断了。
这个项目叫 dsh-workbuddy-connect。它做的事一句话就能说清：把 WorkBuddy 桌面端里能用的模型，原封不动地搬进 DeepSeek Harness 的模型选择器里。
上图是我实际跑起来的样子。模型下拉框里，DeepSeek 账号分组下面多了一整个 WorkBuddy 分组：Hy4 preview、Hy3、Hy3-X、Step-5-Preview、Space-Bunny、Deepseek-V4.1-Flash……每个模型名后面还跟着积分倍率（x0.29、x0.00）和促销标记（限时免费、夜间免费、独家限免）。输入框底部显示着当前账号的积分余额。
零配置。 装上、重启、就能用。
一、三条必须知道的事实
先把最关键的信息摆出来，这决定了你要不要赶在明天之前动手：
| 时间 | 事件 |
|---|---|
| 2026-10-20 | 作者发布停止维护公告：不再处理新功能请求与 PR，不再提供更新、兼容性修复及问题支持 |
| 2026-10-20 | WorkBuddy 开始限制非官方客户端发出的请求 ← 这是停维的直接原因 |
| 2026-10-22 | 仓库计划下线（就是明天） |
先说第二条，因为它是整件事的因果起点。
README 里的原话是：
2026 年 10 月 20 日起，WorkBuddy 开始限制非官方客户端发出的请求。单从技术角度看，这类校验不难跨越。不过，送的模型额度既然附带了使用场地要求，WorkBuddy 已明确希望区分官方客户端与第三方接入，本项目尊重这一边界，不再继续适配。使用官方 WorkBuddy 客户端当然最安全。
这段话值得逐句读。
「单从技术角度看，这类校验不难跨越」——作者把话说得很明白：这确实是个技术门槛，不是算法难题。
「不过，送的模型额度既然附带了使用场地要求」——但模型额度是有附带使用场景约束的。这不是随手发出来的免费额度，是有商业考量的资源。
「本项目尊重这一边界」——所以作者选择了停，而不是选择绕过。
这一点我觉得是整件事里最值得尊重的地方。技术上能绕，作者不绕；平台划了线，作者就停手。这在开源生态里其实相当少见——很多项目遇到平台封堵的第一反应是「升级对抗」，而不是「我重新评估一下这样做对不对」。
公告的最后一句也写得很实在：
同时，由于个人时间和精力有限，本项目即日起停止维护……项目仓库计划于 2026 年 10 月 22 日下线。
所以从时间线上看，这不是一个「宣布弃坑、慢慢腐烂」的软着陆，是公告、限制、收紧、下线，四天之内一气呵成。
二、它是怎么做到的？
值得花点时间理解原理，因为理解了才能判断自己的方案能不能扛住。
插件的技术路线，拆开看是三层：
第一层：复用桌面端登录态
它不要求你重新填 API Key，而是直接读取本机 WorkBuddy 桌面 App 的登录凭据。账号切换自动跟随，国内版和国际版各用各的，互不干扰。
第二层：本地起一个 OpenAI 兼容的 shim
DSH 需要标准的 OpenAI 协议接口，而 WorkBuddy 的上游协议有几个「不标准」的地方，插件要在中间这层补上：
- 强制流式响应
tool_choice传字符串形式而非对象- 特定的 CLI 请求头
第三层：通过公开扩展点注册 provider
用 DSH 的 dsh-llm-pi-ai 扩展点把 workbuddy 这个 provider 注册进去，然后把模型目录、账号、积分、推理档位一并接进来。
整个实现是自包含的——上游提交记录里写得很清楚：
Self-contained DSH bundle: reuses the WorkBuddy desktop app's sign-in (read-only), serves a loopback OpenAI-compatible shim that applies the upstream wire quirks (forced streaming, string tool_choice, CLI headers), and registers the workbuddy provider through the public dsh-llm-pi-ai extension points.
用一句话概括：它是「读本地登录凭据 + 起本地代理 + 套进 DSH 插件体系」的组合，不涉及任何服务端改动。
这也就解释了为什么平台方一收紧就能立刻失效——整条链路都跑在官方客户端之外，官方只要在校验层加一道「你是不是我发的请求」的判断，就够了。
三、它做到了什么程度？
在停维之前，这个小插件的完成度其实相当高。几个细节能看出作者是认真做的：
国内版与国际版并存
两版各自显示分组、各自跟随登录状态、各自算积分。只装一版就只出现一个分组，退出一版对应分组就消失。设置里两张卡片分别展示各自账号和余额。
积分余额速览
选中 WorkBuddy 模型时，输入框底部直接显示剩余积分。积分不自动轮询——每次读取都是真实计费查询，挂载时读一次，之后可以点积分文字前方的 ↻ 手动刷新。
费率比例和促销徽章
每个模型名后直接显示积分倍率（GLM-5.2 · x0.79、Hy3 · x0.00），促销徽章（限时免费、夜间折扣）也跟在后面。数据以服务端为准，每次启动 DSH 时同步。
推理档位设计得很有分寸
这是我觉得最见功力的一块。作者没有拍脑袋给所有模型补齐统一的 low/high/max 档位，理由写得很清楚：
WorkBuddy 中模型的推理档位信息目前分散在上游接口与客户端自身的私有 UI 逻辑中，且模型目录变化很快。若插件根据经验为所有未声明模型补齐统一档位，就需要持续追赶这些未公开、没有稳定契约的产品逻辑。
实测还发现，有些模型虽然接受
reasoning_effort参数，却可能忽略未知值并回退到默认行为；一次请求返回成功，并不能证明某个档位真实可用。
所以对没有声明档位的模型，它让用户主动授权后动态检测——发少量请求，逐个确认哪些档位真的被上游接受。作者还特意声明：「结果只表示当前上游接受该档位，不承诺它一定改变推理效果、速度或积分消耗。」
这份克制，在插件类项目里非常罕见。 很多同类插件是「我猜一个档位糊上去，能用就行」。
还有企业账号积分
国内版企业账号走企业计费接口读周期额度，卡片会显示「企业额度」和周期重置时间。国际版企业账号则因为计费接口未验证，仍按个人版接口读。
四、如果你想赶在明天之前试一次
版本必须和 DSH 内核严格匹配，不匹配会导致 DSH 启动失败。npm 上的最新版不一定适合你：
| DSH 内核 | 推荐插件版 | 备注 |
|---|---|---|
0.2.1-rc.2 |
0.7.9 |
npm latest；仅适配这一内核 |
0.2.1-rc.1 |
0.7.7 |
内核升到 pi-ai 1.3.0；必须移除历史遗留的 0.87.1 overrides |
0.2.0-rc.2 |
0.7.6 |
上一代内核线；不要停留在有注册表回归的 0.7.2 |
0.2.0-rc.1 |
0.7.0 |
0.7.1 起不再支持 rc.1，请停留本版 |
0.1.5 – 0.1.7 |
0.6.5 |
旧内核最终版；0.7.0 起仅面向 0.2.0 |
Web 版安装（以 0.2.1-rc.2 内核为例）：
dsh plugin --profile web add dsh-workbuddy-connect@0.7.9
dsh web
TUI 版：
dsh plugin --profile dsh-tui add dsh-workbuddy-connect@0.6.5
dsh --profile dsh-tui
⚠️ TUI 的终端壳
@deepseek-harness-tui/dsh-tui需要0.10.0-beta.5及以上，更早版本装这个插件会启动失败（events is not iterable）。
Desktop 版要格外小心。 部分 Desktop 发行版（尤其官方 Electron 版）的 desktop profile 由 App 自己管理，官方版会直接拒绝独立 CLI 的 --profile desktop。别盲改 App 管理的目录，也别绕过校验。
验证标准：重启对应界面后，模型选择器出现「WorkBuddy / WorkBuddy AI」分组，并且从分组里选一个模型完成一次简短对话、能正常回复，才算成功。
日常运维命令：
# 查登录状态和剩余积分
dsh plugin --profile web exec dsh-workbuddy-connect status
# 诊断
dsh plugin --profile web exec dsh-workbuddy-connect doctor
# 清理凭据副本（国际版加 --provider workbuddy-ai）
dsh plugin --profile web exec dsh-workbuddy-connect logout
注意 logout 只是删插件自留的凭据副本，不动桌面 App 自己的登录，也不保证模型分组一定消失（App 的凭据文件还在就会继续生效）。
五、但我得说两句不太顺耳的
这个项目的 README 里有一节「免责声明」，写得比停维公告还重。我把关键的几条摘出来：
第三方接入存在账号风险。 官方服务条款对未经授权的第三方接入设有限制。使用本项目可能导致账号或功能受限、账号封禁、服务暂停或终止。能够正常调用、正常扣费，不代表获得官方授权或不存在账号风险。
最后那半句加粗的话，值得多读两遍。
「能用」和「被允许」是两件事。插件跑得通、扣费正常，这些都不能证明官方认可这个接入方式。停维公告里那句「使用官方 WorkBuddy 客户端当然最安全」，听起来像是客套，但配合这半句免责声明读，分量就完全不一样了。
如果你的账号绑着公司业务、绑着额度、绑着别的什么东西——那么为了省几块钱去接一个官方已经明确要限制的第三方客户端，性价比是负的。 官方客户端就在桌面上，点开就能用，没有任何学习成本。
而如果只是个人尝鲜、纯个人账号、丢了也不心疼——那用一天看看、玩明白了、明天卸掉，也没什么问题。
这才是我觉得这次「学习一下」最有价值的地方。 不是学怎么装这个插件——那只是一条 npm 命令。是搞清楚：
- 一个模型额度，是可以在多个 Agent 框架之间流转的。 理解了 shim + provider 注册这套机制，你就知道这事的上限在哪里。
- 平台方的「渠道校验」是真实有效的。 它不需要破解协议，只需要区分请求来源。
- 开源项目的生命周期受平台政策支配。 一个 1549 star、187 fork、两天内发了 30 多个版本的活跃项目，说没就没了。
六、然后呢？生态已经自己接上了
这是我这几天最意外的一点。原来的项目要死了，但社区没有跟着死。
GitHub 搜索 workbuddy dsh 能看到一批接力项目，而且大多还在活跃更新：
| 项目 | Star | 最近推送 | 做什么 |
|---|---|---|---|
ardeyouxipianyi/workbuddy2api-hub |
2262 | 10-20 | 多账号反代网关，支持 Codex / Claude Code / DSH 与标准 OpenAI 客户端 |
dingminhua/dsh-connect-workbuddy |
230 | 10-20 | 英文版接入，只读额度概览 |
XDTrees/dsh-xdpool |
201 | 10-17 | 多账号自动容错、十三家扫码登录、76 家免费额度聚合、用量看板、本地 OpenAI 网关 |
Axiaohungry/dsh-llm-workbuddy |
71 | 10-21 | 在 DSH 里用 WorkBuddy API |
masknull/dsh-workbuddy-connect |
52 | 10-20 | 内置登录、侧栏额度展示、模型自由开关、每日自动签到 |
dsh-plugin-lab/dsh-workbuddy-bridge |
13 | 10-20 | 原生嵌入「设置 → 插件 → 插件配置」 |
生态其实很自然：原项目提供的是一个具体实现，而它解决的是「把 WorkBuddy 额度接进 DSH」这个通用需求。作者不做了，社区按各自的需求分头实现——有的做多账号聚合，有的做反代网关，有的做更细的模型路由。
有个反直觉的细节：在停维公告发布的同一天（10-20），上面好几个项目都还在推送代码。公告说「不再继续适配」，但社区用行动给了另一个答案。
不过我得把这话说完整——接力的这些项目，面对的是同一个平台约束。原项目作者选择「尊重边界、就此停手」，社区这些项目则在继续做同样的事。这不是说谁对谁错，但如果你的账号有商业价值，风险判断还是得自己做。
顺便提一句，原 README 里推荐的 hana-workbuddy-connect 仓库（给 HanaAgent 做接入）现在已经 404 了。
七、最后
仓库明天下午就下线。到那时候，1,549 个 star、187 个 fork、32 个 npm 版本、30 多个社区替代项目，会一起变成一段历史。
但我一点也不觉得白折腾。
这三十来天里，1549 个人看过这个项目，187 个人 fork 了它，有人帮忙排查问题、有人提交 PR、有人在 issue 里留下几百条讨论。一个人的时间精力有限，但这个东西的的确确便利过一批人。
作者在公告最后写道：
非常感谢大家这段时间的使用、反馈和贡献，也谢谢每一位帮忙测试、排查问题和提交 PR 的朋友。特别高兴这个小插件曾给大家带来便利！
「曾」这个字用得特别准。
那么，就这样吧。趁它还在，装一次，看看它长什么样，然后体面地跟它说再见。
本文信息核实于 2026-10-21。仓库地址：
github.com/corrinehu/dsh-workbuddy-connect（MIT 协议）。文中所有版本号、Star 数、推送时间均为当日实测。