拆解 OpenClaw 的大脑：一个 AI 助手的 System Prompt 是怎么炼成的

很多人以为，AI 助手的差异主要来自模型：Claude、GPT、Gemini，谁更聪明，谁就更好用。

但真正把一个“会聊天的模型”变成“能干活的助手”的，往往不是模型本身，而是它每次被调用前收到的那份 System Prompt。

它像一份启动配置，也像一份人格说明书，更像一个运行时操作系统：定义这个助手是谁、能做什么、不能做什么、应该如何理解用户、有哪些工具、有哪些长期记忆、当下处在什么环境里。

OpenClaw 的 System Prompt 有意思的地方在于：它不是一段孤零零的提示词，而是一套被分层组装出来的上下文工程。理解它，你就能理解一个现代 AI Agent 的“脑子”大概是怎么拼起来的。

flowchart LR
    U[用户输入] --> G[OpenClaw Gateway]
    G --> B[Prompt Builder]
    B --> S[System Prompt
9 层上下文]
    S --> M[LLM 推理]
    M --> T{需要工具吗}
    T -->|是| TOOL[工具 / Skills / 外部系统]
    TOOL --> M
    T -->|否| R[最终回复]
    M --> R

---

先把话说透：System Prompt 不是“咒语”，是运行时合同

普通提示词更像一句请求：

请帮我总结这篇文章。

System Prompt 则更像一份合同：

• 你是谁；
• 你的职责是什么；
• 你能调用哪些工具；
• 工具调用必须遵守什么格式；
• 什么情况必须沉默，什么情况必须响应；
• 哪些信息来自长期记忆，哪些信息来自当前会话；
• 用户能改哪里，框架又锁死了哪里。

所以，System Prompt 的核心价值不是“让模型变聪明”，而是 把模型的聪明约束成稳定、可复用、可协作的行为。

这也是 Agent 工程和普通 Prompt Engineering 最大的区别：前者关心的是系统行为，后者更偏单次回答效果。

---

OpenClaw 的 9 层结构：不是越多越炫，而是职责隔离

OpenClaw 的 System Prompt 可以拆成 9 层。

