Karpathy：上下文工程对Agent至关重要，非造新词_AI热点日报

AndrejKarpathy强调上下文工程超越提示词工程，成为工业级LLM应用的核心竞争力。上下文工程动态构建系统，精准填充指令、对话历史、检索信息、工具等上下文。实际落地包括写入、筛选、压缩、隔离上下文四种策略。

上下文工程：从提示词到工业级 LLM 应用的核心竞争力

Andrej Karpathy 揭示 AI 应用新关键：上下文工程如何超越提示词，成为工业级 LLM 的核心竞争力。本教程将带你系统理解上下文工程的概念、与提示词工程的本质区别、重要性以及四种主流落地策略，帮助你在实际开发中构建更智能的 AI 应用。

一、Karpathy 眼中的上下文工程：既是科学也是艺术

Andrej Karpathy 在推特上表示支持“上下文工程”而不是“提示工程”。他明确指出：

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

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

艺术的一面：源于对人类心理与 LLM 行为之间微妙互动的直觉把握。

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

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

因此，上下文工程只是新兴复杂软件层中的一小部分，这些软件将单个 LLM 调用（以及更多内容）协调成完整的 LLM 应用。“ChatGPT 包装器”这个说法已经过时，而且大错特错。

二、什么是上下文工程？

要理解上下文工程，我们首先得拓宽对“上下文”的定义。它不仅仅是发给大语言模型的一句提示词，而是模型生成回答之前所看到的一切信息。

上下文工程包括以下核心要素：

指令 / 系统提示词：定义模型整体行为的初始指令，可以（也应该）包含示例、规则等。
用户提示词：用户提出的即时任务或问题。
当前状态或对话历史（短期记忆）：用户和模型此前的对话内容，展现当前交流的背景。
长期记忆：跨多次对话积累的持久性知识库，比如用户喜好、历史项目摘要、记住的特定事实。
检索的信息（RAG）：外部的、最新的信息，包括从文档、数据库或 API 获取的相关内容，用于回答特定问题。
可用工具：模型可以调用的所有函数或内置工具定义（如检查库存、发送邮件等）。
结构化输出：明确定义模型输出的格式，例如 JSON 格式的对象。

小提示：在实际开发中，建议先将所有可能需要的上下文来源列成清单，再根据任务需求动态筛选，避免一次性塞入过多无用信息。

三、提示词工程 vs 上下文工程：到底啥区别？

很多开发者容易混淆这几个概念，我们来逐一对比：

提示词（Prompt）
用户给 AI 模型的输入文本，直接向模型输入的问题或指令。比如让 ChatGPT 总结一段文本、调用模型 API 传入提示词去翻译一篇文章。简单理解，提示词是一段文本，有点像代码。
提示词工程（Prompt Engineering）
系统化地设计、测试、优化提示词的过程。就像软件工程，为了完成某个需求，要有一套科学的方法来帮助完成软件开发的过程，有方法论（比如敏捷开发），要使用工具，要保证质量，不断迭代，最终交付软件或代码。对翻译提示词“设计”、“测试”、“优化”的整个过程就是提示词工程。
上下文工程（Context Engineering）
一门设计和构建动态系统的学科，能够在正确的时间，以正确的格式，为大语言模型提供恰当的信息和工具，使其能够完成任务。上下文工程是一个系统，而不是一句话；它动态生成上下文；在恰当的时间提供正确的信息和工具；并且非常重视信息的呈现格式。

关键关系：提示词是上下文工程中的一小部分，提示词工程是优化提示词的方法，而上下文工程是构建整个动态上下文系统的工程实践。

四、为什么上下文工程很重要？

构建真正有效的 AI Agent 的秘诀，不是取决于写的代码有多复杂，而是提供给 Agent 的上下文质量。

举一个直观的例子：假设你让 AI 助手基于一封简单的邮件来安排会议：

嘿，想确认一下，你明天方便快速碰一下吗？

