OpenClaw Context Engine 深度探索系列1:理解 AI Agent 的上下文管理-夜雨聆风

OpenClaw Context Engine 深度探索系列1:理解 AI Agent 的上下文管理

上下文窗口是 LLM 的 RAM——它决定了 Agent 在任何时刻能”想起”什么。上下文工程，就是决定”在这块有限的内存里放什么”的艺术与科学。

你让 Agent 帮你调试一个生产问题。对话进行了 50 轮，它终于定位到是数据库连接池配置不对。然后你问：”刚才你说的连接池配置是什么来着？”

它回答：”抱歉，我不记得了。”

你愣住了。

50 轮对话，烧了十几万 token ，结果它把关键信息忘了？它没有偷懒，它只是把关键信息”忘”了——因为那段对话被挤出了上下文窗口。这不是智力问题，是记忆管理问题。

理解为什么这是 Agent 系统中最核心的挑战，需要一个更高层的视角。这也是上下文工程那试图解决的根本问题。今天这篇文章，我们从原理出发，彻底理解 AI Agent 的上下文管理。

01 LLM OS ：为什么上下文就是一切

Andrej Karpathy 在 2025 年提出了一个极具洞见的类比：LLM 就像一个操作系统。

不是比喻——是结构性的相似。把它和传统计算机对比一下：

传统计算机	LLM OS	说明
CPU	LLM 模型	核心推理引擎，执行”计算”
RAM	上下文窗口	有限的、易失的工作记忆
硬盘	向量数据库 / 文件系统	持久化存储，跨会话保留
外设	工具（ Tools ）	与外部世界交互的接口
网络 I/O	API / 其他 LLM	与外部服务和其他模型通信

这个类比的核心洞察是什么？

上下文窗口就是 RAM 。它有三个关键特性：

•有限——不管模型号称支持多大窗口，它终究有上限

•易失——对话结束等于断电， RAM 里的内容全部清零

•昂贵——每多放一个 token ，就多烧一份计算和费用

就像操作系统要管理 RAM 的分配和换页一样， Agent 系统也需要管理上下文窗口里放什么、不放什么、什么时候换出去、什么时候调回来。

这就是上下文工程——Agent 系统中最核心的工程问题

02 从Prompt Engineering 到 Context Engineering

你可能听过 Prompt Engineering （提示词工程）——花时间打磨提示词的措辞，让 LLM 给出更好的回答。但在 2025 年，行业的认知发生了一次关键升级。

Shopify CEO Tobi Lutke 说：”Context engineering 比 prompt engineering 更准确地描述了这项核心技能。”

Andrej Karpathy 进一步定义：”在每一个工业级 LLM 应用中， Context Engineering 是精心填充上下文窗口的精妙艺术与科学——放入恰到好处的信息，以获得最佳的下一步行动。”

Anthropic 则把 Context Engineering （上下文工程）称为 Prompt Engineering 的”自然演进”。

一句话定义：Context Engineering 是设计和构建动态系统的学科，该系统在正确的时间向 LLM 提供正确的信息和正确的工具。

它和 Prompt Engineering 有什么本质区别？

维度	Prompt Engineering	Context Engineering
范围	单次交互，优化措辞	系统级，管理整个信息环境
关注点	“怎么说”——措辞技巧	“给什么”——信息选择与编排
适用场景	日常对话、简单任务	生产级 Agent 系统
核心组件	仅Prompt 文本	System Prompt + RAG + Memory + Tools + 状态
失败模式	措辞不当导致理解偏差	上下文污染、过载或关键信息缺失

简单说： Prompt Engineering 关心”如何对模型说话”， Context Engineering 关心”让模型看到什么”。

那么，上下文窗口里到底有什么？这个是OpenClaw的中的上下文内容

来源	典型token占用	增长特性
系统 Prompt/Soul等	500-2000	相对固定
Skill列表	每个约100+ token	随启用Skill数量线性增长
对话历史	无上限增长	随时间持续增长
工具调用记录	每次可达数千	随任务复杂度增长
记忆文件	按需注入	可控但需要策略

每一项都在争夺上下文窗口这块有限的”RAM”空间。上下文工程的核心挑战，就是在这几个维度之间做出最优分配。

记住这句话：“Agent 的失败，本质上是上下文的失败，而不是模型的失败。”

