理解Agent的上下文是怎么构建的、记忆检索是怎么工作的、钱到底烧在了哪里能帮公司省掉推理费的人才是Agent工程师真正值钱的地方。OpenClaw是2026年初最火的开源AI Agent项目。它在不到两周内GitHub Star数量突破了17.5万。但很多人兴奋地把它跑起来之后都会意识到一个比较严重的问题那就是它实在是太烧token了。任务还没跑几个自己的钱包已经顶不住了。今天这篇文章我想从OpenClaw的上下文架构出发一层一层拆解Agent到底把钱烧在了哪里。拆解完后发现其实OpenClaw的上下文管理做的十分朴素基本上就是尽量往模型的上下文窗口硬塞所有的信息。然后你会看到一个非常有意思的事实随着OpenClaw开始解决这个烧钱的问题OpenClaw的记忆系统进化本质上往Agentic RAG方向靠拢。这个发现直接回答了一个行业里争论不休的问题RAG到底死没死。第一部分OpenClaw 的上下文到底装了什么要理解OpenClaw为什么烧钱你得先理解它每次调用模型的时候到底往上下文窗口里塞了什么东西。OpenClaw每次调LLM上下文由四个部分组成System prompt含项目上下文、注入的workspace文件、skills列表、工具列表和工具schema、会话历史、工具调用和工具返回的结果以及compaction产生的压缩摘要。1. System Prompt每次调用都要付的「入场费」你可以直接用/context list指令来看看这部分的token消耗数量。这部分消耗大约9600个token。这里消耗的token是为了告诉模型怎么作为Agent行动怎么使用工具、怎么推理代码、怎么和你的workspace交互。你没有办法很大幅度的降低这部分的token否则Agent功能就会崩掉所以它是每次调用的固定成本。工具schema又增加了大约8000个token。OpenClaw能用的每一个工具文件读写、代码执行、网页搜索等等都需要一个JSON schema定义来告诉模型怎么调用。当你启用更多skill或者连接MCP服务器时这个数字还会继续上涨。光这两项加起来就是将近1.8万token。你还没说话「入场费」已经收了。再看workspace文件注入注入的workspace文件包括一系列markdown文件AGENTS.md1742字/436 tokenSOUL.md912字/228 tokenTOOLS.md原始54210字被截断到20962字/5241 tokenIDENTITY.md211字/53 tokenUSER.md388字/97 token工具schemaJSON31988字约7997 token注意到没有TOOLS.md这个文件原始有54210个字约13553 token但被截断到了20962字。大文件会按单文件上限被截断默认上限是20000字。OpenClaw还设了一个跨文件的总注入上限默认150000字。这说明什么说明OpenClaw的设计者已经意识到workspace文件注入是个成本大户所以做了截断限制。但即便有截断一个中等复杂度的workspace光系统prompt部分就轻松超过14000 token。2. Skills 列表不是全量加载但也不是零成本系统prompt还包含你加入OpenClaw的Skills列表根据Skill的规范这个列表包含了每个Skill的名称、描述、位置。这个列表有实际的Token开销。当然了因为Skill是渐进式披露所以一开始Skill的具体Prompt不会被包含模型只在需要的时候才去读SKILL.md。但这部分成本也不可忽略。具体成本是多少呢基础开销至少有1个skill时195字符每个skill额外增加97字符加上Skill的名称、描述、位置粗略换算每个skill大约消耗24个token加上你字段的实际长度。所以如果你装了30个skill大概额外增加1000到2000 token。不算巨大但也不是零。3. 会话历史只增不减的雪球这才是真正的坑。每次你和OpenClaw聊天所有历史消息都保存在.openclaw/agents.main/sessions/目录下的JSONL文件里。问题是每次新请求OpenClaw会把整个对话历史发送给模型。更夸张的是工具返回结果的膨胀。工具的输出结果会被永久存储在session的JSONL文件中。一旦发生这种情况后续的每一条消息都会拖着这些记录前进导致Token消耗数指数级增长。4. Compaction安全阀但有代价当上下文快要爆了怎么办OpenClaw有一个compaction机制也就是压缩。当session超过上下文限制时compaction会丢弃信息进行摘要。解决方案是当session接近阈值时阈值的计算公式为contextWindow - reserveTokensFloor - softThresholdTokens即模型默认的上下文窗口大小减去一个最低的预留量再减去一个提前预警缓冲量。设置最低预留量是因为模型进行摘要也要消耗上下文。缓冲量相当于一个安全区相当于一个预警。OpenClaw会触发一个静默的agentic turn提醒模型在compaction发生之前把持久化记忆写到磁盘上。对于200K的上下文窗口默认设置下20K reserve4K soft threshold这会在大约176K token时触发。第二部分记忆系统 Agentic RAG到这里我们已经看到了Agent的短期记忆是怎么烧钱的。但Agent还需要「长期记忆」跨session的持久记忆。这才是OpenClaw架构中最有意思的部分。OpenClaw最迷人的地方就是它能够扮演一个对你十分了解的助手你感觉它好像对你的一切都记得。但这个机制的实现其实特别粗暴甚至在最初版本时这个机制是直接靠堆积上下文进行的。目前较新的版本才做了优化。Markdown 文件就是 Source of TruthOpenClaw的记忆是agent workspace中的纯Markdown文件。这些文件就是source of truth。模型只「记住」写到磁盘上的内容。默认的workspace布局使用两个记忆层每日日志append-onlysession启动时只加载今天和昨天的日志长期策划记忆 MEMORY.md只在主要的私有session中加载这个设计决策是OpenClaw方案的特别之处所有记忆都以纯Markdown文件存储在本地文件系统中。每次session结束后AI会自动将更新写入这些Markdown日志。我们可以打开这些Markdown文件直接编辑它们随时查看AI记住了什么。这些记忆对人类来说都是透明的。检索方式两个工具 Agentic RAG关键来了。这些记忆文件不是全量塞进上下文的。OpenClaw暴露了两个工具memory_search对索引片段做语义召回memory_get针对性读取特定Markdown文件范围这就是典型的Agentic RAG。Agent自己决定什么时候要搜、搜什么关键词然后把检索到的片段注入到当前的对话上下文里。不是你告诉它搜什么是它自己判断。混合搜索BM25 向量 MMR检索的底层不是简单的向量匹配。而是通过混合检索进行。向量搜索擅长「这意味着同一件事」的匹配但对精确的、高信号的token如错误字符串很弱BM25正好相反擅长精确token匹配但不善于处理改述混合搜索是务实的折中同时使用两种检索信号让「自然语言」查询和「大海捞针」查询都能得到好结果。当向量和关键词结果都可用时通过加权分数合并默认权重是vectorWeight0.7、textWeight0.3归一化到和为1.0。结果按finalScore降序排列。合并之后还有后处理。MMR最大边际相关性对结果做重排平衡相关性和多样性确保top结果覆盖查询的不同方面而不是重复相同的信息。QMD 后端升级版本地RAG设置memory.backend qmd可以把内置的SQLite索引器替换成QMD一个本地优先的搜索sidecar结合BM25 向量 重排序。Markdown依然是source of truthOpenClaw调用QMD进行检索。QMDQuery Markup Documents是Shopify创建的本地Markdown搜索引擎。它结合三种搜索方式BM25全文搜索处理快速关键词匹配向量语义搜索使用本地GGUF模型找概念相似的内容混合搜索通过Reciprocal Rank Fusion合并结果再用本地LLM做重排序。全部本地运行无API Key无云依赖。相比注入成千上万无关的token你得到的是精准的检索BM25做精确匹配向量搜索做语义相似度LLM重排做精度保证。全部本地运行零云端成本零数据泄露。OpenClaw的memory_searchmemory_get 混合搜索 MMR QMD本质上就是一套完整的Agentic RAG系统只是它被内化到了Agent的认知架构里。为什么 RAG 不会死讲了这么多OpenClaw的架构和成本现在可以回答那个行业里争论不休的问题了。2026年初每当一个新模型发布更大的上下文窗口社交媒体上就会冒出一波「RAG已死」的宣言。但这些宣言误解了RAG的目的以及为什么它在AI中始终有一席之地。OpenClaw的架构恰好给了我们一个最好的反驳案例。理由一最火的 Agent 自己就在用 RAG你看到了OpenClaw这个最火的Agent应用在上下文管理爆炸的痛点下依然对其记忆系统进行了RAG架构的改进。如果RAG真的死了为什么最成功的Agent还在用它理由二成本问题成本问题在任何情况都是开发者需要考虑的。除非说未来大模型的token成本无限趋近于零否则这部分成本依然会让大部分人吃不消。理由三上下文窗口大了 ≠ 模型用得好了研究一致表明模型在远未达到其官方上下文窗口限制时就已经出现性能下降。这就是为什么OpenClaw的memory_search只默认返回top 6条结果每条限制在约700字符。它不是给你整个图书馆它是给你最相关的那几页。这就是RAG的核心价值。理由四RAG 正在变成「上下文引擎」RAG正在经历自己的深刻蜕变从「检索增强生成」这一特定模式进化为以「智能检索」为核心能力的「上下文引擎」。这个演化趋势现在已经不可逆转。OpenClaw的整个架构从系统prompt的workspace文件注入到skills的懒加载到memory_search的混合检索到compaction前的flush。全部都是上下文工程。而上下文工程的核心就是RAG的进化形态。有人说得好「声称大型LLM上下文窗口取代了RAG就像说因为有了足够的内存就不需要硬盘了。」你的电脑有磁盘、内存和网卡是有原因的。它们服务于不同的目的作为一个系统一起工作。总结OpenClaw给我们上了一课。它用最极致的方式验证了一件事Agent的成本本质上是一个上下文工程问题。系统prompt的固定税、会话历史的滚雪球、工具输出的垃圾堆积、心跳的静默消耗所有这些成本都指向同一个问题你往上下文窗口里塞了多少token。而解决这个问题的方法依然还是精准地检索和注入这正是RAG一直在做的事情。RAG没有死。它成为了上下文工程极其重要的一环。然后以Agentic RAG的形态嵌入到了每一个Agent框架里。理解Agent的上下文是怎么构建的、记忆检索是怎么工作的、钱到底烧在了哪里能帮公司省掉推理费的人才是Agent工程师真正值钱的地方。转载https://www.douyin.com/article/7612505265002401074