2025年6月25日Andrej Karpathy在X上发了一条帖子获得了1.4万点赞和2600次转发。内容不长但直接改变了整个AI工程圈的讨论方向“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.”上下文工程是一门精妙的艺术与科学——为下一步操作在上下文窗口中填充恰到好处的信息。两天后Django和Datasette的作者Simon Willison跟进表态Prompt Engineering这个词已经退化成了在聊天框里打字的代名词而真正在做Agent开发的人日常花大量时间处理的事情早就不是怎么措辞了。到2025年9月Anthropic发布了《Effective context engineering for AI agents》正式把这件事定义为一门工程学科。Gartner同年10月将其纳入术语表预测到2028年80%的AI工具会内置上下文工程能力。这不是一次简单的换马甲。它背后是整个行业从单轮对话玩具走向多步Agent生产系统过程中遇到的真实工程瓶颈。一、为什么Prompt Engineering不够用了先说结论Prompt Engineering解决的是怎么跟模型说话的问题而上下文工程解决的是模型在做每一步决策时能看到什么信息的问题。前者是后者的子集。从单轮到多步的范式断裂Prompt Engineering的黄金时代是ChatGPT刚出来那会儿。你给模型一段精心编写的指令附带几个few-shot示例模型一次性返回结果。任务有明确的开始和结束所有信息在一次调用内完成闭环。但Agent不是这么工作的。一个Agent可能需要在一次任务中连续调用10次LLM推理每次都调用不同的工具、读取不同的文档、处理不同的中间结果。当第7步出了问题你去改第1步的prompt大概率解决不了问题——因为失败的原因根本不在prompt的措辞里而在于第6步注入的工具返回结果太多把关键信息挤出了注意力范围。Redis的工程博客一针见血地描述了这个陷阱你的客服Agent检查了退款状态回复用户说已退款并附上了确认号。但这笔退款20分钟前被退回了——因为Agent查的那个门店数据只做过夜同步。你修改prompt“回答前务必确认最新交易状态”。下一张工单同样的错误。因为问题从来不在prompt里在于Agent拿到的数据本身就是过时的。这就是Prompt Engineering的天花板——它能影响模型怎么理解指令但管不了模型拿到了什么数据。三个Prompt Engineering解决不了的问题1. 工具膨胀Tool Sprawl给Agent 5个工具它能选对。给Agent 30个工具它经常选错。因为工具描述本身就占上下文空间工具越多模型做选择时的决策面越宽出错概率越高。这不是prompt措辞能解决的——你需要一套工具筛选机制在每一步只把当前任务相关的工具注入上下文。2. 记忆缺失Missing MemoryAgent在第3步获得了一个关键信息到第15步需要用到时已经忘了——不是真的忘了而是那信息在上下文窗口里被后续的对话和工具输出挤到了中间位置恰好落在了模型注意力最弱的区域。这就是学术界已经验证的Lost in the Middle效应。3. 检索失灵Broken Retrieval你接了RAG但检索回来的文档里有3篇互相矛盾的内容模型无法判断该信谁。Prompt里写以最新文档为准也没用因为模型根本分不清哪个更新。这是检索管线的问题不是prompt的问题。二、上下文工程到底在做什么Karpathy在同一条帖子里给了更完整的定义之所以是科学因为做好这件事涉及任务描述、few-shot示例、RAG、相关数据可能是多模态的、工具、状态和历史记录、上下文压缩。太少或格式不对模型无法达到最优表现太多或太无关成本上升、表现反而下降。之所以是艺术因为需要对大模型的心理和行为模式有直觉性的把握。Anthropic在2025年9月的文章里把它进一步形式化为在LLM推理期间策划和维护最优token集合的一组策略。LangChain在2025年7月的《Context Engineering for Agents》中给出了目前业界最广泛引用的操作框架——四个核心动作1. Write写入把信息持久化到上下文窗口之外笔记、记忆存储、状态文件。目的是让信息不必一直占用上下文空间。典型场景Agent完成一步推理后把关键结论写入一个scratchpad文件而不是把完整推理过程留在对话历史里。2. Select筛选每一步只把相关的记忆、工具输出或文档拉进上下文而不是把所有可用的东西都塞进去。典型场景Agent有30个工具但每一步只注入5-8个与当前子任务相关的工具描述。3. Compress压缩对已在上下文中的信息进行摘要和裁剪防止累积成噪声。典型场景工具返回了3000 token的JSON但Agent只需要其中150 token的关键字段——在注入下一步之前就把原始响应压缩掉。4. Isolate隔离把上下文拆分到子Agent或沙箱步骤中让一个任务的噪声不污染另一个任务的推理。典型场景Anthropic自己的多Agent研究系统每个子Agent有独立的上下文窗口。他们发现这种方式比把所有信息塞进单个窗口表现更好——代价是token消耗最多增加到15倍。这是一个主动的cost-reliability trade-off。DevinCognition公司的自主编码Agent的工程团队对此有一个直白的总结上下文工程实际上是构建AI Agent的工程师的第一要务。三、上下文窗口的三个杀手做上下文工程本质上是在跟三个现象作斗争Context Rot上下文腐烂随着上下文窗口被填充模型精度下降——即使总token数远低于技术上限。Chroma Research在2026年对18个前沿模型包括GPT-4.1、Claude 4 Opus/Sonnet、Gemini 2.5 Pro/Flash做了受控测试发现每一个模型的准确率都随着输入长度增长而下降且退化在达到标称上限之前就已经开始。更关键的是位置效应当关键信息位于20个文档的中间位置时准确率比放在开头或结尾时下降超过30个百分点。这比早期Lost in the Middle研究的结论更为严峻。Context Pollution上下文污染上下文中存在过多不相关、冗余或互相矛盾的信息分散模型注意力降低推理准确性。这不是信息太多的问题而是信噪比太低的问题。Context Confusion上下文混淆模型无法区分指令、数据和结构标记或者遇到逻辑上互相矛盾的指令时出现的失效模式。比如系统prompt说不要引用外部数据但RAG模块注入了一段需要引用的文档——模型会陷入两难。更大的上下文窗口也救不了你一个直觉性的反驳是既然上下文是瓶颈买更大的窗口不就行了2026年Claude和Gemini都已经开放100万token的上下文窗口相比2023年GPT-4的8K上限提升了约100倍。Chroma Research的回答是不行。窗口大了但模型的注意力分配机制并没有本质改变。塞进去的信息越多有效利用率越低。这就好比给你一本1000页的书和一根荧光笔你的有效注意力仍然只能覆盖其中一小部分。四、上下文工程 vs 记忆工程两个层次一个系统2026年下半年行业讨论开始区分两个密切相关但范畴不同的概念上下文工程Context Engineering和记忆工程Memory Engineering。上下文工程关注的是单次推理调用这一步该包含什么信息、怎么压缩、放在哪个位置、丢弃什么。所有信息都是临时的——调用结束窗口清空。记忆工程关注的是跨次交互什么信息值得持久化、存在哪里、怎么检索、如何保持时效性。当Agent需要回忆上一次对话的内容、或应用几天前学到的用户偏好时它依赖的是记忆工程而非上下文工程。两者的交汇点在检索Retrieval记忆系统产出候选信息上下文组装决定这些候选是否进入、进入多少、放在哪里。在实践中最常见的两个失败模式是失败模式1检索没有上下文预算。记忆搜索返回了一堆相关条目全部注入prompt。记忆系统的召回率看着很高但上下文窗口被挤满了检索内容留给指令、工具输出和推理过程的空间越来越少。系统性能下降但排查时你会误以为是检索出了问题——其实检索没做错是上下文组装缺少预算机制。失败模式2检索信息放置不当。高相关性的记忆被检索到了但被追加到了上下文的末尾或中间某个不显眼的位置模型在推理时实际上没看到它。检索成功了放置失败了。一个务实的设计原则是先分配token预算再在预算内做检索。而不是先检索、再想办法塞进窗口。五、落地实践一个典型的上下文组装流程说了这么多概念来看一个Agent在每一步推理前实际执行的上下文组装伪代码defassemble_context_for_step(agent_state,current_step):# 1. 固定区域系统指令和工具描述system_promptagent_state.system_prompt# ~500 tokenstoolsselect_tools(current_step,max_tools8)# 动态筛选~400 tokens# 2. 预算分配total_budget128000# 模型上下文上限reservedlen(system_prompt)len(tools)4000# 预留输出空间availabletotal_budget-reserved# ~123100 tokens 可分配# 3. 按优先级填充# 高优先级当前任务相关的记忆从记忆系统检索memoriesretrieve_with_budget(memory_store,current_step.query,max_tokensint(available*0.3)# 最多30%给记忆)# 中优先级最近对话历史压缩后的historycompress_history(agent_state.conversation,max_tokensint(available*0.3)# 最多30%给历史)# 剩余空间RAG检索结果docsretrieve_docs(knowledge_base,current_step.query,max_tokensavailable-len(memories)-len(history))# 4. 结构化放置利用首尾注意力优势contextcompose(topsystem_prompthard_constraints,# 顶部硬约束middlehistorymemories,# 中间背景信息bottomdocscurrent_step.query# 底部检索结果当前任务)returncontext这段代码体现的核心原则预算先行先确定各部分能用多少token再检索填充动态筛选工具不是把所有工具都挂上而是按步骤选压缩历史对话历史不是原样保留而是滚动压缩位置策略硬约束放顶部检索结果和当前任务放底部靠近生成点中间放背景信息六、数据说了什么让数字说话。以下是2025-2026年几个关键调查的核心数据LangChain 2026年Agent工程现状调查1340名从业者2025年11-12月57.3%的组织已有Agent在生产环境运行万人以上企业达67%32%的团队将质量而非成本列为Agent上生产的最大障碍企业开放题回答中上下文管理被频繁点名为根本原因89%的组织有某种Agent可观测性工具但只有52.4%在做离线评估DataHub 2026年上下文管理状态报告250名IT和数据负责人82%认为单独的Prompt Engineering不够用77%认为单独的RAG在生产中不够用83%同意没有上下文平台就没有Agent能产出生产价值88%已将上下文管理架构写入AI战略Anthropic多Agent研究系统隔离上下文的子Agent方案比单一窗口方案效果更好代价是token消耗最多增加到标准单聊调用的15倍Anthropic主动选择了这个trade-offChroma Research上下文腐烂研究18个前沿模型所有模型的准确率都随输入长度增长而下降退化在达到标称上下文上限之前就已开始关键信息放在中间位置时准确率比首尾下降超30个百分点这些数据的结论是一致的Agent在生产环境中的失败大多不是模型能力不足而是上下文管理不到位。七、这个领域会往哪里走上下文工程目前还处于快速演化阶段。几个值得关注的方向1. 上下文管理成为基础设施层。LangChain、LlamaIndex、Pinecone等都在向这个方向转。2026年Q1企业检索优化的预算占比从19%上升到28.9%首次超过了评估evaluation的预算占比。这意味着行业开始认为给模型喂对信息比测模型准不准更重要。2. Harness Engineering的概念正在兴起。OpenAI Codex团队的Ryan Lopopolo提出了harness engineeringHarness工程的说法——核心论点是Agent本身不是难点围绕Agent的工程框架才是。这个概念和上下文工程有大量重叠但目前还没有定论谁会最终成为主流术语。3. 记忆工程与上下文工程的融合。Mem0、Redis等实时上下文引擎正在模糊两者的边界。未来的趋势可能是统一的context platform——既管持久化记忆也管运行时上下文组装。4. 标准化。目前上下文工程还没有像MCPModel Context Protocol那样的统一协议。各家框架的实现差异很大。随着企业级部署规模增长标准化的压力会越来越大。写在最后回到最初的问题Prompt Engineering是不是死了严格来说没有。对于单轮、有界的任务写好prompt仍然是最直接有效的手段。但在Agent场景下prompt只是模型做决策时看到的一大堆信息中的一小部分。你可以把prompt打磨得完美无缺但如果模型拿到的工具列表是错误的、检索到的文档是过时的、对话历史是冗长的——结果照样不行。上下文工程不是Prompt Engineering的替代品而是它的超集。它把你从怎么措辞这个单一维度拉到了模型在每一步看到了什么、怎么看到的、为什么这么安排的系统层面。如果你正在构建Agent系统下次遇到质量问题时别急着改prompt。先看看模型的上下文窗口里到底装了什么。参考资料Andrej Karpathy关于Context Engineering的帖子2025.06.25Anthropic: Effective context engineering for AI agents2025.09LangChain: Context Engineering for Agents2025.07LangChain: State of Agent Engineering Report2026.06Redis: Context engineering vs prompt engineering2026.06Machine Learning Mastery: Context vs Memory Engineering in Agentic AI Systems2026.06Chroma Research: Context Rot StudyNeuralWired: Karpathy Was Right - Context Engineering Wins in 20262026.07.30Gartner: Context Engineering - Why It’s Replacing Prompt Engineering2025.10VentureBeat: Context architecture is replacing RAG2026.05.19 【agent专栏】一文搞懂Agent上下文工程：Prompt Engineering已经不够用了
2025年6月25日Andrej Karpathy在X上发了一条帖子获得了1.4万点赞和2600次转发。内容不长但直接改变了整个AI工程圈的讨论方向“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.”上下文工程是一门精妙的艺术与科学——为下一步操作在上下文窗口中填充恰到好处的信息。两天后Django和Datasette的作者Simon Willison跟进表态Prompt Engineering这个词已经退化成了在聊天框里打字的代名词而真正在做Agent开发的人日常花大量时间处理的事情早就不是怎么措辞了。到2025年9月Anthropic发布了《Effective context engineering for AI agents》正式把这件事定义为一门工程学科。Gartner同年10月将其纳入术语表预测到2028年80%的AI工具会内置上下文工程能力。这不是一次简单的换马甲。它背后是整个行业从单轮对话玩具走向多步Agent生产系统过程中遇到的真实工程瓶颈。一、为什么Prompt Engineering不够用了先说结论Prompt Engineering解决的是怎么跟模型说话的问题而上下文工程解决的是模型在做每一步决策时能看到什么信息的问题。前者是后者的子集。从单轮到多步的范式断裂Prompt Engineering的黄金时代是ChatGPT刚出来那会儿。你给模型一段精心编写的指令附带几个few-shot示例模型一次性返回结果。任务有明确的开始和结束所有信息在一次调用内完成闭环。但Agent不是这么工作的。一个Agent可能需要在一次任务中连续调用10次LLM推理每次都调用不同的工具、读取不同的文档、处理不同的中间结果。当第7步出了问题你去改第1步的prompt大概率解决不了问题——因为失败的原因根本不在prompt的措辞里而在于第6步注入的工具返回结果太多把关键信息挤出了注意力范围。Redis的工程博客一针见血地描述了这个陷阱你的客服Agent检查了退款状态回复用户说已退款并附上了确认号。但这笔退款20分钟前被退回了——因为Agent查的那个门店数据只做过夜同步。你修改prompt“回答前务必确认最新交易状态”。下一张工单同样的错误。因为问题从来不在prompt里在于Agent拿到的数据本身就是过时的。这就是Prompt Engineering的天花板——它能影响模型怎么理解指令但管不了模型拿到了什么数据。三个Prompt Engineering解决不了的问题1. 工具膨胀Tool Sprawl给Agent 5个工具它能选对。给Agent 30个工具它经常选错。因为工具描述本身就占上下文空间工具越多模型做选择时的决策面越宽出错概率越高。这不是prompt措辞能解决的——你需要一套工具筛选机制在每一步只把当前任务相关的工具注入上下文。2. 记忆缺失Missing MemoryAgent在第3步获得了一个关键信息到第15步需要用到时已经忘了——不是真的忘了而是那信息在上下文窗口里被后续的对话和工具输出挤到了中间位置恰好落在了模型注意力最弱的区域。这就是学术界已经验证的Lost in the Middle效应。3. 检索失灵Broken Retrieval你接了RAG但检索回来的文档里有3篇互相矛盾的内容模型无法判断该信谁。Prompt里写以最新文档为准也没用因为模型根本分不清哪个更新。这是检索管线的问题不是prompt的问题。二、上下文工程到底在做什么Karpathy在同一条帖子里给了更完整的定义之所以是科学因为做好这件事涉及任务描述、few-shot示例、RAG、相关数据可能是多模态的、工具、状态和历史记录、上下文压缩。太少或格式不对模型无法达到最优表现太多或太无关成本上升、表现反而下降。之所以是艺术因为需要对大模型的心理和行为模式有直觉性的把握。Anthropic在2025年9月的文章里把它进一步形式化为在LLM推理期间策划和维护最优token集合的一组策略。LangChain在2025年7月的《Context Engineering for Agents》中给出了目前业界最广泛引用的操作框架——四个核心动作1. Write写入把信息持久化到上下文窗口之外笔记、记忆存储、状态文件。目的是让信息不必一直占用上下文空间。典型场景Agent完成一步推理后把关键结论写入一个scratchpad文件而不是把完整推理过程留在对话历史里。2. Select筛选每一步只把相关的记忆、工具输出或文档拉进上下文而不是把所有可用的东西都塞进去。典型场景Agent有30个工具但每一步只注入5-8个与当前子任务相关的工具描述。3. Compress压缩对已在上下文中的信息进行摘要和裁剪防止累积成噪声。典型场景工具返回了3000 token的JSON但Agent只需要其中150 token的关键字段——在注入下一步之前就把原始响应压缩掉。4. Isolate隔离把上下文拆分到子Agent或沙箱步骤中让一个任务的噪声不污染另一个任务的推理。典型场景Anthropic自己的多Agent研究系统每个子Agent有独立的上下文窗口。他们发现这种方式比把所有信息塞进单个窗口表现更好——代价是token消耗最多增加到15倍。这是一个主动的cost-reliability trade-off。DevinCognition公司的自主编码Agent的工程团队对此有一个直白的总结上下文工程实际上是构建AI Agent的工程师的第一要务。三、上下文窗口的三个杀手做上下文工程本质上是在跟三个现象作斗争Context Rot上下文腐烂随着上下文窗口被填充模型精度下降——即使总token数远低于技术上限。Chroma Research在2026年对18个前沿模型包括GPT-4.1、Claude 4 Opus/Sonnet、Gemini 2.5 Pro/Flash做了受控测试发现每一个模型的准确率都随着输入长度增长而下降且退化在达到标称上限之前就已经开始。更关键的是位置效应当关键信息位于20个文档的中间位置时准确率比放在开头或结尾时下降超过30个百分点。这比早期Lost in the Middle研究的结论更为严峻。Context Pollution上下文污染上下文中存在过多不相关、冗余或互相矛盾的信息分散模型注意力降低推理准确性。这不是信息太多的问题而是信噪比太低的问题。Context Confusion上下文混淆模型无法区分指令、数据和结构标记或者遇到逻辑上互相矛盾的指令时出现的失效模式。比如系统prompt说不要引用外部数据但RAG模块注入了一段需要引用的文档——模型会陷入两难。更大的上下文窗口也救不了你一个直觉性的反驳是既然上下文是瓶颈买更大的窗口不就行了2026年Claude和Gemini都已经开放100万token的上下文窗口相比2023年GPT-4的8K上限提升了约100倍。Chroma Research的回答是不行。窗口大了但模型的注意力分配机制并没有本质改变。塞进去的信息越多有效利用率越低。这就好比给你一本1000页的书和一根荧光笔你的有效注意力仍然只能覆盖其中一小部分。四、上下文工程 vs 记忆工程两个层次一个系统2026年下半年行业讨论开始区分两个密切相关但范畴不同的概念上下文工程Context Engineering和记忆工程Memory Engineering。上下文工程关注的是单次推理调用这一步该包含什么信息、怎么压缩、放在哪个位置、丢弃什么。所有信息都是临时的——调用结束窗口清空。记忆工程关注的是跨次交互什么信息值得持久化、存在哪里、怎么检索、如何保持时效性。当Agent需要回忆上一次对话的内容、或应用几天前学到的用户偏好时它依赖的是记忆工程而非上下文工程。两者的交汇点在检索Retrieval记忆系统产出候选信息上下文组装决定这些候选是否进入、进入多少、放在哪里。在实践中最常见的两个失败模式是失败模式1检索没有上下文预算。记忆搜索返回了一堆相关条目全部注入prompt。记忆系统的召回率看着很高但上下文窗口被挤满了检索内容留给指令、工具输出和推理过程的空间越来越少。系统性能下降但排查时你会误以为是检索出了问题——其实检索没做错是上下文组装缺少预算机制。失败模式2检索信息放置不当。高相关性的记忆被检索到了但被追加到了上下文的末尾或中间某个不显眼的位置模型在推理时实际上没看到它。检索成功了放置失败了。一个务实的设计原则是先分配token预算再在预算内做检索。而不是先检索、再想办法塞进窗口。五、落地实践一个典型的上下文组装流程说了这么多概念来看一个Agent在每一步推理前实际执行的上下文组装伪代码defassemble_context_for_step(agent_state,current_step):# 1. 固定区域系统指令和工具描述system_promptagent_state.system_prompt# ~500 tokenstoolsselect_tools(current_step,max_tools8)# 动态筛选~400 tokens# 2. 预算分配total_budget128000# 模型上下文上限reservedlen(system_prompt)len(tools)4000# 预留输出空间availabletotal_budget-reserved# ~123100 tokens 可分配# 3. 按优先级填充# 高优先级当前任务相关的记忆从记忆系统检索memoriesretrieve_with_budget(memory_store,current_step.query,max_tokensint(available*0.3)# 最多30%给记忆)# 中优先级最近对话历史压缩后的historycompress_history(agent_state.conversation,max_tokensint(available*0.3)# 最多30%给历史)# 剩余空间RAG检索结果docsretrieve_docs(knowledge_base,current_step.query,max_tokensavailable-len(memories)-len(history))# 4. 结构化放置利用首尾注意力优势contextcompose(topsystem_prompthard_constraints,# 顶部硬约束middlehistorymemories,# 中间背景信息bottomdocscurrent_step.query# 底部检索结果当前任务)returncontext这段代码体现的核心原则预算先行先确定各部分能用多少token再检索填充动态筛选工具不是把所有工具都挂上而是按步骤选压缩历史对话历史不是原样保留而是滚动压缩位置策略硬约束放顶部检索结果和当前任务放底部靠近生成点中间放背景信息六、数据说了什么让数字说话。以下是2025-2026年几个关键调查的核心数据LangChain 2026年Agent工程现状调查1340名从业者2025年11-12月57.3%的组织已有Agent在生产环境运行万人以上企业达67%32%的团队将质量而非成本列为Agent上生产的最大障碍企业开放题回答中上下文管理被频繁点名为根本原因89%的组织有某种Agent可观测性工具但只有52.4%在做离线评估DataHub 2026年上下文管理状态报告250名IT和数据负责人82%认为单独的Prompt Engineering不够用77%认为单独的RAG在生产中不够用83%同意没有上下文平台就没有Agent能产出生产价值88%已将上下文管理架构写入AI战略Anthropic多Agent研究系统隔离上下文的子Agent方案比单一窗口方案效果更好代价是token消耗最多增加到标准单聊调用的15倍Anthropic主动选择了这个trade-offChroma Research上下文腐烂研究18个前沿模型所有模型的准确率都随输入长度增长而下降退化在达到标称上下文上限之前就已开始关键信息放在中间位置时准确率比首尾下降超30个百分点这些数据的结论是一致的Agent在生产环境中的失败大多不是模型能力不足而是上下文管理不到位。七、这个领域会往哪里走上下文工程目前还处于快速演化阶段。几个值得关注的方向1. 上下文管理成为基础设施层。LangChain、LlamaIndex、Pinecone等都在向这个方向转。2026年Q1企业检索优化的预算占比从19%上升到28.9%首次超过了评估evaluation的预算占比。这意味着行业开始认为给模型喂对信息比测模型准不准更重要。2. Harness Engineering的概念正在兴起。OpenAI Codex团队的Ryan Lopopolo提出了harness engineeringHarness工程的说法——核心论点是Agent本身不是难点围绕Agent的工程框架才是。这个概念和上下文工程有大量重叠但目前还没有定论谁会最终成为主流术语。3. 记忆工程与上下文工程的融合。Mem0、Redis等实时上下文引擎正在模糊两者的边界。未来的趋势可能是统一的context platform——既管持久化记忆也管运行时上下文组装。4. 标准化。目前上下文工程还没有像MCPModel Context Protocol那样的统一协议。各家框架的实现差异很大。随着企业级部署规模增长标准化的压力会越来越大。写在最后回到最初的问题Prompt Engineering是不是死了严格来说没有。对于单轮、有界的任务写好prompt仍然是最直接有效的手段。但在Agent场景下prompt只是模型做决策时看到的一大堆信息中的一小部分。你可以把prompt打磨得完美无缺但如果模型拿到的工具列表是错误的、检索到的文档是过时的、对话历史是冗长的——结果照样不行。上下文工程不是Prompt Engineering的替代品而是它的超集。它把你从怎么措辞这个单一维度拉到了模型在每一步看到了什么、怎么看到的、为什么这么安排的系统层面。如果你正在构建Agent系统下次遇到质量问题时别急着改prompt。先看看模型的上下文窗口里到底装了什么。参考资料Andrej Karpathy关于Context Engineering的帖子2025.06.25Anthropic: Effective context engineering for AI agents2025.09LangChain: Context Engineering for Agents2025.07LangChain: State of Agent Engineering Report2026.06Redis: Context engineering vs prompt engineering2026.06Machine Learning Mastery: Context vs Memory Engineering in Agentic AI Systems2026.06Chroma Research: Context Rot StudyNeuralWired: Karpathy Was Right - Context Engineering Wins in 20262026.07.30Gartner: Context Engineering - Why It’s Replacing Prompt Engineering2025.10VentureBeat: Context architecture is replacing RAG2026.05.19