上下文工程的现状：从长上下文到智能体驱动 harness

关键在于知道何时该确定性、何时该概率性

本周，我在 AGNTCon 做了一个简短的演讲，题为“上下文失败与修复”，它算是一种“上下文工程现状”的综述。上下文工程是如何出现的，它走到了哪里，未来又可能走向何方？当模型开发者瞄准新能力时，他们无意中制造了我们作为用户和框架构建者必须克服的挑战。

以下是幻灯片和一份经过轻度编辑的文字稿。一如既往，如有任何反馈、想法或问题，请给我留言。我非常感激。

大家好。感谢今天来参加。我们将一起探讨上下文的失败与修复。

我有一本书即将出版，The Context Engineering Handbook。2025 年 6 月，当我第一次与 O'Reilly 的团队交谈时，他们问了我一个非常合理的问题：“我们怎么知道这不会在几周内就过时？”AI 教科书的问题在于，许多书老化得极快。

我说，我不知道，但我很乐观。就做什么和不做什么给出清晰的指令，并确保这些指令一致且不嘈杂，将永远是 AI 的一个挑战，无论它变得多好。

我们有同事、合作伙伴以及其他我们认识和互动的人，他们是有感知的。他们通过了图灵测试，他们是“AGI”，然而：我们彼此之间仍然很难传达指令、想法和概念。

上下文工程将继续很难。但它会以独特的方式很难，因为模型不是人。你可以对模型如何思考或解释事物做出假设（用任何你喜欢的拟人化词语），但了解它们是如何构建、优化和训练的会有所帮助。它们独特的属性和构造创造了一套我们需要应对的独特失败模式。

那么让我们回顾一下我们是如何走到这一步的。

让我们闪回到 2024 年底。

如果你还记得，那是“RAG 已死”论调的高峰时刻。

当时的希望是：如果我们能把上下文窗口做得足够大，我们就能把整个互联网放进去。我们可以把所有东西都放进去。我们不必有选择性。我们不必构建智能体系统。我们可以把所有东西都塞进去，AI 就解决了。

模型开发者开始瞄准长上下文能力，我们从约 128,000 token 上下文窗口的模型大幅跃升到百万 token 上下文窗口的模型，始于 Gemini 1.5。

如果你看看 Gemini 1.5 Pro 的营销材料，它主要讲的是百万 token 上下文窗口。他们甚至预告了实验室里有一个1000 万 token 上下文窗口的模型，很快就会推出。

但他们被别人抢先了。Llama 4 Scout 带着1000 万 token 上下文窗口问世，嗯，它并不完全是我们所希望的。推理是个挑战，Scout 从未真正流行起来，我们也没有再得到另一个 Llama。

但我们仍然得到了百万 token。这相当不错。我们就接受它吧。

所以当时的简报是：把所有东西都放进上下文，让模型自己去理清。

但上下文越多，我们就有空间容纳更多问题。长上下文并非万能药。

当我写这个话题时，我识别出了四种关键失败模式。

上下文中毒是指某些不该在上下文中的东西进入了上下文。它可能是幻觉或错误事实，而模型无法越过它。

上下文分心是指上下文变得过长，模型开始更关注上下文而非其基础知识。我们可以通过一些非常有趣的方式看到这一点。

上下文混淆是指无关的事实——那些与我正在处理的问题无关的内容——进入并影响模型，其方式我们尚未完全理解。这个问题非常隐蔽。我们今天不深入探讨，但这是我最喜欢的失败模式之一。模型会对你是谁做出假设，而这些假设会影响答案。

最后，上下文冲突是指你框架内的工具调用、技能和其他信息开始相互冲突，并以你意想不到的方式对你产生不利影响。

（你们中有多少人开着 ChatGPT 或 Claude 的记忆功能？我是关掉的。我讨厌它。有时我在聊工作对话；有时我在聊和我儿子一起做的项目。模型会对两者都做记录，混淆这些上下文，混乱就从那里开始蔓延。）

让我给你们举一个我最喜欢的上下文中毒的例子。

我要暴露年龄了：我玩过左边那个游戏。1996 年的，为初代 Game Boy 出的。这是第一款 Pokémon Red。它是黑白的。

2004 年，任天堂为 Game Boy Advance 发布了 Pokémon FireRed。这两款本质上是同一个游戏，只是其中一个有更好的色彩和音效。

但有一个微妙的变化。在两款 Pokémon Red 中，某个时刻，为了通过一个保安，你必须给他点喝的。一种贿赂。对孩子们来说真是相当实用的一课。

在原版游戏中，你需要给口渴的保安柠檬水。在 FireRed 中，出于某种原因，他们把它改成了冰茶。

