上下文工程（Context Engineering）：构建Agent的核心技能

想象一下，你让你的 AI 差旅助手“小智”去“预订下个月去朝阳开会的酒店”。

几秒钟后，它回复：“搞定！我为您预订了汉庭酒店，位于辽宁省朝阳市。”

你很生气，但转念一想，这可能是你的错。你没有说清楚是“北京市朝阳区”。这是提示工程（Prompt Engineering）的失败。

于是你吸取教训，发出了更明确的指令：“在北京市朝阳区，帮我订三里屯附近的酒店，预算1000 一晚。“小智迅速完成了预订。然而，当你提交报销时，却被财务拒绝了，因为这远远超过了你公司 500 元/晚的差旅标准。

这一次，你很难再责怪自己。

一个真正智能的助手，难道不应该被“工程化”地接入你的日历（工具）以自动知晓会议地点，并主动查询公司的差旅政策（RAG）来提醒你预算超标吗？

这个case，正是“提示工程”的上限和“上下文工程”（Context Engineering）的起点。

一场已经发生的认知革命：从“提示”到“上下文”

过去两年，我们都痴迷于“提示工程”——试图找到那句能让 AI 产生惊艳结果的“魔法咒语”。但 AI 领域的顶尖实践者们，已经开始转向一个更宏大、更系统的领域。

”Context Engineering“的概念源于几个大神在社交网络 X 中的讨论。

Shopify 的 CEO Tobi Lütke 在 2025年6月19号 首先提出了”Context Engineering“：

我真的更喜欢”上下文工程“这个词，而不是”提示工程“。它更好地描述了核心技能：提供任务所需的所有上下文，使其能被 LLM 合理地解决。

这个观点迅速得到了 Andrej Karpathy 的响应，他将其拔高到了“工业级应用”的层面：

为”上下文工程“点赞。……在每一个工业级的 LLM 应用中，上下文工程都是一门精细的艺术和科学，它要做的就是在下一步中用恰到好处的信息填满上下文窗口。

最后，BloomTech 的 CEO Austen Allred 发表了极具冲击力的总结：

上下文工程比提示工程强 10 倍。

为什么他们都在强调要从”提示工程“向”上下文工程“转变？因为我们构建 AI 的方式已经发生了根本变化。

到底什么是上下文工程？

如果说“提示工程”关心的是“你问什么”，那么“上下文工程”关心的就是“你如何准备模型来回答”。

它不再是关于设计单个指令文本，而是演变为一门系统级的学科：在 AI Agent 执行任务的每一步，动态地、程序化地组装和优化 LLM 在推理时看到的所有信息。

一个简单的公式可以概括：

上下文工程 = 提示工程 + （RAG + 工具 + 内存 + 任务状态 + …）

Andrej Karpathy 有一个最棒的比喻：LLM 是 CPU，上下文窗口就是它的 RAM。

“提示工程”就像是在 RAM 里写一个简单的脚本。而“上下文工程”则是构建一个完整的操作系统，它需要决定在每一纳秒，哪些数据应该被加载进 RAM，哪些应该被清除，哪些应该被压缩后存入硬盘。

IBM 表示一个 AI Agent 最终在运行时看到的“总提示词”，可能只有 20% 是你写的静态指令，而 80% 是由上下文工程动态组装的内容（如 RAG 的检索结果、内存中的事实、工具的 API 响应等）。

一个设计精良的上下文“信息有效载荷”（information payload），通常由以下组件构成：

• 指令提示词（Instruction Prompt）：系统提示词，用于设定 AI 的角色、规则和必须遵循的原则和工作流程。
• 知识（Knowledge）：通过 RAG（Retrieval-Augmented Generation，检索增强生成）、GraphRAG（Graph Retrieval-Augmented Generation，图谱检索增强生成） 或 API 检索到的内/外部数据。
• 内存 （Memory）：短期（对话历史）和长期（跨会话的用户偏好等）。
• 工具（Tools）：工具的 API 规范（告知 AI 它能做什么）和工具的响应（告知 AI 它刚做了什么，得到了什么结果）。
• 状态（State）：一个“暂存器”（Scratchpad），用于跟踪多步骤任务的进展。
• 输出结构（Output Structure）：强制模型按特定 JSON 或 XML Schema 输出的指令，以便下游系统解析。

