OpenClaw Context Engine 深度探索系列2:OpenClaw上下文里有什么

OpenClaw上下文里有什么

上一篇OpenClaw Context Engine 深度探索系列1：理解 AI Agent 的上下文管理介绍了什么是上下文管理及为什么要做上下文管理， 本篇文章我们来拆解OpenClaw上下文有什么？

OpenClaw上下文有什么，先给一张全景图：

五样东西抢一块地。每一样都觉得自己重要，加在一起，留给模型”真正思考”的空间就被挤得所剩无几了，下面我们来详细拆解这五样东西。

System Prompt ：拼出来的地基

OpenClaw 的 System Prompt 不是一段写死的文本，而是在每次对话启动时动态拼装放在上下文中。源码 src/agents/system-prompt.ts 里有个核心函数 buildAgentSystemPrompt()，接收几十个参数，按固定顺序把模块搭上去——像盖楼，先打地基，再砌墙，最后封顶。

它回答了 Agent 运行的几个根本问题：你是谁？能做什么？守什么规矩？在哪干活？怎么回忆过去？

三种模式对应三种场景：

拆开看几个关键模块。

# 模块 1：身份标识 [永远存在] 这一行永远存在，告诉OpenClaw「你是谁」。即使在none模式下，也会有这一行。You are OpenClaw, a personal AI assistant.# 模块 2：工具清单 [full/minimal]这个模块列出了OpenClaw当前可以使用的所有工具，包括文件操作、网络搜索、消息发送等。工具名称区分大小写，OpenClaw必须严格按照名字调用。## Available ToolsTool names are case-sensitive.- read: Read file contents- write: Write to file- edit: Edit existing file...# 模块3：OpenClaw CLI操作指令 [full] 列出常用的聊天命令，比如：- /status — 查看系统状态- /new — 开始新对话- /compact — 手动触发上下文压缩- /think — 调整思考深度# 模块 6：技能（Agent Skills）—— 条件加载 [full, 有技能时] 如果有技能（Skill）被注册，就会加载这段指令，OpenClaw不会预先加载所有技能的详细内容，而是先扫描技能列表（只看名字和描述），判断需要用哪个，再去读对应的SKILL.md。这样既节省了上下文空间，又保持了灵活性。## Skills (mandatory)Before replying: scan <available_skills> <description> entries.- If exactly one skill clearly applies: read its SKILL.md, then follow it.- If multiple could apply: choose the most specific one.- If none clearly apply: do not read any SKILL.md.Constraints: never read more than one skill up front.#模块 7：记忆召回 —— 条件加载 [full, 有记忆工具时] 只有当 memory_search 和 memory_get 工具可用时才会加载，这段话告诉OpenClaw，在回答任何关于「之前做过什么」「之前说过什么」的问题时，必须先搜索记忆，不能凭空编造，主要是为了防止大模型「幻觉」。## Memory RecallBefore answering anything about prior work, decisions, dates, people,preferences, or todos: run memory_search on MEMORY.md + memory/*.md;then use memory_get to pull only the needed lines.If low confidence after search, say you checked.#模块 8：工作区信息（Workspace）[full/minimal] 这是告诉OpenClaw当前的工作目录在哪里。## WorkspaceWorking directory: ~/.openclaw/workspace# 模块 9：Workspace的文件注入 [full/minimal]这是一个非常关键的步骤——系统会把工作区中的Markdown文件直接注入到提示词中，注意：这里和SKILL.md的渐进式披露不一样哦# Project Context## AGENTS.md --Agent运行的核心规范要求[文件内容]## SOUL.md -描述了这只“龙虾”的人格特质、性格倾向、说话风格甚至价值观。[文件内容]## USER.md - 记录了用户的个性化信息，包括称呼、偏好、厌恶、习惯等。正是通过对这些隐私数据的持续学习和引用，“龙虾”才能做到“越来越懂你”，实现真正的个性化服务。[文件内容]## IDENTITY.md -你可以理解为这就是“龙虾”的“身份证”，它的外在标识，比如名字、类型、头像风格等。[文件内容]## TOOLS.md -动态记录当前环境下可用的工具信息及其使用说明，确保Agent知道“手里有什么武器”。[文件内容]如果检测到 SOUL.md 存在，还会额外添加一条指令，让AI「扮演」SOUL.md中定义的人格。SOUL.md detected — embody its persona and tone.

Skill 的渐进披露：先看菜单，再点菜

之前有篇文章详细介绍了Skill 的加载逻辑，可以参考这篇：Skill怎么写？Anthropic官方揭秘：写好Skill的9条铁律