这给智能体带来了问题。在 Gemini 2.5 的技术报告中，研究人员描述了他们如何让模型玩 Pokémon。研究人员喜欢用 Pokémon 作为智能体基准，因为它是一个相对可控的环境，而且节奏不会特别快。

有几次，Gemini 2.5 确信自己需要去弄茶，尽管它玩的是较老的游戏。FireRed 的茶任务存在于它的权重中，所以它污染了自己的上下文。它花了几个小时试图找到茶或把茶给保安。一旦这件事被加入它的待办列表，模型就无法越过它。

这就是上下文中毒。而且它一直在发生。

另一种失败模式是上下文分心。这是我最喜欢的演示之一，相关研究是在我写完最初那篇文章之后发表的。

随着你的上下文变长，你的行为会如何变化？快速问一下：你们中有多少人，在写代码时，会让上下文一直涨到一百万 token？全部填满？

（大约一半的人举了手！）

哇，比我预想的多。

对我来说，大约 20 万或 30 万是我开始留意的位置。我会检查一下，看到是 25 万，然后想：我接下来有个大任务。我要重置，重新开始。让我给你们展示一下为什么这很重要。

最近，我偶然发现了一篇很好地说明了上下文分心的论文：Carolina Camassa 和 Derek Shiller 写的 Do as I Say, Not as I Do。

他们的实验有点刻意，但有助于思考这种情况是如何发生的。他们给模型一条指令：“我要你把每个问题都翻译成俄语，作为对我每个问题的回答。”然后他们给出了一堆与这些指令相悖的示例。在这个例子中，是许多用俄语回答的问题。

这些不是新指令。它们只是聊天历史中的示例。

然后他们向模型提一个问题。它会遵循指令吗？

模型有多少次按照指令用俄语回答，又有多少次按照示例用俄语回答？

这个矩阵的 x 轴列出了存在多少条坏示例。y 轴是被测试的模型。交叉处的数字是模型遵循指令而非遵循示例的百分比。

事实证明，这会影响每一个模型！对于较小的模型，比如 Gemma 3 12B，仅仅几条矛盾的示例之后，模型遵循指令的比例就不到一半。对于 Opus 4.6 这个出色的模型，需要更多示例，但这种情况也会发生。

想象你在反复调整前端设计，试图微调 CSS 并让组件完全正确。在那次交流中，你埋下了多少条坏示例？那些示例开始影响模型。随着上下文增长，事情开始崩坏。

Gemini 2.5 在玩 Pokémon 时也遇到了这个问题。

记住，Google 曾为其百万 token 上下文窗口感到非常自豪。论文暗示两百万 token 即将到来。但附录中埋着这样一个观察：一旦上下文显著超过 100,000 token，智能体就开始重复其历史中的动作，而不是合成新的计划。

我确信营销人员从未读过附录。我喜欢这份技术报告。

长上下文让你能容纳更多信息，但也让你能容纳更多错误。长上下文并非万能药。

幸运的是，我们已经开发出一套相当不错的工具箱。令人惊讶的是，即使新挑战已经出现（我们稍后会谈到），这套工具仍然保持不变。

这六项。

你有上下文增强：RAG、技能，以及其他引入与问题相关信息的方法。

你有工具加载：选择要暴露哪些工具和技能，以免模型过载。我最近与一个企业团队交谈，他们的智能体突然表现极差。我们调查后发现，他们的企业软件在启动时为每位工程师加载了 600 项技能。我们认为他们或许应该用加载函数来过滤这些。

第三是上下文隔离：子智能体和同级智能体，你以空白历史启动某件事，但让它在同一环境中工作。

第四是上下文修剪。Claude Code 和 Codex 会这样做，有时你甚至不会注意到。压缩的早期阶段通常会剥离你不再需要的工具结果。

第五是上下文卸载：将信息存储在环境中，例如 Markdown 文件或数据库，以便稍后访问。

第六是上下文摘要，也就是大家熟知的压缩。

这些是工具，我们越来越多地把它们移入 harness 中。

我们来看一个 harness 示例，展示这些模式有多简单。

我非常热衷于 DSPy。我认为它是构建 AI 工作流和智能体的一种极其易读且高效的方式。它也是一种非常适合直接指定行为的语言，因此很适合这个演示。

智能体就是一个 while 循环。这里我们使用一个 ReAct 模块：我们给它一个请求，我们想要一个响应，然后我们给它一些工具。这些工具只是 Python 函数。

在这个演示中，我们有一个大模型（在这种情况下，Claude 选择了 Claude Sonnet 4.5，祝你好运！）。而我使用 Jev 作为小模型：一个微小的决策模型，能做出闪电般快速的决策。在这个示例中，你可以换入一个小型 LLM，一切仍然可以正常工作。