03 Context Rot ：更大的窗口不是万能药

你可能想：既然窗口大小是问题，那用更大的窗口不就行了？

没那么简单。 Chroma 的研究揭示了一个关键现象——Context Rot （上下文腐蚀）：随着上下文中 token 数量增加，模型准确回忆和利用信息的能力会递减。

原因在 Transformer 架构本身。自注意力的计算量与 token 数量呈 $n^2$ 关系： 10K token 需要约 1 亿次注意力计算， 50K token 就是约 25 亿次。计算量的暴增创造的不是一个”硬悬崖”，而是一个性能梯度——信息检索的准确率随着上下文长度逐渐下滑。

核心结论：上下文是有限资源，具有递减的边际回报。往里塞更多信息，不一定能让模型表现更好。

窗口看起来很大，但实际场景中的消耗远超想象。上下文管理要解决四个核心问题：

问题	后果	对应策略
超限	请求直接失败	Compress / Isolate
成本	历史越长越贵	Compress + Prompt Cache
信息丢失	关键上下文被压缩掉	Write + Select
噪音干扰	无关信息降低回答质量	Select + Isolate

这四个问题互相矛盾。没有完美的方案，只有取舍。下面的四策略框架，就是帮你系统性做出这些取舍的工具。

04 上下文工程四策略： Write / Select / Compress / Isolate

LangChain 在 2025 年提出了一个简洁的框架，把上下文工程的所有操作归纳为四种策略。这也是 OpenClaw Context Engine 的核心方法论。

策略一： Write——把信息写到上下文之外

上下文窗口太小？那就别把所有东西都塞进去。

Write 策略的核心是：让 Agent 把信息主动写出到外部存储，需要时再读回来。

最典型的实践是Scratchpad （便签本）模式。 Agent 在执行复杂任务时，维护一个 todo.md 或 NOTES.md 文件，把任务目标、已完成步骤、待解决问题写进去。

OpenClaw的三层记忆系统：

每天的重要事件、决策、结论写进 memory/YYYY-MM-D.md。新会话启动时， Agent 只读当天和昨天的日记。

MEMORY.md — 长期记忆。持久的事实、偏好和决策。会在每个私信会话开始时加载。
主动长期记忆系统

策略二： Select——把相关信息检索回来

Write 把信息写出去了， Select 负责在正确的时刻把正确的信息检索回来。

核心原则是 Just-in-Time （即时）上下文——不是把所有信息预加载到上下文里，而是在需要的时候才去取。

OpenClaw的memory_search :会从你的记忆文件中查找相关笔记，即使措辞与原文不同。它通过将记忆索引成小块，并使用嵌入、关键词或两者来搜索这些小块。

策略三： Compress——压缩上下文

当对话越来越长，上下文窗口逐渐被填满时，就需要压缩、裁剪了。

压缩的核心操作叫 Compaction （压实）：用 LLM 把冗长的对话历史压缩成精炼的摘要，然后用摘要替代原始内容，重新初始化上下文窗口。

OpenClaw的压缩和裁剪：

会话裁剪会在每次 LLM 调用前，从上下文中裁剪旧的工具结果。
当对话接近该限制时，OpenClaw 会将较早的消息压缩成摘要，以便聊天可以继续。

策略四： Isolate——隔离上下文

当一个任务太复杂、一个上下文窗口装不下时，拆分。

Isolate 策略的核心是 Sub-Agent Architecture （子 Agent 架构）：把任务分解给专门的子 Agent ，每个子 Agent 在自己干净的上下文窗口中工作，只把精华结果返回给主 Agent 。

05 Prompt Cache ：让上下文工程可负担

上下文工程有一个现实问题：贵。

Agent 系统的输入和输出 token 比例可以高达 100:1——每生成一个 token 的回答，可能需要处理 100 个 token 的上下文。这意味着输入成本远远超过输出成本。

Prompt Cache 是解决这个问题的关键基础设施。

Prompt Cache可以参考：彻底搞懂KV Cache：大模型推理加速的核心秘密

写在最后

回到开头的那个场景： Agent 忘记了连接池配置。问题不在模型的记忆力，而在于我们没有为它设计一套有效的上下文管理系统。

上下文工程的本质，可以用一句话概括：

“找到最小的高信号 token 集合，最大化期望结果的可能性。”

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