Repository navigation
Description
快进水位 v6:(sessionid, msgid) 复合身份驱动增量快路的完整设计(实现契约)
owner 裁定(2026-11-04):前代实现线全部作废——PR #5576(v5 身份门 / canonical 行链车道 / msgid 车道打包)虽经两轮深度评审,仍被 owner 关闭未合并;本次为全量重新开发,从最新 master 的干净分支起步,不移植旧分支任何代码(设计结论与评审教训只作参考,代码一律重写)。本文档是那次重做的唯一实现契约与防漂移基准。
第二轮对齐完成(2026-11-04):身份判决升级为 (sessionid, msgid) 复合键(单看任一者都有跨会话撞值风险);新增身份硬前置门(§3.2:收不到完整双 id = 故障 → 拒绝请求 + 零副作用,禁止任何形式的静默回退);新增 P9 身份层禁截断。由此
"?"槽概念整段删除,原「无证据增量」路径作废。
第三轮对齐完成(2026-11-04,owner 裁定=纯忽略版):只要能对账(§3.2 双信道完整)就忽略客户端压缩——只看客户端增量消息;增量消息若是压缩摘要本身,一概接纳、不做特殊处理。由此:视图永远前向追加(P3 字面无例外);hide/replace/archive日志种类整体删除(词汇表缩为 geom/block/arm/unarm 四种类);摘要前缀表、幸存区重锚定、W<0 判压缩机件、未知角落分支全删(后者并入 §3.2 故障拒绝);x-bili-pf-tail-ids改为全元素全量列表(与 T 一一对应、体序排列),v5 尾窗+锚点模式仅为非 cohort 路径保留。§4/§4.1 存储机制至此经三轮走查定稿,直接进入实现。范围边界(本 issue 只做 v6 msgid 车道):L1 身份薄表 + 身份硬门 +
fastpath.ts判决重写 + §4.1 三表存储(待下一轮定稿)+ §8 测试矩阵。
不属于本 issue:M1 原生身份观测层(nativeIdentityObservation)、canonical transcript 行链车道、以及此前各中间版本的演进过程。master 上已有的 v5 水位基线(pluginFullResendWatermark,含 tail-ids 信道)原样保留并继续为非 cohort 流量服务(其"降级诊断层"表述作废——它就是这些流量的正式服务路径);cohort 内采集端(src/agent/pf-channel.ts/native-intercept)切换全量列表模式的改动属本 PR 范围。
1. 背景(为什么重做,一段话)
dsh/pi/omp/opencode 等客户端全量重发历史,服务端每轮 JSON.parse 整个 multi-MiB 前缀 + 重建 CoreMessage(#5403 OOM 对)。此前实现把"身份"建立在服务端产物上(内容哈希/字节比对当主门、内核行链对齐当主门),违背了裁定:客户端自己的 sessionid + msgid 才是身份标志。在此基础上,第一轮实现的第二版又留了致命的软口:缺 id 时可以靠计数几何"猜"着继续跑——owner 裁定(2026-11-04):这种猜着跑一旦把错误增量缝进既有世界就是不可逆污染,后果灾难性,禁止回退。本版契约按该裁定收紧:身份是硬前置门,收不齐就报错,宁拒勿猜。一次性做完,不设观察期。
2. 已裁定原则(编号供引用,P1–P5 来自 owner 原始裁定记录 m02690/m02693/m02696/m03239;P6–P8 随第 2 版存储骨架一并裁定 2026-11-03;P9 随第二轮对齐裁定 2026-11-04)
- P1 身份唯一:sessionid + msgid 统一处理为身份标志,以复合对 (sessionid, msgid) 参与判决——sessionid 单看会被不同会话复用撞值,msgid 单看也有跨会话发同值的观测风险,而对同时撞上 = 基本确定同一会话(owner 裁定 2026-11-04,残留的完整对撞按接受处理,不加第三信号)。不管载体是哪个(shim 信道、wb 显式头、codex 本地态头、cc/opencode/gemini 各自信道)。bili 自造的任何 id(内核
h_*)只属于渲染层,永不进入命中判决。快照分区键不由客户端任何头上报的值充当(见 §3.1)。 - P2 只增量解析:命中轮只对**本轮新入册的元素(身份差集 NEW,可落任意体位)**做转换解析;其余全部字节零转换、零驻留原文。
- P3 快照绝对权威:服务端稳定快照是唯一账本。客户端侧一切结构变化--压缩、切模型(族内)、换序、就地改写、重编号--在内容与档案层一律忽略;视图核只前向追加;没有任何单一客户端事件触发全局重定基。快照档案单调增长(防 [bug] DSH 桌面端 0.1.188:宿主原生压缩落地摧毁折叠基底 → 同一区间永久不可锚定、compress 连片失败并熔断(compaction-basic auto:false 仍无效) #2432 死螺旋 / "会话毁灭" 的底线不变量)。(注:客户端压缩的唯一账面动作是盖戳随身体几何走——
t天然等于本轮实测 T,属记账不是处置,不改档案与视图核本体,见 §6.1;第三轮裁定确认压缩无任何独立执行路径,摘要消息按普通增量接纳。) - P4 前置段透传:system、tool/skill 定义、第一条用户消息之前的一切可识别前置内容 → 每轮从当前流量取新鲜值透传,永不进入冻结快照(因此不存在"system 挡命中"问题,system 永远跟随当前轮)。识别不出前置段的未知布局 → 保守地从 body 开头起算账本边界(宁可多冻结正文,不误把系统文本冻进去再放不出去)。
- P5 禁止全量重解析(硬红线):既有会话在任何情况下不再走全量解析路线。仅有的两个合法例外 = 冷启动武装轮 与 新身份发放(§3.1 匹配失败/未命中即新世界)。
- P6 持久不重建:成立(§4.1.4 重启段)。全量重解析的合法入口恒定为恰好两个(全新会话、新发 pf_sid §3.1)。
- P7 数据平面零状态、元数据 = log 派生:当前状态永远是确定性纯函数值
fold(pf_ckpt.meta_json, pf_log[ls_seq > ckpt_ls_seq]),内存只是缓存。 - P8 id 永生(2026-11-04 扩展至 sess/msg 对):账本每行的
(sess_raw, ledger_id)对只在首次入册写入,永不删除改写;「见过没?」=(sess_raw, ledger_id)复合索引点查 → pf_sid + pos,跨重启恒可答。 - P9 身份层禁截断(新增 2026-11-04):身份收集层对
(sessionid, msgid)一律存储原值——数据平面、索引、ext 工作副本、诊断输出全链路,任何环节禁止截断 / 哈希 / digest 化 / 摘要化(防哈希碰撞致身份错认;前车之鉴:作废分支曾以n:<sha1-8>摘要入 ext 键位,round-1 评审 X1 已标记,此条将其升格为禁令)。内容侧衍生物([PR] protocol-stable core identity: same logical conversation, same ids in every dialect (#3642) #3658 身份 sig、Image message ids re-mint whenever an earlier image leaves the visible tail (membership-based ClusterCounter suffix) — prefix-cache breaks per fold, feeds #3748 storage growth #3751 图片指纹)只允许出现在 warn 诊断流,永不进入命中判决、永不入账本(原 sig 兜底锚定职责撤销)。 - 结构事实(物理约束,非设计选择):跨协议族切模型(chat↔responses↔google proto)不能共用快照字节流——出站必然按目标族重建,逻辑核仍共享;族内切模型 = 忽略(无事件)。图片 base64 重编码在同 id 下不触发任何事件(命中标度只看 (序号, (sess,msgid), cs),不比内容字节,见 §6.2)。
3. 架构分层(建在 master 已有的标准结构上,不新建第二套)
| 层 | 内容 | 状态 |
|---|---|---|
| L0 通用结构 | BiliMessage/CoreMessage 规范 IR;{openai,anthropic,responses,google}ToCore ↔ coreToX wire 矩阵;#3642 跨协议稳定规范 id(规范投影 role|contentType|toolName|text,粒度公理);#3658 身份 sig、#3751 图片指纹(降为诊断信号,见 P9) |
master 已有,零重建 |
| L1 身份提取 | 双信道采集(§3.2)+ pf_sid 匹配(§3.1)+ 载体表 resolver 链,归一输出 (pf_sid?, sess_raw, elementIds[])(elementIds 要么完整真实、要么触发故障门) |
本 PR 新增(薄表) |
| L2 元素边界扫描 | 每族一个薄适配器,统一 span 机制 | openai = 现有 scanMessagesSpans;他族同构跟进(rollout 排序问题,非架构问题) |
| L3 判决 | 纯函数,作用域=单个 pf_sid,只消费 (元素序号 × elementIds × (sess,msgid) × 宽度),协议无关 |
本 PR 重写 fastpath.ts |
| L4 出站 | coreToX 每轮按目标族渲染 |
master 已有 |
L1 载体表(cohort 准入以双信道完备为准,§3.2 cohort 节):
- shim 信道
x-bili-plugin-conversation(会话级身份载体)+x-bili-pf-count+x-bili-pf-tail-ids(v6 模式=全元素全量列表,与 T 一一对应、体序排列;fleet dsh/pi/omp/opencode 均有唯一原生 id,采集器读客户端存储 id;初始 cohort,主战场); - wb:
x-conversation-id/x-conversation-message-id(重试稳定)+x-compaction/x-context-compacted显式事件头; - codex:
session-id/thread-id/x-codex-window-id+turn-id,previous_response_id轮换; - cc:
x-claude-code-session-id(+ metadata.user_id 双通道); - opencode:
x-session-affinity/x-opencode-session-id; - gemini:协议形态信号 +
<state_snapshot>标记。
以上列出的是候选信道来源;每个 carrier 能否进 v6 cohort,以其 resolver 能稳定产出「请求级 sessionid + 与体元素一一对应的全量元素级 msgid」为准(配置级声明,见 §3.2)。取不到即不进 cohort 或按故障处理,不再有 "?" 保位一说。
3.1 身份发放与匹配(2026-11-04 第二轮对齐:复合键制)
事实基础(owner 裁定):sessionid 单看不唯一(观测到跨会话复用);msgid 单看有跨会话同值风险;(sessionid, msgid) 对同时出现 ⇒ 基本确定即同一会话。因此:
- 快照分区键 = 服务端自造的
pf_sid(形如pf_<hex12>),与客户端头上报的任何值完全解耦(自引用表查询,一经发放终身有效、重启可再匹配)。 - 客户端身份原值成对入表(P8/P9):账本行记首见的
(sess_raw, ledger_id),只写一次、永不改写;全局复合索引idx(sess_raw, ledger_id)支撑 O(log n) 点查。sessionid 不再是"只入诊断日志"——它是复合键的一半,以原值、入表、参与判决(第一轮契约中"客户端 sessionid 退出判决/从不入表"的表述整体作废)。
匹配规则(每轮进道执行一次,纯读;本轮必须先通过 §3.2 身份门):
① echo 直中:请求头 x-bili-pf-session 在表 ⇒ O(1) 命中该 pf_sid,并抽验一致性——本轮上报的 sess_raw 与该世界登记 sess_raw 一致、且至少一个 (sess,msgid) 对在账本内;抽验不符 ⇒ 按 §3.2 故障处置(伪造回声/漂移环,计入 breaker)。echo 只是加速:不配合 echo 的客户端走②同样命中,匹配正确性不依赖客户端配合。
② 复合探测:任取本轮真实 (sess_raw, msgid) 对探测全局复合索引 ⇒ 命中该 pf_sid。仅 msgid 命中而 sess_raw 与登记值不符 ⇒ 视为未命中(防跨世界合并,本条是对第一轮"msgid 单探续接"规则的明确否决)。
③ 兜底发放:全不中 ⇒ 发放新 pf_sid + log arm 条目,本轮走合法武装轮(P5 例外二)。
已裁定代价(2026-11-04):"同一逻辑对话换了 sessionid 回来"不再自动续接旧世界——严格复合键下它表现为规则③,付一轮合法全量武装,旧档案完整保留可回滚。判据:绝不合并两个世界 > 偶尔多一轮全量。
- 不设冷静期(维持):连续发放多个身份且后续无命中不触发特殊处理;诊断留痕,异常再诊断。
- 生命周期(维持):随内核会话删除清理,无独立保留期。
3.2 身份硬前置门(新增 2026-11-04,本版最硬的条款)
前置条件:任何一轮请求要走 v6 快道,必须先成功收集完整双信道——请求级 sessionid + 元素级 msgid[],且 msgid[] 与本轮 body 的元素一一对应(长度 == 扫出的元素总数 T)、全部为真实 id(空位、占位、解析失败的槽一律不接受)。
故障判定(满足任一即为身份故障):
- 信道缺失:无 sessionid 头 / msgid 列表头缺失或无法解析;
- 数量失配:
|msgid[]| ≠ T(与几何扫描矛盾 = 信道谎报或半路丢失); - 成员失真:列表中任一元素非真实 id;
- 一致性破裂:echo 头声称的世界与其携带的身份对互相矛盾(规则①抽验失败)。
故障处置(owner 裁定:报错,不回退):
- 立即拒绝本轮请求——返回错误响应(具体 HTTP 状态码 / 错误体格式列入下轮议程 §7-D),客户端可见、响亮;
- 服务端零副作用:不写
pf_rows/pf_log/pf_ckpt、不动 ext、不推水位、不落任何核(拒绝不留痕 ⇒ 客户端重试同一轮(id 相同)自然成功收敛,无需特殊重放机件); - ERROR 级日志 + 诊断输出(含 carrier、缺哪一半、|R| vs T);故障计数器递增,喂 breaker 与告警。
三个禁止(红线):
① 不得静默落 legacy 非快路继续服务该请求("默认回退"正是本条封死的对象);
② 不得凭计数几何猜测归属去追加增量(第一轮契约的「无证据增量」路径——R 缺/不全但 W>0 照做尾切片——作废删除);
③ 不得用内容签名猜测任何判决(配合 P9:sig/指纹退出判决层)。
理由记录(为何拒绝是唯一自洽处置):身份污染是不可逆的——错误的增量一旦缝进既有世界的账本,账本只增不删,之后每一轮都在污染之上生长(#2432 类失效的加强版);而拒绝是可逆的——什么都没发生,下一轮照常。可逆操作永远优于不可逆操作。
cohort 准入(配置级,区别于运行时故障):carrier 天生不具备完整双信道的 ⇒ 在配置层面排除出 v6 快道——保持现状基线行为,不报错、不启用、不进 breaker(它从未承诺过身份,谈不上违约);运行时故障 = carrier 声称有信道但某轮实际收不齐(这才是 §3.2 的报错对象)。初始 cohort 名单逐 carrier 核实后置入配置(§7-D 议程)。
4. 两个寿命不同的持久结构
- 位置水位
t(易变):上一轮请求体的元素总数语义的水印,每轮末 = 本轮实测 T(盖戳定义使然,无"重置"动作——客户端压缩只是让这个数字自然变化,见 §6.1)。用途收窄为三:① 握手盖戳诚实性(戳永远=身体实测几何,否则下轮客户端窗口错位);② §3.2 数量失配检查的对账基准;③ 漂移诊断流。不再参与增量区间计算(第三轮裁定后唯一判决轴是身份)。 - 累计身份账本(只增):本世界见到的一切 (sess_raw, msgid) 对的有序集合,跨重启恒在。它永不收缩——它就是档案本身,也是集合差能永久算下去的原因。规范版存于 §4.1 数据平面
pf_rows的(sess_raw, ledger_id)列 + 全局复合索引;ext 里只留有界工作副本(容量帽 2048×512ch 量级,超出转诊断;工作副本中的 id 同为原值,P9)。
视图核:按账本序排列的前向追加核数组。内存驻留纪律:原始请求字节只做临时解码、零驻留;稳态内存 = 窗口化核(由现有 fold/block 管道治理预算)+ 账本元数据(≤256KB 量级)+ KB 级状态。永久细节档案 = 磁盘上的 unified transcript rows(现有设施),不在内存里重复存一份全史。
4.1 服务端实时快照存储与"当前状态"(原始存储 + LSM tree 元数据,2026-11-04 三轮走查定稿)
状态横幅(2026-11-04,已定稿进入实现):本节机制经 owner 三轮走查审定(快照维护全生命周期、两种"压缩"的区分、三表结构逐项确认)。第二轮对齐强制变更持续有效:
sess_raw列入表、idx(sess_raw, ledger_id)复合索引、"?"槽整体移除、故障轮零写入(第四条不变量:rejected ⇒ no trace)。第三轮裁定并入:客户端压缩纯忽略(无 hide/replace/archive 事件,词汇表缩为四种类)、x-bili-pf-tail-ids全量列表线格式、未知角落并入 §3.2 故障拒绝、故障计数挂geompayload 扩展位(faults?)。演进记录(背景):初版「单可变行 Meta@rev + CAS」2026-11-03 被裁定作废;第 2 版按 owner 定向的「原始存储 + LSM tree 元数据」设计。核心一句话:LSM 版是元数据本身也是日志——所有元数据变更以不可变条目追加进 L0,周期性压实成 L1 检查点,当前元数据 = 检查点 ⊕ 回放其后的日志;丢更新结构上不可能,历史可重建,读成本有压实保证。
4.1.1 三张表、两个平面
数据平面(原始存储,append-only,无状态列)
pf_rows(sid, pos, sess_raw, ledger_id, core_id, core_json, ts) PK(sid, pos)
元数据平面(LSM)
pf_log(sid, ls_seq, kind, payload_json, born_pos_hi, ts) PK(sid, ls_seq) ← L0 热日志
pf_ckpt(sid, ckpt_ls_seq, meta_json, checksum, updated_at) PK(sid) ← L1 检查点
sid = pf_sid(服务端发放,§3.1);sess_raw / ledger_id 均为客户端上报原值(P9)
索引:idx(pf_rows(sess_raw, ledger_id)) 全局复合 —— §3.1 规则②探测;idx(pf_rows(sid, core_id)) —— block↔pos 绑定
- pf_rows(数据平面):
pos单调元素序永不重排;(sess_raw, ledger_id)= 该位首次见到的宿主身份对原文,跨重启 host↔核心绑定的唯一依据,集合差因此永远算得下去,永生(P8);core_id= 规范核 id(= 内核接收后的 msg_id,The intermediate message (core) is not protocol-agnostic: switching protocols/models causes identity churn; cross-protoc | 中间消息(core)没有做到协议无关:切协议/切模型制造身份 churn,补齐跨协议映射 #3642),用于把 bili 自己的 fold block 精确绑定回 pos 区间而无需重解析内容;core_json= 协议中立的规范 CoreMessage 序列化。严格 append-only:半成品(在途解析)绝不占 pos 再改写。清理 = 内核会话删除事件时按该会话 ext 中的 pf_sid 列表三表连删(无独立保留期)。表零状态:无 status/frontier/状态列。 - pf_log(L0):每条元数据操作一行,
ls_seq每会话单调递增;条目自包含——锚点一律用稳定 id,不用会被后续追加推移的数字偏移;born_pos_hi记录该条目生效时数据平面的最大 pos(两平面的时序戳)。 - pf_ckpt(L1):每会话一行的压实结果,
checksum= fold 后完整元数据的短哈希,水合时快速校验而不必全量 diff。
4.1.2 元数据日志的条目种类(穷举,全部纯追加语义)
| kind | payload | 谁写 |
|---|---|---|
geom |
{t, maxPos, m, misses?, faults?, disabledAt?}(faults? = 本轮之前累计的身份故障计数,第三轮定夺挂在扩展位) |
每轮 finalize |
hide / replace / archive |
已删除(第三轮裁定 2026-11-04:客户端压缩纯忽略、视图不收缩,无隐藏区概念;原审计职责归 unified transcript rows) | — |
block |
{blockRef, span}(bili 自己 fold 的可见性隐藏,从内核 blocks 按 core_id 绑定派生,best-effort:绑定不齐就不写该条目,宁可视图多给、由内核 fold 管道自行治理,绝不为对齐去猜) |
finalize |
unarm / arm |
{reason}(身份边界:匹配失败新发 pf_sid 清档重武装的事件化记录) |
对应路径 |
当前元数据 = fold(pf_ckpt.meta_json, pf_log[ls_seq > ckpt_ls_seq])。fold 规则逐 kind 定义、确定性、幂等(同 key 重复提交 no-op)。视图核可见性 = f(pf_rows × fold(meta)):状态只存在于日志条目里,行永远不变——P7 在 LSM 形态下的表述:数据平面零状态、元数据 = log 派生。
4.1.3 原子性:三层各守一个事务边界
- 单事务双平面提交:finalize 时
INSERT 新行[pos..newMax]+INSERT pf_log(kind='geom')(及当轮产生的 block/arm/unarm 条目,若有)同一个 SQLite 事务。读者任何时刻看到的是整轮前或整轮后,不存在「行在但几何没到」或反之。 - 压实同事务:
UPDATE pf_ckpt(新meta, checksum) + DELETE pf_log(ls_seq <= 新ckpt_ls_seq)同一事务;不变式fold(new_ckpt, remaining_log) ≡ fold(old_ckpt, old_log)——压实前后读出的当前元数据逐字段相等。 - 崩溃分支由此穷尽且有定义:
- 轮中崩 → 事务回滚,下轮客户端重发全量 body,未提交追加消失,零痕迹(天然 at-least-ononce;客户端 body 本身就是重放源,我们是请求驱动的中继不是长驻 runner,刻意不抄 claim/resume 长驻语义并说明理由);
- WAL 页撕裂 → SQLite 自身恢复,上层无感;
checksum校验失败(坏块)→ 降级现状行为 + 诊断打点,绝不猜测重建。安全优先于聪明,设计决策而非遗漏。- (第四条不变量见本节横幅:rejected ⇒ no trace。)
4.1.4 读路径与水合("重启只水合未覆盖窗口"的可实现细节)
- 进程内:每会话一份常驻可见核数组(稳态内存 = 窗口化核 + 账本元数据 ≤256KB 量级;存储不是省内存用的)+ ≤64KB 元数据缓存(ckpt⊕log 结果)。
- 命中轮:身份探测与集合差纯内存判定;前缀核供服务用常驻数组;NEW 元素现解。缓存有效时全程不碰磁盘(常路命中轮触碰数据面 0 次)。
- 重启首触会话(惰性:第一次有该会话请求才做):读 ckpt(校验和)→ 回放尾部 log(有界,见压实策略)→ 得到 geom.t 与 frontiers → 按可见区间水合 pf_rows 的 core_json 填常驻数组(深度折叠区只取轻列不出正文)→ 该会话回到纯增量态,后续轮次与重启前完全一致。没有任何「重启武装轮」:武装只属于 P5 的两个例外(全新会话、新发 pf_sid),重启不在其中(P6 由本条满足)。
⚠️ 已知陷阱(作废分支 round-1 B1 发现,重写时必须钉死回归):hydration 快照必须携带活跃世界原点 o,frontier 只能由 arm/reset 类条目移动,绝不能用"水合窗口起点"冒充原点,否则重启后服务截断历史。 - 压实策略(保证回放有界,都在 finalize 顺带做,无后台线程):
pf_log条目数 ≥ 64 或 ≥ 64KB 或 会话 30min 无活动时触发一次;稳态读成本 = O(1 行 ckpt + ≤64 条 log)。
4.1.5 两种压缩对表的动作(2026-11-04 第三轮裁定后形态)
(A) 客户端侧压缩(cc /compact、opencode 自动、codex 本地 compact、wb 显式头——到 relay 层无需区分产者)→ 纯忽略(owner 裁定原话:"我们只要能对账就忽略客户端压缩,只看客户端增量消息;如果客户端的增量消息是压缩消息本身,一概接纳不做特殊处理"):
- 既有行一字不动;该轮真新增(身份差集 NEW,可能包括摘要消息本身,可能落在任意体位)按普通新增入册,零特殊识别(无摘要前缀匹配、无幸存区重锚定、无 W<0 分支)。
- 元数据平面只剩一条
geom:t天然等于本轮实测 T——盖戳永远跟身体几何走,不存在"重置"动作。 - 明示代价(owner 已知并接受):模型上下文不随客户端缩减而变小,token 账单不跟随 /compact 下降;视图永远前向追加(P3 字面成立,防 [bug] DSH 桌面端 0.1.188:宿主原生压缩落地摧毁折叠基底 → 同一区间永久不可锚定、compress 连片失败并熔断(compaction-basic auto:false 仍无效) #2432 不变量同域守护)。
- 审计不依赖元数据回滚视图:unified transcript rows(现有磁盘设施)是全史真相源。
(B) bili 自己的 fold/token 预算管道(可任意中间段)→ 数据平面仍不动(零状态)、log 变:finalize 检测新增活跃 block → 按 core_id 绑定算出 pos 区间 → 追加 block 条目。渲染不假设可见集合的任何单调性(代码库已有 #3222 中段成对剥离、filterDeadRanges 等非前缀操作先例)。
4.1.6 原则效力修正与容量/迁移
- P6–P9:效力已并入 §2,本节不再重复。
- 容量:数据面典型长会话 MB~数十 MB(core_json 数百 B~数 KB/行);v1 不做物理淘汰(fold 深处行被
block条目隐藏后即为冷数据,GC 留后续题)。元数据面稳态 < 2×64KB(压实保证)。 - 迁移:schema v10→v11,三张表纯
CREATE IF NOT EXISTS,存量安装升级后全空、字节零变化;rollout 开关 OFF 时全套代码零流量零读写。MySQL 后端本期不实装(sidecar 不可用节点行为见 §7-A②)。
5. 逐轮流程(常路)
- 门:rollout 开关(
watermarkV6MsgId默认 OFF,config-file key,见 §9 配置面);pluginMode;非 title-gen;breaker 未熔断;carrier ∈ cohort(§3.2,配置级双信道声明)。 - 扫描与身份采集:span 扫出
T(本轮元素总数);采集双信道(请求级 sess_raw + 元素级 msgid[]);§3.2 身份门:任一故障判定成立 ⇒ 拒绝 + 零副作用(流程到此终止,不进后续步骤)。 - 身份匹配:按 §3.1 规则①→②→③执行(echo 直中+抽验 / 复合探测 / 新发放武装)。
- 集合差判定(唯一判决轴):本轮全部元素 (sess_raw,msgid) 对逐一探全局复合索引 ⇒ 命中 = 老面孔(冻结核已在视图中,零动作零解析);未命中的真实 id = NEW 真新增(可落任意体位)。没有幸存区贪心、没有签名兜底、没有几何推断——对不上就是新增,这是身份自描述的直接推论。
- 增量转换:只解析覆盖 NEW 元素的字节 span(span 来自步骤 2 结构扫描按元素序号定位;NEW 分散时逐块解析);单次整数组 codec 调用保证
_N编号与传统行为逐字一致(codecClusterCounter规则,node_modules/acp-kernel/dist/wire/index.js:64)。实现验证点:v5 已证连续尾切片可达成逐字一致,散布子集需复验(对应 §8 行 6)。 - 组装与出站:视图 = 冻结前缀核 + 追加新核;
coreToX出站;记账t←T、账本 ∪= 本轮对集、写 ext、打x-bili-pf-session(echo 恒带回)+x-bili-pf-seq=T。 - miss 语义(格式级 fail-soft):几何/编解码等格式级判据不足(非身份维度)⇒ 不进快道,落入既有非快路(含 dsh-compaction-guard 边界机件 fix: rebase fold substrate on Codex local auto-compaction (#2372) #2373/[bug] DSH 桌面端 0.1.188:宿主原生压缩落地摧毁折叠基底 → 同一区间永久不可锚定、compress 连片失败并熔断(compaction-basic auto:false 仍无效) #2432/bili-authored client compaction: let the host's own compaction flow run, but bili writes the checkpoint #3733)。credited-miss breaker(5 连击 60min TTL)保留,§3.2 故障计数同样喂入。
关键推论(第三轮修订:身份是唯一判决轴):身份由 (sess_raw, msgid) 复合键自描述——谁旧谁新、属于哪个世界,一次点查即答,与元素在体中的位置无关。计数几何(t/k/T/W)降级为三重辅助:① 握手盖戳必须诚实(戳=本轮实测 T,否则下轮客户端窗口错位);② 故障门输入之一(|R|≠T = 数量失配 ⇒ §3.2 拒绝);③ 漂移探测诊断流。它不再承担任何正确性推理——第一轮"k 意味着客户端保留了 [0..k)、故即便 id 缺失增量也精确已知"的位置信任链在 v6 已整体作废(id 是硬前置不是可选优化)。客户端压缩因此无害:身体怎么变形都不影响逐元素身份探测,唯一需要跟上的是盖戳数字本身。这正是 P2(只解析增量)与 P3(档案不被外来内容污染、单调增长)同时成立的支点。
6. 事件矩阵(完整判定表)
| 事件 | 信号 | 视图核动作 | 账本 | 水位 | 解析代价 |
|---|---|---|---|---|---|
| 纯追加(常态) | NEW 非空(常态恰在体尾) | 追加新核 | ∪新对 | t=T |
仅 NEW 元素 |
| 客户端压缩(任意产者形态——cc /compact、opencode 自动、codex 本地、wb 显式头,无需区分) | 无需检测:任何身体形状(含 W<0)一律常路处理 | 视图继续前向追加,不收缩(模型看到旧核全集 + 新核,不跟随客户端裁剪) | ∪= NEW(摘要消息若在场=普通新消息照常入册,零特殊识别) | t=T_new(盖戳跟身体几何) |
仅 NEW 元素(任意体位) |
| id 稳定·内容变(就地改写) | 判决层不可见(不比字节,§6.2) | 骑旧核 | 不动 | 不动 | 零 |
| 顺序换位 | 判决层不可见 | 按账本序呈现(模型看到的顺序恒定) | 不动 | 不动 | 零 |
| 族内切模型 | 无(忽略类) | 不动 | 不动 | 不动 | 尾切片照旧 |
| 身份边界 | §3.1 规则③匹配失败 ⇒ 新发 pf_sid(含"同一对话换 sessionid 回来"场景) | 新世界 | 新世界 | 重置(arm/unarm 条目) | 合法全量(P5 例外二) |
| 身份故障(新增行) | §3.2 任一故障判定(信道缺失/数量失配/成员失真/一致性破裂) | 无动作(拒绝,零副作用) | 不写 | 不推 | 零(请求被拒) |
| 已并入 §3.2:双信道硬门下该状态不可达——身份/几何任一不一致即故障拒绝;身份完整则几何无判决权 | — | — | — | — |
6.1 客户端压缩的执行细则
- 没有专门的执行路径(第三轮裁定:"只要能对账就忽略客户端压缩")。常路(§5)对压缩轮的处置与非压缩轮完全同构:逐元素身份探测 → 集合差 → 只解析 NEW。摘要消息若以真实 id 出现在体里,它就是一条普通的新消息:被解析、入册、进视图,与自家
<bili-snapshot v1 …(src/server/dsh-authored-compaction.ts)没有任何待遇差别。 - 前缀表 / 产者归属识别:删除。行为不因产者而异;诊断日志如需归因,记录该消息前若干字节的原文片段即可(不进判决、不建常量表)。
- 盖戳跟身体几何:
t每轮末 = 本轮实测 T。这不是"重置"而是盖戳定义使然;它保证下一轮客户端的窗口算术不错位(§3.2 数量失配检查的对账基准)。 - 防 [bug] DSH 桌面端 0.1.188:宿主原生压缩落地摧毁折叠基底 → 同一区间永久不可锚定、compress 连片失败并熔断(compaction-basic auto:false 仍无效) #2432 不变:全程零碰冻结区 ⇒ 内核 fold 锚点永不因客户端事件自毁;与现有
markNativeCompactionBoundary/carriesDshLocalCompactionSummary(阈值 8)guard 互补。
6.2 字节变动的执行细则
- 命中判据只看
(序号, (sess_raw, msgid), cs),从不比较内容字节:参数空格/键序抖动、base64 重编码在同对下全部归零。 - 就地编辑对模型不可见的唯一例外通道 = §2 P4 前置段(永远新鲜透传)。超出前置段的一切就地修改,模型永远看到账本里的版本。
- 降级为诊断流的原 v5 判据(prevId-pin、宽度算术告警、head 字节比较)与 [PR] protocol-stable core identity: same logical conversation, same ids in every dialect (#3642) #3658/Image message ids re-mint whenever an earlier image leaves the visible tail (membership-based ClusterCounter suffix) — prefix-cache breaks per fold, feeds #3748 storage growth #3751 内容衍生签名保留为 warn 日志,喂漂移探测与统计,永不参与判决(P9)。
7. 待裁项与下轮议程
A. 遗留待裁默认值(可否决,逐条独立)
~~1. ~~未知布局角落 — 已关闭(第三轮 2026-11-04):该状态在双信道硬门下不可达——任何身份/几何不一致直接落入 §3.2 故障拒绝,不再有独立处置分支。
2. sidecar 不可用节点(MySQL 后端本期不实装):默认 = 该节点 v6 全套软停用、现状行为,请求不报错(节点级配置排除,区别于 §3.2 的请求级故障)。
3. pf_log 压实后旧条目:默认 = 物理删除(checksum + 诊断兜底);备选 = 保留最近 K 代检查点做深度回滚审计。
4. 就地编辑可见性:默认 = 维持服务端绝对权威,白名单仅前置段(P4);若要允许某种覆盖语义需另行裁定,本 PR 不实现。
B. 已锁定(本轮对齐关闭,不再复议除非 owner 推翻)
身份复合键制(§3.1)、身份硬门与三禁止(§3.2)、P9 禁截断、"?" 槽删除、无证据增量作废、sessionid 原值入表、旋转不换绑(付武装代价)、故障=拒绝+零副作用、cohort 配置级准入、客户端压缩纯忽略(B 版,视图恒前向追加)、日志词汇表缩为四种类(geom/block/arm/unarm)、tail-ids 全量列表线格式、cohort 初始名单 = shim 系(x-bili-plugin-conversation + 全量 msgid 列表)。
C/D. 下一轮对齐议程("实时快照与存储",owner 点名)
D1 实时快照机制已完成(2026-11-04 走查通过:全生命周期带数字时间线 + 四条不变量);D2 三表 schema 定稿已完成(三表/索引/fold/原子性/压实/水合逐项确认;ckpt 语义=纯回放成本装置不承载业务语义;sess_raw 不设存储上限、P9 约束成立;B1 陷阱回归钉已入 §8 行 19);- D3 故障响应形态:HTTP 状态码 / 错误体 JSON 形状 / 客户端重试约定 / 是否带诊断 id;
- D4 初始 cohort 清单:六个候选 carrier 逐个核实"resolver 能否稳定产出完整双信道",定进/出名单(含 shim 采集器的落地形态);
- D5 重编号事件:id 值被客户端换掉(内容同、id 异)在新体系下 = 旧对消失 + 新对 NEW ⇒ 需明确是判为新增(会双份)还是引入对级去重——本轮未裁,留待 D 轮;
- D6 测试矩阵锁定(§8 现稿随 D 轮修订后冻结)。
8. 测试矩阵(按新语义重写 tests/fastpath*.test.ts + 新增 tests/fastpath-v6-msgid.test.ts;D6 轮锁定)
- 纯追加命中,尾切片转换、
_N编号与全量路径逐字一致; - 双信道完整(sess+msgid 齐)⇒ 正常命中入道;
- cohort 排除:无双信道声明的 carrier ⇒ 保持现状基线行为,开关 ON/OFF 均不报错(门双向断言,Test Blind Spot Retrospective: Reinforcing Negative Assertion Discipline, Tightening Fake Upstream Strictness, Thin Inst | 测试盲区复盘:补反向断言纪律、假上游严格化、薄安装冒烟、形态矩阵与生命周期覆盖 #3617 规约);
- 压缩·纯忽略(B 版):压缩轮后视图继续前向追加不收缩(模型看到全部旧核+新核)、无 hide 类条目写入、次轮照旧命中;
- 压缩·摘要即增量:摘要消息以真实 id 出现在压缩轮体中 ⇒ 当普通新消息正常解析、入册、进视图(零特殊识别回归钉);
- 压缩·散布 NEW:NEW 落在任意体位(如 opencode 形态摘要在 pos 0)⇒ 正确解析且
_N编号与全量路径逐字一致(散布子集编码一致性回归钉); - 身份故障·零副作用:msgid[] 缺一项 ⇒ 请求被拒 + 三表/ext/水位无任何写入 + ERROR 日志与计数存在;
- 身份故障·数量失配:
|msgid[]| ≠ T⇒ 拒绝; - 故障恢复无痕迹:故障轮后客户端重发同一轮(同 ids)⇒ 正常命中、世界与账本和故障未发生时逐字段一致(拒绝可逆性的回归钉);
- 仅 msgid 命中而 sess 不符 ⇒ 判未命中、新发放(跨世界合并防护钉——第一轮规则②的反向回归);
- 同一对话换 sessionid 回来 ⇒ 新发 pf_sid + 合法武装轮 + 旧世界档案完整保留(旋转代价钉);
- 伪造 echo 头(sid 在表但身份对矛盾)⇒ §3.2 故障 + breaker 计数;
- id 稳定内容改:骑旧核、视图不变、诊断 warn 存在;
- 换序:视图按账本序,与输入顺序无关;
- 族内切模型:无事件,照旧命中;
- breaker:5 连击 credited-miss(含故障计数)⇒ 60min 熔断 + 恢复;
- 容量帽:ext 工作副本超 2048 条截断 + 诊断(磁盘全量原值仍在);
- 开关关(默认)⇒ 现有 v5 套件全绿不变;
- 水合一致性:模拟进程重启(丢内存镜像)后首轮命中,视图与重启前最后一轮逐字节相同(P6;叠加跨 L1 折叠的 3 次连续重启 oracle 比对——B1 陷阱回归钉);
- 中间段折叠渲染:
block日志条目落在中段时,出站视图与内核可见性一致,被折区 id 仍可解析(P7/P8); - 身份 echo:响应头
x-bili-pf-session存在 ⇒ 稳态直接命中(O(1))+ 抽验通路存在; - 换绑后档案:新发后旧 pf_sid 数据完整保留(回滚参照);deleteSession 连带清理该会话全部 sid(pf_* 三表连删无孤儿)。
验收:tsc --noEmit 0 + 相关全套绿;PR 正文引用本 issue(Closes 本 issue)。
9. Rollout 与实施顺序
- 开关
watermarkV6MsgId默认 OFF,config-file key(src/knobs.ts,不新增 env 旋钮;env 稀缺面规约),与现有pluginFullResendWatermark并存;v5 代码路径保留、继续为非 cohort 流量服务(不是删掉)。 - 配置面(PR 必须单列章节):
watermarkV6MsgId(总闸)+ v6 cohort carrier 名单(每项声明其双信道 resolver;初始名单 = shim 系:x-bili-plugin-conversation+全量 msgid 列表;他族逐格解锁)。 - 实施顺序(对齐完成,直接开工):schema v11 三表 → 存储模块(fold / 原子提交 / 压实 / 水合)→ knobs 开关面 → L1 载体薄表 + 采集端全量列表化 → L3 判决纯函数 → evaluate 接线 → §8 测试矩阵 →
tsc+ 全套 → 回归交 owner。从最新 master 开干净分支全新实现,单 PR,不分观察期,不移植 [PR] Native-Identity Fastpath: Observation Layer (M1) + Identity-Only Hit Gate (v5) | 原生身份快路径:观测层+身份制判据(一次做完) #5576 旧代码。 - 观测/归因类能力(原生身份观察层等)不在本 PR 范围;客户端身份原值本就入表入诊断,如后续需要更强归因另行立项。
补充裁定(2026-11-05,owner):规范流转顺序——所有平面的设计基准(ai: sglang-gpu0/qwen3.8-27b)
裁定背景:PR #5689(#5664 渲染快照平面)被 owner 指出设计偏离本契约——缓存单位取成映射后的出站字节、稳态轮直接拼接此前已发字节跳过再序列化。完成偏离盘点后,owner 裁定如下,补录进契约正文(不另开子 issue)。
- 目标函数:快路体系追求的是稳定性、扩展性、通用性,不是性能;性能收益是按下面流程做对的副产品。一切设计评审先问"流转顺序对不对",不问"快不快"。
- 规范流转顺序(固定,每轮全链路必须走全):
原始字节 → to core 通用协议 → 改写(内核)→ apply 到快照 → to 目标协议 → 出站
快照只允许缓存改写层右侧的通用核形态(即 §4.1pf_rows.core_json的 CoreMessage 形态),禁止缓存任何映射后的出站 wire 字节。每一轮都必须完整经过全部环节、含最后的目标协议序列化——这是 §2「结构事实」(跨协议族不能共用出站字节流、出站必然按目标族重建)的物理体现:族内切模型因此天然过映射层,身份平面不必为它设事件。 - 边界归属:快照的校验、状态指纹与审计比对点只落在两处——内核侧内部状态(策略/折叠摘要等)与改写后的通用核形态;模型/渲染阶段专属参数(model、maxDim、toolArmed 等)降为每轮映射层的输入,不参与快照有效性判定。
- 结构事件的处置:一切客户端结构变化(压缩、就地改写、换序、重编号等)一律走规范链:改写层重新推导、映射层每轮重建,受影响段落的快照按版本化重建/替换处理,永不就地覆写;车道关死只保留一种情形——存储底材本身损坏且不可恢复(校验和不符/水合失败)。
- 实施约束:v12 三表与 rollout 开关均未合入 master,改形在合并前完成 ⇒ 零迁移成本。fastpath v6 render snapshot plane: one-time full rewrite, steady-state rounds skip full view scan (#5643 sub-item) | fastpath v6 render 快照平面:全量改写只做一次,稳态轮跳过全视图扫描(#5643 子项) #5664 / PR [PR] feat(fastpath): v6 render-snapshot plane — steady turns skip the full-view scan (#5664) #5689 恢复施工时按本节重写其正文与实现,正文引用本节而不另立新原则。
补充裁定(2026-11-05 下午,owner):快照必须随压缩演进——事件化更新语义(ai: sglang-gpu0/qwen3.8-27b 记录)
背景质疑(owner):压缩是 bili 自己的核心功能;链上「改写」这一环的主体就是压缩。快照平面若在任何一次折叠发生时自杀,那么在「上下文大到需要压」的目标会话里它的收益从第一次折叠起就永久消失——等于给核心场景没做东西。快照必须活过压缩的完整生命周期。
裁定三原则(owner 原话骨架):
- 压缩是 bili 自己的压缩核心功能;
- 压缩本质是客户端请求服务端——它走普通请求进来,没有带外事件通道;
- 服务端收到请求后直接生成最新的 snapshot 修改:权威投影与当前快照的 diff = 一串有序事件(插入/更新/删除),按序作用于快照,完成对快照的修改。
实施基准(由上述原则落地):
- 行键 = ledger 绝对位置(append-only、永不复用的身份地基),不是存活元素的紧凑序号——delete 事件来了全表不重编号;
- 快照表就是普通可变表:每轮 diff 落成 INSERT(尾部新元素)/ UPDATE(块覆盖范围被改写的格)/ DELETE(被折叠行),单事务提交。持久性与崩溃一致性由 SQLite/WAL 事务 + unified 双写对账承担;禁止再叠加日志结构化层(op 表/版本列/ckpt+回放)——快照是派生缓存而非账本,真值在 pf_rows 与内核状态里,且死版本只增不减踩泄漏红线;
- diff 只按内核管道证据寻址(块覆盖范围、ledgerSeq、checkpoint 帧边界),禁止模糊相似度匹配;地址对不上 ⇒ 该轮不产事件、整轮 legacy 回退,下轮再说;
- 四件套保护一个不少:tripwire(核心形态边界比对)、S4 逐行校验和、见证要求(结构变化必须有内核事件背书)、审计节拍抽验。无见证漂移照样永久判死,行为与现状逐字节相同;
- §5 上文一条不改:行内容仍是改写后通用核形态、出站整段每轮现过完整映射链;红门词汇、90% 压让路、O(新) 稳态开销保留;存储随存活元素有界增长;
- 明确否决的替代方案:A) 折叠即判死(目标场景收益归零);B) 分段重置/换段重建(离散事件的粗糙近似,被事件化语义取代);C) 逐行版本链+WAL 回放(重复建设 + 死版本泄漏)。
附录(2026-11-05,落点确认):插件模式的压缩调用打的就是 bili 的管理端点(POST /__bili/plugin/tool,src/server/admin.ts:801 →handlePluginTool)——压缩在该次管理请求内执行,服务端内核当场改写、blocks 当场更新,端点即第一现场。实施口径:端点执行压缩成功后给该会话盖一次性「结构事件待处理」标记;期间平面保持红门(新红因structural-pending)拒绝任何绿轮猜测;下一轮模型请求走全量路径时执行表修改(UPDATE 摘要格 + DELETE 被覆盖行 + INSERT 新增,落地形态为「自首个分歧点截断 + 整段重新追加」的单事务写)。行键维持存活元素紧凑序号的连续不变量,不引入稳定行键——理由:结构变化总是使分歧点之后的整段按权威投影重同步,前缀逐字节不变,稳定寻址在此无正确性收益、只增加索引与水合复杂度;「插入/更新/删除」三原语对紧凑有序表的语义与截断重追加完全等价,存储与校验和机制不动。绕过该端点的宿主(dsh native compaction,[bug] DSH 桌面端 0.1.188:宿主原生压缩落地摧毁折叠基底 → 同一区间永久不可锚定、compress 连片失败并熔断(compaction-basic auto:false 仍无效) #2432 类)由既有的 checkpoint 帧签名+rebase 检测把证据喂给同一个表修改例程。标记在表修改成功落盘后消费;进程重启丢失标记的后果是保守方向(下轮按无见证漂移判死,fail-safe)。无见证漂移的判死语义一字不改。
附录二(2026-11-05 晚间,owner):事件写回时序补正——压缩请求内同步落表,下一轮只做核对
owner 复述裁定:「改写压缩产生 diff 直接写快照;快照就是 lsm tree 追加增删改事件,合成就是新快照」——对「实施基准」的时序措辞作如下补正:
- 写入时机 = 压缩请求内同步。结构事件的第一现场(插件端点 / 内核自折点)在拿到内核管道证据的当次请求里就把增删改事件落成单事务写;「下一轮模型请求走全量路径时执行表修改」仅保留为绕过第一现场的宿主(dsh native compaction 类)的兜底路径。两路喂同一个表修改例程。
- 快照形态确认(owner 原话):普通可变表就是 lsm tree——每轮把 diff 追加为插入/更新/删除事件、单事务提交,表本身即最新合成结果。此表述与实施基准「禁止再叠加日志结构化层(op 表/版本列/回放引擎)」不矛盾:事件是单事务里的 DML,不是持久化重放日志;崩溃一致性照旧由 SQLite/WAL 承担,S4 校验和与 ckpt 折叠不动。
- 「行键维持存活元素紧凑序号」的实施口径作废,恢复为实施基准原文:行键 = ledger 绝对位置,delete 事件来了全表不重编号(三原语各自真寻址;紧凑序号≡截断重追加只是等价落地形态,不是采纳的理由)。
Activity
[-]feat(fastpath): v6 msgid 身份驱动增量快路 —— 全量重新开发(前代 #5576 线作废)| fastpath v6: msgid-identity-driven incremental fastpath, full rework[/-][+]feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fastpath): v6 msgid 身份驱动增量快路 —— 全量重新开发(前代 #5576 线作废)| fastpath v6: msgid-identity-driven incremental fastpath, full rework[/+][-]feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fastpath): v6 msgid 身份驱动增量快路 —— 全量重新开发(前代 #5576 线作废)| fastpath v6: msgid-identity-driven incremental fastpath, full rework[/-][+]feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fas…[/+]ranxianglei commentedon Nov 4, 2026
[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)
查重: 不重复。前代实现线 #5576 已由 owner 关闭作废(本 issue 契约第一条即其替代);open/closed 全量检索无其他同机制(msgid 身份驱动增量快路)在途条目。本 issue 是 v6 的唯一实施契约。
标签:
dshpiopencodeomp(涉及的全部插件车道,dsh threads 模型为主战场)+scope/wiring(请求管道快路车道 + 统一存储三表)+p3(性能/内存加固型 feature,当前用户面无可感知缺陷——#5403 OOM 对已有 v5 水位兜底;不打 bug:功能请求非缺陷)。开工确认(按契约执行,单一 PR、干净分支自最新 master
23a826d37、零移植旧分支代码):pf_rows(sid,pos,ledger_id,core_id,core_json,ts)数据平面 +pf_log/pf_ckptLSM 元数据平面,走 sidecar(Storage layer: four concrete defects (filename coupling, multi-writer heuristic, non-atomic content-store write, immortal compressed sessions) #2671/Web UI first paint stalls 78-180s+: /__bili/overview cold scan blocks the event loop, and the freeze itself feeds the respawn churn #3199),随 kernel session 删除级联清理;fastpath.tsL3 判决重写为「(元素位 × id × 宽度)」纯函数,§5 每轮流程 + §6 事件矩阵全行覆盖(客户端压缩只动元数据平面、摘要永不注入、未知角落走默认①身份边界);watermarkV6MsgId默认 OFF + env override,与现有pluginFullResendWatermark并存;v5 字节门保留为诊断+兜底层,不删。待决项 ①②④⑤ 按契约默认值执行(未知角落=身份边界 / 原位编辑不可见 / sidecar 不可用=降级现状 / log 压实物理删除),owner 随时可否决,推翻即改。PR 落地后按八问回归报告。开始实现。
[-]feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fastpath): v6 msgid identity-driven incremental fastpath — full rework (previous #5576 line voided) | fastpath v6: | feat(fas…[/-][+]feat(fastpath): v6 (sessionid,msgid) 复合身份驱动增量快路 —— 全量重新开发 | fastpath v6: composite-identity-driven incremental fastpath, full rework[/+][-]feat(fastpath): v6 (sessionid,msgid) 复合身份驱动增量快路 —— 全量重新开发 | fastpath v6: composite-identity-driven incremental fastpath, full rework[/-][+]fastpath v6: composite-identity-driven incremental fastpath, full rework | feat(fastpath): v6 (sessionid,msgid) 复合身份驱动增量快路 —— 全量重新开发[/+]ranxianglei commentedon Nov 4, 2026
Implementation landed: PR #5652 (
2026-11-04_fastpath-v6-msgid, from clean master — no #5576 code ported).Scope delivered against this contract: hard identity pre-gate with four fault classes and zero-side-effect rejection (§3.2), composite-key matching with server-minted
pf_sidworlds (§3.1), set-difference-only judgment over the full element-id list (§5), scattered-NEW incremental parse with absolute_N/wire-index rekeying, compaction-as-pure-ignore (§6.1), schema v11 sidecar planepf_rows/pf_log/pf_ckptwith single-transaction row+log commits and fold(ckpt⊕log) semantics (§4.1), client full-list wire form +x-bili-pf-sessionecho, rollout featurewatermarkV6MsgIddefault OFF (nested cohort underpluginFullResendWatermark), §8 test matrix incl. 3× restart across an L1 fold hydration oracle, and session-deletion cascade.Local pre-flight: tsc clean, targeted suites green; two pre-existing sandbox failures (claude-native port, storage golden drift) verified identical on pristine master. Full-suite verdict left to CI. Open defaults followed per §7-A (unknown corner → §3.2 rejection; soft-degrade without sidecar; physical log deletion after compaction with checksum guard) — vetoable before merge.
ranxianglei commentedon Nov 4, 2026
[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)
Confirmed — PR #5652 is real and matches the contract. I independently verified the landed branch before responding (I did not author or push it; commits are under your identity
ranxianglei/bili-dev).Live state (GitHub API):
mergeable: true,mergeable_state: blocked(awaiting review approval / CI — you noted the full-suite verdict is left to CI)edba38af9@ranxianglei:2026-11-04_fastpath-v6-msgid· basemaster· 4 commits · 19 files · +2033/−5923a826d37); no [PR] Native-Identity Fastpath: Observation Layer (M1) + Identity-Only Hit Gate (v5) | 原生身份快路径:观测层+身份制判据(一次做完) #5576 code ported.Independent spot-check of the diff against load-bearing contract points (all pass):
STORAGE_SCHEMA_VERSION = 11;pf_rows/pf_log/pf_ckptcreated;idx_pf_rows_ledger ON (sess_raw, ledger_id)(the global "seen it?" probe index) +idx_pf_rows_core ON (sid, core_id)(block↔pos binding).watermarkV6MsgId: { percent: 0, base: "pluginFullResendWatermark" }= default OFF, nested cohort under the existing watermark flag, env override intact.PfV6IdentityFault(terminal identity fault, zero-side-effect rejection), 5-consecutive-fault breaker → 60 m park (pf:v6-guard),randomBytes-mintedpf_sidworlds, metadata =fold(ckpt, log-after-ckpt)with checksum.deleteSessionreadssession_ext['pf:v6-sids']before sweeping and cascades all bound sids.§8-16/19restart-hydration row (3× boot across an L1 fold, post-restart view byte-identical to pre-restart).Positioning / loop guard: I had been doing parallel local exploration of this same contract while working the issue — it is uncommitted and was never pushed. Since the complete implementation already landed as #5652 under your identity, I will not open a competing second PR (one issue → at most one PR; a duplicate would only create conflicting churn). My local tree is superseded; say the word and I'll discard it.
Open items are yours to drive:
mergeable_state: blocked= needs review sign-off + green CI (merge is human-only either way). Happy to run a deeper line-by-line review pass over the 2033-line diff, or targeted local repros of specific §8 rows, if you want a second set of eyes before you veto-merge.ranxianglei commentedon Nov 4, 2026
[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)
收工判定: 本 issue 的实施已由 PR #5652 完成并落地(owner 身份提交,4 commits / 19 files / +2033−59,干净切自 master
23a826d37)。我已完成独立核验(schema v11 三表+索引、rollout 默认 OFF 嵌套灰度、§3.2 身份预门+熔断、fold(ckpt⊕log)、会话删除级联、§8 测试矩阵含跨 L1 fold 重启水合——全部与契约一致),详见上一条确认回复。按「一 issue 一 PR」纪律我不再另开 PR;本地并行探索的未提交代码已作废,需要我清掉说一声。剩余动作(review 签核 + CI 全量判定 + merge)在 owner 侧。53 remaining items
ranxianglei commentedon Nov 7, 2026
[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)
收到新状态:v6 全线撤回已确认,issue reopen 等重设计。独立核验结果附上。
✅ 独立核验(刚对 origin/master @
bebc239f2实跑):fastpath-v6.ts/fastpath-v6-render.ts均已删除;src/+tests/ 全量 grep v6 符号族(watermarkV6MsgId/pf_rows/pf_render/recordServerSideFold/structural-pending/PF_V6_EXT_KEY/pf:v6)=零命中;evaluateWatermarkFastpath等)原样完好;rolloutpluginFullResendWatermark5% 灰度不变;STORAGE_SCHEMA_VERSION=11属于 [perf] FK child columns ofcontentare unindexed — every releaseContent DELETE full-scansmessages#5539(FK 子索引),不是 v6 线的——即 v6 线最终形态里的版本号(叠在 [perf] FK child columns ofcontentare unindexed — every releaseContent DELETE full-scansmessages#5539 之上)已随三表干净退掉,无残留。撤回是干净的。watermarkV6MsgId=1,其本地库会留有 pf_rows/pf_log/pf_ckpt 三张孤儿表且 user_version=12;升级到回滚后 master(v11)时迁移只前进不后退,三表成为无代码引用的死字节——无害,DB 重建自然消失。我的立场:不擅自启动重设计——功能类 triage 规矩,范围由 owner 拍板(FLOOR 48 已写明「重设计以独立形态启动,范围由 owner 拍板」)。本 issue 沉淀的裁定(目标函数=稳定性/扩展性/通用性、固定链「原始字节→通用核→内核改写→快照应用→目标协议→出站」、校验点只落内核内部状态与改写后核形态、结构事件走规范链、零迁移窗口、附录二事件写回时序)继续作为重设计基准,全部保留在 issue 正文里。你定了范围后,我可以先交一份方案对比/评估(各候选路线如何满足保留裁定、上一版在哪一维失败),拍板后再进实现。
卫生:我的工作区还留着最初实施阶段的未提交探索代码(
fastpath-v6.ts等,从未推送)。目标设计既已撤回,我现在清理并把工作区重置到干净的 origin/master 状态。ranxianglei commentedon Nov 7, 2026
[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)
定位纠正收到,线程记录已更新:这条线不是「增量车道」,是新的基于快照表的压缩底座(新存储为主)——压缩算法内核(折判定/摘要/prompts/ref 契约)不动,动的是状态存取底座(kstate JSON/hydration/save 换挂行表,pos↔内容哈希 id 翻译在 bili 存储桥层,
kernel/零改动);有 session+msgid 的宿主全走此路,无 msgid 按顺序>hash 降级身份通道、同一套表;#5855 只是工程基底非终态。issue 标题里的 "incremental fastpath" 措辞随本纠正作废(标题归系统管道所有,我不改)。✅ #5855 核验("Re-land v6 lane — inverse of #5854 revert (base for snapshot-centric rework, #5643)"):open /
mergeable_state: blocked(等 review),head8d5f069@2026-11-07_reland-v6-lane,base master,1 commit / 35 files / +5822−125。CI 镜像缓存当前在 head 上 30/30 零失败零 pending(我上一刻抓到过一瞬的 3 failed 快照,随后刷新即消——是被取代 run 的中间态,未深挖;若复现再说)。三个待裁定项的参考意见(明确推荐、非拍板,决策在你):
① 折叠覆盖格行生命周期——同意建议方案(标 inactive 保留双形态供 decompress,GC 再物理清)。与内核 lossless round-trip 结构不变量及既有 dead_refs+GC 批量清扫纪律同构。一个微调建议:物理清空的触发条件绑定到覆盖块的生命周期(该格所在 block 本身被归档/删除时才允许 GC 该行),不用全局 TTL——否则 decompress 引用窗口和 GC 窗口需要额外对齐证明。
② 宿主自行变更历史的无见证漂移——推荐分级处置,不要永久关死。理由:这现在是底座不是可选快车道,可用性大于性能(#3128 规矩);且表设计上就是「一次全量 pass 可廉价重建」的(零迁移窗口性质),永久关死浪费了这个便宜。具体:(a) 身份级有证据(宿主自己重发的 msgid 列表与账本 diff 得出布局变化)⇒ witnessed resync=强制恰好一轮全量对账 + 单事务重建受影响段;(b) 真无见证的字节级漂移⇒ sid 级弃表 + 下一 arm 轮全新重建 + 熔断计数;(c) 永久关死只留作反复循环后的最后手段。不变的前提:tripwire(出站字节必须与全量路径逐字相等)仍是最终护栏——漂移状态下供出陈旧前缀字节=缓存投毒,任何 resync 策略都不能绕过这道逐字校验。
③ 无 msgid 降级边界——推荐 count-geometry 为骨架(v6 线已验证的 KEY COROLLARY:增量正确性由计数几何保证,id 只是辅助证据,全 ? 槽位+有效计数也照样正确解析尾窗)。边界行为具体化:模式每会话粘滞,进入 msgid 模式需一致 id 打标证据(按车道白名单纪律,同 dshPersonaFingerprintApplies 的证据门槛);? 槽位走顺序通道拿序数 pos,不阻塞邻居的 id 解析;会话中途换模式=一次 resync,禁止静默混用。
卫生:工作区清理已完成——初版探索代码(fastpath-v6.ts 等 3 个未跟踪文件)已删,8 个改动文件已还原,分支 reset 到干净 origin/master @
bebc239f27(#5854 回滚点),status 除平台目录外全净。ranxianglei commentedon Nov 7, 2026
(ai: sglang-gpu0/qwen3.8-27b)
设计草案 v0.1:Snapshot 中心底座 —— 纯新增 LSM 表族,现有存储零改动
状态:待逐条裁定,未动工。本阶段不触发压缩、不写实现。批准后从 P0 开始。
0. 锁定的边界(按 11-07 裁定原样落字)
PK(sid,pos)、单事务事件追号、S4 校验和的 ckpt 在 compaction 时吸收自身日志),持久化走 WAL 单写者——就是你问的「我们不是已经有 lsm 设计了吗」,这套骨架已合入且有回归钉。acp-kernel一个文件不碰,无人工评审门槛开销。1. 全链路(目标数据流)
关键点:只要表里行不物理删除,snapshot 本身就是全量数据(你的原话定调);所谓「引入 log」的本质 = snapshot 最终是 log+meta 压实成的最新快照(LSM 合成语义)。
2. DDL 草案(新增版本块 v13:老库升级只跑 CREATE,不碰任何旧列)
不变量:
max(log.max_seq, ckpt.ckpt_seq),单调、永不重排;active=0标记;物理清理属裁定 B;post_json恒为改写后通用核形态:model/maxDim/toolArmed 等只是每轮映射输入,从不入表、不参与快照有效性——所以族内切模型不需要任何事件。3. 写路径(方向唯一:内核/压缩事件 → 新表;反向永不发生)
pfRenderCommit:单事务内 [可选清空重建] → upsert 行 → log 追号 → [可选] 折 ckpt(写新 meta+checksum,随后吸收自身日志)。任何疑点抛错即整轮放弃、不落半态。cast(车道首次装载)/append(新元素)/update(改写落位或摘要就地覆写)/delete(覆盖行置 inactive,载荷 = pos 列表)/compact(ckpt 吸收)。core_idsjoin)——就是你说的「结构变更 = 压缩引擎输出的行,很好找」。一次压缩 = 一次单事务{delete 覆盖段 + update/append 摘要},下一帧出站即刻生效,没有补偿轮、没有中间状态。4. 读路径(消费面切换,全部是新读者,旧读者原地不动)
mapEgress(存活行按 pos 排序 ++ 本轮尾窗);前缀字节跨轮稳定 ⇒ 缓存友好。旧版拼缝/tripwire 机器的绝大部分可以退役,仅保留逐字节核对作为红线守卫。x-bili-pf-*握手头堆叠大部分可以删掉(它们的存在前提是旧的两级快路径)。5. 灰度与回滚
6. 测试矩阵(全 hermetic,门闸类断言一律双向)
7. 分期(批准后才启动,每步可独立回退)
8. 待你裁定(每条附倾向,不同意就直接说)
retired_at软标记+最终 GC 是既有的同类先例。需要你显式拍板,我不代拟默认值。附:与已撤回工作的关系
已撤回的「egress 视图层」实现不复活,它的零件只以两种身份回来:pf_* 三件套的事务骨架(已随 #5855 合回 master,本草案直接站在上面)与被实战检验过的测试方法论(A/B 字节级对比、docker gate 演练)。其余(水位握手头、补偿轮、端点 journal、splicing 机器)全部废弃,理由写在 #5854 复盘与本 thread。
ranxianglei commentedon Nov 7, 2026
[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)
设计草案 v0.1 收到,记录为重设计基线文档(待逐条裁定、未动工)。先报一个前提事实校正,再给 A–E 参考意见。
8d5f069,CI 30/30 绿,但mergeable_state: behind:master 已前进到fb18e7e4c4,需先同步)。当前 origin/master 的 schema 仍是 v11(#5539),pf_ 表不在。推论:①「骨架已合入且有回归钉」暂不成立;② 草案的 v13 版本号隐含 #5855 的 v12 先行——P0 的 DDL 工作应排在 #5855 合入之后(或叠在其分支上),否则版本块编号要重排。建议先把 #5855 同步到最新 master 并合掉,再启 P0。A–E 参考意见(明确推荐、非拍板):
A. 行内形态——同意倾向 ②(只存 post)。pre 形态在既有 messages/CAS 里已有持久化(边界 1 规定它们原地继续服务),复制一份体量近翻倍换零新能力。附加条件:与 B 联动——被存活 snap 行引用的 pre 字节必须活得比该行久(GC 顺序耦合),否则 decompress 审计路径要有「pre 缺失→诊断降级」的显式出口,不能静默空引用。
B. 失效行保留——推荐 ②(compaction 时物理清理),策略绑定生命周期而非全局 TTL。保留期 = max(覆盖摘要/块的生命周期, 消费方引用窗口[decompress 审计/计费引用]),在 compaction 时逐格判定。反对 ①(永不清理)的理由很硬:单调无界增长正是 #3752 烧过的红线,owner 修订已把「存储只增不减失控增长」列为 p1 类——长会话下 snap_rows 会重演这个事故。messages 表的 retired_at 软标记+最终 GC 是现成同类先例,照搬其判定框架即可。此项草案明确要求你显式拍板,以上仅供决策输入。
C. 摘要落位——同意倾向 ①(就地占据段首 pos)。出站相对顺序不变=前缀缓存不碎,这是整个底座的存在理由;也是 PK 不撞的自然解。补一条要钉死的:delete 事件的 pos 列表载荷会被 ckpt 吸收掉,所以 ckpt meta 必须在吸收后保留显式覆盖映射(摘要 pos → 被覆盖 pos 区间),decompress/GC 不能只靠位置推断——否则日志压实一次,覆盖关系就只剩隐式约定了。
D. 会话键空间——同意沿用现有 sid。独立命名空间=身份管道翻倍+会话生命周期出现第二事实源(删除级联要跨两个键空间);沿用则 deleteSession 级联平凡化,单写者纪律不破。
E. 本期范围——推荐只做 P0+P1 就收手交验收。这条线刚经历整线撤回,信任要增量重建:P0+P1 是零行为面(影子写不被读),恰好证明事件正确性+体量增长曲线这两个此刻最不确定、且错了最贵的东西;P2(真实 hydrate/egress 切源)是字节对等风险集中点,值得独立 PR+灰度 cohort 在你观察下走(#5403/#5576 的教训都是小流量先行)。P2/P3 等 P1 长跑数据落地后另开 PR。
全部为参考意见,拍板在你。裁定落地后 P0 实施可指派给我(或支援任何接手的 agent)——工作区已在干净 master 待命。
[-]Snapshot中心化的压缩底座:单行表真源 + 压缩=对表的增删改事件(非增量车道,#5652/v6 线定位纠正)[/-][+]Snapshot-Centric Compression Foundation: Single-Row Table as Source of Truth + Compression = Insert/Delete/Update Events | Snapshot中心化的压缩底座:单行表真源 + 压缩=对表的增删改事件(非增量车道,#5652/v6 线定位纠正)[/+]ranxianglei commentedon Nov 7, 2026
[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)
收工:本回合工作=设计草案 v0.1 评审(FLOOR 57 已发:#5855 前提事实校正 + A–E 五条参考意见,拍板在你)。当前无在途代码动作;等你对 A–E 逐条裁定(尤其 B 需你显式拍板)+ #5855 同步合入后,P0 随时可启动。
ranxianglei commentedon Nov 7, 2026
(ai: sglang-gpu0/qwen3.8-27b)
快照表压缩底座:正式提案已出稿,docs-only PR 提交,Discussion 已建。
按上面定位纠正评论(本线 = 基于快照表的压缩底座,内核不动,非增量车道、非 v5 续作),缺口分析报告已整理成完整设计提案:
docs/proposals/snapshot-compression-foundation/README.zh-CN.md/README.md(中英镜像,§0–§16)---- 粘贴开始 ----
提案:快照表式压缩底座(六段固定链,单一存储真源)
0. 摘要(TL;DR)
本提案把上下文压缩的状态底座从「进程内存 + kstate JSON + 多张表」的平行真源格局,换成一套快照表作为唯一存储真源。每轮请求固定走完同一条链:
原始字节 → 协议转换(通用核) → 改写(压缩) → 快照表应用 → 出站映射 → 出站
压缩内核(折判定、摘要、prompts、ref/msgid 契约)零改动。有宿主 session+msgid 双信道的会话全部走新链路;没有 msgid 的宿主按「顺序 > hash」降级身份写同一套表。任何环节失步,该轮整体回落今天的 legacy 全量路径(降级,不猜)。回滚 = DROP 四张新表 + 关旗,逐字节回到今天。
目标函数排序不变:稳定性 / 扩展性 / 通用性优先,性能是副产品——先问流转对不对,不问快不快。
1. 背景与定位
1.1 来龙去脉
(sess_raw, msgid)复合身份给插件车道做增量快路。1.2 这条线不是什么(防止再次漂移)
1.3 保留的基准裁定(继承自 #5643 正文,全文有效)
目标函数排序、固定链、两处校验点(内核内部状态 + 改写后核形态)、行键 append-only、diff 只按内核管道证据寻址(禁模糊相似)、四件套保护(tripwire / S4 逐行校验和 / 见证要求 / 审计抽验)、客户端压缩纯忽略、P5–P9 五组不变量,全部沿用,不在本文重复展开;与本文冲突处以本节为准并在裁定表(§14)显式登记。
2. 现状架构与三个结构性问题
今天的一条模型请求从入站到出站要经过:
prepare-*适配器 →lane-decisions分轨(legacy 全量 / 增量 plugin-turn / v5 watermark 5%灰度 / D-lane 快照渲染 ≈0%灰度)→ 内核 →coreTo*出站映射。状态住在三个地方:进程内存(lastMessages AST、常驻核数组)、统一 SQLite v11 表族、kstate JSON(经mergeState()水合)。三个结构性问题:sessions.hardMaxBytes(Windows, 0.1.210) #5403 OOM 的直接生产者就是 lastMessages 整包驻留;重启靠水合拼装,拼错即降级或烧会话。刚被撤回的那条线的根病正是这种平行真源。(sess_raw, msgid)对在 ingest 时剥掉,只活在 in-flight 信封里一轮。messages.msgId列存的是 bili/内核自己的规范 id,宿主的原始身份没有任何表承载。「这个元素见过没?」跨进程、跨重启无法回答(P8 要求恒可答),于是每轮都冷启动重新探测。3. 目标架构总览
全貌与 §2 现状架构图逐位对齐,直接对照即可看出改的是全局哪一块、影响范围多大(灰 = 零改动 · 青 = 新增段/表 · 琥珀 = 角色变更 · 红虚线 = 兜底安全网):
六段固定链自身的内部流转 —— 分阶段展开(提交原语 / DDL chip / 降级红门 R1–R4 / 共存路由与回滚灰度):
现状图里的每一块在新架构下变成什么样子 —— 组件迁移总览(底部为三个结构性痛点的一一对应解决锚点):
六个阶段的职责一句话版:
横切两条:红门降级带(§7,任何疑点回落 legacy)与共存路由(§8,每种流量只有一个家)。
4. 六段固定链逐段设计
4.0 第 0 段:入站 · 身份入册(现状中不存在的一段)
输入:原始字节体 + 双信道身份——请求头里的
sess_raw(宿主会话 id 原值)+ 逐元素msgid[]信封。采集直接消费 #5842 已合入的载体 resolver 输出(shim / pi entry-walker / opencode transform 钩子 / codex / cc / gemini 六候选载体),不建第二套采集系统。世界匹配裁决(顺序执行,第一个命中即止):
(sess_raw, msgid)在 L1 表中探测命中 ⇒ 沿用既有账本身份;cohort vs 降级的边界(裁定 I,见 §14):声称具备双信道的 cohort 宿主某轮收不齐 id = 故障,硬拒绝 + 零副作用 + 喂 breaker(baseline §3.2 原样);天生没有 msgid 的非 cohort 宿主走「顺序 > hash」粘滞降级通道,写同一套表(pos 由序位发号);模式每会话粘滞,中途换模式 = 一次显式 resync,禁止静默混用。
L1 表(G 裁定的承载体):
l1_world(sess_raw PK, ledger_id, …),全局可跨重启查询;原值禁截断(P9),sig/fingerprint 只进 warn 诊断流永不入判决(P8/P9)。4.1 第 1 段:协议转换 → 通用核(现成复用)
{openai,anthropic,responses,google}ToCore ↔ coreToX与跨线稳定规范 id(The intermediate message (core) is not protocol-agnostic: switching protocols/models causes identity churn; cross-protoc | 中间消息(core)没有做到协议无关:切协议/切模型制造身份 churn,补齐跨协议映射 #3642)均在 master,零重建。_N,解析散布子集必须复现「整数组调用」的编号上下文,否则出站字节漂移 = 前缀缓存碎掉。散布子集编码的字节级回归钉是 P2 准入条件(连续尾切片情形 v5 已证可行,散布子集是新情形)。message_media引用,base64 不进行表。4.2 第 2 段:改写 / 压缩(内核零改动)
acp-kernel 保持一行不改:折叠判定(projectUnit 共享投影)、四条 prompts、nudge flat-50K 节拍、ref/msgid 永不复用契约。它对外的输出在本设计中定义为结构化事件流:
事件寻址规则沿用 baseline:只按内核管道证据(block 覆盖区间 / ledgerSeq / 帧边界)定位受影响行,禁止任何模糊相似匹配;对不上 ⇒ 该轮不产事件、整轮走 legacy(§8 R2)。
落表时序(以 #5643 附录二为准):第一现场 = 插件端点
POST /__bili/plugin/tool(src/server/admin.ts:797)在当次请求内同步单事务完成事件→表修改;下一轮模型请求只做核对。绕过端点的宿主(dsh native compaction 一类)由 checkpoint 帧签名 + rebase 检测喂同一个表修改例程兜底。端点到落表之间平面挂structural-pending标记;进程重启丢失标记 = 保守判死(fail-safe 方向,§8 R4)。4.3 第 3 段:快照表应用(本提案主体)
提交原语 = 单事务,内含三步:
不变量表(草案 v0.1 起、review 补强后沿用):
ckpt.meta_json 三件套(F+C 裁定的合流):① 内核会话态(CompressionState:blocks/refs/deadRefs/nudge/tokenSnapshot/…)序列化 + 自身校验和——内核没有确定性「事件流→状态」重建入口,序列化随 checkpoint 走是唯一既零改内核又满足 P7(内存只是缓存)的方案;② 覆盖映射(摘要 pos → 被覆盖 pos 区间)——delete/compact 载荷会被 ckpt 吸收,压实之后 decompress/GC 的唯一依据就是这份显式映射;③ S4 聚合校验和。
失效行生命周期(B 裁定建议):inactive 行保留至其覆盖块本身被归档/删除时一并物理清理;反对永不物理清(#3752 单调无界增长是 p1 红线)也反对全局 TTL(GC 窗口和解引用窗口不用额外对齐证明)。
4.4 第 4 段:出站映射
mapEgress= 存活行按 pos 排序取核 ++ 尾窗[K..T)本轮新解析的核,再过coreToX到目标协议族。前缀跨轮字节稳定 ⇒ 前缀缓存友好(这就是目标函数,不是巧合而是结构保证)。4.5 第 5 段:出站
tripwire 运行期形态(J 裁定建议):低比例抽样把出站字节与 legacy 全量路径产物逐字比对(除 time attr)。一致放行;不一致 ⇒ 该会话立即摘回 legacy + 告警。最终护栏防的是「漂移状态下供出陈旧前缀 = 缓存投毒」。
协议卫生:pf-* / 信封类握手头是协议头不是 hop 头,转发上游前剥掉(UPSTREAM_HOP_HEADERS 白名单纪律);本提案引入的任何新握手头同样进白名单管理。灰度期全程 A/B 字节钉在场。
5. 存储 schema(提案骨架,P0 契约定稿)
版本叠加规则:#5855 合并落地它自己的 schema 版本(草案假定 v12)之后,本方案在其上再升一版(v13+);老库升级纯
CREATE ... IF NOT EXISTS加性变更,无数据迁移。DDL 骨架(精确列型留待 P0 契约评审):写模型假设(H 裁定项):默认单进程假设(WAL 天然串行化跨进程写);若要多实例并发写,需附内存视图失效协议(常驻核数组/元数据缓存谁作废谁通知)——P0 契约里二选一钉死。
6. 读路径与消费方切换台账
hydrate 双道:绿道(新表可读且 S4 通过)从 snap_rows+meta 重建读视图;红道(开关关 / 无活跃块 / 表不可读 / 校验失败)原样走 kstate 旧路承接。切换按会话粒度、单向渐进,任何一道失步整轮回退 legacy——与 D-lane #3756 同纪律。
消费方逐个标注(P0 列全清单,此处为主干):
|sub:<fp>)7. 降级红门枚举(命中任一 ⇒ 该轮/该会话整体回落 legacy 全量路径并重新盖戳)
不是红条件的:跨协议族切模型、maxDim 变化、toolArmed 变化、客户端压缩痕迹(纯忽略,只看增量)。把这组边界写成判定函数放进 lane-decisions 矩阵,每种组合正负成对断言(#3617 纪律)。
8. 与既有车道的共存路由(每种流量只有一个家)
lane-decisions 矩阵:每个组合一行,正负成对(触发时触发、不该触发时不触发),新增行可追溯。
9. Rollout 与配置面(owner-gated,命名待 P0 config-surface 章节定稿)
src/knobs.ts(env > file > default)解析;不新增 env 旋钮(env 稀缺面纪律 彻底整治环境变了滥用,除非必要都走配置文件 #2030)。具体 key 名在 P0 PR 的 config-surface 专章申报后定稿。10. 观测面
/__bili/status:attribution 字段扩展新底座维度(哪条链路在服务本会话、平面健康)。11. 测试矩阵
分期测试骨架(正负成对原则全程适用):
CI:docker gate + 求解器无关;hermetic,端口 listen(0)(#360 纪律)。
12. 分期交付(每期为独立 PR,人审关卡标出)
E 裁定建议维持:本期范围到 P0+P1 收手交验收;P2 的字节对等风险集中,独立 PR + 灰度基建齐备后再上。
13. 前置依赖与时序
14. 待 owner 裁定汇总
已在线讨过的(A–E,沿用草案 v0.1 编号)+ 缺口分析新增(F–L)+ 遗留(D3–D5):
15. 风险与诚实边界
16. 参考号速查
#5643(本线起源+定位纠正)· #5854(整线撤回,merged)· #5855(工程基底 re-land,open)· #5842(身份采集 wiring,merged)· #3756(D-lane 快照渲染,将被 K 裁定处置)· #3752(存储无界增长 p1 红线)· #5403(OOM:lastMessages 驻留)· #2432(客户端压缩死螺旋,纯忽略策略的来源)· #3236(共享投影判据)· #3642(跨线稳定规范 id)· #3617(gate 双向断言)· #1104/#1106/#1107(fingerprint 白名单纪律)· #4491/#4834(msgid 身份层级)· #5539(schema v11 FK 子索引)· #155(诚实输出)· #360(listen(0) 端口纪律)· MESSAGE-IDENTITY.md(身份教义)· #5643 定位纠正评论:#5643 (comment)
---- 粘贴结束 ----
ranxianglei commentedon Nov 7, 2026
[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b)
正式提案收到(PR #5873,docs-only)。事实核验全过,附一条实质评审发现 + 文档小疵 + F–L 参考意见。
✅ 事实核验:#5873 open/blocked(6 files,纯文档);#5842(身份采集六车道)✓ 已合入——§4.0「直接复用不建第二套」成立;#5855 仍 open/
behindmaster——§13.1 第一时序依赖属实未解;POST /__bili/plugin/tool端点确在 src/server/admin.ts(≈:798)——附录二第一现场落点准确。Discussion 建帖受 API 限制只能你手动三步粘贴,知悉。🔍 评审发现 1(实质,建议随 G 裁定一并定,P0 DDL 前应解决):l1_world 的 PK(裸 sess_raw) 与 KDD#9 persona fork 纪律冲突。已知实例:dsh auto-review 的
classifyRisk()把同一 conversation id 盖在主会话和辅助 persona 的每次请求上(固定 REVIEW_POLICY system + 每次工具调用前新拼 blob),现行解法是在会话键层用subagentNamespace(id, systemText)fork 成<id>|sub:<fp>。若 L1 以裸 sess_raw 为主键:persona 流量的复合探测要么误采主会话的账本身份(mis-attribution=MESSAGE-IDENTITY.md 定义的最贵失败),要么同一 sess_raw 下要求第二个 ledger_id=PK 冲突。两种结果都不可接受。建议:L1 键改用解析后的会话键(含 fork 命名空间后缀)或(sess_raw, fingerprint)复合键——这正是 #1916/#1307/#1314/#2156 烧过的同一类坑,P0 契约定稿前钉死。🔍 评审发现 2(文档小疵):不变量 iv 写死「行不物理删除」,但 §4.3/B 裁定建议是绑定覆盖块生命周期的物理清理——B 一旦落地,iv 字面自相矛盾。加限定词即可(「覆盖块归档前不删」或「以 B 裁定为准」)。
+ 一条正面观察:§4.1 散布 NEW 编码(P2 准入的脏实现点)在本设计里比旧车道更可解——snap_rows.post_json 存着精确的前缀编号上下文,ClusterCounter 基数可直接从存储行推导(同 v5
rekeyWindowCoresFromCounts的 base-counts 机制),不必从零复现整数组调用语境。建议写进 P2 准入设计注记。F–L 参考意见(非拍板):
立场不变:F/G/B 先行拍板(决定表骨架)+ #5855 合入之前不动工;裁定落地后 P0 可指派给我,工作区干净待命。
docs: add component migration map to §3 — where each current componen…
fix: rename third diagram assets arch-mapping -> arch-migration (refs #…
fix: rename third diagram assets arch-mapping -> arch-migration (refs #…
docs: target arch now shows host lanes & lane-routing ingress band (r…
docs: ship layout-aligned target overview (mirror of current) + stage…
Merge origin/ci-fixes (= master tip 58a8796) into reland-v6 lane
test: reconcile master-side pins with the merged v6 lane