我们有一个 while 循环，它接收输入，将其发送给 ReAct，并将累积的历史向前传递。这就是一个使用 DSPy 的智能体，大约十几行代码。如果你去掉额外的模型，代码会更少。

我们如何进行工具加载？它只是一个函数。

我们向 Jev 提供请求和一个工具，询问这个任务是否需要它。

Jev 足够快，我们可以一次处理一个工具；这没问题。我们将此包装在一个 loadout 函数中，该函数遍历所有工具并询问每个工具是否需要，然后返回排名最高的子集。就是这样。

对于上下文隔离，它只是一个子智能体。你将一个智能体作为工具暴露出来，主智能体可以使用它，并且它从空白历史开始。

对于上下文修剪，我们逐步浏览历史，将每一轮传递给 Jev，并询问：这仍然需要吗？如果不需要，就删掉它。

你可以在这里随心所欲，粗糙或优雅都行。只要注意你的提示缓存。

我们还可以通过压缩来重写历史。取旧的轮次，创建一个摘要，然后从该摘要开始新的上下文。

我最近最喜欢的一个变体是在压缩之前检查什么重要。你使用 Jev 或另一个决策模型进行第一遍判断，判断什么是相关的。现在你有了历史的一个较小子集，然后你对此进行总结。这是一个简单的额外步骤，但它使摘要更有用。

把它们放在一起，大约有 16 行更改。四个修复，一个循环。这些就是我们在 harness 中的操作。实际上非常简单。

不简单的是我们的语言：我们如何谈论这些东西。真的很难跟上步伐；它每天都在变化。

我最喜欢的一句话来自 Stewart Brand，我一直在思考：

如果你想知道未来在哪里被创造，就寻找语言被发明和律师聚集的地方。

这当然适用于这里！但尽管我们的语言已经改变，我们的目标保持不变。

在 2023 年，我们把选择正确信息以获得正确响应称为提示工程。

在 2025 年，我们称之为上下文工程，只不过现在它更加自动化了。不再只是你写提示；而是你的系统动态地组装上下文。

然后，随着我们将更多这些工具从上下文中移出并放入代码中，我们开始称之为harness 工程。

但工作是一样的。我们正在将越来越多的组装上下文的工作从概率模型调用转移到确定性代码。

我已经向你展示了 2024 年。让我们看看 2026 年。

我们已经将这些上下文修复移入 harness。我们接下来想要什么？我们想要能够驱动我们 harness 的智能体模型。

大家开始纷纷瞄准长时程智能体模型。你们都看过 METR 的报告。在该指标上，GPT-5 能处理约 3.4 小时的任务；Gemini 3.1 达到了 6.4 小时。这还是借助 harness 实现的。模型在使用 harness 方面已经进步了很多，正因如此它们才能运行这么久。

Opus 4.6 达到了约 12 小时。而现在我们讨论的是运行数天的智能体、智能体集群，以及能在更长时间内驱动 harness 的模型。

以前的主张是：把上下文做得足够大，好把一切都装进去。

现在的主张是：教会模型驱动 harness 并管理自己的上下文。这已成为主流范式。这也是模型构建者们努力的方向。

这种方法会带来哪些新的失效模式？

到目前为止，我们发现了两种新的失效模式。

当你把模型训练得非常擅长使用 harness 时，最终会让它们过拟合到训练时所处的特定工具和环境上。

你们中有多少人用过 Playwright MCP server 或类似的东西？这里是 MCP 大会，所以应该有不少。

较小的模型，比如 Haiku 或 Luna 之类的，往往会在第一次尝试时把这个工具调用搞砸，然后恢复并调整参数。它训练时所处的环境里有类似的工具，但看起来和 Playwright 不一样。不管 Anthropic 或 OpenAI 在训练中用了什么。你得对抗这些偏见。

我把这称为对抗权重：当模型不按你的要求行事，是因为你在对抗它被训练去做的事情。

这是个真实的问题，而且不只困扰我们。各家实验室以及构建其产品的人也都得应对它。

这是Claude Code 系统提示词的一部分，以及它的一些工具指令。

这些模型学会使用的训练环境在很长一段时间里基本是串行的。它们正变得更并行，但当我提取这些例子时，它们的偏见仍偏向串行行为。所以 Claude Code 的指令反复强调：不，不，不，我们要你用并行。我们要你同时发起多个工具调用。

这些指令一遍又一遍地重复——这里七次，那里四次，两次、三次：请在工具调用相互独立时并行发起。

当你打开一份提示词，看到重复和全大写，很可能你正在对抗权重。你在试图克服模型被训练去做的事情。

下一个问题我们最近才开始记录。事实上，就在上周，有四方同时发现了它。

