如何读懂dsh-anchored-standard的Durable事件驱动阶段状态机：Resume安全的晋升设计原理
【免费下载链接】dsh-anchored-standardTwo-phase DeepSeek Harness preset: Minimal-aligned bootstrap, then full Standard tools (Project2 98/99)项目地址: https://gitcode.com/gh_mirrors/ds/dsh-anchored-standard
dsh-anchored-standard 是一个两阶段 DeepSeek Harness preset：先用 Minimal 条件锚定会话的首轮轨迹（bootstrap 阶段），再在会话"持久化"后晋升到 Standard 能力（resident 阶段）。本文带你读懂它最核心的机制——Durable 事件驱动的阶段状态机，以及为什么这种"晋升判定"设计在会话重启、恢复（resume）之后依然安全。
两阶段晋升：一张状态转移图
整个机制可以用下面这张图概括（与 README.zh-CN.md 中"工作原理"一节一致）：
用户第一条消息 │ ▼ ┌ 请求 #1 ── bootstrap 阶段 ─────────────────────────┐ │ 工具 : bash + str_replace_editor（Minimal 真实对）│ │ 上下文 : 无 AGENTS.md 摘要、无技能目录提醒 │ └─────────────────────────────────────────────────────┘ │ 首个持久化 tool/call 或 assistant/message ▼ 晋升（promotion）——由持久事件推导，resume 安全 ┌ 请求 #2 起 ── resident 阶段 ────────────────────────┐ │ 工具 : bootstrap 对 + 发现工具 + 模型已解锁工具 │ │ 上下文 : 恢复常规注入 │ └─────────────────────────────────────────────────────┘| 阶段 | 可见工具 | 自动注入上下文 | 退出条件 |
|---|---|---|---|
| 🧭 bootstrap（引导） | 仅bash+str_replace_editor | 全部关闭 | 出现持久晋升信号 |
| 🚀 resident（驻留） | 引导对 +dev_tool_search/skill_search/skill_load+ 已解锁工具 | 恢复 | 遇到compaction/end时回退 |
注意：状态机的"状态"不是某个内存变量，而是由三类持久会话事件推导出来的：
tool/call（工具调用事件）assistant/message（助手回复事件）compaction/end（上下文压缩边界事件，会让状态机"回退"）
为什么选择"从持久事件推导"而不是记在内存里
这是整个设计最值得一读的地方。核心实现在 shared/compaction-epoch.mjs，它导出一个只有两个方法的追踪器：
| 方法 | 作用 | 行为 |
|---|---|---|
status(agent) | 查询当前阶段 | 内存里没有记录时，冷启动全量扫描会话事件日志一次，然后 O(1) 命中 |
observe(session, event) | 增量喂入事件 | 每收到一条session/event就地更新，无需再扫描 |
这种"先冷扫描、后增量"的组合带来两个关键性质：
- 重启安全（resume-safe）：进程重启后内存为空，但冷扫描会重放同一份事件日志，得出的阶段与重启前完全一致——状态从来没有"丢失"，因为它根本不被存储，而是被重新推导；
- 零冗余：晋升判定按会话记忆化，每会话每进程只完整扫描一次。
💡 一句话总结设计哲学：事件日志是唯一的真相来源（source of truth），阶段状态只是它的一个投影。这也是术语表里 README.zh-CN.md 中"持久（durable）"的含义——已写入会话事件日志。
兼容细节：扫描时优先使用session.snapshotEvents()（新版 harness 的冻结副本），旧版自动回退到session.events，所以新旧 harness 都能加载，见 shared/tool-bootstrap.mjs。
晋升触发器：promoteOn 的三档语义
状态机"什么时候晋升"由promoteOn配置决定，在 preset/agent.cordis.yml 的两行（context-gate与tool-bootstrap）中都必须保持一致：
| 取值 | 晋升信号 | 适用场景 |
|---|---|---|
either（默认） | 首个tool/call或首个assistant/message，先到者为准 | 基础模式 |
tool-call | 仅tool/call | 兼容原行为 |
assistant-message | 仅assistant/message | 零工具锚定变体 |
📌为什么要默认either？如果只用tool-call，模型首轮只回了文字、没调工具，会话就会永远困在 bootstrap 阶段——这就是所谓"陷阱"。改用either后，请求 #1 恒见 bootstrap 目录、请求 #2 恒见 resident 目录，纯文字首答也能在第二轮解锁，见 shared/tool-bootstrap.mjs 中PROMOTE_EVENTS的定义。
还有一个容易被忽略的细节：工具执行失败也会晋升——因为tool/call事件在调用发出时就已经持久化了，与执行成败无关。
Epoch 边界：compaction 是"第二次的第一个请求"
阶段状态机带有一个epoch（纪元）概念：compaction/end事件会把阶段回退到受控阶段，之前的晋升信号全部"作废"，只有边界之后出现的新信号才能重新晋升。
assistant/message(seq=1) ── 晋升 ✅ compaction/end(seq=3) ── 边界=3，promoted 复位为 false tool/call(seq=2，边界之前) ── 不计数（旧信号失效） assistant/message(seq=4) ── 边界之后，重新晋升 ✅为什么需要回退？因为压缩会重写模型可见面：之前的对话塌缩成一条合成摘要、工作区指令基线从零重新注入——压缩后的第一个请求，本质上就是"第二次的第一个请求"，拥有同样的首 token 条件，因此要重新走一遍锚定控制，源码注释在 shared/compaction-epoch.mjs 中有完整说明。
工程实现上，回退就是把{ boundary, promoted }中的边界更新为最新compaction/end的 seq，promoted置 false；多次压缩时最后一条边界获胜。这些规则被 test/compaction-epoch.test.mjs 逐条覆盖，例如"只有边界之后的信号才计数"与"跨边界立即翻转阶段"两个用例。
回退后会话并非裸奔：tool-bootstrap行支持compactionTools（preset/agent.cordis.yml 中配置了read、write、edit等核心工作集），让"任务进行到一半"的模型面对一个小目录继续干活，而不是直接放开完整 Standard 目录。
三个插件消费同一个阶段状态
状态机是共享基础设施，三个插件各自createEpochPromotion一份、各自订阅session/event，但消费方式不同：
| 插件 | 消费阶段做什么 | 降级策略 |
|---|---|---|
| 🚪 context-gate.mjs | 未晋升时关闭两条统一注入路径：清空装配期的 runtime-context 贡献、pre-step 只保留 claimed 消息批次 +allowKinds白名单；晋升后恰好差分注入一条全新快照消息（"首轮极简、二轮注入"） | 出错时保留全部消息，绝不吞上下文 |
| 🧰 tool-bootstrap.mjs | 未晋升时把工具目录裁剪为 bootstrap 对；晋升后裁剪为 resident 集（引导对 + 发现工具 + 经dev_tool_search解锁、且从持久tool/call事件推导出的工具名） | 引导工具缺失时降级为完整目录并一次性告警 |
| 💬 instruction-hint.mjs | 晋升后每会话恰好一次注入"存在指令文件"的提示；防重复靠扫描持久事件日志而非内存标记，因此进程重启不会二次注入 | 提示注入失败时跳过，绝不影响会话 |
三者共同遵守一条防御式默认：status()对 undefined 的 agent/session 一律返回promoted: true——宁可全开，也不要把一个偶发错误放大成"卡死整个会话"，见 shared/compaction-epoch.mjs。
子 agent 与 includeSubagents：状态机的一个旁路
默认情况下，子 agent（delegationDepth > 0）被视为已晋升——它的首个请求就能用工具，避免委托链路整体被锚定拖慢。如果希望子 agent 也完整走一遍 bootstrap 阶段（它们的"首个回复或工具调用"同样会晋升），需要在context-gate与tool-bootstrap两行同步设置includeSubagents: true（基础模式已默认如此，注释见 preset/agent.cordis.yml）。
⚠️ 记住"两行同步"这条约定：任何一行漏配，工具目录和注入控制就会各说各话。
快速验证：跑测试与看 JSONL
不用启动 harness 也能读懂并验证这套状态机：
- 零依赖测试套件：
npm test（脚本定义见 package.json），其中 test/compaction-epoch.test.mjs 是最小可执行的状态机说明文档——每个用例就是一个状态转移断言； - 实机验证时导出会话 JSONL，按 README.zh-CN.md 中"验证加载"清单检查
request/header事件：首请求tools恰好为["bash", "str_replace_editor"]、晋升后 header 出现 resident 目录、compaction/end之后 header 再次回到受控目录，即为状态机工作正常的三个信号。
各模式目录内的插件副本由 scripts/sync-modes.mjs 从shared/物化生成——读状态机源码时认准shared/为唯一源，模式目录里的同名文件只是副本。
小结
📌 dsh-anchored-standard 的阶段状态机值得借鉴的正是三点设计：
- 状态不落盘、不驻留内存，而是从 Durable 事件日志推导——resume 与进程重启天然安全；
- 晋升与回退都只认事件（
promoteOn信号晋升，compaction/end回退），冷扫描保证任意时刻可重建； - 消费方与状态机解耦——context-gate、tool-bootstrap、instruction-hint 各自订阅、各自降级，任何一环出错都不阻断会话。
如果你想继续深挖，建议按此顺序阅读源码：shared/compaction-epoch.mjs（80 行，状态机本体）→ test/compaction-epoch.test.mjs（行为规格）→ shared/tool-bootstrap.mjs 与 shared/context-gate.mjs（两个主要消费方）。
【免费下载链接】dsh-anchored-standardTwo-phase DeepSeek Harness preset: Minimal-aligned bootstrap, then full Standard tools (Project2 98/99)项目地址: https://gitcode.com/gh_mirrors/ds/dsh-anchored-standard
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