Agent 启动时，上下文里只有一份”菜单”——每个 Skill 的名字和一句话描述，大约 100+ token 一条。 10 个 Skill 也就 1000 token ，成本可控。

当用户的问题触发某个 Skill 时， Agent 才去读完整的 SKILL.md把内容加载进上下文 。这就像在餐厅：你不会把整本菜单的食材清单和烹饪步骤全背下来，你只看菜名和简介，点了再上菜。

约束也很明确：一次最多读一个 Skill 。多个 Skill 都可能相关？选最具体的那个。都不沾边？一个都不读。

这个设计把”可用性”和”经济性”卡在了一个不错的平衡点上。但代价是——Agent 必须在只看菜名的情况下做出正确判断，选错了就跑偏。

这让我想起一个类比：你去看病，分诊台的护士只凭你一句话决定你挂什么科。说”肚子疼”，消化科还是妇科？如果描述不够精确，路由就错了。 Skill 的路由决策本质上面临同样的问题。

在整个过程中，所用到的Skill的MD文件以及中间Skill的调用过程，都包含在上下文中。

对话历史和工具调用：两个沉默的吃货

对话历史没什么好说的——保留最近几轮， token 自然增长。但它的增长是无上限的，不干预就会膨胀到溢出。

工具调用才是真正的大胃王。

每次 bash 执行、 HTTP 请求、文件读写，输入输出全部进上下文。一次复杂的工具调用，几千 token 就没了。跑个部署脚本？输出可能直接吃掉十分之一的窗口。

这不是夸张。我见过一个 Agent 跑了三次 shell 命令，上下文从 4K 涨到 30K——其中 90% 是工具的 stdout 输出。大部分内容对后续推理毫无用处，但它们就在那里，占着位置，挤占本就不富裕的空间。

这也是为什么 OpenClaw 有压缩和裁剪逻辑，把冗长的工具输出提炼成摘要，腾出空间。

记忆文件：从日记到总结到按需召回

记忆系统是 OpenClaw 上下文管理里最精巧的部分。不是一块整的，分了三层，每层覆盖不同的时间跨度， token 成本逐级降低。

第一级：日记文件。 每天的重要事件、决策、结论写进 memory/YYYY-MM-D.md。新会话启动时， Agent 只读当天和昨天的日记。这个设计的精妙之处在于——它把”对话历史”转换成了”结构化摘要”。你不需要把过去三天的完整聊天记录全塞进去，两份几百字的日记就够了。 Token 消耗可能降了一个量级。

第二级： MEMORY.md 。 日记是原始记录， MEMORY.md 是提炼后的精华。打个比方：日记是你随手写的备忘录， MEMORY.md 是年底翻备忘录整理出来的年度总结。它不记录对话细节，只保留值得长期记住的判断——”用户是 Python 开发者”、”偏好简洁代码风格，不要过度注释”。

这个文件只在主会话加载，不会泄露给群聊或共享会话。一个容易被忽略但很关键的安全隔离。你在群聊里跟同事讨论项目， Agent 不会把你的个人偏好抖出来。

第三级： memory_search 。 需要回忆更早的内容时，不是把所有记忆文件全量加载，而是根据语义相关性检索，只把命中的片段注入上下文。这是”按需召回”而非”全量加载”。聊项目架构的时候，不会把三个月前讨论午餐吃什么的记忆也拉进来。

三级架构的 token 经济学很清晰：

总成本可控，但覆盖的时间跨度可以无限延伸。

这设计让我想到一个比喻：人的记忆也是这么运作的。短期记忆管当下，长期记忆管”你是谁”，而那些”想不起来但一旦提醒就想起来了”的东西——那不就是向量检索吗？

上下文管理的本质是资源分配

拆完这五个模块，一个事实浮出水面：上下文管理本质是资源分配问题。

128K 的窗口， System Prompt 吃掉两千， Skill 列表几千，对话历史和工具调用几千到几万不等，记忆文件按需占几百到两千。留给模型”思考”的空间，可能不到窗口的 60%。

而每一层设计——渐进披露、分级记忆、条件加载、裁剪压缩——都在做同一件事：在有限的空间里，把”最重要的信息”放进”最该放的位置”。

这个问题没有完美解。你多塞一点上下文，模型就更”了解情况”；但你塞得越多，留给推理的空间就越少。这是一个不可回避的取舍 。

下一篇，我会拆解整个上下文处理的流程：从用户发一条消息开始，到 Agent 生成回复，中间经历了哪些步骤，每一步怎么影响上下文的构成和大小。

那才是真正理解 Agent 系统运转方式的入口。

关注我，给你分享OpenClaw上下文管理深度探索系列文章