DSH Connect Doubao

把豆包（Doubao）账号接入 DeepSeek Harness：对话模型与 「工作任务」模型（2.1 Lite / 2.1 Pro / 自动，走会员付费额度）、Seedream 生图，外加一块只读额度看板（5 小时限额 / 周额度 / 活动赠送额度，含重置倒计时）。登录方式只有一种：浏览器扫码登录一次。仅 Windows x64 —— 会话用 Windows DPAPI 密封在本机。

豆包卡片：额度面板与模型清单

⚠️ 前置条件（必读）

登录方式只有一种：浏览器扫码登录一次。不需要安装或登录豆包桌面客户端。

点卡片里的「重新登录」，插件拉起一个独立的 Chromium 窗口打开豆包登录页；你扫码（或手机号验证）之后它通过 CDP 取回会话 cookie，并用 Windows DPAPI 密封到 %USERPROFILE%\.dsh\doubao-credentials-browser.dpapi。整个流程只在登录那一刻需要人，之后都是纯 HTTP 调用。

要求	说明
扫码登录一次	未登录 → 卡片显示「未登录」，provider 不可用
Windows	会话密封依赖 Windows DPAPI。macOS / Linux 不支持
本机有 Chrome 或 Edge	登录窗口就是它，装在默认路径即可
有可用订阅额度	免费账号也能连，但配额很小

没有登录态时插件会明确报错（「还没有浏览器登录态。请在豆包卡片里点「重新登录」扫码一次。」），而不是静默失败。

功能特性

两组豆包模型 —— 对话模式两条（快速 / 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。
深度思考默认开启 —— 不再需要额外开关：非「工作任务」模型每轮发 need_deep_think: 3，任务模型沿用抓包到的真实形态 10001。DSH_DOUBAO_DEEP_THINK=0 可关掉。
只读额度面板 —— 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 独立确认）。

深度思考开关默认打开（2026-11-07 起）：非「工作任务」模型发 need_deep_think: 3 与 ext.use_deep_think: "3"；「工作任务」模型（2.1 Lite / Pro / 自动）沿用官方客户端抓到的真实形态 10001。设 DSH_DOUBAO_DEEP_THINK=0 可恢复成不思考的普通回合。档位始终只由 reasoning_effort 携带，与开关是两个独立的轴。

「豆包快速」不参与思考：深度思考全开、档位拉到高，它的回复仍是 thinking: false，流里也没有 10040 思考容器。所以它被标记为不可推理，模型选择器不再给它显示低/中/高。

思考过程为什么看不见：开关打开后服务端确实在思考（响应里出现 10040 思考容器和 10091 计时块），但推理正文不下发。2026-11-07 用官方客户端抓包对照确认：思考容器的子块只有一个 summary: "正在思考"，正文块里只有正式答案。这是接口限制，不是插件丢内容。

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

豆包把「能力」做成 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）被排除。缓存里缺了某条任务模型时，会从内置清单补齐。
缓存读不到、或解析结果不可信时，回落到内置清单，绝不清空用户的选择器。
结果缓存 10 分钟；卡片上的「刷新」（POST）会丢弃记忆重新读盘。
doctor 第 5 项会报告这次到底是从缓存发现的、还是回落的。

当前这台机器上的实测输出：

[ ok ] models  客户端缓存 5 个模型，开放 6 个（仅排除「即将下线」等不可用条目）

实验性：工具调用（默认关闭）

豆包没有函数调用通道。 带 OpenAI 风格的 tools 发请求，服务端会静默忽略 ——2026-10-22 实测：HTTP 200、流正常，但它转而使用自己的服务端搜索技能（流里冒出 block_type 10101 的「正在搜索」块），从头到尾没引用过我们声明的函数。这和 model_item_key 不校验是同一类事：字段根本没被读。

