第1章：什么是上下文工程？
介绍了上下文工程由6个核心组件组成,每个组件解决LLM应用中的特定挑战,这是序章。
- 2. Query Augmentation - 查询增强
- 4. Prompting Techniques - 提示技巧
我们接着这个开一个系列:
本章节学习目标：
- 理解从 Prompt Engineering 到 Context Engineering 的演进
- 建立"正确信息 + 正确工具 + 正确时机 + 正确格式 = 有效Agent"的核心公式
1.1 上下文工程的定义与边界
1.1.1 从"提示工程"到"上下文工程"的演进
在经历了数年提示工程（Prompt Engineering）作为应用型AI焦点之后，一个新的术语正在走到台前：上下文工程（Context Engineering）。这不仅仅是名称的改变，而是反映了我们对AI系统构建方式的根本性转变。
提示工程的局限
"提示工程"这个术语在AI社区之外常被误解为"只是在聊天机器人中输入精巧的请求"。虽然提示工程教会了我们如何"用散文编程"，用巧妙的一句话获得更好的输出，但随着应用复杂度的增长，仅仅关注单个提示的局限性变得越来越明显。
正如业界的一句戏言所说：_"提示工程走路，是为了让上下文工程能跑起来。"_ 一个精妙的一次性提示或许能在演示中让人眼前一亮，但要构建可靠的、工业级的LLM系统，我们需要更全面的方法。
上下文工程的兴起
这种认知转变促使业界开始围绕**"上下文工程"**这个术语形成共识，将其作为更好描述从AI获得优秀结果的技艺。这一转变得到了行业领袖的推动，Shopify的CEO Tobi Lütke和AI领军人物Andrej Karpathy在2025年中期普及了这个概念。
"相比'提示工程'，我更喜欢'上下文工程'这个术语，" Tobi写道。_"它更好地描述了核心技能：为任务提供所有必要上下文，使LLM能够合理解决问题的艺术。"_
Karpathy强烈赞同，指出_人们往往将提示与简短指令联系起来，而在每个严肃的LLM应用中，上下文工程才是精细的艺术和科学——在每一步中用恰当的信息填充上下文窗口_。
1.1.2 什么是上下文工程？
让我们从几个不同的视角来定义上下文工程：
Shopify CEO的定义：
上下文工程是为LLM提供所有用于合理解决任务的上下文信息的艺术。
实用定义：
上下文工程是设计并构建动态系统的学科，这些系统在正确的时间，以正确的格式，提供正确的信息和工具，为LLM完成任务提供所需的一切。
本质定义：
上下文工程意味着动态地为AI提供完成任务所需的一切——指令、数据、示例、工具和历史记录——在运行时全部打包到模型的输入上下文中。
1.1.3 上下文 vs 提示：核心区别
插图：多个信息源被组合到LLM的上下文窗口（它的"工作记忆"）中。上下文工程师的目标是用正确的信息、以正确的格式填充该窗口，使模型能够有效完成任务。
1.1.4 为什么需要"工程"？
现在的上下文窗口已经普遍达到128K以上甚至1M tokens，这给了智能体无限的可能性：你可以把大量智能体需要的东西（指令、知识、工具等）都放进一次Prompt中，让LLM自由地推理、规划、行动。
但为什么智能体的表现仍然不尽如人意？问题的关键不在于上下文能"装"多少，而在于LLM最终"消化"的是什么。
LLM的输出永远存在不确定性——这是架构层面注定的事实。在模型尚未发生质变之前，我们能控制的唯一变量，就是它的输入：上下文（Context）。
控制上下文，更大的"胃口"（窗口大小）固然重要；但更重要的是"营养"（质量）。大量测试表明：
- ⚠️ 冗余、冲突、错误（幻觉）信息会让LLM迷失方向
- ⚠️ 即使上下文内容完全正确，输入规模过大时，LLM的"注意力"也会被分散
- ⚠️ 在多轮推理中，微小的偏差会不断"叠加"，最终任务"南辕北辙"
这就是为什么需要上下文工程：当LLM可以"吞"下更多内容时，你需要确保"营养搭配"：有结构、有逻辑、有重点，而不仅仅是"堆料"。
1.1.5 上下文腐蚀（Context Rot）现象
尽管模型速度越来越快、可处理的数据规模越来越大，但我们观察到：**LLM和人类一样，在一定点上会"走神"或"混乱"**。
什么是上下文腐蚀？
"针堆找针"（needle-in-a-haystack）类基准揭示了一个现象：随着上下文窗口中的tokens增加，模型从上下文中准确回忆信息的能力反而下降。
不同模型的退化曲线或许更平滑，但这一特征几乎在所有模型上都会出现。因此：
上下文必须被视作一种有限资源，且具有边际收益递减。
就像人类有有限的工作记忆容量一样，LLM也有一笔"注意力预算"。每新增一个token，都会消耗这笔预算的一部分。
为什么会发生上下文腐蚀？
这种稀缺并非偶然，而是源自LLM的架构约束：
注意力分散：Transformer让每个token能够与上下文中的所有token建立关联，形成n²级别的两两注意力关系。随着上下文长度增长，模型对这些关系的建模能力会被"拉薄"。
训练数据偏差：模型的注意力模式来源于训练数据分布——短序列通常比长序列更常见，因此模型对"全上下文依赖"的经验更少。
位置编码限制：位置编码插值等技术可以让模型适配比训练期更长的序列，但会牺牲部分对token位置的精确理解。
关键洞察：
这些因素共同形成的是一个性能梯度，而非"悬崖式"崩溃：模型在长上下文下依旧强大，但相较短上下文，在信息检索与长程推理上的精度会有所下降。
基于上述现实，有意识的上下文工程就成为构建强健智能体的必需品。
1.2 六层上下文模型：上下文的"解剖学"
要理解上下文工程，我们必须首先扩展对"上下文"的定义。它不仅仅是你发送给LLM的单个提示，而是模型在生成响应之前看到的所有内容。
1.2.1 六层上下文结构
第一层：指令 / 系统提示（Instructions / System Prompt）
第二层：用户提示（User Prompt）
第三层：状态 / 历史（短期记忆）（State / History）
第三层：长期记忆（Long-Term Memory）
第四层：检索信息（RAG）
第五层：可用工具（Available Tools）
- 例如：check_inventory、send_email、execute_code
第六层：结构化输出（Structured Output）
1.2.2 上下文是一个系统，不是字符串
在精心设计的设置中，LLM看到的最终提示可能包含多个组件：
[系统角色指令]
+
[用户最新查询]
+
[即时检索的相关数据]
+
[期望输出格式的示例]
+
[可用工具列表]
例如，想象一个编码助手AI收到查询："如何修复这个认证bug？" 背后的系统可能会：
你是一位专家编码助手。用户正面临认证bug。
以下是相关代码片段：[代码]
用户的错误消息：[日志]
请提供修复方案。
上下文工程就是决定拉入哪些片段以及如何组合它们的逻辑。
1.2.3 上下文是动态的、情境特定的
与单个硬编码提示不同，上下文组装是按请求发生的。系统可能根据查询或对话状态包含不同的信息：
- 如果用户问题引用某文档：从wiki获取该文档并包含相关摘录
这种动态特性至关重要。你不会为每个翻译的句子给翻译模型完全相同的提示；你会每次喂入新句子。类似地，在AI智能体中，你会随着状态演化不断更新给的上下文。
1.3 简单Demo vs 魔法Agent的本质区别
让我们通过一个具体例子来理解上下文工程的价值。
1.3.1 场景：AI助手安排会议
用户请求：
"嘿，看看你明天有空快速同步吗？"
1.3.2 "廉价Demo"Agent
上下文质量：贫瘠
输出：
"感谢您的消息。明天对我来说可以。我能问一下您想的是什么时间吗？"
问题：
1.3.3 "魔法"Agent
上下文质量：丰富
代码的主要工作不是弄清楚_如何_响应，而是收集LLM需要的信息以实现其目标。
在调用LLM之前，系统扩展上下文以包括：
1. 📅 日历信息（显示你明天完全被占满）
2. 📧 与此人的过往邮件（确定合适的非正式语气）
3. 👤 联系人列表（识别他们是关键合作伙伴）
4. 🛠️ 工具：send_invite、send_email
输出：
"嗨Jim！明天我这边排满了，一整天都是背靠背的会议。如果周四上午有空的话可以吗？已发送邀请，告诉我是否可行。"
为什么"魔法"？
1.3.4 核心差异总结
关键洞察：
魔法不在于更智能的模型或更巧妙的算法。它在于为正确的任务提供正确的上下文。 这就是为什么上下文工程很重要。智能体失败往往不是模型失败；它们是上下文失败。
1.4 上下文工程作为"熵减"过程的理论框架
1.4.1 上下文工程的"CPU-RAM"类比
一个有用的心智模型（由Andrej Karpathy等人提出）是将LLM想象成CPU，将其上下文窗口（一次看到的文本输入）想象成RAM或工作内存。
作为工程师，你的工作类似于操作系统：用恰当的代码和数据为任务加载那块工作内存。
在实践中，这个上下文可以来自许多来源：
上下文工程就是在运行时编排所有这些片段到模型最终看到的提示中。 它不是静态提示，而是信息的动态组装。
1.4.2 信息熵与上下文质量
如果说上下文是LLM的RAM，那么上下文工程就是这块有限RAM的管理机制，让信息的组织、输入、更新、淘汰都更有秩序与目的性。
从信息论的角度，我们可以将上下文工程视为一个**"熵减"过程**：
信息宇宙的熵
- 包含：代码库、文档、历史对话、工具输出、用户偏好等
上下文工程的目标
从不断变化的信息宇宙中，筛选并组织最相关的内容，精心放入有限的上下文窗口。
这本质上是一个熵减过程：
1.4.3 上下文工程的核心问题
上下文工程需要关注一系列结构性问题与工程方法：
信息选择
信息格式
- 普通文本还是半结构化的JSON、Markdown？
信息来源
信息处理
信息清洗
信息生命周期
1.4.4 核心公式
综合以上分析，我们可以得出上下文工程的核心公式：
有效Agent = f(正确信息 + 正确工具 + 正确时机 + 正确格式)
其中：
1.5 Claude团队的核心理论：长时程任务的上下文工程
💡 本节来自Anthropic官方：这些是Claude Code团队在生产环境中验证的核心策略。
长时程任务要求智能体在超出上下文窗口的长序列行动中，仍能保持连贯性、上下文一致与目标导向。例如大型代码库迁移、跨数小时的系统性研究。
指望无限增大上下文窗口并不能根治"上下文污染"与相关性退化的问题，因此需要直接面向这些约束的工程手段。
图：与写提示的离散任务相反,上下文工程是迭代的,每次决定传递给模型什么时都会进行策划。
1.5.1 压缩整合（Compaction）
定义：当对话接近上下文上限时，对其进行高保真总结，并用该摘要重启一个新的上下文窗口，以维持长程连贯性。
实践：
- 新窗口携带压缩摘要 + 最近少量高相关工件（如"最近访问的若干文件"）
在Claude Code中的应用：
当消息历史接近上下文限制时:
1. 传递消息历史给模型进行总结和压缩
2. 模型保留最关键的细节:
- 架构决策
- 未解决的bug
- 实现细节
3. 代理继续使用压缩的上下文 + 最近访问的5个文件
→ 用户获得连续性，无需担心上下文窗口限制
调参建议：
- 一种安全的"轻触式"压缩：清理"深历史中的工具调用与结果"
优势与挑战：
1.5.2 结构化笔记（Structured Note-taking）
定义：也称"智能体记忆"。智能体以固定频率将关键信息写入上下文外的持久化存储，在后续阶段按需拉回。
价值：以极低的上下文开销维持持久状态与依赖关系。
典型应用：
- 跨数十次工具调用与多轮上下文重置仍能保持进度与一致性
实例：Claude玩Pokemon
Claude在玩Pokemon游戏时，展示了记忆如何转变智能体能力：
智能体维护精确计数,跨数千游戏步骤:
"在过去的1,234步中,我一直在1号道路训练我的Pokemon,
皮卡丘已经获得8级,目标是10级。"
无需任何关于记忆结构的提示,它自己发展出:
- 探索区域的地图
- 记住已解锁的关键成就
- 维护战斗策略的战术笔记(哪些攻击对不同对手最有效)
上下文重置后:
→ 智能体读取自己的笔记
→ 继续多小时的训练序列或地牢探索
在非编码场景中的应用：
Anthropic的Memory工具：
作为Sonnet 4.5发布的一部分，Anthropic在Claude Developer Platform上发布了记忆工具（public beta）：
1.5.3 子代理架构（Sub-agent Architectures）
思想：由主代理负责高层规划与综合，多个专长子代理在"干净的上下文窗口"中各自深挖、调用工具并探索，最后仅回传凝练摘要。
架构示例：
[主代理]
/ | \
/ | \
子代理1 子代理2 子代理3
(代码搜索)(文档分析)(测试运行)
↓ ↓ ↓
总结1 总结2 总结3
\ | /
\ | /
[主代理综合]
好处：
- ✅ 关注点分离：庞杂的搜索上下文留在子代理内部，主代理专注于整合与推理
- ✅ 并行探索：适合需要并行探索的复杂研究/分析任务
- ✅ 干净的上下文：每个子代理有全新的上下文窗口，避免污染
实例：Anthropic的多代理研究系统
在How we built our multi-agent research system中介绍的系统显示：
- 专门的子代理探索特定主题(每个可能使用数万tokens)
- 子代理返回1,000-2,000 tokens的凝练总结
结果：该模式在复杂研究任务上相较单代理基线具有显著优势。
典型场景：
用户: "分析这个代码库的性能瓶颈并给出优化建议"
[主代理规划]
├─ 子代理A: 分析CPU密集型函数
├─ 子代理B: 分析内存使用模式
├─ 子代理C: 分析I/O操作
└─ 子代理D: 审查并发实现
[主代理综合] → 生成完整的性能分析报告
1.5.4 三种策略的选择指南
根据Anthropic团队的经验，方法取舍可以遵循以下经验法则：
组合使用：
在实际生产环境中，这三种策略常常组合使用：
[Claude Code的实际策略]
1. 基础层：结构化笔记（TODO.md, NOTES.md）
2. 中间层：子代理架构（搜索代理、执行代理、反思代理）
3. 兜底层：压缩整合（当上下文仍然超限时）
1.5.5 Anthropic的核心洞察
💡 关键洞察：即便模型能力持续提升，**"在长交互中维持连贯性与聚焦"仍是构建强健智能体的核心挑战**。谨慎而系统的上下文工程将长期保持其关键价值。
Anthropic团队在Claude Code的实践中证明：
- 系统性方法必不可少：需要工程化的策略，而非临时补丁
图：一端是脆弱的硬编码if-else提示，另一端是过于笼统或错误假设共享上下文的提示。
本章小结
在本章中，我们建立了对上下文工程的完整认知框架：
1. 演进认知（1.1节）
- 从提示工程（crafting prompts）到上下文工程（designing information environments）
- 上下文工程是设计并构建动态系统，在正确时机以正确格式提供正确信息和工具
- 上下文腐蚀（Context Rot）现象：上下文必须被视作有限资源，具有边际收益递减
2. 六层上下文模型（1.2节）
3. Demo vs 魔法Agent（1.3节）
- "廉价Demo"与"魔法Agent"的差异在于上下文的质量和完整性
- 魔法不在于更智能的模型，而在于为正确任务提供正确上下文
4. 理论框架（1.4节）
- CPU-RAM类比：LLM是CPU，上下文窗口是RAM
- 上下文工程是"熵减"过程：从混乱信息宇宙筛选有序相关内容
- 核心公式：有效Agent = f(正确信息 + 正确工具 + 正确时机 + 正确格式)
5. Claude团队的核心理论（1.5节） ⭐
- 压缩整合（Compaction）：高保真总结，维持长程连贯性
- 结构化笔记（Structured Note-taking）：持久化关键信息到上下文外存储
- 子代理架构（Sub-agent Architectures）：关注点分离，并行高效探索
- 三种策略常常组合使用，这是Claude Code在生产环境中验证的最佳实践
关键洞察：
💡 即便模型能力持续提升，"在长交互中维持连贯性与聚焦"仍是构建强健智能体的核心挑战。上下文工程的价值将长期存在。
核心公式（再次强调）：
有效Agent = f(正确信息 + 正确工具 + 正确时机 + 正确格式)
参考资源
| | | |
|---|
| Phil Schmid - The New Skill in AI is Not Prompting | | https://www.philschmid.de/context-engineering | |
| A Survey of Context Engineering for LLMs | | https://arxiv.org/abs/2507.13334 | |
| Anthropic - Effective Context Engineering | | https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents | |
| | https://zhuanlan.zhihu.com/p/1928378624261731252 | |
| addyo.substack - Context Engineering | | https://addyo.substack.com/p/context-engineering-bringing-engineering | |
粤ICP备14082021号
免费POC，
零成本试错
