会话身份是怎么定位的：压缩状态的归位机制

billion-context（ranxianglei/billion-context）架在编程助手与模型 API 之间，用 acp-kernel 压缩重写 Anthropic/OpenAI 流。它最容易被误解的地方不在压缩算法，而在压缩状态挂在哪把钥匙上：钥匙错了，用户看到的就是「刚压完又从头开始」。这篇只讲身份与归位。

为什么用客户端给的会话值，而不是自己造一个

代理以客户端自己提供的会话值为键隔离压缩状态（原样照搬，见 src/session-id.ts）。三个刻意不做的事：

• 不哈希——客户端给什么就用什么。

• 不掺协议维度——换 Anthropic / OpenAI 线格式不该算两个会话。

• 不掺上游与 API key 维度——它们会在会话中途变化，真拿它们做 key，恰好会在用户继续对话的那一刻把状态弄丢（#280/#286）。

另外，该 id 只在代理内部使用（状态存储、持久化、UI 标签），绝不上送；上游粘性路由只转发客户端本来就提供的身份值（例如 body 里的 session_id 以 x-session-id 上送），绝不自行合成。

取值优先级链：从插件 header 到 body 字段

多个来源同时存在时，按顺序取第一个命中的：

发不发信号，决定了客户端落在链条哪一层：Codex、OpenCode、Claude Code 与经插件的 omp 都能命中前四层，只有 pi 裸跑什么都不发。想对照同类插件的中文清单与安装形态，可以看 完整插件清单与汉化避坑指南。

无 header 的客户端：匿名前缀亲和

客户端完全不发会话信号时，代理不从外部要 id，而是从重放的历史本身解析会话（src/prefix-affinity.ts，#309）：只有当请求历史从第 0 条开始逐字节复现某已存会话的消息链时，才重新挂回该会话；否则获得一个确定性的新 pfa-… 会话。后果（#1262）：恢复的对话能重新挂回自己的会话（包括代理重启后，#499）；但开头相同的新任务不会继承另一个会话的 block——它拿全新会话，历史一旦分叉就彻底独立。

完全没有信号时：显式 400，而不是静默撞状态

连前缀亲和的锚点都拿不到时，请求会被显式 400 拒绝，而不是静默与他人状态碰撞——宁可当场报错，也不要让两个不相关的人共享同一份压缩状态。

派生会话：只读血缘与深度上限

当 agent 派生子会话（subagent 或 fork，从空历史起步、不重发父内容）时，它会在出生时上报血缘：身份注册携带父会话 id（parentConversationId），代理据此在子会话上记一条只读链接 derivedFrom（#1333、#1362）。此后 decompress 与 search_context 对子会话没见过的内容沿父链回退（带环检测、深度上限 8）；任何东西都不复制进子会话，父会话也绝不被修改。容易搞反的一点：claude/codex/dsh 在这里不需要任何父信号——它们的子 agent 共享同一个会话 id，或根本没有子会话概念。

机制边界

无 header 的多 agent 场景。 现象是几个 pi 裸跑的 agent 把压缩状态串在一起，或者干脆收到 400；原因是它们不发信号、只能靠匿名前缀亲和，而前缀亲和要求历史从第 0 条逐字节复现，两个任务只要开头相同、中途分叉就各走各的。解法是优先装客户端插件（为每个会话盖稳定 id），或每会话显式传 x-acp-session。

更新了但没生效。 现象是弹过通知说装了新版本，行为却和旧版一样；原因是启动时与每 3 分钟检查 npm 新版本，发现后原位安装 + 打印通知，重启 bili 才生效，可选自重启（–auto-restart-on-update / ACP_AUTO_RESTART_ON_UPDATE=1 / 配置 autoRestartOnUpdate）默认关闭，进程落后于磁盘安装即 stale。解法是用这条命令把它变成可监控字段：

返回 {version, diskVersion, stale, autoRestartOnUpdate, advisory, inFlight}，stale 为真即「装好的版本还没跑起来」。

被强制降级安装。 现象是某天版本号反而变小、像被回滚。原因是严重缺陷公告独立于自动更新（#1481）：即使关掉 autoUpdate，代理也按同样 3 分钟节奏轮询伴生 npm 包 billion-context-advisories，命中受影响版本范围就强制安装靶版本，而靶版本可以比当前更旧。源码检出与宿主托管的安装会被拒绝并给手动升级指引；该检查默认 fail-open，公告源不可达只警告、不阻断流量。要停用可设 advisoryCheck: false 或 BILI_ADVISORY_CHECK=0。

总结

压缩状态归位遵循一条简单原则：钥匙由客户端给，代理原样照搬、不哈希、不掺会中途变化的维度，取不到信号时显式拒绝而不是撞状态；想对照同类插件的中文清单与安装形态见 完整插件清单与汉化避坑指南。

适合与不适合

适合：长期跑多轮 agent 会话、需要压缩状态稳定归位的团队；主力客户端是 Codex、OpenCode、Claude Code、omp 这类会主动发会话 id 的工具的人；需要在 subagent / fork 之间继承压缩上下文、又不污染父会话的用法。

不适合：pi 裸跑又不装客户端插件、也不传 x-acp-session 的多 agent 场景，它会串会话或直接 400；把「早期」当「成熟」、要求生产级稳定性的线上系统——项目自述真实模型集成测试还是下一里程碑；不希望被强制降级公告打扰、又不肯关 advisoryCheck 的机器。

标签：亿级上下文压缩、DeepSeek Harness、会话身份、上下文压缩、dsh 插件

本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。