探索如何发布为native模式

[ranxianglei]

探索如何发布为native模式,比如变成一个彻底的native插件,举例来说,
比如在pi,omp,dsh中,可以安装这个插件.然后动态起代理.使得用户无感

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 收到。这是探索类 feature request，按流程先给分析和推荐方案，你拍板方向后我再拆 issue 动手实现。

现状：一半已经存在

bili plugin install <agent>（src/plugin-install.ts）已能把 thin plugin 部署进各 host 的原生配置：pi → ~/.pi/agent/settings.json 的 packages、omp → ~/.omp/agent/config.yml 的 extensions、claude/codex/opencode → MCP server 注册。插件本身是纯协议客户端（无压缩逻辑），装好后在 pi/omp 里自动注册 4 个 ACP 工具并转发给代理。所以"安装为插件"对 pi/omp 今天就能做到——缺的是另外两半：代理得自己起来、流量得绕进代理。

三个 gap

1. 不能动态起代理。插件检测不到代理就自禁用（detectProxyBase 返回 undefined）；起代理目前只有两条路：bili start 手动跑，或 bili <client> launcher 代跑。且 MCP 系 agent（claude/codex/opencode）的 install 会在没有运行中代理时直接拒绝（proxy-origin 劫持链:launcher 临时代理无条件抢写全局指针、读侧零验活、plugin-install 把 ephemeral origin 冻结进持久配置(双实例计数分叉实锤) #403：不把死 origin 冻结进配置）——pi/omp 不受此限，它们的条目只指向绝对路径，origin 运行时再发现。
2. 流量路由依赖 launcher。当前流量进代理靠：MITM env（HTTPS_PROXY+CA，必须在客户端启动前设好）或 /bili/<上游URL> baseURL 前缀（必须写进客户端 provider 配置）。用户跑裸 pi/omp/dsh 时两条路都不生效。这是 native 模式的核心难点：如何让一个已经在运行的 agent 把自己的模型流量导向代理。
3. dsh 不在 PLUGIN_AGENTS。dsh 现在只有 launcher 注入（--patch overlay + DEEPSEEK_BASE_URL），bili plugin install dsh 不存在。

推荐方案：install-time rewire + 常驻 daemon

• 路由：安装期改写客户端 provider 配置。bili plugin install pi --rewire 读出当前 baseURL（client-config.ts 已有只读发现能力），把 http://127.0.0.1:8787/bili/<原baseURL> 写回配置（.bili-bak 备份）。/bili/ 零配置前缀就是为这个设计的——代理侧无需任何上游配置。装完裸 pi 即全量走代理，无运行时魔法，最稳。备选"extension hook 里运行时改 URL"依赖 host API 能力（omp 的 before_provider_request 返回值能否改目标 URL、pi 暴露哪些 hook，都还没验证过），即便可行也比静态配置脆。
• 动态起代理：插件侧 ensure-proxy。session_start / 首次请求时探默认端口 8787 健康检查；不在则 detached spawn bili start（launch token 握手 + instance file pid 存活校验，与 launcher 的 ensureProxyRunning 同一套机制；并发竞争由端口绑定 + EADDRINUSE 重试自然消解）。同时放开 proxy-origin 劫持链:launcher 临时代理无条件抢写全局指针、读侧零验活、plugin-install 把 ephemeral origin 冻结进持久配置(双实例计数分叉实锤) #403：rewire 后 origin 是固定 well-known 地址而非 live 实例快照，MCP 系的"没起代理也能装"随之成立。
• 生命周期：代理变常驻服务。现在代理生命周期绑 launcher（launcher 退出即 kill）；native 模式下没人管关停，需要常驻（内存占用小，且 3 分钟自更新机制下常驻反而利于 auto-update）+ 提供 bili stop。备选是空闲超时自退，但多 agent 场景下"最后一个退出才退"判断复杂，我不倾向。
• dsh：加进 PLUGIN_AGENTS，cordis 插件部署进 DSH_HOME + DEEPSEEK_BASE_URL 写进 settings.yaml（同一套 rewire 逻辑）。dsh 无客户端 conversation id，保持 wire mode（代理端压缩），可接受。
• 发布形态：维持单 npm 包，不按 agent 拆独立包——plugin 和 proxy 同包保证版本一致，避免"插件新、代理旧"的 kernel drift 问题。pi 的 packages 列表本身支持 npm:billion-context 条目，不想用 CLI 的用户可以纯 npm 装。