一个普通的 Agent 只有糟糕的上下文，它只看到了用户的请求，尽管代码完全正确——调用大语言模型并获得了回应——但输出却呆板无用：

感谢您的信息。明天我可以，请问你想几点碰面？

“神奇的”Agent 则拥有丰富的上下文。它的主要任务并不是决定“怎么”回应，而是去“收集信息”，以让大语言模型顺利实现目标。在调用模型前，你需要扩展上下文，比如包括：

你的日历信息（显示明天已满）。
你和发件人的历史邮件（决定适当的随意语气）。
你的联系人列表（识别对方是关键合作伙伴）。
可用的工具，比如发送邀请或邮件。

然后生成如下回应：

嘿，Jim！明天我的日程已经排满了，一整天都是背靠背的会议。周四上午我有空，不知道你是否方便？我已经发了个邀请，看看是否合适。

这种效果，并不是来自更聪明的模型或更精巧的算法，而是来自提供了适合任务的正确上下文。这正是上下文工程的意义所在。Agent 的失败不再只是模型问题，而是上下文的失败。

五、上下文工程的四种落地策略

Langchain 近期发布的一篇博客文章，总结了四种常见的上下文工程策略。

5.1 写入上下文（Write Context）

写入上下文，是指将信息保存到上下文窗口之外，以辅助 Agent 完成任务。

草稿板（Scratchpads）
当人类在解决任务时，会做笔记并为未来相关的任务保留记忆。如今，Agent 也正逐步具备这些能力，通过“草稿板”做笔记，是在 Agent 执行任务期间持久化保留信息的一种方法。核心思想是将信息保存在上下文窗口之外，同时又能让 Agent 随时取用。
Anthropic 的多 Agent 研究员给出了一个清晰的例子：
LeadResearcher 首先会思考整个处理流程，并将计划保存到内存中，以确保上下文的持久化，因为一旦上下文窗口超过 200,000 个 token，内容就会被截断，而保留计划至关重要。
草稿板可以通过几种不同方式实现。它可以是一个仅将内容写入文件的工具调用；也可以是运行时状态对象中的一个字段，保持在整个会话期间保持不变。
记忆（Memories）
草稿板帮助 Agent 在单次会话（或线程）中解决任务，但有时，Agent 需要跨越多个会话来记忆信息，这会带来更大地助益。Reflexion 引入了在 Agent 每一轮行动后进行反思，并复用这些自我生成记忆的理念。而“生成式 Agent”（Generative Agents）则会从过往的 Agent 反馈集合中，周期性地合成记忆。
这些概念已经被 ChatGPT、Cursor 和 Windsurf 等热门产品所应用，这些产品都拥有能够根据用户与 Agent 的交互，自动生成可跨会话持久化的长期记忆的机制。

5.2 筛选上下文（Select Context）

筛选上下文，是指将所需信息拉入上下文窗口，来辅助 Agent 完成任务。

从草稿板筛选
取决于草稿板的具体实现方式。如果它是一个工具，Agent 只需通过工具调用便可读取内容。如果它是 Agent 运行时状态的一部分，开发者则可以在每一步选择将状态的哪些部分公开给 Agent。这些为后续回合中向 LLM 提供草稿板上下文提供了精细化的控制。
从记忆中筛选
如果 Agent 具备保存记忆的能力，它们也需要能够筛选出与当前执行任务相关的记忆。这样做有几个好处：Agent 可以筛选出少样本示例（情景记忆）作为期望行为的范例；可以筛选出指令（程序性记忆）来引导自身行为；或者可以筛选出事实（语义记忆）作为与任务相关的上下文。
挑战之一是确保筛选出来的记忆是相关的。一些主流的 Agent 仅使用一小部分固定文件，并能将它们拉入到上下文中。例如，许多编码 Agent 使用特定文件来保存指令（“程序性”记忆），或在某些情况下保存示例（“情景”记忆）。Claude Code 使用 CLAUDE.md 文件，Cursor 和 Windsurf 则使用规则文件。
但是，如果 Agent 存储了大量的记忆（例如语义记忆），包括事实或关系，筛选就更难了。ChatGPT 就是一个很好的例子，这款主流产品能够从大量用户专属记忆中进行存储和筛选。
使用嵌入（Embeddings）或知识图谱进行记忆索引，是一种辅助筛选的常用方法。尽管如此，记忆筛选仍然充满挑战。在 AI Engineer World's Fair 大会上，Simon Willison 分享了一个筛选出错的案例：ChatGPT 从记忆中获取了他的位置信息，并意外地将其注入到一张他要求的图片中。这种意料之外或不希望出现的记忆检索，会让一些用户感觉上下文窗口“不再属于他们自己”了！
从工具中筛选
Agent 需要使用工具，但如果提供的工具过多，可能会不堪重负。通常是因为工具描述之间存在重叠，导致模型在选择使用哪个工具时感到困惑。一种方法是对工具描述采用 RAG 技术，以便只检索与任务最相关的工具。一些近期的论文表明，这种方法可以将工具选择的准确率提升 3 倍。
从知识中筛选
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.4 隔离上下文（Isolating Context）

