理解“什么是上下文工程？这项能力如何把 AI 演示变成真正可用的 AI”，最好的方式不是把它当作又一个 AI 流行词，而是把概念放进真实决策中。AI Tools Radar 的这篇指南聚焦其实际含义、真正重要的取舍，以及采用某款工具或工作流前值得提出的问题。
2025 年 6 月，Andrej Karpathy 发布了一则定义，此后成为这门新兴学科最常用的表述：上下文工程是“为下一步在上下文窗口中填入恰到好处的信息的一门精细艺术与科学”。
这个说法之所以重要，是因为它为从业者一直在做、却尚未命名的工作赋予了名称。每一个严肃的 AI 应用、每一个生产环境中的智能体，以及每一套真正能够持续交付结果的工作流，都需要有意识地决定模型运行时能看到哪些信息。这些决策合在一起，就是上下文工程。
相比之下，提示词工程是大多数人想到“使用 AI”时首先联想到的事情：写出更好的指令、清晰措辞、加入示例。提示词工程真实且有用，但它只解决问题的一个层面，而在生产系统中，这一层往往还不是最重要的。
上下文工程是一门范围更广的学科。它关注的不只是你向模型提出什么要求，还包括模型回答时知道的一切：它遵循的指令、可以调用的工具、对话历史、为支持任务而检索的文档，以及关于你是谁、正在做什么的记忆。能否在正确时刻以正确组合提供这些要素，决定了 AI 应用究竟成功还是失败。
上下文工程与提示词工程：究竟有何不同。
这种区别并非学术争论。对于所有构建 AI 系统或希望稳定使用 AI 的人，它都会带来实际后果。
提示词工程聚焦查询本身：问题该怎样措辞？应加入哪些示例？如何组织指令，才能得到所需的输出格式？它通常假定一个相对静态的场景：一个模型、一名用户、一项请求。
上下文工程聚焦模型所处的环境：用户输入之前，模型已经知道什么？哪些信息会被检索并注入？如何管理对话历史？有哪些工具可用？系统中内置了哪些约束？它把模型的上下文窗口视为需要主动设计的界面，而不是一张白纸。
LangChain 对上下文工程的解析这样概括两者差异：提示词工程是提出正确的问题；上下文工程则是为模型创造最佳环境，使它能够识别并执行正确的解决方案，有时甚至不需要用户主动提问。
在日常的轻量 AI 使用中，提示词工程通常已经够用。你打开 ChatGPT，提出问题，如果答案不理想就调整措辞。这没有问题。
但在生产级 AI 系统中，提示词工程只是基本功。到 2026 年，一个典型的已部署应用会涉及检索、工具调用、对话历史管理、结构化状态、条件路由，有时还要协调多个模型。其中每一项都包含上下文决策，而这些决策的质量会决定系统每一次输出的质量。
上下文窗口不只是你输入的文字。在任何经过良好设计的 AI 应用里，为一次模型调用组装的上下文通常包含几个不同层次：
系统提示 它是一组持续生效的指令，用来定义模型的角色、约束和行为。模型是谁？能做什么？绝不能做什么？设计良好的系统提示不是一段模糊的建议，而是一套经过谨慎维护、影响每次回答的规则与角色定义。
对话历史 也就是迄今为止说过的内容。保留多少历史、内容变长后如何压缩、哪些部分应总结、哪些必须逐字保存，都是需要主动作出的工程决策。历史过多会浪费上下文空间，太少则会让复杂多步骤任务失去连贯性。
检索文档 在推理时从外部知识源获取并注入上下文的信息。这就是检索增强生成（RAG），也是上下文工程最重要的基础能力之一。检索质量、文本块大小、相关性排序以及检索内容的排列顺序，都会影响输出质量。
工具定义 这些接口让模型可以采取行动，例如调用 API、运行代码、搜索网络或写入数据库。工具如何描述、开放哪些参数，以及特定上下文中有哪些工具可用，都属于上下文工程决策。
记忆 关于用户、项目或历史互动的持久化信息。短期记忆可能是最近几次交流，长期记忆则可能包含用户偏好、以往决定，以及持续工作中积累的知识。Weaviate 对上下文工程的分析将记忆描述为这样一层能力：它使 AI 系统能够随时间真正实现个性化，而不是每次会话都从头开始。
状态与结构化数据 对于跨越多个步骤的智能体工作流，任务当前状态、此前步骤的输出，以及模型推理所需的任何结构化数据，都属于必须谨慎管理的上下文。
上下文工程的艺术，在于为每一次具体调用正确组装这些层次：决定哪些内容应纳入、哪些应压缩、哪些需要检索、哪些应该舍弃，让模型得到完成任务所需的一切，同时没有削弱有效信号的杂音。
为什么上下文工程已成为关键能力。
三项变化使上下文工程在大多数严肃 AI 工作中变得比提示词工程更重要。
智能体 AI 的兴起。当模型只针对一个问题运行一次时，提示词工程最为重要；当模型循环运行、采取行动、接收结果并决定下一步时，上下文会随每一步不断变化。智能体的质量几乎完全取决于每一步的上下文是否包含作出正确决定所需的信息。Deepset 的分析认为这是核心驱动力：随着 AI 系统自主性提高，上下文设计正成为占主导地位的工程挑战。
上下文窗口变长，但稀缺性问题依旧存在。如今模型可以支持 100 万 token 的上下文窗口，看起来似乎解决了问题，实际上并没有。装满无关信息的 100 万 token 窗口，会比只含恰当信息的 10 万 token 窗口产生更差的结果。容量增加不会消除筛选的必要，反而会提高代价。大规模而粗糙的上下文工程意味着更多噪声，而不是更少。
演示与生产之间的鸿沟。做出令人惊艳的 AI 演示很容易：手工准备上下文、精挑输入，然后只运行一次。但要让一个 AI 系统面对数千名用户、数千种输入和状态仍能稳定工作，非常困难。两者的差异几乎总能追溯到上下文工程。演示之所以成功，是因为有人手工做出了良好的上下文选择；生产系统之所以失败，是因为这些选择从未被系统化。
还有一层上下文工程几乎被所有工具和框架忽略：你的个人上下文。
系统提示、工具定义和检索文档，都是团队能够在应用层解决的工程问题。但还有一类上下文只属于你：过去六个月积累的研究、与客户进行的会议、团队上季度作出的决定，以及你对具体工作情境积累的知识。任何 AI 应用都不会自带这些上下文，也不可能自带，因为它们属于你。
这正是多数 AI 工具在严肃知识工作中令人沮丧的原因。模型能力足够强，基础设施也很完善，但每次会话仍从零开始。“模型了解世界多少”与“模型了解你的工作多少”之间的距离，限制着你获得的每一项输出。
对多数人而言，从提示词工程转向上下文工程会经历三个阶段。
阶段 1：有意识的系统设计。 不要再把系统提示当作附带事项。清楚定义模型是什么、不是什么、始终应该做什么、绝不能做什么。把系统提示当作代码：进行版本管理、测试变更并持续维护。
阶段 3：多步骤任务的状态管理。 当任务跨越多个步骤或多次模型调用时，应明确跟踪状态：已经决定了什么？产出了什么？还有哪些工作？主动将这些状态传递到后续步骤，而不是希望模型仅凭对话历史自行重建。
这三个阶段背后的原则相同：模型输出质量取决于输入上下文的质量。设计好上下文，才是真正的工作。
上下文工程只适合开发者吗？ 不是。这个术语源于软件工程，但实践适用于每一个经常使用 AI 工具的人。向 AI 助手提问前决定加入哪些信息、整理相关文档以便放进会话，或者用知识库持续积累工作笔记，都是上下文工程，即使一行代码也没有写。
RAG 与上下文工程有什么区别？ RAG（检索增强生成）是上下文工程的组成部分，负责检索相关文档并将其注入上下文。上下文工程的范围更广，还包括系统提示设计、记忆管理、工具定义、对话历史处理，以及多步骤工作流中的状态跟踪。
更大的上下文窗口会降低上下文工程的重要性吗？ 不会。更大的窗口提供更多容量，却不会降低放入什么内容的重要性。缺乏重点的 100 万 token 上下文，比聚焦的 10 万 token 上下文效果更差。容量越大，信息的筛选、排序和压缩反而越重要。
上下文工程与 AI 智能体是什么关系？ 上下文工程是智能体设计的基础。智能体的可靠性取决于它在每一步获得的上下文。系统提示质量、工具定义、检索到的状态和记忆管理，共同决定智能体能否作出良好决策，还是会发生偏离、幻觉或陷入循环。在智能体应用中，上下文工程欠佳造成的后果最为明显。
上下文工程并非一种潮流，而是让 AI 应用达到用户实际所需质量的学科。从“提出更好的问题”转向“设计更好的信息环境”，意味着从使用 AI 走向用 AI 构建，也意味着从容忍不稳定结果走向期待可靠表现。
判断这套方法是否值得采用，要看它能否改善一项可重复的工作，同时不掩盖来源、成本或失败方式。先用一个有代表性的任务试行，在错误会造成影响的环节保留人工检查点，并随着模型和产品变化重新评估结果。
我们会结合一手资料、产品文档与实际使用场景，帮助你更清楚地判断工具是否适合你的工作流。