> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 上下文工程：让AI更可靠
- URL: https://www.hubwiz.com/blog/context-engineering-making-ai-more-reliable/
- Published: 2026-08-26T15:20:19.000Z
- Updated: 2026-08-26T15:20:19.000Z
- Description: 我们开始问为什么这么多AI产品会失败。我一次又一次发现的答案不是模型不知道如何完成任务。
- Author: admin
- Tags: LLM, #Import 2026-10-14 14:41

您的代理不会耗尽技能，而是会耗尽干净的上下文。压缩、子代理、技能、RAG和护栏最终都归结为同一招。

*过去几年与AI的相处非常紧张。最近几个月更是如此。在很短的时间内，我们从将AI视为偶尔能正确编写一段代码的玩具，发展到真正值得构建到产品中的工具。然而，大多数都失败了。不是因为模型无法完成任务——它可以。问题是途中出了某些差错，而这与我们提问的质量无关。*

## 1、这不是提示工程

自从我开始在Medium上写作以来，远在AI热潮之前，我一直喜欢向读者展示一个一直存在但几乎被忽视的现实。那些改变你看待事物方式的东西，一旦你看到它，就再也无法忽视。**对于AI，我曾认为它几乎可以自主运行，它会帮助你，而我几乎做不了更多**，**但**在看到很多集成AI的解决方案后，我发现**我错了**。

事实证明，**我遇到的第一个神话是提示工程是关键**，它能打开通往任何领域的大门。有了理想的提示，你就能解决任务。说实话，我听到这个神话的次数越来越少，但它仍然根深蒂固。

首先，当大型AI公司都难以获得健壮的系统提示时，很容易怀疑这是不够的。这些公司可以轻松测试不同的系统提示来引导它们的代理。它们可以实时看到哪些变化会导致什么结果。然而，越狱问题始终存在，就像幻觉一样。

但这不是唯一的观点，因为确定性也让我们失望了。我们习惯于计算机在我们与它交互时总是以相同的方式表现，它是可靠的。然而，无论我们多么努力地让提示更完美，总会有变异性，总会有它想干什么就干什么的时刻。在小规模下很容易忽略，但**当你扩展到数千或数百万用户时，简单的1%错误可能是灾难性的**。

最后，也许最重要的是：上下文的大小。AI能记住的东西是有限的。它的每一步行动、每一个想法、我们对它说的每一个字、它读到的每一个资源都在不断增长上下文。但上下文有上限，当达到上限时，就结束了，它无法在不忘记某些内容的情况下继续。这意味着**如果任务需要的上下文空间超过了可用空间，那是不可能的**，即使它知道如何去做。

这就引出了我们的观点：我们要做的不是提示工程，而是……

## 2、上下文工程

处理上下文很可能是处理AI最重要的部分。一旦我们将模型训练放在一边，它就涵盖了一切。

上下文工程比提示工程更进一步。它的作用是编辑AI本身的记忆和回忆，以使其在执行任务时尽可能保持确定性。我们操纵它对现实的感知，以满足我们的目标。

上下文包含代理所知道的一切，是它的记忆。这就是我们谈论的系统提示所在的地方，接着是对话，包括你的消息和它们的回复。但除此之外，它还包含工具调用及其结果。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-wq0rJo256F4rhFCVApaH9g.png)

除了常识之外，这个上下文正是AI所看到和知道的一切。你给它的任务就在那里。它的推理也在那里。

更有趣的是，这也是整个上下文工程分支的起源：**AI没有意识到我们是否操纵或更改了上下文**。它只会生成下一个令牌，接受我们放在它面前的上下文作为现实。而操纵这个上下文就是我们引导它的方式。对它来说，上下文就是它的经历。接下来的一切都源于此：**如果上下文是它的现实，编辑上下文就是编辑它的现实**。

这也是为什么一个执行任务二十分钟的代理并不完全是开始时的那个代理。它随着记录的经验而成长。

## 3、操纵上下文

> *压缩*

