AI 智能体上下文工程现状：失败模式、治理工具与新型风险

诀窍在于知道何时应保持确定性 & 何时应采用概率性方法

本周，我在 AGNTCon 做了一场简短演讲，题为“上下文失效 & 修复”，其作用类似于一份“上下文工程现状报告”。上下文工程是如何兴起的、如今走向何方、未来又可能走向何方？随着模型开发者瞄准新能力，他们也在无意中制造出一些挑战，而这些挑战必须由我们这些用户和框架构建者来克服。

下面是幻灯片和一份略经编辑的文字记录。一如既往，有任何反馈、想法或问题，都请给我发消息。真的非常感谢。

大家好，感谢今天加入。我们来聊聊上下文的失效与修复。

我有一本书很快就要出版了，上下文工程手册。我最初与 O’Reilly 团队沟通是在 2025 年 6 月，他们问了我一个非常合理的问题：“我们怎么知道这本书不会在几周后就过时？”AI 教科书的问题在于，许多内容过时得惊人。

我说，我也不知道，但我很乐观。无论 AI 变得多么强大，如何清楚说明该做什么、不该做什么，以及如何确保这些指令保持一致且不受噪声干扰，对 AI 来说都将是永远的挑战。

我们认识并来往的同事、合作伙伴和其他人确实具有感知能力。他们能通过图灵测试，他们就是“AGI”，但即便如此：我们仍然很难在彼此之间准确传达指令、想法和概念。

上下文工程会继续很难。但这种难会以独特的方式呈现，因为模型不是人。你可以假设模型如何思考或理解事物（想用哪种拟人化措辞都行），但了解模型是如何构建、优化和训练的会有所帮助。它们独特的属性与构造方式形成了一组独特的失效模式，需要我们认真应对。

那么，让我们回顾一下我们是如何走到今天的。

让我们回到 2024 年底。

如果你还记得，当时正值“RAG 已死”论调最盛之时。

当时的设想是：只要把上下文窗口做得足够大，就能把整个互联网塞进去。可以把所有东西都放进去。我们不必筛选，也不必构建智能体系统。全都能装得下，而 AI 难题就此解决。

模型开发者开始瞄准长上下文能力，我们从 ~128,000-token 上下文窗口模型到百万 token 上下文窗口模型有了一次巨大跃迁，起点是 Gemini 1.5。

如果你查看 Gemini 1.5 Pro 的营销材料，其中大多讲的是百万 token 上下文窗口。他们甚至还在暗示，实验室里有一个 10-million-token 上下文窗口模型，很快就会发布。

但被他人抢先一步。Llama 4 Scout 发布时采用了 10-million-token 上下文窗口，不过，它并没有达到我们期待的程度。推理是一项挑战，Scout 也始终没有真正走红，而我们之后再也没等到另一款 Llama。

不过，我们还是获得了百万 token。这已经相当不错了。我们接受。

所以，当时的大致思路就是：把所有东西都放进上下文里，让模型自己理清楚。

但上下文越多，可能出现的问题也越多。长上下文并非万灵药。

我在撰写相关文章时，总结出了四种关键的失效模式。

上下文投毒是指本不该出现在上下文中的内容进入了上下文。它可能是幻觉，也可能是错误事实，而模型无法绕过它。

上下文干扰是指上下文变得过长，以至于模型开始更关注上下文，而非其基础知识。我们能在一些非常有趣的情形中看到这种现象。

上下文混淆是指多余事实——与正在处理的问题无关的信息——介入并以我们尚未完全理解的方式影响模型。这一种尤其阴险。今天我们不深入讨论，但它是我最喜欢的失效模式之一。模型会假设你是谁，而这些假设会影响答案。

最后，上下文冲突是指工具调用、技能以及运行框架内的其他信息开始相互冲突，并以你意想不到的方式妨碍你。

（你们当中有多少人在 ChatGPT 或 Claude 中一直开着记忆功能？我会关掉。我讨厌它。有时我谈论工作上的对话；有时我谈论我正在和儿子做的一个项目。模型会把两者都记下来，混淆这些上下文，混乱就会由此不断加剧。）

让我给出我最喜欢的上下文投毒示例。

