请求拦截修复 balongTTY/dsh-workbuddy-fix

WorkBuddy 400 错误修复 · unapproved channel（code 11128）· DSH 插件

一键修复 WorkBuddy / CodeBuddy 的 Illegal API invocation from an unapproved channel（HTTP 400 / code 11128）。

装进 DSH，在「设置」页开关。提示词无损绕过 —— 语义不变、上下文不丢、可随时关闭。

关键词：unapproved channel · Illegal API invocation · code 11128 · 11140 · WorkBuddy 400 · CodeBuddy 400 · 请求被拦截 · 提示词风控 ·关键词过滤绕过 · 零宽空格 · DeepSeek Harness · prompt filter bypass

📺 看 24 秒演示 （1080p MP4，2.4 MB · 前情提要 → 报错长什么样 → 为什么不是渠道问题 → 真因与解法 → 装好后的开关）

背景音乐：Peaceful Instrumental Background Music by Peaceful Peach — CC0 1.0，来自 Internet Archive

演示视频放在 Release 附件里而不是仓库内 —— 仓库只装插件本体（< 100 KB），视频/动图会拖慢每个人的 git clone。需要 GIF 版可以自己从 MP4 转。

常见报错速查

| 你看到的报错 | 真实原因 | 本插件能修吗 |
| Illegal API invocation from an unapproved channel | 上游按关键词风控 system prompt | ✅ 能（这就是本插件） |
| code 11128 / code 11140 / HTTP 400 | 同一错误族 | ✅ 能 |
| first message is not system prompt | 首条消息不是 system 角色 | ✅ 能（「补首条 system」开关） |
| code 11133 integer_below_min_value | max_tokens 太小 | ❌ 调大 max_tokens |
| code 6004 usage exceeds frequency limit | 上游限流 | ❌ 换账号或等冷却 |
| EMPTY_RESPONSE / 有思考无正文 | 推理模型把 max_tokens 吃光 | ❌ max_tokens ≥ 4096 |

如果你是因为这个报错搜到这里

buddy: 请求被拦截，请重新发送 Illegal API invocation from an unapproved channel

Illegal API invocation from an unapproved channel

HTTP 400 · 上游 code 11128（有时 11140）

这个报错在骗你

文案说 "unapproved channel"（未获批准的渠道），但它跟渠道一点关系都没有。

我逐项实测排除过：换账号、换域名（copilot.tencent.com / www.workbuddy.ai）、换客户端身份（CodeBuddy / WorkBuddy）、补齐 13 个缺失请求头、调 reasoning_effort、调 max_tokens、减少工具数量（316→少量）、换网络、降并发 —— 全都不是原因。

真因：上游在对 system prompt 做关键词内容风控。
只要 prompt 里出现 DeepSeek Harness 这个词组，请求就被拒。

60 秒自证

用同一个 token 打两次，只改 system prompt 里的一个词：

| system prompt | 结果 |
| You are an AI agent powered by DeepSeek Harness. | ❌ 400 / 11128 |
| You are an AI agent. | ✅ 200 |

符合这个规律，就是这个原因。

💡 为什么它时好时坏：关键词要配合请求体够大（约 >1KB）才稳定触发。
短 prompt 即使含关键词也会放过 —— 这是最容易误判成「偶发故障」的地方。

修法：零宽空格

在 DeepSeek 与 Harness 之间插一个不可见字符 U+200B：

// 改前 "You are an AI agent powered by DeepSeek Harness." // 改后 "You are an AI agent powered by DeepSeek\u200B Harness."

- 模型看到的语义完全不变
- 上游的子串匹配不再命中
- 无损：没有裁剪、没有改写、没有丢上下文

实测（真实 DSH 请求形状：316 tools + effort=max + max_tokens=128000）：

原文 → ❌ 0/5 全部失败中和后 → ✅ 5/5 全部成功

⚠️ 文件路径不能被改写

运行时上下文里有真实路径：

D:\10_COD\DeepSeek Harness\resources\app.asar\dsh\

在路径里插零宽字符，会让模型把坏路径传给工具调用，直接失败。
所以匹配器带前后负向断言，跳过路径语境：