待你拍板

1. 代理生命周期：常驻 + bili stop（我的建议）还是空闲超时自退？
2. 默认共享端口 8787 可以吗？（多用户机器有碰撞可能，EADDRINUSE 回退已有）
3. 确认 install-time rewire 方向？（vs 运行时 URL rewrite，后者需先验证各 host API）
4. 首批范围：issue 里点名的 pi/omp/dsh，还是连 claude/codex/opencode 一起带？（它们的 MCP shell 已有 BILI_MCP_PROXY，改造成本低）

确认后我拆成具体 issue 开工。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 补充：几个关键点已验证完毕，结论如下——

1. 运行时改 URL 路线被排除（关键）
查了 pi 的扩展 API 源码（earendil-works/pi，packages/coding-agent/src/core/extensions/types.ts）：

• before_provider_request：事件只有 payload: unknown，返回值类型 BeforeProviderRequestEventResult = unknown——只能替换请求体，没有 URL 字段；
• before_provider_headers：in-place 改 headers，返回值被忽略。

omp 的 before_provider_request 同样只替换 payload（此前已对照 omp 17.3.8 dist 验证过）。所以 pi/omp 都无法在运行时 hook 里改写目标 URL。路由只能走安装期配置改写——问题 3 其实被 host 能力定了，没有第二条路。

2. 生命周期验证

• launcher 起的代理是 "OWNED" 语义：客户端退出即被 kill（src/launcher.ts:26）；
• 目前没有 bili stop 命令（现有命令仅 start/help/version/plugin-register/mcp/plugin/export/update/test/launch）。

即 native 模式需要新增：常驻 daemon 模式 + bili stop。

3. rewire 地基已就绪
src/client-config.ts 已有 pi/omp/dsh/codex/claude/opencode/hermes 的 baseURL 只读发现（readPiConfig/readOmpConfig/readDshConfig 等）。rewire 直接建在上面；缺的是写回器——JSON 简单，YAML/TOML 按 plugin-install.ts 处理 omp extensions: 块的同款模式做行级精确编辑 + .bili-bak 备份。

4. 新发现的问题：常驻 daemon 与 auto-update 冲突
现在的 auto-update（src/update.ts）检测到新版本后安装新代码，但需要 "Restart bili to finish"——launcher 模式下总有重启时机，常驻 daemon 没人重启它。需定方案：daemon 自更新后自动 spawn-new-kill-old 自重启（复用现有 launch token 握手），还是接受停留在旧版本直到手动重启。我倾向自重启。

issue 拆分（待你确认后开）

1. 代理 daemon 化：常驻模式 + bili stop + auto-update 后自重启
2. 插件侧 ensure-proxy：共享模块（探默认端口健康 → attach 或 detached spawn，launch token 握手，并发竞争由端口绑定自然消解），pi/omp/dsh 插件与 MCP shell 共用
3. bili plugin install <agent> --rewire：pi/omp 先行（配置改写 + remove 时还原），顺带放开 proxy-origin 劫持链:launcher 临时代理无条件抢写全局指针、读侧零验活、plugin-install 把 ephemeral origin 冻结进持久配置(双实例计数分叉实锤) #403（rewire 后 origin 是固定地址而非 live 实例快照，MCP 系也能没起代理就装）
4. dsh 进 PLUGIN_AGENTS：cordis 插件部署进 DSH_HOME + settings.yaml rewire

等你拍板：常驻 vs 空闲超时（我倾向常驻）、默认端口 8787、首批是否带 claude/codex/opencode。拍完我立刻拆 issue 开工。

[ranxianglei]

确认没有任何办法 在启动的时候，插件触发，然后插件自动起代理吗

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 有办法——插件在启动时自动起代理完全可行，这正是我方案里的第 2 条。我上一条说"被排除"的是另一件事：hook 里运行时改请求 URL。这两件事互相独立，拆开看：