我先来标注一下年代：左边这款游戏我玩过。那是 1996 年为初代 Game Boy 推出的游戏。这就是第一代 Pokémon Red。它只有黑白画面。

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

但有一处细微变化。在两代 Pokémon Red 中，都有这样一个环节：为了通过保安那一关，你必须给他点喝的东西。一份贿赂。这给孩子上的真是很实用的一课。

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

这给智能体制造了一个问题。在 Gemini 2.5 技术报告中，研究人员描述了 他们如何让模型玩 Pokémon。研究人员喜欢用 Pokémon 作为智能体基准，因为这是一个相当可控的环境，而且运行速度不算特别快。

有好几次，Gemini 2.5 坚信自己需要拿到茶，尽管它正在玩更老的游戏。FireRed 中的茶任务已经存在于它的权重中，因此它给自己的上下文投了毒。它花了几个小时试图找到茶，或把茶交给保安。一旦这件事被加入它的待办清单，模型就无法再绕过它。

这就是上下文投毒。而且这种情况一直在发生。

另一种失效模式是上下文干扰。这是我最喜欢的演示之一，而这项研究是在我写完最初的文章后才发表的。

随着上下文越来越长，你的行为会发生什么变化？快速问一句：你们当中有多少人在写代码时，会任由上下文一路增长到一百万个 token？把它全部填满？

（现场约有一半人举起了手！）

哇，这比我预想的还多。

对我来说，大概到了 200,000 或 300,000 个 token，我就会开始留意。我会查看一下，发现已经到了 250,000，然后想：接下来有个大任务要来了。我要重置并从头开始。让我给你们看看这为什么重要。

最近，我偶然发现了一篇论文，它很好地体现了上下文干扰：照我说的做，而不是照我做的做，作者是 Carolina Camassa 和 Derek Shiller。

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

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

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

模型有多大比例会按照指令用俄语回答，又有多大比例会像示例中那样用法语回答？

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

结果发现，这会影响每一个模型！对于 Gemma 3 12B 这样的小模型，只需几个相互矛盾的示例，模型遵循指令的频率就会低于一半。Opus 4.6 虽然是个很棒的模型，需要多得多的示例，但这种情况在它身上也会发生。

想象一下，你在反复推敲前端设计，试图调整 CSS，让一个组件完全达到预期。在那次交流中，你植入了多少个坏示例？这些示例会开始影响模型。随着上下文不断增长，一切就会开始崩溃。

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

记得，Google 曾对自己拥有一百万 token 的上下文窗口非常自豪。论文暗示，两百万 token 很快就会成为现实。但附录中却埋着这样一条观察：一旦上下文显著超过 100,000 tokens，智能体便会开始重复历史记录中的动作，而不是综合制定新的计划。

我敢肯定营销人员从来没读过附录。我很喜欢这份技术报告。

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

幸好，我们已经开发出了一套相当不错的工具箱。令人惊讶的是，尽管不断出现新的挑战（我们马上就会谈到这些），这套工具却一直没有变化。

一共就是这六种。

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

其中还有工具配置：选择要向模型开放哪些工具和技能，以免让模型负载过重。最近我在与一个企业团队交谈，他们的智能体表现突然变得非常糟糕。我们展开调查后发现，他们的企业软件在启动时为每位工程师加载了 600 项技能。我们认为，他们或许应该通过一个配置函数来筛选这些技能。

第三种是上下文隔离：子智能体和对等智能体，即以空白历史启动某个任务，同时让它在同一环境中工作。

第四种是上下文剪枝。Claude Code 和 Codex 会这样做，有时你甚至都不会注意到。压缩过程的早期阶段往往会剔除你不再需要的工具结果。

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

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

这些就是工具，我们已越来越多地将它们移入执行框架。

来看一个执行框架示例，看看这些模式有多简单。

我非常喜欢 DSPy。我认为它是一种极其易读且高效的方式，可用于构建 AI 工作流和智能体。它也是一种很适合简洁定义行为的语言，因此非常适合这次演示。

智能体就是一个 while 循环。这里我们使用 ReAct 模块：向它提供一个请求，希望得到一个响应，再给它一些工具。这些工具只是 Python 函数。

