一、什么是上下文工程

1.如何理解上下文

上下文（Context）是提供给 LLM 的、用于完成下一步推理或生成任务的全部信息集合。是一个多维，动态，服务于特定任务的系统性概念。可以将上下文划分为三个核心类别：

• 指导性上下文（Guiding Context）：这类上下文的核心功能是指导模型该做什么以及如何做，主要为模型行为设定框架，目标和规则。
  • Prompt Engineering 一般旨在优化指导性上下文。它包括：System Prompt；Task Description；Few-shot Examples；Output Schema（前面三个很简单，Output Schema 一般是强制要求模型以特定格式（如 JSON、XML）输出的结构定义）
• 信息性上下文（Informational Context），这类上下文的核心功能是告诉模型需要知道什么知识，为模型提供解决问题所必备的事实，数据与知识。它包括：
  • RAG（外部知识库）；
  • Memory（Short-term Memory：当前对话历史，Long-term Memory：跨会话存储的一些重要信息和偏好）；
  • State / Scratchpad（状态维护和草稿纸，例如 Claude Code 在开始计划先的临时 TODO 以及 Thinking 模型下的思考“草稿本”）
• 行动性上下文（Actionable Context），这类上下文的核心功能是告诉模型能做什么以及做了之后的结果，为模型提供与外部世界交互的能力。它包括：Tool Definition；Tool Calls & Results / Tool Traces（调用了哪些工具以及工具返回的结果，即工具调用的历史追踪）

2.如何理解上下文工程

Context Engineering 是一门系统性学科，专注于设计、构建并维护一个动态系统，该系统负责在 Agent 执行任务的每一步，为其智能地组装出最优的上下文组合，以确保任务能够被可靠、高效地完成。
如果把 LLMs （或更广义的 Agentic System）视为一种新型操作系统，LLM 就像 CPU，而上下文窗口（Context Window） 就像 RAM（同样是容量有限，管理 CPU 所需要的内存）。上下文工程则是这个操作系统中的内存管理器。它的职责是通过复杂的调度算法，决定在每一个“时间周期”，哪些数据应该被加载、哪些应该被换出、哪些应该被优先处理，从而保证整个系统的流畅运行和最终结果的准确性。

二、为什么需要上下文工程

1.模型不及预期原因分析

当 agentic system 或单次 LLM 调用的输出不及预期时，问题的根源往往可以归结为两个方面：

• 模型能力局限： 基座模型自身的能力不足，需要对模型本身进行优化。
• 上下文信息缺失： 模型没有接收到生成高质量回复所需的恰当上下文。
  通常情况下（尤其是现在基础模型的智能已经超过一个阈值），输出不及预期的原因更多指向后者。即我们没有实现有效的上下文工程，导致模型缺失了一些解决问题的关键信息。

2 必要性分析

1. 缺少上下文

2. 上下文退化
   为了保证模型“无所不知”，系统将每一次交互都记录下来——每一条用户指令、文件读取、编译错误、成功的工具调用——并将这整段历史作为上下文，在每次调用 Agent 时都完整地传递给 LLM。 必然出现：

• 性能下降： 早期任务中无关紧要的细节（例如一次已解决的语法错误）会不断稀释当前步骤所需的核心信息，造成上下文干扰 (Context Distraction)
• 成本与延迟激增： 随着上下文线性增长，每次 API 调用的 Token 数量急剧膨胀，导致成本失控和更高的延迟
• 崩溃： 系统将撞上架构限制——上下文溢出 (Context Overflow)。当累积的信息总量超过模型的上下文窗口上限（无论是 200K 还是 1M tokens），API 调用将直接失败，可能导致任务中断，或因信息截断而引向错误的结果

同时，长上下文带来成本与协同压力，更易暴露四类上下文失效：污染、干扰、混淆、冲突。它们常彼此耦合，并直接损害推理稳定性与跨代理传递。

• 上下文污染：主要是幻觉进入 Context 导致异常结果
• 上下文干扰：当 Context 接近溢出时，模型训练中获得的知识会被“覆盖”导致模型降智
• 上下文混淆：冗余且不相关的 Context 让输出结果偏离期望
• 上下文冲突：当上下文中的信息互相矛盾时，比如上下文存在过去错误的答案。

通过建立一套系统性的方法论，来对上下文进行智能的、动态的写入（Write）、选取（Select）、压缩（Compress）和隔离（Isolate），仅将高价值的结论与信息注入上下文（相当一部分 token 是没有价值的分析），从而规避上述风险。

三、最佳实践

1. 写入：主要是将 上下文持续久化，超越上下文窗口的限制，在未来按需取用。通常情况下分为：

• 会话内写入：Agent 将中间思考、计划或临时数据写入一个会话内的草稿纸 。这是一种轻量级的、非持久化的写入，用于管理当前任务的复杂性。
• 持久化写入：系统将具有长期价值的信息（如用户偏好总结、关键事实）写入外部的记忆 系统，如向量数据库或知识图谱。这实现了跨会话的知识积累。例如，ChatGPT 和 Cursor 等应用通过这种方式，让 Agent 在与用户的持续交互中“学习”和“成长”，用户在解决某些问题时无需手动引入上下文。

2. 选取：目的是在每次 LLM 调用前，从所有可用的信息源中，动态地拉取与当前子任务最相关的信息。这是保证上下文信噪比的关键。上下文工程的中的选取包括三类：

• 确定性选取: 指根据预设规则加载上下文。例如，编码 Agent （Claude Code）在启动时，固定加载 项目根目录下的 CLAUDE.md 文件，这是一种简单高效的先验知识注入
• 模型驱动选取: 当可用信息源过多时（如海量工具或文档），可以利用模型自身的能力进行筛选
• 检索式选取: 这是最主流的方式，其核心范式是通过相似度检索，从记忆、草稿纸或外部知识库中选取信息。因此，选取操作的成败，在很大程度上依赖于底层检索系统的质量。

3. 压缩：目的是在信息进入上下文窗口之前，对其进行有损或无损的压缩，用更少的 Token 承载最核心的信号。
4. 隔离：是一种在系统架构层面进行的、更根本的上下文管理策略。隔离的目的，在多信息流之间设置边界，由子流程先行消化，仅上交要点。可视为跨流层面的‘压缩’。最经典的表现就是多智能体架构，由于 Lead Agent 只接收隔离上下文中最有价值的部分，可以很大程度的避免 Long Context 带来的潜在问题，例如 上下文干扰/上下文冲突，隔离也侧面提高了上下文中的信息密度。