能力	可行性
插件触发 → 自动起代理	✅ 完全可行，机制现成
插件触发 → 把流量绕进代理（改 URL）	❌ pi/omp 的 hook 只给 payload/headers，没有 URL 字段

自动起代理怎么落地（pi/omp/dsh 插件都跑在宿主 Node 进程里，直接可用）：

agent 启动 → 扩展加载 (session_start)
  → 插件: GET http://127.0.0.1:8787/__bili/health
     ├─ 活着 → attach（注册工具、盖 headers）
     └─ 不在 → spawn detached: node <包根>/dist/index.js start --port 8787
                → 轮询 instance file（launch token 握手）直到健康
                → attach
之后的每个模型请求前 → ensureProxy() 幂等复查（daemon 中途死了会自动重拉，自愈）

关键点：

• CLI 入口定位零成本：插件文件就在 <billion-context安装根>/dist/agent/pi.js，往上两级就是包根，process.execPath 拼出入口即可。全局 npm 装和 pi 的 npm:billion-context 条目两种方式都成立。
• 并发竞争天然消解：两个 agent 同时启动、都想起代理——端口绑定定胜负，输的那个 EADDRINUSE 重试后落到赢家起的实例上（launcher 端口 TOCTOU(探测-释放-重bind 无重试):可静默挂上陌生 bili 或 20s 挂死;且被启动代理强制 --debug 制造 12MB/天日志 #407 已有这套 retry-bind + instance file 报告真实 origin 的机制，launcher 的 ensureProxyRunning 几乎可以原样搬进插件）。
• 一个需要留意的耦合：如果配合安装期 rewire（baseURL 指向 127.0.0.1:8787），代理挂了 agent 就发不出请求了。缓解就是上面那个"每个请求前 ensureProxy"：daemon 死了下次请求会先把它拉起来再继续，代价是一次约 1 秒的重启等待。不 rewire 的话代理挂了只是没压缩、不影响使用——所以 rewire 和 ensure-proxy 要配套做。

所以结论："安装插件 → 启动时自动起代理 → 用户无感"这条路是通的，缺的只是把 launcher 里已有的 ensureProxyRunning 机制搬一份到插件侧 + 常驻化生命周期。路由那一半才需要安装期改配置这个动作（一次性、带备份、可还原）。

方向没问题的话我就按之前拆的 4 个 issue 开工了；还差你确认：常驻 vs 空闲超时、端口 8787、首批范围。

[ranxianglei]

安装插件 → 启动时自动起代理 → 用户无感
所以是启动的时候，加载插件，然后插件是不是直接找bili命令起服务即可？然后返回端口？
先讨论清楚

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 好，把机制讨论清楚。你的两个猜测各对一半，逐条说：

1. "直接找 bili 命令"——不靠 PATH，靠插件文件自己的位置

PATH 查找不可靠：用户可能没全局装（比如 pi 用 npm:billion-context 条目装的，node_modules 里根本没有全局 bin），agent 进程的 PATH 也未必含 npm 全局 bin 目录。

但不需要找：插件文件本身就住在 <billion-context安装根>/dist/agent/pi.js，往上两级就是包根，CLI 入口固定是 <包根>/dist/index.js（已确认 package.json bin.bili = ./dist/index.js）。spawn 命令就是：

process.execPath + [<包根>/dist/index.js, "start", "--port", "8787"]
detached + unref，stdio 进日志文件

process.execPath 是宿主 agent 正在用的 Node 二进制，连 Node 都不用找。兜底顺序：包根解析 → PATH 找 bili → 都失败报明确错误。

2. "返回端口"——不用返回，端口预先固定，instance file 负责报实

这是 native 模式的关键设计决策：代理必须绑稳定端口（默认 8787，可配）。原因：launcher 模式下端口可以动态（launcher 当场知道端口、当场注入 env）；native 模式下客户端 baseURL 在安装时就改写成了 http://127.0.0.1:8787/bili/<上游>——地址固化在用户配置文件里。若用临时端口，每次启动都得回头改用户配置，比不做强。

"实际落在哪个 origin"的确认复用现有 #407 机制（已核对 server.ts:424-438）：

