一个清晰的趋势正在显现：AI应用开发的重心正经历显著转移。

以往，人们见面就问“你的Prompt怎么写？”，仿佛掌握了某种神奇的提示词句式，就能让模型瞬间变成超级智能体。但你有没有发现，这种套路越来越不奏效了？

来看看LangChain最新发布的一篇博文怎么说。其核心观点直截了当：当AI应用从简单的问答对话，进化为复杂的智能体系统时，你会很快意识到，仅靠几句提示词根本撑不住整个局面。即便你只是用模型聊天，也能感受到提示词的边际效用递减得愈发明显——因为如今的模型自身就已经具备智能体能力。

举个直观的例子：Claude能一气呵成地为你绘制一个完整网页、生成SVG架构图，甚至直接用网页版Opus4就能跑出一个独立应用。这些能力几乎完全替代了我们之前对智能体工具的定义。而像Claude Code这类站在巨人肩膀上的产品，更是如雨后春笋般涌现。要在这些系统里真正发挥价值，传统提示词显然难以胜任。

于是，博文提出了一个格局更大的概念：上下文工程（Context Engineering）。

什么是上下文工程？

原文的定义听起来比较官方：“上下文工程，就是构建一个动态系统，以正确的格式提供正确的信息和工具，从而让大语言模型能够合理地完成任务”。读起来有点绕，我们来拆解一下：

• 它是一个动态系统。 复杂的智能体，其上下文来源是多点开花的：开发者预设的指令、用户实时输入的问题、历史对话记录、工具调用返回的数据、甚至外部数据库。把这些零散碎片拼成一张有用的“图”，本身就是个系统工程。
• 它是动态变化的。 很多上下文是实时输入的，这意味着你最后喂给大语言模型的“提示”，必须是动态生成的，而不是一个写死的模板。
• 需要“正确”的信息。 模型不是神，你得把完成任务最关键的东西喂进去。Garbage in, garbage out——输入无效，输出自然不会好看。
• 需要“正确”的工具。 很多时候，光靠已有信息，模型自己搞不定。你得给它趁手的兵器。比如Claude Code在执行过程中，会自动调用搜索引擎、访问API、启用MCP。给对工具，和给对信息一样重要。
• “格式”至关重要。 怎么跟模型对话，直接影响它的表现。一个简短清晰的错误提示，远比一个庞大的JSON数据块好消化。工具的输入参数如何设计，也决定了模型能不能用起来顺手。

所以，当你用Claude Code或Gemini CLI觉得不够理想时，不妨问自己一个根本问题：

“在给定了这些信息和工具的前提下，一个人类同事能合理地完成这个任务吗？”

这本质上是拷问：到底是模型能力不行，还是你根本没给它创造成功的条件？

它跟提示工程到底有什么区别？

听起来好像是换了个马甲？其实不然。

过去的提示工程，更侧重遣词造句，是在“怎么说”上下功夫，引导模型给出好答案。

而上下文工程的格局大得多，它关心的是在调用模型之前，如何设计一整套系统，来动态地、结构化地准备好所有必要条件。它关心的是“提供什么”，而不仅仅是“怎么说”。

打个比方：

• 提示工程，是战术层面，优化与模型单次交互的会话。
• 上下文工程，是战略层面，构建一个能持续提供高质量内容的系统。

理论有些抽象，结合Claude Code来看看具体实践：

• 工具集成。 Claude Code内置了大量工具，会根据任务场景自动调用外部工具获取信息，比如待办列表、网络搜索等。
• 记忆系统。 分为短期与长期。短期记忆在长对话中自动将前面的聊天内容摘要化，作为后续上下文，防止模型“失忆”；长期记忆则以文本形式记录到一个MD文件中，记住用户的偏好习惯，并在新交互中主动利用这些信息。
• 检索增强（RAG）。 在回答专业问题前，先从知识库中动态检索相关文档注入到上下文，让回答更精准有力。
• 指令设计。 在系统提示词中清晰列出智能体的角色、行为准则和目标，这是基础的上下文结构保证。

这些就是典型的上下文工程实践。文中提到的LangGraph智能体框架，也正是这类思想的最好印证。

总结

说到底，上下文工程的核心就两个字：沟通。大多数智能体系统的失败，并非模型能力不够，而是缺乏适当的上下文沟通。它是未来正确创建和使用智能体的新范式。

不管怎样，单靠提示词工程打天下的时代已经过去了。我们需要的，不再是“提示词魔法师”，而是能够设计和构建复杂、动态、可靠的上下文系统的上下文工程师。