OpenClaw System Prompt 九层架构：从“能用”到“可控”

为什么要理解“九层架构”

很多人把 Agent 的行为理解为“一个 System Prompt 决定一切”。

但在 OpenClaw 里，System Prompt 更像是一个 动态组装系统： 它不是单文件，而是由多个层级在运行时拼接而成。

理解这件事的价值在于：

• 你会知道哪里可以改，哪里不该改
• 你会明白为什么“同样一句话，不同会话表现不一样”
• 你能把“玄学调参”变成“工程化配置”

---

九层结构（工程视角）

Layer 1～6：框架自动层（稳定性优先）

这部分通常由框架自动注入，目标是保证一致性与安全边界：

1. Framework Core（框架核心规则）
2. Tool Definitions（工具定义与参数约束）
3. Skills Registry（技能注册与可用性）
4. Model Aliases（模型别名）
5. Protocol Specs（协议规范，如 Reply Tags / Heartbeat）
6. Runtime Info（运行时信息，如 agent、host、model、channel）

这 6 层通常不建议“硬改”，而是通过配置间接影响。

---

Layer 7：静态可控层（Workspace Files）

这是最直接、最稳定的个性化入口。常见文件包括：

• AGENTS.md
• SOUL.md
• USER.md
• IDENTITY.md
• TOOLS.md
• HEARTBEAT.md
• MEMORY.md / memory/*.md

适合放：

• 角色定位
• 长期偏好
• 工作规范
• 可复用决策

---

Layer 8：动态可控层（Hooks）

这是“按场景注入”的关键能力。比如：

• 根据会话类型加载不同文档
• 在 prompt 构建前注入实时上下文
• 按条件追加 bootstrap 文件

适合放：

• 会变的内容
• 上下文相关内容
• 自动化拼装逻辑

---

Layer 9：入站上下文层（Inbound Context）

每次请求都会带上：

• 发送者信息
• 渠道元信息
• 会话上下文
• 当前消息特征

它解释了为什么同样 prompt，在不同渠道/会话里会出现不同响应倾向。

---

真正的“控制面”在哪？

结论很简单：

• 长期稳定行为：放 Layer 7
• 动态场景行为：放 Layer 8
• 会话差异影响：理解 Layer 9

也就是说，真正可控的核心不是“改一段神奇 prompt”，而是：

Layer 7 + Layer 8 的协同设计。

---

常见误区

误区 1：只盯着系统提示词文本

问题：你看到的只是结果，不是组装过程。

建议：先弄清“由谁、在何时、按什么规则”拼装。

误区 2：把所有需求都塞进一个文件

问题：静态内容和动态内容混在一起，后期维护灾难。

建议：

• 稳定规则写 Layer 7
• 动态逻辑写 Layer 8

误区 3：忽视上下文噪声

问题：Layer 9 带来的对话历史噪声会让输出漂移。

建议：定期收敛上下文，保持任务边界清晰。

---

一套可落地的优化方法

1. 先清理 Layer 7：删重复、删修辞、留规则
2. 再约束 Layer 8：只注入必要内容，避免重依赖
3. 观察 Layer 9：排查“历史消息污染”
4. 逐步迭代：每次只改一个变量，便于回归验证

---

总结

OpenClaw 的 System Prompt 不是“写作题”，是“系统工程题”。

当你把九层看成一个组装管线，而不是一段固定文本时， 你就从“会用 Agent”走到了“能设计 Agent”。

下一步最值得做的，不是继续堆提示词，而是把你的 Layer 7/8 做成可维护、可迭代、可验证的配置体系。