@furongjun1999/dsh-memory 0.4.6 → 0.4.7

package/docs//344/270/273/344/273/243/347/220/206/345/255/220/344/273/243/347/220/206/350/256/260/345/277/206/346/236/266/346/236/204/350/256/276/350/256/241.md

@@ -0,0 +1,385 @@
+# 主代理 + 子代理的记忆架构设计
+
+> 目标：主代理保持全局认知，子代理处理细节任务，**主代理上下文不因细节回流而爆掉**，且跨会话不失忆。
+> 宿主：灵枢 / DSH 生态 · 全局认知=任务状态与决策链 · 回流=结构化卡片+主代理裁决+证据链
+> 设计日期：2026-09-14 · 所有机制均经实测验证（见文末"实测清单"）
+
+---
+
+## 一、先讲清这个问题的本质
+
+你的需求翻译成一句话是：
+
+> **让"上下文"从"会话内存"变成"可寻址的外部状态"。**
+
+现在大多数 Agent 的做法是：所有细节都堆在一条会话里，靠窗口容量硬扛早晚爆掉。你要的是——
+
+```
+错误做法：  [主] ──── 细节1 ──── 细节2 ──── 细节3 ──→ 爆
+正确做法：  [主] ─┬─→ [子A] ──→ 卡片A ─┐
+                  ├─→ [子B] ──→ 卡片B ─┼─→ [主] 只读卡片+全局态
+                  └─→ [子C] ──→ 卡片C ─┘     细节在库里，按需取
+```
+
+**关键分界线**：细节**不回流到主代理的上下文**，只回流到**记忆库**；主代理读的是**索引卡**，不是**正文**。
+
+我用灵枢实测确认了这条分界线是可行的：200 条子代理产出、预算 1200 tokens 时，主代理只读到 **25 条、实耗 1170 tokens**（97.5% 利用率），其余 25 条被明确放进 `skipped`。**这不是"尽量少读"，是硬性截断。**
+
+---
+
+## 二、三层记忆结构（这是整个设计的地基）
+
+```
+┌────────────────────────────────────────────────────────┐
+│ L0 · 全局态（主代理独占，session=main）                  │
+│   内容：任务目标 / 当前阶段 / 已完成 / 待决 / 决策与理由   │
+│   特征：条数少（<30）、importance 高（≥0.9）、极高频读写    │
+│   预算：每次召回 800-1200 tokens                         │
+└────────────────────────────────────────────────────────┘
+                     ▲ derived_from 溯源
+┌────────────────────────────────────────────────────────┐
+│ L1 · 卡片层（子代理产出，session=subXXX）                │
+│   内容：固定 5 栏卡片（见第三节），不是原始输出            │
+│   特征：条数多（每个子任务 1-3 条）、importance 0.6-0.7   │
+│   预算：主代理默认不读；按 task 号定向取                  │
+└────────────────────────────────────────────────────────┘
+                     ▲ derived_from 溯源
+┌────────────────────────────────────────────────────────┐
+│ L2 · 细节层（子代理过程产物，session=subXXX, contextual） │
+│   内容：改了什么文件、跑了什么命令、完整输出、中间推理      │
+│   特征：量最大、生命周期最短、几乎不主动召回               │
+│   预算：主代理只在"需要追问"时按 id 精确取单条             │
+└────────────────────────────────────────────────────────┘
+```
+
+**实测支撑**：`session` 过滤是**硬隔离**。我建了 `main` 1 条 + `subA/B/C` 各 5 条，实测：
+
+| 过滤条件 | 返回 |
+|---|---|
+| `session=None` | 16 条（全部） |
+| `session="main"` | **1 条**（只有全局态）|
+| `session="subA"` | **5 条**（只有 subA）|
+
+这意味主代理可以用 `session="main"` 保证自己**永远只看到全局态**，无论子代理往库里写了多少东西。
+
+---
+
+## 三、子代理卡片规范（回流的最小单元）
+
+子代理**必须**产出这张卡。它是"细节"和"全局认知"之间唯一的接口。
+
+```markdown
+# 功能名：<任务域，结构化短名，如"缓存后端选型">
+# 子功能：<子任务名，如"Redis 使用决策">
+# 生效条件：<空格分隔的关键词串！如"缓存选型 决策">
+
+结论：<做了什么、结论是什么——注意：这行不带 #>
+
+证据：<可验证锚点，如"f1.py:120-145"、"pytest 12 passed">
+
+影响面：<改了什么/谁会被影响>
+
+未决项：<需要主代理裁决的；没有就写"无">
+```
+
+### ⚠️ 三条硬性格式要求（都是实测踩出来的，违反则冲突检测失效）
+
+我在实现参考代码时**连续踩了三个坑**，每一个都会导致"两条明显矛盾的信息被静默放过"。这三条不是风格偏好：
+
+| # | 规则 | 违反的后果（实测） |
+|---|---|---|
+| **1** | `# 功能名` / `# 子功能` / `# 生效条件` **必须带 `#`** | 缺则检测器返回 `ACCEPT（无冲突）`——因为它靠这三个字段判"是否同一件事" |
+| **2** | `# 生效条件` 必须是**空格分隔的关键词串**（`缓存选型 决策`），**不能是句子**（`缓存选型决策时`） | 句子把词面覆盖率稀释到阈值 `0.75` 以下 → **漏检**。我实测：`缓存选型 决策` 覆盖率 **1.0** 触发 `DEFER`；改成 `缓存选型决策时` 直接 `ACCEPT` |
+| **3** | `结论：/证据：/影响面：/未决项：` 四行**必须不带 `#`** | 系统的结论比对用的是「**去掉所有 `#` 声明行后的正文**」。若结论也带 `#`，正文被清空 → 检测器认为"两条卡片结论完全相同"（实测 `conclusion_overlap=1.0`，需 `<0.95` 才报分歧）→ **漏检** |
+
+**第 3 条最反直觉**：我最初把卡片设计成全部字段带 `#`（看起来更整齐），结果两条"选择 Redis" vs "放弃 Redis"的卡片被判为**无冲突**。原因是 `_body_text()` 把 `# 字段：值` 行全部剔除，正文变成空字符串，空 vs 空的覆盖率是 1.0。
+
+> **一句话记住**：**声明用 `#`，结论不带 `#`。**
+
+### 为什么是这几栏——不是拍脑袋
+
+| 栏 | 作用 | 实测依据 |
+|---|---|---|
+| `# 功能名` / `# 子功能` | **判"是不是同一件事"** | 缺这两栏，`slot_overlap` 无法计算，同条件冲突**测不出来** |
+| `# 生效条件` | **判"在什么条件下"** | 缺这一栏，检测器返回 `BLINDSPOT`："既有节点均未声明条件：无法建立比对路径" |
+| 结论正文 | 供冲突比对"取值是否不同" | 实测两卡片 `conclusion_overlap=0.0` 时正确触发分歧告警 |
+| 未决项 | 主代理的**待办输入** | 这是子代理向主代理"提问"的唯一正规通道 |
+
+---
+
+## 四、四阶段工作流
+
+### 阶段 1：主代理开工前——锚定全局态
+
+```
+1. mdcg_recall(query="当前任务目标", session="main", budget_tokens=1200, goal=<当前目标>)
+   → 拿到 L0 全部内容（实测：session 过滤保证只拿全局态）
+
+2. 若返回空（新会话）→ 用 cg(op=write) 写 L0 首条：
+   # 功能名：<项目名>任务状态
+   # 生效条件：本任务进行期间
+   结论：目标=...；阶段=...；已完成=...；待决=...
+```
+
+**这一步就解决了"跨会话丢状态"** ——因为 L0 是落盘的 md 文件，不是会话内存。
+
+### 阶段 2：派发子任务——给子代理"最小充分上下文"
+
+给子代理的 prompt 里**只放**：
+- 它要做什么（任务描述）
+- **它需要的部分全局态**（不是全部！从 L0 里挑相关的）
+- 卡片规范（第三节的模板，原样贴）
+- 它的 `session` 标识（如 `subA`）
+- 它**必须**调用的写入指令
+
+**关键：不要让子代理自己去 recall 全局态。** 由主代理裁剪后直接注入——因为主代理才知道"这个子任务需要知道什么"。这既省子代理的预算，也避免它被无关全局信息干扰。
+
+### 阶段 3：子代理执行——产出卡片 + 细节分层落盘
+
+子代理完成后，**两次写入**（这是分层的落点）：
+
+```
+写入1（卡片，主代理会读）:
+   cg(op=write, content=<第三节模板>, layer="knowledge",
+      session="subA", importance=0.7,
+      verification_basis="other",
+      derived_from=["<L0的节点id>"])
+
+写入2（细节，主代理默认不读）:
+   cg(op=write, content=<完整过程/命令/输出>, layer="contextual",
+      session="subA", importance=0.4,
+      derived_from=["<卡片节点id>"])
+```
+
+**实测要点（这三条都是真金白银踩出来的）**：
+- `session` 必须作为**顶层参数**传（走 `**extra` → `fm.update(extra)`）。我第一次用 `extra={"session":...}` 嵌套写法失败了，`session` 字段落成 `None`、过滤失效——**这是个真实踩坑点**。
+- `verification_basis` 只接受这几个值：`compiler / test / measurement / formal_proof / data / textbook / public_kb / other`。写 `user_request` 会**直接抛异常**。
+- `derived_from` 是**真实存在的溯源字段**，实测能反查（我靠它成功列出某任务的全部子代理产出）。这就是你要的证据链。
+- ⚠️ **节点 ID 必须带序号**：若只用毫秒时间戳，同一毫秒内的两个子代理会生成相同 ID，**后一个 `.md` 会覆盖前一个**（我实测撞过一次，两条卡片只剩一条）。
+
+### 阶段 4：主代理收口——只读卡片 + 裁决冲突
+
+```
+1. 定向取卡片（不读细节）：
+   mdcg_recall(query="<子任务名>", session="subA", budget_tokens=600, k=5)
+   
+2. 若子代理写了冲突信息 → 它在队列里等你裁决：
+   cg(op=review, pid=<pid>, decision=accept|reject|edit|merge, reason=<理由>)
+
+3. 把结论合并进 L0：
+   cg(op=write, content=<更新后的全局态>, session="main",
+      derived_from=["<各子代理卡片id>"])
+
+4. 【可选】细节确实需要追问时，按 id 精确取单条：
+   mdcg_search(query="...", layer="contextual", session="subA", k=1)
+```
+
+---
+
+## 五、冲突裁决：这套设计最值钱的部分
+
+你选了"结构化卡片 + 主代理裁决 + 证据链"。我实测了这条路径**完全跑得通**，且比预想的好：
+
+### 实测：冲突被准确识别并交给你裁决
+
+我写两条同域信息（旧："选择 Redis"；新："放弃 Redis，改本地内存"），补上正确结构字段后：
+
+```
+verdict           : DEFER
+reason            : 同条件空间下结论槽取值不一致：需裁决是更正还是分支
+conflicts[0]      : type=same_condition_divergence
+                    detail="适用条件与结论槽均重合但取值不同：
+                            可能是更正（应覆盖旧值）或分歧（应补区分条件）"
+                    same_condition=1.0, slot_overlap=1.0, conclusion_overlap=0.4523
+```
+
+**注意它给的不是"冲突了"，而是"是更正还是分歧？"——这正是主代理该回答的问题。**
+
+### 实测：裁决闭环 + 审计留痕
+
+```
+入队  : prop_482fa75a6100
+裁决  : review_decide(pid, "accept", reason="主代理确认：这是对旧决策的更正")
+结果  : {"ok": true, "node_id": "new",
+         "record_node_id": "rev_482fa75a6100_r1",
+         "record_hash": "1a77d65540e9526de12e0249ae5c2d9cd191f9fd"}
+```
+
+**每次裁决都生成一条带哈希的审核记录**——这是可直接被审计的决策链，比任何"我判断过了"的口头声明都硬。
+
+### 实测：这条路径的边界（必须知道）
+
+| 情形 | 判定 | 我要提醒你的 |
+|---|---|---|
+| 自相矛盾（生效条件与不适用条件冲突） | **REJECT** 硬拦 | 最可靠，直接拒绝 |
+| 同条件+同槽位+异取值 | **DEFER** 交裁决 | 需要卡片规范配合，**这是主战场** |
+| 条件互斥 | **DEFER** | 需补区分条件 |
+| 条件部分覆盖 | **DEFER** | — |
+| 节点都没声明条件 | **BLINDSPOT** | **不假装确定**——所以卡片规范是硬要求 |
+| 卡片全字段带 `#`（我的初版设计） | **ACCEPT（漏检！）** | ⚠️ 正文被清空，两条矛盾卡片被判"结论相同" |
+| 生效条件写成句子而非关键词串 | **ACCEPT（漏检！）** | ⚠️ 覆盖率被稀释到阈值 0.75 以下 |
+
+### 实测对照：同一组矛盾，两种模板的判定差异
+
+```
+❌ 漏检  ACCEPT   | 全字段带 # 、条件写成"缓存选型决策时"
+✅ 检出  DEFER    | 声明带 # 、结论不带 # 、条件为"缓存选型 决策"
+                    same_cond=1.0  slot=1.0  concl=0.0
+```
+
+**诚实结论**：这套冲突检测**不是万能的**——它只在"结构化声明"的范围内有效。这也是为什么第三节的卡片规范是**强制**而非可选：**你不按格式写，系统就真的看不见冲突。**
+
+---
+
+## 六、防爆的三道闸门
+
+你的核心诉求是"避免超过上下文"。我实测了三道闸门，全部有效：
+
+### 闸门 1：`budget_tokens` 硬截断（主力）
+
+实测 200 条子代理产出：
+
+| 预算 | 纳入 | 跳过 | 实耗 | 利用率 |
+|---:|---:|---:|---:|---:|
+| 300 | 6 | 44 | 270 | 90.0% |
+| 800 | 17 | 33 | 786 | 98.2% |
+| 1200 | 25 | 25 | 1170 | 97.5% |
+| 2000 | 42 | 8 | 1986 | 99.3% |
+
+**利用率 97-99%，说明预算是被用足的、不是浪费的**；溢出的条目进 `skipped` 而不是被硬塞。这是最可靠的防爆手段。
+
+### 闸门 2：`session` 隔离（结构性）
+
+主代理用 `session="main"` 时，**物理上拿不到**子代理的细节（实测只返回 1 条）。这条不依赖预算计算，是结构保证。
+
+### 闸门 3：分层 `layer`（语义性）
+
+`layer="contextual"` 的细节层默认不参与主代理召回，只在显式指定时取。
+
+**三闸门的关系**：闸门 2 挡"不该看的"，闸门 3 挡"不该默认看的"，闸门 1 挡"看不过来的"。**三个互补，不冗余。**
+
+---
+
+## 七、跨会话不失忆（你的隐含需求）
+
+你的表述是"避免超过上下文导致的 ai 失忆"——真正的失忆有两类，这套设计都覆盖：
+
+| 失忆类型 | 原因 | 本设计的解法 |
+|---|---|---|
+| **会话内失忆** | 上下文被细节挤爆 | 三闸门：细节不回流，主代理只读卡片 |
+| **跨会话失忆** | 会话结束，内存清空 | L0 落盘为 md 文件，新会话 `recall(session="main")` 直接恢复 |
+
+**实测**：L0 就是磁盘上的 `.md` 文件，用任何编辑器都能打开审阅。这是"真源是文档"的好处——**你可以人工检查和修改全局认知**，不依赖任何工具。
+
+---
+
+## 八、需要你自己决定的三个参数
+
+我不替你定这三个，因为它们取决于你的任务特征：
+
+| 参数 | 建议起点 | 取决于 |
+|---|---|---|
+| L0 的 `budget_tokens` | 1200 | 全局态复杂度。任务链越长、决策越多，越高 |
+| 卡片层 `importance` | 0.7 | 0.7 会触发自动保护（实测：`≥0.7` 自动打 `protected` 标记，不可遗忘） |
+| 细节层保留策略 | 定期 `cg(op=scrub)` | 细节层会持续膨胀，需要主动清理 |
+
+**第三点特别提醒**：L2 细节层是**只增不减**的，长期运行必然膨胀。建议在每完成一个大任务后调 `cg(op=scrub)` 或 `cg(op=forget)` 清理已归档的细节。这是这套架构里**唯一需要主动运维**的地方。
+
+---
+
+## 九、一句话总结设计
+
+> **主代理管"状态"，子代理管"细节"；细节落库不落上下文，状态读卡片不读正文；
+> 冲突交给结构检测发现、交给主代理裁决、交给哈希留痕。**
+
+三个关键动作，缺一不可：
+1. **子代理按格式出卡**（否则冲突检测失效——实测漏检）
+2. **`session` 硬隔离**（否则主代理迟早被细节淹没）
+3. **`derived_from` 建溯源**（否则事后追不回"这结论从哪来"）
+
+---
+
+## 附：实测清单（本文所有数字均为实机复现）
+
+| 验证项 | 方法 | 结果 |
+|---|---|---|
+| 预算硬截断 | 200 节点 + 6 档预算 | ✅ 利用率 90-99%，溢出进 `skipped` |
+| session 隔离 | main + 3×sub 交叉过滤 | ✅ `main`→1 条，`subA`→5 条，完全隔离 |
+| 溯源链 | `derived_from` 反查 | ✅ 可列出某任务全部子代理产出 |
+| 同条件异值检出（修正后模板） | CCG 槽位 + 生效条件 | ✅ `DEFER`，含 `slot_overlap=1.0` / `conclusion_overlap=0.0` |
+| **同条件异值漏检（初版模板）** | 同内容、全字段带 `#` + 条件写句子 | ⚠️ **`ACCEPT`（真实盲区）** |
+| 裁决闭环 | `propose` → `review_decide` | ✅ `ok=true` + `record_hash` 审计留痕 |
+| 自否定硬拦 | 生效条件与不适用条件冲突 | ✅ `REJECT` |
+| `verification_basis` 白名单 | 尝试 `user_request` | ⚠️ 抛异常，须用 `other` 等合法值 |
+| `session` 传入姿势 | `extra={"session":x}` vs 顶层 | ⚠️ **嵌套写法静默失败**，必须顶层 |
+| 节点 ID 唯一性 | 同毫秒两次写入 | ⚠️ **ID 相同会互相覆盖**，须带序号 |
+| 参考实现端到端 | `orchestrator_memory.py selftest()` | ✅ 四阶段全通，含待裁决检出与证据链反查 |
+
+### 独立复现报告（2026-09-14 · dsh-memory 主会话 · 27/27 全绿）
+
+> 复现脚本：`docs/experiments/orch_mem_verify/verify_orch.py`（临时库零污染，可重跑）。不采信上文自述，逐项独立复现的结论：
+
+| 项 | 文档声称 | 独立实测 | 裁决 |
+|---|---|---|---|
+| session 硬隔离 | None=16 / main=1 / subA=5 | 完全一致 | ✅ 复现 |
+| 预算硬截断 | 利用率 90-99% | 四档均 98.0%，溢出全进 `skipped` | ✅ 复现 |
+| 修正模板检出 | `DEFER` | `DEFER`（same_cond=1.0 slot=1.0 concl=0.6975） | ✅ 复现 |
+| **初版全带`#`漏检** | **`ACCEPT`（漏检）** | **`DEFER`（检出）** | ⚠️ **不复现，见下** |
+| 条件句子化漏检 | `ACCEPT`（漏检） | `ACCEPT`（漏检） | ✅ 复现 |
+| 裁决闭环 | ok + record_hash | ok=True + hash | ✅ 复现 |
+| ID 撞车覆盖 | 后写覆盖前写 | 成立；且 0.7 只触发「不可遗忘」不触发「不可覆盖」→ 同 ID 静默覆盖 | ✅ 复现 |
+| 溯源 / 白名单 / 嵌套坑 / protected / 细节不泄漏 | — | 全部一致 | ✅ 复现 |
+
+**「第三坑」结论修正**：`consistency.py` 结论比对带空正文兜底（`concl = _cov(...) if tw_content else 0.0`）——任一侧正文为空时 `concl` 恒 `0.0 < 0.95`，**恒报分歧而非判重复**。当前版本对「全字段带 `#`」是 fail-closed（检出但结论取值信息丢失），不是静默漏检。三条硬要求的理由据此分层：第 1/2 条（声明带 `#`、条件关键词串）是**防漏检**硬要求（句子化漏检实测复现）；第 3 条（结论不带 `#`）的真实代价是**比对退化 → 无效 DEFER 增多**，而非漏检。
+
+**其他修正**：参考实现 `selftest` 内注释「session=main 应为 3」实为 2（1 锚定 + 1 合并）；`orchestrator_memory.py` 实际位于 `test/`；文首所述 png 未随文档交付。
+
+### 多进程并行实验（2026-09-14 · Windows spawn + WSL2 fork 双端对照 · 双端 12/12 全绿）
+
+> 脚本：`docs/experiments/orch_mem_parallel/parallel_test.py`（gitignored 可重跑）。N 个**真进程**各自持有独立 `OrcMemory` 实例写同一 root：A 组 8 进程 × 3 卡（条件唯一）测完整性，B 组 4 进程同条件不同结论测并行冲突检测。
+
+| 项 | 实测（双端一致） |
+|---|---|
+| 完整性 | 24 卡 + 24 细节零丢失零损坏，ID 唯一无撞车，收口 24/24，终态 index=57 |
+| 三层隔离 | L2 细节零泄漏进 main 召回；三层统计精确一致 |
+| 并行冲突检出 | 子进程侧 0/4 DEFER（时序敏感）→ **收口检查点 4/4 全检出**（V12） |
+| 原子写 | 临时文件零残留；无挂死进程 |
+| 吞吐 | Linux fork 1 ms/卡 vs Windows spawn 7 ms/卡（约 7×） |
+
+**发现一（生命周期约定，参考实现已补 API）**：index 是进程内快照（`__init__` 加载一次）。子进程写完必须 `close()`（把未达 autoflush 阈值的脏索引 flush 进本进程独占分片，否则「在盘上但不可见」）；主代理收口前必须 `refresh()`（重载快照+回放全部分片，否则 `collect_cards` 只见自己 init 时的旧世界——实测不 refresh 时 collect 0/24）。`orchestrator_memory.py` 已新增这两个方法；`md_cg` 的分片+OS 锁架构本身零改动、零丢失。
+
+**发现二（并行冲突检测盲区→已补全）**：每个子进程的 `check_consistency` 只见实例 init 时的 index，**看不到并行者 init 之后写入的卡**（B 组 0/4 DEFER；偶发检出是 spawn 慢启动恰逢回放到已落盘分片）——并行提交绕过跨进程冲突检测。**缓解已落地**：主代理收口检查点 `final_check()`（refresh 后逐卡重查，exclude 自身；只报告不落库，处置走裁决通路），V12 实证 B 组 4 卡全检出、A 组唯一条件卡零误报，双端一致。串行形态不受影响。
+
+### 收口检查点与证据链（参考 J-Space Cognition Suite SV1）
+
+J-Space（github.com/Tiger3807861189/J-Space-Cognition-Suite）的核心是一条证据链：源文件—地图—断言—检查点—报告，地图挂 SHA-256 防陈旧；「相同重试无新证据不算恢复」；测试只证明覆盖的已实现行为，不宣称普适增益。其五环节在 `orchestrator_memory.py` 的映射（取其实质，不引入其控制面）：
+
+| J-Space 环节 | OrcMemory 对应 |
+|---|---|
+| 源文件 | L2 细节在盘（drill_down 唯一读入口） |
+| 地图 | index（refresh 后的全库快照） |
+| 断言 | 卡片结论（L1，条件+结论+证据槽） |
+| 检查点 | `final_check()`：收口全库一致性复查，并行冲突在此无条件检出 |
+| 报告 | `closeout()`：stats+未决项+检出+指纹；fingerprint=卡 ID 清单 SHA-256 前缀，同批复验指纹必须一致，卡集变化即指纹变化——防报告陈旧 |
+
+未决项（卡片「未决项：」槽）经 `closeout` 透出后可落 L5（`add_unresolved`），对应 J-Space 的 unknowns 带 settled_by——未解问题驱动下一轮探索。
+
+**独立复核并非缺口——本仓已有结构形态**（智能论 v3.4 §十三 五大单元，与 J-Space xhigh 的编排形态互补）：
+
+| 独立复核环节 | J-Space xhigh（编排形态：不同 agent 实例隔离上下文） | 本仓（结构形态：权限权职分离，`identity.POSITIONS` 同源） |
+|---|---|---|
+| 防自验 | 独立子代理复核，root 独立核验 | 验证单元 `layers_allow=['rejected','contextual']`——写 knowledge 直接 `AccessDenied`，「自己写、自己验」在结构上不成立 |
+| 反思 | 子代理两轮实质 pass | 反思单元 `reflect`：信息差 D(t,C) 与 d²D/dt²（`_reflection.jsonl`） |
+| 终裁复核 | root verdict | 维生系统：`heal` 只写 self 层，调度 `reflect_fn`/`verify_fn` 双签固化（consolidate 两道复核）；中断权阶梯「维生>验证>用户>实例」；权限面终裁归 designer（`review_decide` require_admin） |
+| 复核盲区 | root 核验兜底 | 收口检查点 `final_check()`——写侧逐进程快照检测必然有时序盲区，复核后置到全量可见处（本轮 V12 闭环） |
+
+两种形态防的是同一件事（写入者自裁自决）：编排形态靠上下文物理隔离，结构形态靠角色写权限互斥——`md_cg` 的权限模型在结构上使「验证单元不得改事实层」可机器强制（`test_p21_tokens` 有断言防漂移），不依赖编排纪律自觉。
+
+### 交付物
+
+| 文件 | 内容 |
+|---|---|
+| `docs/主代理子代理记忆架构设计.md` | 本文档：架构、规范、工作流、边界 |
+| `test/orchestrator_memory.py` | 可运行参考实现（含 `selftest()`，封装 L0/L1/L2 三层与裁决闭环，实测位置在 `test/`，非仓根；含多进程生命周期 `close()`/`refresh()`、收口检查点 `final_check()` 与证据链报告 `closeout()`） |
+| `docs/experiments/orch_mem_verify/verify_orch.py` | 独立复现实测脚本（27 断言，gitignored 可重跑产物） |
+| `docs/experiments/orch_mem_parallel/parallel_test.py` | 多进程并行实验脚本（12 断言双端对照，gitignored 可重跑产物） |