最近圈内有个非常火的讨论：Prompt Engineering 是不是已经过时了
Shopify CEO Tobi Lutke 最早点燃战火，说他更喜欢Context Engineering这个词。紧接着，Andrej Karpathy 也下场了，认为prompt这个词太窄了，让人联想到chatbot里那些特别短的指令。
在真正的工业级AI应用里，往往不仅仅是几句提示词，而是一个包含任务描述、少量样本、RAG、多模态数据、工具、状态和历史的复杂填充下的上下文窗口。
这不只是改个名那么简单，它代表了构建强大AI Agent的思路转变。
今天，我们就来深入扒一扒，为什么“Context Engineering”如此重要，有哪些坑，以及如何像高手一样驾驭它。
从“Prompt”到“Context”，不只是换个名字
Karpathy 指出，上下文信息给少了，模型性能上不去；给多了或给了不相关的，成本飙升性能还可能下降。一个优秀的工程师，需要有引导LLM“心理”的直觉，知道如何提供恰到好处的信息。
这事儿有多重要？前阵子因为Agent架构打得火热的两个多Agent构建主角——Cognition 和 Anthropic，都把“上下文管理”放到了核心位置。
Cognition (Devin的公司) 强调：上下文工程是AI Agent工程师的“首要任务”。 Anthropic (Claude的公司) 表示：Agent动辄需要数百轮交互，必须采用精细的上下文管理策略。
简单说，上下文工程决定了AI Agent能力的上限。而随着模型上下文窗口越来越大（动辄100万token），很多人以为可以一把梭哈，把所有东西都扔进去。但现实是，这么做往往会把事情搞砸。
上下文越大，模型可能越“笨”
把上下文窗口当成一个无底洞的垃圾抽屉，只会让你的Agent在关键时刻掉链子。
常见的有四大典型翻车现场：
上下文投毒 (Context Poisoning)
当模型的一次幻觉或错误被写入上下文，它就会像病毒一样不断被引用，污染后续的所有决策。
DeepMind 在 Gemini 2.5 的技术报告里就提到了这个坑。他们在让 Agent 玩宝可梦时，Agent 偶尔会产生幻觉，比如“脑补”出一个根本不存在的游戏目标。
这个错误的目标一旦进入上下文，Agent 就会陷入执念，反复尝试一些毫无意义的操作，根本无法自拔。
上下文分心 (Context Distraction)
随着 Agent 工作流的进行，上下文变得越来越长，积累的历史信息反而成了“包袱”，让模型分心，而忽略了自己训练时学到的知识。
去年databricks做过一个LongContext RAG的实验，几乎所有的模型都会有一个上下文长度临界点，当超过之后，性能就开始下降。
还是Gemini 技术报告中那个玩宝可梦的 Gemini Agent，当上下文超过10万个 token 后，它就开始倾向于重复历史记录里的旧操作，而不是创造新的策略。这说明，用于信息检索的长上下文和用于多步推理的长上下文，完全是两码事。
上下文混淆 (Context Confusion)
信息给的太多、太杂，尤其是无关紧要的信息，会导致模型输出质量下降。最典型的例子就是“万能工具箱”（MCP）的设想，以为给模型接上所有工具，它就能搞定一切。
但现实很骨感。Berkeley Function-Calling Leaderboard的数据显示，所有模型在提供多个工具时的表现，都比只提供一个工具时要差。甚至当没有一个工具是相关的时候，模型还是会“手贱”去调用一个不相干的。给Llama 3.1 8b提供46个工具时，它直接罢工了；而只给19个时，任务却成功了。
你放进上下文的任何东西，模型都会被迫去关注它，哪怕是无关的垃圾信息。
上下文冲突 (Context Clash)
这是最麻烦的一种情况。上下文里的不同部分信息相互矛盾，直接让模型精神错乱。
微软和 Salesforce 的发表过一篇研究。他们把一个完整的prompt，拆分成多轮对话的形式。
结果是：模型的平均表现下降了39%，连强大的 GPT-4o 的分数也从98.1暴跌到64.1。
为什么？因为在多轮对话中，模型在早期信息不全时做出的错误尝试和回答，被保留在了上下文里。这些错误的中间产物与后来的正确信息产生冲突，导致模型一条道走到黑，无法纠正最初的错误。这对需要逐步收集信息、调用工具的 Agent 来说是致命的。
上下文管理的六大策略
既然长上下文有这么多坑，我们该如何解决？
RAG
RAG 的思想永远都会存在。按需、精准地为模型提供最相关的信息。不要把整个文档库都扔进去，而是先检索出最相关的片段。这个思想同样适用于后面的工具选择。
工具包定制
工具包这个词一版游戏里边才能看到，指根据任务选择最佳的武器和装备组合。构建 Agent 也是一样，不要一次性加载所有工具，而是动态选择当前任务最需要的工具。
之前我们分享过RAG-MCP也是做了类似的事情。
给MCP加上RAG，Agent准确率起飞？
当工具超过30个时，DeepSeek-v3 的工具选择准确率就开始下降。通过类似 RAG 的方式动态推荐工具，不仅能让 Llama 3.1 8b 的性能提升44%，还能节省18%的能耗和77%的速度，一举三得。
上下文隔离 (Context Quarantine)
一个有效的策略是，将一个大任务分解成多个独立的子任务，每个子任务都在自己独立的、干净的上下文窗口中运行。
Anthropic 的多Agent研究系统就是这么做的。主Agent接到一个复杂问题后，会把它分解成多个子问题，交给多个子Agent并行处理。每个子Agent都有自己的工具和上下文，独立探索，最后将精华信息汇总给主Agent。这种方式不仅快，还能避免上下文污染和分心，最终性能比单个Agent高出90.2%。
上下文剪枝 (Context Pruning)
随着 Agent 不断收集信息，上下文会变得越来越臃肿。我们需要定期修剪掉无关的信息。你可以让主 Agent 来做，也可以用专门的工具。
比如一个 ICLR 2025 有篇论文是关于上下文剪枝的，它可以在几行代码内，将一篇维基百科文章削减95%的内容，同时精确地保留问题的答案。
在 Agent 的工作流中加入这样的步骤，能有效保持上下文的“信噪比”。
上下文总结 (Context Summarization)
这个技巧最初是为了解决上下文窗口大小限制。但现在我们发现，即便窗口够大，定期对历史记录进行总结也至关重要。
前面提到的 Gemini 玩宝可梦的例子就是最好的证明，过长的历史记录会导致“分心”。通过调用一个 LLM，将冗长的对话历史或文档内容压缩成一个简短的摘要，可以有效避免模型陷入重复，让它专注于未来。
上下文卸载 (Context Offloading)
这是我最喜欢的一个策略，简单到你不敢相信它会有效。就是给 Agent 一个“草稿纸”工具。
Anthropic 把这个工具叫做 think。当模型需要进行复杂的推理或处理多步工具调用时，它可以先把中间步骤、分析和计划写到这个“草稿纸”上。这块区域的内容不会污染主上下文，但又可以在需要时被模型随时查阅。这个简单的技巧，在特定任务上带来了高达54%的性能提升。
最后
Karpathy说，上下文工程师的工作就是恰到好处地填充上下文窗口。这正是构建Agent的核心。
从“Prompt Engineering”到“Context Engineering”的转变，标志着我们对LLM应用的理解进入了更深的层次。百万token的上下文窗口不是让我们变得懒惰的借口，恰恰相反，它对我们的信息管理能力提出了更高的要求。
你放进上下文的每一个token，都在塑造模型的行为，或好或坏。
好了，这就是我今天想分享的内容。如果你对构建AI智能体感兴趣，别忘了点赞、关注噢~