所以工具调用只能在提示词里模拟：把工具清单写进提示词，让模型输出一个 ```doubao-tool 围栏包一个 JSON，再解析回标准 tool_calls。

项	值
开关	设置卡片「实验性：工具调用」，默认关闭
配置字段	`toolEmulation: boolean`
围栏格式	```` ```doubao-tool ``\n`{"name":"…","arguments":{…}}`
解析结果	`delta.tool_calls` + `finish_reason: "tool_calls"`（流式与非流式一致）
工具结果回传	入站 `role: "tool"` 折叠成 `[tool result] <name>: <content>`

实测数据（2026-11-02）：

沙箱两工具循环：9 次调用、0 次 JSON 格式错误、5/5 轮收敛、平均 11.5 秒/轮、1 次重复调用
真机走 shim：第 1 轮 finish_reason=tool_calls、参数完整；回填结果后给出结论、无误围栏泄漏
反例：让它「查天气」时它不调用我们的工具，而是用自带的联网搜索直接答 —— 所以这套只在豆包自身不具备的能力上可靠（读写文件、跑命令），在它已有技能（搜索、生图、翻译）上会绕过。

失败模式是重复调用（没有原生 stop token），因此解析层内置去重，调用方仍需设置步数上限。这是一套模拟，上游模型换了输出习惯就可能退化 —— 这是它默认关闭、并且每条注释都写明「measured / simulated」的原因。

验证脚本：node scripts/verify-tool-emulation.mjs（只验证协议链路，不执行工具）。

工作原理

DSH (pi-ai provider)
  └─ doubao-adapter ──► 本机 loopback shim (127.0.0.1，仅本进程密钥)
                         └─ doubao-upstream ──► 豆包 /chat/completion
                                                （带上密封会话里的 cookie）

凭据：只来自浏览器扫码 —— 一次 CDP Storage.getCookies，立刻用 Windows DPAPI 密封到 ~/.dsh/doubao-credentials-browser.dpapi；读出的值只进请求头，从不写日志、命令行、环境变量或其它文件。
provider：把 pi-ai 的 OpenAI 形状请求翻译成豆包方言（bot_id + reasoning_effort）。
流式：上游的三行帧被解析成 pi-ai 的事件流，工具调用 / 压缩 / 权限仍由 Harness 掌控。
只读路由：/plugins/dsh-connect-doubao/quota 与 /catalog 提供额度与目录，按显式允许清单构造响应，不透传上游任何字段，并拒绝非 loopback 来源。

安装

三种方式

# ① 通过 DSH CLI（推荐）
dsh plugin --profile desktop add dsh-connect-doubao

# ② npm 直装
npm install -g dsh-connect-doubao
dsh plugin --profile desktop add dsh-connect-doubao

# ③ 本地开发（不发布，直接挂源码目录）
dsh plugin --profile desktop add "E:\path\to\dsh-connect-doubao"

方式 ③ 会写成 link: 依赖，改完源码 npm run build 即可，不需要重装。

受支持的宿主范围

项目	版本
DeepSeek Harness	`>=0.1.7-rc.1 <0.3.0-0`（实测：`0.2.0-rc.2`）
`@earendil-works/pi-ai`	`>=0.85.0 <0.88.0`（宿主实测：`0.87.1`）
Node.js	`^22.19.0 \|\| >=24.0.0`

