【译】“上下文工程”的兴起“上下文工程”的兴起上下文工程，就是搭建动态系统，以正确的信息、工具和格式，让 LLM 有可

“上下文工程”的兴起

上下文工程，就是搭建动态系统，以正确的信息、工具和格式，让 LLM 有可能完成任务。

大多数代理表现不稳定，根因都是没把合适的上下文、指令和工具传给模型。

LLM 应用正从单一提示词演进为更复杂、动态的代理系统。因此，上下文工程正成为AI 工程师最重要的技能。

上下文工程，就是搭建动态系统，以正确的信息、工具和格式，让 LLM 有可能完成任务。

我喜欢的这个定义，基于 Tobi Lutke、Ankur Goyal 和 Walden Yan 最近的观点。拆开来看：

上下文工程是一个系统

复杂代理可能从多个来源获取上下文：应用开发者、用户、过往交互、工具调用或其他外部数据。把这些拼在一起需要复杂的系统。

这个系统是动态的

很多上下文是动态进来的，因此构建最终 prompt 的逻辑也得动态，而不是一份静态提示词。

你需要正确的信息

代理失效的常见原因是没有正确的上下文。LLM 不是读心术——必须给它对的信息，垃圾进垃圾出。

你需要正确的工具

LLM 并不总能仅靠输入解决任务。要赋能它，就要确保有合适的工具：查信息、执行动作或其他操作。给对工具跟给对信息一样重要。

格式很重要

和人与人交流一样，怎么和 LLM 交流也很重要。简短但描述清晰的报错，远比一大坨 JSON 有用。工具亦然，输入参数设计直接影响 LLM 是否能用好。

它能现实地完成任务吗？

做上下文工程时值得常问这个问题。它提醒我们 LLM 不是读心者，需要帮它设好舞台。也有助于区分失败模式：是没给对信息/工具，还是信息齐全但模型仍失误？不同模式的修法完全不同。

代理出错，大多是 LLM 出错。从第一性原理看，LLM 出错有两个原因：

多数情况下（尤其模型越来越强时）错误更像是第二种。传给模型的上下文可能糟糕，因为：

为何从“提示词”转向“上下文”？早期大家用巧妙措辞来榨答案。但应用复杂起来后，显然给 AI 提供完整且结构化的上下文比任何魔法措辞都更重要。

我认为提示词工程是上下文工程的子集。即便拿到了所有上下文，如何在 prompt 里组装仍然关键。区别在于：你不是让 prompt 只适配一组输入，而是接受一组动态数据并正确格式化。

还要强调，核心指令（LLM 应该如何行为）也是上下文的重要部分，往往是提示词工程的关键。给代理清晰、细致的行为指令算上下文工程还是提示词工程？我觉得两者都有。

一些基础案例：

我们做 LangGraph 时，希望它成为最可控的代理框架，也因此能完美支持上下文工程。

在 LangGraph 中，你能控制一切：决定执行哪些步骤、准确传什么给 LLM、把输出存哪儿——全都由你定。

这让你能做想做的上下文工程。许多代理抽象层（其他框架常强调）反而限制了上下文工程：有些地方你改不了送进 LLM 的具体内容，或前置步骤无法调整。

顺带一提，推荐阅读 Dex Horthy 的《12 Factor Agents》。很多点都与上下文工程相关（“掌控你的 prompt”“掌控上下文构建”等）。这篇博客的封面图也来自 Dex，我们很喜欢他阐述重点的方式。

LangSmith 是我们的 LLM 应用可观测与评测方案。它的关键特性之一是能追踪代理调用。虽然当初做 LangSmith 时还没有“上下文工程”这个说法，但它正好描述了追踪能提供的帮助。

LangSmith 让你看到代理的每一步，明确为收集送进 LLM 的数据跑了哪些步骤。

LangSmith 让你看到送进 LLM 的精确输入和输出，清楚它拥有哪些数据、格式如何。你可以据此调试：是否包含了完成任务所需的关键信息？也包括 LLM 能用哪些工具——好调试是否给了它合适的工具。

几个月前我写过一篇博客《Communication is all you need》。主旨是：和 LLM 沟通很难、常被低估，而且往往是代理出错的根源。这些点很多都与上下文工程有关！

上下文工程不是新概念——过去一两年代理开发者一直在做。只是用一个新术语恰当地描述了这项日益重要的技能。我们会继续写更多内容。我们认为自己构建的工具（LangGraph、LangSmith）非常适合启用上下文工程，也很期待看到这股趋势继续升温。