/(?=24.0.0 |

不需要：官方客户端后台常驻、额外 API Key、管理员权限。

兼容性说明：旧版要求必须装 dsh-our-free-model（因为它要往 OFM 的 pack.js 插一行钩子）。v1.1.0 起不再依赖任何第三方文件 —— 主通道改在 globalThis.fetch 层拦截，只要你的 WB 反代插件用 fetch 发 chat/completions 请求就生效，不管它是 OFM 还是别的实现、哪个版本、装在哪个 profile。

安装

先看这一步的版本要求：本插件需要 v1.1.4 或更新。
v1.0.0 是早期版本，没有 fetch 通道，对大部分人是无效的 —— 见下面的「装了没用？」。

方式一：从 GitHub 直接装（推荐，最简单）

在 DSH 里说：

我装了 github:balongTTY/dsh-workbuddy-fix 把 github:balongTTY/dsh-workbuddy-fix 装成插件

或自己执行（把 <DSH目录> 换成本机实际路径）： powershell <DSH目录>\resources\runtime\cli\bin\dsh.cmd plugin --profile desktop add github:balongTTY/dsh-workbuddy-fix

实测耗时约 30 秒（要拉 GitHub）。装完重启一次 DSH。

⚠️ 网络不通时这条会失败（GitHub 直连不稳）。用方式二。

方式二：下载 Release 附件（网络不好时用这个）

1. 打开 最新 Release
2. 下载 balong-dsh-workbuddy-fix-<版本>.tgz（约 41 KB）
3. 执行： powershell <DSH目录>\resources\runtime\cli\bin\dsh.cmd plugin --profile desktop add .\balong-dsh-workbuddy-fix-1.1.4.tgz

⚠️ 只下 .tgz 附件。v1.0.0 的 Release 里那个 wb400-intro.mp4 是演示视频，不是插件包。

方式三：克隆后装（要改代码时用） powershell
git clone https://github.com/balongTTY/dsh-workbuddy-fix.git
cd <DSH安装目录>\resources\runtime\cli\bin
.\dsh.cmd plugin --profile desktop add <克隆下来的目录绝对路径>

clone 实测约 0.35 MB（见体积说明）。

怎么确认装对了

重启 DSH 后打开 设置 → wb400修复，顶部应该显示：

主通道已接管（fetch 层）

看到这一行 = 新版且生效。
如果显示「未打钩子」「pack.js 钩子已打上」之类，说明装的是旧版，重装。

装完 DSH 起不来怎么办

先按下面「卸载」把插件摘掉，DSH 就能恢复： powershell <DSH目录>\resources\runtime\cli\bin\dsh.cmd plugin --profile desktop remove @balong/dsh-workbuddy-fix

然后去 Issues 反馈，带上：

1. 装的是哪个版本（v1.1.4 / v1.0.0 / 不确定）
2. 用的哪种方式（方式一 / 二 / 三）
3. DSH 启动日志里的报错原文
- 位置：%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-<时间>-*.log

有这三条我能直接定位。

卸载 powershell <DSH目录>\resources\runtime\cli\bin\dsh.cmd plugin --profile desktop remove @balong/dsh-workbuddy-fix

卸载不会动你的关键词配置（~/.dsh/workbuddy-meter/lexicon.json），重装后开关状态还在。

装了没用？先看这里

按顺序排查，通常第 1 或第 2 条就是原因。

① 版本装错了（最常见）

| 面板显示 | 说明 |
| 主通道已接管（fetch 层） | ✅ 新版，正常 |
| 未打钩子 / 只有 pack.js 状态 | ❌ 旧版（v1.0.x），重装 |

v1.0.x 只支持 workbuddy 渠道，走 buddy（CodeBuddy）渠道的用户完全不受益，而且它依赖 OFM 的文件结构，OFM 版本不对就打不上钩子。

② 报错前缀能区分渠道

| 报错 | 渠道 | v1.1.4 支持 |
| buddy: 请求被拦截… | CodeBuddy / copilot.tencent.com | ✅ |
| workbuddy: 请求被拦截… | WorkBuddy 国际版 | ✅ |

两个渠道 v1.1.4 都覆盖了（WB_HOSTS 里的 5 个域名）。

③ 反代插件没有走 globalThis.fetch 极少见，但如果你的反代插件用 undici 直连或 node:http，fetch 层拦不到。
判断方法：在面板看「介入次数」是否随对话增长。
powershell
node diagnose.mjs

会打印当前 OFM 版本、锚点情况，以及该用哪条通道。

④ 装了但一次都没触发

如果你用的是 dsh-connect-workbuddy，注意它有个特性：它会在 system prompt 丢失时补一句 "You are a helpful assistant." —— 那句里没有关键词，所以本来就不需要本插件介入（这种情况你也不会看到 400）。这不是 bug。

使用

打开 设置 → wb400修复，看到 4 个开关：

| 开关 | 默认 | 作用 |
| 总开关 | 开 | 关掉即完全恢复原始请求（一个字节都不改） |
| 中和身份关键词 | 开 | 上面说的零宽空格替换 |
| 补首条 system | 开 | 首条非 system 时注入保底 system（11128 的另一个成因） |
| 隐藏品牌词 | 关 | 更激进：连 DeepSeek 也打散 |

面板还会显示：

- 补丁状态（钩子是否在位）+ 补打钩子按钮
- 本机已中和多少处
- 改写效果预览（前后对照）
- 是否与「用量计量」插件联动

改完即时生效，不需要重启。

与 dsh-workbuddy-meter 的关系

本插件是 dsh-workbuddy-meter 里「关键词中性化」功能的独立精简版。

| | 本插件 | dsh-workbuddy-meter |
| 解决 400 错误 | ✅ | ✅ |
| 积分/token 计量面板 | ❌ | ✅ |
| 体积 | ~40 KB | ~300 KB |
| 设置页入口 | ✅ 独立页面 | 侧栏「用量」面板内 |

两个插件可以同时装，而且开关是联动的

它们共享同一个状态文件：

~/.dsh/workbuddy-meter/lexicon.json

任一方改了开关，另一方立即跟随 —— 一个打开，另一个也打开。
不会冲突，不会重复改写（钩子名相同，后装的覆盖先装的，但行为一致）。

只装其中一个也完全正常：
- 只装本插件 → 有修复功能，没有计量面板
- 只装 meter → 两者都有（meter 内置了同样功能）
- 都装 → 修复逻辑一致，开关双向同步

它对你的代码做了什么

主通道：fetch 层拦截（v1.1.0 起，不碰任何文件）

包装 globalThis.fetch，在请求真正发出前改写 body：

POST https://copilot.tencent.com/v1/chat/completions
↓
命中 WB 域名 → 读 body → 改写 messages → 重新序列化 → 发出

- 不修改任何第三方文件，所以 OFM 升级、换插件、换 profile 都不会失效
- 只命中 copilot.tencent.com / workbuddy.ai / workbuddy.cn / codebuddy.ai / codebuddy.cn 的 chat/completions，其它请求原样透传（已测：非 WB 域名 body 字节一致）
- 只处理 POST + JSON；body 解析失败、rewrite 抛错、messages 非数组 —— 一律原样放行
- 关掉总开关后，发出的 body 与原请求字节级一致

兼容通道：pack.js 行钩子（可选，不再是依赖）

旧方案仍保留，在 pack.js 里插一行： js
;globalThis.__wbLexicon?.rewrite?.(messages);

它的作用变成「兜底拦截非 fetch 请求」（比如插件自己起的 undici 实例）。
装不上不影响使用 —— 面板会显示「旧版钩子未打上（不影响使用）」，而不是像以前那样报「未打钩子」让人以为坏了。

安全边界

- 判定顺序：先看总开关 → 再看 URL 是否 WB → 再看 method 是否 POST → 才碰 body
- 任何一步不满足就 return original(...)，开销是一条 URL 字符串匹配
- 可完整卸载（恢复原 fetch 引用），测试里验证过引用相等

手动控制（可选） powershell

只检查，不改文件

node -e "import('./src/patch.mjs').then(m=>console.log(m.inspectLexicon(m.resolvePackFile())))"

打钩子（默认 dry-run，这里显式落盘）

node -e "import('./src/patch.mjs').then(m=>console.log(m.applyLexiconPatch({dryRun:false})))"

移除钩子（⚠️ meter 插件也依赖这行，会由它的自愈重打回来）

node -e "import('./src/patch.mjs').then(m=>console.log(m.revertLexiconPatch()))"

已知边界

- 只对本机 OFM 进程内的请求生效（服务器上反代的流量要单独装）
- 上游如果换关键词（不再拦 DeepSeek Harness），本插件就不需要了 —— 关掉总开关即可主通道（fetch）：与 OFM 版本无关

只要目标插件用 globalThis.fetch 发 chat/completions，任何 OFM 版本都能拦。

兼容通道（pack.js 钩子）：只支持 OFM v2.5.2 ~ v2.5.7

OFM 版本兼容矩阵

这是 14 个版本全量实测的结论：

| OFM 版本 | 锚点 | 说明 |
| v2.0.0 ~ v2.5.1 | ❌ | 锚点代码尚未引入 |
| v2.5.2 ~ v2.5.7 | ✅ | 唯一支持区间（6 个版本） |
| v2.5.8+ | ❌ | 上游移除 WorkBuddy 渠道（release note 原文：「移除 WorkBuddy 国内版和国际版渠道入口」）|

图里的 wb 是 pack.js 中 workbuddy 字符串的出现次数：正常 41 次，v2.5.8 骤降到 4 次 ——这是「渠道被移除」最直观的信号。

所以如果你的 OFM 是 2.5.1 及以下，面板会显示「旧版钩子未打上」——这不影响主功能，fetch 通道照常工作。若想用上兜底，需升级到 v2.5.2~v2.5.7 区间内。

⚠️ 不要把 OFM 升到 v2.5.8+：那个版本移除了 WorkBuddy 渠道，本插件的所有通道都会失去意义（没有 WorkBuddy 请求可拦了）。

- 如果某个反代插件用 undici 直连（不经 globalThis.fetch），fetch 钩子拦不到，这时才需要 pack.js 那行；两者都失效时面板会明确显示原因

仓库体积

克隆实测约 0.35 MB（.git 131 KB + 工作区 220 KB）。
代码本体不到 100 KB，其余是文档和兼容矩阵图。

演示视频（MP4 2.4 MB / GIF 3.1 MB）不在仓库里，也不在 git 历史里 ——它们放在 Release 附件和 README 的外链里。

v1.1.5 期间做过一次历史清理（git filter-repo），把早期误提交的视频从整条历史中移除，clone 体积从 10.47 MB 降到 0.35 MB。
如果你在此前 clone 过，请重新 clone —— 旧的本地副本历史与远程已不一致。

如果你要重新生成演示视频，源码在 _video/（render.mjs / mix-bgm.mjs 等），按里面的注释可以用 ffmpeg 重建（渲染产物已被 .gitignore 忽略）。

许可

MIT © 2026 balong