flowchart TB
    subgraph F[框架控制层：稳定基线]
        L1[Layer 1
框架核心：身份 / 规则 / 安全边界]
        L2[Layer 2
工具定义：函数、参数、调用协议]
        L3[Layer 3
技能注册：可复用任务手册]
        L4[Layer 4
模型别名：模型切换入口]
        L5[Layer 5
协议规范：沉默、心跳、群聊响应]
        L6[Layer 6
运行时信息：时间、目录、环境]
    end

    subgraph U[用户可控层：个性化与项目知识]
        L7["Layer 7
工作区文件：IDENTITY / AGENTS / MEMORY"]
        L8[Layer 8
动态注入：Hook / Git 状态 / 外部数据]
    end

    subgraph C[会话现场层：每次消息动态生成]
        L9["Layer 9
入站上下文：发送者 / 历史 / 平台 / @ 状态"]
    end

    F --> U --> C --> P[最终组装成 System Prompt]

如果只看名字，9 层很容易显得玄乎。但它背后的逻辑其实很朴素：不同来源、不同更新频率、不同控制权限的上下文，不应该混在一起。

可以先记住这个分法：

• Layer 1~6：框架层
  由 OpenClaw 自动生成，负责身份基线、工具协议、技能注册、模型配置、运行环境等基础设施。

• Layer 7~8：用户可控层
  用户真正能影响 Agent 行为的地方，包括工作区文件、记忆、额外文档、动态 Hook。

• Layer 9：会话现场层
  每次用户发消息时动态生成，包括当前发送者、消息历史、是否被提及等实时上下文。

也就是说，OpenClaw 并不是每次都把一大坨文本塞给模型，而是在调用前按层组装：稳定的放前面，动态的放后面；框架的归框架，用户的归用户。

---

Layer 1：框架核心层——先规定“你是什么东西”

第一层是 OpenClaw 自动生成的基础系统说明。

flowchart LR
    A[框架核心层] --> B[身份定义]
    A --> C[行为原则]
    A --> D[安全边界]
    A --> E[输出与工具调用规范]
    B --> F[统一行为底座]
    C --> F
    D --> F
    E --> F

这一层通常包含几类信息：

• Agent 的基础身份；
• 核心行为原则；
• 当前系统运行时间；
• 基础安全边界；
• 对输出格式和工具调用方式的底层要求。

这层的作用不是给 Agent 加个“人设”，而是定调：它不是网页里的聊天框，而是一个运行在框架里的工具型智能体。

我觉得这里最重要的一点是：身份定义不能写得太文学化。

很多人写 System Prompt 喜欢堆“你是世界顶级专家”“你无所不能”“你必须完美完成任务”。这种写法短期看很振奋，长期看很容易制造不稳定行为。一个好的 Agent 身份应该回答三个问题：

1. 你服务谁？
2. 你负责什么？
3. 遇到不确定时怎么处理？

OpenClaw 把这部分放进框架层，就是为了保证所有 Agent 至少有一致的行为底座。

---

Layer 2：工具定义层——告诉模型“手上有哪些按钮”

一个 Agent 和普通 Chatbot 的分水岭，通常就在工具调用。

flowchart LR
    I[用户意图] --> M[模型判断]
    M --> S[JSON Schema
工具名 / 参数 / 必填字段]
    S --> A[工具调用]
    A --> O[外部结果]
    O --> M
    M --> R[整合后回复]

这一层会把可用工具注入给模型，例如：

• 读取文件；
• 搜索资料；
• 执行命令；
• 调用浏览器；
• 发送消息；
• 写入记忆；
• 触发其他自动化流程。

每个工具一般都会带结构化参数说明，也就是 JSON Schema。它告诉模型：这个工具叫什么、什么时候该用、参数有哪些、哪些字段必填、返回结果大概是什么。

这件事看起来很细，但非常关键。

因为模型本身并不会“真的知道”外部世界。它需要通过工具把意图变成行动。工具定义越清晰，模型越不容易乱猜；工具边界越明确，系统越不容易出事故。

一个简单判断标准是：如果一个工具说明写得让人类开发者都看不懂，那就别指望模型稳定调用它。

---

Layer 3：技能注册表——把经验封装成可复用配方

工具解决“能做什么”，技能解决“怎么做得更好”。

flowchart TD
    Q[用户任务] --> D{命中技能吗}
    D -->|否| G[按通用流程处理]
    D -->|是| R[读取技能说明]
    R --> W[遵循固定工作流]
    W --> V[执行验证步骤]
    V --> O[交付结果]

OpenClaw 的 Skills 可以理解成一组任务手册：

• 发小红书应该走什么流程；
• 读 Twitter 长文怎么抓取；
• 发布博客要检查哪些 front matter；
• 生成封面图要避开什么坑；
• 部署前要跑哪些命令。

这比把所有规则都塞进一个巨大 System Prompt 更合理。因为技能天然有边界：只有当任务相关时才应该加载或引用。

但这里也有一个代价：如果技能注册表注入得太重，会吃掉上下文窗口；如果技能描述太泛，又会让模型不知道什么时候该用。

所以好的 Skill 不是“知识库全文”，而应该像菜谱索引：

• 名字清楚；
• 触发条件明确；
• 描述短；
• 真正复杂的内容放到需要时再加载。

这也是 Agent 工程里一个很现实的取舍：可发现性和上下文成本永远在打架。

---

Layer 4：模型别名层——把复杂配置变成可操作入口

模型别名层看起来不如工具和技能重要，但它解决的是使用体验问题。

flowchart LR
    A["/model fast"] --> B["低成本快速模型"]
    C["/model opus"] --> D["强推理模型"]
    E["/model vision"] --> F["多模态模型"]
    B --> T[任务路由]
    D --> T
    F --> T

实际使用中，模型 ID 往往很长：provider、模型名、版本、路由策略、API 兼容层，混在一起很难记。

别名的意义就是让用户能用简单命令切换复杂配置：

/model glm-5
/model opus
/model fast

这不是单纯的快捷方式，而是在降低“模型能力编排”的门槛。

一个 Agent 系统如果支持多模型，就必须面对一个问题：哪些任务用强模型，哪些任务用快模型，哪些任务用便宜模型？别名层让这种策略有了可读入口。

---

Layer 5：协议规范层——让 Agent 不只会说话，还会守规矩

Agent 跑在聊天环境里时，最怕两件事：该回的时候不回，不该回的时候乱回。

flowchart TD
    M[入站消息] --> K{消息类型}
    K -->|用户明确请求| R[正常响应]
    K -->|收到 / OK| N[静默或最小回复]
    K -->|Heartbeat Poll| H[返回健康状态]
    K -->|群聊未 @| Q{是否需要介入}
    Q -->|否| S[不打扰]
    Q -->|需要介入| R

协议规范层就是为了解决这些边界问题，比如：

• 用户只是说“收到”，Agent 是否应该沉默；
• 系统发来心跳检查，Agent 应该返回什么；
• 群聊里没有 @，Agent 是否应该插话；
• 回复某条消息时，是否需要携带引用标签；
• 工具调用和最终回复之间如何区分。

这层很容易被低估。

但对真正长期运行的助手来说，“不添乱”和“会干活”一样重要。一个 Agent 如果在群里乱插嘴、心跳消息乱回复、对系统事件当成用户请求处理，再聪明也会很烦。

所以协议层本质上是在教模型一种“场合感”。

---

Layer 6：运行时信息层——让模型知道自己现在在哪里

模型没有天然的“现在”。它不知道今天是哪天，也不知道自己运行在哪台机器、当前目录是什么、正在用哪个模型、有哪些环境限制。

flowchart LR
    R[运行时信息] --> T[当前时间]
    R --> M[当前模型]
    R --> D[工作目录]
    R --> O["操作系统 / Shell"]
    R --> P[消息平台]
    T --> C[减少错误假设]
    M --> C
    D --> C
    O --> C
    P --> C

所以 OpenClaw 会在请求时注入运行时信息，例如：

• 当前日期和时间；
• 当前模型；
• 当前工作目录；
• 操作系统；
• shell 环境；
• 当前会话来源。

这层的价值在于减少“幻觉式自信”。

比如用户问“现在几点”，模型不能凭训练数据猜；用户问“这个文件在不在”，模型不能假装看过；用户让部署项目，模型需要知道当前目录、命令环境和可用工具。

运行时信息不是为了让回答更华丽，而是为了让行动更接地。

---

Layer 7：工作区文件层——用户真正开始接管大脑

前 6 层主要由框架控制。从 Layer 7 开始，用户终于能明显影响 Agent 的长期行为。

flowchart TD
    W[工作区文件层] --> I[IDENTITY.md
身份与沟通风格]
    W --> A[AGENTS.md
项目规则与协作约定]
    W --> M[MEMORY.md
稳定偏好与长期事实]
    W --> T[TOOLS.md
项目专属工具说明]
    I --> B[长期行为偏置]
    A --> B
    M --> B
    T --> B

典型文件包括：

• IDENTITY.md：身份、语气、价值观；
• AGENTS.md：项目内协作规则或子 Agent 说明；
• MEMORY.md：长期记忆；
• TOOLS.md：项目特定工具说明。

这一层最像“给 AI 写员工手册”。

但这里有个非常常见的误区：很多人把它写成了愿望清单。

比如：

你必须永远主动、完美、准确、聪明、优雅、无所不能。

这类内容几乎没有工程价值。真正有用的是具体、稳定、可执行的偏好：

• 用户喜欢中文回答，结论优先；
• 项目使用 pnpm，不要用 npm；
• 发布博客前必须跑 npx hexo generate；
• 图片必须上传到 CNBlogs，不要引用本地路径；
• 代码修改后先检查 diff，再提交。

Layer 7 的黄金原则是：写事实，不写口号；写约束，不写鸡血。

---

Layer 8：动态注入层——让上下文从“静态文档”变成“实时系统”

如果说 Layer 7 是静态记忆，那么 Layer 8 就是可编程记忆。

flowchart LR
    H[动态 Hook] --> G[Git 状态]
    H --> T[测试结果]
    H --> L[最新日志]
    H --> D[按需文档]
    H --> E[外部实时数据]
    G --> P[Prompt Builder]
    T --> P
    L --> P
    D --> P
    E --> P
    P --> C[更贴近现实的上下文]

它允许用户在构建 Prompt 前动态插入内容。典型场景包括：

• 注入当前 Git 分支、未提交 diff、测试状态；
• 注入项目 issue、TODO、CI 状态；
• 注入最近的日志、监控告警、服务健康检查；
• 根据当前任务选择性加载某份文档；
• 根据用户身份或群聊场景切换响应策略。

静态文件的问题是：它们会过期。动态 Hook 的价值就在于把“此刻”带进来。

例如，用户问“帮我看看项目现在还能不能跑”，一个没有动态上下文的 Agent 可能只能建议你运行测试；但一个有 Hook 的 Agent 可以在 prompt 构建时已经拿到最近测试结果、服务状态和 git diff，回答会更像一个真的在线同事。

当然，Layer 8 也最容易失控。我的建议是：

• 动态注入要短，不要把日志全文塞进去；
• Hook 要快，不要让每次对话都等十几秒；
• 注入内容要有标题和来源，方便模型判断可信度；
• 能按需加载就别常驻；
• 不要把敏感信息无脑注入给所有模型。

动态上下文很强，但它本质上是在扩大 Agent 的感知范围。感知越多，治理越重要。

---

Layer 9：入站上下文层——当前这句话到底是谁在什么场景下说的

最后一层是每次消息进入时生成的现场上下文。

flowchart TD
    I[入站上下文] --> U[发送者是谁]
    I --> P[来自哪个平台]
    I --> H[最近消息历史]
    I --> A[是否被 @]
    I --> R[是否引用某条消息]
    U --> J[判断该不该回、怎么回]
    P --> J
    H --> J
    A --> J
    R --> J

它通常包含：

• 当前消息内容；
• 最近对话历史；
• 发送者身份；
• 消息来源平台；
• 是否在群聊；
• 是否被 @；
• 是否需要引用回复。

这层决定了 Agent 对“同一句话”的不同理解。

比如“发一下”这三个字：

• 在私聊里，可能是让 Agent 发送文件；
• 在群聊里，可能需要先确认是不是对它说的；
• 接在一段草稿后面，可能是发布；
• 接在图片生成后面，可能是把媒体传给用户。

所以，Agent 的智能并不只在模型参数里，也在它能否正确读懂“场景”。Layer 9 就是在补这件事。

---

这 9 层合起来，到底解决了什么问题？

如果用一句话概括：

OpenClaw 的 9 层 System Prompt，把一个大模型包装成了一个有身份、有工具、有记忆、有场合感、能被用户定制的长期助手。

更具体一点，它解决了五个工程问题。

1. 身份稳定

Agent 不会每次都从零开始猜自己是谁，而是有固定的行为基线。

2. 能力明确

工具和技能被显式列出来，模型知道自己能做什么、怎么做。

3. 上下文分层

静态规则、动态状态、用户消息不会混成一团，方便维护和优化。

4. 用户可控

用户不需要改框架源码，也能通过文件和 Hook 改变 Agent 行为。

5. 长期演化

记忆、技能、项目规则可以不断积累，让助手越用越贴合个人工作流。

这其实就是 AI 助手从“玩具”走向“基础设施”的关键：不是回答一次问题，而是能长期稳定地嵌入你的生活和工作。

---

Token 成本：System Prompt 不是免费的

flowchart LR
    A[常驻短规则
身份 / 协议 / 安全] --> K[适合固定注入]
    B[长文档
项目说明 / API 文档] --> L[适合按需检索]
    C[实时状态
Git / 测试 / 日志] --> M[适合动态 Hook]
    D[重复信息
框架已知道的内容] --> N[应该删除]

    K --> O[更低 Token 成本]
    L --> O
    M --> O
    N --> O

分层架构听起来很优雅，但它有一个现实成本：每一层都要占上下文窗口。

尤其是：

• 技能注册表越来越长；
• 长期记忆越写越多；
• 项目文档被整篇注入；
• Hook 把日志、状态、搜索结果全塞进去。

最后就会出现一个尴尬局面：真正的用户问题还没开始，System Prompt 已经吃掉一大截上下文。

所以，System Prompt 优化不是玄学，它很像系统性能优化：

• 常用但短的内容，可以常驻；
• 长而低频的内容，按需加载；
• 会过期的内容，动态生成；
• 可检索的内容，不要全文注入；
• 重复信息，坚决删掉。

一句话：Agent 的大脑不是越大越好，而是越干净越好。

---

普通用户真正该改哪里？

如果你只是 OpenClaw 用户，不需要把 9 层都背下来。真正值得动手的是 Layer 7 和 Layer 8。

flowchart TD
    U[普通用户最该改的地方] --> I[IDENTITY.md
稳定偏好]
    U --> A[AGENTS.md
项目约定]
    U --> M[长期记忆
只存稳定事实]
    U --> H[Hooks
注入变化信息]
    I --> R[更像你的助手]
    A --> R
    M --> R
    H --> R

第一，先整理 IDENTITY.md

不要写空泛人设，写稳定偏好：

- 用户主要用中文交流。
- 回答优先给结论，再给步骤。
- 涉及外部发布、转账、删库等操作前必须确认。
- 代码任务默认先读项目文件，不要凭空猜测。

第二，把项目规则放进 AGENTS.md

例如：

- 本项目使用 pnpm，不使用 npm。
- 修改后运行 pnpm test。
- API 类型定义在 src/types/。
- 不要改 generated/ 目录下的文件。

这类信息对 Agent 极其有用，因为它能直接减少错误操作。

第三，谨慎维护长期记忆

记忆应该保存稳定事实，而不是任务流水账。

适合写入记忆的内容：

• 用户偏好；
• 固定路径；
• 项目约定；
• 反复出现的坑；
• 已验证过的工作流。

不适合写入记忆的内容：

• 今天做到哪一步；
• 某次临时搜索结果；
• 一段过期日志；
• 没验证过的猜测。

第四，用 Hook 注入“变化的信息”

比如 Git 状态、最近测试结果、服务健康检查。这类东西不适合写进静态文件，但很适合动态注入。

好的 Hook 输出应该像这样：

## Runtime Project State
- branch: feature/payment-refactor
- git status: 3 modified files
- last test: failed, 2 failing tests
- server: running on port 3000

短、准、有来源，模型就能用。

---

这套架构最值得借鉴的地方

OpenClaw 这套 System Prompt 设计，最值得抄的不是“9 层”这个数字，而是它背后的几个原则。

原则一：把上下文当成工程资产

System Prompt 不是随便写写的文案，而是会影响稳定性、成本、安全和用户体验的核心配置。

原则二：区分谁控制什么

框架该锁死的锁死，用户该能改的开放。否则要么不安全，要么不可定制。

原则三：静态和动态分开

身份、偏好、项目规则是静态的；时间、状态、日志、会话是动态的。混在一起只会越来越乱。

原则四：让 Agent 学会少说话

会回答很重要，会沉默也重要。尤其在群聊、自动化、心跳场景里，不打扰本身就是能力。

原则五：用技能沉淀流程，而不是堆长 prompt

长期助手真正的成长，不是 System Prompt 越写越长，而是把可复用流程变成技能，把稳定事实变成记忆，把实时状态交给 Hook。

---

结语：真正的大脑，是模型和上下文一起长出来的

OpenClaw 的 System Prompt 拆开看，是 9 层配置；合起来看，是一个 AI 助手的运行时人格。

模型提供推理能力，工具提供行动能力，技能提供经验，记忆提供连续性，协议提供场合感，运行时上下文提供现实感。

少了任何一块，助手都会退化：

• 没有工具，它只是会聊天；
• 没有记忆，它每次都像第一次见你；
• 没有协议，它会在不该说话时乱说；
• 没有动态上下文，它会对现实环境失明；
• 没有用户可控层，它就很难真正成为“你的”助手。

所以，一个 AI 助手的 System Prompt 不是一段神奇咒语，而是一套持续演化的上下文系统。

你真正要打造的，也不是一份完美提示词，而是一个能被维护、能被压缩、能被扩展、能记住你、也知道什么时候该闭嘴的数字大脑。

---

原文作者：@servasyy_ai，版本 v2.1，更新时间 2026-03-05。本文为基于原文主题的重写与扩展整理。