从提示词到上下文：范式的转移
过去，构建更好的AI系统往往被简化为编写完美的提示词（Prompt），即所谓的“提示词工程”。然而，随着大型语言模型和AI智能体技术的演进，行业重心正从单纯的提示词优化转向更为宏观的上下文工程（Context Engineering）。这一转变并非否定前者的价值，而是认识到在复杂场景中，仅靠指令措辞已不足以支撑智能体的运作。上下文工程被定义为一种刻意结构化并优化传递给LLM或智能体信息的实践，旨在产生更准确且相关的输出。
为了理解这一概念的重要性，我们可以类比人类的认知机制。研究表明，人类的工作记忆有限，我们一次只能处理和保持大约3到5条信息片段，持续时间约为20秒。当面临多任务处理时产生的认知过载感，正是源于这种限制。为了应对这一挑战，人类倾向于将信息“分块”（chunking）或拆解为更小的子任务。AI模型处理大量信息的方式与此惊人相似，尽管现代模型支持数百万token的上下文窗口，但更多的上下文并不等同于更好的性能。事实上，随着上下文的膨胀，模型的性能可能会下降，这种现象有时被称为“上下文腐烂”（context rot）。过多的无关信息、结构混乱或缺失的数据会导致推理能力变差和幻觉增加。
"Context engineering is the practice of deliberately structuring and optimizing the information passed to an LLM or agent to produce more accurate and relevant outputs."
"Too much irrelevant information, poorly structured or missing data leads to worse reasoning and hallucinations."
上下文工程的定义与核心差异
要深入理解上下文工程，必须明确其与提示词工程的本质区别。提示词工程主要关注如何措辞指令以获取期望的输出，而上下文工程则聚焦于提供给模型的整个信息环境。 换句话说，提示词工程只是上下文工程的一个组成部分。这一区分在构建AI智能体时至关重要，因为智能体不仅仅回答单一问题，它们需要在多个步骤中进行推理、使用工具、检索信息并更新记忆以做出决策。
这就好比给员工布置任务：如果只给出一页关于“如何接待新同事”的简单说明，执行者很容易快速理解并完成任务；但如果提供4000页杂乱的Slack聊天记录、邮件和随机笔记，执行者将难以辨别哪些信息对当前任务至关重要。上下文工程的目标不是给模型更多信息，而是提供格式正确的正确信息。
在推理阶段，上下文包含了所有模型可见的元素。以LLM为例，这包括系统提示、用户查询、从外部源（如向量数据库或文档存储）检索的任何文档或信息，以及LLM与用户之间过去交互和响应的历史。此外，任何额外系统的输出（如工具输出、API响应或其他智能体的结果）也属于上下文的一部分。对于需要多步推理的智能体而言，管理如此庞大的信息量成为了一项核心挑战。
"Prompt engineering is all about asking, how do I phrase the instructions to get what I want out of this LLM? In contrast, context engineering is about focusing on the entire information environment provided to the model."
"Agents don't just answer one question. They reason across multiple steps. They use tools. They retrieve information. And update memory to make decisions."
优质上下文的四大特征与处理流程
构建有效的上下文需要遵循几个关键特性，这些特性共同构成了上下文处理（Context Processing）的基础。首先是相关性：包含的每一条信息都应有助于模型完成任务。其次是结构化：信息应清晰组织，通常带有标签或格式，帮助模型区分不同类型的信息。第三是时机：特别是在智能体系统中，上下文应在需要时才引入。最后是压缩：与其将原始数据倾倒到提示中，不如总结或过滤出最有用细节。这些转换步骤的结果是可用的上下文。
在处理好单次输入后，下一步是上下文管理（Context Management），这是一个跨交互和随时间推移维持模型上下文的持续过程。其核心思想包括决定保留什么、丢弃什么，以确保相关信息得到维护，而不必要或过时的信息被移除或最小化。在对话系统中，这意味着跟踪相关的用户输入、系统指令和之前的响应，以便模型能够一致地回应并意识到上下文。
此外，必须对信息进行优先级排序。并非所有信息都同等重要，上下文管理根据相关性、近期性或任务重要性为某些数据分配优先级。同时需要处理信息生命周期，当新信息可用时更新上下文，使旧数据失效，并确保上下文反映最准确和当前的知识状态。这在信息随时间变化的动态环境中尤为重要。最后，必须保持一致性和连贯性，确保检索到的信息被正确集成，且整体上下文继续合乎逻辑。
"The goal isn't to give the model more information, but rather the right information in the right format."
"Instead of dumping raw data into the prompt, we often summarize or filter only the most useful details. This set of transformative steps helps result in usable context and this is called context processing."
医疗预约场景中的上下文工程实战案例
为了具体说明上下文工程的实际应用，我们可以考察一个为医疗保健提供商构建AI助手以协助患者预约的场景。该系统需要整合多个数据源、约束条件和工具输出来生成决策。如果没有这些元素，一个简单的提示可能只是“为这位患者安排预约”，但这留下了大量的错误空间。 模型不知道诊所的规则、医生的可用性，甚至不了解患者的病史。
通过引入上下文工程，系统不再仅提供提示词，而是提供完整的结构化背景。这包括：诊所的预约政策（如预约类型和时长）、医生的实时可用性、患者的偏好（例如仅限上午）以及相关的病史。此外，系统还会整合来自调度API的工具输出（即可用的时间段）。当模型生成响应时，它不再是猜测，而是基于完整的结构化上下文进行推理。
"Imagine you're building an AI assistant for a healthcare provider that helps patients schedule appointments. Under the hood, this is a system that requires multiple data sources, constraints, and tool outputs to generate decisions."
"Instead of saying, here are some available slots, it can say, you're due for a follow-up visit and Dr. So-and-so is available at Wednesday at 10 a.m., which matches your preference for morning appointments. Would you like me to book that?"
这种转变使得AI的输出从模糊的“这里有一些可用时段”变为具体的、个性化的建议：“您需要进行随访，某某医生在周三上午10点有空，这符合您对早晨预约的偏好。需要我预订吗？”这种基于丰富上下文的推理显著提升了用户体验和任务完成的准确性。
结论
上下文工程代表了AI应用开发从微观指令优化向宏观信息架构设计的范式转移。随着智能体在推理、工具使用和记忆更新方面的能力增强，仅靠提示词已无法应对复杂的多步任务需求。尽管模型拥有巨大的上下文窗口，但“更多”并不等于“更好”，无关或结构混乱的信息会导致性能下降和幻觉（上下文腐烂）。因此，成功的AI系统依赖于对上下文的精心工程化设计：确保信息的相关性、结构化、适时引入和压缩处理。通过像医疗预约案例中那样，整合政策、实时状态和用户偏好等多维数据，AI才能从简单的信息检索者转变为具备真正推理能力的智能助手。掌握上下文工程已成为构建高效、可靠AI智能体的关键技能。
"Whether you're building AI agents, experimenting with workflows, or just trying to understand where the field is headed, context engineering is becoming one of the most important skills to understand."
"Context is everything the model sees at inference time... The output of any additional systems like tool outputs, APIs, or other agents."