dsh-connect-doubao

dsh plugin --profile web add dsh-connect-doubao

DSH Connect Doubao

把本机豆包（Doubao）桌面客户端已有的登录态接入 DeepSeek Harness：对话模型与

「工作任务」模型（2.1 Lite / 2.1 Pro / 自动，走会员付费额度）、Seedream 生图，

外加一块只读额度看板（5 小时限额 / 周额度 / 活动赠送额度，含重置倒计时）。

仅 Windows x64 —— 凭据解密依赖 Windows DPAPI。




---

⚠️ 前置条件（必读）

本插件复用豆包桌面客户端的登录态，因此必须先在豆包客户端登录。

它不会替你登录、也不会输入任何账号密码：它读取豆包客户端已保存在本机的

Chromium cookie（通过 Windows DPAPI 在本进程内解密），把它当作请求凭据。

要求 · 说明

豆包桌面客户端已登录 · 未登录 → 卡片显示「未登录」，provider 不可用

Windows · 凭据解密依赖 Windows DPAPI。macOS / Linux 不支持

有可用订阅额度 · 免费账号也能连，但配额很小

如果你没有登录豆包客户端，插件会明确报错而不是静默失败。

---

功能特性

• 两组豆包模型 —— 对话模式两条（快速 / 2.1 Turbo·专家）与「工作任务」模式三条

（2.1 Lite seed-lite-7b、2.1 Pro 5、自动 9）。任务模型走的是会员付费额度，

选中即自动切到任务模式的完整请求形态。

• 生图（Seedream 5.0） —— 模型选择器里选「豆包 生图」，回复即以 Markdown 图片返回真实生成图，可直接下载落盘。2026-11-02 实测端到端通过。
• 推理强度三档 —— 低 / 中 / 高，对应上游 reasoning_effort 实测值 3 / 4 / 5。
• 只读额度面板 —— 5 小时限额、周额度、活动赠送额度三条进度条，各带重置倒计时；设置面板里手动刷新 + 5 分钟自动刷新。
• 模型勾选清单 —— 勾选的条目会出现在 DSH 的模型选择器中，请求时按 model_item_key 指定模型。
• 账号状态行 —— 区分「已登录 / 未登录 / 登录信息读不出来」等状态，各自给出不同的处置建议。
• 独立 loopback shim —— 对话请求走一个只监听 127.0.0.1 的本地端点，带每进程共享密钥，任何非本机请求一律拒绝。
• 命令行诊断 —— doctor / probe，不消耗推理额度即可体检整条链路。

---

已验证

验证环境（一次具体的真机条件，不是"所有环境都可用"的承诺）：

项 · 值

操作系统 · Windows x64

豆包电脑版 · 2.31.4（已登录）

DeepSeek Harness · 0.2.0-rc.2（桌面版）

Node.js · 24.18.1（宿主内）

真机截图证明（用户实拍）

• ✅ 卡片挂在设置左侧导航里 —— 设置面板左栏出现「豆包」一级导航项，点击后右侧显示本卡片。
• ✅ 额度面板读到真实数据 —— 截图里可见 标准套餐、5 小时限额 已用 0% · 2h 17m 后重置、

周额度 已用 9% · 5d 21h 后重置、账号状态: 已登录、每 5 分钟自动刷新、配置目录路径。

• ✅ 模型清单六个条目全部渲染 —— 豆包 快速 / 2.1 Lite（0921 新版）/ 2.1 Turbo（专家）/

2.1 Pro / 2.1 Turbo（即将下线）/ 自动，角标与桌面包一致，计数显示 已启用 6 ↑。

> 这张截图来自 0.4.0：当时工作任务模型只被渲染出来、还没接通，徽章取客户端原名。

> 0.4.1 起它们带 工作任务 徽章并且真的能对话，截图尚未重拍。

• ✅ 模型选择器里出现「豆包（Doubao）」分组 —— 六个条目逐一列出。

这是 provider 注册成功 + catalog 生效 的端到端证据。

• ✅ 勾选交互可用 —— 每行一个勾选框，配 刷新 / 全选 / 全不选 / 保存 四个按钮。

代码级 / 抓包级证据（非截图）

• doctor 五项检查全绿：凭据 29 cookie 解密且 9/9 必需会话 cookie 齐备、账号被上游接受、

shim 绑定回环端口且错误 bearer 返回 401、三个额度窗口可读、模型发现开放 6 个。

• 推理强度 低=3 / 中=4 / 高=5：由抓取客户端切换档位时重新序列化的配置 diff读出，

并由客户端配置里的 reasoning_effort_config 独立确认。

• 请求体带 model_item_key 与 reasoning_effort：抓包确认。

这不代表什么

以上只对上述那台机器、那个账号、被验证的那个时间点成立。

不构成任何兼容性保证 —— 请务必读下面的「已知限制」。

---

模型目录

豆包把模型按模式分组，menu_list 每个模式有自己的一份清单：

模式 · 可选条目

对话 · 豆包 快速（0）、豆包 2.1 Turbo「专家」（3）

工作任务 · 自动（9）、2.1 Lite（seed-lite-7b）、2.1 Pro（5）、Turbo（3）

