Context Engineering：让 AI Agent 活得更久、更聪明的那把钥匙

"语言模型活在当下，它只看得见现在给的内容。"

为什么我们需要 Context Engineering？

语言模型的上下文窗口是有限的，但我们希望 Agent 能"活得久"、能"记住事"、还能"越做越聪明"。

语言模型本质上是在做「文字接龙」，它有两个致命弱点：

活在当下 ：它不记得之前的交互，除非你把历史记录全部喂给它。
容量有限 ：Token 长度有上限，输入太长不仅贵，模型还会"迷失"。

当我们让它完成复杂任务时，问题出现了：

模型调用工具一，得到输出；

再调用工具二，得到输出；

……

每一轮，都要把 所有历史记录 拼在一起，整个塞给模型。随着步骤增加，结果就是：上下文长度指数级爆炸 ，不做任何管理的话，很快Token就会超过模型的上下文限制。

AI Agent 是拦截在语言模型与外界之间的「守门人」。它不让所有信息涌入，而是决定模型在每一刻能看到什么。

帮语言模型管理输入、动态调整内容、确保输入的长度合适且信息密度最优——这件事，就叫做 Context Engineering 。

Context Engineering 的两大方向

Context Engineering 可以从两个角度入手：压缩（把已有的变短）和过滤（让进来的变少，信息更有效）。

压缩 (Compression)

LLM 摘要（Summarization）

最直接的方法：当历史记录太长，调用一个语言模型，把久远的内容压缩成摘要，再拼回去继续跑。

Context Collapse 陷阱

压缩过头，把 最关键的约束/规则/人类红线 压没了，导致后面表现崩盘。

（经典案例：Meta 收邮件实验，把"必须人工确认才能删邮件"压没了）

也有可能出现，压缩之后，某些关键细节消失了，模型以为自己从没做过某个步骤，于是重复执行，反而跑了更多轮，花了更多 token。

Hard Clear / Observation Masking

在解决软件工程问题（SWE-bench）时，直接把冗长的工具输出替换为一句话——[此处曾有一个工具输出，详见 log1.txt] 或干脆【这里曾经调用过某一个工具】

神奇结论 ：这种简单的处理，有时效果竟然和昂贵的 LLM 摘要差不多，甚至更省钱！

这个简单粗暴的 masking 在性价比上经常不输 LLM 摘要 。

更妙的是，log1.txt 里的内容并不是真的丢掉了——如果模型之后真的需要这段输出，它可以用 read 工具重新读取回来。

把内容存到硬盘，需要时再取出来，就是语言模型的记忆。

最优策略：两种方法结合

有论文实验表明，最佳策略是 分阶段组合使用 ：

前期：用 Hard Clear，把工具的长输出替换掉，保持轻量
后期：当 Context 仍然累积到一定程度，再用 LLM 摘要做一次整体压缩

记忆 (Memory)

把重要的历史挪到硬盘，上下文里只留索引。

常见实现方式：

纯文本：memory/*.md
带时间戳的时序记忆
图结构（Graph Memory）：节点是事件/实体，边是因果/时间/依赖关系
Vector DB + RAG（最常见工业方案）

关键工具设计：

memory_search：语义检索，找出可能相关的记忆文件
memory_get：不是 read 整个文件，而是 从第几行读 N 行

Sub-Agent

还有一种更优雅的压缩思路： 生成子 Agent 。

当主任务的 Context 太长，不如把一个子任务「分包」给一个新的 Agent 去独立完成。子 Agent 跑完后只返回结果，它自己的整个过程不会堆进主干的 context。

这等于把压缩变成了一种自然的任务拆分。

原生模型通常拒绝/不擅长自主 spawn sub-agent ，大多需要专门的 RL 训练或很强的 prompt 诱导。Sub-Agent 的能力需要通过强化学习专门训练出来，还要附加惩罚机制：

主干 Context 过长 → 受到惩罚，逼迫模型主动分包
Sub-Agent 越权、把整个任务自己做完 → 同样受到惩罚

过滤：让进来的信息变少

与其把已经进来的信息压短，不如从源头控制： 只让真正有用的信息进入 Context 。

有论文分析发现，在典型的 Agent 运行中，来自外界的输入（Observation）占据了约 84% 的 Context 空间——读文件、读代码、工具返回的冗长内容，才是真正的「吃 token 大户」。

按需过滤：更智能的读取

解决思路是让「读取工具」更聪明。不再是「把整个文件塞给模型」。

智能阅读 (Smart Read)

不再让模型一次性读完 100MB 的日志，而是开发一个更聪明的工具，让模型说："请帮我从日志中提取出和 Bug 有关的 50 行内容。"

前面说到的 memory_get 的设计异曲同工——它不是普通的 read ，而是支持 指定起始行和行数 的精准读取，防止把整个巨大的记忆文件一次性塞进 Context。

工具按需加载

工具描述本身也会占用大量 Token。比如，仅 GitHub 工具的说明就需要 4600 个 Token。如果把所有工具都放进 System Prompt，模型直接超载。

传统方法：根据用户任务，提前检索相关工具说明。

但问题是用户的需求往往模糊，比如「帮我 debug」，背后可能需要 read、edit、run 等多个工具，很难一次性判断到位。

更好的方法： 让语言模型自己决定需要什么工具 。模型先理解任务，再动态搜索并加载所需的工具说明。这正是 OpenClaw 里 skill 概念的核心—— 技能按需加载，不用的不出现 。

Agentic Context Engineering：把 Context Engineering 交给 AI 自己

以上所有方法，都是人类工程师在AI Agent中「写死」的规则。

有没有可能，让语言模型自己来做 Context Engineering？

这就是 Agentic Context Engineering 的核心思想：

把那个「如何更新 context」的规则，也交给语言模型来决定。让模型自己学会"存未来能复用的策略、代码、关键发现"，而非把所有具体对话都死保。

Dynamic Cheatsheet

模型在执行任务的过程中，会不断更新一份"Playbook（员工守则）"。

它会存下：有效的策略、可重用的代码、关键的发现 。
它会删掉：一次性的、琐碎的干扰信息。

核心精神用一句话概括：

存下未来能用上的东西：有效的策略、可复用的代码、关键的发现——而不是只与当前任务相关的具体细节。

Recursive Language Model

更激进的想法：把无限长的 Context 全部存进硬盘，模型的 Prompt 里只放极简的「元数据」（Metadata）（如 Context 的总长度、分段位置等）。

模型读到元数据后，自己写程序去硬盘里做 RAG 检索，找出此刻真正需要的内容，更新自己的 prompt，再继续工作。

用 prompt engineering 诱导 LLM 保留"高价值模式"而非"低价值细节"

Context 与 Prompt，不是同一回事

最后，值得厘清两个常被混用的概念：

概念	定义
Context	AI Agent 经历的一切——包括存在硬盘里的和放进模型的
Prompt	Context 中真正被送入语言模型的那一部分

Context Engineering 的核心，正是决定：在每一刻，把 Context 的哪一部分作为 Prompt 送给模型。

结语

随着 Context Engineering 技术的不断进化，AI Agent 将会从一个简单的"提示词包装盒"，演变成一个具备自主记忆管理、动态技能调度、自我反思能力的 真正智能体 。

参考

https://www.youtube.com/watch?v=urwDLyNa9FU&t=308s