我要投稿

Karpathy：我不是要造新词，是「上下文工程」对 Agent 来说太重要了

发布日期：2025-07-04 21:23:22 浏览次数： 1529

作者：Founder Park

微信搜一搜，关注“Founder Park”

Andrej Karpathy 又带火了一个词——Context Engineering。

Shopify CEO Tobi Lütke 的一条推特引发了行业对此的广泛讨论，Andrej Karpathy 转发并表示强烈认同。

这不是一个新概念，只是业内共识的逐渐形成：决定 AI 应用效果的关键，已经不是你怎么问，而是你给 AI 喂了什么料。

提供完整且恰当的上下文往往比编写好的提示词更重要。

到底什么是「上下文工程」，在应用的落地开发中怎么更好使用「上下文工程」？我们整理了 DeepMind 工程师 Philipp Schmi、以及 LangChain 对此的讨论，希望在一篇文章里介绍清楚「上下文工程」的概念以及实操落地的问题。

超 8000 人的「AI 产品市集」社群！不错过每一款有价值的 AI 应用。

邀请从业者、开发人员和创业者，飞书扫码加群：

进群后，你有机会得到：

最新、最值得关注的 AI 新品资讯；
不定期赠送热门新品的邀请码、会员码；
最精准的AI产品曝光渠道

01 Karpathy：

「上下文工程」既是科学也是艺术

图：Andrej Karpathy 推特内容

支持「上下文工程」而不是「提示工程」。

人们通常将提示词（prompt）与日常使用中给 LLM 的简短任务描述联系起来。但在每个工业级 LLM 应用中，上下文工程（Context Engineering）是一门精妙的艺术与科学——它需要精准地为上下文窗口填充恰到好处的信息。

说它是科学，因为这项工作涉及任务描述与解释、少量示例、检索增强生成（RAG）、相关（可能是多模态的）数据、工具、状态与历史记录、信息压缩...提供太少或形式不当，LLM 就缺乏最优表现所需的上下文；过量或相关性不足，则会导致成本上升性能下降。做好这件事绝非易事。

而称之为艺术，则源于对人类心理与 LLM 行为之间微妙互动的直觉把握。

除了上下文工程本身，一个 LLM 应用还必须能够实现：

将问题恰到好处地分解为（control flows）；
恰到好处地填充上下文窗口
调度类型和能力都合适的 LLMs
处理「生成-验证」的用户交互（UI/UX）流程；
还有很多方面 - 安全护栏、防护措施、评估机制、并行处理、数据预取......

因此，上下文工程只是新兴复杂软件层中的一小部分，这些软件将单个 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，但模式可以将信息隔离在其他字段中，以供更有选择性地使用。

参考来源：

https://x.com/karpathy/status/1937902205765607626

https://www.philschmid.de/context-engineering

https://blog.langchain.com/context-engineering-for-agents/