[test][e2e] dsh 缺少端到端 / docker 模拟宿主回归测试（pi 有完整 harness）

[ranxianglei]

来源: ranxianglei/billion-context-pi#305 对照分析 dsh 与 pi 的测试覆盖差距时发现

现象

billion-context-dsh 目前只有单元测试（tests/*.test.ts + tests/kernel-upstream/search.test.ts），没有任何端到端（e2e）/ docker 模拟宿主的回归测试。CI（.github/workflows/ci.yml）只跑 typecheck → test → build → dist-drift-check。

而 billion-context-pi（本仓）有一套完整的 e2e harness，能驱动真实宿主 headless + 脚本化假 LLM，并对持久化后的 ACP state 做断言：

• Dockerfile.e2e：FROM node:22-slim，用 devDependencies + lockfile 钉住 Pi host 版本，npm ci、build dist，ENTRYPOINT 跑 node ./scripts/e2e/run-e2e.mjs。
• .github/workflows/e2e.yml：job e2e（matrix ubuntu + windows，node 22）跑 node scripts/e2e/run-e2e.mjs；job docker build Dockerfile.e2e 并 docker run --rm。
• scripts/e2e/：run-e2e.mjs、fake-llm-server.cjs（OpenAI 兼容 SSE，:8400，按 scenario 驱动多轮、解析 compress/decompress/search 的 tool_use）、e2e-extension.js、verify.mjs（断言 block 数 / nudge baseline / 压缩统计 / session-log 工具调用序列），以及 scenarios/01..05-*.json（basic-compress / batch-compress / nudge-triggered / compress-then-decompress / multiple-compressions）。每个 scenario 使用独立的 Pi HOME（models.json→假 provider、acp.json autoUpdate:false）。
• package.json 带 "e2e" script。

为什么重要

dsh 的核心价值是「durable-surface」压缩模型：seq-as-ref、nudge 以 user/message 事件 append、shadow 而非二次总结。这类跨轮、依赖真实宿主事件流的正确性，纯单元测试很难覆盖，尤其：

• emergency / normal nudge 在真实 agent/pre-step 循环里的注入节奏（正是 [compression] emergency nudge 无上限逐 step 重注入，且缺少 compress attempt 断路器 #108 那类反馈环，只有跑起来才看得见）；
• compress/decompress/search 与宿主 tool_calls/tool 响应的严格配对（provider 会拒绝 assistant tool_calls 块后紧跟非 tool 消息）；
• 跨版本 session.jsonl.zstd 回放（session-events 兼容层）。

pi 的 e2e 就是为捕获这些宿主集成回归而存在的；dsh 缺这一层，等于把宿主集成回归完全交给人工。

建议

为 dsh 移植一套等价 harness：

1. 一个 fake-llm-server（OpenAI 兼容 SSE）按 scenario 驱动多轮对话，并发出 compress/decompress/search 的 tool_use；
2. 驱动真实 dsh/cordis 宿主（@deepseek-ai/dsh-agent）headless 运行并挂载 AcpCompactionEngine；
3. verify 步骤断言持久化 state：block 数、nudge 注入次数受 [compression] emergency nudge 无上限逐 step 重注入，且缺少 compress attempt 断路器 #108 cap 约束、压缩统计、日志中工具调用序列合法；
4. Dockerfile.e2e 钉住 @deepseek-ai/* + cordis + Node major，并在 .github/workflows/e2e.yml 加一个 job 跑它。

可先落地最小可行集（1 个 basic-compress scenario + docker job）把宿主集成纳入 CI，再逐步补齐其余 scenario。

[ranxianglei]

我来协助看一下这个问题,请分析并回复处理结果。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

结论先行

issue 成立,且可行性已用可运行的 PoC 验证完毕。建议按「方案 B」(进程内程序化 harness + 宿主官方 mock LLM 服务器)落地,而不是完整移植 pi 的「子进程 CLI + 自写假服务器 + Docker」harness。方向确认后我再开工提 PR。

1. 事实核查与查重

• 现状描述准确:仓库只有单元测试(tests/*.test.ts + tests/kernel-upstream/),CI(.github/workflows/ci.yml)只跑 typecheck → test → build → dist-drift。单测用 detached Session.create 模拟宿主事件,不经过真实 agent 循环、pre-step 瀑布、工具分发和 wire 协议——issue 点名的三类风险(nudge 注入节奏、tool_calls 严格配对、跨版本回放)确实全部落在这层盲区里。
• 查重:检索了现有 issue/PR(含已关闭)中 e2e / docker / harness / 宿主集成相关主题,无重复项。

2. 关键发现:DSH 自带官方 e2e 设施,不用从零造

• @deepseek-ai/dsh-llm-mock-server(npm 已发布,有与我们 devDep 基线一致的 0.1.0-rc.6 版):OpenAI 兼容的 SSE mock 服务器,按脚本序列驱动多轮对话——每个请求消费一个预置行为(success、tool_call_success,以及 connection_reset / rate_limit / context_overflow / malformed_json 等错误注入)。库入口 startMockLlmServer 可嵌入测试,并捕获每一个发出的 wire 请求体(断言 nudge 是否真的进了 HTTP 请求,靠它)。
• 宿主自己的 headless 测试就是程序化搭 Context:new Context() → SessionProjectionRegistry → AgentLoop → 真 DeepSeek 适配器(通过 DEEPSEEK_BASE_URL 指向 mock 服务器)→ 按需挂 TokenMeter / compaction 插件;驱动用 agent.followup(...),断言用 session.events。宿主自己的 compaction.e2e.ts 断言的形状(start/end 配对、summary.shadowedSeqs、replace-op 节点)与我们的需求几乎一致。
• 所需包在 npm 上都有 rc.6 线版本,无需 fork 宿主仓库。

3. PoC 证据(已实际跑通,10/10 断言通过)

我在本地一次性工作区搭了最小 harness:真实 AgentLoop + 官方 mock 服务器 + 本仓 dist/index.js 以标准插件方式挂载为 CompactionEngine(stock 配置,仅显式 modelContextLimit: 2000 + autoCommand: false)。场景:3 轮预热问答(每轮 ~5.2K 字符)+ 第 4 轮由脚本让模型对最老一轮对话调用 compress。结果:

• nudge 精确注入 1 次(5 个 wire 请求中的第 4 个,即触发压缩那一轮的 pre-step),tier=EMERGENCY——nudge 节奏问题([compression] emergency nudge 无上限逐 step 重注入，且缺少 compress attempt 断路器 #108 那类反馈环)第一次有了可断言的对象;
• compress 走真实工具分发,落盘出完整 durable 事件序:compaction/start → compaction/summary → replace-op user/message → compaction/end → tool/result → compaction/prune(prune 把 compress 调用/结果对整体影子化,保持 wire 干净);
• summary.shadowedSeqs 精确指向被压缩消息,shadowedTokenCount=6689(宿主词汇计价、非负)——compress 影子价格用错估算器：宿主 token-meter messageTokens 被打成负数，中文 session 压缩后永久卡死 #54/[bug] 图片区间的压缩影子价误用路由重定价 node.tokens 而非 heuristicTokens → 宿主 token-meter 投影扣负（#54 残留通道） #103 那类 brick-session 回归从此可以红灯;
• 压缩后wire 投影的 tool 配对保持干净(log 里 compaction 事件交错插入后,发往 provider 的请求仍无孤儿 tool 消息、无错位)——provider 400 风险有了直接回归保护;
• 压缩后对话正常继续。全程确定性输入(固定文本 + 固定字节分块),可直接进 CI。

4. 方案对比(给出明确建议)

	A:移植 pi 式 harness(issue 原案)	B:DSH 惯例进程内 harness(建议)
假 LLM	自写 fake-llm-server.cjs(OpenAI SSE)	直接用官方 dsh-llm-mock-server(或后续补一个 ~100 行薄壳,见下)
宿主驱动	子进程跑 dsh --profile headless,解析磁盘上的 session.jsonl.zstd	进程内建真实 AgentLoop(同一份运行时代码路径),断言 session.events + 捕获的 wire 请求
环境钉住	Dockerfile.e2e 为主	CI job 为主,Docker 二期(价值仅剩 Node major/依赖环境钉住)

选 B 的理由:① 宿主官方提供了 mock LLM 服务器,不必再维护第二套(pi 自写是因为它的宿主没有这个设施);② 进程内更快、更确定,直接拿到事件流和 wire 请求,免去「子进程 + zstd 解包 + 磁盘解析」这层易碎间接;③ 与宿主维护者自己的 e2e 形态一致,将来宿主升级对齐成本低;④ CLI/profile-YAML 组合层是宿主的职责面(宿主自带 e2e 套件覆盖),我们的契约面是 CompactionEngine seam,B 直接打在这个面上。A 的优势是进程级保真度更高,但对我们这层的边际收益小。

5. 已知限制(影响场景设计,如实说明)

• 官方 mock 服务器的 toolName/toolArguments 是每服务器实例一份:单个 scenario 内只能脚本化一种工具调用形状。「先 compress 再 search_context」这类多工具场景要么拆成多个 scenario,要么我们自写一个薄的 OpenAI 兼容假服务器。建议 MVP 先用官方服务器 + 一 scenario 一工具,确需完整复刻 pi 的场景矩阵时再补薄壳。
• npm prerelease peer 解析坑(PoC 实测):lockfile 之外的传递 peer 会被解析到最新 prerelease(rc.8 线)引发级联 ERESOLVE,必须把整个闭包显式钉到 rc.6 线并随 PR 提交解析后的 lockfile(与 peerDependencies "dsh-compaction@^0.1.0-rc.6" 永远匹配不了 0.1.1-rc.2（semver 预发布元组规则）— 最新 DSH 上装不上 #68 同类问题)。已有可行解法。

6. 建议的 MVP 范围(待拍板)

1. scripts/e2e/:可复用 harness(程序化 Context 装配)+ scenarios/*.json(行为序列 + 断言参数)+ verify 断言;
2. 首批 3 个 scenario:basic-compress(PoC 已验证)、nudge-rhythm(受控压力下断言 nudge 次数/tier)、compress-then-decompress(decompress 从 log 还原原文);
3. package.json 加 "test:e2e";.github/workflows/e2e.yml 新 job(ubuntu,node 22,主 ci 之后);Docker job 放二期;
4. 文档同步:README/docs 说明 e2e 覆盖范围与本地运行方式,AGENTS.md 模块图补 e2e 层。

覆盖到的回归:nudge 节奏、durable 事件顺序、wire 配对安全、shadow-price 非负——全部变成 CI 红灯项。

请确认:是否同意方案 B + 上述 MVP 范围?同意我就开工(分支 2026-09-06_e2e-harness,commit 前缀 (test));若希望一步到位含自写假服务器的完整 pi 场景矩阵,说一声我扩大范围。

[Tyan66666]

同意

[ranxianglei]

挂了？继续

[ranxianglei]

🤖 Powered by ework · qwen3.8-flash-next-w4a16-p294

处理完成 — PR 已开: #131

(直推主仓 403 — 运行凭属 ranxianglei 账号,正常防护;分支 2026-09-07_e2e-harness 推 fork,跨仓 PR 按规范流程。)

落地内容(拍板方案 B: 进程内真实宿主组装)

• scripts/e2e/harness.mjs — 进程内组装真实 DSH 宿主: cordis Context + 官方 agent-loop + 发布版 DeepSeek 适配器 + token meter,挂载本引擎(从打包产物 dist/index.js,即用户安装同文件)作为压缩后端 — 生产同注册路径。
• scripts/e2e/fake-llm.mjs — 最薄脚本化 OpenAI 兼容 SSE 服务:逐轮回放(纯文本 / compress/decompress 工具调用),{{U1}} 占符渲染 live seq(scenario JSON 不钉宿主 seq 布局),报 honest usage(引擎 nudge 用量以 provider 回报的 prompt size 为锚 — 假服务报常数 3 时 nudge 全盲,首轮踩过的陷阱)。
• scripts/e2e/run-e2e.mjs + scenarios/*.json — 3 场景(basic-compress / nudge-rhythm / compress-then-decompress),17 项断对持久化事件日志 + 捕获在线协议: compaction 起止配对、summary 遮蔽请求区间、shadowedTokenCount ≥ 0(compress 影子价格用错估算器：宿主 token-meter messageTokens 被打成负数，中文 session 压缩后永久卡死 #54 非负折叠)、durable replace 节点落、最终线请求严格 tool 配对(provider 400 面)、nudge 注入节奏(EMERGENCY 命中;节奏场景小历史无注入/不每轮)、end 后对话继续、decompress 结果含原始文本(日志重建路径)、compress 结果报 tier。
• package.json — npm run test:e2e;+18 @deepseek-ai/* devDep 钉 0.1.0-rc.6 线(全传递 peer 闭包 — 不在 lockfile 的 peer 被 npm 解析到最新 prerelease 级联 ERESOLVE,peerDependencies "dsh-compaction@^0.1.0-rc.6" 永远匹配不了 0.1.1-rc.2（semver 预发布元组规则）— 最新 DSH 上装不上 #68 同类),dsh-token-meter caret→exact(可复测基线)。
• .github/workflows/e2e.yml — 新 e2e job(node 22, npm ci→build→test:e2e)跑每 PR。
• 文档同 PR: 新 docs/e2e-harness-design.md(方案 B/A 取舍、honest-usage 陷阱、闭包钉、二期: 官方 mock server/Docker/错误注入)+ README(zh/en)开发块 + CONTRIBUTING + AGENTS.md(模块图/命令/钉标准)+ docs 索引。

验证

• npm run typecheck / npm test(208 绿)/ npm run build 全绿,dist 无漂移。
• e2e 全绿(Node v22.23.2, 17/17 PASS): basic 场景 EMERGENCY nudge 在 compress 轮,落 compaction/start → summary(shadowedSeqs [4,12], shadowedTokenCount 4518) → replace 节点 → end → prune(隐藏 compress 对);节奏场景使用率跨 70% 线恰在大历史轮落地(投影锚,滞后一轮);decompress 由日志重建原始文本、无新 compaction 事件。

待 owner 两项(非阻塞)

1. 可选: 把 e2e 加 main 分支保护 required checks(当前 PR 必 ci+pr-title;workflow 已上报状态,CONTRIBUTING 已注明)。
2. 二期(记在 design doc,未实现): 官方 @deepseek-ai/dsh-llm-mock-server 替换(需上游 per-turn 工具参数化 — 现全局单工具形状限制)、Dockerfile.e2e + windows matrix、CLI/profile 组合层 + session.jsonl.zstd 回放、错误注入行为(断流/429)。

[Tyan66666]

我看 main 上面的 ci 比没跑完是怎么回事

[Tyan66666]

acp_status 现在能不能查？——不能，但架构上完全可以

现状：3 个场景里没有一个调用 acp_status，返回内容的正确性零覆盖。但 harness 的两个 oracle 恰好都能支撑这类断言，不需要改框架：

1. 事件日志路径：DSH 的 tool/call / tool/result 事件是逐字落盘的（(feat) 容器化 headless E2E 集成测试套件：并行分道 + smoke/full 分集 #128 的设计文档也确认了这点），所以加一个“模型调 acp_status”的场景，就能对 tool/result 的 data.message 做结构断言。
2. wire 路径（更严格的 oracle）：server.requests 抓的是完整请求体，body.messages 里就有 tool 结果消息——这是模型真正看到的内容，比事件日志更接近“正确性”的本质。

具体可以加的断言（都对应 AGENTS.md 里的实战规则）：

• acp_status 结果含 CONTEXT BREAKDOWN / COMPRESSED BLOCKS 段（证明走的是 kernel buildStatusReport，不是手搓格式——规则 9）
• 压缩后块表里有 b1 行，且带 Checkpoint seqs 行（issue T2 蒸馏可用性缺口：acp_status 对摘要节点失明，checkpoint seqs 只在 nudge 注入行存在（三失败模式） #60 P2 的蒸馏入口）
• summary 节点不被双计（规则 9：messages 喂给 buildStatusReport 时要排除 checkpoint 节点——现在没有任何测试在端到端层验证这个）
• nudge 表行含 [tool X% | text Y%] 份额和 oldest-first 排序（规则 3）
• Surface: seq 锚存在

顺带指出一个更根本的覆盖缺口

比 acp_status 更要紧的一条现在也缺：压缩后发出去的请求内容没有被断言。现在的 wirePairing 只看角色顺序，但“replace 真的把原文从请求里换成了 summary”这件事没有被直接验证——正确的断言应该是：压缩后的下一个 wire 请求里，
包含 summary 文本、且不再包含被遮蔽的 filler 原文（Note 0: the pruning section... 不应再出现在 body.messages 里）。这是 durable surface model 的端到端本质，一句话就能断，值得加。

建议的补覆盖顺序（如果做后续 PR）

1. 投影内容断言：压缩后请求体 = summary 在、原文不在（最强的一条，成本低）
2. acp_status 场景：压缩 → 调 acp_status → 对 tool/result 做结构断言（块表、Checkpoint seqs、kernel 段落头、无双计）
3. nudge 表结构：范围表行数、份额标记、排序
4. 负面断言：acp_status 的 window 语义行（estimated context/context window）不出现在模型工具里（规则 9 明确说这是 /acp 的人用职责）

框架本身（fake LLM、seq 占位符、双 oracle）不用动，纯粹是往 scenarios/*.json + run-e2e.mjs 加场景和检查。唯一要留意的是上回发现的 hang bug 得先修（server.close() / process.exit），否则每加一个场景 CI 就多挂 6 小时。

[ranxianglei]

应该是挂了 不知道为啥这个会话总是挂

[ranxianglei]

🤖 Powered by ework

[bot] 汇报进度 —— 先说结论：CI 那个 e2e 挂起已定位并修好，commit 1284974 已推到 PR #131。

CI e2e 挂起根因（三个缺陷叠加）

1. fake-llm.mjs 的 close() 调用了未定义的全局 close（应为 server.close），一调用就抛 ReferenceError；
2. harness.mjs 的 runScenario 全程没调用 server.close()，fake LLM 的 http server 一直开着；
3. run-e2e.mjs 成功路径只 console.log('e2e PASS') 就 return，没有显式退出。

三者叠加 → 事件循环被 http server 句柄一直占住 → 所有断言跑完后进程不退出 → CI job 挂到 6 小时 Actions 超时（就是你看到的"没跑完"）。

修复（1284974）：close() 改 server.close + closeAllConnections() 断 keep-alive；runScenario 在 ctx.fiber.dispose() 后 await server.close()；main() 末尾显式 process.exit(0/1)，每个 scenario 套 try/catch，异常也走清理不挂起。
本地验证：3 场景 17 断言全过，整个进程 约 2 秒干净退出（之前会一直挂）。
CI 状态：新 commit 刚推上去，check-runs 还没登记，几分钟内出结果。

关于"会话总是挂"：如果你指的是我这个 bot 工作会话卡住被强制重启（刚才 34 分钟无输出被重启）——那是另一层问题，不是 e2e CI 的挂起。我这边看不到 daemon 侧完整日志，但已把所有网络/工具调用都加了严格超时（--max-time / 命令 timeout），避免再出现长时间无响应的调用把会话拖死。如果你指的是 CI job 挂起，那就是上面已修的那个。

麻烦看下新 commit 的 CI 结果，e2e 若还异常我再深挖。

[ranxianglei]

🤖 Powered by ework

[bot] 两件事都处理完了，都推到 PR #131（2026-09-07_e2e-harness）。

① CI 没跑完（你的第一个问题）
是 e2e job 挂起了（ci/pr-title 都 success，只有 e2e 一直 pending 到被 cancel）。根因是 3 个缺陷：假 LLM 服务的 close() 调了未定义的全局 close、harness 跑完没 server.close()、runner 成功路径只 console.log 不退出——事件循环被 http server 句柄拖住，CI 里就一路挂到 GitHub 的 6 小时超时。已在 commit 1284974 修掉（close()+closeAllConnections()、process.exit 显式退出、每 scenario try/catch 不连环挂）。本地整套现在 ~2.5s 跑完并干净退出。

② 你指出的 4 个覆盖缺口
全部按你列的顺序实现（commit 28dea0f），框架没动（fake LLM / {{U1}} 占位 / 双 oracle 都原样），纯粹是往 scenarios/*.json + run-e2e.mjs 加场景和检查：

1. 投影内容断言（最强那条）：compress 之后的下一个 wire 请求体里含 summary 文本、且被遮蔽的原文已消失（Note 0: the pruning section... 不再出现在 body.messages）——durable surface 的端到端本质，之前 wirePairing 只查了角色顺序。
2. acp_status 场景：compress 后模型调 acp_status，断言 tool result 是 kernel buildStatusReport（含 CONTEXT BREAKDOWN / COMPRESSED BLOCKS，rule 9 非手搓）、块 b1 行 + Checkpoint seqs 行（蒸馏入口，issue T2 蒸馏可用性缺口：acp_status 对摘要节点失明，checkpoint seqs 只在 nudge 注入行存在（三失败模式） #60 P2）、Surface: seq 锚、Nudge: 决策行。
3. nudge 范围表结构：表头 oldest first、行带 [tool X% | text Y%] 份额、行按 surface seq 升序（rule 3）。
4. 负面断言：acp_status 模型工具里不含 estimated context / context window（窗口语义是人侧 /acp 的职责，rule 9）。

验证：断言从 17 项增到 41 项（4 场景），41/41 PASS（~2.5s，进程干净退出）；typecheck / 214 单测 / build / test:e2e 全绿。文档同 commit 同步（design doc 场景表 + 计数、AGENTS.md 模块图）。

PR #131 已更新，CI 会重跑（这次 e2e 不会再挂）。