通过掌握真正重要的东西来释放AI的全部潜力：上下文
有一段时间，提示词工程是AI世界的流行词。
我们在网上分享提示词技巧。 我们收藏提示词库。 我们争论"扮演一个..."是否比"你是一个..."给出更好的结果。
说实话，这很有道理——当AI主要意味着与GPT聊天时。
但游戏规则已经改变了。
当提示词不再足够时在ChatGPT的早期，你可以通过巧妙的措辞完成令人惊讶的工作量。 想要一首诗？ 想要代码？ 想要结构化的JSON响应？
你只需要找到魔法词汇。我们做到了。提示词工程是关于制作巧妙、简洁的请求，从黑盒中挤出性能。
但我们不再只是聊天了。
我们在构建。
能够规划、推理和行动的AI智能体。 动态获取和注入信息的RAG系统。 具有记忆、工具和状态的工作流。 融合文本、代码、视觉、音频和工具的多模态管道。 所有这些都依赖于一件事：上下文。
什么是上下文工程？
说实话，只有这个术语是新的。 如果我们实事求是——我们已经在做上下文工程了，只是没有这样称呼它。
每次我们制作更好的提示词时，往往是因为我们提供了更好的上下文。 更多的清晰度。更多的例子。更多的约束。
"更好的提示词"只是那个有更好上下文的。
但现在，它提升到了另一个层次。
我们不再只是调整短语——我们在构建系统： 记忆、检索、工具、状态、多模态信息——全部缝合在一起，为模型提供它需要的东西，在它需要的时候。
正如Andrej Karpathy（特斯拉前AI总监、OpenAI创始成员、著名AI教育家）所说：
"支持'上下文工程'而不是'提示词工程'。 人们将提示词与简短的任务描述联系起来... 而在每个工业级LLM应用中，上下文工程是用恰好正确的信息填充上下文窗口以进行下一步的精妙艺术和科学..."
让这句话深入人心： 上下文工程是决定模型在每一步知道什么、看到什么和记住什么的关键。
它不仅仅是关于你说什么，而是关于模型在幕后看到什么。
Karpathy继续将"上下文窗口"描述为真正的战场：
"...任务描述、示例、RAG结果、多模态输入、工具调用、状态/历史——所有这些都需要仔细编排。"
它是信息设计、软件架构和叙事的结合。
甚至Datasette的创建者Simon Willison也呼应了这种转变：
"'提示词工程'让人们想到巧妙的文字游戏。 但现在重要的是以正确的格式、正确的顺序构建正确的数据。"
那么为什么上下文是新技能？问题在于：
LLM对上下文很饥渴。它们不"知道"世界——你必须在运行时给它们重要的东西。
无状态模型需要智能状态管理。如果你想要连续性、历史、事实、工具和记忆——你必须构建和注入这些。 多步骤智能体不能仅仅依赖提示词。它们需要不断发展的计划、动态记忆和工具访问——所有这些都编码在上下文中。
换句话说：
提示词是口红。 上下文是底层系统。
现实世界中的上下文工程是什么样的
让我们从流行词转向现实。以下是上下文工程的5个例子：
RAG（检索增强生成）： 动态获取相关块（来自PDF、向量数据库等）并将它们加载到提示词中——针对每个查询量身定制。
具有记忆/状态的智能体： 跟踪之前的步骤、结果和计划。存储中间推理，并智能地重新注入。
多轮对话系统： 不是倾倒完整的聊天历史，而是抽象和总结之前的轮次以保留信号，而不是噪音。
工具增强工作流（LangChain / OpenAgents）： 将工具输出作为结构化上下文反馈到循环中——解析、过滤、格式化和注入。
少样本或上下文学习： 选择高质量、相关的示例，实际指导行为——不只是更多标记。
为什么专注于上下文工程？因为这是杠杆所在。
掌握上下文工程的工程师和研究人员：
构建更有能力、更可靠的系统。 在不重新训练或微调的情况下提高性能。 将通用模型定制为领域专家。 通过正确的上下文设置解锁涌现能力。 也许最重要的是——他们扩展得更快。 你不需要定制LLM。你需要在正确的时间以正确的格式提供正确的信息。
LangGraph如何实现上下文工程当我们构建LangGraph时，我们的目标是使其成为最可控的智能体框架。
这也使其能够完美地实现上下文工程。 通过LangGraph，你可以控制一切。
你决定运行哪些步骤。你决定究竟什么进入你的LLM。你决定在哪里存储输出。
你控制一切。 这允许你进行所有你想要的上下文工程。
智能体抽象的缺点之一（大多数其他智能体框架都强调这一点）是它们限制了上下文工程。
可能存在一些地方，你无法改变究竟什么进入LLM，或者究竟事先运行了哪些步骤。
示例：简化的图调用
# 当前方式（仍然支持）
agent.invoke(
state,
config={"configurable": {"user_id": "user_123", "thread_id": "12345"}}
)
# 新方式（推荐）
agent.invoke(
state,
config={"thread_id": "12345"},
context={"user_id": "user_123"},
)
示例：增强的节点函数签名
# 当前方法
def my_node(state: StateSchema, config: RunnableConfig):
user_id = config["configurable"]["user_id"] # 深层嵌套
# ...
# 新方法
class Runtime(Generic[ContextT]):
context: ContextT
config: LangGraphConfig # 具有顶级属性的更清洁配置
@property
def stream_writer(self) -> StreamWriter:
"""无需在节点签名中进行复杂注入即可访问流式工具。"""
def my_node(state: StateSchema, runtime: Runtime):
user_id = runtime.context.user_id # 清洁、类型化的访问
thread_id = runtime.config.thread_id # 不再嵌套在"configurable"下
# ...
提示词工程让我们起步。 上下文工程是我们如何变得专业。
这种转变反映了AI的演变： 从"聊天玩具"→到"核心基础设施"。 从"巧妙提示词"→到"动态、分层、状态感知系统"。
所以下次有人谈论"提高提示词技能"时， 问问他们的上下文管道是什么样的。
因为在现代LLM的世界中， 上下文不是可选的——它是真正的输入。
觉得这有帮助？ 关注我获取更多关于AI、自动化和塑造未来系统的见解。 让我们超越流行词汇——构建更智能的系统。
