在人工智能代理的小世界里，当下最流行的词是上下文工程。

这似乎又是一个为了销售我们已经做过的东西而发明的品牌。部分是这样。然而，正如经常发生的那样，这个标签之所以流行，是因为它给真正的痛苦起了一个名字。

痛苦在于：模型不会仅仅因为“不思考”而失败。他们经常失败，因为我们派他们去错误的房间工作。

我们给他们旧的指示。我们向他隐藏了重要文件。我们向他们传递的文件太长，而且没有说明什么是重要的。我们向他们展示日志，没有优先顺序。我们给了他们十种工具，但没有解释何时使用它们。然后，如果特工的动作就像一个在未知公寓中醒来的人一样，我们会感到惊讶。

提示是您对它说的短语。背景是你围绕它准备的世界。

从即时工程到情境工程

即时工程通常被认为是写作。选择正确的词语，以正确的方式提问，添加示例，指定格式。

情境工程更接近于建筑。

您不只是问“我如何提出请求？”。它问：

• 真正需要什么信息？
• 什么是噪音？
• 什么需要即时恢复？
• 应该记住什么？
• 哪些工具应该公开？
• 哪些指令是稳定的，哪些取决于任务？
• 如何让代理人明白什么是权威？

这是一个微妙但巨大的变化。因为当您使用代理时，上下文不是静态块。每一步都会发生变化。

代理打开文件、学习某些内容、运行测试、接收错误、更新计划、调用工具、发现依赖项。每跑一圈，他都必须决定要带什么、不带什么。

这是工程学。

上下文不是垃圾填埋场

具有大上下文窗口的模板给了我们一个诱惑：让我们把所有东西都放进去。

这是可以理解的。如果我有一百万个代币，我为什么要选择？

因为即使你可以把所有东西都放进去，也不意味着所有东西都有帮助。事实上，噪音是有代价的。它需要代币、需要注意力、需要延迟、需要质量。就像我们一样，当我们打开二十个选项卡并且不再记得原因时，模型可能会迷失在不相关的细节中。

良好的上下文具有层次结构：

1. 系统指令和政策；2.具体目标；3.现状；4.相关数据；
2. 限制因素；6.可用的工具；
3. 跟踪已经做出的决定。

没有必要把所有事情都放在同一水平上对待。用户命令比旧注释更有价值。现在，一次失败的测试比三个月前的审美偏好更有价值。安全策略比生产捷径更有价值。

上下文工程还意味着赋予权重，而不仅仅是数据。

记忆力：记得少，记得好

代理的记忆是最棘手的话题之一。

作为用户，您希望代理了解您。你希望他记住语气、计划、约定以及已经决定的事情。作为一名工程师，您知道每一个持久记忆也是一种风险：它可能是错误的、陈旧的、过于个人化的、过于通用的、无法验证的。

一个有用的记忆至少应该具备三个品质：

• 出处：这些信息从哪里来？
• 日期：什么时候是真的？
• 目的：它应该用于什么类型的任务？

没有这三件事，记忆就变成了迷信。

我喜欢将主体记忆视为一本练习册，而不是一个神奇的头脑。有临时注释、已确认的决定、风格偏好、技术限制、来源链接。有些东西会过期。有些需要重写。有些必须被消除，因为特工错误地推断了它们。

一个好的系统必须让这种维护变得常态化。不英雄。

检索和工具不是一回事

当我们谈论背景时，我们通常会立即提到 RAG。嵌入、矢量数据库、分块、重新排名。

都很有用。但检索只是将信息引入模型的一种方法。他不是唯一一个。

代理可以通过读取文件、查询 API、调用 MCP 服务器、打开浏览器、运行测试、搜索 Slack、查看仪表板、询问人员来获取上下文。

有趣的部分是决定使用哪条路线以及何时使用。

如果智能体需要回答历史问题，也许仅仅检索就足够了。如果他必须修复错误，他就必须阅读真实的代码。如果他需要了解部署失败的原因，他需要查看新日志。如果您需要写信给客户，则需要检索票证的语气、历史记录和状态。如果他必须对生产采取行动，他必须征求许可。

上下文不是数据库。这是一个工作流程。

好的代理也懂得如何忽略

代理人成熟的标志是能够说：我不需要这些信息。

看似微不足道，实则非常困难。许多代理系统不断积累。每个工具调用都会添加文本。每个错误都保留在缓冲区中。每个读取的文件都会添加到堆栈中。最后这个模型已经有很长的历史了，而且没有地图。

需要压缩。需要中间体合成。它需要结构化。

不是“这就是发生的一切”，而是：

• 目标仍然有效；
• 当前的假设；
• 已检查的文件；
• 做出的决定；
• 公开风险；
• 下一步行动。

这使得代理不那么夸张，而且更有帮助。不是因为他看起来更聪明，而是因为他在一张整洁的办公桌上工作。

上下文工程是针对团队的，而不是针对即兴艺术家的

这个话题让我感兴趣的原因是它将责任从个人转移到了系统上。

在即时工程中，最能与模型对话的人往往会获胜。在上下文工程中，最好组织工作的团队会获胜：文档、约定、问题、日志、测试、所有权、命名、来源。

干净的存储库会成为更好的环境。写得好的问题会成为更好的燃料。更新的操作手册可以节省代币和焦虑。清晰的变更日志可以减少幻觉。

这是个好消息，但有些令人不安。美丽是因为它奖励良好的实践。不方便是因为你无法通过巧妙的提示解决所有问题。

这些特工增强了他们发现的系统的卫生状况。

明天我将如何应用它

如果我要将上下文工程引入到一个真实的项目中，我会从小事开始：

• 简短且维护的项目指导文件；
• 预期产出的好例子；
• 可用工具和使用它们的案例列表；
• 以可引用方式编写的架构决策；
• 最低限度强制性背景的问题；
• 易于检索日志和测试；
• 人类可修改的持久记忆。

然后我会衡量一个简单的事情：代理需要澄清多少次或走错方向？

如果这种情况经常发生，我不会立即添加更大的模型。我会看看上下文。

我的阅读

是的，上下文工程这个词有点臃肿。但这个概念是合理的。

它提醒我们，智能体的智能不仅仅存在于模型中。它在于我们为他准备的环境：他看到什么，他记得什么，他能做什么，他被禁止做什么，他认为哪些来源是真实的。

人的部分是这样的：充分准备环境是一种关怀形式。它告诉经纪人，也告诉团队，“我不想让你猜测，我希望你拥有你需要的东西。”

魔法少一点。房间更干净。代理商和我们一样需要它。

来源

• LangChain博客：上下文工程的兴起
• 西蒙·威利森：情境工程
• 模型上下文协议：简介
• [Anthropic：构建有效的代理](https://www.anthropic.com/engineering/building- effective-agents)
• OpenAI：构建代理的新工具