还在卷Prompt？真正拉开Agent差距的，是Context Engineering
你有没有遇到过——精心调教了半天的System Prompt，Agent前几轮表现完美，跑到第30轮却突然“失忆”，把最初设定的规范全忘了？
你有没有经历过——给Agent接了一大堆工具，结果它面对两个功能相近的API反复纠结，选错的概率比选对的还高？
你有没有想过——明明用的是200K上下文窗口，把所有相关资料都塞进去了，Agent的回答质量反而下降了？
这三个问题，指向同一个被大多数AI工程师忽视的真相：Agent的失败，大多数时候不是模型的失败，而是上下文的失败。
2025年，当AI工程从“Demo Agent”走向“生产级Agent”，三位业界顶尖人物几乎同时给出了同一个诊断：
“我越来越喜欢用context engineering这个词，而不是prompt engineering。它更准确地描述了这项技能：在上下文窗口中精心填充恰当的信息。” —— Andrej Karpathy，2025年7月
“现在大多数Agent的失败已经不再是模型的失败，而是上下文的失败。” —— Philipp Schmid，2025年6月
“在AI时代，使用人工智能的核心技能在于上下文工程。” —— Tobi Lütke，Shopify CEO，2025年4月
一、从Prompt到Context：三个阶段的演进
要理解Context Engineering为什么不可缺少，必须先看清这条演进路线。
第一阶段：Prompt Engineering（2020-2022）
GPT-3发布后，工程师们发现：只需要在输入里描述任务，模型就能输出不错的结果。但结果好坏对措辞极其敏感。于是大家开始研究：如何写出让模型“最听话”的提示词？
Zero-shot、Few-shot、Chain-of-Thought等技术应运而生。它们有一个共同点：都在优化“单次LLM调用”——写好一条输入，获得一条更好的输出。
这在单轮任务里非常有效，但“单轮”是它的硬边界。
第二阶段：ReAct范式（2022-2024）
2022年，普林斯顿和Google的研究团队提出了ReAct范式。它解决了一个Prompt Engineering解决不了的问题：如何让LLM主动使用外部工具、动态获取信息、分多步完成复杂任务。
ReAct定义了“思考→行动→观察”（Thought→Action→Observation）的闭环循环。这确实是一个巨大的进步——LLM从“静态答题机”变成了“能动手的助理”。
但ReAct的设计核心是行动逻辑，对“做的过程中上下文如何管理”几乎没有显式规定。
ReAct的隐患：每一轮的Thought/Action/Observation都会追加到上下文里。在一个20步、30步、50步的复杂任务里，上下文会越积越大。ReAct解决了“做什么”，但没有解决“管什么信息”。
第三阶段：Context Engineering（2025-现在）
当AI工程从Demo走向生产，工程师们集体撞上了同一堵墙：
- 任务轮次增加后，Agent开始“忘记”最初设定的规则
- 工具返回值越来越多，有用信息被淹没
- 系统提示写得再好，也扛不住上下文被“稀释”的侵蚀
Context Engineering，就是专门解决这个“只进不出”问题的。
二、核心思想：LLM就是一台“操作系统”，上下文窗口就是它的“工作内存”
理解Context Engineering，首先要理解Karpathy提出的一个被广泛引用的类比：把LLM理解为一种全新的操作系统。
| CPU（处理核心） | LLM模型本身 | 负责实际的“思考”与生成 |
| RAM（工作内存） | 上下文窗口 | 临时存储，Token限制 |
| 硬盘上的只读程序 | 模型权重 | 固化的世界知识 |
| 外接硬盘/云存储 | 向量数据库/工具 | 海量外部信息，需检索调入 |
| 操作系统的内存调度器 | Context Engineering | 决定什么信息进RAM、何时换出 |
关键认知：LLM在每次推理时，只能“看到”当前上下文窗口里的内容。无论模型权重里储存了多少知识，只要相关信息没有出现在上下文窗口里，对当次推理而言，那个信息就“不存在”。
Context Engineering就是LLM OS的“内存管理”。 优秀的内存管理不是把所有数据都塞进RAM，而是在正确的时机把正确的数据调入RAM，不用的数据及时换出。
三、三个被实验反复验证的物理约束
很多工程师的直觉是：“既然上下文窗口很大，那就把所有相关的东西都放进去，信息越多越好。”
这个直觉是错误的。 三个经过实验验证的物理约束，解释了为什么。
约束一：Lost in the Middle——信息的位置决定它被“看见”的概率
斯坦福大学的研究发现了一个稳定的U型曲线：
| 开头（第1位） | ≈75% | 首因效应，高召回 |
| 中间位置 | ≈35%～45% | “中间困境”，低召回 |
| 结尾（最后一位） | ≈70%～75% | 近因效应，高召回 |
更令人震惊的是：当正确答案被放在上下文中间时，模型的开卷正确率甚至低于什么都不给它看的闭卷基线（56.1%）。
也就是说，此时“塞给模型更多信息”反而变成了负贡献。
约束二：Context Rot——上下文越长，召回率越低
“随着上下文Token数量增加，模型准确召回上下文信息的能力线性下降。虽然不同模型降级程度不同，但这一现象在所有模型中普遍存在。”—— Anthropic，2025
这不是崩溃，而是慢性退化。 在长任务中，不主动管理上下文，Agent质量会持续下滑。
约束三：Attention Budget——O(n²)的注意力代价
| 1,000 Token | 1×（基准） | 一般提示词长度 |
| 10,000 Token | 100× | 约5000字中文内容 |
| 50,000 Token | 2,500× | 较长任务的上下文 |
| 128,000 Token | 约16,384× | 接近GPT-4 Turbo上限 |
注意力是稀缺资源。 每一个进入上下文的Token都在消耗注意力预算，增加无关内容不是中性操作，而是主动损害有效信息的信号强度。
核心公式：最优上下文 = 最小Token数量 × 最高信噪比
四、一个真实的50轮任务：有Context Engineering和没有，差距有多大？
| 第1轮 | ~3,000 Token | ~3,000 Token |
| 第15轮 | ~45,000 Token | ~8,000 Token（已触发1次压缩） |
| 第30轮 | ~85,000 Token，规则被淹没，开始生成错误变量名 | ~23,000 Token，规则在开头，行为与第1轮一致 |
| 第45轮 | ~120,000 Token，严重退化，重复审查已审查文件 | ~20,000 Token，已历经3次压缩，上下文干净 |
| 第50轮 | 任务实际上已经失败 | 基于外部笔记生成完整报告，质量与第1轮等同 |
关键差异：不是CE减少了任务的信息量，而是CE用更少的Token承载了同样的有效信息。每次压缩发生时，丢弃的是已经没有信息价值的冗余内容，保留的是真正影响后续决策的关键信息。
五、长任务的三大核心技术
① Context Compaction（上下文压缩）——让Agent“自动记忆”
核心机制：当对话的Token数量接近上下文窗口上限（通常设为70%～80%时触发），自动调用LLM对当前完整对话历史进行摘要，然后以“系统提示+压缩摘要+最近几轮原始对话”重新初始化上下文窗口。
应保留：任务目标、已完成的工作、关键决策和原因、当前状态、未解决的问题
应丢弃：冗余的工具调用原始输出、重复的中间尝试、无关的错误日志
② Structured Note-Taking（结构化笔记）——Agent的“工作日志”
与Compaction的区别：Compaction是被动的——上下文满了才触发。Structured Note-Taking是主动的——Agent在执行任务过程中，主动将关键信息“卸载”到外部持久化存储。
四种笔记类型：
- 进度笔记：已经做了什么
- 决策笔记：为什么这样做
- 发现笔记：过程中发现的重要信息
- 策略笔记：下一步怎么做
③ Sub-Agent Architecture（子Agent架构）——上下文隔离的艺术
核心设计思想：不要让一个Agent处理一切，而是让一个“主Agent”负责高层规划，将具体探索性子任务分发给多个专门的“子Agent”。每个子Agent拥有独立、干净的上下文窗口，执行完毕后只向主Agent返回精炼的摘要。
关键优势：用上下文隔离换取规模扩展。子任务的探索过程可能消耗数万Token，但这些Token被隔离在子Agent的上下文中，不会污染主Agent的上下文。
六、ReAct的四大上下文陷阱
随着TAO循环不断累积，ReAct Agent会落入四个典型的上下文陷阱：
陷阱一：Observation无限膨胀——工具调用结果永久追加，即使Agent早已消化了信息，原始返回值仍占据空间。
陷阱二：规则漂移（Rule Drift）——系统指令从“开头”被推入“中间”，正好落入Lost in the Middle的“性能洼地”。Agent前10轮严格遵守规范，从第20轮开始偶尔出错，到第30轮已经完全混用不同风格。
陷阱三：错误轨迹污染——工具调用失败、API超时、格式解析错误被永久保留，一旦一条错误信息进入上下文，它就会影响后续所有轮次的推理。
陷阱四：Thought冗余积累——中间推理在当时有意义，但随着任务推进变成了纯粹的历史记录，不再提供信息价值，却持续消耗Token预算。
四大陷阱的共同本质：ReAct循环只进不出。
七、五大常见反模式
| “更多上下文更安全”的幻觉 | 把所有可能相关的都塞进去 | 最优的上下文不是最长的，而是信噪比最高的 |
| 工具越多越好 | 注册十几个功能重叠的工具 | 工具集应“够用”而非“全面”，职责边界清晰 |
| System Prompt越详细越可靠 | 列出所有边缘情况和处理规则 | 系统提示应提供“原则”而非“枚举” |
| 不清理工具调用结果 | 完整原始结果永久保留 | 结果被消化后，应移除或压缩 |
| 用大上下文窗口作为“解决方案” | “我用200K窗口，不需要管理” | 更大的窗口只是推迟问题，信号稀释效应依然存在 |
八、写在最后
Context Engineering不是一个新概念，而是一个被长期忽视的工程维度。从Prompt Engineering到ReAct，再到Context Engineering，这三个范式不是替代关系，而是叠加关系。
Context Engineering ⊇ ReAct ⊇ Prompt Engineering
Context Engineering包含了Prompt Engineering的技巧（如何写好系统指令），也包含了ReAct的工具调用模式，并在此基础上增加了整个信息生命周期的管理维度。
ReAct是行动框架，CE是信息保障，两者缺一不可。有ReAct无CE→短期能用，长期退化。有CE无ReAct→有信息管理但没有行动逻辑。ReAct+CE→可以在生产环境长期稳定运行的Agent。
当AI工程从“Demo Agent”走向“生产级Agent”，决定Agent能不能在生产环境跑起来、跑得久、跑得稳的关键，不再是模型选得多好、提示词写得多精妙，而是——你懂不懂Context Engineering。
本文数据来源：Anthropic《Effective Context Engineering for AI Agents》（2025年9月）、Philipp Schmid《The New Skill in AI is Not Prompting, It’s Context Engineering》（2025年6月）、斯坦福大学《Lost in the Middle: How Language Models Use Long Contexts》（arXiv:2307.03172，TACL 2024）、普林斯顿大学CoALA论文（TMLR 2024）、Andrej Karpathy公开演讲内容、腾讯技术工程公众号
关注我们，获取更多AI工程架构深度解读与Agent落地实践。 如您所在的企业正面临Agent上下文管理、生产级Agent架构设计或AI应用工程化方面的挑战，欢迎进一步沟通。我们可提供针对贵企业具体场景的定制化方案和现场调研服务。