核心挑战：“天真 RAG” 与 “上下文腐烂”

在深入实践之前，我们必须理解上下文工程要解决的核心问题。

首先，我们必须弄清一个概念：“天真 RAG”（Naive RAG）。

“天真 RAG” 是我们最早接触 RAG 时的做法：1. 将一堆 PDF 文档无脑切成小块（Chunking）；2. 将这些碎块全部“向量化”（Embedding）后塞进向量数据库；3. 当用户提问时，捞出最相似的 5 到 10 个碎块（原理：将问题Embedding，然后在向量数据库中计算”问题向量“和”知识向量“的”余弦相似度“，越相似则向量间的夹角越小），然后把它们和问题一起塞给 LLM。

你可能会想：现在上下文窗口越来越大，从 128K 到 1M Token，我把所有资料都塞进去不就行了？

这是一个致命的误解。这里边存在一个核心悖论：

• “上下文腐烂”（Context Rot）：Anthropic 的“大海捞针”测试和 Chroma 的研究都表明，上下文窗口是一种有限的“注意力预算” （Attention Budget）。当上下文中的信息（Token）过多时，模型准确回忆和利用信息的能力反而会急剧下降。
• 上下文“失败模式”：简单地塞满上下文，会导致：
  • 上下文中毒（Context Poisoning）：不相关或错误的信息会“污染”模型的推理。
  • 上下文混淆（Context Confusion）：过量（即使相关）的信息也会“淹没”模型，使其分心。

因此，上下文工程的真正目标，是追求 Anthropic 所提出的的：“最小可行的高信号 Token 集” （smallest possible set of high-signal tokens）。我们不再是“信息填充者”，而是“信息规划者”。

工程应用的四大核心策略

那么，我们具体该如何“工程化”这个 ”RAM“ ？

1. 写入（Write）/ 代理式内存（Agentic Memory）

• 是什么：允许 Agent “记笔记”。将关键事实、中间结论或用户偏好，写入到上下文窗口之外的持久化存储中（例如一个 NOTES.md 文件或专用的内存工具）。
• 举例：Anthropic 曾展示 Claude 玩《宝可梦》。它会在游戏过程中不断地“记笔记”，比如“我正在1号公路训练皮卡丘，目标10级，已完成8级”。当上下文窗口重置后，它会“读回笔记”，从而实现跨越数小时的长周期任务。

2. 压缩（Compress）/ 精炼

• 是什么：当上下文接近极限时，主动进行“有损压缩”。Anthropic 将之称为 “Compaction”。
• 举例：最简单却高效的技巧是”工具结果清理”（Tool result clearing）。假设 AI 调用了一个 API 来查询订单，该 API 返回了一个包含 1000 个 Token 的巨大 JSON。在“压缩”策略下，AI 在确认信息后，会丢弃这个 JSON，只在上下文中保留一句“状态：订单 8975 已确认”，从而释放 990+ 个宝贵的 Token 空间。

3. 隔离（Isolate）/ 分治

• 是什么：通过“子代理架构”（Sub-agent Architectures）将复杂任务分解。
• 举例：来自 Human Layer 团队的实践：一个“主代理”需要在一个复杂代码库中查找功能 。它启动一个“搜索子代理”。这个子代理可以在自己的上下文窗口中“消耗”50,000 个 Token（读取文件、grep、分析依赖），这个过程是“脏”和“高噪音”的。但它最终只向主代理返回一个 50 Token 的摘要：“功能 X 位于 utils/auth.py 第 42 行”。主代理的上下文因此保持了“干净”和“高信号”。

4. 选择（Select）/ RAG升级

• 是什么：这是 RAG 的进化版。代理在需要时，主动“选择”要拉取什么信息放入上下文。
• 举例：这不再是“天真 RAG”。一个成熟的代理会混合使用多种工具来实现“即时上下文” (Just-in-Time Context) ：
  • 任务：总结一下‘XX项目’的风险。
  • 选择1（GraphRAG）：查询知识图谱获取结构化关系：谁是项目经理？依赖哪些项目？
  • 选择2（API工具）：调用 Jira API 获取实时数据：有哪些未解决的 P0 Bug？
  • 选择3（文件工具）：grep 代码库查找关键实现：//TODO: HACK
  • 选择4（向量检索）：最后才使用向量检索：“找找看还有哪些文档和风险相关。

