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\

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

/(?<![\\/])(DeepSeek)[ \u00A0]+(Harness)(?![\\/])/gi

---

前置条件

项	要求
DSH 桌面版	已在用（本插件是 DSH 插件，不是独立程序）
任一 WorkBuddy/CodeBuddy 反代插件	dsh-our-free-model 或其它同类插件，已登录账号
Node.js	^22.19.0 或 >=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目录> 换成本机实际路径）：

<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. 执行：

<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 是演示视频，不是插件包。

方式三：克隆后装（要改代码时用）

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 就能恢复：

<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

有这三条我能直接定位。

卸载

<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 层拦不到。 判断方法：在面板看「介入次数」是否随对话增长。

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 里插一行：

;globalThis.__wbLexicon?.rewrite?.(messages);

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

安全边界

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

手动控制（可选）

# 只检查，不改文件
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

这是 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