Context Engineering

最后更新：2026-03-05

从 Prompt Engineering 到 Context Engineering

AI Agent 时代的核心工程能力完全指南

2026 年 3 月 | 基于 1400+ 篇论文及行业最新实践 | 零基础友好

一、什么是 Context Engineering（上下文工程）

如果你用过 ChatGPT 或 Claude 这样的 AI 工具，你一定有过这样的体验：同样一个问题，换一种问法，AI 给出的回答质量天差地别。早期大家把"怎么跟 AI 说话"这件事叫做 Prompt Engineering（提示词工程）。而 Context Engineering 是它的进化版本，是一个范围更大、更系统化的工程学科。

💡 一句话理解

Prompt Engineering ≈ "怎么写好一句话让 AI 听懂"

Context Engineering ≈ "怎么设计一整套信息系统，让 AI 在任何时候都能拿到正确的信息、做出正确的决策"

Anthropic（Claude 的开发公司）在 2025 年 9 月发表了一篇重要的工程博客，给出了一个精准的定义：

Context 指的是在大语言模型（LLM）进行推理时，输入给它的全部 token（信息单元）。Context Engineering 的工程目标，是针对 LLM 的固有限制，优化这些 token 的效用，从而稳定地达成期望的输出结果。

翻译成人话就是：LLM 每次生成回答时，能看到的信息量是有限的（就像你的工作台只有那么大）。Context Engineering 就是帮你把这张有限的工作台上，摆满最有用的参考资料，让 AI 交出最好的作业。

1.1 为什么需要从 Prompt 升级到 Context？

2025 年中，Shopify 的 CEO Tobi Lütke 在 X（推特）上发了一条引爆行业的推文，大意是：

"我更喜欢'上下文工程'这个词，而不是'提示词工程'。它更好地描述了核心技能：为 LLM 提供所有必要上下文，使任务有可能被解决的艺术。"

紧接着，前特斯拉 AI 总监 Andrej Karpathy 也公开表态，将 Context Engineering 描述为精心填充 LLM 上下文窗口的实践。2025 年 7 月，Gartner（全球顶级研究机构）更是直接宣布：Context Engineering 取代 Prompt Engineering，成为 AI 领域的优先事项。

这个转变为什么发生？根本原因有三个：

AI 的用途变了： 早期 AI 主要做单轮问答（你问一句，它答一句）。现在 AI Agent（智能体）需要自主执行多步骤任务，比如自动调研、写代码、做交易分析。单纯的 prompt 远远不够。
信息来源变了： AI 不再只依赖自身训练数据，还需要实时调用外部工具（搜索引擎、数据库、API），这些工具返回的信息都要被塞进上下文窗口里管理。
质量要求变了： 从"能用就行"的 Demo 阶段，进入了"必须稳定可靠"的生产阶段。一个提示词在某些情况好用、某些情况不好用的不确定性，是生产系统无法接受的。

1.2 Prompt Engineering vs Context Engineering 对比

维度	Prompt Engineering	Context Engineering
关注范围	单条提示词的措辞和结构	模型看到的全部信息的架构设计
类比	写一封好邮件	设计整个邮件系统 + 知识库 + 工作流
包含要素	系统提示、用户指令、few-shot 示例	提示 + 记忆 + 工具输出 + 检索文档 + 对话历史 + 状态管理
工作方式	手动调优，反复试错	系统化设计，有评估流水线
适用阶段	原型、Demo、一次性任务	生产系统、多轮交互、AI Agent
可扩展性	遇到新场景就要重写提示	架构化设计，自动适配不同用户和任务
关系	是 Context Engineering 的子集	是 Prompt Engineering 的超集

🎯 关键洞察

Prompt Engineering 关注的是你在上下文窗口里「写了什么」；Context Engineering 关注的是你「用什么来填充」整个上下文窗口。两者不矛盾，而是包含关系——就像 UI 设计是 UX 设计的一部分。

二、核心概念：上下文窗口与注意力预算

2.1 上下文窗口（Context Window）——AI 的"工作台"

大语言模型在每次生成回答时，能"看到"的信息总量是有限的，这个上限就叫上下文窗口。你可以把它想象成一张书桌——桌子上能放多少参考资料，就决定了 AI 能参考多少信息来回答你的问题。

上下文窗口的大小以 token 为单位（1 个 token 大约等于 0.75 个英文单词，或约 1.5 个中文字符）。近年来窗口大小经历了爆炸式增长：

早期（2022-2023）：4K–16K token（一篇短文的量）
中期（2024）：128K–200K token（一本小说的量）
现在（2025-2026）：100 万–1000 万 token（几十本书的量）

听起来问题应该解决了？窗口这么大，什么信息都放得下。但现实远非如此——这就引出了一个关键问题。