• 插件 spawn 前生成 launchToken（uuid），经 env 传给子进程；
• 子进程绑定成功后把 {origin, pid, launchToken} 写进 instance file（原子写）；
• 插件轮询 instance file 直到看到自己的 token + 健康检查通过，从里面读出真实 origin。即使子进程因端口占用换到别的端口，报的也是真实地址。

3. 需要新增的一条规则：并发去重（这是本次讨论发现的唯一新点）

已核对现状：EADDRINUSE 且有 launchToken 时，子进程会换端口再试、把第二个代理也起来（server.ts:430）。launcher 模式下这正确（每个 launcher 要独立实例）；native 模式下两个 agent 同时启动就会起两个常驻 daemon——输的那个成孤儿，没人路由流量过去，白耗内存还各自跑 auto-update。

所以加一条：首选端口被占时，先探占用者——是健康 bili（health 端点 + instanceId 匹配）就干净退出。发起方插件发现自己的 token 一直没出现，就重新探 8787，看到别人的活实例照常 attach。占用者不是 bili 则明确报错（改写后的配置指向 8787，被别的东西占了本来就是坏的）。

端到端时序

pi 启动 → 扩展加载 (session_start)
  ensureProxy():
    GET 127.0.0.1:8787/__bili/health
    ├─ 健康 bili → attach（origin 记下）
    └─ 不在 → token=uuid
              spawn detached: node <包根>/dist/index.js start --port 8787
                env BILI_LAUNCH_TOKEN=<token>
              轮询 instance file 直到 token 匹配 + 健康
              ├─ 出现 → attach（origin 取自 instance file）
              └─ 超时 → 重探 8787（可能别的 agent 先起了）→ attach 或报错
每个模型请求前 → ensureProxy() 幂等复查（daemon 中途死了自动重拉，自愈）

结论：不需要任何新协议——launch token 握手、instance file、health 端点全是现成的。新代码只有两块：(a) 插件侧 ensure-proxy 共享模块；(b) 子进程侧"占位者是健康 bili 则退出"的去重规则。

这样机制上清楚了吗？清楚的话剩三个拍板项：常驻 vs 空闲超时、默认 8787、首批范围（pi/omp/dsh 还是带上 claude/codex/opencode）。

[ranxianglei]

这是 native 模式的关键设计决策：代理必须绑稳定端口（默认 8787，可配）
这个端口需要动态分配而不是静态。每个会话一个端口。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 同意，而且每会话一个动态端口比我原来的静态 8787 方案更好——它顺手消掉了我列的三个难题：

• 不需要空闲超时/常驻决策：代理随会话生、随会话死（插件在 session_shutdown/进程退出时 kill 自己的 child）；
• 不需要并发去重规则：各进程各起各的，天然隔离；
• 不需要担心 8787 被占、多用户碰撞。

代理侧零改动——launch token 握手 + instance file 报真实 origin + EADDRINUSE 重试就是为动态端口造的（launcher 今天就这么跑）。**唯一的真问题是路由：正在运行的客户端怎么知道本会话的端口。**官方 hook 已验证没有 URL 字段（pi 的 before_provider_request 只给 payload，before_provider_headers 只给 headers）。但有一条更彻底的路，比安装期改配置还干净：

进程内出口拦截（推荐）

插件和宿主 agent 跑在同一个 Node 进程里。插件加载时包一层 globalThis.fetch：请求的目标 origin 命中"当前模型的上游 origin"（从 ctx.model.baseUrl 拿，精确匹配，不是泛泛的域名列表）→ 改写成 http://127.0.0.1:<本会话端口>/bili/<原URL>；其余一切流量（MCP、web 工具、npm、git……）原样放行。

关键点：

• JS 标识符是调用时才解析到全局对象的——pi 的 openai-completions 客户端构造里传的就是裸 fetch（模块作用域无局部遮蔽），所以扩展加载后打补丁对之后的所有请求生效；
• 完全不改用户配置。安装 = 往宿主配置加一行插件条目，仅此而已。比 rewire 方案少掉一整块写回器/备份/还原代码，才是真正的"用户无感"；
• 并发会话零串扰：每个进程有自己的代理、自己的端口、自己的包装器；
• 代理中途挂了：包装器里触发重拉或该次直连降级（不破坏请求）；
• 插件自己对代理的 manifest/tool/status 调用走 127.0.0.1 且带 /bili/ 前缀识别，天然排除在改写之外，不会自我缠绕。