本插件提供这两组里的五条（外加生图别名）：

id · 名称 · 徽章 · 模式 · 推理强度

0 · 豆包 快速 · — · 对话 · ✅

3 · 豆包 2.1 Turbo · 专家 · 对话 · ✅

seed-lite-7b · 豆包 2.1 Lite · 工作任务 · 工作任务 · ✅

5 · 豆包 2.1 Pro · 工作任务 · 工作任务 · ✅

9 · 自动 · 工作任务 · 工作任务 · ✅

「工作任务」三条为什么能用了。 上一版把它们整个隐藏，理由是执行侧是豆包客户端进程内的

CUA 运行时（tasks-mode-resource + sbox），外部客户端注册不进去，每一轮必然得到

710010702。那个判断只对了一半：CUA 进程确实接不进去，但它不是必需的 —— 服务端

真正等待的只是三条 HTTP 应答：

POST /alice/office/tool_local/msg/ack              # 轮询本地指令
POST /alice/office/tool_local/upload_command_result # 回传执行结果
POST /alice/office/tool_local/msg/complete          # 标记该指令完成

服务端按 ${unique_key}:${device_id}:${aid}:message:${seq} 顺序下发指令（seq = 0,1,2,…）：

command: 6003（cmd_call，如 local.workspace.apply）需要回传结果，

command: 6004（agent_finished）表示这一轮结束。插件在流式生成期间并发跑一个应答器

把这些走完，于是任务回合不再落到 710010702。**实测 2026-11-05 跑通，Lite 与 Pro

各一次纯文本回合。**

⚠️ msg/ack 必须单条查询。 { msg_ids: [0,1,2,3,4,5,6] } 会整体失败并返回

{"code":710010702,"msg":"系统错误"} —— 批里只要含一个服务端尚未生成的 seq，

整批就废。这是逆向时最容易踩的坑，tests/ 里没有钉它（需要真实上游才能复现）。

推理强度：低 = 3、中 = 4、高 = 5（由客户端切换档位时重新序列化的配置 diff 读出，

并由配置里的 reasoning_effort_config 独立确认）。深度思考开关本身走

need_deep_think: 0；任务模式下抓到的真实请求固定发 10001，档位仍只由 reasoning_effort 携带。

---

生图（技能轴，与模型轴正交）

豆包把「能力」做成 skill，走的是同一个 /chat/completion 端点 —— 客户端里没有独立的文生图 HTTP 接口

（唯一的生成端点 /creativity/canvas/exec 是图片编辑器：抠图 / 扩图 / 分层，不是文生图）。

字段 · 值

位置 · ext.input_skill（JSON 字符串）

内容 · {"skill_id":"3","skill_type":3,"variables":{}}

关系 · skill_id 就是 skill_type 的十进制字符串；普通对话是 "0"/0

响应 · block_type: 2074 → content.creation_block.creations[].image.{image_ori,image_preview,image_thumb}

模型 · placeholder.description 显示 Seedream 5.0 Flash

技能全表（客户端枚举原样抄录，非推测）：0 自由对话、2 写作、3 生图、4 搜索、5 翻译、

6 阅读、7 网页、8 深度搜索、9 音乐、11 教育、13 代码执行、16 代码助手、17 视频、18 PPT。

本插件目前只接了 生图：模型选择器里的「豆包 生图（Seedream 5.0）」是 DSH 侧的能力别名

（image-gen，不是 model_item_key），选中后 shim 发一条普通对话轮并带上 input_skill: imageGen，

再把返回的图片以 ![…](url) 追加到正文。

两个实测细节：

• 图片 URL 的签名有效期极长（抓到的 x-expires 在 2037 年），但服务端会把 .jpeg 结尾的 URL

实际返回 PNG 字节 —— 落盘时按内容判断格式，别信扩展名。

• 提示词会被服务端改写扩写（creation_material_info.creation_prompt 里是扩写后的版本），

所以产物质量与措辞由豆包决定，不是逐字照发。

验证脚本：node scripts/verify-imagegen.mjs（会真实消耗生图额度）。

---

模型清单是自动发现的

插件不再硬编码模型表。 桌面客户端把服务端下发的 menuConfV2 存在自己的 IndexedDB 里，

本插件直接读那份缓存 —— 所以豆包上线新模型后，不需要等插件更新就会出现在 DSH 里。

• 缓存值是 V8 structured clone（不是 JSON）：字符串 = 标签 + LEB128 长度 + 数据，

0x22 是 Latin-1、0x63 是 UTF-16LE。实测确认 0x63 的长度字段是字节数而不是字符数

—— 按字符数会正好读多一倍，模型名后面会吃掉下一个字段的字节。

• 客户端给「工作任务」专属模型的名称自带前缀（工作任务 Pro、工作任务 Auto），

所以模式归属直接从缓存里就能读出来。但带前缀不再等于隐藏：0.4.1 起它们会被

标记成 taskMode 并正常开放，只有 DOUBAO_UNAVAILABLE_MODELS 里的条目（目前仅

「即将下线」的 4）被排除。缓

…(truncated)