上下文工程的三层架构

理论很清晰，但在一个复杂系统中，尤其是企业应用，如何将这些策略落地？答案是构建一个分层的架构，实现可治理、可扩展的 AI Agent。

L1：数据与知识层（The Source Layer）

这是所有信息的源头，也是上下文工程的“弹药库”。

• 作用：存储企业的所有知识，包括结构化数据（数据库）、半结构化数据（JSON、API）和非结构化数据（PDF、文档）。
• 如何构建：
  • 向量数据库（Vector DBs）：这是“天真 RAG”的基础。通过“Chunking-Embedding”的方式处理非结构化文档。
  • 知识图谱（Knowledge Graph – KG）：这是 RAG 的进化，即 GraphRAG。知识图谱不再存储“扁平的文本块”，而是存储实体（Entities）和关系（Relationships）。
• 举例：
  • 天真 RAG：你问“‘XX项目’的负责人是谁？”，它从 PDF 中检索出 10 个包含“XX项目”和“负责人”的段落，答案可能就藏在其中。
  • GraphRAG：你问同样的问题，它直接从 KG 中返回一个精确的事实：{实体: “张三”} -[关系: LEADS]-> {实体: “XX项目”} 。这极大提升了检索的准确性和可解释性。

一张表看懂 天真 RAG 和 GraphRAG ：

对比维度	Naive RAG（天真 RAG）	GraphRAG（知识图谱 RAG）
定义	一种通过检索“相似文本块”来增强 LLM 上下文的技术。	一种通过检索“结构化事实”来增强 LLM 上下文的先进技术。
核心思想	查找相似性：假设与问题语义相似的文本块包含答案。	推理关联性：假设答案隐藏在数据间的结构化联系中。
知识准备（Indexing）	1. 分块（Chunking）：将文档切割成独立的文本块。 2. 嵌入（Embedding）：将每个文本块“翻译”成向量。 3. 存储：存入向量数据库（Vector DB）。	1. 提取（Extraction）：从所有数据中提取“实体”和“关系”。 2. 构建（Construction）：将实体和关系连接成一个图谱。 3. 存储：存入图数据库（Graph DB）。
知识检索（Retrieval）	1. 查询嵌入：将用户问题“翻译”成一个查询向量。 2. 向量搜索：使用余弦相似度（Cosine Similarity）在数据库中查找“夹角”最小的 K 个向量。 3. 返回：返回 K 个原始文本块（Top-K Chunks）。	1. 查询解析：将用户问题“翻译”成一个图查询语句 (如 Cypher，由 Neo4j 公司开发的目前最主流的图查询语言)。 2. 图谱遍历：在图谱中定位节点并沿着“关系”边进行遍历。 3. 返回：返回一个精确的子图谱（Subgraph）或事实。
数据结构	扁平的、非结构化的、互相隔离的文本块。	结构化的、互相连接的“实体”（Nodes）与“关系”（Edges）。
核心能力	语义搜索（Semantic Search）	多跳推理（Multi-hop Reasoning）
答案质量	基于零散文本块的“总结”或“猜测”，可能存在噪音或矛盾。	基于结构化事实的“精确回答”，逻辑清晰，噪音低。
可解释性	较低。（“答案可能来自这 5 个段落，但不知如何组合。”）	极高。（“答案遵循了 A -> B -> C 的精确推理路径。”）
典型用例	简单的文档问答、客服机器人、文章摘要。	复杂的企业知识推理、金融反欺诈、科研、供应链分析。
举例	提问：“XX项目”的负责人是谁？ 结果：返回 5 个同时包含“飞龙项目”和“负责人”的文本段落。	提问：“XX项目“的负责人是谁？ 结果：返回一个精确的事实： {XX项目} – [负责人是] -> {张三}

L2：语义层（The Semantic Layer）

这是最关键、也最容易被忽视的一层。它是数据和 AI 之间的“翻译官”和“治理者”。