官方 @deepseek-ai/* 依赖全部声明为 peerDependencies（不打包，由宿主提供），这既是插件市场的硬性要求，也保证运行期用的是宿主那一份。

平台支持

平台	状态
Windows x64	✅ 实测验证
macOS	❌ 不支持（DPAPI 是 Windows 专有）
Linux	❌ 不支持（同上）

登录态只有一个来源（src/doubao-auth.ts + src/doubao-auth-browser.ts）：

卡片点「重新登录」→ 拉一个独立的 Chromium 用户目录（~/.dsh/doubao-browser-profile），打开 https://www.doubao.com/chat/；
扫码（或手机号验证）完成 → 通过 CDP Storage.getCookies 一次取回全部 cookie；
只保留豆包/Bytedance 域下、且 9 个必需会话 cookie 齐备的那份，用 Windows DPAPI 密封到 %USERPROFILE%\.dsh\doubao-credentials-browser.dpapi（当前用户作用域，别的账户和别的机器解不开）；
之后所有请求只读这个密封文件，进程内缓存 10 分钟。

为什么不再解密豆包客户端的 cookie。 客户端运行时对 Default\Network\Cookies 持独占锁，而本插件恰恰是为「客户端正在运行」的账号准备的：读不到 → 回退到 12 小时前的密封副本 → 服务端早已换过会话 → 每个请求都被上游拒绝，而本地状态还显示「已登录」，用户无从判断。浏览器扫码没有这个死结：cookie 是当场抓到的，密封的也是刚抓到的，不存在更旧的副本可用。

数据目录（与登录无关）。 listDoubaoProfiles（src/doubao-profile.ts）按代价从低到高：配置文件里的 profileDir / 环境变量 DSH_DOUBAO_PROFILE → AppData 候选 → 运行中客户端的 --user-data-dir → 限时扫盘。它现在只用于模型清单的客户端缓存与「工作任务」模式的本地工作区；命中不到时工作区退回临时目录，仍然可以对话。

命令行

# 体检整条链路（不消耗推理额度）
dsh-connect-doubao-doctor
dsh-connect-doubao-doctor --json

# 冒烟探针（会消耗一次推理额度）
dsh-connect-doubao-probe --prompt "hi"
dsh-connect-doubao-probe --prompt "hi" --model 5 --thinking high --json

probe 的完整参数：

--prompt <text>              提示词（默认 "hi"）
--model <key>                模型 id，见上表
--thinking <low|mid|high>    推理强度
--json                       输出 JSON
--timeout <ms>               超时（默认 120000）

doctor 输出五项独立结论：凭据 / 账号 / provider 装配 / 额度 / 模型发现。凭据只报数量，不报值。

开发

npm install
npm run typecheck   # 节点侧 + 浏览器侧两套 tsconfig
npm run build       # 两个 target：node(ESM) + browser(CJS)
npm run test        # 客户端产物格式回归
npm run check       # 以上全部

⚠️ 浏览器侧产物必须是 CommonJS：桌面外壳用 <script> 加载它，不加 type="module"。 ESM 会直接抛 Cannot use import statement outside a module，并让整个 web boot 失败（1 entry did not activate）。 tests/client-bundle-format.test.ts 钉住了这条规则。

已知限制（请如实预期）

使用非官方接口。 豆包没有公开的第三方 API，本插件逆向其客户端行为。上游任何改动都可能让它失效，且不会有预告。
'4'（豆包 2.1 Turbo「即将下线」）未实测。 其余 5 个条目已实测可对话。
无法从响应侧独立验证"确实是这个模型"。 上游 SSE 的 message.ext 里有一个不透明标记（实测为 38），它不是版本号也不是档位，字节跳动从未公布其含义 —— 所以没有一个响应侧的字段可以拿来证明"服务端真的用了你选的那个模型"。本插件能确定的是：它把 model_item_key 随请求发出（这已抓包确认）。至于服务端如何解释这个键，只能由服务端回答。
仅 Windows。 会话密封依赖 DPAPI（macOS / Linux 不支持）。豆包客户端不需要安装：登录态只来自浏览器扫码。数据目录只在两处还会被读到 —— 模型清单缓存与「工作任务」模式的本地工作区 —— 自动探测几层（配置文件里的 profileDir、环境变量 DSH_DOUBAO_PROFILE、AppData 候选、运行中客户端的 --user-data-dir、限时扫盘）；全落空时工作区退回临时目录，不再影响登录。
风控滑块无法自动处理。 触发后需在弹出的登录窗口里手动完成验证，再点一次「重新登录」。
图片输入未提供。 本 provider 只发送文本块，不转发图片。
单账号。 没有账号池、没有区域切换、没有签到。
「工作任务」能跑，但扣不扣费取决于这一轮做了什么。 agent_mode 的取值是 2 = 普通对话、1 = 工作任务（CDP 抓包实测，2026-10-22）。任务模式下服务端把每一轮交给 Agent-GeneralTask，并由插件并发跑一个 tool_local 应答器（msg/ack → upload_command_result → msg/complete）把本地指令走完，所以不再必然回 710010702。但纯文本、不触发本地工具的小回合，服务端会在 ext 里标 general_agent_task_mode: "simple" 与 mode_downgrade_reason: "success"，此时活动赠送额度的 usedAmount 不变（实测调用前后恒为 782，即「走降级、不计费」）。想让任务模型真正消耗付费额度，得让它执行多步工具/文档任务。这一条是实测结论，不是产品承诺。
model_item_key 服务端不校验，所以「选中哪个模型」只能靠模式与账号决定。 三条证据（2026-10-23）：
1. CDP 抓到 App 选 2.1 Pro 时的真实请求：model_item_key: "5" + mode_id: "3" + agent_mode: 1 + general_task_param.runtime_type: 2（本地电脑）。
2. 用 mode_id=3 + key=5 在对话模式发请求：正常回答，但与 key=0 无可测差异（耗时 15.1–17.6 s、长度 311–340 字，均在噪声范围内）。
3. 真正的对照：把三处 model_item_key 全部改成一个不存在的值直接发送，服务端仍返回 200 与完整正常流，没有任何错误帧 —— 它不校验这个字段。所以 0.4.1 能提供的是**「工作任务模式 + 该 key」这一整组请求形态**（实测能出答案），而不是「服务端一定会用 Pro 而不是 Lite 来算」。要更强的模型，仍建议在豆包客户端里确认。
本插件的设置不走宿主 settings，存在自己的 JSON 文件里。 ~/.dsh/dsh-connect-doubao.settings.json，由插件自己写入（先写临时文件再原子重命名），读取也不依赖任何宿主服务在线。原因是宿主这条路对本插件完全关闭：它的 fiber 永远停在 state 1（LOADING，和 hmr、credentials 一样），因此 entry.fiber.runtime.Config 从不挂载 → 宿主 describe() 直接过滤掉这个命名空间 → 任何写入都以 No configurable plugin entry "dsh-connect-doubao" 失败。 历史上这个插件的设置一次都没能落盘过（包括手工改的），所以卡片会出现「点了没反应 / host did not persist the value / 保存成功但刷新后回退」三种症状。 schema 里仍然保留 asVolatile()：那是宿主侧的正当声明，一旦上游修好 fiber 生命周期，走宿主路径也不会再踩坑；只是在当前版本上它不再决定成败。tests/store.test.ts 和 tests/save-route.test.ts 钉住文件语义与路由安全边界。

免责声明

本项目仅供个人学习与研究使用。

使用本插件即表示你同意遵守豆包（Doubao）的服务条款；
使用风险自负，本项目作者不对任何账号封禁、额度损失或数据后果承担责任；
本项目与字节跳动（ByteDance）、DeepSeek、DeepSeek Harness 官方无任何关联或背书；
请勿用于商业用途或任何超出个人学习范围的场景。

致谢

dsh-connect-workbuddy —— 本插件在设计思路与插件结构上借鉴了它的做法（loopback shim、provider 注册链路、设置卡片挂载、构建与打包约定）， 所有代码均为独立实现，未复制其源码。

第三方开源依赖

依赖	用途
`@earendil-works/pi-ai`	模型 provider 运行时（宿主提供）
`@deepseek-ai/*`	Harness 插件框架（宿主提供）
`@deepseek-ai/schemastery`	设置 schema（宿主提供）

运行时不引入任何第三方连接器插件。

许可证

MIT

DSH Connect Doubao

把豆包（Doubao）账号接入 DeepSeek Harness：对话模型与 「工作任务」模型（2.1 Lite / 2.1 Pro / 自动，走会员付费额度）、Seedream 生图，外加一块只读额度看板（5 小时限额 / 周额度 / 活动赠送额度，含重置倒计时）。登录方式只有一种：浏览器扫码登录一次。仅 Windows x64 —— 会话用 Windows DPAPI 密封在本机。

豆包卡片：额度面板与模型清单

⚠️ 前置条件（必读）

登录方式只有一种：浏览器扫码登录一次。不需要安装或登录豆包桌面客户端。

要求	说明
扫码登录一次	未登录 → 卡片显示「未登录」，provider 不可用
Windows	会话密封依赖 Windows DPAPI。macOS / Linux 不支持
本机有 Chrome 或 Edge	登录窗口就是它，装在默认路径即可
有可用订阅额度	免费账号也能连，但配额很小

没有登录态时插件会明确报错（「还没有浏览器登录态。请在豆包卡片里点「重新登录」扫码一次。」），而不是静默失败。

功能特性

两组豆包模型 —— 对话模式两条（快速 / 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。
深度思考默认开启 —— 不再需要额外开关：非「工作任务」模型每轮发 need_deep_think: 3，任务模型沿用抓包到的真实形态 10001。DSH_DOUBAO_DEEP_THINK=0 可关掉。
只读额度面板 —— 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`	自动	`工作任务`	工作任务	✅

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

⚠️ msg/ack 必须单条查询。 { msg_ids: [0,1,2,3,4,5,6] } 会整体失败并返回 {"code":710010702,"msg":"系统错误"} —— 批里只要含一个服务端尚未生成的 seq，整批就废。这是逆向时最容易踩的坑，tests/ 里没有钉它（需要真实上游才能复现）。

推理强度：低 = 3、中 = 4、高 = 5（由客户端切换档位时重新序列化的配置 diff 读出，并由配置里的 reasoning_effort_config 独立确认）。

思考过程为什么看不见：开关打开后服务端确实在思考（响应里出现 10040 思考容器和 10091 计时块），但推理正文不下发。2026-11-07 用官方客户端抓包对照确认：思考容器的子块只有一个 summary: "正在思考"，正文块里只有正式答案。这是接口限制，不是插件丢内容。

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

字段	值
位置	`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

两个实测细节：

图片 URL 的签名有效期极长（抓到的 x-expires 在 2037 年），但服务端会把 .jpeg 结尾的 URL 实际返回 PNG 字节 —— 落盘时按内容判断格式，别信扩展名。
提示词会被服务端改写扩写（creation_material_info.creation_prompt 里是扩写后的版本），所以产物质量与措辞由豆包决定，不是逐字照发。

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

模型清单是自动发现的

缓存值是 V8 structured clone（不是 JSON）：字符串 = 标签 + LEB128 长度 + 数据， 0x22 是 Latin-1、0x63 是 UTF-16LE。实测确认 0x63 的长度字段是字节数而不是字符数 —— 按字符数会正好读多一倍，模型名后面会吃掉下一个字段的字节。
客户端给「工作任务」专属模型的名称自带前缀（工作任务 Pro、工作任务 Auto），所以模式归属直接从缓存里就能读出来。但带前缀不再等于隐藏：0.4.1 起它们会被标记成 taskMode 并正常开放，只有 DOUBAO_UNAVAILABLE_MODELS 里的条目（目前仅「即将下线」的 4）被排除。缓存里缺了某条任务模型时，会从内置清单补齐。
缓存读不到、或解析结果不可信时，回落到内置清单，绝不清空用户的选择器。
结果缓存 10 分钟；卡片上的「刷新」（POST）会丢弃记忆重新读盘。
doctor 第 5 项会报告这次到底是从缓存发现的、还是回落的。

当前这台机器上的实测输出：

[ ok ] models  客户端缓存 5 个模型，开放 6 个（仅排除「即将下线」等不可用条目）

实验性：工具调用（默认关闭）

所以工具调用只能在提示词里模拟：把工具清单写进提示词，让模型输出一个 ```doubao-tool 围栏包一个 JSON，再解析回标准 tool_calls。

项	值
开关	设置卡片「实验性：工具调用」，默认关闭
配置字段	`toolEmulation: boolean`
围栏格式	```` ```doubao-tool ``\n`{"name":"…","arguments":{…}}`
解析结果	`delta.tool_calls` + `finish_reason: "tool_calls"`（流式与非流式一致）
工具结果回传	入站 `role: "tool"` 折叠成 `[tool result] <name>: <content>`

实测数据（2026-11-02）：

沙箱两工具循环：9 次调用、0 次 JSON 格式错误、5/5 轮收敛、平均 11.5 秒/轮、1 次重复调用
真机走 shim：第 1 轮 finish_reason=tool_calls、参数完整；回填结果后给出结论、无误围栏泄漏
反例：让它「查天气」时它不调用我们的工具，而是用自带的联网搜索直接答 —— 所以这套只在豆包自身不具备的能力上可靠（读写文件、跑命令），在它已有技能（搜索、生图、翻译）上会绕过。

验证脚本：node scripts/verify-tool-emulation.mjs（只验证协议链路，不执行工具）。

工作原理

DSH (pi-ai provider)
  └─ doubao-adapter ──► 本机 loopback shim (127.0.0.1，仅本进程密钥)
                         └─ doubao-upstream ──► 豆包 /chat/completion
                                                （带上密封会话里的 cookie）

凭据：只来自浏览器扫码 —— 一次 CDP Storage.getCookies，立刻用 Windows DPAPI 密封到 ~/.dsh/doubao-credentials-browser.dpapi；读出的值只进请求头，从不写日志、命令行、环境变量或其它文件。
provider：把 pi-ai 的 OpenAI 形状请求翻译成豆包方言（bot_id + reasoning_effort）。
流式：上游的三行帧被解析成 pi-ai 的事件流，工具调用 / 压缩 / 权限仍由 Harness 掌控。
只读路由：/plugins/dsh-connect-doubao/quota 与 /catalog 提供额度与目录，按显式允许清单构造响应，不透传上游任何字段，并拒绝非 loopback 来源。

安装

三种方式

# ① 通过 DSH CLI（推荐）
dsh plugin --profile desktop add dsh-connect-doubao

# ② npm 直装
npm install -g dsh-connect-doubao
dsh plugin --profile desktop add dsh-connect-doubao

# ③ 本地开发（不发布，直接挂源码目录）
dsh plugin --profile desktop add "E:\path\to\dsh-connect-doubao"

方式 ③ 会写成 link: 依赖，改完源码 npm run build 即可，不需要重装。

受支持的宿主范围

项目	版本
DeepSeek Harness	`>=0.1.7-rc.1 <0.3.0-0`（实测：`0.2.0-rc.2`）
`@earendil-works/pi-ai`	`>=0.85.0 <0.88.0`（宿主实测：`0.87.1`）
Node.js	`^22.19.0 \|\| >=24.0.0`

官方 @deepseek-ai/* 依赖全部声明为 peerDependencies（不打包，由宿主提供），这既是插件市场的硬性要求，也保证运行期用的是宿主那一份。

平台支持

平台	状态
Windows x64	✅ 实测验证
macOS	❌ 不支持（DPAPI 是 Windows 专有）
Linux	❌ 不支持（同上）

登录态只有一个来源（src/doubao-auth.ts + src/doubao-auth-browser.ts）：

卡片点「重新登录」→ 拉一个独立的 Chromium 用户目录（~/.dsh/doubao-browser-profile），打开 https://www.doubao.com/chat/；
扫码（或手机号验证）完成 → 通过 CDP Storage.getCookies 一次取回全部 cookie；
只保留豆包/Bytedance 域下、且 9 个必需会话 cookie 齐备的那份，用 Windows DPAPI 密封到 %USERPROFILE%\.dsh\doubao-credentials-browser.dpapi（当前用户作用域，别的账户和别的机器解不开）；
之后所有请求只读这个密封文件，进程内缓存 10 分钟。

命令行

# 体检整条链路（不消耗推理额度）
dsh-connect-doubao-doctor
dsh-connect-doubao-doctor --json

# 冒烟探针（会消耗一次推理额度）
dsh-connect-doubao-probe --prompt "hi"
dsh-connect-doubao-probe --prompt "hi" --model 5 --thinking high --json

probe 的完整参数：

--prompt <text>              提示词（默认 "hi"）
--model <key>                模型 id，见上表
--thinking <low|mid|high>    推理强度
--json                       输出 JSON
--timeout <ms>               超时（默认 120000）

doctor 输出五项独立结论：凭据 / 账号 / provider 装配 / 额度 / 模型发现。凭据只报数量，不报值。

开发

npm install
npm run typecheck   # 节点侧 + 浏览器侧两套 tsconfig
npm run build       # 两个 target：node(ESM) + browser(CJS)
npm run test        # 客户端产物格式回归
npm run check       # 以上全部

⚠️ 浏览器侧产物必须是 CommonJS：桌面外壳用 <script> 加载它，不加 type="module"。 ESM 会直接抛 Cannot use import statement outside a module，并让整个 web boot 失败（1 entry did not activate）。 tests/client-bundle-format.test.ts 钉住了这条规则。

已知限制（请如实预期）

使用非官方接口。 豆包没有公开的第三方 API，本插件逆向其客户端行为。上游任何改动都可能让它失效，且不会有预告。
'4'（豆包 2.1 Turbo「即将下线」）未实测。 其余 5 个条目已实测可对话。
无法从响应侧独立验证"确实是这个模型"。 上游 SSE 的 message.ext 里有一个不透明标记（实测为 38），它不是版本号也不是档位，字节跳动从未公布其含义 —— 所以没有一个响应侧的字段可以拿来证明"服务端真的用了你选的那个模型"。本插件能确定的是：它把 model_item_key 随请求发出（这已抓包确认）。至于服务端如何解释这个键，只能由服务端回答。
仅 Windows。 会话密封依赖 DPAPI（macOS / Linux 不支持）。豆包客户端不需要安装：登录态只来自浏览器扫码。数据目录只在两处还会被读到 —— 模型清单缓存与「工作任务」模式的本地工作区 —— 自动探测几层（配置文件里的 profileDir、环境变量 DSH_DOUBAO_PROFILE、AppData 候选、运行中客户端的 --user-data-dir、限时扫盘）；全落空时工作区退回临时目录，不再影响登录。
风控滑块无法自动处理。 触发后需在弹出的登录窗口里手动完成验证，再点一次「重新登录」。
图片输入未提供。 本 provider 只发送文本块，不转发图片。
单账号。 没有账号池、没有区域切换、没有签到。
「工作任务」能跑，但扣不扣费取决于这一轮做了什么。 agent_mode 的取值是 2 = 普通对话、1 = 工作任务（CDP 抓包实测，2026-10-22）。任务模式下服务端把每一轮交给 Agent-GeneralTask，并由插件并发跑一个 tool_local 应答器（msg/ack → upload_command_result → msg/complete）把本地指令走完，所以不再必然回 710010702。但纯文本、不触发本地工具的小回合，服务端会在 ext 里标 general_agent_task_mode: "simple" 与 mode_downgrade_reason: "success"，此时活动赠送额度的 usedAmount 不变（实测调用前后恒为 782，即「走降级、不计费」）。想让任务模型真正消耗付费额度，得让它执行多步工具/文档任务。这一条是实测结论，不是产品承诺。
model_item_key 服务端不校验，所以「选中哪个模型」只能靠模式与账号决定。 三条证据（2026-10-23）：
1. CDP 抓到 App 选 2.1 Pro 时的真实请求：model_item_key: "5" + mode_id: "3" + agent_mode: 1 + general_task_param.runtime_type: 2（本地电脑）。
2. 用 mode_id=3 + key=5 在对话模式发请求：正常回答，但与 key=0 无可测差异（耗时 15.1–17.6 s、长度 311–340 字，均在噪声范围内）。
3. 真正的对照：把三处 model_item_key 全部改成一个不存在的值直接发送，服务端仍返回 200 与完整正常流，没有任何错误帧 —— 它不校验这个字段。所以 0.4.1 能提供的是**「工作任务模式 + 该 key」这一整组请求形态**（实测能出答案），而不是「服务端一定会用 Pro 而不是 Lite 来算」。要更强的模型，仍建议在豆包客户端里确认。
本插件的设置不走宿主 settings，存在自己的 JSON 文件里。 ~/.dsh/dsh-connect-doubao.settings.json，由插件自己写入（先写临时文件再原子重命名），读取也不依赖任何宿主服务在线。原因是宿主这条路对本插件完全关闭：它的 fiber 永远停在 state 1（LOADING，和 hmr、credentials 一样），因此 entry.fiber.runtime.Config 从不挂载 → 宿主 describe() 直接过滤掉这个命名空间 → 任何写入都以 No configurable plugin entry "dsh-connect-doubao" 失败。 历史上这个插件的设置一次都没能落盘过（包括手工改的），所以卡片会出现「点了没反应 / host did not persist the value / 保存成功但刷新后回退」三种症状。 schema 里仍然保留 asVolatile()：那是宿主侧的正当声明，一旦上游修好 fiber 生命周期，走宿主路径也不会再踩坑；只是在当前版本上它不再决定成败。tests/store.test.ts 和 tests/save-route.test.ts 钉住文件语义与路由安全边界。

免责声明

本项目仅供个人学习与研究使用。

使用本插件即表示你同意遵守豆包（Doubao）的服务条款；
使用风险自负，本项目作者不对任何账号封禁、额度损失或数据后果承担责任；
本项目与字节跳动（ByteDance）、DeepSeek、DeepSeek Harness 官方无任何关联或背书；
请勿用于商业用途或任何超出个人学习范围的场景。

致谢

dsh-connect-workbuddy —— 本插件在设计思路与插件结构上借鉴了它的做法（loopback shim、provider 注册链路、设置卡片挂载、构建与打包约定）， 所有代码均为独立实现，未复制其源码。

第三方开源依赖

依赖	用途
`@earendil-works/pi-ai`	模型 provider 运行时（宿主提供）
`@deepseek-ai/*`	Harness 插件框架（宿主提供）
`@deepseek-ai/schemastery`	设置 schema（宿主提供）

运行时不引入任何第三方连接器插件。

许可证

MIT

Wahwayhale/dsh-connect-doubao

DSH Connect Doubao

⚠️ 前置条件（必读）

功能特性

已验证

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

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

这不代表什么

模型目录

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

模型清单是自动发现的

实验性：工具调用（默认关闭）

工作原理

安装

三种方式

受支持的宿主范围

平台支持

命令行

开发

已知限制（请如实预期）

免责声明

致谢

第三方开源依赖

许可证

Community comments

Wahwayhale/dsh-connect-doubao

DSH Connect Doubao

⚠️ 前置条件（必读）

功能特性

已验证

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

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

这不代表什么

模型目录

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

模型清单是自动发现的

实验性：工具调用（默认关闭）

工作原理

安装

三种方式

受支持的宿主范围

平台支持

命令行

开发

已知限制（请如实预期）

免责声明

致谢

第三方开源依赖

许可证

Community comments