fix(proxy): stand down when model baseUrl routes through the bili wire proxy (closes #296)

[ranxianglei]

问题（#296）

bcp 此前只认 launcher 注入的 BILLION_CONTEXT_PROXY 环境变量。用户单独跑代理（bili start）并手动把 pi 的 models.json baseUrl 指到 http://127.0.0.1:PORT/bili/https://upstream…（或只设 HTTPS_PROXY）时 env 未设 → bcp 全功能激活 + 代理照常压缩 → 每轮请求双重压缩（token 浪费、嵌套摘要、ref 体系混乱）。

修复

• 新增 src/proxy-detect.ts：
  • isBiliProxyBaseUrl(baseUrl) —— 镜像 billion-context proxyBaseFromUrl 的判定（http(s) scheme、首段路径为 bili、余下部分匹配 /^\/https?:\/\//，避免普通 /foo/bili/ 路径误判）
  • PROXY_STAND_DOWN_MESSAGE —— 让位警告文案（说明原因 + 透明模式指引）
• session_start 惰性检测 ctx.model.baseUrl（src/index.ts），命中即按 env 相同方式让位：进程内一次性警告（UI notify / headless stderr）、不取消宿主原生压缩、不注入 ACP prompt、context 原样透传
• context 事件作为兜底检测点 —— 防 session_start 未先于首个 LLM 调用触发的宿主
• env 检查保留为主信号 —— MITM 透明模式 URL 无 /bili/ 前缀，只能靠 env 识别
• 工具拒绝文案区分原因：runtime.refusalMessage ?? OMP_UNSUPPORTED_MESSAGE（四个 ACP 工具返回让位原因而非 OMP 文案；OMP 行为不变）
• README（en/zh）Host support 节新增 wire 代理共存段落 + HTTPS_PROXY 用户导出 BILLION_CONTEXT_PROXY=1 指引；CHANGELOG 条目

测试

• tests/proxy-standdown.test.ts：URL 矩阵 14 例（命中 / 非命中 / 防误判）+ 集成 6 例（stand-down 全套行为、warn-once、headless stderr、直连 endpoint 保持激活、context 兜底）
• 全量：typecheck clean；485 tests / 482 pass / 0 fail / 3 skip；tsup build 自包含（acp-kernel inline）

Triage 结论

• 复现查证：bcp 唯一的代理检测确实是 process.env.BILLION_CONTEXT_PROXY（factory 首行），全 src 无任何 baseUrl 检查 —— bug 属实
• 层次判断：根因是 env-only 检测覆盖不了手动接线路径；修复直接补检测缺口（复用代理侧现成判定逻辑），非治标
• 方案：与 issue 建议一致；唯一差异是工具拒绝文案改为按拒绝原因区分（原 OMP 文案在该路径下有误导）

[github-actions]

📦 Built Extension Artifact

Branch: 2026-09-05_issue296-bili-proxy-baseurl (d1a0ced)

Option A — Install from npm PR tag (recommended)

pi install npm:billion-context-pi@pr-297

Each push to this PR publishes a new version under the pr-297 npm tag.

Option B — Download artifact

1. Download the artifact from the Actions run
2. Extract the tarball and install:

tar xzf billion-context-pi-pr297.tgz
pi install ./package

---

This comment is automatically updated on each push.

[ranxianglei]

🤖 ework agent · qwen3.8-27b

PR review 完成 —— 本地独立验证通过,LGTM。

验证结果(checkout b1ce78d 实测,非仅读 diff):

1. Bug 复现查证:master 上 bcp 唯一代理检测确为 factory 首行 process.env.BILLION_CONTEXT_PROXY(src/index.ts:49),全 src grep 无任何 baseUrl 检查 → 手动接线双重压缩路径成立。
2. 检测逻辑核对:src/proxy-detect.ts 的 isBiliProxyBaseUrl 与 billion-context src/agent/shared.ts:23 proxyBaseFromUrl 逐行一致(http(s) scheme、首段路径 bili、余下匹配 /^\/https?:\/\//),普通 /foo/bili/、大写 /BILI/、ftp:// 均不误判;MITM 透明模式(HTTPS_PROXY)保留 env 识别并文档提示导出 BILLION_CONTEXT_PROXY=1 —— 层次正确,非治标。
3. 本地全量 CI:typecheck clean;485 tests / 482 pass / 0 fail / 3 skip(与 PR 描述完全一致);tsup build dist 544KB 自包含(acp-kernel inline、无外部 require)。
4. 可合并性:git merge-tree 对最新 master(bcd841e,已含 v0.1.56 release + fix(delegate): gate ACP_DELEGATE prompt on resolveDelegate().enabled #276 delegate fix)测试合并 → 零冲突。GitHub 显示 behind 只是 base 滞后,无需 rebase。
5. 查重:检索现有 issue/PR(双重压缩 / baseUrl / BILLION_CONTEXT_PROXY / proxy 关键词,含已关闭)无重复条目;本 PR 精确对应 手动指向 bili 代理时双重压缩:bcp 只认 BILLION_CONTEXT_PROXY 环境变量,不识别 baseUrl 的 /bili/ 模式 #296,非重复实现。
6. 规范符合性:内容提交未动 version/acp-kernel pin(符合 release-branch-only 约定);测试文件名匹配 tests/*.test.ts glob;hermetic(禁 auto-update + stub npm,镜像 omp-refuse.test.ts)。

一个次要观察(非阻塞):OMP 宿主若同时把 baseUrl 指向 bili 代理,session_start 里 OMP 检测先置 refused,standDownIfProxied 随后会把 refusalMessage 覆盖为代理让位文案(四个工具届时显示代理原因而非 OMP 原因)。两者语义都是"ACP 已禁用",代理文案在该场景同样准确,可不改;若想严格区分,可在 refusalMessage 已非 null 时跳过覆盖。

其余均无问题:warn-once 为进程级(与 OMP 模式一致)、直连 endpoint 保持激活、context 事件兜底防宿主 session_start 缺失、工具文案按拒绝原因区分、README(en/zh)+ CHANGELOG 齐备。

结论:实现与 #296 triage 方案一致,单测 + 集成覆盖到位,本地验证全部通过。等待 @ranxianglei 合并(按仓库规范,merge 由人工执行)。

[ranxianglei]

Review 结论:✅ 通过

• isBiliProxyBaseUrl 忠实镜像 billion-context proxyBaseFromUrl 的判定(首段路径 bili + 余部 /^\/^https?:\/\//,/foo/bili/ 不误判),new URL 解析 + try/catch 兜底干净
• 让位语义与 env 路径完全一致(session_start 检测 + context 兜底防事件顺序缺失、warn-once、不取消宿主 compaction、工具返回让位原因而非误导性 OMP 文案)
• 测试覆盖充分(URL 矩阵 14 + 集成 6)

已将分支 rebase 到 v0.1.58 master(原分支落后于 #310/#311/#315,mergeable 为 UNKNOWN):解了 src/index.ts 两处冲突(保留 master 新增的 wireDelegateReadTracking 并让 standDownIfProxied 继续穿参)+ CHANGELOG 前插。本地 25/25 测试通过,push 后 CI 重跑中。

一个不阻塞的已知限制:mid-session 切换模型后 refused 粘滞(与 OMP 路径同语义),如需可后续跟进。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

Rebase 后已在本地重新验证新 head d1a0ced,全部通过:

• 基线确认:单 commit 直接落在 55afd55(v0.1.58 release merge,当前 master HEAD)之上,无冲突、mergeable
• 冲突解法核对:src/index.ts 保留了 master 的 wireDelegateReadTracking(pi)(位于 wireCompactionDisable 与 wireSessionLifecycle 之间),standDownIfProxied 继续穿参给 session_start + context 两处 —— 与你描述一致,PR 内容本身相对上一版零变化
• 本地 CI:typecheck clean;612 tests / 609 pass / 0 fail / 3 skip(master 随 v0.1.57/v0.1.58 套件从 485 涨到 612,全绿);tsup build dist 720KB 自包含(acp-kernel 0.0.55 inline,无外部 require)

mid-session 切模型后 refused 粘滞的限制知悉 —— 与 OMP 路径同语义、且该场景需要用户手动改配置,可接受;如后续要修(例如按 model identity 重置 refusal),另开 issue 跟踪即可。

CI 绿后即可合并。