很可能你们都熟悉的上下文操纵技术之一是压缩。当对话变得非常长时，它不会告诉你无法继续（这是过去的情况），而是出现一条消息说"正在压缩"，然后继续。实际上，它做的是生成摘要：获取整个上下文，对其进行总结，然后从摘要继续。即使我们在UI中看到整个对话，对AI来说它已不复存在。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-09KsemypE03d6Q5v9hqHWg.png)

**我们重写了它的过去。它的整个生命现在就是那个摘要**，因为摘要可能无法捕捉所有细微差别，所以摘要出错的任何内容，它都会继续相信那是真实的过去。

> *子代理*

防止上下文过快填满的另一种技术是子代理。在这种情况下，它做的是创建一个新的上下文，带有自己的系统提示和输入，然后启动一个并行AI来完成工作。完成后，它将结果返回给原始AI。这意味着原始的上下文只保存创建子代理的请求、输入和结果，节省了它沿途运行的所有步骤、推理和错误。我们在这里做的是创建两个上下文而不是一个，这样两者的总和大于一个，从而避免了可能的摘要损失。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-OPK0VD1uSWgHl23b3R5l5Q.png)

**我们向原始AI隐藏了子代理发生的事情**。它不会看到任何推理、步骤甚至错误，对它来说这些从未发生过。这不仅仅是空间上的节省。

> 上下文的问题之一不仅仅是达到其限制，还有上下文退化。如果AI上下文包含太多不同的任务，并且组合了太多低相关信息，AI经常感到困惑，失去对任务的关注，增加了不确定性。

> *能力注入*

如果前两种技术是关于避免超过上下文窗口限制，我们也可以使用上下文向AI解释如何使用外部工具。在这种情况下，就像系统提示一样，我们添加调用不同工具的指令。这样，即使模型没有在这些工具上训练过，它也可以使用它们。这里我们有两种变体：MCP，类似于带有API调用指令等的超级工具，以及技能，它是更轻量级和可定制的版本。这些工具作为扩展能力的方式出现，利用上下文的优势。

**我们改变它知道如何做事的方式。如果上下文说它有这些工具，它就有。**

关于技能与MCP的说明。MCP首先出现，来自Anthropic，允许你连接和理解任何API，是技术能力与文档的混合。但很快出现了一个问题：它们占用了过多的上下文。MCP越多，留给其他东西的空间就越少，噪音也越多。相比之下，技能是反向设计的：将可用技能及其描述的简短列表添加到代理的上下文，以及如何使用它们和查找更多信息的一般描述。通过这种解决方案，不再需要像加载MCP那样加载整个技能，代理只需读取并在需要时调用技能。这个概念可以应用于许多其他事情。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-JYCIo7rxLa98V7SSV-5U0A.png)

所以**问题从来不是指令不好**。而是它们在那里，**占用空间，分散注意力**，而代理试图思考其他事情。

> *RAG注入*

如果你仔细观察，技能中的加载是延迟到AI需要它时才进行的，但还有其他技术也这样做。其中之一是RAG，检索增强生成。RAG允许AI访问比其内部容量大得多的数据空间，但如何做到？这个想法非常简单，但除非仔细完成并进行大量精炼变体，否则效果不佳。基础是将文档切分成AI可以轻松处理的小块。我们不能逐一运行每个小块并询问是否相关，这会花费太长时间。实际做的是计算每个小块的"嵌入"，这不过是一个指示文本大致内容的数值向量（就像情感一样）。然后，当提示到来时，它进行相同的嵌入计算，比较向量，取最相似的，然后将找到的相关片段注入上下文。这不能保证成功，但比文本搜索好得多。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-g2Xn9mckzc3r39s3SJnZKw.png)

我们改变它记住的内容。**我们不是给它访问文档的权限，而是让准确的片段出现在它面前**，就好像它一直记在心里一样。