在这个演示中，我们使用一个大模型（这里 Claude 选用了 Claude Sonnet 4.5，祝你好运！）。我还使用 Jev 作为小模型：一个能够做出闪电般快速决策的微型决策模型。在这个示例中，你也可以换成小型 LLM，一切仍然照常工作。

我们有一个 while 循环，它接收输入，将其发送给 ReAct，并继续传递不断累积的历史记录。使用 DSPy，只需大约十二行代码就能实现一个智能体。如果去掉额外的模型，代码还会更少。

我们如何装载工具？只需要一个函数。

我们把请求和一个工具交给 Jev，问它这个工具是否对此任务有必要。

Jev 足够快，可以一次处理一个工具；完全没问题。我们把这套逻辑封装在一个 loadout 函数中，遍历所有工具并询问每个工具是否需要，然后返回排名最靠前的子集。就这么简单。

使用上下文隔离时，它就是一个子智能体。把一个智能体作为工具暴露给主智能体使用，并让它从空白历史开始。

使用上下文剪枝时，我们逐步遍历历史，把每一轮对话交给 Jev，并询问：这还需要吗？如果不需要，就删掉。

这里你可以写得很粗糙，也可以写得很优雅。只要注意提示缓存即可。

我们还可以用压缩来重写历史。取出旧的对话轮次，创建一份摘要，并从该摘要开始构建新的上下文。

我最近最喜欢的变体之一，是在压缩之前检查哪些内容重要。先用 Jev 或另一个决策模型进行第一轮判断，确定哪些内容相关。这样你就有了历史中更小的子集，再对它进行总结。这只是额外的一个简单步骤，却能让摘要更有用。

全部组合起来，只需大约 16 行代码改动。四项修复，一个循环。这些就是我们在执行框架中采用的操作。实际上简单得惊人。

不简单的其实是我们的语言：我们谈论这些东西的方式。要跟上它的变化非常难；它每天都在变。

我最喜欢的名言之一来自 Stewart Brand，我经常想起这句话：

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

当然也适用于这里！不过，尽管我们的语言发生了变化，目标始终未变。

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

2025 年，我们称之为上下文工程，只不过这时它已更加自动化。不再只是你编写提示，而是由你的系统动态组装上下文。

后来，随着我们把更多这类工具从上下文中移入代码，我们开始称之为运行框架工程。

但工作本质没有变。我们正在把越来越多组装上下文的工作，从概率模型调用转移到确定性代码中。

我向你们展示的是 2024 年。现在来到 2026 年。

我们已经把这些上下文修复移入了执行框架。接下来我们想要什么？我们想要能够驱动执行框架的智能体模型。

所有人都开始瞄准长时程智能体模型。你们已经看过 METR 的报告。按该衡量标准，GPT-5 可以处理大约 3.4 小时的任务；Gemini 3.1 最高达到 6.4 小时。这是在有运行框架的情况下。模型已经大幅提升了对它的使用能力，正因如此，它们才能运行如此之久。

Opus 4.6 最高达到约 12 小时。现在我们讨论的是持续运行数天的智能体、智能体集群，以及能够更长时间驾驭运行框架的模型。

以前宣传的是：把上下文做得足够大，让一切都能容纳进去。

现在宣传的是：教会模型驾驭运行框架并管理自己的上下文。这已经成为主流模式。模型构建者正朝这个方向努力。

这种方法会产生哪些新的失效模式？

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

当你训练模型非常熟练地使用运行框架时，最终会让它们对训练时所在的特定工具集和环境产生过拟合。

在座有多少人用过 Playwright MCP 服务器或类似工具？这是 MCP 大会，所以估计人数不少。

较小的模型，比如 Haiku 或 Luna，往往第一次调用工具就会搞砸，随后才恢复并调整参数。它接受训练的环境中有类似工具，但外观与 Playwright 不同。无论 Anthropic 或 OpenAI 在训练中使用了什么，你都必须与这些偏差作斗争。

我把这称为对抗权重：当模型没有照你的要求做，是因为你在逆着它受训后的行为去要求它。

这是个现实问题，而且不只是我们面临。那些实验室以及构建自己产品的人也得应对它。

这里有一段Claude Code 系统提示词，以及其中的一些工具指令。