2.2 Context Rot（上下文腐烂）——信息越多反而越蠢

2025 年 7 月，Chroma 实验室发表了一项里程碑式的研究，测试了 18 个顶级 LLM（包括 GPT-4.1、Claude 4、Gemini 2.5 等），发现了一个反直觉的现象：

⚠️ Context Rot 核心发现

随着输入上下文长度的增加，所有被测试模型的性能都会下降——即使是简单的信息检索任务也不例外。更长的上下文 ≠ 更好的表现。

这就像你的书桌上堆满了几百本参考书，反而找不到你真正需要的那一页。具体来说，Context Rot 有三个核心机制：

机制一：注意力稀释（Attention Dilution）

LLM 基于 Transformer 架构，其中每个 token 都要"注意"其他所有 token。当有 n 个 token 时，就有 n² 对注意力关系需要处理。上下文越长，每个 token 分到的"注意力"就越稀薄，就像一个老师班上有 10 个学生和 1000 个学生时，关注度完全不同。

机制二：位置偏差（Positional Bias）

模型对信息位置非常敏感。斯坦福大学的研究发现了"lost-in-the-middle"（中间丢失）问题：放在输入开头和结尾的信息，AI 能很好地利用；但放在中间的信息，准确率从 70-75% 暴跌到 55-60%。想象你读一本很长的书，最记得住的往往是开头和结尾。

机制三：干扰效应（Distractor Effect）

Chroma 的研究特别指出，当上下文中存在"语义相近但事实无关"的内容时，模型的幻觉（hallucination）率显著上升。比如你让 AI 在代码库里找一个 webhook 处理函数，如果上下文里塞满了测试文件、废弃的旧实现和名字相似的无关函数，AI 反而更容易给出错误答案。

📊 数据说话

Chroma 的实验显示，即使上下文窗口只用了 5% 的容量，性能退化就已经开始了。一个 100 万 token 的窗口，在 5 万 token 时就出现明显的 context rot。研究结论：重要的不是窗口有多大，而是窗口里信息的质量。

这就是为什么 Context Engineering 如此重要——它的核心使命就是对抗 Context Rot，确保模型在每一次推理时都拿到"最小但最精准"的高信号信息集。

三、Context Engineering 的六大支柱

Weaviate（向量数据库公司）在 2025 年 12 月发表了一个被广泛引用的框架，将 Context Engineering 分解为六个相互依赖的组成部分。每个组件控制着"什么信息在什么时候到达模型"。

3.1 指令设计（Instructions / Prompting）

这是最基础的一层，也是 Prompt Engineering 的领地。核心实践包括：

角色指定： 告诉模型它是谁（如"你是一个资深金融分析师"）
输出约束： 规定回答的格式、语气、长度
推理引导： 使用 Chain-of-Thought（思维链）让模型逐步推理
Few-shot 示例： 给出输入-输出的样例，让模型学着做

在 Context Engineering 的框架下，指令设计不再是孤立的，而是要和其他五个组件协同工作。

3.2 检索增强（Context Retrieval / RAG）

RAG（Retrieval-Augmented Generation，检索增强生成）是 Context Engineering 最重要的技术之一。原理很简单：当模型需要回答问题时，先去外部知识库里搜索相关信息，再把搜索结果塞进上下文里。

分块策略（Chunking）： 把长文档切成小段。小块精度高但缺乏语境，大块信息全但向量检索时噪音多——这是经典工程取舍
向量嵌入（Embedding）： 把文本转换成数学向量，用余弦相似度等方法找到最相关的内容
混合检索： 同时使用关键词搜索和语义搜索，取长补短

3.3 工具集成（Tool Integration）

工具让 AI Agent 能"做事"而不只是"说话"。Anthropic 在博客中特别强调了工具设计的重要性：

工具发现： 在系统提示中给 Agent 提供清晰的工具列表和描述，告诉它每个工具什么时候用、怎么用
工具选择和规划： Agent 收到请求后，需要判断是否要用工具、用哪个、按什么顺序
参数构造： Agent 需要从用户的自然语言中提取出工具所需的参数

🔧 MCP——工具集成的统一标准

Model Context Protocol（MCP）由 Anthropic 发起，现已移交 Linux Foundation 管理，成为连接 AI Agent 与企业工具的通用标准。截至 2025 年底，MCP 月 SDK 下载量超过 9700 万次，被 Anthropic、OpenAI、Google、Microsoft 共同采用。可以理解为 AI 世界的"USB 接口"。

3.4 记忆系统（Memory）

无状态的 LLM 不知道 5 分钟前发生了什么。记忆系统让 AI 有了"时间感"，核心分为三层：