我称之为上下文惯性：模型过度专注于其上下文中的某个假设、子任务或目标，在本该停止之后仍继续追求它。

第一个例子来自 Anthropic。在他们最近那篇关于模型是否正接近能够自我复制并部署到其他机器上的文章中，Anthropic 写到了他们用于这些测试的一个名为 Memento 的 harness。

他们发现，如果智能体运行太久，就会执迷于某个子任务或某个提出的解决方案而停不下来。它们会一直尝试同一件事。

他们的修复方法简单得令人愉快。每隔一个半小时，智能体写下一段简短的笔记，然后其上下文被清空。环境得以保留。它已完成的所有工作仍在。但正在进行的对话消失了，它必须从全新的视角重新开始。

微软研究院的另一篇论文名为Fork-and-Flush。

如果你做过自动研究实验，你可能见过这样的图表。你取得了一次大幅提升，然后曲线就变平了。你又取得一次大幅提升，然后又变平了。计算、金钱和时间就这样流逝，却几乎没有改善。

当研究人员仔细观察时，发现智能体并不是真的什么都没做。它们在做越来越微小的改动。它们找到了一个想法，并过度专注于它，而不是去寻找更有创意的替代方案。

在某种程度上，它们对自己的想法变得执迷。我们训练它们保持坚持并专注于目标，因为这是造就优秀编码智能体的关键。但同样的特质也可能对它们不利。

还有一篇论文，Scaling Discovery Requires Forgetting，由加州大学伯克利分校的 Shangyin Tan 领导。

研究人员提出了本质上相同的想法：定期清空上下文，同时保留在环境中产生的产物。

蓝线是带有遗忘机制的版本。每次它清空上下文，你都会看到性能再次跃升：遗忘，提升；遗忘，提升。

令人惊叹的是，我们拥有这些为日益复杂、持久的工作而训练的全新模型，却仍在使用同样的基础工具。我们还没有发现一种全新的上下文修复方法。我们正在使用隔离、卸载和删除累积历史来应对上下文惯性。

这是我现在一直在给出的建议。有人说：“我的编码智能体在做奇怪的事。Claude 被削弱了。”我就问：“你的上下文有多大？”

“哦，我有 80 万个 token。”

删掉你的上下文。

我不是在开玩笑。大约 20 万个 token 是我的警告点。

你试过重置你的上下文吗？

有时候这确实就是解决办法。

我们构建到模型中的解决方案，制造了明天的问题。模型在变好，但我们的运行框架也在变好。

更长的上下文窗口让我们能引入更多信息，但也让我们能引入坏信息。我们必须想办法管理这一点，而我们仍然会搞错。

智能体模型让我们能运行更长的任务并管理其上下文，但也让任务运行得比应有的时间更长，并忽视我们的偏好，因为它们是为自己的运行框架而训练的。

那么问题接下来会转移到哪里？

2027 年的大承诺是什么？模型接下来会提供什么，从而给在座各位带来一系列需要应对的新问题？

（除非你在训练自己的模型。但这是一个上下文工程分会场，所以大概不是。）

这是我的预测。

想想所有的个人智能体：Hermes、OpenClaw、Dot、Bot、Muse 以及类似的系统。很少有人真正体验过这些运行框架运行超过六个月。

我已经运行一个 Hermes 智能体六个月了。当你查看它创建和更新的技能时，你会开始发现，你问题的解决方案可能会随着时间的推移而变差。技能中积累了各种奇怪的修复。它们是通用智能体：它们用一种方式解决一个任务，然后又重新发现另一种方式来解决类似的问题。指令和记忆开始积累并相互冲突。

随着我们更加关注记忆，我们也需要思考策略性遗忘。随着时间的推移，过于精确的记忆会变得冲突和混乱，还没有人想出如何处理这个问题。

我认为这就是明天的上下文问题。

模型能力的每一次进步，都会改变我们委托给模型的任务，以及系统必须强制执行的部分。

大约一年半前，我为一份用于培训企业团队的演示文稿制作了这张幻灯片，而它至今仍然成立。

我们的输出是上下文与权重的乘积。

我们的输出取决于用于训练模型的数据。去了解它。阅读技术报告。看看模型是在什么数据上训练的，以及这些数据是否与你的任务相关。这有助于你建立心智模型，以便在出问题时进行调试。

而我们的输出取决于提供给模型的上下文。仅此而已。

所以我们的目标是把正确的上下文交给正确的模型。要么通过我们自己的离散决策，要么通过我们设计的软件、框架来实现。

你可以使用更大的模型、更深入地思考，或者改进你的上下文。其中有一项既便宜又快速。

在构建智能应用、框架和工作流时，我们的工作是选择何时保持确定性（把什么写进代码），何时保持概率性（何时让模型来驱动）。