这些模型学会使用的训练环境长期以来在很大程度上都是串行的。它们正变得更加并行，但当我查看这些示例时，它们仍偏向串行行为。因此 Claude Code 的指令反复强调：不，不，不，我们希望你使用并行方式。我们希望你同时进行多次工具调用。

指令一遍又一遍地重复这一点——这里是七次，那里是四次，还有两次、三次：请在工具调用彼此独立时并行进行。

当你打开一个提示词，看到其中有重复内容和全大写文字时，你很可能是在对抗权重。你正试图克服模型受训去做的事情。

下一个问题是我们直到最近才开始记录的。事实上，仅在上周就有四方注意到了它。

我把它称为上下文惯性：模型会极度聚焦于其上下文中的某个假设、子任务或目标，并在应该停止后仍继续推进。

第一个例子来自 Anthropic。在他们最近一篇关于模型是否接近复制自身并将其部署到其他机器上的文章中，Anthropic 介绍了一个用于这些测试的运行框架，称为 Memento。

他们发现，如果智能体运行时间过长，就会执迷于某个子任务或某个拟议解决方案，无法停止。它们会不断尝试同一种做法。

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

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

如果你运行过自主研究实验，你可能见过这样的图表。你取得一次大幅提升，然后曲线就趋于平缓。你又取得一次大幅提升，随后又再次趋平。这意味着计算资源、资金和时间都在不断流逝，却几乎没有改进。

当研究人员仔细观察时，这些智能体并不是真的什么都没做。它们在进行越来越细微的改动。它们找到一个想法后，便对它极度专注，而不是去寻找更有创造性的替代方案。

在某种程度上，它们会执着于自己的想法。我们把它们训练得坚持不懈、专注于目标，因为这正是优秀编程智能体所需的品质。但这种品质也可能反过来妨碍它们。

另一篇论文是 规模化发现需要遗忘，由加州大学伯克利分校的 Shangyin Tan 领衔。

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

蓝线代表采用遗忘机制的版本。每当它清空上下文时，你都会看到性能再次跃升：遗忘，改进；遗忘，改进。

令人惊讶的是，我们已经有了专为日益复杂、持久的工作而训练的全新型模型，却仍在使用相同的基本工具。我们还没有发现一种彻底解决上下文问题的新方法。我们正通过隔离、卸载和删除累积的历史记录来应对上下文惯性。

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

“哦，我有 800,000 tokens。”

删掉你的上下文。

我不是在开玩笑。大约到 200,000 tokens 时，我就该发出警告了。

你试过重置上下文吗？

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

我们植入模型的解决方案，会带来明天的问题。模型在变得更好，我们的智能体框架也在变得更好。

更长的上下文窗口让我们能够引入更多信息，但也让我们能够引入质量不佳的信息。我们不得不摸索如何管理这些信息，而至今仍会处理失当。

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

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

2027 年最大的期待是什么？模型接下来会提供什么，从而给在座各位制造出一套新的难题？

（除非你正在训练自己的模型。不过这是一场关于上下文工程的分享，所以大概不是。）

以下是我的预测。

想想这些个人智能体：Hermes、OpenClaw、Dot、Bot、Muse，以及类似的系统。真正见过这些运行框架连续运行超过六个月的人非常少。

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

随着我们更加关注记忆，也需要考虑策略性遗忘。随着时间推移，过度精确的记忆会变得相互冲突且杂乱无章，而目前还没有人弄清楚该如何处理。

我认为那就是明天的上下文难题。

模型能力的每一次提升，都会改变我们委托模型处理的内容，以及系统必须强制执行的内容。

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

我们的输出是上下文与权重的产物。

我们的输出取决于用于训练模型的数据。要理解这一点。阅读技术报告。了解模型是用什么数据训练的，以及这些数据是否与你的任务相关。这有助于你建立一套用于排查故障的心智模型。

而且，我们的输出取决于提供给模型的上下文。就是这样。

所以我们的目标是把正确的上下文交给正确的模型。无论这是通过我们自己的明确决策，还是通过我们设计的软件、运行框架来实现。

你可以使用更大的模型、进行更深入的思考，或者改进上下文。其中一种方式既廉价又快速。

在构建智能应用、运行框架和工作流时，我们的任务是决定何时采用确定性方法（哪些内容要写入代码），何时采用概率性方法（何时让模型来驱动）。