然而，现实给了我们一记重击。正如许多一线开发者和研究者所发现的，更长的上下文并不会自动生成更好的回复。一个臃肿、混乱的上下文往往是导致AI Agent表现不佳、甚至彻底失败的罪魁祸首。
这门管理、塑造和优化模型上下文的技术，就是今天我们要探讨的核心主题——上下文工程（Context Engineering）。
本文对Drew Breunig的博客《How Long Contexts Fail》、《How to Fix Your Context》和 Manus的博客《AI代理的上下文工程：构建Manus的经验教训》做了深度解构和重组。
如果你正在构建 Agent 系统、研究提示词调度、RAG 链路、踩过cache miss、上下文错乱、模型行为漂移等无数坑，本文将给你一些解决思路和经验：
- 诊断问题：首先，我们将深入了解长上下文是如何以四种方式失效的。
- 对症下药：接着，我们将学习六种行之有效的策略，来修复和管理上下文。
- 实战经验：最后，我们将从Manus的实战经验中，汲取上下文工程技巧。
准备好了吗？让我们开始吧。
长上下文如何失效？
给你的模型塞入过多信息，就像试图让一个人在嘈杂的派对上同时进行五场深度对话一样，结果往往是灾难性的。上下文可能会被污染、分散注意力、变得混乱或相互冲突。对于依赖上下文来收集信息、综合发现和协调行动的Agent来说，这尤其致命。
1. 上下文污染 (Context Poisoning)
上下文污染是指当幻觉或其他错误进入Context后，被反复引用。
想象一个正在玩《宝可梦》的AI Agent。在某一步，它产生了一个幻觉，错误地认为自己学会了一个新技能。这个错误信息一旦进入了它的上下文（比如“当前状态”或“历史记录”），就会像毒药一样蔓延。Agent会基于这个错误的“事实”制定荒谬的策略，固执地尝试使用一个根本不存在的技能，最终陷入死循环。
Deep Mind在Gemini的技术报告中明确指出了这个问题：模型可能会执着于实现不可能或不相关的目标，仅仅因为它的上下文被错误信息“污染”了。
2. 上下文分心 (Context Distraction)
上下文分心是指当上下文变得过长，导致模型过度关注上下文内容，而忽略了其在训练中学到的知识。
随着Agent与环境的交互，它的上下文历史记录会不断增长。当这个历史记录变得极其庞大时（例如超过10万个token），一个怪异的现象出现了：Agent不再利用其庞大的、在训练中学到的知识来创造性地解决问题，反而开始模仿和重复其历史记录中的行为。
这就像一个经验丰富的老兵，因为回忆录写得太长，结果忘了自己除了写回忆录之外还会打仗。Gemini的宝可梦Agent就表现出了这种倾向。Databricks的研究也发现，即使是Llama 3.1 405b这样的大模型，在上下文超过3.2万token后，正确率也开始下降。
超大上下文窗口在总结和事实检索任务中表现优异，但在需要多步生成式推理的Agent任务中，过长的上下文可能是一种诅咒。
3. 上下文混淆 (Context Confusion)
上下文混淆是指当上下文中多余的内容被模型用来生成低质量的回复时。
“连接万物”的MCP（Model-Connects-to-Everything-Protocol）曾是热门概念：给模型提供所有可用的工具，让它自由选择。然而，现实是，工具太多，模型会晕。
Berkeley的函数调用排行榜显示，当提供超过一个工具时，几乎所有模型的表现都会变差。更糟糕的是，在被要求不调用任何工具的场景下，模型们还是会偶尔调用不相关的工具。
一个惊人的案例是：一个Llama 3.1 8b模型，在面对包含46个工具的查询时失败了；但当工具被精简到19个时，它却成功了。这里的瓶颈不是上下文窗口大小，而是模型的“认知负荷”。你放进上下文里的任何东西，模型都必须去关注它，哪怕它完全不相关。
4. 上下文冲突 (Context Clash)
上下文冲突是指当你在上下文中累积的新信息和工具与上下文中的其他信息发生冲突时。
这是“上下文混淆”的升级版。不只是不相关，而是信息之间直接自相矛盾。
微软和Salesforce的一项研究完美地展示了这一点。他们将一个完整的、一次性给出的提示，拆分成了多轮对话。
结果令人震惊：模型表现平均下降了39%！强如OpenAI的o3模型，得分也从98.1暴跌至64.1。
为什么会这样？ 因为在多轮对话中，模型在获得全部信息前，会进行一些早期的、不成熟的尝试。这些错误的尝试和假设留在了上下文中，像幽灵一样干扰着最终的决策。模型一旦“走错了路，就很难再找回来”。
这对Agent构建者来说是个噩梦，因为Agent天生就是从不同来源（文档、工具、子任务）拼凑上下文的，这大大增加了信息冲突的风险。
如何修复你的上下文？
既然我们已经了解了上下文失效的种种方式，是时候了解如何治愈这些问题了。总体而言，我们对修复上下文失效有六大策略。
1. RAG (检索增强生成)
RAG是指有选择性地添加相关信息，以帮助大语言模型（LLM）生成更好的回复。
每当有更大上下文窗口的模型发布，“RAG已死”的论调就会甚嚣尘上。但事实是，RAG活力依旧。与其把整个图书馆都塞给模型（造成Context混淆），不如只给它最相关的那几页书。精准的检索永远比盲目的堆砌更有效。
2. 工具配置（Tool Loadout)
Tool Loadout是指只选择相关的工具定义添加到你的上下文中。
“Loadout”是一个游戏术语，指你为特定任务选择的装备组合。在上下文工程中，这意味着不要把你的整个工具箱都给Agent，只给它这次任务需要的几件工具。
实现方式多种多样：
- 用RAG选择工具：将工具描述存储在向量数据库中，根据用户查询检索最相关的工具。研究表明，当工具超过30个时，这种筛选至关重要。
- 用LLM推荐工具：使用一个专门的LLM来推理“需要哪些工具”，然后进行语义搜索来确定最终的“loadout”。这种方法在Berkeley函数调用排行榜上将Llama 3.1 8b的性能提升了44%，同时还节省了18%的功耗和77%的速度。
3. 上下文隔离 (Context Quarantine)
上下文隔离是指将不同的上下文隔离在各自专用的线程中，每个线程由一个或多个LLM单独使用。
这是“分而治之”的智慧。Anthropic的多智能体系统（见Claude “深度研究”功能实现剖析）就是一个绝佳范例。当面对一个复杂的“深度研究”时，他们不是让一个Agent处理所有事情，而是：
- 分解任务：主Agent将问题分解为多个子问题。
- 并行处理：多个子Agent在各自独立的上下文窗口中，带着专用的工具和提示，并行地研究这些子问题。
- 汇总提炼：子Agent将它们的发现提炼后，汇报给主Agent。
这种方法不仅速度更快，而且通过保持每个上下文的专注和纯净，显著提高了结果质量。Anthropic报告称，其多Agent系统比单个Agent的表现优越90.2%。
4. 上下文修剪 (Context Pruning)
上下文修剪是指从上下文中移除不相关或不需要的信息。
就像园丁修剪植物一样，我们也需要定期修剪我们的上下文。你可以让主LLM来做，也可以使用专门的工具。例如，Provence是一个高效的上下文修剪器，它可以将一篇维基百科文章削减95%的内容，只留下与问题最相关的部分。
from transformers import AutoModel
provence = AutoModel.from_pretrained("naver/provence-reranker-debertav3-v1", trust_remote_code=True)
# 读入一篇关于阿拉米达市的维基百科文章
withopen('alameda_wiki.md','r', encoding='utf-8')as f:
alameda_wiki = f.read()
# 针对一个问题修剪文章
question ='我有哪些离开阿拉米达市的选项？'
provence_output = provence.process(question, alameda_wiki)
专业提示：维护一个结构化的上下文（比如Python字典），将指令、文档、历史等分离开，这样在修剪时就能更精确、更安全。
5. 上下文摘要 (Context Summarization)
上下文摘要是指将累积的上下文浓缩成一个精简的总结。
摘要最初是为了应对小上下文窗口的限制。但现在，它有了新的更重要的作用：防止上下文分心。当Agent的历史记录变得过长时，定期让一个LLM将其总结成一个简短的回顾，可以帮助Agent保持对核心目标的关注，而不是在历史的细节中迷失。
6. 上下文卸载 (Context Offloading)
上下文卸载是指将信息存储在LLM的上下文之外，通常通过一个能存储和管理数据的工具来实现。
这可能是我最喜欢的策略，因为它简单得令人难以置信。Anthropic称之为“think”工具，但叫它scratchpad（草稿本）可能更贴切。
它就是一个给模型用的笔记本。 模型可以在这个“笔记本”里写下中间步骤、思考过程、临时发现等。这些笔记不会污染主上下文，但又可以在需要时被读取。这在处理多步工具调用或需要遵循复杂规则时尤其有效。Anthropic的报告显示，结合使用“草稿本”和特定领域的提示，可以将Agent的基准测试性能提升高达54%。
来自Manus的上下文工程经验
理论和策略固然重要，但真正的智慧往往来自于残酷的实战。AI Agent公司Manus将其成功押注于上下文工程，并通过四次重构和无数次实验，沉淀出了宝贵的经验。
以下是他们在实战中总结出的六条黄金法则。
1. 围绕KV缓存进行设计
KV缓存是LLM推理的核心加速技术。它能缓存已经计算过的前缀（prompt），从而极大地降低延迟和成本。对于Agent这种“输入长、输出短”（Manus的输入输出比约为100:1）的场景，KV缓存命中率是最重要的单一指标。
如何提高KV缓存命中率？
- 保持提示前缀稳定：不要在系统提示的开头加入时间戳这种易变内容，哪怕一个token的改变都会让后续缓存全部失效。
- 上下文只追加，不修改：确保你的历史记录是append-only的。序列化JSON时也要注意键的顺序，否则会悄无声息地破坏缓存。
- 明确标记缓存断点：如果你的推理框架需要，请手动设置缓存断点。
2. 遮蔽，而非移除 (Mask, Don't Remove)
当工具太多导致“上下文混淆”时，一个自然的反应是动态加载工具。但Manus的实验表明：除非万不得已，不要在迭代中动态增删工具。因为这会改变上下文前部，导致KV缓存大规模失效，并且会让模型对历史记录中引用了已移除工具的步骤感到困惑。
更好的方法是“遮蔽”。工具定义始终在上下文中，但通过控制解码过程，在特定状态下“屏蔽”掉不可用的工具。
Manus通过预填充回复来强制模型选择（或不选择）某些工具，例如：
- 必需调用：预填充
<|im_start|>assistant<tool_call> - 指定调用：预填充到工具名称的前缀，如
<|im_start|>assistant<tool_call>{"name": "browser_
这种方法既能约束模型的行为，又保持了上下文的稳定性，最大化了KV缓存的利用。
3. 使用文件系统作为上下文
128K的上下文窗口听起来很大，但在真实世界中（比如处理一个网页或PDF），它很快就会被填满。而且长上下文会降低性能、增加成本。
激进的压缩或截断会导致不可逆的信息丢失。Manus的解决方案是：将文件系统视为终极上下文。
模型学会了按需读写文件，将文件系统用作一个大小不受限、天然持久化的外部记忆。压缩策略也变得可恢复：例如，网页内容可以从上下文中移除，只要保留URL即可；文档内容可以省略，只要文件路径还在沙盒中。这样既缩短了上下文，又不会永久丢失信息。
4. 通过复述操控注意力
你可能注意到Manus在处理复杂任务时，会创建一个todo.md文件，并不断更新它。这是一种刻意的注意力操控机制。
在一个平均需要50次工具调用的长任务中，Agent很容易偏离目标。通过在每次迭代后重写待办事项列表，Manus将全局计划 “复述”到上下文的末尾，这使得任务目标始终处于模型的“近期注意力”范围内，有效避免了“迷失在中间”（lost-in-the-middle）的问题。
5. 保留错误的内容
Agent会犯错。一个常见的冲动是清理这些错误，假装无事发生。但Manus的经验恰恰相反：将错误的尝试和失败的观察结果保留在上下文中。
当模型看到一个失败的动作以及由此产生的错误信息（如堆栈跟踪）时，它会隐式地更新其内部信念，从而大大降低重复相同错误的可能性。从错误中学习的能力，是真正Agent行为的最明显指标之一。擦除失败，就是擦除学习的机会。
6. 不要被少样本示例所困
少样本提示词（Few-shot prompting）是常用技巧，但在Agent中可能适得其反。模型是优秀的模仿者，如果你的上下文中充满了相似的“动作-观察”对，模型会倾向于遵循这个模式，哪怕它已不再是最优解。
例如，在审查20份简历时，Agent可能会陷入一种节奏，对所有简历执行完全相同的操作，从而忽略个体差异。
解决方法是增加多样性。Manus会有意在上下文的动作和观察中引入少量结构化变化——不同的序列化模板、替代性措辞、微小的格式噪音。这种受控的随机性有助于打破模式，让Agent保持“清醒”。
结论
我们从一个美好的梦想开始：无限的上下文将解锁无所不能的AI。但很快发现，上下文是一把双刃剑。上下文工程——这门巧妙地填充、管理、塑造上下文的艺术——才是构建高效、可靠、可扩展AI Agent的核心。
它要求我们从盲目堆砌转向精准供给（RAG、Tool Loadout），从单一作战转向协同处理（上下文隔离），从被动接受转向主动维护（修剪、总结、卸载），并从实战中学习更高级的生存法则，比如拥抱缓存、遮蔽而非移除、利用外部记忆、操控注意力、从错误中学习以及打破思维定势。
模型会变得更强、更快、更经济，但再多的算力也无法替代对记忆、环境和反馈的精心设计。
#Agent #智能体 #上下文 #上下文工程 #Context