短期记忆（Short-term）： 当前对话的上下文窗口内容——最近的对话、推理步骤、工具输出
中期记忆（Working Memory）： 通过摘要、便签本（Scratchpad）保存的跨步骤信息
长期记忆（Long-term）： 持久存储的用户偏好、领域知识、历史决策，需要时按需检索

记忆系统的核心挑战不是"能存多少"，而是"现在应该把什么放到模型面前"。

3.5 查询增强（Query Augmentation）

用户的原始输入往往是模糊的。查询增强是在用户的请求到达模型之前，先对其进行丰富和精炼。例如：

自动补充当前日期和时间（否则模型会猜，导致搜索结果不准）
将模糊查询改写为更精确的搜索关键词
根据用户画像自动注入偏好和背景信息

3.6 Agent 编排（Agent Orchestration）

Agent 既是上下文的设计者，也是上下文的使用者。它动态决定什么时候检索知识、什么时候调用工具、什么时候记录信息。编排层的核心是控制流的设计——决定 Agent 在每一步应该做什么，以及如何处理错误和异常。

四、对抗 Context Rot 的四大核心策略

Anthropic 和 FlowHunt 在各自的技术文档中，总结了生产级 AI 系统中最有效的上下文管理策略。

4.1 上下文压缩（Compaction）

当对话或任务持续时间很长时，上下文窗口会被撑满。Compaction 的思路是：用 LLM 自身来"压缩"历史信息，只保留关键要点。

自动摘要： 定期让模型对前面的对话生成摘要，用摘要替换原始内容
选择性保留： 只保留与当前任务最相关的历史片段
知识交接： Cognition AI 透露他们在 Agent 之间传递知识时，使用微调过的专用摘要模型来压缩信息

4.2 结构化笔记（Structured Note-taking / Scratchpad）

就像人类处理复杂问题时会在纸上记笔记一样，AI Agent 也需要"便签本"来持久化关键信息。这是所有策略中最简单但最强大的一个。

Agent 在执行过程中，将重要发现、中间结论、待办事项写入结构化的笔记区域
这些笔记存储在上下文窗口之外，需要时再取回
核心原则：不要强迫模型记住所有东西，让它把关键信息"写下来"

4.3 上下文修剪（Context Trimming）

与压缩不同，修剪是更"粗暴"但高效的策略：直接用硬编码规则删除不需要的内容。

按时间裁剪：删除较旧的消息
按重要性过滤：标记并保留高优先级信息
使用训练过的修剪器（如 Provence 模型）智能判断哪些该删

🎯 关键洞察

一个聚焦的 300 token 上下文，往往比一个杂乱的 113,000 token 上下文表现更好。你删掉什么，可能跟你保留什么一样重要。

4.4 上下文隔离（Context Isolation / Multi-Agent）

最高级的策略是：不要把所有信息塞进一个模型的窗口里。而是把任务分配给多个专门的 Agent，每个 Agent 在自己独立的上下文窗口中工作，只返回最终结果。

主 Agent 负责任务分解和结果汇总
子 Agent 各自在干净的上下文中执行专项任务
Anthropic 的实践表明，多 Agent 架构将性能提升了 90%

Google 的 ADK（Agent Development Kit）团队将这种思路进一步系统化：将上下文视为一个有自己架构和生命周期的"一等公民"系统。他们提出三个设计原则：

存储与呈现分离： 持久状态（Session）和每次调用的视图（Working Context）是两回事
显式转换： 上下文通过命名的、有序的处理器构建，而不是临时字符串拼接
默认最小化： 每次模型调用只看到完成当前任务所需的最少上下文

五、学术前沿与研究方向

5.1 里程碑论文一览

论文/报告	时间	核心贡献
Chroma "Context Rot"	2025.7	首次系统证明 18 个 LLM 随上下文增长性能退化
ACE Framework (arXiv:2510.04618)	2025.10	提出 Agentic Context Engineering 框架，Agent 自主进化上下文
Context Engineering Survey (arXiv:2507.13334)	2025.7	基于 1400+ 篇论文的系统综述，建立完整分类体系
Anthropic Engineering Blog	2025.9	定义 Context Engineering 为 Prompt Engineering 的自然进化
Google ADK Blog	2025.12	提出上下文即编译器的架构范式

5.2 ACE 框架：让 Agent 自己进化上下文

2025 年 10 月的 ACE（Agentic Context Engineering）论文提出了一个前沿思路：不是人类工程师来设计上下文，而是让 Agent 自己通过"生成→反思→策展"的循环来持续优化自己的上下文。

将上下文视为不断演进的"剧本"（Playbook），通过结构化增量更新来积累策略
解决了两个关键问题：简洁偏差（摘要丢失领域洞察）和上下文坍塌（迭代改写侵蚀细节）
实验结果：Agent 任务提升 10.6%，金融领域提升 8.6%，且不需要标注数据，仅利用执行反馈

