从“工作记忆”到“资源博弈”：AI Agent 的 Context Window 为何是最核心的工程约束？

1. 引言：压垮 AI Agent 的最后一根稻草是什么？

设想这样一个场景：你交给 AI Agent 一个涉及 48 个步骤的复杂客户退货处理任务。它流畅地完成了前 47 步：检索订单详情、检查库存、处理退款、更新了多个系统。一切堪称完美。

然后，在第 48 步，它突然忘记了客户的名字和最初要退的是哪件商品。

你遇到了Context Window（上下文窗口）的极限。

在 AI Agent 工程中，Context Window 不仅仅是“模型能记住多少东西”的度量衡，它更像是一个动态博弈的战场——成本、响应速度、决策质量、系统稳定性，全部被压缩在这个有限的容量里。它是最核心、最硬性的约束之一，决定了一个 Agent 系统能在生产环境中走多远。

2. 核心定义：Context Window 到底是什么？

要理解 Context Window，我们首先需要区分两个极易混淆的概念：上下文（Context）和上下文窗口（Context Window）。

2.1 容器与内容

• 上下文（Context）：这是内容。它是指 Agent 在执行任务时实际可用的全部信息集合，涵盖了系统提示词（System Prompt）、对话历史、工具调用的输入与输出、从向量数据库检索到的文档片段、以及用户的当前输入等。这是一份由开发者通过工程化手段动态构建的动态信息集合。
• 上下文窗口（Context Window）：这是容器。它指大语言模型（LLM）单次推理时所能处理的最大 Token 数量限制。这个容量由模型架构决定，是一个静态且硬性的技术约束。

可以这样理解：上下文是你想塞进箱子里的所有东西，而上下文窗口就是这个箱子的物理容积。

你无法让箱子容纳超过其物理容积的东西。更糟的是，一旦箱子满了，最底下的东西（早期的关键信息）就会被无声无息地挤掉。

2.2 Context Window 里到底装了些什么？

OpenClaw 官方文档清晰列出了 Context Window 中实际承载的内容：

• 系统提示词：包含 Agent 的角色身份、运行规则、工具列表、技能（Skills）元数据以及注入的工作区文件（如AGENTS.md,SOUL.md）。
• 对话历史：当前会话中的全部用户与助手消息。
• 工具调用与结果：每次调用工具（read,exec,web_search等）的指令和返回结果，通常包含大量的命令输出或文件内容。
• 附件与转写：用户上传的图片、音频或文件内容。

2.3 现状速览：主流模型的“箱子”有多大？

仅仅看这些数字会带来巨大的误导。认为“窗口够大，所以问题不存在”是 Agent 工程中最大的思维陷阱之一。

3. 为什么它是 Agent 最核心的约束？

对于简单的问答应用，Context Window 的压力尚可承受。但对于需要执行多步推理和操作的Agentic Workflow，这个约束会迅速变成一个“液压机”，从四个层面挤压你的系统。

3.1 约束一：沉默的崩溃（Silent Degradation）

当上下文窗口被填满后，模型不会报错，它只会礼貌地、自信地继续运作，只不过它的“记忆”里已经丢失了最早期的重要信息。

危险之处：Agent 的执行结果看起来依然逻辑通顺，但决策依据已经残缺不全。例如，Agent 成功“预订”了航班，但完全忘记了你在对话开始时提到的“糖尿病餐食需求”。你在问题发生前，很可能完全无法察觉。

3.2 约束二：“迷失在中间”（Lost in the Middle）

即便你的上下文还有“物理空间”，模型对它“看到”的信息的注意力也不是均匀分布的。研究表明，LLM 对于位于上下文开头和结尾的信息处理效果更好，而对淹没在中间的“500K 位置”的关键细节，其关注度会显著下降，性能也因此大打折扣。

事实是：一个 1M Token 的大窗口，并不等于 1M Token 的完美记忆。信息物理上“在场”，但认知上可能已经“缺席”。

3.3 约束三：Token 消耗与成本的指数级增长

一个 Agent 工作流通常包含 20-50 次甚至更多的 LLM 调用。每一次调用，原始的系统提示词、历史对话和工具结果都像复利一样在原始请求上不断叠加。

以 OpenClaw 为例，仅工具定义的 JSON Schema部分就会消耗~7,997 个 Token，而整个系统提示词在缓存后仍可能占据14,250 Tokens的上下文。当窗口利用率持续逼近 90% 甚至 100%，成本和响应延迟都会失控。

3.4 约束四：上下文污染与级联故障

在复杂任务中，Agent 会进行大量探索性动作。这些对当时有用但对后续决策无意义的信息（如失败的搜索、过时的假设）会堆积在上下文中，形成噪声，这就是“上下文污染”。

4. 工程化突围：如何在硬约束下做文章

面对这一硬约束，优秀的 Agent 系统（如 OpenClaw, Cursor）并不依赖于“无限扩大窗口”，而是通过精心设计的工程策略在约束内优化。

4.1 可视化监控：看清你的“箱子”

在 OpenClaw 中，你可以通过/context list或/context map命令，以清单甚至树状图的形式，精准定位哪些部分（是工具 Schema、系统提示词，还是某个文件）成为了上下文“大户”。无法测量的东西，就无法优化。这一步是第一步。

4.2 技能（Skills）机制：化“全书”为“目录”

这就是前几篇博客中提到的核心概念。OpenClaw 不在 System Prompt 中加载所有 Skills 的完整指令（可能是海量的文本），而是只注入一个轻量的 Skills 列表（名称+描述）。只有当 Agent 判断某个 Skill 与当前任务相关时，才会通过read工具去按需加载其详细的SKILL.md。

4.3 子代理（Subagent）与上下文隔离

子代理不是为了酷炫，而是一种精妙的上下文隔离机制。主 Agent 将搜索、探索、排查等任务委派给子代理。子代理在自己的上下文窗口中消化掉所有过程信息，最后只将一个干净、高浓度的结论返回给主 Agent。这让主 Agent 的上下文免于被临时性的噪声和探索日志污染。

4.4 压缩（Compaction）与滑动窗口（Sliding Window）

当上下文接近满载时，系统会自动触发压缩，将早期的对话历史用 LLM 提炼成一个简洁的摘要，从而释放窗口空间。这就是所谓的“滚动上下文窗口”策略，只保留最近的 N 次交互，以控制成本与延迟。

4.5 分层存储设计

借鉴 Dify 等框架的实践，将上下文分为短期记忆（最近 N 轮对话）、中期摘要（由 LLM 生成压缩摘要）和长期索引（存入向量数据库，供检索增强生成，即 RAG）三部分。这种设计理念也被 OpenClaw 采用，它明确区分了“上下文”与“记忆”：记忆存在硬盘上随时调用，而上下文只在模型当下的“思维”中。

5. 结语：敬畏约束，而非对抗约束

Context Window 是 AI Agent 工程中最诚实的“金丝雀”。它的每一次满载，都在提醒你系统的状态——是决策质量在下降，还是 Token 成本在失控。

真正成熟的 Agent 系统，不是试图用“更大的箱子”来解决所有问题，而是通过精细的工程治理，在有限的箱子内装下最有价值的信息。

Context Window 是你 Agent 的“物理脑容量”。理解它的边界，敬畏它的约束，然后用工程化的方法去驾驭它，这才是构建可靠、稳定 AI 员工的关键。