手动指向 bili 代理时双重压缩:bcp 只认 BILLION_CONTEXT_PROXY 环境变量,不识别 baseUrl 的 /bili/ 模式

[ranxianglei]

背景

pi 用 ACP 有两条路:客户端扩展(billion-context-pi)和 wire 代理(billion-context)。两者同时激活会对同一份会话双重压缩——浪费 token、产生嵌套冗余摘要、ref 体系混乱。

现状:launcher 路径已闭环(已验证)

• bili pi 等所有 launcher 路径都向客户端注入 BILLION_CONTEXT_PROXY=origin(billion-context src/launcher.ts:333/337/466/2088/2124/2146)
• bcp 工厂首行检查该变量并整体让位(src/index.ts:49-52:log [bcp] disabled 后 return,不注册工具/transform)
• 即使 settings.json 里装着 bcp(overlay 保留 packages 条目、扩展会加载),加载即让位 ✅

缺口:手动配置路径

用户不起 launcher,而是:

1. 单独跑代理(bili start / bili-proxy)
2. 手动把 pi 的 models.json baseUrl 指到 http://127.0.0.1:PORT/bili/https://upstream...(或自己设 HTTPS_PROXY 但不导出 BILLION_CONTEXT_PROXY)

此时 BILLION_CONTEXT_PROXY 未设置 → bcp 全功能激活 + 代理照常压缩 → 双重压缩。

README 明确宣传 "Any agent that can set a base URL works out of the box",pi 属于此类,该组合是合理用法而非误用。

证据

• bcp 唯一的代理检测是 process.env.BILLION_CONTEXT_PROXY(src/index.ts:49),不检查 ctx.model.baseUrl
• 薄壳插件已有现成的 URL 模式检测可复用:billion-context src/agent/shared.ts:23 proxyBaseFromUrl —— http(s) URL、首段路径为 bili、余下部分匹配 /^\/https?:\/\//(避免普通 /foo/bili/ 路径误判)

建议修复

bcp 在首个带 model 上下文的事件(session_start / 首次 context transform)上惰性检测 ctx.model?.baseUrl:命中 /bili/<scheme>:// 模式则按与 env 相同的方式让位(log + return)。env 检查保留为主信号——MITM 透明模式(HTTPS_PROXY,URL 无 /bili/ 前缀)只能靠 env 识别(见 shared.ts:38 注释),文档应提示手动用 HTTPS_PROXY 的用户同时导出 BILLION_CONTEXT_PROXY。

影响面

中等:需要用户刻意手动接线(非文档主推的 bili pi 流程),但一旦发生每轮请求都被两侧各压一遍,长会话下 token 浪费和摘要嵌套会持续累积。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 审核完成,确认是真实 bug,开始实现。

审核三步结论

1. 复现/查证:已核实——bcp 唯一的代理检测就是 process.env.BILLION_CONTEXT_PROXY(src/index.ts:49-52);全 src grep 无第二处检测点,也从未检查 ctx.model.baseUrl。手动把 models.json baseUrl 指到 .../bili/<scheme>://... 时该 env 必然未设置 → bcp 全功能激活 + 代理照常压缩 = 双重压缩。bug 成立。
2. 层次判断:双重压缩是表面现象;根因是"代理检测信号只依赖 launcher 注入的 env",不覆盖手动接线路径。issue 给的方案直接打到了根因,不是治标。
3. 方案评估:采纳 issue 建议——在首个带 model 上下文的事件(session_start / 首次 context transform)惰性检测 ctx.model.baseUrl,命中 /bili/<scheme>:// 模式则按与 env 相同方式让位(log + 让位,不注册 transform、不取消宿主 compaction)。env 保留为主信号:MITM 透明模式(HTTPS_PROXY)URL 无 /bili/ 前缀,无法从 URL 识别,只能靠 env,文档会补提示。URL 判定逻辑将镜像 billion-context src/agent/shared.ts 的 proxyBaseFromUrl(首段路径为 bili + 余下匹配 /^\/https?:\/\//,避免普通 /foo/bili/ 误判)。

查重:已检索现有 issue/PR(双重压缩、baseUrl、BILLION_CONTEXT_PROXY、proxy disable 等关键词,含已关闭),无相似条目,非重复。

开始实现,测试通过后开 PR 并回帖链接。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

已完成修复,PR:#297

实现(与 issue 建议一致):

1. 新增 src/proxy-detect.ts — isBiliProxyBaseUrl(baseUrl) 镜像 billion-context proxyBaseFromUrl 的判定:http(s) scheme、首段路径为 bili、余下部分匹配 /^\/https?:\/\//(普通 /foo/bili/ 路径不误判);另含让位警告文案常量。
2. session_start 惰性检测 ctx.model.baseUrl(src/index.ts)— 命中即按 env 相同方式让位:进程内一次性警告(UI notify / headless stderr)、不取消宿主原生压缩、不注入 ACP prompt、context 原样透传。env 检查保留为主信号(在 OMP 检测之后执行)。
3. context 事件兜底检测点 — 防个别宿主 session_start 未先于首个 LLM 调用触发。
4. 工具拒绝文案区分原因 — 四个 ACP 工具改为返回 runtime.refusalMessage ?? OMP_UNSUPPORTED_MESSAGE:代理让位时模型看到的是"baseUrl 经 bili 代理、客户端压缩已禁用"而非误导性的 OMP 文案;OMP 路径行为不变。
5. 文档 — README(en/zh)Host support 节新增 wire 代理共存段落,明确提示:透明模式(HTTPS_PROXY MITM,URL 无 /bili/ 前缀)无法从 URL 识别,需手动导出 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 自包含。

Triage 结论:bug 属实(bcp 唯一代理检测确为 factory 首行的 env 检查,全 src 无 baseUrl 检查);根因层是 env-only 检测覆盖不了手动接线路径,修复直接补检测缺口并复用代理侧现成判定逻辑,非治标。与 issue 建议的唯一差异是第 4 点(工具文案按拒绝原因区分)。

PR 待 review,合并后随下个 release 生效。

[ranxianglei]

Review 完成:PR #297 方案与实现均通过(见 PR 评论)。分支已 rebase 到 v0.1.58(原 base 落后于 #310/#311/#315 导致 GitHub 未重算可合并性),冲突已解、本地测试全绿,CI 重跑中,通过后即可合并。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

收到,谢谢 review。已核实 rebase 后的分支状态:

• 分支 tip d1a0ced 直接落在 v0.1.58 release merge(55afd55)之上,commit message 与内容完整(11 文件、+272/−16 全部保留,冲突未丢改动)
• PR fix(proxy): stand down when model baseUrl routes through the bili wire proxy (closes #296) #297 当前 mergeable=true,head=d1a0ced,base=master

我这边无需再动。CI 通过后由你合并即可,随下个 release 生效;若 CI 有红需要我在分支上跟进,随时说。