L2 场景记忆：LLM 沙箱 Agent 维护的场景档案
L2 把同一情境下的记忆卡片打包成 .md 文件，按情境组织、不按日期。抽取由 LLM 以「Agent」身份完成——但它被锁在沙箱里，只能用工具读写场景文件。
L2 Scenario · scene-extractor.ts
1
备份 + 读 checkpoint
CheckpointManager 读处理进度；本地模式 BackupManager 对 scene_blocks/ 做目录备份（保留最近 10 份）。
2
加载 scene_index + 构建摘要
读取现有场景的 filename / heat / updated / summary，拼接进 Prompt，让 LLM 看到「当前场景总数：N / 15」与容量状态。
3
容量控制（分档警告）
≥15 个：必须先 MERGE 相似场景；=14 个：只能 UPDATE 禁 CREATE；≥12 个：建议 UPDATE / MERGE。
4
快照 pre-extract 索引与内容
记录抽取前每个场景的 summary 与正文，供结束后 diff 出 created / updated / deleted。
5
LLM 沙箱执行（核心）
CleanContextRunner 开启工具模式；workspaceDir 锁死 scene_blocks/，LLM 只能 read / write .md 场景文件，看不到 checkpoint、scene_index、persona.md；超时 300s。
失败 → 从备份 restore 回滚部分写入，防止泄漏进下一次召回
6
软删除清理 + 文件名规范化
LLM 无 exec 工具，靠写 [DELETED] 标记「删文件」；清理阶段移除空文件 / 标记文件 / 仅有 META 无正文的文件。文件名含空格 / 标点的重命名为规范形式（防御破坏下游解析）。
7
同步索引 + 更新导航
syncSceneIndex 从磁盘剩余非空文件重建 scene_index；scene 导航块（场景列表 + 热度）追加到 persona.md 尾部。
8
解析 Persona 更新信号
LLM 输出里带 [PERSONA_UPDATE_REQUEST] 块时，把原因写进 checkpoint，触发 L3 生成。
场景文件格式
--- type: scene title: 鉴权模块重构 created: 2026-08-01 updated: 2026-08-20 summary: 重构进度与约束 heat: 7 --- # 鉴权模块重构 - 别重构旧鉴权模块… - 新方案已评审，待排期…
frontmatter 记录创建 / 更新时间、摘要、热度（命中 +1）。
为什么用「沙箱 Agent」而非普通 LLM？
一次调用内可以多次读、写、合并文件，按需操作而不是一次性生成全部
物理隔离系统文件：LLM 永远看不到索引与画像本体
MERGE / ARCHIVE / UPDATE 由模型自主决策，人只需要事后审核
与 L1 的关系
L1 记忆卡片带 scene_name 字段，是 L2 分组的依据
L2 读取 L1 输出 → 用 LLM 决策如何归并到现有场景
热度最高的场景排在导航最前，供召回优先注入
来源：MemoryCore/src/core/scene/scene-extractor.ts + scene-format.ts + scene-index.ts + scene-navigation.ts + utils/clean-context-runner.ts。远端同步走 ProfileRecord（id = profile:v1:sha256(scope+type+filename)）。