诚实的风险声明

1. 这是对宿主进程的网络栈做 monkey-patch，正确性依赖宿主及其上游 SDK 在调用时查全局 fetch——必须按宿主逐个用真实 e2e 验证（先 pi，我们有现成的 e2e 测试模式）。某个代码路径若绕过了全局 fetch（比如直接持有引用），后果只是那部分流量不走压缩、直连上游，不会坏——优雅降级是设计出来的，不是碰运气。
2. WebSocket 类连接（如 codex-responses 的 ws 路径）不过 fetch，暂时不覆盖，列为已知限制。
3. omp/dsh 同为 Node 系、同族插件机制，预期同样成立，落地前各自验证一遍。

更新后的端到端时序

pi 启动 → 扩展加载
  ensureProxy():
    分配空闲端口 N（bind-0 试探）
    spawn detached: node <包根>/dist/index.js start --port N
      env BILI_LAUNCH_TOKEN=<token>
    轮询 instance file 直到 token 匹配 + 健康 → 得到真实 origin
  安装 fetch 包装器：upstream origin → http://127.0.0.1:N/bili/<原URL>
  注册 4 个 ACP 工具、盖 x-bili-plugin* headers（现有逻辑不动）
会话运行中 → 每次请求经包装器进本会话专属代理
session_shutdown(quit)/进程退出 → kill child，端口释放

这个方向把"安装期 rewire"整个替换掉了（不再需要），issue 拆分相应变为：①插件侧 ensure-proxy + 动态端口；②fetch 拦截层（逐宿主 e2e 验证）；③会话结束时回收 child；④dsh 进 PLUGIN_AGENTS。claude/codex/opencode 走 MCP shell 的不用动（它们本来就是 wire mode + 独立注入）。

你确认这个"进程内出口拦截 + 每会话动态端口"的方向，我就拆 issue 开工，第一步先拿 pi 做 e2e 验证拦截层的可行性。

[ranxianglei]

大体没问题，不过实际上为啥不复用bili启动器呢？他这个流程都做出来了 只差触发

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 对，应该复用——我上一条方案里插件侧重新写一遍"分配端口→spawn→轮询握手"其实是在分叉 launcher 已经验证过的流程，没必要。理清一下哪些能直接吃、哪些吃不了：

能复用的（launcher 已做完的 90%）：ensureProxyRunning 整套——probe/spawn/launch token 握手/EADDRINUSE 重试/instance file 报真实 origin，外加一个白捡的：child 本来就在监视 BILI_PARENT_PID（#414 的优雅退出机制）——插件把宿主 agent 的 pid 传进去，agent 进程一退出代理自动收尾，会话回收这块代码都省了。

做法：加一个薄子命令（比如 bili daemon --fresh --json），内部就是调现有 ensureProxyRunning，起完把 {origin, port, pid, logPath} 打 JSON 到 stdout 然后退出。插件侧只剩 ~50 行胶水：解析包根路径 → spawn 这个子命令 → 读 JSON → 装拦截器。生命周期逻辑永远只有一份，在 launcher 这边。

吃不了的（本质不匹配）：launcher 的流量接线是spawn-time 的——env（MITM/DEEPSEEK_BASE_URL）、overlay home、-e 注入插件、最后拉起客户端二进制，全都是在配置"将要出生的子进程"。native 模式下进程已经活着了，env 和 home 改不动，客户端也不会被第二次拉起。所以运行时接线只能靠 fetch 拦截，这块是纯新增，绕不开；但它是整个方案里唯一的新机制，其余全是组装。

两个小改动（复用时发现的真问题）：

1. --fresh 语义：launcher 默认"健康且兼容就 attach"，native 模式要每会话独立实例，得跳过 attach 强制新起；
2. instance file 是全局单文件（~/.local/state/billion-context/proxy-origin），两个会话并发 spawn 会互相覆盖、输家的轮询拿不到自己的 token。改成 per-session 结果文件：父进程建临时路径经 env 传给 child，child 绑定成功后写进去，父进程只轮询自己的文件。全局文件保留给 MCP shell/install 用（last-writer 可接受）。

最终形态收敛为：

