More support for opencode adaptation.Especially for opencode-v2 adaptation.

[ranxianglei]

More support for opencode adaptation. Especially for opencode-v2 adaptation.

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

查重:不重复——open/closed 里没有覆盖这个「opencode(尤其 V2)支持」总需求的条目。相关但机制独立的条目:#3352(closed,V1/V2 增量轮次零节省)、#2656(open,V2 条件工具永不注册)、#2445(open,陈旧 PR)等;更早的 #1958/#1569/#1373/#1699/#1362/#920 等都已关闭且功能在 master 上。本条作为总需求独立处理,下面逐项给出差距清单。

现状(master @ v0.1.198,逐文件读过源码核对)

一个插件同时服务两代宿主:bili opencode launcher 与原生安装(billion-context-opencode)对 V1 走 config hook + 全局 fetch patch + zod 工具注册,对 V2 走 setup() 路由(model.request / http.request hook、ctx.tool、ctx.command.transform)。V2 侧压缩核心能力已齐:请求头 stamping(conversation/persona/window/model/max-output)、5 个核心工具(compress/decompress/search_context/acp_status/absorb)同步注册、派生会话继承(#1362)、fork 子收养(#2399)、Responses-over-WS 拦截(#2359/#2491)、compaction 边界上报、/acp 与 /acp-cache 命令、kill switch。两代都有 e2e 套件(Responses WS 套件需真实 opencode-v2 二进制,gate ACP_TEST_E2E_OC_WS=1)。

差距清单(按优先级)

#	差距	状态	建议处置
G1	增量轮次没真正上线:基础设施 + V2 发送路径都在,但让它真正省流量的实现(PR #3481,pull-receipt + V1 接线)合并时进了 #3340 的分支,该分支另行并入 master 后代码不在 master 上。后果:V2 每轮发 marker 却收不到 ack,每轮全量重发 = 零节省(正是 #3352 的症状);V1 连发送路径都没有	#3352 已关、#3481 已关,无人察觉	无决策依赖(设计在 #3352 已批准、实现已存在):把 commit 4f01bd1 重放到当前 master,定向测试后提 PR。我现在就开始做。
G2	V2 条件工具(acp_retrieve / acp_rule / read_original_image)永不注册:manifest 端点提供嵌套 OpenAI 工具对象 {type,function:{name,...}},客户端 fetchManifest 却按扁平字段解析 → 恒抛错且 catch 是静默的	#2656 open,#2659 已挂 7 天无人审	review/rebase 后落地 #2659,不开并行工作
G3	/acp-rule 命令两个 opencode lane 都缺(pi/omp 已原生注册)	无人报过	小 parity 修,可与 G5 同 PR
G4	opencode 没有内建「子代理委派」面:pi 有 acp_delegate / acp_delegate_wait / acp_delegate_cancel(仓库内 pi-subagents/ 组件),opencode 的子代理只拿到 per-persona 会话 + 血缘继承,没有委派工具	设计缺口	真设计取舍,等你拍板再动手
G5	V2 的 /acp 输出缺 V1 会附带的 stale notice	体验瑕疵	顺手修

结构化八问

1. 是什么问题:opencode(尤其 V2)与其他 lane(pi/omp/dsh)的能力差距盘点,外加一个已完成功能因合并事故未上线的隐藏缺陷(G1)。
2. 什么原因导致的:G1 根因是流程事故——Incremental turns: pull receipt for hosts without a response seam + opencode v1 wired (#3352) #3481 被合进另一个 PR 的分支而非 master,该分支随后单独并入,内容被留在 master 之外(已用 git 祖先关系核实);G2 根因是 manifest 端点与客户端解析器的工具形状不一致(嵌套 vs 扁平);G3/G5 是表面缺失;G4 是能力设计空白。
3. 影响范围与严重程度(按选项):
   • 选项 A(G1+G2+G3+G5):G1 —— 增量轮次默认关闭(rollout percent=0),当前用户零影响;但一旦放量,V2 侧零节省、V1 完全不可用,功能形同虚设(严重,静默)。G2 —— 开了 CCR/rules/rescale 的 V2 用户拿不到对应工具,静默失败(中)。G3/G5 —— 体验瑕疵(低)。
   • 选项 B(A 之外加建 G4):新增 opencode lane 委派工具面,补齐与 pi 的能力对齐(能力增强,非缺陷修复)。
4. 怎么修复的:G1 = 恢复既有实现(重放已批准的 commit 到 master + 定向验证,无新设计);G2 = 落地既有 PR [PR] fix: opencode V2 manifest serves nested OpenAI tools but fetchManifest parsed them flat (#2656) #2659;G3+G5 = 小 parity 修补;G4 = 先讨论方案再实现。
5. 回归风险(按选项):选项 A —— G1 重放需与在途的 [PR] fix: give-up direct send must not ship the lane-rewritten payload (#3304) #3535 / fix(agent): proxy-death fallback no longer forwards incremental payloads upstream (#3304) #3529(都动增量直发路径,均在审)一起核读,三者同域我合并视角过一遍;G2 只改 fetchManifest 解析,不动 wire;G3/G5 纯新增输出,低风险。选项 B —— 新增工具注册面 + 跨 lane 协议对齐,面更大,需设计先行。
6. 是否破坏缓存:不破坏。G1 恰是让增量轮次生效,提升前缀缓存命中率;其余不改缓存/重试/游标策略。
7. 是否改了设计方向:否。全部沿用 Incremental turns give opencode native zero savings in either generation (V1: no divert seam; V2: no response-ack channel) | opencode 原生插件的增量轮次两个版本下都不生效 #3352、opencode V2 lane: acp_retrieve still never registered — fetchManifest reads the wrong schema for the openai format (#2444 follow-up) #2656 里已定的方向,无架构转向。
8. 是否引入新配置:否。

待你拍板

1. 范围确认:清单是否认可?认可的话我按 G1(已在做)→ G2 → G3+G5 顺序推进,G4 挂起等讨论。
2. G4 要不要做:若做,我的建议是把 pi-subagents/ 的委派协议语义复用到 opencode lane(opencode 本身有子代理运行时,工具面照 acp_delegate* 对齐),但这动的是两 lane 的工具面一致性,值得先单独讨论一轮。
3. 如果你说的「more support」还包含某个具体场景(比如更新版 opencode-v2 的新 runtime API、或某类 provider 在 V2 下的适配),告诉我具体现象,我补进清单。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

G1 已落地为 PR:#3599(增量轮次 pull-receipt + opencode V1 接线,重放到当前 master)。

要点:

• 内容 = 原 PR Incremental turns: pull receipt for hosts without a response seam + opencode v1 wired (#3352) #3481 的单个 commit(4f01bd1)原样 cherry-pick,无新设计——方案在 Incremental turns give opencode native zero savings in either generation (V1: no divert seam; V2: no response-ack channel) | opencode 原生插件的增量轮次两个版本下都不生效 #3352 里你已拍板方向 2,实现当时已过审,只是合并时进了 fix: attribute incremental-turn acks by per-request turn id, not URL (#3329) #3340 的分支被留在 master 之外。
• 与当前 master 的语义重叠已逐处核对(197-master 发版最后 #3511 zod opaque specifier、Egress image downscale: shrink big images before sending to the model, originals stay local and self-readable | 重做图片降采样(简化版):发模型前压大图、原图留本地不动、模型被告知尺寸后可自读原图 #3400 图片缩放、Three issues found during real-model stress testing: WS passthrough can't connect — HTTP upstream is guaranteed to die; | 真模型压测发现的三个问题:WS 直通连不上 HTTP 上游必死、超限时死锁+紧急提示风暴、compress 激活本身太重 #3461 nudge gated 三处漂移都不碰新代码路径);唯一文本冲突是 CHANGELOG([Unreleased] 两边各加条目,都保留、新→旧排序)。
• 本地定向验证:typecheck 干净;opencode-incremental / incremental-lane / incremental-client-recovery / issue3343-divert-authz / opencode-native(-v1) / opencode-v2 七个套件 86 pass / 0 fail。全量以 CI 为准。
• 默认行为零变化:rollout pluginIncrementalTurns 仍是 0%,所有安装字节级不变;开启后 V2 才真正吃到增量(V2 此前每轮全量重发),V1 获得同样能力。无新增配置面。
• 一个合并协调点:在途的 [PR] fix: give-up direct send must not ship the lane-rewritten payload (#3304) #3535 / fix(agent): proxy-death fallback no longer forwards incremental payloads upstream (#3304) #3529(When the proxy goes down, incremental rounds fall back to direct connection, sending the incremental payload as-is to upstream and causing a 400 (same mechanism across opencode/omp/dsh-native). | 代理挂掉时增量轮次降级直连会把增量载荷原样发给上游导致 400(opencode/omp/dsh-native 同一… #3304 后续)与本 PR 同碰 incremental-client.ts 和 opencode-native.ts,改动区域相互独立,但谁先合谁后 rebase,合并时建议一起看一遍(PR 描述里已注明)。

下一步继续 G2:review 在途的 #2659(V2 条件工具注册修复),不另开并行工作。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

进度更新:G3+G5 已完成(PR #3615),三个 PR 的状态如下。

PR	内容	状态
#3599	G1:把搁浅的增量轮询修复(#3481/#3352)重新落回 master(V2 拉取回执 + V1 接入)	CI 全绿(仅 windows 22 的一个分片在检查时还在跑);可合,等人工合并
#2659	G2:opencode V2 条件工具(acp_retrieve/acp_rule/read_original_image)因 manifest 解析形状不匹配永不注册(#2656)——已 rebase 到当前 master 并审查	CI 全绿(四条 test lane + 全部门禁 success);审查结论已回帖,可合,等人工合并
#3615	G3+G5:opencode 两条泳道补齐 /acp-rule 命令(与 pi 泳道语义逐字节一致:裸命令列清单、<文本> 记录、remove <id> 删除、裸 clear 清空、clear <文本> 是记录不是清空)+ V2 /acp 面板补上 V1 自 #1603 起就有的「运行版本 ≠ 已安装版本」陈旧提示	CI 运行中;本地 typecheck 干净 + 定向测试 56/56 通过

#3615 的关键设计点(与 pi 泳道对齐,不发明新东西):

• V1:报告渲染为被忽略的消息并用 [acp-rule]…[/acp-rule] 包裹——这个包裹本来就在代理的内容签名剥离名单里,所以零新增剥离代码,模型上下文里不会出现报告原文;
• V2:报告渲染为合成非模型消息(和其他报告同一机制,最多可见 ~8 KB),模型只看到一句惰性占位文本,不需要包裹;
• 无新配置项、无 wire/消息形状变更;V2 下只能 TUI 调用(run 模式不派发斜杠命令,文档已注明)。

剩余事项:

1. G4(opencode 的 subagent 委派面,即 pi 泳道的 acp_delegate 一族)仍按之前说的等你拍板再动;
2. 三个 PR 都合入后,本 issue 的已知差距(G1–G5)就清零了。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

收工报告:G1–G5 全部交付完毕(三个 PR 待人工合并),结构化八问如下。

PR	内容	CI
#3599	G1:搁浅的增量轮询修复(#3481/#3352)重新落回 master	✅ 全绿
#2659	G2:V2 条件工具(manifest 形状不匹配)永不注册(#2656)——rebase + 完整审查	✅ 全绿
#3615	G3+G5:opencode 两泳道补 /acp-rule + V2 /acp 陈旧提示	⚠️ 仅一个 lane 红,且是 master 既有 flake(见下)

八问

1. 是什么问题:opencode(V1/V2 两代)相对 pi/omp/dsh 泳道存在能力差距;此外一次合并事故让已批准实现的增量轮询修复从 master 整体丢失。
2. 什么原因导致的:①Incremental turns: pull receipt for hosts without a response seam + opencode v1 wired (#3352) #3481 被合进了另一个 PR 的 base 分支而非 master → 内容搁浅;②客户端 fetchManifest 按扁平 {name} 解析,而 manifest 提供的是嵌套 OpenAI wire 形状 {type:"function",function:{...}} → 解析出 0 个工具且失败被静默吞掉;③/acp-rule 当年只在 pi 落地(/acp-rule 命令人可以直接调用 #1251/rules 默认打开 + /acp-rule 命令补 remove/clear 转发(人类侧删除权) #1399),opencode 泳道没有跟进;V2 /acp 漏掉了 V1 自 auto-update installs but never activates on long-lived plugin hosts; unwritable install dir retries every 3-min cycle for 11+ days #1603 起就有的陈旧版本提示。
3. 影响范围与严重程度:①增量轮询在 opencode 上零收益(V2 发标记但 ack 永不落、V1 未接入)——rollout 默认 0%,启用前无用户影响;②开了 CCR/rules/图片缩放的用户在 opencode V2 拿不到对应条件工具(该宿主上功能不可用);③人无法在 opencode TUI 直接操作持久规则(只能绕模型);④纯体验瑕疵。
4. 怎么修复的:①把已批准的提交原样 cherry-pick 到当前 master(逐行核对过与 master 漂移无语义重叠);②审查并 rebase 既有修复 PR(客户端侧解析嵌套形状,向后兼容);③新 PR 走既有跨泳道模式:V1 共享命令工厂注册第三命令、报告用既有的 [acp-rule] 包裹走既有内容签名剥离(零新增剥离代码);V2 在 command editor 加第三个条目、渲染为惰性合成消息;参数语义与 pi 泳道逐字节一致。
5. 是否有回归问题:逐 PR 审过既有行为——①rollout 0% 下零行为变更;②唯一变化是「坏的→好的」(已披露旧值→新值);③仅命令面,无 wire/消息形状变更,两种压缩模式都推演过(proxy 模式无命令接缝,不受影响)。feat: opencode lanes gain /acp-rule + V2 /acp staleness notice (#3594) #3615 唯一红的 lane 是 test (windows-latest, 22, 2) 里的 dsh-native 用例——master 自身在同一用例上也红(run 39051432070),本 PR diff 完全不触碰 dsh 代码,本地 57/57 通过;已立项 #3624(带来源标记)跟踪,人工 rerun 或修掉 flake 后该 lane 即绿。
6. 是否破坏缓存:不涉及——未触碰缓存/重试/增量游标/去重键逻辑,前缀缓存不受影响。
7. 是否改了设计方向:不涉及——所有修复都是把 opencode 对齐到既有跨泳道模式(拉取回执、manifest 契约、pi 命令对等),没有新架构。
8. 是否引入了新的配置:无——零新增 env/config/CLI flag(PR 描述中已声明)。

待你操作:①人工合并三个 PR(agent 无权合并);若 #3615 那个 lane 仍红,rerun 一下即可(flake 证据见 #3624)。②G4(opencode 的 subagent 委派面,即 pi 的 acp_delegate 一族)仍等你拍板再做。