上下文工程旨在构建动态系统，以正确格式提供信息和工具，使 LLM 合理完成任务。它强调了系统性、动态性、信息和工具的正确性、格式的重要性以及任务的合理性。LangGraph 和 LangSmith 有助于实现和优化上下文工程。
译自：The rise of "context engineering"
作者：[no-author]
题图来自 Dex Horthy 在 Twitter 上的分享.
上下文工程是构建动态系统，以正确的格式提供正确的信息和工具，从而使 LLM 能够合理地完成任务。
大多数时候，当代理无法可靠执行时，根本原因是适当的上下文、指令和工具没有传达给模型。
LLM 应用程序正在从单一提示发展为更复杂、动态的代理系统。因此，上下文工程正成为 AI 工程师可以培养的最重要的技能。
什么是上下文工程？
上下文工程是构建动态系统，以正确的格式提供正确的信息和工具，从而使 LLM 能够合理地完成任务。
这是我喜欢的定义，它建立在 Tobi Lutke、Ankur Goyal 和 Walden Yan 最近的观点之上。让我们来分解一下。
上下文工程是一个系统
复杂的代理可能会从多个来源获取上下文。上下文可以来自应用程序的开发人员、用户、之前的交互、工具调用或其他外部数据。将这些整合在一起涉及一个复杂的系统。
这个系统是动态的
许多上下文信息是动态传入的。因此，构建最终提示的逻辑也需要是动态的。它不仅仅是一个静态提示。
你需要正确的信息
代理系统无法正常工作的一个常见原因是它们没有正确的上下文。LLM 无法读懂人心 - 你需要给它们正确的信息。无用输入，无用输出。
你需要正确的工具
并非总是 LLM 仅凭输入就能解决任务。在这种情况下，如果你想授权 LLM 这样做，你需要确保它拥有正确的工具。这些工具可以是查找更多信息、执行操作或介于两者之间的任何工具。为 LLM 提供正确的工具与提供正确的信息同样重要。
格式很重要
就像与人类交流一样，你如何与 LLM 交流也很重要。一个简短但描述性的错误消息比一个大型 JSON blob 有用得多。这也适用于工具。确保 LLM 可以使用工具时，工具的输入参数非常重要。
它能合理地完成任务吗？
在考虑上下文工程时，这是一个值得问的好问题。它强调 LLM 不是读心者 - 你需要为它们的成功做好准备。它还有助于区分故障模式。是因为你没有提供正确的信息或工具而导致失败吗？或者它拥有所有正确的信息，但只是搞砸了？这些故障模式有非常不同的修复方法。
为什么上下文工程很重要
当代理系统出错时，很大程度上是因为 LLM 出错。从第一性原理思考，LLM 出错有两个原因：
- 底层模型只是搞砸了，它不够好
- 底层模型没有传递适当的上下文来产生良好的输出
通常（尤其是在模型变得更好时），模型错误更多是由第二个原因引起的。传递给模型的上下文可能因以下几个原因而不好：
- 只是缺少模型做出正确决定所需的上下文。模型不是读心者。如果你不给它们正确的上下文，它们就不会知道它的存在。
- 上下文格式不佳。就像人类一样，沟通很重要！将数据传递到模型中时，数据的格式绝对会影响它的响应
上下文工程与提示工程有何不同？
为什么从“提示”转移到“上下文”？早期，开发人员专注于巧妙地措辞提示，以引出更好的答案。但随着应用程序变得越来越复杂，很明显，向 AI 提供完整且结构化的上下文远比任何神奇的措辞重要。
我还会说，提示工程是上下文工程的一个子集。即使你拥有所有上下文，在提示中如何组装它仍然绝对重要。区别在于，你不是在设计你的提示以与单个输入数据集良好配合，而是要获取一组动态数据并正确地格式化它。
我还想强调的是，上下文的一个关键部分通常是 LLM 应该如何行为的核心指令。这通常是提示工程的关键部分。你会说，为代理应该如何行为提供清晰而详细的指令是上下文工程还是提示工程？我认为两者兼而有之。
上下文工程的例子
一些好的上下文工程的基本示例包括：
- 工具使用：确保如果代理需要访问外部信息，它拥有可以访问它的工具。当工具返回信息时，它们以 LLM 最容易理解的方式格式化
- 短期记忆：如果对话持续了一段时间，创建对话摘要并在将来使用它。
- 长期记忆：如果用户在之前的对话中表达了偏好，能够获取该信息。
- 提示工程：提示中清楚地列出了代理应该如何行为的指令。
- 检索：动态获取信息并在调用 LLM 之前将其插入到提示中。
LangGraph 如何启用上下文工程
当我们构建 LangGraph 时，我们的目标是使其成为最具可控性的代理框架。这也可以完美地启用上下文工程。
使用 LangGraph，你可以控制一切。你决定运行哪些步骤。你完全决定了 LLM 中包含的内容。你决定在哪里存储输出。你控制一切。
这使你可以进行所有你想要的上下文工程。代理抽象（大多数其他代理框架都强调）的缺点之一是它们限制了上下文工程。可能有些地方你无法完全更改 LLM 中包含的内容，或者无法完全更改之前运行的步骤。
旁注：一篇非常值得阅读的文章是 Dex Horthy 的 "12 Factor Agents"。其中的许多要点都与上下文工程有关（“拥有你的提示”、“拥有你的上下文构建”等）。本博客的题图也来自 Dex。我们非常喜欢他交流空间中重要内容的方式。
LangSmith 如何帮助进行上下文工程
LangSmith 是我们的 LLM 应用程序可观测性和评估解决方案。LangSmith 的一项关键功能是能够 跟踪你的代理调用。尽管在构建 LangSmith 时“上下文工程”一词并不存在，但它恰当地描述了这种跟踪所提供的帮助。
LangSmith 让你看到代理中发生的所有步骤。这让你看到运行了哪些步骤来收集发送到 LLM 的数据。
LangSmith 让你看到 LLM 的确切输入和输出。这让你确切地看到 LLM 中包含的内容 - 它拥有的数据以及它的格式。然后你可以调试它是否包含完成任务所需的所有相关信息。这包括 LLM 可以访问哪些工具 - 因此你可以调试它是否已被赋予适当的工具来帮助完成手头的任务
沟通是你所需要的
几个月前，我写了一篇名为 "沟通是你所需要的" 的博客。主要观点是，与 LLM 沟通很难，而且没有得到足够的重视，并且通常是许多代理错误的根本原因。这些要点中的许多都与上下文工程有关！
上下文工程并不是一个新想法 - 代理构建者在过去一两年中一直在这样做。这是一个新术语，恰当地描述了一项日益重要的技能。我们将撰写和分享更多关于这个主题的内容。我们认为我们构建的许多工具（LangGraph、LangSmith）都非常适合启用上下文工程，因此我们很高兴看到对这一点的重视程度有所提高。
