Andrej Karpathy 又带火了一个词——Context Engineering。
Shopify CEO Tobi Lütke 的一条推特引发了行业对此的广泛讨论，Andrej Karpathy 转发并表示强烈认同。
这不是一个新概念，只是业内共识的逐渐形成：决定 AI 应用效果的关键，已经不是你怎么问，而是你给 AI 喂了什么料。
提供完整且恰当的上下文往往比编写好的提示词更重要。
到底什么是「上下文工程」，在应用的落地开发中怎么更好使用「上下文工程」？ 我们整理了 DeepMind 工程师 Philipp Schmi、以及 LangChain 对此的讨论，希望在一篇文章里介绍清楚「上下文工程」的概念以及实操落地的问题。
01
Karpathy：
「上下文工程」既是科学也是艺术
图：Andrej Karpathy 推特内容
支持「上下文工程」而不是「提示工程」。
人们通常将提示词（prompt）与日常使用中给 LLM 的简短任务描述联系起来。但在每个工业级 LLM 应用中，上下文工程（Context Engineering）是一门精妙的艺术与科学——它需要精准地为上下文窗口填充恰到好处的信息。
说它是科学，因为这项工作涉及任务描述与解释、少量示例、检索增强生成（RAG）、相关（可能是多模态的）数据、工具、状态与历史记录、信息压缩...提供太少或形式不当，LLM 就缺乏最优表现所需的上下文；过量或相关性不足，则会导致成本上升性能下降。做好这件事绝非易事。
而称之为艺术，则源于对人类心理与 LLM 行为之间微妙互动的直觉把握。
除了上下文工程本身，一个 LLM 应用还必须能够实现：
因此，上下文工程只是新兴复杂软件层中的一小部分，这些软件将单个 LLM 调用（以及更多内容）协调成完整的 LLM 应用。「ChatGPT 包装器」（ChatGPT wrapper）这个说法已经过时，而且大错特错。
在交流中，Karpathy 表示：
我并不是要造新词。只是觉得人们使用「prompt」这个词时，往往（错误地）低估了这个相当复杂的组件。你给 LLM 一个提示让它解释天空为什么是蓝色的。但应用程序会（精心）为 LLMs 构建上下文来解决它们的定制任务。
02
什么是上下文工程？
要理解上下文工程，我们首先得拓宽对「上下文」的定义。它不仅仅是发给大语言模型的一句提示词，而是模型生成回答之前所看到的一切信息。
图：上下文工程所包含的范围
上下文工程包括：
指令 / 系统提示词： 定义模型整体行为的初始指令，可以（也应该）包含示例、规则等。
用户提示词： 用户提出的即时任务或问题。
当前状态或对话历史（短期记忆）： 用户和模型此前的对话内容，展现当前交流的背景。
长期记忆： 跨多次对话积累的持久性知识库，比如用户喜好、历史项目摘要、记住的特定事实。
检索的信息（RAG）： 外部的、最新的信息，包括从文档、数据库或 API 获取的相关内容，用于回答特定问题。
可用工具： 模型可以调用的所有函数或内置工具定义（如检查库存、发送邮件等）。
结构化输出： 明确定义模型输出的格式，例如 JSON 格式的对象。
03
提示词工程、上下文工程
到底啥区别？
提示词、提示词工程、上下文工程，三者的区别是什么？
提示词（Prompt）
提示词很好理解，就是用户给 AI 模型的 输入文本，直接向模型输入的问题或指令。 比如用户让 ChatGPT 总结一段文本、调用模型 API 传入提示词去翻译一篇文章等。简单理解，提示词是一段文本，有点像代码。
提示词工程 （Prompt Engineering）
提示词工程是一个过程，系统化地设计、测试、优化提示词的过程。
就像软件工程，我们为了完成某个需求，要有一套科学的方法来帮助完成软件开发的过程，有方法论（比如敏捷开发），要使用工具，要保证质量，不断迭代，最终交付软件，或者说代码。
简单来说，对翻译提示词「设计」、「测试」、「优化」的整个过程就是提示词工程。
上下文工程 （Context Engineering）
上下文工程是一门设计和构建动态系统的学科，能够在正确的时间，以正确的格式，为大语言模型提供恰当的信息和工具，使其能够完成任务。
上下文工程的特点包括：
它是个系统，而不是一句话： 上下文并不仅仅是一条静态的提示词模板，而是在模型调用之前运行的完整系统的输出。
动态生成： 根据即时任务需求动态生成。例如，某个请求可能需要日历数据，而另一个请求可能需要邮件内容或网络搜索结果。
在恰当的时间提供正确的信息和工具： 它的核心职责是确保模型不会遗漏关键细节（输入错误，输出必然错误）。这意味着只在需要时提供有用的知识（信息）和功能（工具）。
格式的重要性： 信息的呈现方式至关重要。清晰简洁的摘要好于杂乱无序的数据堆砌；明确的工具结构优于模糊的指令。
宝玉老师整理的一张图，非常直观地呈现了这三者之间的关系与区别。
图：提示词、提示词工程与上下文工程的关系
04
为什么「上下文工程」很重要？
构建真正有效的 AI Agent 的秘诀，不是取决于写的代码有多复杂，而是提供给 Agent 的上下文质量。
创建 Agent，真正关键的不是代码或框架，而在于提供的上下文信息质量。举个例子，假设你让 AI 助手基于一封简单的邮件来安排会议：
嘿，想确认一下，你明天方便快速碰一下吗？
一个普通的 Agent 只有糟糕的上下文，它只看到了用户的请求，尽管代码完全正确——调用大语言模型并获得了回应——但输出却呆板无用：
感谢您的信息。明天我可以，请问你想几点碰面？
「神奇的」Agent 则拥有丰富的上下文。它的主要任务并不是决定「怎么」回应，而是去「收集信息」，以让大语言模型顺利实现目标。在调用模型前，你需要扩展上下文，比如包括：
你的日历信息（显示明天已满）。
你和发件人的历史邮件（决定适当的随意语气）。
你的联系人列表（识别对方是关键合作伙伴）。
可用的工具，比如发送邀请或邮件。
然后生成如下回应：
嘿，Jim！明天我的日程已经排满了，一整天都是背靠背的会议。周四上午我有空，不知道你是否方便？我已经发了个邀请，看看是否合适。
这种效果，并不是来自更聪明的模型或更精巧的算法，而是来自提供了适合任务的正确上下文。这正是上下文工程的意义所在。Agent 的失败不再只是模型问题，而是上下文的失败。
05
「上下文工程」的四种落地策略
Langchain 近期发布的一篇博客文章，总结了四种常见的上下文工程策略。
图：上下文工程的一般类别
5.1 写入上下文 （Write Context）
写入上下文，是指将信息保存到上下文窗口之外，以辅助 Agent 完成任务。
草稿板 （Scratchpads）
当人类在解决任务时，会做笔记并为未来相关的任务保留记忆。如今，Agent 也正逐步具备这些能力，通过「草稿板」做笔记，是在 Agent 执行任务期间持久化保留信息的一种方法。核心思想是将信息保存在上下文窗口之外，同时又能让 Agent 随时取用。
Anthropic 的多 Agent 研究员给出了一个清晰的例子：
LeadResearcher 首先会思考整个处理流程，并将计划保存到内存中，以确保上下文的持久化，因为一旦上下文窗口超过 200,000 个 token，内容就会被截断，而保留计划至关重要。
草稿板可以通过几种不同方式实现。它可以是一个仅将内容写入文件的工具调用；也可以是运行时状态对象中的一个字段，保持在整个会话期间保持不变。但无论是采用哪种方式，草稿板都让 Agent 能够保存有用信息，从而更好地完成任务。
记忆 （Memories）
草稿板帮助 Agent 在单次会话（或线程）中解决任务，但有时，Agent 需要跨越多个会话来记忆信息，这会带来更大地助益。Reflexion 引入了在 Agent 每一轮行动后进行反思，并复用这些自我生成记忆的理念。而「生成式 Agent」（Generative Agents）则会从过往的 Agent 反馈集合中，周期性地合成记忆。
图：LLM 可用于更新或创建记忆
这些概念已经被 ChatGPT、Cursor 和 Windsurf 等热门产品所应用，这些产品都拥有能够根据用户与 Agent 的交互，自动生成可跨会话持久化的长期记忆的机制。
5.2 筛选上下文 （Select Context）
筛选上下文，是指将所需信息拉入上下文窗口，来辅助 Agent 完成任务。
草稿板 （Scratchpad）
从草稿板中筛选上下文的机制，取决于草稿板的具体实现方式。如果它是一个工具，那么 Agent 只需通过工具调用便可读取内容。如果它是 Agent 运行时状态的一部分，那么开发者则可以在每一步选择将状态的哪些部分公开给 Agent。这些在为之后地后续回合中向 LLM 提供草稿板上下文提供了精细化的控制。
记忆 （Memories）
如果 Agent 具备保存记忆的能力，它们也需要能够筛选出与当前执行任务相关的记忆。这样做有几个好处：Agent 可以筛选出少样本示例（情景记忆）作为期望行为的范例；可以筛选出指令（程序性记忆）来引导自身行为；或者可以筛选出事实（语义记忆）作为与任务相关的上下文。
图：几种记忆类型
挑战之一是确保筛选出来的记忆是相关的。一些主流的 Agent 仅使用一小部分固定文件，并能将它们拉入到上下文中。例如，许多编码 Agent 使用特定文件来保存指令（「程序性」记忆），或在某些情况下保存示例（「情景」记忆）。Claude Code 使用 CLAUDE.md 文件，Cursor 和 Windsurf 则使用规则文件。
但是，如果 Agent 存储了大量的记忆（例如语义记忆），包括事实或关系，筛选就更难了。ChatGPT 就是一个很好的例子，这款主流产品能够从大量用户专属记忆中进行存储和筛选。
使用嵌入（Embeddings）或知识图谱进行记忆索引，是一种辅助筛选的常用方法。尽管如此，记忆筛选仍然充满挑战。在 AI Engineer World's Fair 大会上，Simon Willison 分享了一个筛选出错的案例：ChatGPT 从记忆中获取了他的位置信息，并意外地将其注入到一张他要求的图片中。这种意料之外或不希望出现的记忆检索，会让一些用户感觉上下文窗口「不再属于他们自己」了！
工具 （Tools）
Agent 需要使用工具，但如果提供的工具过多，可能会不堪重负。通常是因为工具描述之间存在重叠，导致模型在选择使用哪个工具时感到困惑。一种方法是对工具描述采用 RAG 技术，以便只检索与任务最相关的工具。一些近期的论文表明，这种方法可以将工具选择的准确率提升 3 倍。
知识 （Knowledge）
RAG 是一个内容丰富的话题，也可能成为上下文工程中的一个核心挑战。编码 Agent 是在大规模生产环境中应用 RAG 的最佳范例之一。来自 Windsurf 的联创兼 CEO Varun Mohan 很好地概括了其中的一些挑战：
「代码索引 ≠ 上下文检索，我们正在进行索引和嵌入搜索，包括对代码进行 AST 解析，并沿着有语义意义的边界进行分块。随着代码库规模的增长，嵌入搜索作为一种检索启发式方法变得不再可靠，我们必须依赖多种技术的组合，例如 grep/文件搜索、基于知识图谱的检索，以及一个重排序步骤，在此步骤中，上下文会按相关性进行排序。」
5.3 压缩上下文 （Compressing Context）
压缩上下文，指的是仅保留执行任务所必需的 token。
上下文摘要 （Context Summarization）
Agent 的交互可能长达数百轮，并使用消耗大量 token 的工具调用。摘要是应对这些挑战的一种常见方法。如果你用过 Claude Code，应该见过这个功能的实际应用。当上下文窗口超过 95% 时，它会运行「自动压缩」（auto-compact）功能，总结用户与 Agent 交互的整个轨迹。这种贯穿 Agent 执行轨迹的压缩可以采用多种策略，如递归或分层摘要。
图：摘要技术可以应用的几个环节
在 Agent 设计的特定环节加入摘要功能也可能很有用。例如，它可以用于后处理某些工具调用（如消耗大量 token 的搜索工具）。再比如，Cognition 提到在 Agent 之间进行知识传递时进行摘要，来减少 token 的消耗。如果需要精准捕捉特定的事件或决策，摘要可能会成为一项挑战。Cognition 为此使用了一个精调模型，这也突显了这一步可能需要投入的大量工作。
上下文修剪 （Context Trimming）
如果说摘要通常是利用 LLM 来提炼上下文中最相关的部分，那么修剪则通常是过滤或（如 Drew Breunig 所指出的）「裁剪」（prune）上下文。这可以采用硬编码的启发式规则，比如从列表中删除较早的消息。此外，Drew 还提到了一个为问答任务训练的上下文裁剪器「Provence」。
5.1 隔离上下文 （Isolating Context）
隔离上下文，指的是通过拆分上下文来辅助 Agent 完成任务。
多 Agent （Multi-agent）
将上下文分散到不同的子 Agent 中，是隔离上下文最主流的方法之一。OpenAI 的 Swarm 库的动机之一是实现「关注点分离」（separation of concerns），即让一个 Agent 团队处理特定的子任务。每个 Agent 都拥有一套特定的工具、指令和自己的上下文窗口。
图：将上下文分散到多个 Agent 中
Anthropic 的多 Agent 研究员也为此提供了论据：多个拥有独立上下文的 Agent 的表现优于单个 Agent，这很大程度上是因为每个子 Agent 的上下文窗口都可以分配给一个更专注的子任务。正如其博客文章所说：
「 子 Agent 在各自的上下文窗口中并行运作，同时探索问题的不同方面。」
当然，多 Agent 也面临挑战，包括 token 使用量（据 Anthropic 报告，最高可达聊天模式的 15 倍）、需要精心的提示工程来规划子 Agent 的工作，以及子 Agent 之间的协调问题。
利用环境隔离上下文 （Context Isolation with Environments）
HuggingFace 的 Deep Researcher 项目展示了另一个有趣的上下文隔离示例。大多数 Agent 使用工具调用 API，这些 API 返回 JSON 对象（工具参数），参数被传递给工具（如搜索 API）以获取工具反馈（如搜索结果）。而 HuggingFace 使用的是一个 CodeAgent，它会输出包含所需工具调用的代码。然后，这些代码在一个沙盒（sandbox）中运行。从工具调用中筛选出的上下文（如返回值）再被传回给 LLM。
图：沙盒可以将上下文与 LLM 隔离开来
这使得上下文可以在环境中与 LLM 隔离开来。Hugging Face 指出，这是一种隔离消耗大量 token 的对象的好方法：
「代码 Agent 可以更好地处理状态，那如果需要存储这个图像/音频/或其他内容以备后用呢？没问题，只需在你的状态中将其赋值给一个变量，你就可以稍后使用它。」
状态 （State）
值得一提的是，Agent 的运行时状态对象本身也是一种隔离上下文的好方法。这可以起到与沙盒相同的作用。可以为状态对象设计一个包含多个字段的模式（schema），上下文可以写入这些字段中。模式中的一个字段（如消息）可以在 Agent 的每一轮交互中暴露给 LLM，但模式可以将信息隔离在其他字段中，以供更有选择性地使用。
粤ICP备14082021号
免费POC，
零成本试错