• bili daemon --fresh --json（薄封装，复用 ensureProxyRunning）
• 插件侧：fetch 拦截层（核心新增，先 pi e2e 验证）+ 胶水（spawn daemon 子命令、装拦截器、注册工具/headers 走现有逻辑）
• dsh 进 PLUGIN_AGENTS

这个形态你点头我就拆 issue 开工，第一步仍是 pi 的拦截层 e2e 验证。

[ranxianglei]

好 没问题了开工

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 收到，开工。执行计划：

先拆 4 个子 issue（挂在 #513 下）：

• A: bili daemon 子命令——每会话动态端口起代理，JSON 契约，per-session 结果文件，BILI_PARENT_PID 自动回收
• B: pi native 模式——fetch 拦截层 + 插件胶水（marker 门控，默认行为不变），第一步先做真实 pi 的 e2e 可行性验证（这是全设计里唯一没验证过的承重假设）
• C: omp native 模式（同套拦截层 + omp 集成）
• D: dsh 进 PLUGIN_AGENTS（cordis 插件部署 + 拦截层）

节奏：A+B 一个 PR（Phase 1），C、D 各自跟进。拦截层如果 pi 上 e2e 不过，我会立刻在 #513 这里报告并带替代方案回来，不会硬推。

开始。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 native 模式已实现并实测通过，两个 PR：

PR #524（#519，本 issue 核心） — pi 的彻底 native 插件，基于 #523 的分支：

• 用法：bili plugin install pi --native，之后用户直接跑裸 pi —— 无 launcher、无 env、无感
• 机制：插件加载后看到 marker 文件（~/.local/state/billion-context/native.json）→ 从插件文件位置自定位包根 → spawn node <root>/dist/index.js daemon --parent-pid <pi-pid>（动态端口）→ 在 pi 进程内包一层 globalThis.fetch，只把目标 origin 与当前 model upstream 精确匹配的 http(s) 请求改写成 <proxy>/bili/<原始URL>，其余流量原样直通；响应流原样返回（SSE 安全）
• 生命周期：pi 退出 → daemon 经 parent-pid watch（Windows 上 launcher 子代理从无优雅退出:stopProxy 直接 TerminateProcess,SIGBREAK-flush 全史 0 次触发,防抖窗状态+进行中轮被拦腰 #414）自杀；session_shutdown 也会主动卸载拦截器 + SIGTERM
• 安全边界：无 marker = 行为与原来逐字节一致（launcher 用户不会被惊动）；检测到 launcher 代理时 launcher 优先；spawn 失败 = 警告 + 自禁用，绝不弄坏客户端

PR #523（#518） — bili daemon 子命令（并行会话先行完成）：每会话全新实例、动态端口、per-session 握手文件、单行 JSON 契约。#524 直接构建在它之上，未重复任何代理侧代码。

真实 pi e2e 验证（pi 0.83.6 + mock OpenAI upstream，隔离 HOME）：round-1 请求直连（daemon 启动约 1s，README 已文档化的已知行为——agent 重发全量历史，一轮内自愈）；SDK 重试请求被拦截并经代理转发（forward POST → …/v1/chat/completions），SSE PONG 正常流回；pi exit 0；daemon 在 pi 退出后 ≤3s 自动消失。typecheck/build 干净；测试套件 971 中 969 过、1 skip、1 fail 为预存在的环境依赖用例（pristine master 同样失败）。

设计要点回顾（为什么是这个形状）：pi 官方扩展钩子只能替换请求体不能改 URL（before_provider_request 返回值 = payload only，before_provider_headers 返回值被忽略——已在 earendil-works/pi 源码核实），所以运行时出口拦截是唯一能让"已经在跑"的进程走"会话期才启动"的代理的路径。

遗留后续（不在这两个 PR 内）：

• feat: omp native 模式——fetch 拦截层 + omp 集成（native 模式 C） #520 omp native（需单独验证 omp 的 fetch 路径）
• feat: dsh 进 PLUGIN_AGENTS——native 插件部署 + 拦截层（native 模式 D） #521 dsh 进 PLUGIN_AGENTS
• pi-native 路径的 gated e2e 测试（目前为手工脚本验证）

请先看 #523，再合 #524（base 是 #523 分支）。