一、Prompt 的两段式结构
systemPrompt · 稳定层
角色定义 / 硬约束 / 否定清单 / 工作流 / 输出模板 —— 可缓存、可被运营改写
userPrompt · 动态层
记忆数据 / 时间戳 / 统计 —— 每次重新组装
动态数据永不进 system：否则提示词缓存失效，运营改写也会被数据污染。
二、区块顺序（以 L2 场景整合为例）
systemPrompt —— 11 个区块
1输出语言
2角色定义
3架构模型
4场景上限（参数注入）
5文件操作约束（7 条）
6文件命名规范（正反例）
7工作流 阶段 0–3
8撰写准则
9热度管理
10输出规范（META + 模板）
11主动触发信号
L3 结构同源：文件操作约束 → 严格禁止 → 核心运作逻辑（四层深扫）→ 输出模板。L1 则是"任务一 / 二 / 三"三段式。
userPrompt —— 动态区块
1输出语言
2New Memories List
3Existing Scene Blocks Summary
4Current Timestamp
5已有场景文件清单（read 白名单）
6场景数量警告（运行时分档）
L3 的 user 段更重：已把现有 persona.md 全文预加载进来，所以 Prompt 明确写"无需 read 工具"——用输入换调用次数。
三、工具是怎么"告诉"LLM 的：双轨并行
轨一 · 工具 schema（硬约束，走 API 字段）
read : { path }
write : { path, content }
edit : { path, edits:[{ oldText, newText }] }
tools: { allow: ["read","write","edit"] }
disableTools: !enableTools
stopWhen: stepCountIs(20)
resolveSandboxedPath() // 越界即拒绝
参数名 / 必填项 / 类型由 inputSchema 定义，这就是模型看到的函数签名。白名单之外的工具（exec / browser / cron）不可见。
轨二 · Prompt 语义约定（软约束）
- 声明有哪些工具：明确点名 write / edit，并限定 read 的可用范围
- 说明何时用哪个：整体重写用 write，局部替换用 edit，结构性变更建议 read + write
- 说明参数语义：path = 相对文件名、content = 完整内容、edits = [{oldText, newText}]
- 刻意缺省 delete：改由 write(path, "[DELETED]") 软删除，工程侧扫描真删
Prompt 里不重复 schema，只做"有哪些、何时用、参数什么意思"的语义约定 —— 硬软分工，各管一层。
L2 · workspaceDir = scene_blocks/
checkpoint、scene_index、persona.md 对 LLM 物理不可见 —— 靠隔离。
L3 · workspaceDir = dataDir
能看到文件树，因此 Prompt 必须显式禁止从路径 / 目录结构推断用户信息 —— 靠禁令。