Prompt Engineering 教你怎么问问题。Context Engineering 教你怎么给 AI 搭建整个"认知脚手架"。2025 年中期这个词突然火了，但它背后的工程挑战其实比大多数人想象的深得多——涉及注意力经济学、记忆架构设计、信息压缩理论、工具编排，以及一个至今没人完全解决的根本矛盾：上下文窗口是有限的，但 Agent 需要处理的信息是无限的。
一、先讲清楚：Context Engineering 到底是个啥
2025 年 6 月，Shopify CEO Tobi Lütke 发了一条推："我真的很喜欢 'context engineering' 这个词，它比 prompt engineering 更好地描述了核心技能：为任务提供所有必要上下文的艺术，使其对 LLM 而言是可解的。"
几天后，Andrej Karpathy 跟了一条更有技术含量的推文，直接把这个概念推上了风口浪尖："在每一个工业级 LLM 应用中，context engineering 是一门精密的艺术和科学——往上下文窗口里填入恰好正确的信息，服务于下一步操作。"
Karpathy 的定义揭示了一个关键洞察：Context 不是一个字符串，而是一个系统的输出。
让我把这个概念拆得再细一点。当我们说"context"的时候，实际上在说什么？
- System Prompt / Instructions：定义 Agent 行为的基础规则
- User Prompt：用户当前的任务或问题
- State / History（短期记忆） ：当前对话的历史记录
- Long-term Memory：跨会话的持久化记忆
- Retrieved Knowledge（RAG） ：从外部知识库实时检索的信息
- Tool Definitions：可用工具的描述和调用规范
- Tool Outputs：工具执行的返回结果
- Environment Info：运行环境的元数据
- Examples（Few-shot） ：示例输入输出对
Context Engineering 就是设计和构建一个动态系统，在正确的时间、以正确的格式、提供正确的信息和工具，让 LLM 拥有完成任务所需的一切。
注意这里的关键词：动态系统。它不是在写一个静态的 prompt 模板，而是在构建一个运行时的信息编排引擎。对于不同的请求，这个系统可能需要拉取日历数据、搜索邮件、查询数据库、检索文档——然后把这些异构信息整合成一个对 LLM 来说"刚好够用"的上下文包。
二、为什么 Prompt Engineering 不够用了
很多人觉得 Context Engineering 就是"Prompt Engineering 的高级版"。这个理解不算错，但低估了两者之间的断层。
Prompt Engineering 关注的是怎么问——措辞、格式、思维链、角色设定。它默认你已经有了所有需要的信息，问题只是怎么组织语言让 LLM 理解你的意图。
Context Engineering 关注的是喂什么——在 LLM 推理之前，你的系统需要做大量工作来决定哪些信息应该出现在上下文里、以什么顺序、什么格式、什么粒度。
Karpathy 给了一个很好的类比：把 LLM 想象成 CPU，上下文窗口就是 RAM。Prompt Engineering 是在写汇编指令，Context Engineering 是在设计整个内存管理系统——包括什么数据从磁盘加载到内存、什么时候换出、怎么压缩、怎么索引。
这个断层在 Agent 场景下尤其明显。一个简单的聊天机器人可能只需要好的 prompt。但一个能自主运行数小时、调用几十个工具、处理多文件编辑的编程 Agent，它的成败 70% 取决于上下文质量，而不是模型能力。
Gao 等人在 2024 年的 RAG 综述中指出了一个反直觉的事实：现代 LLM 应用中超过 70% 的错误不是因为模型能力不足，而是因为上下文不完整、不相关或结构不良。换句话说，在 2026 年模型已经足够强的今天，决定 AI 应用成败的瓶颈已经从"模型侧"转移到了"上下文侧" 。
Hugging Face 的 Phil Schmid 说得更直白："大多数 Agent 的失败不是模型失败，而是上下文失败。"
三、上下文窗口的根本矛盾：注意力是稀缺资源
这是整个 Context Engineering 领域最核心的底层挑战，很多人知道它存在，但很少有人真正理解它有多棘手。
3.1 上下文窗口越大 ≠ 越好用
2025-2026 年，上下文窗口经历了爆发式增长：Claude 支持 200K tokens，Gemini 3 Pro 达到 2M tokens，GPT-5.4 在 Codex 模式下支持 1M tokens，Llama 4 甚至声称支持 10M tokens。
直觉告诉我们：窗口越大，能塞进去的信息越多，效果应该越好。
但研究给出了残酷的现实：
Lost-in-the-Middle 效应：LLM 对上下文的注意力分布是不均匀的——对开头和结尾的信息关注度最高，中间的信息容易被"遗忘"。这不是某一个模型的 bug，而是 Transformer 注意力机制的结构性缺陷。
注意力稀缺：每个 token 都在争夺有限的注意力资源。上下文越长，每个 token 平均分到的注意力越少。到了一定长度后，增加更多上下文实际上会降低性能——信噪比下降了。
延迟成本：输出 token 的生成延迟随输入 token 数量显著增加。超过 100K tokens 后，一些模型的延迟会大幅飙升，直接影响用户体验。
经济成本：更长的上下文意味着更高的推理费用。对于大规模部署的应用，这不是可以忽略的开销。
Anthropic 在他们最新的 Context Engineering 文章中把这个问题提炼为一句话：Context engineering 的本质是找到最小的、高信号的 token 集合，最大化期望结果的可能性。
这是一个优化问题。而且是一个非常难的优化问题——因为你需要在"信息充分性"和"注意力效率"之间找到动态平衡，而这个平衡点会随着任务类型、对话长度、工具调用次数的变化而变化。
3.2 不只是"中间丢失"——更深层的失败模式
Weaviate 的技术博客总结了长上下文场景下的几种致命失败模式：
Context Poisoning（上下文中毒） ：错误或幻觉信息进入上下文后，Agent 会在此基础上继续推理，错误像滚雪球一样积累和放大。
Context Distraction（上下文分心） ：过多的历史信息让 Agent 过度依赖过去的行为模式，而不是针对当前问题进行新鲜推理。就像一个人背负了太多过往经验，反而无法看清眼前的新问题。
Context Confusion（上下文混淆） ：多个来源的信息在上下文中产生矛盾——比如 RAG 检索到的文档和系统 prompt 的指令冲突——导致 Agent 行为不可预测。
Context Staleness（上下文过时） ：对话越长，早期的信息越可能已经过时。但这些过时信息仍然占据着宝贵的上下文空间，而且模型没有内置的"过期检测"机制。
这些失败模式不是理论上的。任何做过生产级 Agent 的人都会在第一周内遇到其中的至少两种。
四、六大核心工程策略：生产级 Agent 怎么管理上下文
面对这些挑战，社区和工业界已经发展出了一套成熟的策略。我把它们分成六个层次，从最基础到最高级。
4.1 渐进式披露（Progressive Disclosure）
核心思想：不要一次性把所有信息塞进上下文，而是按需加载。
静态渐进式披露：通过配置文件预定义什么信息在什么阶段加载。比如 Codex 的 Skills 系统——Agent 启动时只加载每个 Skill 的元数据（名称和描述），只有当它判断需要使用某个 Skill 时才读取完整内容。Claude Code 的 @ 引用也是类似思路。
动态渐进式披露：让 LLM 自己决定什么时候加载更多上下文。比如给 Agent 提供"搜索代码库"和"读取文件"的工具，让它根据当前任务自行决定需要查看哪些文件。这是让 Agent 自主运行的前提。
一个重要的权衡：让 LLM 决定何时加载上下文提高了自动化程度，但引入了不确定性——你无法保证它会在你期望的时机去加载关键信息。Martin Fowler 网站上 Thoughtworks 的一篇文章把这称为 Context Engineering 的一个基本张力：控制 vs 自主。
4.2 上下文压缩（Context Compression）
当对话变长、工具调用积累，上下文最终会逼近窗口极限。这时候需要压缩。
滑动窗口 + 摘要：保持最近 N 轮对话完整不动，对更早的历史用 LLM 做摘要压缩。这是目前社区公认最实用的基线方案。
来自生产实践的两个关键细节（源自 Manus 平台的分享）：
- 保留最近的工具调用原始格式。压缩掉工具调用的细节后，模型会丧失"节奏感"——它不知道之前的工具调用是什么格式、什么模式，导致后续的工具调用出现微妙的退化。
- 永远不要压缩掉错误 trace。当工具调用失败时，保留完整的错误信息和堆栈跟踪，帮助模型避免重蹈覆辙。这个技巧在 Instructor 等库中已经是标准做法。
压缩的根本困难是：任何压缩都是有损的。你在节省 token 的同时必然丢失了一些细节。什么信息可以丢、什么必须保留？这个判断本身就需要"理解"——而做判断的又是一个 LLM。这是一个递归的难题。
4.3 路由（Routing）
一个多领域 Agent 可能连接了多个知识库、多个工具集、多组指令。如果每次查询都加载所有这些，上下文会迅速膨胀。
路由的思路是：先判断当前查询属于哪个领域，只加载相关的上下文。
最简单的做法是基于关键词的规则匹配——成本几乎为零，但能显著减少上下文膨胀。更复杂的做法是用一个轻量级 LLM 做意图分类，然后路由到对应的专家 Agent 或知识库。
4.4 检索增强（Evolved Retrieval）
RAG 是 Context Engineering 中最成熟的技术之一，但 2025-2026 年的 RAG 已经远超"embedding + 向量搜索"的基础形态。
Agentic RAG：Agent 自己决定什么时候需要检索、检索什么、对检索结果做什么。它可能先搜索一轮，评估结果，发现信息不足，然后换个关键词再搜一轮。这种"带反思的检索"在复杂任务上比一次性检索效果好得多。
Graph RAG：结合知识图谱和向量搜索，不只是找到相关文档，还能沿着实体关系进行推理。比如"这个 API 的调用者有哪些？那些调用者又被谁依赖？"——这种多跳推理纯向量搜索做不到。
Reranking：检索出候选文档后，用专门的排序模型（而不是原始的 embedding 相似度）重新排列，把真正相关的推到前面。结合"Position Engineering"——把最关键的信息放在上下文的开头或结尾——可以显著改善 Lost-in-the-Middle 问题。
4.5 工具管理（Tool Management）
工具定义本身就消耗大量 token。一个连接了 20 个 MCP Server 的 Agent，光是工具 schema 就可能吃掉几千甚至上万 token——在用户说第一句话之前。
Anthropic 的文章专门提到了这个被忽视的问题：工具集膨胀是最常见的失败模式之一。太多功能重叠的工具会导致模型在选择工具时犹豫不决；工具描述如果写得不清晰，模型会传入错误的参数。
最佳实践：工具应该像设计良好的代码库中的函数一样——自包含、对错误鲁棒、用途明确。输入参数应该描述清晰、无歧义。如果一个人类工程师看了工具描述后都不确定该用哪个工具，那模型更不行。
4.6 记忆架构（Memory Architecture）
这是 Context Engineering 中最前沿、也最没有定论的领域。
参考认知科学，社区正在收敛到一个三层记忆模型：
Working Memory（工作记忆） ：就是当前的上下文窗口。包含当前对话的所有消息、检索到的知识片段、工具调用结果。Token 预算最贵，但精度最高。核心挑战：在有限预算内决定保留什么、压缩什么、丢弃什么。
Episodic Memory（情景记忆） ：存储过去交互的"经验"——之前对话的摘要、用户问过的问题、系统犯过的错误和纠正。跨会话持久化，用于避免重复错误和个性化响应。
Semantic Memory（语义记忆） ：结构化的知识库——事实、关系、规则。通常由向量数据库或知识图谱承载。这是最"传统"的外部知识存储。
2025 年底 Stanford 的 Generative Agents 研究展示了这个方向的可行性。2026 年，层次化记忆架构成为一个主要研究焦点——通过分层的短期、工作、长期记忆系统，使模型能在扩展交互中处理和记住大量信息。
五、前沿研究：四个让人兴奋的方向
5.1 Agentic Context Engineering（ACE）——让上下文自我进化
这是 2025 年 10 月一篇来自 arXiv 的重要论文提出的框架。核心思想很有意思：把上下文视为一个不断进化的"剧本"（playbook），通过生成、反思、策展的模块化流程来积累、精炼和组织策略。
传统做法是人类手写 system prompt，然后祈祷它对所有场景都好用。ACE 的做法是让 Agent 自己根据任务表现来更新自己的 prompt。表现好的策略被保留和强化，表现差的被淘汰。
ACE 解决了两个老大难问题：
- Brevity Bias（简洁偏差） ：传统的上下文优化倾向于生成越来越简短的摘要，丢失了领域特定的关键细节
- Context Collapse（上下文坍缩） ：迭代式的上下文重写会逐渐侵蚀细节，最终变成一堆没有营养的泛化语句
北京大学智能信息科学国家重点实验室 2026 年的后续工作（Meta Context Engineering via Agentic Skill Evolution）进一步推进了这个方向，探索如何让 Agent 的 Skill 也能动态进化。
5.2 GAM：对抗"上下文腐烂"的双 Agent 记忆架构
VentureBeat 在 2025 年底报道了一个叫 GAM（Generative Agent Memory）的架构，它的核心洞察很深刻：不要试图在存储时就决定什么重要，而是在检索时按需"编译"上下文。
GAM 用了一个类比：Just-in-Time（JIT）编译。它维护一个完整的、无损的原始历史存档，加上一层轻量级的索引线索。当需要回忆时，一个"研究员" Agent 会执行分层搜索——混合向量检索、关键词匹配和直接查找——直到收集到足够的证据才停止。
传统的压缩方法（摘要、滑动窗口）本质上是预编译——提前决定了什么重要什么不重要。但任务是动态的，今天不重要的信息明天可能变得关键。GAM 的 JIT 方法避免了这种"过早优化"的陷阱。
5.3 上下文压缩的新范式：从有损到"选择性无损"
2026 年最新的研究（比如 OpenReview 上的 SAC 论文）正在探索一种新思路：不再用随机初始化的"压缩 token"来表示上下文，而是从原始文本中选择代表性 token作为"锚点"，然后用双向注意力（而非传统的因果注意力）来让这些锚点聚合整个上下文的信息。
这种方法的优势是锚点本身携带了语义先验——它们不是无中生有的向量，而是原文中的真实 token——这减少了压缩导致的语义失真。在实验中，这种方法实现了超过 3000 倍的压缩比，同时保持了约 92% 的事实准确率。
不过必须诚实说，这类研究距离生产落地还有距离。但它代表了一个重要的研究方向：能不能找到一种压缩方式，在极端压缩比下仍然保持关键信息的无损性？
5.4 MCP 的标准化：上下文的"USB 接口"
Model Context Protocol（MCP）正在成为 AI Agent 连接外部工具和数据源的通用标准。Anthropic 在 2025 年底将 MCP 捐赠给了 Linux Foundation 旗下的 Agentic AI Foundation，联合发起方包括 OpenAI、Google、Microsoft、AWS、Block 等。
截至 2026 年，MCP SDK 的月下载量超过 9700 万次，有 75+ 个官方连接器。2025 年 11 月的规范更新引入了异步操作、无状态模式和服务器身份验证。
从 Context Engineering 的角度，MCP 解决的是工具上下文的标准化问题。没有 MCP 之前，每个工具都有自己的 API 格式，Agent 需要为每种工具编写定制的集成代码。有了 MCP，工具的描述、调用方式、返回格式都被标准化了，大大降低了工具上下文的工程复杂度。
但 MCP 也带来了新的 Context Engineering 挑战：当一个 Agent 连接了几十个 MCP Server 时，光是工具 schema 就可能消耗大量 token。如何做到"按需发现"而不是"全量加载"，是正在被积极解决的问题。
六、编程 Agent 中的 Context Engineering 实战
编程 Agent 是 Context Engineering 最密集的应用场景之一——代码库巨大、文件间关系复杂、需要理解项目规范和历史变更。
6.1 Anthropic 的实践：指令 vs 指导 vs 上下文接口
Thoughtworks 的 Birgitta 在 Martin Fowler 网站上发了一篇很有启发的文章，把编程 Agent 的上下文分成了三类：
Instructions（指令） ：告诉 Agent 做什么。比如"按以下方式编写 E2E 测试：..."
Guidance（指导/规则） ：Agent 应遵循的通用约定。比如"测试之间必须相互独立。"
Context Interfaces（上下文接口） ：描述 Agent 如何获取更多上下文的方式。最基础的是文件读取和代码搜索——让 Agent 能自主探索代码库。
她还指出了一个被低估的问题：你的代码库本身就是上下文。代码的可读性、注释质量、目录结构的清晰度——这些"人类可读性"的传统关切，在 AI 时代有了新的含义。一个 AI-friendly 的代码库设计，本身就是一种 Context Engineering。
6.2 AGENTS.md 的局限性
Faros AI 的经验值得深思。他们在大量仓库中投入了精力编写详尽的 AGENTS.md 文件——架构模式、编码规范、常见陷阱、最佳实践——本质上就是一份"面向 AI 的开发者入职手册"。
结果呢？效果一般。他们发现：
- Agent 的变异性比 rules 文件的优化更重要。同一个 Agent，用完全相同的上下文，运行两次产生的结果可能截然不同。
- 通用规则的效果很弱。"遵循 DRY 原则"在理论上有帮助，但无法阻止每个代码库特有的反模式。
- 上下文质量 > 上下文数量。一份 500 行的 AGENTS.md 不一定比一份精炼的 50 行版本更有效。
这再次印证了 Anthropic 的核心观点：保持上下文信息充分但紧凑。不是写得越多越好。
6.3 编程 Agent 的"三层上下文加载"策略
综合各家实践，编程 Agent 的上下文加载通常分三层：
- Always-on（始终加载） ：系统 prompt + AGENTS.md/CLAUDE.md 核心规则 + 项目结构概览。这些信息每次推理都在，不需要触发条件。
- Triggered（触发式加载） ：按路径匹配的规则（比如只在编辑 .ts 文件时加载 TypeScript 规范）、按任务类型加载的 Skill、按文件引用加载的上下文。
- On-demand（按需加载） ：Agent 通过工具调用自主检索——grep 搜索、文件读取、git log 查询、文档搜索。这是最灵活但也最不确定的层次。
关键洞察：第一层要足够小，第三层要足够强。always-on 的内容越精简，留给按需检索的 token 预算越多，Agent 的灵活性越强。
七、尚未解决的难题：老实说，我们还差得远
Context Engineering 领域有很多令人兴奋的进展，但更多的是尚未解决的根本性难题。作为一个在这个领域摸爬滚打过的人，我觉得有必要把这些挑战摊开来说。
7.1 可评估性问题
怎么衡量一个上下文设计的好坏？这比听起来要难得多。
传统的 Needle-in-a-Haystack 测试太简单了——它只测试简单的词汇检索，不代表生产场景需要的复杂推理和语义理解。
SwirlAI 的 newsletter 提到了一种"probe-based evaluation"方法：在上下文中嵌入探针问题，检查 Agent 是否能回忆出被压缩或被检索的信息。但这也只是测量了"信息保留"，没有测量"信息利用"——模型可能记住了信息但在推理时没有用到。
目前这个领域缺乏一个公认的、端到端的评测标准。这严重制约了 Context Engineering 从"art"走向"science"。
7.2 上下文 Debug 的可观测性
当 Agent 产生了错误输出，你怎么判断是模型的问题还是上下文的问题？
目前大多数 Agent 框架的可观测性工具都很原始。你能看到完整的 prompt 和 response，但很难追踪"为什么检索到了这段文档而不是那段"、"为什么工具 A 被选中而不是工具 B"、"压缩过程丢失了哪些关键信息"。
社区里有人提出了一个雄心勃勃的构想：codex proxy start --record .codex/logs——一个透明的中间人代理，记录结构化的 JSONL 日志，包含时间戳、session、agent、prompt、工具调用、延迟、token 消耗等。这个方向很正确，但离标准化还很远。
7.3 多 Agent 的上下文隔离与共享
当多个 Agent 协作时，它们之间如何共享上下文？太少的共享导致信息孤岛，太多的共享导致上下文膨胀和隐私风险。
目前大多数多 Agent 系统（包括 OpenAI 的 Agents SDK 和 Anthropic 的 Agent Teams）采用的是"文件交接"模式——Agent A 把产出写入文件，Agent B 从文件读取。这简单但粗暴。
理想的方案应该是一种分层的上下文权限模型——类似操作系统的进程间通信和内存保护。某些上下文信息是"全局可见"的（项目规范），某些是"组内可见"的（当前任务的状态），某些是"私有"的（单个 Agent 的推理中间状态）。
7.4 上下文的因果性问题
当 Agent 基于检索到的信息做出决策，如果检索结果是错误的或过时的怎么办？
更深层的问题是：Agent 能不能区分"我知道的"和"我被告知的"？ 目前的 LLM 不擅长这个。它们倾向于把上下文中的所有信息当作事实来处理，即使那些信息是 RAG 从一份三年前的文档中检索出来的。
这不是一个小问题。在生产环境中，上下文中毒（context poisoning）是最难调试的故障之一——错误信息进入上下文后，会被后续的推理步骤反复引用和放大，而你看到的错误表象可能已经距离根因十几步之远。
7.5 个性化 vs 泛化的张力
如果一个 Agent 记住了用户 A 的偏好并据此做出推理，当用户 B 使用同一个 Agent 时，那些个性化记忆可能变成噪声。
更微妙的情况是：同一个用户在不同项目、不同角色下可能有不同的偏好。一个在 Python 项目中"永远用 type hints"的规则，在一个快速原型项目中可能是过度约束。
上下文的个性化粒度应该是什么？用户级？项目级？任务级？会话级？ 目前没有标准答案。
八、未来的方向：Context Engineering 会走向哪里
8.1 从"被动填充"到"主动探索"
当前大多数 Context Engineering 系统是"被动"的——基于预定义的规则和触发条件来组装上下文。未来的方向是让 Agent 主动管理自己的上下文——它知道自己不知道什么，知道应该去找什么，知道什么时候需要压缩、什么时候需要扩展。
Anthropic 的文章暗示了这个方向："随着底层模型变得更强，Agent 的自主程度可以提升——更聪明的模型允许 Agent 独立导航复杂的问题空间并从错误中恢复。"
8.2 "认知工作区"模型
受认知科学启发的"Cognitive Workspace"概念正在被严肃对待。这个模型建议未来的 LLM 系统可能有离散的"记忆模块"，类似于人类的短期记忆、工作记忆和长期记忆。
不是简单地在外面加一层 RAG 或 vector store，而是在模型架构内部实现多层记忆。这需要模型训练范式的根本性变化——从"固定上下文窗口 + 外部检索"到"内建层次化记忆 + 自主记忆管理"。
8.3 上下文的可组合性
未来的 Context Engineering 系统可能会像 Unix 管道一样可组合——不同的上下文处理器（压缩器、过滤器、排序器、格式化器）可以自由组合，形成针对特定任务优化的上下文管道。
LangChain/LangGraph 已经在朝这个方向走——将上下文流视为代码，prompt、工具、记忆通过编程式的链组合。但目前的抽象层次还不够高，组合性还不够好。
8.4 多模态上下文
当 Agent 需要同时处理文本、图像、音频、视频时，上下文管理的复杂度又上了一个台阶。一张截图可能包含了相当于 1000 个文本 token 的信息，但在上下文窗口中的"注意力权重"如何分配？多模态信息之间的"相关性"如何计算？
这些问题目前基本上是 open problems。
8.5 形式化理论
最令人兴奋的研究方向之一是尝试为 Context Engineering 建立形式化的数学框架。比如用"Directed Information γ-covering"来描述最优上下文选择——给定一个任务和一个上下文空间，什么是数学上最优的上下文子集？
这类理论工作目前还很早期，但如果成功，它可以把 Context Engineering 从"经验驱动的调优"推向"理论指导的设计"——就像编译器优化从启发式发展为形式化验证一样。
九、写在最后：真正的 10x 不在模型，在上下文
回顾这篇文章讨论的所有内容，我想用一个最核心的判断作为结尾：
在 2026 年，模型能力已经不再是瓶颈。上下文质量才是。
这不是我一个人的观点。Anthropic 说"most agent failures are context failures"。Karpathy 说 context engineering 是"一门精密的艺术和科学"。Faros 的实战数据显示 agent 变异性比 rules 优化更重要。所有这些观察都指向同一个结论：我们已经进入了一个"模型很强但应用很脆"的时代，而 Context Engineering 是弥合这个鸿沟的关键学科。
对于正在做 Agent 开发的同学，我的建议是：
- 停止执着于 prompt 的措辞。把精力放在设计上下文的"供给系统"上——什么信息、什么时候、什么格式、什么优先级。
- 投资可观测性。你无法优化你不能观测的东西。记录每次推理的完整上下文、token 消耗、决策路径。
- 从 Lost-in-the-Middle 开始优化。最简单的改进往往是最有效的：把关键信息放在上下文的开头和结尾。
- 拥抱 MCP。工具上下文的标准化是大势所趋。
- 建立三层记忆架构。即使是最简陋的版本——working memory（上下文窗口）+ episodic memory（对话摘要存储）+ semantic memory（文档向量库）——都比"把所有东西塞进 prompt"好一个量级。
Context Engineering 还是一个年轻的学科，很多基础问题还没有定论。但正因如此，这是一个充满机会的领域——理论和实践之间的鸿沟，正等着有能力的工程师来填补。
参考资源：Anthropic "Effective context engineering for AI agents"、Andrej Karpathy 的 X 帖文和 2025 Year in Review、Martin Fowler 网站 "Context Engineering for Coding Agents"、Weaviate "Context Engineering - LLM Memory and Retrieval"、ACE 论文 (arXiv:2510.04618)、SwirlAI "State of Context Engineering in 2026"、Phil Schmid "The New Skill in AI"、Faros AI "Context Engineering for Developers"、VentureBeat GAM 报道等。
本文写于 2026 年 3 月。Context Engineering 是一个快速演进的领域，具体技术细节请以最新资料为准。
