dsh-webin
Unofficial DSH plugin — 用真实浏览器驱动多个 AI 网页版（DeepSeek / 通义千问 / …）。
核心思路是不设计协议，操作界面：打开真浏览器 → 用真实输入把字打进输入框 →
页面自己发请求 → 从页面 DOM 把回复读出来 → 工具结果当普通消息打回聊天框。
没有任何一行在「调 API」 —— 没有 create_pow_challenge、没有 x-ds-pow-response、
没有 x-hif-* 回放。这是不封号的原因。
为什么读 DOM 而不是拦 SSE
插件同时有两条读回复的路，但主路径是 DOM：
| 怎么读 | 什么时候能用 |
|---|
| DOM（主） | 从页面渲染出来的回复容器里读，并把 <pre><code> 还原成围栏代码块 | 随时（内容在页面上，不依赖任何注入时机） |
| SSE（辅） | 包一层 window.fetch / XMLHttpRequest 观察页面自己的流 | 只在请求发出之前就装上 hook 才行 |
SSE 那条路有个绕不过去的时序问题：要在页面脚本执行之前注入 hook，
唯一的办法是 preload。而 DSH 的 webview 门禁会把 webPreferences
清空后只设固定几项（lib/main.js），preload 不在里面 ——
所以我们只能等 dom-ready，那时页面请求早就发出去了。
后果就是「页面明明有回复，插件却收不到」。所以 DOM 成为主路径，
网络拦截只是辅助信号。
选择器用的是实测出来的真实类名（ds-markdown / ds-think-content /
ds-pow-response），后面才是语义兜底 —— 不靠猜。
各版本改了什么见 CHANGELOG.md。
前置条件：宿主必须提供浏览器 guest 桥
⚠️ 本插件需要一个受控的真 Chromium，而这个能力只有带 Electron 通道的宿主才有。
它取桥的方式是：
const carrier = globalThis.dshDesktop // src/client/index.ts:922
if (carrier?.protocolVersion !== 1) return undefined
const bridge = carrier.browser // acquire / release
| 宿主 | 有桥？ | 说明 |
|---|
| 官方 DSH Desktop（Electron 应用） | ✅ | 设计目标环境 |
| DSH-X 启动器 + 浏览器里的 Web GUI | ❌ | 浏览器无法注入 Electron preload |
| 第三方 Electron 壳（未补桥） | ❌ | 默认没有桥 |
自建 Electron 壳（已补 webviewTag + preload 注入） | ✅ | 参见下方“没有官方 Desktop 时” |
在无桥宿主上的行为：插件仍然能安装并加载，模型选择器里也会出现 LDW，
但发任何消息都会失败。现在它会明确告诉你原因（而不是误导成“标签没打开”），
并在 /status 的 hostCapability 字段里报 no-desktop-bridge。
# 一条命令确认当前宿主有没有桥（在 DSH 页面按 F12）
# 有桥 -> { protocolVersion: 1, browser: {...} }
# 无桥 -> undefined
globalThis.dshDesktop
安装
# 从本地目录装进 DSH 的 desktop profile
dsh plugin --profile desktop add link:F:/Code/DSH-Code/dsh-webin/dsh-webin
# 或从 npm（若已发布）
dsh plugin --profile desktop add dsh-webin
--profile 要填你实际在用的那个。上面写 desktop 是因为
官方 DSH Desktop 用的就是这个保留名；用 dsh web 的人则是 web。
装错 profile 的典型症状就是“插件看不见”。
装完重启 DSH（host 半没有热重载）。然后在对话区会出现 LDW 标签，
模型选择器里出现「LDW · DeepSeek 网页版」。
首次使用：切到 LDW 标签 → 登录一次 → 回到对话选 LDW 模型。
没有官方 Desktop 时
两条路：
-
装官方 DSH Desktop —— 它天生提供桥。
-
给一个 Electron 壳补桥 —— 只需两步：
// 壳的 BrowserWindow：开 webviewTag + 注入 preload
webPreferences: { contextIsolation: true, nodeIntegration: false, webviewTag: true, preload: PRELOAD }
preload 向页面暴露 globalThis.dshDesktop = { protocolVersion: 1, browser: { acquire, release, onOpenRequested } }，
并在主进程用 session.on('will-attach-webview') 做租约门禁。
参考实现：官方 apps/desktop-host，
或一份等价的本地实现（D:\deepseekwork\dsh-desktop-shell）。
用持久分区（persist: 前缀）而非内存分区，还能顺带解决下方 L1（重启免登录）。
设置页
侧栏 → 设置 → 「LDW 网页版」。
平台：
- 看每个平台的地址 / 模型 / 上下文窗口 / 登录状态
- 添加自定义平台：贴一个 Provider JSON 即可，不用改代码、不用重启
- 删除自定义平台（内置项删不掉，要改就用同 id 覆盖）
插件配置（11 项，改完立刻生效，不用重启）：
| 分组 | 项 | 默认 | 说明 |
|---|
| 防封号 | 发送间隔 | 2~4 秒 | 网页版对请求密度敏感 |
| 每 N 次请求后长休 | 关 | 工具循环连跑十几轮时压低密度 |
| 单轮请求上限 | 不限 | 防止意外烧配额 |
| 行为 | 等回复超时 | 10 分钟 | |
| 浏览器未打开时快速失败 | 20 秒 | 不让你干等满 10 分钟 |
| 工具结果截断 | 4000 字符 | 太大顶爆输入框，太小模型看不到 |
| 允许调用工具 | 开 | 关掉 = 纯聊天 |
| 登录态快照间隔 | 30 秒 | |
| 诊断 | 详细日志 | 关 | 出问题时打开 |
每个数值都有边界。填超界会回退默认并告诉你哪项被修正 —— 不会静默生效，
也不会把「发送间隔填 0」（= 秒发 = 必封）这种值存进去。
登录状态显示「浏览器未打开」是正常的 —— 切到 LDW 标签就会变「已登录，浏览器在线」。
插件只在浏览器真的活着时才知道登录态，不猜。
状态
| 能力 | 状态 |
|---|
| 真实浏览器驱动（DSH 自带 Chromium guest） | ✅ |
| 真实登录 + 登录态持久化（重启免登录） | ✅ |
| 真实发送（填框 + 点发送键 / 合成 Enter） | ✅ |
| 从页面 DOM 读回复（主路径，含思考） | ✅ |
还原 pre 代码块围栏（工具调用靠它） | ✅ |
| 观察页面自己的 SSE 取回复（辅助路径） | ✅ |
| 工具调用（JS 代码块协议） | ✅ |
| 多平台（DeepSeek / 通义千问 / 自定义） | ✅ |
| 每个 DSH 会话绑定独立网页对话（重启后接回） | ✅ |
| 差分发送（不重发历史） | ✅ |
| 设置页（平台 / 登录态 / 11 项配置 / 增删自定义） | ✅ |
| 离线测试 | 865 项 |
多平台架构
一个平台 = 一个 Provider 对象
平台差异（选择器、评分规则、SSE 路径、模型表、上下文窗口）全部收敛到
一个 Provider（src/shared/providers.ts），
驱动层只认接口。新增站点 = 加一个对象。
const MY_PLATFORM: Provider = {
id: 'my-platform', // ← 同时是 workspace 名，决定登录态隔离
name: 'LDW · 我的平台',
homeUrl: 'https://example.com/',
urlPattern: 'example\\.com',
input: { selectors: ['textarea[placeholder*="输入"]', 'textarea'] },
send: {
selectors: ['button[type="submit"]', '[role="button"][aria-label*="发送"]'],
signatures: [['send-button', 60]], // 站点特征加分
vetoes: ['toggle', '停止'], // 命中即否决
},
completionPath: '/api/v1/chat/completions',
models: [{ id: 'fast', name: '快速' }],
contextWindow: 131_072,
maxOutputTokens: 8_192,
}
登录态隔离靠 workspace，不改 DSH 一行
DesktopBrowserGuests.acquire(owner, workspace) 按 workspace 字符串缓存 partition
（main.js:9636-9641）：
let partition = this.partitions.get(workspace);
if (partition === void 0) {
partition = `dsh-sidebar-browser-${randomUUID()}`;
this.partitions.set(workspace, partition);
}
所以用 provider.id 当 workspace 名，各平台自然拿到不同 partition、
不同 cookie / localStorage ⇒ 登录态天然隔离，零侵入。
三个层次的可扩展性
| 层次 | 做法 | 适用 |
|---|
| 内置表 | 在 BUILTIN_PROVIDERS 加一项 | 贡献新平台 |
| API 装载 | POST /dsh-webin/api/providers 贴一个 Provider JSON | 站点改版后修选择器，不改代码 |
| 磁盘持久化 | ~/.dsh/webin/providers/<id>.json | 跨重启存活，与登录态同一套存储 |
自定义 provider 覆盖同 id 的内置项（改坏了删掉即可回退），
且加载时逐个校验（validateProvider()）—— 一条坏的不影响其它。
运行时校验
TS 类型运行时被擦除，"必须实现接口"靠 validateProvider() 真正强制。
校验覆盖：id 格式（会用作 workspace 名）、
URL 合法性、正则可编译、models 非空、contextWindow 为正数…
加一个平台（三步）
1. 先探测真实 DOM —— 不要猜选择器：
npm run probe:dom # dump 输入框/按钮结构 + 用当前选择器匹配
2. 照着 provider.example.json 填一份 JSON，然后：
$h = @{ Authorization = "Bearer <secret>" } # 见 ~/.dsh/.credentials.yaml
$body = Get-Content provider.example.json -Raw
Invoke-WebRequest "http://127.0.0.1:19387/dsh-webin/api/providers" -Method Post `
-Headers $h -ContentType "application/json" -Body $body
装好后立刻生效（host 会热重载路由），新平台出现在模型选择器里，
文件落在 ~/.dsh/webin/providers/<id>.json，跨重启存活。
3. 在 LDW 面板顶部的下拉里选中它，登录一次即可（登录态独立保存）。
移除：
Invoke-WebRequest "http://127.0.0.1:19387/dsh-webin/api/providers/my-platform" `
-Method Delete -Headers $h
查看装载情况（含校验失败原因）：
Invoke-WebRequest "http://127.0.0.1:19387/dsh-webin/api/providers" -Headers $h
⚠️ 内置的 qwen 选择器尚未实测，第一次用前请跑 npm run probe:dom 校准。
未校准的 provider 不会静默失败：发送脚本找不到目标时会带诊断清单报错。
「只回一个字」的根因：裸文本帧没被处理
现象
网页版里回复是完整长文，DSH 对话里只有开头一个字。用户实测报障两次。
定位过程（npm run probe:frames）
先发现页面用 XHR 而非 fetch 发 completion（POST [XHR] /api/v0/chat/completion），
于是把探测脚本改成拦 XHR 逐帧记录，拿到真实帧序列：
[0] {"request_message_id":1,...} ← 元信息
[2] {"v":{"response":{...fragments:[{content:"1"}]}}} ← 初始快照
[3] {"p":"response/fragments/-1/content","o":"APPEND","v":"."} ← 带路径增量
[4] {"v":" HTTP"} ← ⚠️ 裸文本帧：没有 p、没有 o
[5] {"v":"（"} ← ⚠️ 正文主体全是这种，占 95% 以上
...
[131]{"p":"response/status","o":"SET","v":"FINISHED"}
正文的绝大部分是裸字符串帧（v 直接是要追加的文本，无路径）。
提取器只认「带 p 且路径匹配」的帧 ⇒ 每个回复只拿到快照里的第一个字。
早期测试没暴露是因为 8+8=? 的答案 16 恰好完整落在快照帧里。
修法
isBareTextDelta()：无 p、o 缺省或 APPEND、v 为非空字符串 ⇒ text += v。
显式排除元信息帧（有 request_message_id/updated_at 的走不进这个分支）
和错误信封（有 code/data）。o: 'SET' 的裸值帧不按增量处理。
回归：npm run verify:extract（13 项）把实测帧序列灌进产物里的真实提取器。
会话路由：每个 DSH 会话绑定自己的网页对话
缺陷（用户实测发现，封号级）
换了几个 DSH 窗口聊天，网页版里全落在同一个会话窗口 ——
上下文互相串、多个话题混在一条流里，行为模式像机器人，不被封才怪。
语义
| 场景 | 行为 |
|---|
| DSH 会话首条 | 在当前页发，落地 URL 由结果带回 host 存进游标 |
| 同一会话后续任务 | job 带 expectUrl（= 上次落地页），URL 相同则不导航（零开销） |
| 切换 DSH 会话 | job 带各自的 expectUrl，client 先导航过去再发 |
| 老 client / 抓 URL 失败 | 不绑定，行为不退化（当前页照发） |
数据流
adapter.stream(sessionId)
└─ cursors[sessionId].chatUrl → job.expectUrl
↓ client
页面 URL ≠ expectUrl → loadURL(expectUrl) → 等输入框 → 发送
↓ 结果
done → PUT result { text, chatUrl: location.href }
↓ host
cursors[sessionId].chatUrl = result.chatUrl
⚠️ 存 chatUrl 必须在 diff.commit() 之后 —— commit 会整体重写游标，
放前面会被它用旧值覆盖（verify-session-route 的 ⭐ 断言就是抓这个的）。
实测
npm run verify:session-e2e：两次发送分别落在两个不同的对话 URL
…/s/8530a042… 和 …/s/92020348…）。
npm run verify:session-route（14 项）：两会话互不串、切回仍回原对话、
无 chatUrl 时不退化。
每次重启新建对话 → 网页版侧栏堆一排会话
现象
用户侧栏出现「从1数到800」×3、「8加8等于16」×2 —— 每次重启/重挂载都新建对话。
（其中一部分是探测脚本直接用真实账号发的 —— 已知污染，抱歉。）
根因
boot 阶段无条件 loadURL(homeUrl)。首页被页面当成「开新对话」。
更严重的连带后果：host 的差分游标记着「这会话发过 N 条」，
而页面里是空的新对话 ⇒ 下一轮只发增量，模型完全没有上下文。
修法
快照里存了 url（上次离开时所在页面）。boot 时优先导航到它，
并做平台域校验（urlPattern 匹配 hostname+pathname 才用，防串平台）。
非法/无快照时才退回 homeUrl。
差分发送：为什么网页端聊天记录不该出现超长提示词
问题
第一版实现里，每发一条消息，网页端聊天记录里都堆着一条超长提示词。
根因是位置搞错了：DSH 是标准 LLM 宿主，每一轮都把完整历史
（system + 全部 messages）交给 adapter，由 adapter 自己决定怎么变成
provider 的请求体。对 HTTP provider 这没问题 —— 每次请求本来就该带全量上下文。
但网页版不是无状态 API：页面自己维护着对话历史。把整段历史每轮都打进
输入框有两个后果：
- 网页端聊天记录里堆满重复的超长提示词（用户一眼就能看到）；
- 上下文被重复计数 —— 模型看到的是「历史 + 又一份历史」，
有效上下文被砍半，还容易被判成刷屏。
为什么 harness 类工具没这问题
因为它们不是 LLM adapter，而是 harness —— 自己驱动 AI 页面，
系统提示词只在进入项目时发一次：
| harness 类工具 | 本插件（第一版） |
|---|
| 架构位置 | Electron 外壳，自己驱动 AI 页面 | DSH 的 llm adapter |
| 系统提示词 | 初始化时只发一次 | 每轮都随历史重发 |
| 每轮发送 | 只发新消息 | flatten 全量历史 |
| 页面角色 | 就是记忆体 | 被当成无状态 API |
本插件的做法
本插件处在 adapter 位置（DSH 要求这样），所以自己补上这层差分 ——
src/host/adapter.ts 的 diffPrompt()：
| 规则 | 原因 |
|---|
首轮发 system + 全部消息 | 页面需要一次拿到完整设定 |
| 后续轮只发新增消息 | 页面已有历史，不重复 |
| 跳过页面自己产生的 assistant 回复 | 那是页面吐出来的，重发会让记录里出现重复内容 |
| 历史变短（压缩/回退）→ 从头发 | 否则页面缺上下文 |
system 指纹变了（换 agent/preset）→ 重发 | 新设定必须传达 |
增量为空 → 直接返回 stop，不发 | 纯重复没有发送意义 |
用 sessionId 做键 | 多会话并行不互相污染 |
实测各轮长度（verify-diff.mjs 第 3 组断言）：
首轮 227 字符（含系统提示词）
后续 33, 33, 33, 33 字符（只有增量）
回归保护：npm run verify:diff（30 项）锁死上述全部规则，
包括「第二轮不含旧回复」「连续多轮每轮都跳过自己的回复」这类容易写错的地方。
投递失败不得推进游标
diffPrompt() 是纯函数，游标推进靠返回的 commit()，调用方只在投递成功后调。
早期版本在算增量的同时就推进游标，于是发送失败/超时后：DSH 认为「这段内容发过了」，
下一轮只发之后的增量 —— 而页面里其实没有这段内容 ⇒ 中间那段上下文永久丢失，
模型从此缺一段记忆。
不推进 ⇒ 下次调用重新算出同样的增量，内容不丢。
任务生命周期：三个会真实撞上的坑
1. 插队（最严重）
发送成功后 pendingJobRef 仍置着，而轮询每 1.5s 跑一次。
早期版本没有闸门 ⇒ 页面还在生成时又领了下一个任务，把新 prompt
打进输入框发送。后果：生成被打断、两个回复混在一起、done 分不清归属。
修法：pendingJobRef 有值 ⇒ 本轮只问 host「是否被取消」，不领新活。
2. 取消后任务挂着
用户按停止 → host 侧 signal.aborted 抛错退出，但任务仍留在队列里
处于 claimed 状态：
hasClaimed() 永远 true ⇒ /status 误报「面板在干活」- 页面继续生成到结束 ⇒ 白烧配额
- 之后回来的
done 还可能算成下一个任务的回复 ⇒ 串台
修法：queue.cancel() 标记任务；client 每轮轮询带 ?running=<jobId>，
host 回 cancel 就去点页面的停止按钮。
3. 待办永久卡死
pendingJobRef 靠 done 事件清空。若事件丢失（页面导航 / hook 被清 /
回复永不来），它会一直挂着 ⇒ 发送循环永久罢工，用户看到「模型一直不回复」。
修法：5 分钟超时兜底，交回错误并解锁循环（比 adapter 的 10 分钟更早）。
停止键定位：靠实测，不靠猜
真浏览器 dump（npm run probe:stop）出来的关键事实：
生成中，输入框区域同时存在：
发送键：ds-button--primary ds-button--filled ds-button--circle
停止键：ds-button--outlinedNeutral ds-button--outlined ds-button--circle ← 生成中才出现
| 特征 | 归属 | 用法 |
|---|
--circle | 两者共有 | 只给 +10 分（不能靠它区分） |
--filled / --primary | 发送键独有 | 命中即排除 |
--outlined | 停止键独有 | +60 分（阈值 60） |
而且生成中发送键不会消失（早期假设它消失，是错的）。
分数并列时不敢猜 —— 宁可不停止（只浪费一次配额），
也绝不能误点「深度思考」开关（那会改变后续所有请求的行为）。
实测结果：空闲时返回 no-stop-control（不误点），生成中命中
--outlinedneutral，score 90，候选唯一。
启动阶段机
早期用 documentCount === 1 / 2 / >= 3 计数决定做哪一步，有两个真实缺陷：
- 某步没发生就永久卡住：没有快照时
=== 2 分支直接 return 不 reload，
计数停在 2 ⇒ hook 永不注入、ready 永不置位、插件永久失效。
- 后续导航打乱计数（用户点链接 / 页面跳登录页）。
改成显式阶段机：
boot → navigating → restoring → reloading → live
每个阶段只做一次，不依赖「第几次 dom-ready」。另外：
- 每次
dom-ready 都重注入 hook（hook 是页面级的，导航后就没了；
buildDeepSeekHook() 自带幂等标记，重复注入无害）
- 加载失败回退到
boot（否则断网后永远不再前进）
- 渲染进程崩溃回退到
boot（OOM 后 webview 重载，阶段机要能重来）
工具调用（JS 代码块协议）
为什么用 JS 代码块，不用 JSON
网页版没有原生 function calling，所以要让模型把调用写成代码块。
设计上有两条路：JSON 协议，或 JS 代码块协议。本插件选后者，理由是
JSON 要求模型做转义，而转义是失败之源：
| JSON 协议 | JS 代码块协议 |
|---|
| 多行文本 | 必须写成 \n（模型常写成真实换行 ⇒ 解析失败） | 反引号模板字符串，直接换行 |
| 值里的引号 | 必须转义为 \" | 不用管 |
| 反斜杠路径 | C:\\Users\\… 双层转义 | 不用管 |
| 需要补的补救条款 | 一大堆（引号、换行、反斜杠…） | 无需 |
所以协议里直接写死：多行文本用反引号模板字符串，不做任何转义。
少一整类失败模式。
协议
需要调用工具时，输出一个 ```ldw 代码块，块外不要有任何文字：
```ldw
const r = await read({"path": "src/index.ts"});
log(r);
```
实测拿到的真实契约（没猜）
解压 ~/.dsh/sessions/*.jsonl.zstd（分帧 zstd，逐帧解压）拿到 4951 行、
851 行含工具调用的真实数据：
// tool-call：assistant content 里的块，arguments 是 JSON 字符串
{ "type": "tool-call", "id": "call_00_…", "name": "read_image",
"arguments": "{\"file_path\":\"C:\\\\…\"}" }
关键：tool-result 不是 content block，而是 role: 'tool' 的独立消息：
{ "role": "tool", "toolCallId": "call_00_…",
"content": [{ "type": "text", "text": "…" }], "isError": false }
字段名猜错 = 静默失败，所以先 dump 真货再写代码。
chunk 契约（实测序列）
block-start(text) → text-delta → block-end
→ block-start(tool-call) → tool-call-delta → block-end
→ finish(tool-calls) ← 有调用时必须这个，否则 DSH 不执行
tool-call-delta 的字段名是 argumentsDelta，block-end.block 里是
arguments（不是 args）—— verify:tool-chunks 专门断言这些字段名。
项目初始化：只补 DSH 缺的那部分
harness 类工具在进入项目时会注入 6 类内容。逐条核对 DSH 已经给了什么
（详见 docs/project-init-compare.md）：
| # | 章节 | DSH 是否已给 | 本插件 |
|---|
| 1 | 平台信息 | ⚠️ system 只提了一次 Windows（讲 exit code） | 补（cmd/pwsh 差异） |
| 2 | 项目目录 | ✅ system 末尾 Your working directory is … | 不补 |
| 3 | 项目介绍 | ✅ AGENTS.md 走 user 消息自动进入 | 不补 |
| 4 | 工具清单 | ⚠️ 走 options.tools，需自己格式化 | 补 |
| 5 | 技能清单 | ✅ skill 工具在清单里 | 不补 |
| 6 | MCP 清单 | ✅ MCP 工具在清单里 | 不补 |
| — | 身份与原则 | ✅ system 提供 | 不补（重复会冲突） |
为什么不全补：① 本插件是 adapter（system 由 DSH 给），重复注入 = 两份冲突指令；
② 体量是封号风险（实测记录：单次输入涨到 293k token，四个账号两天内被限制）。
体量控制
首轮 prompt: system + 工具协议 + 运行环境 + 工具目录 + 首条消息
后续轮 prompt: 只有增量（实测 11 字符）
60 个工具的工具段: 4,080 字符（对比 web-login 的 5 万）
工具结果超 4000 字符自动截断（防一次读大文件把 prompt 顶爆）。
当前进度
| 阶段 | 内容 | 状态 |
|---|
| P0 | 红框位置注册「LDW」标签 | ✅ 已完成 |
| P1 | LDW 面板内挂真实 Chromium guest + 加载 DeepSeek 网页版 + UA 洗白 + 登录态探测 | ✅ 已完成（实测可登录，无「环境异常」） |
| P2 | 注入 hook 观察页面自己的 SSE | ✅ 已完成（辅助路径 —— 见上文「为什么读 DOM 而不是拦 SSE」） |
| P3 | 注册 deepseek-webin provider，网页回复 → StreamChunk → 进「对话」 | ✅ 已完成 |
| P4 | 自动填输入框 + 触发发送 + 工具结果回传 | ✅ 已完成（三段式发送：填充 / 客户端延迟 / 触发） |
| P5 | 设置页（settings.section）+ 平台增删 | ✅ 已完成 |
| P6 | DOM 读回复成为主路径 + 围栏还原 + 思考读取 | ✅ 已完成 |
| P6 | 登录态持久化（重启免登录） | ✅ 已完成（快照 + 目标域回写，见下节） |
| P7 | 工具调用（JS 代码块协议） | ✅ 已完成（见「工具调用」节） |
| P8 | 每会话独立网页对话 + 重启接回 | ✅ 已完成（游标落盘 + 首轮开新对话） |
为什么重启 DSH 后不用重新登录
约束：分区一定是内存分区
DSH 的 guest partition 由 DesktopBrowserGuests.acquire() 生成（main.js:9638）：
partition = `dsh-sidebar-browser-${randomUUID()}`; // ← 无 persist: 前缀
而 webview 门禁又强制 params.partition === lease.partition（main.js:9685）：
if (lease === void 0 || lease.owner !== owner || lease.attached || params.partition !== lease.partition) {
event.preventDefault();
return;
}
所以插件不能自己换成 persist: 分区（会被门禁拒绝），
重启后 storage 必然是空的。唯一出路是「快照 + 在正确源上回写」。
坑：restore 必须在目标域上执行
早期实现在第一次 dom-ready（页面还是 about:blank）上跑 restore，
结果是每次重启都要重新登录。实测（npm run probe:origin）：
[A] about:blank 上写 localStorage
→ SecurityError: Access is denied for this document.
[B] 目标域上写 → 跨 reload 保留 ✓
两层原因：
about:blank 是 opaque origin，localStorage 直接抛 SecurityError；localStorage 按源隔离 —— 在 A 源写的值 B 源读不到。
正确时序
1. loadURL(homeUrl) → 到目标域
2. dom-ready #2：restore → 此时 localStorage 可写、且源正确
3. reload() → 带着登录态重新初始化
4. dom-ready #3+：注入 hook/探针
restore 脚本现在会回读校验并如实报告，不再静默吞异常：
{"ok":true,"restored":13,"verified":13,"failed":0,"cookies":2,
"origin":"https://chat.deepseek.com"}
在错的源上会明确拒绝：
{"ok":false,"reason":"wrong-origin","origin":"null",
"hint":"restore 必须在目标域上执行（about:blank 是 opaque origin，storage 不可写）"}
回归保护：npm run verify:restore（27 项）锁死时序与源校验，
npm run probe:origin 在真浏览器上验证源隔离假设。
仍然存在的限制
- httpOnly cookie 无法用 JS 回写（浏览器安全模型）。本站登录态主要靠
localStorage.userToken，所以不受影响。
- 清空
~/.dsh/webin/ 后需要重新登录（快照没了）。
- 登录态快照按平台分槽（
auth/deepseek.json、auth/qwen.json），互不覆盖。
本轮修复（压缩死锁）
症状
会话发任何消息都卡住，compaction/start 后长时间无响应，最久一次卡 6 分 12 秒才被中止：
[11:12:00] turn/start 21 → compaction/start → (96s) → aborted
[11:14:10] turn/start 22 → compaction/start → (4s) → aborted
[11:14:36] turn/start 23 → compaction/start → (372s)→ aborted
根因（两个 bug 叠加）
1. contextWindow 写错，阈值低到每步都触发压缩（src/host/adapter.ts）
context: { contextWindow: 128_000 } // ❌ 网页版真实是 1 Mi
compaction-basic 的判定是：
thresholdTokens = min(contextWindow × 0.8, contextWindow − maxTokens − headroomTokens)
| contextWindow | maxTokens | headroom | 阈值 | 该会话实测 359,267 tokens |
|---|
| 修复前 | 128,000 | 8,192 | 65,536 | 54,272 | 超阈值 6.6 倍 → 每步都压缩 |
| 修复后 | 1,048,576 | 32,768 | 65,536 | 838,860 | 远低于阈值 → 不触发 |
2. 压缩的摘要调用被路由回 LDW 自己
compaction-basic 的 summarizeWithLlm() 用 routedTarget(session) 选模型 —— 也就是最近一次实际路由的 provider。上一轮把会话切到 deepseek-webin/ldw-think 后，压缩就变成「必须经浏览器发消息」。而发送恰好是坏的 ⇒ 摘要任务进了队列没人能完成 ⇒ 干等满 timeoutMs（10 分钟）。
修法：waitForJob() 增加无人领活快速失败——超过宽限期（20s）仍没有 client GET /job/next，立即判 WEBIN_FAILED 并说明原因，不再干等。
3. 发送路径失效（send-failed: 未找到发送按钮，合成 Enter 也无效）
旧 chat.ts 的三个缺陷：
- 发送按钮只找
<button> —— DeepSeek 新版用 div[role="button"]，永远命中不到
- 兜底扫描只看 4 层祖先里的
<button> —— 同样漏掉 div[role=button]
- 合成 Enter 只发
KeyboardEvent，没有二次尝试
用真 Chrome 加载真实页面 dump DOM 后（npm run probe:send），拿到的事实：
| 元素 | 真实结构 | 后果 |
|---|
| 输入框 | textarea[placeholder="给 DeepSeek 发送消息 "] | 旧选择器能命中 |
| 发送键 | div[role=button].ds-button--primary.ds-button--filled.ds-button--circle | 不是 <button>、无 aria-label、无文字（纯图标）→ 旧代码必然找不到 |
| 附件键 | div.ds-button--iconLabelPrimary.ds-button--icon.ds-button--capsule | 与发送键同尺寸相邻，点错会弹文件选择框 |
| 开关 | div.ds-toggle-button（深度思考 / 智能搜索） | 点了会改发送语义 |
只用「几何位置 + 邻近度」评分时，发送键 32 分 vs 附件键 31 分 —— 只差 1 分。
加入站点特征评分后：
| 候选 | 修复前 | 修复后 |
|---|
| #1 发送键 | 32 | 214 |
| #2 | 31（附件键） | 39 |
| 分差 | 1 | 175 |
4. 发送确认判据不可靠 → 改成不确认
早期尝试用「多信号校验」确认发送成功，但每个信号都不可靠：
hasStopControl() 靠文本找「停止生成」—— DeepSeek 上是纯图标，测不到。
而 grew（页面正文变长）在 dry-run 里误报为 true（页面动画/懒加载也在改文本）。
更糟的是：校验本身要等待，于是「填充 → 等 2.4s → 校验 → 可能重试」
被塞进一次 executeJavaScript —— 那是跨进程调用，页面一导航就整体死掉
（不 resolve、不 reject）⇒ 宿主永远等 ⇒ 用户看到「一直深度求索中」。
现在的做法（读参考实现后重构）：发送三段式，每段都是短调用 ——
| 段 | 做什么 | 耗时 |
|---|
① buildFillScript | 只把字填进输入框 | 几百毫秒 |
② 客户端 setTimeout | 随机延迟（防封号） | 2–4 秒 |
③ buildTriggerScript | 只点发送键（或合成 Enter） | 几十毫秒 |
等待放在客户端，不放在页面脚本里 —— 这样单次跨进程调用的存活时间极短，
导航最多毁掉一次短调用，不会让整条链路僵死。
发送是否成功不再自证：由后续的 DOM 轮询来确认「页面上真的出现了新回复」。
5. 交付判据：条数增长 或 内容变化
判断「本轮回复来了」用两个判据取「或」：
| 判据 | 说明 |
|---|
| 条数比基线多 | 主判据 —— 只有真的新增 assistant 消息才会增长 |
| 内容与基线不同 | 兜底 —— 页面把回复渲染在选择器匹配不到的容器里时仍能交付 |
再加一道稳定性判据：连续两次读到相同内容才算生成完，
避免把「流式输出中的半截回复」交回 DSH。
6. 放弃门槛必须跟配置走
早期硬编码「5 分钟放弃」，但配置里 replyTimeoutMs 默认 10 分钟，
而且注释里记着「实测最慢一次网页回复 6 分 12 秒」——
于是 6 分钟才回完的请求会在 5 分钟被提前掐断。
现在按 replyTimeoutMs * 0.8 算（留余量让 adapter 那次超时不会先触发），下限 60 秒。
7. 其他
| 问题 | 修法 |
|---|
路由 / adapter 未释放 → 重载撞 duplicate prefix route | 改用 ctx.effect() 交回 disposer |
无超时的 executeJavaScript 会静默死锁 | execJs() 统一加超时护栏（超时 resolve 成 sentinel，不 reject —— 抛出去会被外层 catch 吞掉反而变静默） |
| 「已发送 · 收到 0 条」+ DSH 一直等 | 异常分支必须交回结果（早期只打日志 ⇒ pendingJobRef 永挂着 ⇒ 循环僵死） |
发送循环被 loggedIn 门控，误判即全链路失效 | 去掉门控，改由发送脚本在页面上自行判断 |
| 登录误报（登录页也显示「已登录」） | 探针改用 __appKit_userInfo.id 做强证据 + 负面证据交叉判定 |
__appKit_userInfo.id 解不出（明明登录却报 hasUserId:false） | 真实形状是 {"value":{"id":...}}，id 嵌在 value 里；两种形状都认 |
| 空快照覆盖有效快照（重启后仍要重新登录） | 未登录时 userToken={"value":null} —— 早期只查键是否存在，于是登录页的空快照盖掉了有效快照。改为 snapshotLooksLoggedIn() 解出值再判断 |
| 快照存了 cookie 但回写时被丢弃 | buildRestoreScript 补上 cookie 逐条回写（跳过属性残留片段） |
ctx.logger 畸形会让整个 apply() 抛错 → 插件装不上 | safeLogger() 显式判类型，10 种畸形形态全部安全降级 |
| 排查困难 | host 加 POST /client/heartbeat，/status 反映面板在线数 |
6. 压缩摘要不依赖浏览器面板
即使 contextWindow 修正后不再频繁触发压缩，摘要本身也不该走浏览器：
摘要输入动辄几十万 token，塞进网页输入框会让页面卡死，网页版本身也有长度上限。
adapter 现在对 purpose === 'compaction' 的调用立即拒绝（实测 0ms 返回，不进队列），
并给出可操作指引：
压缩摘要不能走 LDW 网页版：摘要输入体量远超网页输入框上限，且会把整轮对话锁在浏览器上。
请把 compaction-basic 的 summarizationProvider / summarizationModel
配成普通 HTTP provider（例如 wb-out / deepseek-v4.1-flash）。
根治方式是在 preset 的 compaction 组里显式钉死摘要模型：
- id: compaction-basic
name: '@deepseek-ai/dsh-compaction-basic'
config:
summarizationProvider: wb-out # ← 空对时会回退到"最新已路由目标"（= LDW），
summarizationModel: deepseek-v4.1-flash # 那就是死锁根源
dsh-compaction-basic/README.zh.md:70-71 原文：
与 summarizationModel 一起设置；空对使用最新已路由请求目标，再回退到 AgentOptions 对。
验证
npm run check # 构建 + 全部离线校验（355 项）
npm run verify:e2e # ⭐ 端到端：真浏览器 + 真登录态 + 真发送 + 真回复
npm run probe:chain # 全链路真实验证（会消耗一次网页版额度）
npm run check 覆盖：contextWindow = 1 Mi、压缩阈值复算、无人领活快速失败、
压缩摘要立即拒绝、心跳路由、任务队列领活/交结果全链路、
卸载后重装不撞重复路由、10 种畸形 logger 下仍能加载、
差分发送的全部规则（30 项，含「第二轮不含旧回复」）、
多平台路由与模型不撞名、以及两个挂载点声明完整。
npm run verify:e2e 是真浏览器端到端验证 —— 起一个真 Chromium、
注入真登录态（含 cookie）、注入真 hook、用真发送脚本发一条消息、
轮询真 drain 脚本抓回复，最后断言 5 项全绿：
[1b] 登录态回写: {"restored":13,"cookies":2}
[4] 发送: stage=sent | signals: {"requestSent":true,...}
[5] stream×4 → DONE status=finished len=2
网页版回复: 12
✓ hook 注入成功 ✓ 发送被确认 ✓ 收到 stream 增量
✓ 收到 done 事件 ✓ done 带正文 5/5 通过
| prompt | 回复 | 结果 |
|---|
1+1=? 只回答数字 | 2 | 6/6 |
2+2=? 只回答数字 | 4 | 6/6 |
3+3=? 只回答数字 | 6 | 6/6 |
单次输出形如：
[2] hook 注入: installed
[3] 探针: {"loggedIn":true,"hasUserId":true}
[4] stage: sent | signals: {"requestSent":true,...}
[5] ✓ hook 捕获到 completion 请求（计数 1）
[6] stream 事件数: 4
抓到的回复: 6
✓ hook 注入成功 ✓ 发送被确认 ✓ 捕获 completion 请求
✓ 收到 stream 增量 ✓ 收到 done 事件 ✓ done 带正文
6/6 通过
另外几个探测脚本（只读或可指定 prompt）：
| 命令 | 作用 |
|---|
npm run probe:dom | dump 真实页面结构 + 用插件选择器匹配，验证选择器是否失效。加 --url <地址> 可校准任意平台 |
npm run probe:send | dry-run 跑真实 buildSendScript()（拦截点击），验证候选评分 |
npm run probe:login | 分阶段验证登录判据（裸访问 / 注入后 / 延时探测），排查 loggedIn 误报 |
npm run probe:done | 逐秒 dump 事件队列，排查 done 事件为何不来 |
⚠️ 这三个脚本都要求本机有 Chrome/Edge，并会读取 ~/.dsh/webin/auth/default.json
的登录态。页面改版后先跑 probe:dom，比看 minified bundle 猜可靠得多。
架构
┌─ DSH Electron 主进程（app.asar/lib/main.js:9617-9803）──────────────┐
│ DesktopBrowserGuests（宿主自带，未修改） │
│ ipcMain.handle('dsh-desktop:browser-acquire') → { lease, partition }│
│ ipcMain.handle('dsh-desktop:browser-release') │
│ will-attach-webview：校验 about:blank#<lease> + partition │
└──────────────────────────────────────────────────────────────────────┘
▲ window.dshDesktop.browser（宿主 preload 已暴露给主窗口主 frame）
│
┌─ dsh-webin client 半（本插件）──────────────────────────────────────┐
│ │
│ ① 常驻宿主 shell.overlay id='ldw-host' ← root scope，永不卸载 │
│ └─ acquire(workspace) → <webview src="about:blank#<lease>"> │
│ → 真 Chromium guest → loadURL(chat.deepseek.com) │
│ │
│ ② 占位符 conversation.view id='ldw' order=20 ← 用户要的红框位置 │
│ └─ 只量自己的 rect 并广播（不含 webview） │
│ │
│ ① position:fixed 贴到 ② 的 rect 上；② 卸载时 rect=null → ① 移出视口 │
└──────────────────────────────────────────────────────────────────────┘
为什么拆成「常驻宿主 + 占位符」两半
因为 conversation.view 切标签会卸载组件。 四环证据：
| # | 证据 | 位置 |
|---|
| A | conversation.view 声明为 kind: 'list' | ui-conversation/lib/client.js:18209 |
| B | 渲染点传 { only: viewId } | ui-conversation/lib/client.js:16412-16421 |
| C | renderer 对 only 是 filter + 单元素 map，不是 CSS 隐藏 | ui-renderer/lib/client.js:1193-1196 |
| D | 全部 client bundle 里 keepAlive / Offscreen 零命中 | — |
React 语义下，兄弟元素 key 从 e<chat> 变成 e<ldw> ⇒ 旧子树整体卸载。
若把 <webview> 直接放里面，用户一切到「对话」看回答，guest 就被销毁、
lease 被释放、轮询全停 —— 生成中的回答直接中断。这正是「把 LDW 当模型用」的核心场景。
shell.overlay 则是 kind: 'list' + scope: 'root'，渲染点
renderSlot('shell.overlay', {}) 不传 only ⇒ 全部注册项常驻
（ui-layout/lib/client.js:312,617）。官方 ui-chat 的额度浮层就是这么挂的
（ui-chat/lib/client.js:12473）。
⚠️ 宿主容器绝不重新挂载：Electron 的 <webview> 一旦从 DOM 移除再插回，
guest 会重新加载。所以宿主只改坐标（left/top/width/height + visibility），
DOM 节点自始至终不动。切走时也不用 display:none（会让 webview 停止布局），
而是移出视口 + visibility:hidden。
运行时可用 cordis_inspect_query（client / Slots / listSubTree）确认两个挂载点：
shell.overlay → occupants 含 { id: "ldw-host", order: 20, active: true }
conversation.view → occupants 含 { id: "ldw", order: 20, active: true }
为什么必须走 webview，不能自己开窗
插件跑在 dsh-desktop-host 子进程里，require('electron') 直接失败
（已实测：Cannot find module 'electron'，process.type === undefined）。
所以拿不到 BrowserWindow / WebContentsView。
DSH 自带的 webview guest 通道是唯一可用且零新增内核的真浏览器路径。
guest 的三条硬约束（来自 main.js:9682-9707）
const id = params.src.startsWith("about:blank#") ? params.src.slice(12) : "";
const lease = this.leases.get(id);
if (lease === undefined || lease.owner !== owner || lease.attached
|| params.partition !== lease.partition) { event.preventDefault(); return; }
src 必须精确等于 about:blank#<lease>partition 必须等于 acquire 返回的 partition- 一个 lease 只能挂载一次（
lease.attached 后再挂会被拒）→ 重开必须重新 acquire
开发
npm install # 首次
npm run check # 构建 + 全部校验（355 项）
拆开跑：
| 命令 | 内容 |
|---|
npm run build | 构建 lib/index.js + lib/client.js |
npm run check | 全部离线测试（865 项，不需要浏览器） |
npm run verify:scrape | ⭐ DOM 读回复（53 项，真实 DOM 树桩） |
npm run verify:stuck | 防僵死 / 交付判据（87 项） |
npm run verify:fill | 填充与换行归一化（30 项） |
npm run probe:dom | 真实页面结构 dump（只读） |
npm run probe:send | 发送脚本 dry-run（只读，拦截点击） |
npm run probe:chain | 全链路真实验证（⚠️ 真发送，消耗额度） |
⚠️ 需要真浏览器的探针脚本尚未适配发送流程重构。
probe:send / probe:chain / probe:done / probe:frames / probe:stop /
verify:e2e / verify:coldstart / verify:session-e2e 仍引用已删除的
buildSendScript()（改成三段式发送后不存在了）。
它们的文件头已写明怎么改（把 buildSendScript(...) 换成
buildTriggerScript(...)），但替换后需要真浏览器验证，所以没有自动改动 ——
用未验证的代码替换已运行的代码只会更糟。离线测试（npm run check）不受影响。
装进 profile（Desktop）：
// ~/.dsh/profiles/desktop/package.json
"dependencies": { "dsh-webin": "link:F:/Code/DSH-Code/dsh-webin/dsh-webin" },
"dsh": { "profile": { "bundles": [ ..., "dsh-webin", ... ] } }
并建 junction：
New-Item -ItemType Junction -Path "$env:USERPROFILE\.dsh\profiles\desktop\node_modules\dsh-webin" `
-Target 'F:\Code\DSH-Code\dsh-webin\dsh-webin'
⚠️ profile 的 bundles 只在 Host 启动时读一次 —— 必须重启 DSH 才会加载本插件。
改完哪一半要怎么生效
| 改了什么 | 生效方式 |
|---|
src/client/*（面板、发送脚本、hook） | HMR 自动，刷新页面即可 |
src/host/*（provider、路由） | 必须重启 DSH（host 半没有 HMR） |
⚠️ 用插件管理器「禁用再启用」不能替代重启：旧版本（无 disposer）留下的幽灵路由
不会被回收，会撞 webserver: duplicate prefix route "/dsh-webin/api"。
新版本已用 ctx.effect() 修好，但已经在跑的旧实例留下的路由仍要重启才清得掉。
排查「模型不回复」
按顺序看这三处：
# 1. 面板在不在线（online: 0 = 没面板在跑，任务必然无人领取）
$h=@{Authorization="Bearer <secret>"} # secret 见 ~/.dsh/.credentials.yaml 的 client-connection/browser-session
Invoke-WebRequest "http://127.0.0.1:19387/dsh-webin/api/status" -Headers $h -UseBasicParsing
# 2. 队列里有没有积压
Invoke-WebRequest "http://127.0.0.1:19387/dsh-webin/api/job/next" -Headers $h -UseBasicParsing
- 切到 LDW 标签，点面板上的**「诊断」**按钮 —— 会 dump 页面输入框与按钮结构。
挂载点自证
// cordis_inspect_query: platform=client, provider=Slots, method=listSubTree
{ "root": "shell.overlay" } // 应含 { id: "ldw-host", order: 20, active: true }
{ "root": "conversation.view" } // 应含 { id: "ldw", order: 20, active: true }
网页版自己停了怎么办：点它自己的「继续生成」
网页版会在服务端主动停止时把回复截断，界面上显示「已停止」并留一个
「继续生成」按钮。这时如果直接把已抓到的内容交付，用户看到的是
「任务没做完，DSH 却报已完成」。
处理顺序：
- 点页面自己的「继续生成」（优先）—— 这是同一条消息的续写，
正文连续、立即生效。最多 3 次。
- 点不到（没有该按钮 / 分数并列不敢猜）⇒ 退回原看门狗：
静默 12 秒且只有思考时，发一条新消息「请继续」，最多 3 次。
- 都不行 ⇒ 正常交付（有什么交什么）。
两道闸门都放在交付之前，且计数独立 —— 一个手段失败不消耗另一个的额度。
回复不完整 / 服务端不可用时怎么办
网页版在服务端不可用（「服务器暂时不可用」「请求过于频繁」）时会直接掐断
生成，留下半截内容。插件不会把这半截当成功交付，判据两条：
| 判据 | 含义 |
|---|
fenceOpen | 回复停在未闭合的代码围栏里 ⇒ 一定没写完（工具调用整段在围栏里，所以能直接挡住「半截工具调用」） |
serverError | 页面上明确写着服务端错误 |
命中任一条 ⇒ 本轮不算成功，按顺序处理：
- 提醒用户：面板状态栏 + 控制台
- 重试（最多 3 次）：先点页面自己的「继续生成」；点不到就重发原 prompt
—— 服务端限流通常几秒就恢复
- 重试耗尽 ⇒ 交付现有内容，但在正文开头加一条明确警告，说明本次不完整、
可能被截断、建议重发
三种补救手段（续写按钮 / 看门狗「请继续」/ 不完整重试）计数各自独立 ——
一个手段失败不消耗另一个的额度。
新会话的任务没人领？（WEBIN_FAILED）
常驻宿主全局只有一个（挂 shell.overlay、root scope、永不卸载），所以整个
窗口只有一个领活循环；而 sessionId 来自每个 DSH 会话各自的占位符，写进同一个
模块级 ref —— 最后一个挂载的覆盖它。
于是只拿得到一个 sessionId，其余会话的任务永远匹配不上 ⇒ 20 秒无人领 ⇒
「LDW 面板未连接」。
现在的行为：领活分两轮 —— 本会话的任务优先拿，本会话没有就回退领走。
回退是安全的，因为 client 会按 expectUrl / freshChat 自己导航到正确的网页对话。
/status 里每条任务带 claimedVia：
| 值 | 含义 |
|---|
session | 会话匹配（正常） |
fallback | 会话对不上，为了不让任务没人领而回退领走 |
频繁出现 fallback 说明会话身份长期对不上，值得查。
网页版在生成，DSH 却报「没发出去」？
「早期放弃」判据（发出后 30 秒无动静就报错）必须被 generating 一票否决：
| 信号 | 含义 | 可信度 |
|---|
generating（停止按钮在） | 页面正在生成 ⇒ 消息一定送到了 | 高 —— 直接反映页面状态 |
| DOM 有没有变化 | 可能读不到（思考阶段还没有回复容器） | 低 —— 会误判 |
网页版处在思考阶段时，.ds-markdown 还没出现，插件的 DOM 读取什么都看不到
（条数没增长、内容没变化、思考区也没读到）—— 三个条件同时成立就会误判成
「没发出去」。所以只要页面在生成，就绝不放弃。
「页面是否在生成」靠什么判断
不能靠 aria-label —— DeepSeek 的停止键是纯图标（无 aria-label、无文字），
aria-label*="停止" 这类选择器永远匹配不到。曾经因此让 isGenerating()
恒返回 false，连带「生成中不交付」闸门从未生效。
正确判据是校准过的 class 特征（与 buildStopScript 同源）：
| 特征 | 含义 |
|---|
ds-button--outlined | 停止键独有 ⇒ 命中即判定生成中 |
ds-button--filled / ds-button--primary | 发送键独有 ⇒ 排除（生成中它不会消失） |
| aria-label / title 含 stop / 停止 | 语义兜底（页面改版后可能补上） |
找不到任何特征时返回 false（不阻止交付 —— 宁早勿卡）。
已知限制
L1：guest partition 不持久（需重启后重新登录）
main.js:9638：
partition = `dsh-sidebar-browser-${randomUUID()}`; // ⚠️ 没有 persist: 前缀
没有 persist: 前缀 ⇒ 内存分区，连磁盘都不落。官方 README 原文：
「Cookie 与 Web storage 不跨应用重启保留」（ui-sidebar-browser/README.zh.md:110）。
本插件用纯插件方案兜底：登录后每 30s 把 guest 的 localStorage（userToken /
appKit* / hif_*）+ 非 httpOnly cookie 存到 ~/.dsh/webin/auth/default.json，
下次启动导航前回写。
⚠️ httpOnly cookie 用 JS 读不到 —— 若 DeepSeek 的登录态主要靠它，这条路会不完整。
那种情况下只能改 DSH 那一行（9638 加 persist: 前缀），代价是升级会被覆盖。
L2：LDW 必须全局单例
并发多窗口实测 6 分钟封 1 天。单轮体量同理，继续用 DSH 自己的 compaction 压上下文
（现已修正 contextWindow，见上）。
设计取舍：为什么不用现成的传输层方案
早期实现走过「手工构造 HTTP 请求」的路线，后来全部推倒 —— 那条路是封号之源：
| 丢掉的东西 | 为什么 |
|---|
伪造的 x-deepseek-harness 头 | 最高风险单点，每个请求都发 |
| about:blank 代理 + 页面内 PoW | 需要 --headless=new --no-sandbox 等自动化 flag，指纹特征明显 |
手工拼 origin/referer/cookie | 在页面里会被浏览器静默丢弃，实际发出去的是 Origin: null + 无 Cookie |
| 传输层开关（HTTP / 浏览器二选一） | 真浏览器方案里不存在这个概念 |
换真浏览器也解决不了的：并发多窗口（实测双窗口 6 分钟封 1 天）与单轮体量。
LDW 必须全局单例，并继续用 DSH 自己的 compaction 压上下文。
致谢
本项目的设计思路受益于以下项目，在此致谢：
本项目为独立实现，全部代码自行编写，许可为 Apache-2.0（见 LICENSE），
与上述项目的许可不冲突。
许可
Apache-2.0（见 LICENSE）。
与 DSH 能力的适配
LDW 作为 DSH 的模型 adapter 接入，因此 DSH 的能力自动可用，无需本插件逐个实现：
- 工具调用：DSH 把当前会话可用的全部工具（内置工具、MCP 工具、Skill 提供的工具）
以统一 schema 传给 adapter；LDW 将其转换成工具目录发给网页模型，
模型输出的调用由 DSH 执行后回灌 —— 你装的 MCP 服务器、启用的 Skill
在 LDW 模型下同样能用
- 上下文管理：会话历史、压缩（compaction）由 DSH 管理，LDW 只做增量发送
- 斜杠命令：由 DSH 的命令系统处理，与模型无关，天然可用
- 多会话：每个 DSH 会话绑定独立的网页对话（见上文会话路由）
免责声明## 免责声明
本项目仅供个人学习与研究使用。使用者需自行承担以下风险：
- 用自动化方式驱动 AI 网页版可能违反服务条款，存在账号被限制的风险
- 本项目通过真实浏览器 + 真实用户操作降低风险（不发伪造请求头、不做 PoW 计算、
串行发送、差分发送控制体量），但无法保证不被风控识别
- 请勿用于商业用途、批量操作或任何违反服务条款的场景
使用即表示你已知悉并接受上述风险。
