OpenClaw核心：上下文工程如何让AI更懂你？（万字源码深度解析）

我们之前说过除了记忆系统Agent 是没什么技术难度的。比如你自己做了个 Agent如果只是想用他去装载几个 skill去完成日常自媒体的选题、或者去小红书等平台上自动发发文章那是比较简单的。但如果你想让这个 Agent 越用越好用越用越贴心用的越久它就越懂你这就难办了他会涉及很多问题比如它是如何知道你前天干了什么事情它是如何记住做事的先后次序而没有混乱…要解决这一切就不得不提 Agent 的上下文工程了。在 Manus 时代这个技术就很金贵大家都捂着捂着不想拿出来可 OpenClaw 这波开源一下就让大家看到生产级别的记忆系统是什么样的了。所以你如果问我 OpenClaw 什么最有价值我一定会建议大家去读读他记忆模块的源码那可是进阶利器啊当然我也知道各位时间紧懒任务重所以今天我们特别带着大家一起来拆解 OpenClaw 的记忆模块/上下文工程上下文工程很多人一看到上下文第一反应就是提示词或者 RAG。这个理解不能说是错的但有点片面也就像把写几行代码等同于软件工程一样。在我看来上下文工程是一整套系统性地构建、管理和注入与任务相关的上下文信息的工程方法简单来说上下文工程就是给大模型设计一套高可用、可治理、能长期稳定运行的输入系统那么更具象化一点什么是上下文说白了可能还是提示词它是模型在当前这一轮推理中/提示词中能看到的所有信息的总和。Context System Prompt User Input 历史对话 工具返回结果 检索内容RAG Memory长期记忆所有这些信息拼在一起才是模型真正用来思考、决策、输出答案的全部依据。解决什么问题大模型有三个短板上下文工程就是为了补齐这些短板而存在胡言乱语大模型在训练时从海量互联网数据中学习到了很多知识如果不加以引导模型会泛泛而谈回答不够准确甚至捏造事实上下文工程的任务就是把模型不知道的、最新的、专属的信息精准喂给它。长度限制模型有固定的 Token 上限复杂任务很容易把上下文撑爆。过长内容会让模型注意力分散、抓不住重点、甚至直接报错。上下文工程要做的就是在有限预算里只保留最关键的信息。模型读不懂如果输入信息没有逻辑、没有规范、杂乱无章模型就无法有效解读。上下文工程要做的就是把信息整理成模型能轻松理解的结构化格式。上下文工程的目标所以上下文工程的任务也就出现了他需要引导与约束。用背景、规则、示例给模型划定边界让它只在规定范围内思考和输出。提升准确性。注入最新数据、内部知识库、实时信息从根源减少幻觉。实现复杂任务。把单次无法完成的复杂任务拆成多轮对话、思维链、工具调用引导模型一步步推理落地。如何实现首先提示词工程是上下文工程最核心、最基础的部分。它研究如何用最精确、最有效的语言来提问。然后就行知识检索与注入对于模型不知道或不擅长的领域如公司内部知识、实时信息上下文工程会通过技术手段RAG先把相关信息检索出来然后和问题一起打包送给模型。然后就是对记忆的管理在多轮对话中有效过滤无关信息、保留关键记忆防止模型忘记前文或被过长历史干扰。最后就是输出格式化明确要求模型以特定格式如JSON、Markdown表格输出结果方便后续的程序自动处理。这里特别提一下上下文工程 vs 提示词工程。很多人分不清这两个概念我们用最直白的方式讲清楚提示词工程如何提问、优化指令本身的设计、格式和措辞。上下文工程给什么背景、筛选、加工和注入模型完成任务所需的外部知识和信息。所以可以看出来两者不是对立而是上下层协作。标准工作流永远是上下文工程先行通过 RAG、记忆、工具把最相关的背景资料筛选出来提示词工程收尾把资料 问题用精心设计的模板组装送给模型我知道大家看不懂所以举个真实例子用户问华为最新的旗舰手机是哪一款什么价格- 上下文工程从新闻搜索到华为旗舰手机、价格等信息- 提示词工程设计模板 → 根据以下资料{{context}}回答用户的问题{{query}}至此大家对上下文的基本概率有所了解了我们开始上强度OpenClaw 的上下文工程OpenClaw 的上下文工程采用了流水线架构。整个提示词的组装过程像一条工厂流水线原始数据从一端进入经过一系列处理步骤最终成品完整的提示词从另一端输出。从解析来说可以分为三层第一层资源管理层负责管理所有上下文的信息来源核心工作决定哪些信息必须留、哪些可以删、冲突信息怎么处理。用户配置工作区文档AGENTS.md、TOOLS.md 等对话历史、工具列表、长期记忆第二层组装层把收集到的所有资源按固定格式、固定顺序拼装。模型格式兼容问题历史消息脏数据清理Token 预算内的取舍权衡第三层保护层确保系统安全稳定运行检测上下文是否即将溢出自动触发压缩防止系统因上下文过大崩溃接下来是核心模块的实现上下文引擎可插拔标准接口定义上下文管理全生命周期契约。默认提供传统引擎支持自定义扩展比如接入 RAG接下来按照流程图依次做展开系统提示词构建器生成 Agent 的 身份说明书一段高质量系统提示词他决定了 Agent 的能力上限。你是什么你能做什么你应该遵循什么规则你的工作目录在哪里**Bootstrap 加载器。**读取工作区里的特殊配置文件自动注入提示词AGENTS.md项目行为规则TOOLS.md工具使用说明MEMORY.md长期记忆SOUL.md人格风格会话清理器。修复历史消息里的所有问题保证送给模型的历史干净、合规、兼容的。删除无效工具调用压缩超限图片修复消息顺序错乱处理跨会话消息标记当上下文快撑爆时就启动上下文压缩器自动瘦身不丢关键信息。上下文组装在开始组装任何内容之前系统需要确定模型的上下文窗口大小context window也就是模型一次能够处理的最大 token 数量。不同的模型有不同的上下文窗口小模型可能只有 32K tokens而大模型可能有 200K 甚至更多。OpenClaw 通过四个来源来获取这个数值优先级从高到低是plaintext配置文件中的明确指定开发者可以在 models.providers.{provider}.models[].contextWindow 中明确指定。这个值的优先级最高因为它代表了开发者的明确意图。2. 模型元数据OpenClaw 的模型发现系统会自动从模型提供商获取元数据其中包含上下文窗口信息。3. 默认值如果前两个来源都不可用系统使用 200,000 作为默认值。4. 配置上限最后系统会检查 agents.defaults.contextTokens 配置如果这个值小于前面计算的值会使用这个较小的值作为上限。这可以防止开发者不小心配置了过大的上下文窗口。确定上下文窗口后系统还需要执行保护检查。这里有一个关键的细节**配置上限的覆盖作用**。 即使你在模型配置中明确指定了 contextWindow系统还会检查 agents.defaults.contextTokens 配置。 如果这个值更小会用它作为实际上限这可以防止开发者不小心配置了过大的上下文窗口导致内存问题。 保护检查的阈值 * **硬性最小值16000 tokens**如果上下文窗口低于此值系统会直接阻止运行并抛出错误因为这么小的空间无法支持有意义的对话 * **警告阈值32000 tokens**如果低于此值系统会记录警告日志提醒用户上下文可能不足但不会阻止运行  ### 加载项目上下文 在确定上下文窗口大小后系统开始收集项目特定的上下文信息。这些信息来自工作区中的特殊文件被称为Bootstrap 文件。 Bootstrap 文件是开发者为 Agent 提供的项目说明书例如 plaintext - AGENTS.md告诉 Agent 在这个项目中应该如何表现有哪些特殊的规则要遵循- TOOLS.md解释项目中使用的特殊工具或命令- MEMORY.md或 memory.md记录重要的决策、约定或历史信息确保 Agent 能够记住关键细节- SOUL.md定义 Agent 的人格和语气让它的回复更加一致和有个性- IDENTITY.md定义项目身份和边界说明这个工作区是什么、做什么的- USER.md提供用户特定的偏好和习惯让 Agent 更好地适配用户风格- HEARTBEAT.md用于定时检查任务的指令- BOOTSTRAP.md仅在新工作区首次运行时提供初始化引导系统会按优先级加载这些文件主会话加载全部子 Agent 和心跳运行只加载核心文件AGENTS.md、TOOLS.md、SOUL.md。加载这些文件时系统需要考虑几个问题一、文件大小控制单个文件可能非常大如果全部加载会消耗太多 token。系统会为每个文件设置一个上限默认 20000 字符超出部分会被截断。同时所有文件的总大小也有上限默认 150000 字符当超出时会停止加载新文件。二、会话过滤不同的会话可能需要不同的上下文。系统支持根据会话键session key来过滤哪些文件应该被加载。例如某个 AGENTS.md 文件可能只对特定的会话有效。三、上下文模式系统支持三种上下文模式完整模式full加载所有文件轻量模式lightweight只加载最基本的信息甚至可能完全跳过 Bootstrap 加载无模式none完全不注入项目上下文。轻量模式通常用于子 Agent 或心跳检查因为它们不需要完整的项目背景。管理记忆内容你可能会问Agent 怎么知道我前天干了什么它怎么记住各种决策和约定这就是记忆系统要做的事情。先搞清楚一个重要的区别OpenClaw 的记忆分两层。第一层工作区 Markdown 文件。这是记忆的数据来源。~/.openclaw/workspace/├── MEMORY.md # 长期记忆决策、约定、持久事实└── memory/ ├── 2026-03-20.md # 每日日志 ├── 2026-03-21.md # 今天 └── ...MEMORY.md或小写memory.md存放持久化的内容比如项目约定、重要决策memory/YYYY-MM-DD.md每日流水当天的笔记、临时讨论都往这里写第二层向量索引。让你能搜索这些文件。系统会监控这些文件的变化把它们切分成小块chunks每块约 400 tokens然后用嵌入模型embedding把每块转换成向量。这个索引存储在 SQLite 里位置在~/.openclaw/memory/agentId.sqlite。搜索的时候系统用的是混合检索向量检索负责理解意思。你问那个网络配置的事它能找到关于 “router”、“VLAN” 的讨论哪怕没出现原词。BM25 关键词检索负责精确匹配ID、代码符号、特定的错误信息这些需要精准匹配才行哦两者按权重融合默认向量 70%、关键词 30%然后可选地应用时间衰减最近的笔记权重更高 和 MMR 去重避免返回五条几乎相同的内容。Agent 访问记忆的方式不是所有记忆都会自动注入上下文那样的话 token 就爆炸了。系统只会在主会话中自动注入MEMORY.md的内容memory/*.md文件是通过工具按需访问的memory_search语义搜索返回相关片段memory_get精确读取某个文件的第几行到第几行所以当 Agent 需要知道上次我们怎么处理这个问题的时它会先调用memory_search找到相关片段然后决定是否需要用memory_get读取完整上下文。长期记忆MEMORY.md在 Agent 启动时通过 Bootstrap 系统直接注入到系统提示词中每次对话都会完整加载。每日记忆通过记忆搜索工具按需检索。系统会在每日记忆文件中查找匹配内容并按时间衰减计算相关性越新的内容权重越高。加载可用工具工具列表不是写死的而是根据你的配置动态生成的。工具来自几个地方核心工具OpenClaw 内置的那些read、write、exec、grep、web_search等插件工具各个插件提供的比如memory-core的memory_search、memory_get渠道工具消息渠道插件提供的比如 Discord、Telegram 的message工具但这些工具不会全部都塞给模型一来是提示词容易炸其次是出于工具调用稳定性考虑。系统有一套工具策略在调用模型之前就完成了筛选策略是分层的从粗到细Profile最粗粒度minimal只给最基本的工具coding给开发工具messaging给消息工具Allow/Deny明确允许或禁止特定工具沙箱限制沙箱环境下某些工具会被禁用子 Agent 限制子 Agent 不能用gateway、cron这些系统管理工具群组策略不同群组可以有不同工具权限最终筛选出的工具会被格式化进系统提示词## ToolingTool availability (filtered by policy):- read: Read file contents- write: Create or overwrite files- edit: Make precise edits to files- grep: Search file contents for patterns...每个工具一行名称加简短描述。它告诉 Agent 这个工具是干嘛的什么时候该用。工具在代码里按功能分组但提示词里是平铺的这样更紧凑。加载可用 SkillsSkills 的来源非常丰富这些来源会按照优先级合并额外插件 内置 用户安装 Agents 通用 项目专属 工作区本地也就是说你在工作区定义的 skill 会覆盖系统自带的。这是合理的毕竟你的项目有你的特殊需求。加载 Skills 的时候系统会做几件事扫描目录从各个来源收集所有带SKILL.md的目录解析 Frontmatter读取每个 skill 的元数据名称、描述、是否允许模型调用等过滤筛选根据配置过滤掉不应该启用的 skill比如设置了disableModelInvocation的去重合并同名 skill 只保留优先级最高的Token 预算检查先尝试完整格式名称 描述 路径超出预算则切换到紧凑格式只有名称 路径还是超就截断只保留前面的最终生成的 skills prompt 长这样available_skills skill namecommit/name location~/.openclaw/skills/commit/SKILL.md/location descriptionCreate git commits following project conventions/description/skillskill namereview-pr/name location~/.openclaw/skills/review-pr/SKILL.md/location descriptionReview and merge pull requests with quality checks/description/skill .../available_skills这个列表会被注入到系统提示词的Skills部分并附带指令Before replying: scan available_skills description entries. If exactly one skill clearly applies: read its SKILL.md at location with read, then follow it.构建系统提示词系统提示词是发送给大模型的消息它定义了 Agent 的基础身份和行为准则。OpenClaw 的系统提示词构建器会生成一个结构化的提示词包含多个部分plaintext基础身份声明首先是一个简单的句子You are a personal assistant running inside OpenClaw.“这确立了 Agent 的基本定位。工具列表接下来是 Agent 可以使用的工具列表。这个列表不是简单地把所有工具都列出来而是经过筛选的。系统会检查每个工具是否在当前会话的允许列表中是否被当前的消息渠道支持。对于每个工具系统会提供工具名称和简短描述。描述需要简洁明了让 Agent 知道什么时候应该使用这个工具。工具调用风格指南这部分告诉 Agent 应该如何调用工具。OpenClaw 的设计理念是默认不叙述”——对于常规的、低风险的工具调用Agent 应该直接调用工具而不是向用户解释它要做什么。只有在复杂的多步骤任务、或者在执行敏感操作如删除文件时才需要向用户说明。这种平衡能够提升用户体验避免不必要的对话噪音。安全指令这是一个非常重要的部分它定义了 Agent 的安全边界。指令明确指出 Agent 没有独立的目标不应该追求自我保存、资源获取或权力扩张。它被要求优先考虑安全和人类监督当指令冲突时应该暂停并询问。这些规则受到了 Anthropic 宪法的启发。Skills 引导OpenClaw 支持技能Skills系统允许开发者定义可重用的 Agent 行为模板。系统提示词会告诉 Agent 在回复前扫描可用的技能列表如果发现某个技能明确适用于当前任务应该读取该技能的文档SKILL.md并遵循其指导。但如果多个技能都可能适用应该选择最具体的一个如果没有技能明确适用就不应该读取任何技能文档。记忆召回指令如果启用了记忆搜索功能系统提示词会告诉 Agent 在回答任何关于之前工作、决策、日期、人员、偏好或待办事项的问题时应该先运行记忆搜索然后使用记忆获取工具来拉取需要的行。这确保了 Agent 能够利用长期记忆来提供更好的服务。工作区信息这部分告诉 Agent 它的工作目录在哪里以及应该如何处理文件操作。如果启用了沙箱模式系统会特别说明文件工具和命令执行工具使用的路径是不同的——文件工具使用主机路径而命令执行工具使用容器内的路径。运行时元数据最后系统会附加一些运行时的技术信息包括 Agent ID、主机名、操作系统、架构、Node 版本、当前使用的模型、Shell 类型、消息渠道等。这些信息虽然不直接影响 Agent 的行为但在调试和诊断问题时非常有用。系统提示词的构建还考虑了不同的提示词模式。 对于主 Agent使用完整模式包含所有上述部分。 对于子 Agent使用精简模式只保留工具列表、工作区信息和运行时元数据因为子 Agent 通常处理明确的子任务不需要完整的上下文。 还有一种无模式只保留基础身份声明用于最简单的场景。  ### 清理会话历史 从会话文件中读取的历史消息不能直接发送给大模型它们可能包含各种格式问题、不兼容的内容、或者过时的信息。 系统需要对每条消息进行仔细的清理和修复。 plaintext 跨会话消息标记当消息从一个会话传递到另一个会话时比如用户让 Agent A 向 Agent B 发送消息接收方会话需要知道这条消息来自外部。系统会在这些消息的内容前添加[Inter-session message]前缀并附加来源信息源会话键、源渠道、源工具等让 Agent 能够区分内部消息和外部消息。图像处理图像是非常消耗 token 的内容。系统需要检查每条消息中的图像块确保它们的大小在可接受范围内。如果图像的像素数量或字节数超出了限制系统会对图像进行缩放如果仍然超出则丢弃该图像。这确保了不会因为一张过大的图片而导致整个上下文溢出。思考块处理一些模型如 Claude 的 extended thinking会在回复中包含 thinking 块用于展示模型的内部推理过程。这些思考块对于调试很有用但在某些场景下需要被移除。系统支持根据策略来决定是否保留这些块。工具调用清理历史消息中可能包含对已经不存在或被重命名的工具的调用记录。系统会验证每个工具调用的名称是否在当前的允许列表中如果不允许则移除或标记。此外系统还会确保工具调用和工具结果的正确配对——每个工具调用后面应该有对应的结果消息如果配对关系被打乱系统会尝试修复。工具结果详情剥离工具的结果消息可能包含大量详细信息比如执行输出的完整日志。这些详细信息在某些情况下是有用的但在大多数时候只需要知道操作是否成功。系统支持剥离这些详细信息只保留最核心的结果以节省 token。Usage 快照处理每次模型调用都会产生 token 使用数据input、output、cache read、cache write这些数据被存储在 assistant 消息的 usage 字段中。系统需要确保每个 assistant 消息都有有效的 usage 快照并且在会话压缩后清理过时的快照避免旧的使用数据干扰当前的状态显示。提供商特定处理不同的模型提供商对消息格式有不同的要求。对于 Google/Gemini 模型如果对话以 assistant 消息开头模型会拒绝请求。系统会检测这种情况并在会话开头添加一个引导性的用户消息。为了防止重复修复系统会在会话中添加一个标记记录已经执行过这个修复。对于 OpenAI 的 Responses API系统会将推理块reasoning blocks降级为普通文本因为该 API 不支持原生的推理格式。模型变更检测系统会在会话中记录最后使用的模型信息提供商、API、模型 ID。当检测到模型变更时这可能是提示词格式需要调整的信号系统会相应地调整清理策略。最终上下文组装在收集了系统提示词和清理后的历史消息后系统需要将它们组装成最终的上下文。这个阶段的核心工作是消息排序。会话历史中的消息可能不是按时间顺序排列的特别是在跨会话传递或经过修复后系统需要确保消息是按照正确的时间顺序排列的这样模型才能理解对话的因果关系。系统还需要进行 token 预算检查。它会估算系统提示词和所有历史消息的总 token 数与之前确定的预算进行比较。如果超出预算系统有两种选择触发压缩或者截断最老的消息。在组装过程中系统会特别保护最近的消息。无论采取什么策略来控制上下文大小最近的对话比如最近几轮总是被完整保留的因为它们最有可能与当前任务相关。最终上下文引擎会返回一个组装结果包含有序的消息数组、估计的 token 数量以及可选的系统提示词附加内容某些引擎可能会在这里添加额外的指令。最终验证在将组装好的上下文发送给大模型之前系统会执行最后一次验证确保一切符合模型的要求。提供商验证不同的提供商对消息格式有不同的验证规则。例如Anthropic 要求对话必须以 user 消息开头交替的 user-assistant 轮次不能被打断。OpenAI 则对消息顺序的要求更宽松一些。系统会根据目标提供商执行相应的验证。Schema 清理对于某些提供商如 Google工具的参数定义不能包含某些 JSON Schema 关键字如 patternProperties、additionalProperties、$ref 等。系统会扫描所有工具的定义移除这些不支持的关键字。魔法字符串清理Anthropic 有一个特殊的安全机制如果消息中包含特定的魔法字符串模型会拒绝响应。系统会检测这些字符串并将它们替换为无害的文本。通过这六个阶段原始的用户输入被转换成了一个结构完整、内容相关、格式兼容的提示词准备好被发送给大语言模型。PS这一坨看上去复杂度很高如果做实现可能只需要做一点但从工程稳定性来说就要把这个链路走完上下文压缩长期对话一定会填满上下文窗口只要到了这个时候就会触发压缩plaintext1、自动触发 - 上下文溢出当大模型 API 返回上下文溢出错误时系统会立即触发压缩。这是最常见的触发场景表示当前的上下文已经超出了模型的处理能力。2、自动触发 - 预算阈值系统在每次运行后会检查当前的上下文大小。如果大小超过了预算的一定比例通常是 90%系统会主动触发压缩防止在下一次运行时溢出。3、手动触发用户可以通过发送 /compact 命令来手动触发压缩。这在用户知道对话已经很长想要主动清理历史时很有用。手动触发会跳过阈值检查强制执行压缩。压缩的策略然后 OpenClaw 提供三级压缩策略 plaintext 1、摘要压缩这是最智能的策略。系统会使用大模型来生成早期消息的摘要。摘要会保留关键信息比如讨论了什么任务、做了什么决策、创建了哪些文件。然后系统用摘要替换原始的详细消息大幅减少 token 使用量同时保留对话的连贯性。摘要压缩的质量取决于生成摘要时使用的指令。系统会告诉模型专注于关键任务、决策和标识符如文件名、API 密钥等并保护这些重要信息不被概括掉。2、截断压缩这是最简单的策略。系统直接丢弃早期的消息只保留最近的消息。这种策略速度快不需要额外的模型调用但会永久丢失被丢弃消息中的信息。截断压缩适用于不需要历史上下文的场景或者当摘要压缩本身也可能失败时比如上下文已经大到连摘要请求都无法处理。3、混合压缩这是两种策略的结合。对于非常早期的消息使用摘要压缩对于中期的消息可能直接截断对于最近的消息完整保留。这种策略试图在信息保留和性能之间找到平衡。压缩的执行过程当触发压缩时系统会执行以下步骤1、计算token用量:系统会计算当前的 token 数量。如果有调用方提供的实时 token 数来自最近的模型调用会使用这个值否则系统会估算历史消息的总 token 数。2、设定压缩目标默认压到预算 80%:系统会确定压缩的目标。如果配置的压缩目标是预算系统会尝试将上下文压缩到 token 预算的 80%留出一些安全边际。如果是阈值则压缩到更低的比例。3、生成高质量摘要:它会将早期的消息提取出来构造一个特殊的摘要请求发送给大模型。摘要请求包含明确的指令告诉模型应该关注什么、应该保留什么类型的信息。收到摘要后系统会构建新的消息历史。新的历史以一个特殊的 compactionSummary 消息开头包含生成的摘要文本。然后是那些被保留的未压缩消息通常是最近的消息。4、原子替换会话历史不破坏原始文件):系统会清空会话文件并将新的消息历史写入。这个过程是原子的确保在压缩过程中如果出现错误不会破坏原始的会话文件。5、压缩的安全保护:压缩操作本身也可能消耗大量资源。如果压缩请求发送给大模型后迟迟没有响应或者压缩本身因为上下文过大而失败系统不应该无限期等待。因此OpenClaw 为压缩操作设置了安全超时。默认的超时时间是可以配置的通常设置为几分钟。如果压缩在超时时间内没有完成系统会取消压缩操作并返回错误。此外系统还会监听未捕获的压缩失败。如果压缩在一个无法被 try-catch 捕获的地方失败比如在异步回调中系统会通过事件机制来捕获这些失败触发会话恢复流程。上下文引擎的可扩展设计OpenClaw 的上下文工程系统是围绕可插拔接口设计的。这意味着开发者可以实现自己的上下文引擎来替换默认的行为而不需要修改核心代码。上下文引擎接口上下文引擎是通过 ContextEngine 接口定义。这个接口包含了一组方法覆盖了上下文管理的完整生命周期plaintext引导阶段bootstrap当一个新会话创建时引擎有机会执行初始化工作。它可以读取会话文件导入历史消息建立内部的数据结构。这个方法是可选的简单的引擎可能不需要特殊的引导逻辑。消息摄入ingest/ingestBatch每当有新消息产生时引擎的 ingest 方法会被调用。引擎可以将消息存储在自己的数据库中建立索引或者执行任何其他需要的处理。ingestBatch 方法允许引擎批量处理一个完整对话轮次的所有消息这比多次调用 ingest 更高效。上下文组装assemble这是引擎的核心方法。在每次调用大模型之前这个方法会被调用引擎需要返回一个消息列表这些消息将作为模型的上下文。引擎可以在这里实现智能的上下文选择策略比如使用检索系统找到最相关的历史消息。上下文压缩compact当需要减少 token 使用时这个方法会被调用。引擎可以实现自己的压缩算法不一定是基于摘要的。比如一个基于向量数据库的引擎可能只是简单地减少检索到的消息数量。轮次后处理afterTurn每次模型调用完成后这个方法会被调用。引擎可以在这里执行清理工作更新索引或者触发后台的压缩决策。子代理管理prepareSubagentSpawn/onSubagentEnded这些方法支持多 Agent 协作。当主 Agent 准备生成子 Agent 时prepareSubagentSpawn 会被调用引擎可以为子 Agent 准备隔离的上下文环境。当子 Agent 结束时onSubagentEnded 会被调用引擎可以聚合结果并清理状态。资源释放dispose当会话结束或应用关闭时这个方法会被调用引擎应该释放所有持有的资源比如关闭数据库连接、清理缓存等。### 传统引擎的实现 OpenClaw 默认提供的 LegacyContextEngine 是一个最小化的实现它保持了向后兼容的行为。 对于 ingest 和 afterTurn 方法传统引擎是空操作no-op。这是因为传统的流程中消息的持久化是由 SessionManager 直接处理的不需要引擎干预。 对于 assemble 方法传统引擎也是透传的。它只是返回传入的消息不做任何处理。这是因为传统的流程中上下文的组装、清理、限制等工作是在主运行流程中完成的。 只有 compact 方法有实际的实现。它将压缩请求委托给 compactEmbeddedPiSessionDirect 函数这是现有的压缩逻辑。通过这种委托传统引擎保持了完全的向后兼容性。 这种设计使得新的引擎可以逐步采用。开发者可以从实现简单的引擎开始逐步添加更多功能而不需要一次性重写整个系统。 配置与调优 ----- OpenClaw 的上下文工程系统有丰富的配置选项允许开发者根据自己的需求调整行为。 plaintext contextTokens上下文 Token 预算默认值是 200,000,建议设为模型窗口的 80~90%bootstrapMaxChars单个 Bootstrap 文件最大字符bootstrapTotalMaxChars所有 Bootstrap 总字符上限compaction.mode压缩模式auto/manual/offcompaction.target压缩激进程度(budget/threshold)在 models.providers.{provider}.models[] 配置中可以为每个模型设置特定的上下文窗口大小。这会覆盖自动发现的值适用于模型元数据不准确的情况。models: { providers: { anthropic: { models: [ { id: claude-sonnet-4-20250514, contextWindow: 200000 } ] } }}最后是调优建议监控 Token 使用避免频繁溢出精简 Bootstrap 文件删除冗余内容复杂任务用子 Agent降低主上下文压力根据业务调整压缩阈值平衡连续性与性能结语OpenClaw 这套上下文系统其实就是用有限的 token 预算尽可能把最该给模型看的信息整理好。它先定义好系统提示词的结构什么地方放工具、什么地方放记忆、哪里放技能系统只需要拿数据往里填就行。它灵活、稳定、好调试想自己改也方便比如自己实现一个 ContextEngine 接口就能接进去。今天文章长度很够了大家慢慢看吧下期的重点会放到 Skills 和 多 Agent 上。最近两年大模型发展很迅速在理论研究方面得到很大的拓展基础模型的能力也取得重大突破大模型现在正在积极探索落地的方向如果与各行各业结合起来是未来落地的一个重大研究方向大模型应用工程师年包50w属于中等水平如果想要入门大模型那现在正是最佳时机2025年Agent的元年2026年将会百花齐放相应的应用将覆盖文本视频语音图像等全模态如果你对AI大模型入门感兴趣那么你需要的话可以点击这里大模型重磅福利入门进阶全套104G学习资源包免费分享扫描下方csdn官方合作二维码获取哦给大家推荐一个大模型应用学习路线这个学习路线的具体内容如下第一节提示词工程提示词是用于与AI模型沟通交流的这一部分主要介绍基本概念和相应的实践高级的提示词工程来实现模型最佳效果以现实案例为基础进行案例讲解在企业中除了微调之外最喜欢的就是用提示词工程技术来实现模型性能的提升第二节检索增强生成RAG可能大家经常会看见RAG这个名词这个就是将向量数据库与大模型结合的技术通过外部知识来增强改进提升大模型的回答结果这一部分主要介绍RAG架构与组件从零开始搭建RAG系统生成部署RAG性能优化等第三节微调预训练之后的模型想要在具体任务上进行适配那就需要通过微调来提升模型的性能能满足定制化的需求这一部分主要介绍微调的基础模型适配技术最佳实践的案例以及资源优化等内容第四节模型部署想要把预训练或者微调之后的模型应用于生产实践那就需要部署模型部署分为云端部署和本地部署部署的过程中需要考虑硬件支持服务器性能以及对性能进行优化使用过程中的监控维护等第五节人工智能系统和项目这一部分主要介绍自主人工智能系统包括代理框架决策框架多智能体系统以及实际应用然后通过实践项目应用前面学习到的知识包括端到端的实现行业相关情景等学完上面的大模型应用技术就可以去做一些开源的项目大模型领域现在非常注重项目的落地后续可以学习一些Agent框架等内容上面的资料做了一些整理有需要的同学可以下方添加二维码获取仅供学习使用