• 作用：它是一个集中的“元数据中心”，用于标准化数据定义和治理策略。
• 为什么至关重要：它解决了“巴别塔”问题（由圣经《创世纪》中“巴别塔”故事所引发的象征性困境，具体来说就是由于语言不通造成的沟通障碍和合作失败）。
• 举例：
  • 情景1：没有 L2（AI 瞎猜）：
    • 用户提问：上季度我们的“活跃用户”有多少？
      AI 的困境： AI 在数据层（L1）发现两个冲突的定义：
      销售库（L1）：active_users = 30天内付费的用户。
      产品库（L1）：dau = 24小时内登录的用户。
      结果： AI 彻底懵了，只能瞎猜一个（比如它猜了“登录”用户），导致给出了一个完全错误的答案。
  • 情景2：有了 L2（AI 查字典）：
    • L2 是一个由人类专家预先定义好的“权威业务词典”。AI 不再需要猜测。
      在这个“词典”里，人类已经写明了一条“唯一事实”：
      “活跃用户”（业务术语）= 30天内付费的用户（业务定义） = [执行这条 SQL 查询 sales_db]
      现在 AI 的工作流被彻底改变了：
      AI 先向 L2 提问：“活跃用户”的定义是什么？
      L2 响应：这是“活跃用户”的唯一定义，以及它的 SQL 查询语句。
      AI 执行 L1： AI 拿着 L2 给的“标准答案”SQL，去 L1 的 sales_db 中执行，得到 100% 准确的结果。
• 总结： L2 语义层不存数据，只存“定义”和“权威指令”。它确保了 Agent 在面对复杂业务时，其行为 100% 可控、可预测，并始终与人类专家的业务口径保持一致。

L3：代理与编排层（The Agentic Layer）

这是上下文工程的“指挥中心”和“CPU”。

• 作用：这是 Agent 本身所在的地方。它负责接收用户目标，并执行上文提到的“四大策略”（写入、压缩、隔离、选择）。
• 如何构建：使用 LangChain 的 LangGraph、LlamaIndex 的 Workflows 、 Anthropic 提出的“规范驱动工作流”或自行开发来编排 Agent 的行为。
• 举例（三层联动）：
  1. 目标：用户要求“总结一下‘XX项目’的风险”。
  2. 查询 L2（语义层）：Agent 首先访问 L2，查询“XX项目”和“风险”的定义。L2 告诉它：“相关数据在知识图谱A（查状态）和 Jira API B（查Bugs）”。
  3. 选择（L3）：Agent 选择并调用 GraphRAG 工具和 Jira 工具。
  4. 检索（L1）：它从 L1 的知识图谱中拉取‘XX项目’的状态，并调用 Jira API 获取最新的 Bug 报告。
  5. 写入/压缩（L3）：它得到了两个巨大的 JSON 响应。它使用“Write”策略将它们放入“暂存器”，并使用“Compress”策略将其总结为几个关键风险点。
  6. 响应：最后，它基于这些精炼过的“高信号”上下文，生成一份准确的总结报告。

总结

从“提示工程”到“上下文工程”的转变，标志着我们从“与 AI 聊天的人”进化为“AI 系统架构师”。

提示工程给你带来更好的问题，上下文工程给你带来更好的系统。

AI 应用开发不再是比拼谁的提示词写得更巧妙，而是比拼谁能构建出更高效、更可靠的上下文供给系统。这不再是一个“提示”问题，这是一个“架构”问题，例如构建一个三层架构，利用知识图谱提供结构化知识，利用语义层实现治理和统一理解等。

学习资料推荐：

• Anthropic 对上下文工程的解析（权威文章）：原文链接
• LangChain 以开发者视角对上下文工程做了战术解析（干货）：原文链接
• LlamaIndex 从数据框架和 RAG 角度探讨了上下文工程：原文链接
• Analytics Vidhya 拆解了上下文工程的常用组件和实践指南：原文链接
• Human Layer 创始人 Dex，从一个资深 AI 工程师和 YC 创始人的视角，介绍了上下文工程实战经验：视频链接
• 浅显易懂地了解什么是上下文工程的视频：视频链接
• 一篇全面、深度的上下文工程论文：原文链接
• 侧重介绍了 RAG 的进阶，GraphRAG：原文链接