现在，关于最后一点，我前一段时间注意到Anthropic倾向于不使用RAG，至少在Cowork或Claude Code中不是。它们做的是跨文件的关键词搜索。我不知道这比RAG好还是差，但效果似乎还不错。

这是我怀疑的另一件事。压缩后原始对话就丢失了，你只有摘要，所以关于较旧部分的任何特定问题可能会丢失或产生幻觉。但我越来越少看到这种情况，我开始认为RAG现在被用来搜索聊天并恢复相关的对话片段。虽然也可能是压缩摘要变得更好了。

## 4、强制确定性

所有这些都是通过操纵上下文来扩展代理能力的工具，无论是通过更改内容还是添加指令，但我们仍然缺少如何强制更大的确定性。

最简单的方法是依赖工具。**与AI生成的响应不同，工具涉及执行代码。而代码**，从原则上讲，**是确定性的**。所以如果我们设法将任何可以转移到工具中的任务交给工具执行，我们就能确定那里存在确定性和零幻觉。

但当然，我们也可以更进一步。不仅仅是工具执行得很好，工具还可以检查一切是否正确，并要求AI纠正任何错误并给出额外的指令。**代码可以监管输出以提高确定性**。

这是用工具，但不需要等待工具。我们可以直接检查输出是否正确，看看一切是否在逻辑上成立。如果我们能访问上下文和所有更改以及AI的来回，我们就可以提前介入并避免更大的问题。这里我们可以应用从监控某些输出以防止不当使用的护栏，到我们想要控制的高级限制。所有这些都是通过直接操纵上下文来完成的。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-BSZrG0Su0HclT6SLcV4cGQ.png)

我们委托给经典的确定性代码，而不是期望AI做它认为正确的事情。

## 5、最后一招

最后一招，简单但不广泛流传。事实证明，[如果AI看到错误，它倾向于犯越来越多的错误](https://arxiv.org/abs/2602.04288?ref=hubwiz.com)。所以错误越多，它犯的错误就越多。在某种程度上，就好像它在写一本书，认为这是一本不良实践的书。但如果我们编辑上下文并擦除错误呢？这种倾向就消失了。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-6XMQAbjaKg2PQKem5J-KEA.png)

所以，**我们正在塑造它的过去**。到目前为止，我们改变的是它知道什么、记住什么、能做什么，但现在**我们改变的是它认为自己是谁**。这是有效的，因为没有人在内部将上下文与其他任何东西进行比较。上下文就是一切。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-CRWHrwC2pThxEEBpVuF81Q.png)

> 然而，关于成本，我们应该考虑一点。每次调用AI都会处理整个上下文，但由于我们通常只做添加，一些AI提供商保留了一个缓存，其中包含处理这些旧令牌的结果。该缓存节省了大量计算和成本。篡改过去可能会影响这些价格，所以我们必须小心。

## 6、需要记住什么

我们开始问为什么这么多AI产品会失败。我一次又一次发现的答案不是模型不知道如何完成任务。它确实知道如何做，当你查看整个对话时，有它清楚的那一刻。问题是在这过程中它积累了错误、噪音和死胡同，到任务中途它不再是开始时的那个代理了。它知道如何做这份工作，但它不知道做这份工作时自己是谁。

没有提示能修复这个问题，无论它多么好。提示是AI读到的第一样东西，但上下文是它做出每个决定时那里的一切。这就是为什么本文中的技术不是孤立的技巧：压缩、委托、注入和擦除。它们都从不同角度做同样的事情，都在它必须做出决定的确切时刻决定代理头脑中有什么。

多年来，编程意味着告诉机器它必须做什么。现在困难的部分是决定它必须记住什么。

![None](https://www.hubwiz.com/blog/content/images/2026/08/1-mpbzVzvM-sxAaiuiKwVNNg.png)

---

原文链接：[Context Engineering Makes AI Behave Like Software That Works](https://medium.com/@drpicox/context-engineering-makes-ai-behave-like-software-that-works-2adc0c4c7706?ref=hubwiz.com)

汇智网翻译整理，请转载文章时标明出处。