5.3 1400+ 论文综述的关键发现

2025 年 7 月的大规模综述论文建立了 Context Engineering 的完整分类体系：

基础组件： 上下文检索与生成、上下文处理、上下文管理
系统实现： RAG 系统、记忆系统与工具推理、多 Agent 系统
核心发现： 当前模型在"理解"复杂上下文方面已经很强，但在"生成"同等复杂的长文本输出方面存在显著短板——这是未来研究的关键方向

六、实操指南：如何落地 Context Engineering

6.1 Agent 开发者清单

检查项	具体操作	常见错误
工具设计	每个工具功能单一、描述清晰、参数明确	工具集膨胀，功能重叠，模型不知道选哪个
上下文预算	监控每次调用的 token 使用量	把所有信息都塞进去，导致 context rot
错误自愈	工具调用失败时，把错误信息回传给模型重试	Agent 遇到错误就卡住或崩溃
渐进式发现	让 Agent 逐层探索信息，而非一次性灌入	预计算所有可能需要的数据
评估流水线	建立 eval pipeline 量化每次改动的效果	凭感觉调试，没有数据支撑

6.2 日常使用者实用技巧

即使你不是开发者，只是日常使用 AI 聊天工具，了解 Context Rot 也能帮你获得更好的体验：

对话变长时主动开新窗口： 研究表明超过 15 轮对话后性能明显下降。切换新话题时，开启新对话
主动提供结构化上下文： 不要说"帮我写个方案"，而是说"我是 XX 角色，目标是 XX，约束是 XX，请输出 XX 格式"
让 AI 先总结再继续： 长对话中，可以让 AI 总结到目前为止的结论，再用总结开启新对话
避免信息灌入： 不要把整个文档复制粘贴进去，只提供最相关的部分

6.3 技术栈与工具链

2026 年的 Context Engineering 生态已经相当成熟：

编排框架： LangChain/LangGraph（Python）、AutoGen（Microsoft）、CrewAI（多 Agent）
数据索引： LlamaIndex（文档结构化和分层索引）
向量数据库： Weaviate、Chroma、Pinecone（存储和检索向量化的知识）
工具协议： MCP（模型上下文协议）—— 连接 Agent 与外部工具的标准
知识图谱： Neo4j（将领域知识建模为图结构，提供结构化上下文）
缓存方案： Redis LangCache（语义缓存，避免重复 API 调用）

七、未来展望与行业趋势

7.1 Context Engineering 的三个发展方向

自适应上下文： 从人工设计上下文到 Agent 自主进化上下文（如 ACE 框架），减少人工干预
上下文即基础设施： Google ADK 的思路——将上下文管理视为独立的系统工程，有自己的存储、转换和观测层
跨模态上下文： 不仅管理文本，还要管理图像、音频、视频等多模态信息的上下文

7.2 对从业者的意义

对于 AI 产品和 Agent 的构建者来说，Context Engineering 正在成为核心竞争力：

它是"模型能力"和"产品质量"之间的桥梁——同样的模型，上下文工程做得好与不好，效果天差地别
它是可复用的技能——不会因为模型更新换代而过时，因为所有模型都需要好的上下文
它跨越"能用"和"好用"的鸿沟——Cognition AI 观察到，Context Engineering 已经成为构建 AI Agent 工程师的首要职责

八、一页总结

📝 Context Engineering 核心要点速查

定义： 为 LLM 设计和管理最优信息输入的系统工程学科

与 Prompt Engineering 的关系： 超集，不是替代

为什么重要： Context Rot——更多信息 ≠ 更好表现

六大支柱： 指令设计、检索增强、工具集成、记忆系统、查询增强、Agent 编排

四大策略： 压缩、笔记、修剪、隔离

核心原则： 找到最小的、高信号的 token 集合，最大化模型表现

未来方向： 自适应、基础设施化、跨模态

参考来源

Anthropic, "Effective context engineering for AI agents", 2025.9
Chroma, "Context Rot: How Increasing Input Tokens Impacts LLM Performance", 2025.7
Zhang et al., "Agentic Context Engineering (ACE)", arXiv:2510.04618, 2025.10
Mei et al., "A Survey of Context Engineering for LLMs", arXiv:2507.13334, 2025.7
Google Developers Blog, "Architecting efficient context-aware multi-agent framework", 2025.12
Weaviate, "Context Engineering - LLM Memory and Retrieval for AI Agents", 2025.12
Gartner, "Context engineering is in, prompt engineering is out", 2025.7
FlowHunt, "Context Engineering: The Definitive 2025 Guide"
Prompt Engineering Guide, "Context Engineering Guide"
IntuitionLabs, "What Is Context Engineering?", Updated 2026