Context Engineering
定义
Context Engineering，是指围绕 Agent 的上下文窗口进行系统化设计的方法，重点不是提示词的修辞技巧，而是管理“说什么、什么时候说、说多少”。在本文语境里，它被描述为比 Prompt Engineering 更底层的一层：Prompt Engineering 主要管“怎么说”，而 Context Engineering 管 Agent 实际获得哪些信息、这些信息何时进入上下文，以及一次放入多少内容才最有效。
它要解决的问题并不抽象，而是当前大模型 Agent 在长上下文使用中的现实痛点：虽然模型可用上下文窗口越来越大，例如文中举例的 Claude 约 200K、Gemini 约 2M，但“窗口大”不等于“上下文管理好”。如果把所有规则、历史、工具说明和任务资料一次性塞进去，模型仍可能出现中间信息记不住、关键信息被稀释、加载成本高、执行效率差等问题。文中将这种现象直接点名为 lost-in-the-middle。
在本文档中的语境
本文中的 Context Engineering 不是单独的一条提示技巧，而是 Agent [[Skills]] 体系中最底层、也最偏理论化的一支。原文提到的项目 Agent Skills for Context Engineering 没有刻意展示花哨功能，却因其对“Agent 的上下文窗口应该怎么管理”提出了成体系的方法而被强调，甚至被描述为“最学术，却最底层”。
在这个语境下，Context Engineering 的意义主要有五点：
- 它直接关注 Agent 应该接收哪些信息，而不是只优化一句提示词的表达；
- 它强调信息进入上下文的时机控制，即不是一次性全量灌入，而是按需加载；
- 它关注上下文容量管理，避免长上下文中信息稀释和中段遗失；
- 它为多 Agent 协作提供架构约束，决定不同 Agent 该共享什么、隔离什么；
- 它把记忆系统与工具使用原则连接起来，使 Agent 不只是“会调用工具”，而是知道何时把哪些记忆、规则和工具说明纳入当前推理环境。
因此，Context Engineering 可以视为连接 Agent Skills、Skill Engineering、记忆机制与工具调用设计的一类基础方法。
关键机制与组成
原文提到，相关 Skills 被分成四层，说明 Context Engineering 不是单一技巧，而是一组分层能力。
基础层（Foundation）
基础层关注 Agent 对上下文本身的理解和处理能力，包含至少三类核心问题：
- 理解上下文是什么：区分系统规则、任务说明、历史对话、检索材料、工具反馈、记忆片段等不同来源的信息；
- 会压缩上下文：不是机械删减，而是在保留任务所需关键信息的前提下进行摘要、提炼和裁剪；
- 能识别上下文失效：尤其是识别 lost-in-the-middle 这类长上下文问题，即重要信息位于中部时更容易被模型忽略。
这一层决定 Agent 是否具备“上下文卫生”能力。如果连哪些信息重要、哪些信息冗余都分不清，后续再复杂的工作流也会建立在低质量输入之上。
架构层（Architecture）
架构层强调上下文不是单 Agent 内部的小问题，而是系统设计问题。原文明确提到，这一层涉及：
- 多 Agent 协作设计；
- 记忆系统设计；
- 工具使用原则。
这意味着 Context Engineering 不只是优化一个 Prompt，而是在回答一组系统级问题：
- 多个 Agent 协作时，哪些上下文需要共享，哪些应局部保留；
- 长期记忆、短期工作记忆和当前任务上下文之间如何切分；
- 工具说明、调用结果和环境状态是否应常驻上下文，还是只在触发时注入。
从这里可以看出，Context Engineering 是记忆与工具使用之间的桥梁。没有这层设计，记忆会变成“堆资料”，工具调用会变成“函数很多但不知道何时用”。
运维层（Operations）
运维层关注运行中的效率和效果，原文给出的关键词是：
- 优化上下文；
- 评估 Agent 系统效果。
这意味着 Context Engineering 不是一次性写好就结束，而要在实际使用中持续观察：
- 当前注入的上下文是否过长；
- 是否存在大段说明从未被真正利用；
- 某类任务是否因为缺少中间信息而频繁失败；
- 上下文裁剪后是否影响结果质量；
- Skills 的按需加载是否比全量注入更高效。
原文还给出了一个非常具体的效率判断：如果 Agent 启动时只加载技能名称，消耗只是几十个 token；真正需要时再加载完整指令，才增加几百个 token。相比把所有说明一开始全部塞入提示中，这种按需加载方式被描述为可高效约 10 倍。这里体现的正是运维层思路：把上下文看成一种需要预算、调度和评估的资源。
认知层（Cognitive）
认知层是原文中最理论化的一层，提到要让 Agent 拥有“信念—欲望—意图”式结构。其含义不是把 Agent 神秘化，而是强调上下文组织不能只围绕输入材料堆叠，还要服务于 Agent 的目标理解、意图维持和行动选择。
换句话说，Context Engineering 在这一层开始关注：
- Agent 当前相信什么是事实；
- Agent 当前想达成什么目标；
- Agent 下一步准备采取什么行动。
如果这些状态不能被稳定地保留、更新和显式组织，Agent 即便有长窗口，也容易在多步骤任务中迷失目标。
为什么它重要
1. 它解决“长上下文够用但不会用”的问题
原文明确指出，模型上下文窗口在持续增大，但有效利用率并不高。问题不在于窗口绝对长度，而在于缺乏对上下文内容、顺序和时机的工程化管理。
因此，Context Engineering 的价值不是单纯追求更长输入，而是追求更高的信息利用率。它反对“能塞就塞”的思路，更强调：
- 不必要的信息不要进入当前上下文；
- 需要的信息要在需要时进入；
- 进入后要以模型更容易抓住的形式组织；
- 可延迟加载的说明不要抢占当前注意力。
2. 它直接缓解 lost-in-the-middle
原文把 lost-in-the-middle 视为 Context Engineering 要识别和应对的典型失效问题。所谓 lost-in-the-middle，是指模型在处理长上下文时，对中间部分的信息关注不足，导致真正关键的条件、约束或事实虽然已提供，却没有在输出中被正确利用。
Context Engineering 对此的基本应对不是一句“请仔细阅读”，而是结构性处理，例如：
- 压缩与重排重要信息；
- 把关键约束放到更容易被保留的位置；
- 将长材料拆为按步骤注入的上下文片段；
- 在任务阶段切换时重新注入当前最关键的信息。
这也是它区别于一般 Prompt Engineering 的地方：问题不只靠措辞修补，而要靠上下文编排解决。
3. 它提升上下文加载效率
原文给出的按需加载机制是 Context Engineering 的一个非常具体的实践模式。Agent 启动时不必把所有技能全文、规则全文、工具全文都加载进来，而可以只加载名称或简短索引；当某个任务真正触发某项能力时，再读入对应的完整说明。
这种做法至少带来三种收益：
- 降低初始 token 消耗；
- 减少无关说明对当前任务的干扰；
- 让同一个 Agent 能挂载更多能力，但不因全量注入而臃肿。
这也是 Agent Skills 之所以能在工程上成立的关键之一：Skill 可以作为按需注入的知识单元存在，而不是永远常驻提示词。
4. 它支撑多 Agent 协作
原文在架构层中直接把多 Agent 协作列为 Context Engineering 的组成部分，说明多 Agent 的关键难点并不只是“多开几个模型实例”，而是如何设计它们的上下文边界。
典型问题包括：
- 总控 Agent 应看到全局计划，执行 Agent 是否只应看到局部任务；
- 某个 Agent 生成的中间结论是否应原样共享给其他 Agent；
- 各 Agent 是否共享同一记忆池，还是按职责分层；