feat: dsh 进 PLUGIN_AGENTS——native 插件部署 + 拦截层（native 模式 D）

[ranxianglei]

来源: #513 分析 native 模式时拆出的子任务（owner 已确认方案）。

• bili plugin install dsh：把 cordis 插件（dsh-acp）部署进真实 DSH_HOME（~/.dsh），替代目前仅 launcher --patch overlay 注入的路径；remove/status 同步支持
• fetch 拦截层集成进 dsh-acp（dsh 的 DEEPSEEK_BASE_URL 解析顺序为 settings baseURL ?? env；拦截按活动上游 origin 改写）
• dsh 无客户端 conversation id，保持 wire mode（代理端压缩），/acp 命令走 fetchStatusLatest 不变
• e2e 真实 dsh 实测

[ranxianglei]

🤖 ework agent · qwen3.8-27b

收到。查重：全库 issue/PR（含已关闭）检索无重复项——唯一相关项是母 issue #513（本条即其拆出的任务 D）。方案你已拍板，直接进实现。

先报一个依赖发现：#513 定的节奏是"A+B 一个 PR（Phase 1），C、D 各自跟进"，但当前 master（v0.1.83）里 A（bili daemon 子命令）和 B（fetch 拦截层）均未合入，也没有对应 open PR。D 离不开拦截层和每会话起代理机制，所以本 PR 会把 D 必需的共享前置一并带上——结构成共享模块，后续 B/C 直接复用，不分叉实现。

实现清单：

1. 共享 fetch 拦截层（新模块）：包一层 globalThis.fetch，目标 origin 命中当前活动上游 origin 的请求改写到 <代理origin>/bili/<原URL>，其余流量原样放行；代理不可达时该次请求降级直连（不破坏请求）；插件自身的管理面调用天然排除
2. 每会话起代理：bili daemon --fresh --json 薄子命令（复用 launcher 的 ensureProxyRunning 握手机制：launch token + 绑定后报告真实 origin）+ per-session 结果文件（父建临时路径经 env 传子，child 绑定成功写入，父只轮询自己的文件）+ BILI_PARENT_PID 自动回收
3. bili plugin install dsh：cordis 插件（dsh-acp）部署进真实 DSH_HOME（~/.dsh）。已对真实 dsh 0.1.1-rc.2 验证：profile 树组成顺序为 bundles → cordis.patch.yml（用户层）→ --patch overlay，用户层就是原生入口点；remove/status 同步支持，.bili-bak 备份 + 幂等，与 pi/omp 同款纪律
4. 拦截层集成进 dsh-acp：加载时解析活动上游 origin（settings baseURL ?? DEEPSEEK_BASE_URL env，与 dsh 自身解析链一致），起/接每会话代理，装拦截器；/acp 不变，仍走 fetchStatusLatest
5. wire mode 不变：dsh 无客户端 conversation id，代理端压缩；插件不注册 ACP 工具、不盖 x-bili-plugin 头
6. launcher 兼容：bili dsh 检测到原生安装时跳过 --patch overlay 注入（避免同一插件双重注册）
7. e2e 真实 dsh 实测：headless one-shot profile + 真实上游，验证裸 dsh → 插件自起代理 → 流量走 /bili/ → 压缩生效 → /acp 可读全链路

诚实声明：拦截层的承重假设是"dsh 的 fetch 栈在调用时才解析全局 fetch"——若实测不过，我立刻报告并带替代方案回来，不会硬推。开工。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 done → PR #525: #525

审核结论（动手前验证了什么）

• 重复判定:全仓 issue/PR(含已关闭)检索无重复;仅父任务 探索如何发布为native模式 #513 相关。
• 层次判断:issue 给的方案打到核心——dsh 的 pi-ai 走裸 fetch()(已对装好的 dsh 源码逐处确认,无捕获引用),所以包 globalThis.fetch 是唯一真正新机制,MITM/CA 路线确实不可行(pi-ai 无任何代理旋钮)。settings baseURL ?? env 链与 deepseek-official 路由源码一致(config.baseURL ?? $DEEPSEEK_BASE_URL),实现里补了 llm-deepseek.baseURL 中间档,两种路由风格都覆盖。
• 前置缺口:A/B 尚未落地(master 与开放 PR 均无),本 PR 按 探索如何发布为native模式 #513 既定节奏携带 D + B/C 要复用的共享件(daemon 子命令、intercept 模块),不越界做 B/C。

交付内容

1. bili plugin install/remove/status dsh:对 $DSH_HOME/profiles/* 每个 profile 的 cordis.patch.yml 合并 - insert: 条目(幂等、stale 条目清理、.bili-bak 备份);launcher 检测到 live native 条目时跳过旧 --patch overlay(防同模块双注册)。
2. bili daemon --fresh --json --parent-pid N:每会话动态端口(port 0)+ 会话级 instance file 握手,不写全局 instance/registry(无单实例守卫:多个 bili 代理进程并存共写 sessions 目录,伴随孤儿 ref、有注册表无 transcript、计数自相矛盾的污染簇 #394),auto-update 关,parent-gone ≤2s 回收。顺带修了 config 校验拒绝 port 0 的 bug(server.ts 本就预期 port 0,只有校验器挡着)。
3. fetch 拦截层(src/agent/intercept.ts,B/C 可复用):只改写 origin == 活动上游的请求 → /bili/<url>;网络失败降级直连一次;目标解析走异步 gate——e2e 抓到并修掉一个首请求竞态(异步 bootstrap 没完成前第一个 LLM fetch 直接走了上游,有回归测试)。
4. wire mode 不变:无 ACP tools、无 conversation id,/acp 仍走 fetchStatusLatest(现在多报一行路由头)。bili dsh attach 模式下 wrap 后的 URL == proxy origin → 拦截层自动 passthrough,零双重代理。

Pre-flight & e2e

• typecheck clean;1052 tests / 1051 pass,唯一失败是 pre-existing 环境相关用例(沙箱里有本地 codex 二进制导致 resolve 断言不同,CI runner 上通过,与本改动无关);build OK,tsup entries 不变。
• 真实 dsh 实测(bare dsh --profile headless,无 --patch):冒烟往返 exit 0;mock upstream 证明改写生效(mock 只见未 wrap 的 /v1/chat/completions,非 SSE mock body 时 dsh 直接渲染出 proxy 自己的错误串——proxy 确实在路径上);32K route cap + ~35.6K token prompt 下压缩管线真实介入(preflight 运行并按正确裁决 fail-fast——单条消息无可折叠历史;完整多轮压缩周期由单测 + e2e-codex 覆盖,headless 一次性调用产生不了多轮历史,见 devlog WORKLOG)。每次运行 parent-gone 回收验证通过;真实 DSH_HOME 的 install/remove 往返实测后已还原。

minor(仅报告,不开 issue)

• 本测试沙箱里 dsh 的 sessions 目录属主为 root,bare dsh 直接崩(EACCES)——与 bili 无关,e2e 用了隔离 DSH_HOME 副本,机制等价。
• headless dsh 的 task 只能走 argv,沙箱 ARGV 上限(~128KB)限制了单次 prompt 规模。