隔离上下文，指的是通过拆分上下文来辅助 Agent 完成任务。

多 Agent（Multi-agent）
将上下文分散到不同的子 Agent 中，是隔离上下文最主流的方法之一。OpenAI 的 Swarm 库的动机之一是实现“关注点分离”（separation of concerns），即让一个 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 隔离开来。Hugging Face 指出，这是一种隔离消耗大量 token 的对象的好方法：
“代码 Agent 可以更好地处理状态，那如果需要存储这个图像/音频/或其他内容以备后用呢？没问题，只需在你的状态中将其赋值给一个变量，你就可以稍后使用它。”
状态（State）
值得一提的是，Agent 的运行时状态对象本身也是一种隔离上下文的好方法。这可以起到与沙盒相同的作用。可以为状态对象设计一个包含多个字段的模式（schema），上下文可以写入这些字段中。模式中的一个字段（如消息）可以在 Agent 的每一轮交互中暴露给 LLM，但模式可以将信息隔离在其他字段中，以供更有选择性地使用。

常见问题（FAQ）

Q1: 上下文工程和提示词工程有什么区别？

提示词工程专注于优化单条或少数几条提示词本身（如何设计措辞、示例等），而上下文工程是一个更宏观的系统工程，它关注如何动态构建整个上下文环境——包括系统提示、用户输入、对话历史、检索信息、工具定义、记忆等。提示词工程是上下文工程的一个子集。

Q2: 上下文工程中，如何避免信息过载？

核心方法是采用筛选策略：仅拉入当前任务最相关的信息。可以使用 RAG 检索关键词、利用嵌入进行记忆筛选、对工具描述进行检索、或者通过多 Agent 将上下文分散给不同的子 Agent。同时，还可以使用摘要或修剪压缩冗余 token。

Q3: 小团队的 Agent 项目应该从哪个策略入手？

建议从“写入上下文”开始：为 Agent 添加草稿板（如简单的文件或状态字段）和基本的记忆机制（如存储用户偏好）。这是最容易实现且效果明显的一步。然后逐步加入“筛选上下文”（如基于嵌入的记忆检索）和“压缩上下文”（如对长对话进行摘要）。

Q4: 上下文工程是否适用于非 Agent 场景？

当然。任何使用大语言模型的应用都可以受益于上下文工程。例如，一个简单的问答系统可以通过 RAG 动态注入相关知识，比静态提示词效果更好。一个代码补全工具可以基于当前文件内容和项目上下文生成更准确的建议。

总结

上下文工程是构建工业级 LLM 应用的核心能力，它让我们从“如何提问”进化到“如何构建系统级上下文”。通过恰当的信息写入、筛选、压缩和隔离，我们可以让 AI 应用在正确的时间获得正确的信息，从而输出更智能、更准确的结果。开始实践上下文工程，你的 AI 应用将不再是“ChatGPT 包装器”，而是真正具备竞争力的智能系统。