这篇发表在langchain博客里面的文章还挺有意思的。
过去我们绞尽脑汁琢磨Prompt怎么写，看别人做出来一个东西第一个反应的就是问他提示词是什么。
但是，现在情况变了，LLM应用早已经从从单一问答走向复杂的智能体系统，你会发现单纯的提示词作用并不是很大。
哪怕是在单纯使用模型会话，也会发现这提示词的效能提升越来越小，因为现在很多的模型自身即是Agent。
比方说，使是Claude就能制作一个完整的网页和SVG架构图，甚至是直接使用Opus4网页版就可以完成一个独立应用。他们都在很大程度上可以直接取代现在的所谓的一些Agent产品了。而构建在这些模型之上的Agent应用也如雨后春笋一样的爆发，比如现在火热的Claude Code。
我们要搭建或者用好这类Agent，传统的提示词可能就很难支撑。所以，这篇文章当中提出了一个比提示词更宏大、也更根本的概念：
上下文工程（Context Engineering）。
LangChain的博文写到：上下文工程，正在成为AI工程师最重要的技能。
对于什么上下文工程？在这篇博客中的定义如下：
上下文工程，就是构建一个动态系统，以正确的格式提供正确的信息和工具，从而让大语言模型（LLM）能够合理地完成任务。
这个表述其实比较的官方，不是特别好懂，定义信息量也很大，我们拆开来看：
复杂的智能体，其上下文来源是多样的：开发者预设的指令、用户的实时输入、历史对话记录、工具调用返回的数据，甚至是外部数据库。将这些零散信息整合起来，本身就需要一个复杂的系统工程。
许多上下文是实时输入的，这意味着最终构建给LLM的“提示”，也必须是动态生成的，而不是一个写死的静态模板。
LLM不是神，不会读心术。你必须把完成任务所需的关键信息喂给它。所谓“Garbage in, garbage out”，没有有效的输入，就不可能有好的输出。
很多时候，单靠已有信息，LLM无法独立解决问题。这时，就必须赋予它合适的“工具”，比如Claude Code在执行过程当中，会主动调用搜索引擎、访问API、调用MCP等。给对工具，和给对信息一样的重要。
如何与LLM沟通，直接影响它的表现。一个简短清晰的错误提示，远比一个庞大的JSON数据块更容易让模型理解。工具的输入参数如何设计，同样决定了LLM能否有效使用它。
所以，当你构建的Agent或者在使用类似于Claude Code Gemini CLI表现不佳时，其实可以问自己这样的一些问题：
“在当前给定的信息和工具下，一个人能合理地完成这个任务吗？”
本质上就是：究竟是模型能力不行，还是你根本没给够它成功的条件？
看起来似乎和提示工程也没啥区别呀！它和提示工程有何不同？
过去的提示工程，更侧重于遣词造句，想方设引导模型给出好答案。
而上下文工程的格局更大，范围更广，关注点更多。
它关注的是在调用模型之前，如何设计一整套系统来动态地、结构化地准备好所有必要条件。它关心的是“提供什么”，而不仅仅是“怎么说”。
说的更简单一点：
提示工程，战术层面，优化与LLM单次交互的会话。
上下文工程，战略层面，构建一个能持续提供高质量的系统。
理论多少有点抽象，来结合Claude Code的特性看看例子：
Claude Code集成了大量的工具集，会根据实际的场景和需求调用外部工具获取信息，比方说To do list，Web search等工具。
Claude Code中的记忆，其实也分为两种：短期记忆 ，在长对话中，自动将前面的聊天内容总结成摘要，作为后续对话的上下文，避免模型“失忆”，Claude Code就有专门的上下文压缩机制。
长期记忆Claude Code中是以文本的形式记录到一个MD文件当中，它会记住用户在过去对话中表达的偏好、习惯，并在新的交互中主动利用这些信息。
检索增强RAG，在回答专业问题前，先从知识库中动态检索相关文档，并将其注入到上下文中，让回答更精准、更有依据。
另外就是指令设计，在系统Prompt中清晰地列出智能体的角色、行为准则和目标。
这些，都是典型的上下文工程实践，文中还特别提到了LangGraph智能体框架，也充分印证和说明了以上的特点（对于这个智能体框架字节笔记本微信公众号里面都有相关的介绍，可以回复相关的关键字进行查看）
上下文工程归结起来其实就沟通二字：大多数智能体系统的失败并非模型能力不足，而是缺乏适当的上下文沟通，它将是未来正确创建和使用Agent的新范式。就Cursor文档驱动开发以及AI时代的文档编写新范式！
不管怎么样，单纯地依靠提示词工程现在已经不足以应对现在复杂的业务场景了，我们需要的不再是“提示词魔法师”，而是能够设计和构建复杂、动态、可靠的上下文系统的“上下文工程师”。
粤ICP备14082021号
免费POC，
零成本试错
