AI 智能体的上下文工程：实用指南（2026）
什么是上下文工程、它与提示词工程（prompt engineering）有何不同、四大核心技术、主流框架的对比、如何衡量其效果，以及如何在多智能体系统中应用。
An AI agent 的表现只取决于它决定下一步行动那一刻上下文窗口中的信息——而如何筛选这些信息正是整个游戏的关键所在。如果说 prompt engineering 是写出一条好的指令，那么 context engineering 就是管理模型所处的整个信息环境：系统指令、工具、检索到的文档、记忆，以及任务运行中的历史记录。 随着 agent 承担越来越长、多步骤的工作，这已成为决定它们成功还是悄然崩溃的最大杠杆。本指南将介绍什么是 context engineering、它与 prompt engineering 有何不同、核心技术有哪些，以及如何在真实的 agent 系统中应用它。
为什么 Context Engineering 很重要
Context engineering 之所以重要，是因为大语言模型拥有有限的上下文窗口，而你如何填充这个窗口决定了 agent 每一次决策的质量。模型的表现只取决于摆在它面前的信息——给得太少它会产生幻觉；给得太多或给错类型，它的准确性就会下降。
这并非纸上谈兵的担忧。研究人员已经记录了一种"迷失在中间"效应，模型能可靠地使用长上下文开头和结尾的信息，却容易忽略埋藏在中间的事实。从业者们还描述了一个相关问题，他们称之为"上下文腐化"（context rot）：随着对话或 agent 运行时间变长，不相关的 token 不断累积，信噪比下降，模型开始做出更差的选择。窗口本身并没有变小——只是变得杂乱了。
这种术语上的转变反映了实践中的真实转变。2025 年，AI 领域的领军人物——包括 Andrej Karpathy 和 Shopify 的 Tobi Lütke——都认为"context engineering"比"prompt engineering"更能准确描述那些真正在构建严肃 LLM 应用的人们实际在做的事情。Anthropic 发布了关于 agent 有效 context engineering 的指南；像 Manus 这样的 agent 产品团队也详细撰文，分享他们在生产环境中管理上下文所汲取的经验教训。业界共识是：对于 agentic 系统而言，context 就是产品本身。
什么是 Context Engineering？
Context engineering 是一门学科，专注于在推理时为模型组装恰到好处的一组 token，使模型恰好拥有采取下一个正确行动所需的信息——不多也不少。这里的"context"包含窗口内的一切：
- 系统指令 —— agent 的角色、约束条件和行为规则
- 工具及其定义 —— agent 可以采取哪些行动，以及这些行动是如何被描述的
- 检索到的知识 —— 为完成这项任务而拉取的文档、搜索结果或数据库记录
- 记忆 —— 从本次会话早期或之前会话中延续下来的事实
- 对话与行动历史 —— 已经说过和做过的事情的运行记录
- 当前用户请求 —— 眼下的目标
Context engineering 就是关于这些位置分别应该填入什么内容、以何种形式、在什么时机填入的一系列决策。它把上下文窗口视为一种稀缺的、需要精心管理的资源，而不是一个可以不断往里塞文本的容器。
上下文窗口是一种有限的注意力预算——context engineering 决定每个位置由什么填充。
Context Engineering 与 Prompt Engineering 的区别
Context engineering 与 prompt engineering 的区别在于范围：prompt engineering 优化单条指令，而 context engineering 管理跨越多步骤任务的整个动态信息环境。Prompt engineering 是 context engineering 的一个子集。
| Prompt engineering | Context engineering | |
|---|---|---|
| 范围 | 单条 prompt / 指令 | 随时间演变的整个上下文窗口 |
| 状态 | 大多无状态、一次性 | 有状态，随多个步骤演变 |
| 关注点 | 措辞、示例、格式 | 包含什么、检索什么、记住什么、丢弃什么 |
| 典型用途 | 单次补全或单轮对话 | 自主 agent、长时间运行的任务 |
| 它能防止的失败 | 指令模糊或被误读 | 上下文腐化、注意力分散、状态矛盾 |
Prompt engineering 依然重要——一条措辞精良的系统 prompt 本身就是良好 context engineering 的一部分。但一旦 agent 运行数十个步骤、调用工具、积累历史记录，任何单条 prompt 的措辞就不再是瓶颈了。真正重要的是管理其周围一切的那套纪律。
四项核心技术
大部分 context engineering 的工作都可以归结为对上下文窗口的四种操作。一个便于记忆的方式是：写入（write）、选取（select）、压缩（compress）、隔离（isolate）。
写入、选取、压缩、隔离——每一个 context engineering 决策背后的四种操作。
1. 写入 —— 在窗口之外持久化上下文
并非所有 agent 需要的信息都应该存在于 prompt 里。写入上下文意味着把信息存储在外部——草稿本、文件、记忆存储、任务列表——这样它就能超越单个窗口而存续，并在需要时被有意识地调取。一个把计划写入文件并重新读取的长时间运行 agent，比单纯依赖对话历史的 agent 更能保持任务方向。
2. 选取 —— 只引入当下相关的内容
选取上下文是一门艺术，在于在恰当的时刻检索出正确的信息：特定的文档、相关的过往决策、当前这一步所需的那一个工具定义。这正是检索增强生成（RAG）、语义搜索和智能工具选择发挥作用的地方。目标是精准——只拉取三个相关事实，而不是三百个相邻但无关的事实。
3. 压缩 —— 在保留信号的同时减少 token
压缩上下文意味着通过摘要或裁剪，让窗口承载意义而非冗余体量。常见做法包括对已完成的子任务进行摘要、截断冗长的工具输出，以及用精简的回顾替代冗长的历史记录。压缩正是让 agent 能够处理超出其原始上下文窗口容量的任务的关键。
4. 隔离 —— 跨 agent 或边界拆分上下文
隔离上下文意味着为问题的不同部分提供各自干净的窗口——例如，派生一个子 agent，只给它完成某个子任务所需的上下文，然后只返回结果。隔离能防止工作的一部分污染另一部分，是构建可靠多 agent 系统的基础。
各大主流框架如何对应
一个常见的困惑来源是：每个主要团队都用自己的一套词汇来描述相同的底层操作。Anthropic、LangChain 和像 Neo4j 这样的图数据库厂商，对 context engineering 的描述各不相同——但它们都能清晰地对应到上述四种操作。下表将它们进行了统一对照：
| 操作（本指南） | Anthropic 的表述 | LangChain 的表述 | 知识图谱 / GraphRAG 的表述 |
|---|---|---|---|
| 写入（在窗口之外持久化） | 结构化笔记记录、agent 记忆（NOTES.md、待办清单） | Store 和 State；通过 Command 写入的工具 | 长期记忆；图本身作为持久化存储 |
| 选取（检索当下相关的内容） | 即时（just-in-time）上下文、agentic 搜索、混合检索 | 动态工具/消息选择；用于读取的工具 | 混合 RAG、GraphRAG、"最小可行上下文" |
| 压缩（减少 token，保留信号） | 压缩（Compaction）；明智地使用"注意力预算" | 通过中间件实现的生命周期摘要 | Token/成本预算管理；"上下文金字塔" |
| 隔离（分离出干净的窗口） | 返回精炼摘要的子 agent 架构 | 生命周期边界与子 agent | 交接与协议（例如 MCP） |
如果你读过这些资料，觉得它们的说法互相矛盾，原因就在这里：它们只是从不同角度描述同样的四个动作。选用适合你的技术栈的词汇即可——真正重要的是这些操作本身。
多 Agent 系统中的 Context Engineering
在多 agent 系统中，context engineering 变成了一个协调问题：每个 agent 都需要足够的上下文来完成自己的工作，但共享过多会带来噪音、成本和相互矛盾的状态。主流模式是由一个编排者（orchestrator）持有高层计划，并将范围狭窄的子任务分派给专门的子 agent，每个子 agent 都在一个隔离的窗口中运行。
每个子 agent 都获得一个干净、隔离的窗口，并只返回精炼后的结果——从而防止交叉污染。
这之所以有效，正是因为上述"隔离"原则。一个只看得到研究问题及自身发现的研究子 agent，其表现会优于那个还要费力梳理兄弟 agent 无关编码任务历史的 agent。编排者随后会将每个子 agent 的输出压缩为核心结果，再将其纳入主上下文中。做得好的话，这正是团队能够让 agent 处理那些原本会数倍溢出任何单一上下文窗口的任务的方式。
常见的 Context Engineering 失败模式
大多数 agent 的失败都可以追溯到少数几种反复出现的上下文问题。把它们命名出来，会更便于针对性设计：
| 失败模式 | 表现形式 | 主要解决方法 |
|---|---|---|
| 上下文投毒（Context poisoning） | 一个幻觉或错误进入上下文后被一再引用，使错误不断累积 | 隔离 + 只写入已验证的事实 |
| 上下文分心（Context distraction） | 窗口变得过大，模型过度关注累积的历史，不再对真正的目标进行推理 | 压缩 |
| 上下文混乱（Context confusion） | 不相关的信息挤满窗口，误导模型做出错误选择 | 更精准地选取 |
| 上下文冲突（Context clash） | 新检索到的信息与窗口中已有的信息相矛盾，模型无法调和两者 | 选取 + 写入单一可信来源 |
四项核心技术正是应对这些问题的解药：通过写入来卸载信息，通过选取来保持相关性，通过压缩来削减杂乱，通过隔离来防止交叉污染。
有一种失败模式是主流指南很少涉及的，那就是一个安全问题：通过检索到的上下文进行的 prompt 注入。 当 agent 拉取一个网页、一份文档或一个工具结果时，这些内容可能包含旨在劫持 agent 的指令。应将所有被选取进窗口的内容都视为不可信输入——将检索到的数据与系统指令分开保存，并在沙盒中而非直接在可信机器上执行工具调用。
如何衡量 Context Engineering 是否奏效
衡量 context engineering 的方法，是将任务成功率与达成结果所耗费的 token 和时间对照来看——好的 context engineering 会在保持或降低成本的同时提高成功率。大多数指南只描述技术，却从不说明如何判断这些技术是否真的有效；以下这些指标正好填补了这一空白。
- 任务成功率 —— 达成正确、完整结果的运行比例。这是结果性指标；其他一切都只是达成它的手段。应针对一组固定的代表性任务集合来跟踪该指标，以便在每次改动前后进行对比。
- 上下文效率（每次成功任务消耗的 token 数） —— 消耗的总 token 数除以成功完成的任务数。每次成功所消耗的 token 数持续下降，是压缩和选取正在发挥作用的最清晰信号。
- 窗口利用率 —— 任务执行期间上下文窗口的填充程度。持续接近上限预示着上下文腐化，是需要进行压缩或隔离的先行指标。
- 检索精确率与召回率 —— 在被选入窗口的内容中，有多少确实是相关的（精确率）；在所有可用的相关内容中，你拉取进来了多少（召回率）。精确率低意味着你在增加噪音；召回率低意味着你在让模型"挨饿"。
- 每个任务的延迟与成本 —— 实际的上限。激进的"即时"探索式检索可以提升准确性，但会拖慢 agent 的速度；这个指标确保这种权衡是诚实可见的。
将这些指标串联起来的纪律是回归测试：保留一套固定的任务集合，在每次修改 prompt、检索方式或记忆机制后运行它，并观察这些数字的变化。没有评估闭环的 context engineering 只是在瞎猜。
Happycapy 如何应用 Context Engineering
Happycapy 是一台 agent-native 的计算机，直接在你的浏览器中运行 AI agent——包括 Claude Code——而 context engineering 被内建于这些 agent 的运作方式之中，而非留给用户自行处理。三个设计选择完成了大部分的工作：
- 将 Skills 作为范围受限的上下文。 Happycapy 不是把所有能力一股脑塞进一个 prompt，而是让 agent 调用某个特定的 skill——设计一份演示文稿、分析一张电子表格、进行网络研究——这样只有该任务所需的相关指令和工具会进入窗口。这正是"选取"和"隔离"原则的默认应用。
- 带记忆与文件的持久化沙盒。 每个 agent 都在一个隔离的工作空间中工作，可以把计划、中间结果和笔记写入磁盘，并在之后重新调取——这正是"写入"原则，让进度得以超越单个上下文窗口而存续。
- 可访问 150 多种模型。 不同步骤有不同的上下文需求；将工作路由到合适的模型本身就是一个 context engineering 决策。
实际效果是，你可以交办一项长期、多步骤的任务，让 agent 在后台自行管理其上下文，然后接收最终结果——无需手动调优 prompt，也无需时刻盯着窗口。
Context Engineering 入门指南
你不需要重建整个技术栈就能开始。从这些收益最高的习惯做起：
- 把上下文窗口当作预算来对待。 在添加任何内容之前，先问它是否值得占用这些 token。
- 把状态移出 prompt。 使用文件、草稿本或记忆存储来保存 agent 需要保留的一切。
- 精准检索。 只拉取某一步骤所需的具体事实，而不是整份文档。
- 随时进行摘要。 用简洁的回顾取代冗长的历史记录和啰嗦的工具输出。
- 隔离子任务。 为每个独立的工作提供各自干净的上下文，在多 agent 场景中尤其如此。
如果你不想手动调优这一切，Happycapy 运行你的任务时已经内建了这些模式：它会在后台自行管理上下文窗口——随时进行选取、压缩和隔离——所以你只需描述期望的结果，完全不用亲自处理 token 预算。
常见问题
问：Context engineering 和 prompt engineering 是一回事吗？
不是。Prompt engineering 优化单条指令；context engineering 管理 agent 在多步骤任务中所看到的整个信息环境——指令、工具、检索到的数据、记忆和历史记录。Prompt engineering 是 context engineering 的一部分。
问：为什么 context engineering 对 AI agent 尤其重要？
因为 agent 要运行许多步骤、调用工具、积累历史记录，它们的上下文窗口很快就会被填满。如果没有主动管理，不相关的 token 就会挤占信号，导致 agent 的决策质量下降——这个问题被称为上下文腐化。Context engineering 让窗口始终聚焦于真正重要的内容。
问：Context engineering 的主要技术有哪些？
四项核心技术是：写入（在窗口之外持久化上下文）、选取（只检索当下相关的内容）、压缩（通过摘要节省 token）、隔离（为子任务提供各自干净的上下文）。大多数实际工作都是这些技术的某种组合。
问：2026 年 context engineering 是否值得学习？
值得。随着越来越多的软件建立在 LLM 和自主 agent 之上，善于管理上下文的能力正在成为开发者、prompt 设计师和 AI 产品团队的核心竞争力——而且它越来越成为决定一个 agent 能否真正work的关键差异。
问：如何衡量 context engineering 是否奏效？
针对一组评估任务集合跟踪任务成功率，再加上效率指标：每次成功任务消耗的 token 数、上下文窗口利用率、检索的精确率与召回率，以及每个任务的延迟/成本。好的 context engineering 会在保持或降低成本的同时提高成功率。每次改动后都运行这套测试集，以便判断这次调整是有帮助还是有损害。
问：使用 AI agent 是否需要我自己动手做 context engineering？
不一定。像 Happycapy 这样的 agent 平台已经将上下文管理内建于系统之中——通过 skills 界定上下文范围、在沙盒中持久化状态、隔离子任务——因此你可以运行多步骤工作而无需手动调优上下文窗口。
