E3 · 如何管理模型的上下文窗口？ - Context Window

所属知识库：Agent 全栈技术地图
所属领域：01 · AI
所属章节：03 · 如何使用和管理 AI 模型？ - Model Engineering
文档类型：技术原理与工程实践研究
版本：v1.0
更新日期：2026 年 10 月 27 日
核心问题：什么是上下文窗口？Token、上下文长度、输出预算之间有什么关系？长对话为什么会遗忘、截断或变慢？如何使用截断、摘要、检索、缓存和结构化状态管理上下文？Context Engineering 与 Prompt Engineering 有何区别？长期运行的 Agent 应如何组织上下文？

专题导读

本篇将系统研究上下文窗口与 Token 预算、长上下文问题、截断与摘要、检索式上下文构建、KV Cache、Context Engineering，以及长期运行的 Agent 和多 Agent 系统中的上下文管理。

一、研究概述

在 E1 中，我们研究了如何通过 API 调用模型；在 E2 中，我们研究了如何设计模型输入。但一个关键工程问题尚未解决：模型每次究竟能够接收多少信息，以及哪些信息应该被放入本次请求？

假设一个研究 Agent 已经运行了三个小时，期间读取了几十篇文章、调用了多次搜索工具、生成了若干中间分析，并与用户进行了多轮讨论。此时，Agent 需要撰写最终报告。它不可能无条件地将所有历史文本都放入一次模型调用：上下文窗口有限，长输入有成本，信息越多也不一定越容易找到关键证据。

因此，上下文管理并非简单的“把聊天记录保存起来”，而是一个持续的工程决策过程：选择什么信息、以什么结构、在什么时刻、以多大篇幅提供给模型。

本篇将依次研究上下文窗口的技术基础、容量预算、长上下文限制、历史管理策略、检索与摘要、缓存、Agent 状态管理，以及可落地的 Context Engineering 架构。

1.1 研究目标

区分 Context、Context Window、Memory、Knowledge Base 和 KV Cache。
理解 Token 预算及输入、输出、工具和多模态内容如何共同占用容量。
认识长上下文的性能、质量与成本限制。
掌握滑动窗口、选择性保留、摘要压缩、检索增强和分层存储等方法。
建立适合多步骤 Agent 与多 Agent 系统的上下文构建流程。
形成可观测、可评估、可迭代的上下文管理方案。

1.2 研究边界

本篇关注模型调用时的信息组织与容量管理。Prompt 的写法详见 E2；外部知识检索详见 K4/K5；持久化记忆详见 A5；推理运行时缓存和性能详见 M7/E8。

二、什么是 Context？

2.1 Context 的基本定义

在语言模型中，Context（上下文）是模型生成当前输出时可以条件化使用的输入信息。对于自回归模型，可以抽象为：

P (y_{t} ∣ x, y_{< t}; θ)

其中， $x$ 是本次调用提供的上下文， $y_{< t}$ 是本轮已经生成的 Token， $θ$ 是模型参数。模型依据这些信息计算下一个 Token 的概率分布。

在实际应用中，上下文可能包含：系统与开发者指令、用户问题、对话历史、文档片段、检索结果、工具输出、任务状态、示例、图片或音频内容等。不同 API 可能将这些信息放在不同字段中，但它们都会影响模型处理当前任务的方式。

2.2 上下文不等于聊天记录

聊天记录只是上下文的一种来源。例如，研究 Agent 当前需要核对一份报告中的数据，它更需要的是数据来源、相关段落、当前草稿和核对规则，而不是三小时前所有闲聊内容。

因此，历史中出现过的信息，不等于当前必须进入上下文的信息。上下文构建应当围绕当前任务选择材料。

2.3 五个容易混淆的概念

概念	定义	主要解决的问题
Context	本次推理可使用的信息	模型现在依据什么作答
Context Window	模型一次推理可处理的序列容量限制	一次最多能容纳多少 Token
Conversation History	过去的消息与交互记录	发生过什么
Memory	跨轮次或跨任务保存、提取的有用状态	未来需要记住什么
Knowledge Base	可查询的外部知识集合	去哪里获取相关事实
KV Cache	推理运行时保存注意力 Key/Value 的计算缓存	如何减少重复计算

特别需要强调：KV Cache 不是 Agent 的长期记忆。它是模型推理的计算优化机制，通常不承担长期知识存储和语义检索职责。

三、什么是 Context Window？

3.1 定义

Context Window（上下文窗口）通常指模型在一次推理过程中能够处理的最大上下文序列长度，通常以 Token 计量。不同模型的限制不同，API 也可能额外规定单次最大输出 Token、文件大小或多模态输入限制。

一个常见的简化预算关系是：

N_{i n p u t} + N_{o u t p u t} \leq W

其中：

$N_{i n p u t}$ ：实际进入模型的输入 Token 数；
$N_{o u t p u t}$ ：本次生成占用的 Token 数；
$W$ ：模型或接口适用的上下文容量。

这只是理解预算的通用近似。某些服务对输入上限、输出上限、隐藏推理 Token、缓存内容和多模态内容有单独约束，必须以实际 API 规则为准。

3.2 为什么需要预留输出空间？

假设一个模型的总上下文预算为 128K Token，而任务需要生成约 8K Token 的报告。不能简单地将输入塞满 128K；至少应预留输出容量，还要考虑系统指令、工具定义、消息格式开销及安全余量。

概念上：

text

总上下文预算 W
├── 系统与开发者指令
├── 当前用户任务
├── 对话历史
├── 检索与工具内容
├── 其他消息/格式开销
├── 输出预算
└── 安全余量

工程上应按 Token 预算，而不是按“字数”预算。 同样长度的中文、英文、代码、表格或特殊符号，在不同 Tokenizer 下可能产生不同数量的 Token。

3.3 上下文窗口并不等于有效理解范围

模型声称支持很长的上下文，不代表它能同样可靠地使用其中每一个位置的信息。长上下文任务还会受到注意力分配、位置分布、训练数据特征、任务复杂度和干扰信息的影响。

因此需要区分：

可容纳长度：接口能够接受多少内容；
有效检索能力：能否找到长文本中的相关信息；
有效推理能力：能否跨多个远距离片段正确综合；
实际工程可用长度：在质量、延迟和成本约束下值得使用的长度。

四、Token 是如何影响上下文容量的？

4.1 Token 不是字、词或字符

Token 是模型 Tokenizer 划分的离散单元。一个 Token 可能对应一个词、一部分词、一个汉字或多个字符，具体取决于分词器。不能把“10 万字”直接等同于“10 万 Token”。

模型请求的总 Token 使用量还可能包括消息角色、分隔符、工具定义、结构化输出指令及多模态表示。计费 Token 与上下文占用的统计口径也可能存在服务商差异。

4.2 一个预算示例

假设某项任务的可用总预算为 64,000 Token，计划分配如下：

内容	预算 Token	作用
系统与任务规则	2,000	固定行为约束
当前问题与目标	1,000	本轮任务
近期对话	5,000	局部连续性
相关历史摘要	4,000	长期进展
检索证据	20,000	事实依据
中间状态与工具结果	6,000	当前工作状态
输出预留	16,000	报告生成
安全余量	10,000	格式与动态增长
合计	64,000

这不是固定配比，而是展示预算思维。实际应用应依据模型上限、输出任务、检索质量和调用成本动态调整。

4.3 上下文预算与成本预算不是一回事

即使请求没有超出上下文窗口，输入 Token 仍可能增加费用和延迟。反过来，较小的上下文也可能因大量输出、重复调用或高成本模型而产生较高费用。

因此，至少需要同时监控：

容量：是否会超出窗口；
质量：是否包含足够且相关的证据；
性能：首 Token 延迟和总体耗时；
成本：输入、输出与缓存 Token 的计费。

五、长上下文为什么会带来问题？

5.1 注意力计算与内存开销

对于标准全注意力机制，长度为 $n$ 的序列形成的注意力分数矩阵规模与 $n^{2}$ 相关；但实际推理的计算、显存和时间表现还受到 FlashAttention、分块计算、KV Cache、注意力变体及硬件实现影响，不能简单用 $O (n^{2})$ 直接推导所有服务的延迟。

在自回归解码时，KV Cache 避免了每生成一个 Token 就重复计算所有历史 Token 的 Key/Value，但缓存本身通常随序列长度增长，占用显存。

5.2 信息干扰

输入越长，可能包含越多：

与任务无关的材料；
重复或过时的事实；
相互矛盾的指令；
低可信度的工具输出；
与关键证据竞争注意力的内容。

长上下文管理的目标不是“尽量塞满”，而是提高有效信息密度。

5.3 Lost in the Middle

研究发现，部分语言模型在处理长输入时，对位于开头或结尾的信息可能表现较好，而对中间位置的信息利用较差。这种现象常被称为 Lost in the Middle。具体表现依模型、任务和输入组织而异，不能认为所有模型都会以相同方式出现。

工程启示是：关键任务、当前问题和高相关证据应当有清晰结构；重要事实不能只依赖其在长文档中自然出现的位置。

5.4 上下文污染与错误传播

如果历史中包含模型早先生成的错误判断，而后续请求不断将其当作事实复用，错误可能被放大。类似地，未经验证的网页片段、搜索摘要或工具输出也可能污染后续结论。

因此，系统应区分：原始证据、模型推断、用户确认、待验证假设和已废弃状态。

六、上下文管理的第一种方法：截断与滑动窗口

6.1 Truncation：截断

截断是指当上下文超过预算时，删除部分内容。最简单的方法是丢弃最早的消息，但这种策略容易删除任务目标、用户约束和关键决策。

6.2 Sliding Window：滑动窗口

滑动窗口只保留最近一定数量的消息或 Token。

text

历史：M1 → M2 → M3 → M4 → M5 → M6
保留：              M4 → M5 → M6

它适用于近期上下文重要、早期信息影响较小的场景，如一般聊天或短期交互。

6.3 为什么不能简单删除最早内容？

在长期项目中，最早的消息可能包含：

项目目标；
用户明确的禁止事项；
已确认的技术路线；
输出验收标准。

如果这些信息被删除，模型可能失去任务约束。

6.4 分层保留策略

更实用的方式是按重要性分类：

text

固定保留
├── 系统与安全约束
├── 当前任务目标
└── 用户确认的关键要求

动态保留
├── 最近对话
├── 当前步骤相关资料
└── 必要工具结果

可压缩或移出
├── 旧对话细节
├── 重复内容
└── 低相关材料

截断是一种容量控制措施，但不应成为唯一的上下文管理机制。

七、第二种方法：摘要与压缩

7.1 Summarization：摘要

摘要通过较短文本保留较长历史的核心信息。例如将 20,000 Token 的对话整理为 2,000 Token 的阶段摘要。

text

长对话历史
    │
    ▼
摘要模型/摘要步骤
    │
    ▼
关键事实、决策、待办、约束
    │
    ▼
后续模型调用

7.2 什么信息应该进入摘要？

对于项目型 Agent，建议保留：

目标：正在完成什么；
决策：已经确认什么；
约束：不能改变什么；
进度：已经完成哪些步骤；
证据：关键事实来自哪里；
问题：尚未解决什么；
下一步：应继续做什么。

相比“我们讨论了很多关于项目的内容”，这样的结构化摘要更有操作价值。

7.3 结构化摘要示例

yaml

project: 行业研究报告
objective: 完成市场竞争格局分析
confirmed_decisions:
  - 采用企业规模和产品类型两个分析维度
constraints:
  - 结论必须有可追溯来源
  - 不得使用未经验证的市场规模数字
completed:
  - 收集主要竞争者名单
pending:
  - 核实各企业的产品定位
  - 完成竞争矩阵
sources:
  - id: source-17
    topic: 主要竞争者
open_questions:
  - 是否需要按地区拆分市场

7.4 摘要的主要风险

摘要是一种有损压缩。它可能：

删除后续需要的细节；
错误概括用户意图；
把推测写成事实；
丢失来源和时间信息；
在多次摘要后累积偏差。

因此，重要项目不应只保存摘要而丢弃原始记录。更稳妥的方式是：原文持久保存，摘要用于快速恢复，必要时回查原文。

7.5 何时触发摘要？

常见触发条件包括：

历史 Token 达到阈值；
任务阶段结束；
用户确认重要决策；
工具调用产生大量结果；
会话即将转移到新执行环境。

八、第三种方法：检索式上下文构建

8.1 从“携带全部历史”转向“按需取回”

如果一个 Agent 需要处理上百份文档，将所有文档始终放入上下文通常不合理。更适合的方式是将资料保存在外部存储中，并在需要时检索相关片段。

text

用户任务
   │
   ▼
查询构建
   │
   ▼
文档/记忆检索
   │
   ▼
相关片段排序与筛选
   │
   ▼
上下文组装
   │
   ▼
模型生成

这也是 RAG 的核心思想之一，但上下文检索不局限于知识问答，也可以检索历史决策、任务状态、代码文件和工具结果。

8.2 检索的常见方式

关键词检索：适合精确术语、文件名和编号；
向量检索：适合语义相关性匹配；
混合检索：结合关键词与向量结果；
元数据过滤：根据项目、时间、类型或权限缩小范围；
重排序（Reranking）：进一步判断候选内容与当前问题的相关性。

8.3 Chunking：文档分块

长文档通常需要切分为可检索的片段。块过小可能丢失语境，块过大则增加无关内容和 Token 成本。分块策略应结合文档结构，例如按标题、段落、章节或语义边界切分，并保留来源位置。

8.4 检索结果应附带什么？

除了正文，最好包含：

json

{
  "source_id": "doc-042",
  "title": "市场调研报告",
  "section": "3.2 竞争格局",
  "retrieved_at": "2026-10-27",
  "content": "……"
}

这些字段帮助模型和应用区分证据来源、定位原文并判断信息是否过时。

8.5 检索不等于正确

检索系统可能漏掉关键内容、找到错误片段或返回过时资料。因此需要评估检索召回率、相关性、证据覆盖度与来源可信度，并在高风险任务中进行事实核验。

九、第四种方法：结构化状态管理

9.1 为什么需要独立于对话的状态？

在 Agent 中，许多信息具有明确的业务含义，例如：当前任务阶段、待执行操作、审批结果、文件路径和已确认参数。这些信息如果只存在于自然语言聊天记录中，容易被模型忽略或错误改写。

因此，应将关键状态存入结构化数据，由应用程序维护。

9.2 示例：研究任务状态

json

{
  "task_id": "research-001",
  "phase": "analysis",
  "status": "in_progress",
  "approved_topic": "工业软件市场研究",
  "completed_steps": ["topic_selection", "source_collection"],
  "pending_steps": ["competitor_analysis", "report_draft"],
  "source_ids": ["doc-017", "doc-042"],
  "review_required": true
}

这些字段可以由工作流引擎、数据库或状态管理组件维护，不必依赖模型“记住”。

9.3 状态与上下文的关系

状态是持久的事实记录，上下文是当前推理所需的信息视图。

例如，数据库保存了 100 个任务字段，但当前模型只需知道“当前阶段是竞争分析、已收集 12 家企业、尚有 3 家待核验”。上下文构建器可以从完整状态中提取必要字段。

9.4 事件日志与检查点

长期运行的 Agent 可以保存：

Event Log：每一步发生了什么；
Checkpoint：某个时刻的完整或必要状态；
Artifact：阶段性产出物；
Summary：供模型快速理解的阶段摘要。

这种设计既支持任务恢复，也避免把所有历史事件重复送入模型。

十、第五种方法：Prompt Caching 与 KV Cache

10.1 Prompt Caching 是什么？

一些模型服务提供 Prompt Caching（提示词缓存），对重复使用的输入前缀进行缓存或复用，以减少重复处理成本或延迟。具体命中条件、缓存生命周期、计费方式及支持范围取决于服务商。

典型场景：多个请求共享相同的长系统指令或固定文档前缀。

text

请求 A：固定指令 + 文档资料 + 问题 A
请求 B：固定指令 + 文档资料 + 问题 B
                  ▲
              可复用前缀

10.2 KV Cache 是什么？

在 Transformer 自回归推理中，KV Cache 保存先前 Token 在各层注意力计算中的 Key/Value 表示，以避免生成后续 Token 时重复计算这些表示。

对于典型、未压缩的 KV Cache，其显存占用可近似写为：

M_{K V} \approx 2 \times L \times B \times S \times H_{k v} \times D_{h e a d} \times b

其中：

$L$ ：Transformer 层数；
$B$ ：批量大小；
$S$ ：缓存序列长度；
$H_{k v}$ ：KV 注意力头数量；
$D_{h e a d}$ ：每个头的维度；
$b$ ：每个元素的字节数。

这个公式不包含所有实际运行时开销，也不适用于所有注意力架构。

10.3 二者与 Memory 的区别

机制	保存内容	主要目的	是否可作为长期记忆
Prompt Caching	可复用输入前缀的计算结果或相关缓存	降低重复处理开销	通常不能
KV Cache	注意力计算的 Key/Value	加速自回归解码	不能直接替代
Agent Memory	事实、偏好、经验、任务状态等	跨轮次或跨任务复用信息	可以

缓存优化的是计算过程，记忆管理的是信息生命周期。两者可以同时使用，但不应混为一谈。

十一、什么是 Context Engineering？

11.1 从 Prompt Engineering 到 Context Engineering

Prompt Engineering 主要关注如何表达任务与指令。Context Engineering 的关注范围更广：如何在每一次模型调用前，动态构建最有用的完整输入环境。

它不仅包括提示词文本，还包括：

历史信息选择；
检索结果筛选；
工具输出处理；
任务状态注入；
Token 预算分配；
来源和可信度标记；
上下文更新与过期处理。

11.2 两者对比

维度	Prompt Engineering	Context Engineering
主要对象	指令和提示词设计	完整模型输入的构建
典型内容	角色、任务、约束、示例	Prompt、历史、证据、状态、工具结果
更新方式	模板版本与变量填充	每轮动态选择和组装
关键目标	让模型理解如何执行	让模型获得当前最需要的信息
工程重点	模板、测试、评估	检索、预算、压缩、状态与来源管理

二者是互补关系。Prompt 是 Context 的重要组成部分，但不是全部。

11.3 Context Builder 架构

text

                  当前任务
                     │
                     ▼
              Context Builder
                     │
      ┌──────────────┼───────────────┐
      │              │               │
      ▼              ▼               ▼
 Prompt Registry  State Store   Retrieval Service
      │              │               │
      └──────────────┼───────────────┘
                     ▼
              Relevance Filter
                     │
                     ▼
               Token Budgeter
                     │
                     ▼
               Context Package
                     │
                     ▼
                  Model API

这里的 Context Builder 是概念性组件，可以作为独立服务，也可以直接集成到 Agent Runtime。

十二、如何为 Agent 构建每一轮上下文？

12.1 建议采用七步流程

步骤一：确定当前任务。 明确这一轮模型调用需要解决什么，而不是笼统地复述整个项目。

步骤二：读取固定规则。 加载必要的系统指令、任务规范、工具权限说明和输出契约。

步骤三：读取结构化状态。 获取当前阶段、已确认决策、待办事项和上一步结果。

步骤四：检索相关信息。 从文档、知识库、历史事件和记忆中查找必要证据。

步骤五：筛选与压缩。 删除重复、低相关和过时内容，必要时摘要，但保留来源引用。

步骤六：分配 Token 预算。 为输入、输出、工具结果和安全余量保留空间。

步骤七：组装并验证。 检查是否存在缺失变量、冲突指令、越权内容和超长输入，再发送给模型。

12.2 一个 Context Package 示例

yaml

request:
  task: 分析三家竞争企业的产品定位差异
  output: 对比表与结论摘要

instructions:
  - 仅使用提供的证据
  - 区分事实与推断
  - 证据不足时明确说明

state:
  phase: competitor_analysis
  confirmed_companies: [企业A, 企业B, 企业C]

recent_context:
  - 用户确认以产品功能和客户群体为比较维度

evidence:
  - source_id: doc-011
    company: 企业A
    excerpt: "……"
  - source_id: doc-024
    company: 企业B
    excerpt: "……"

budget:
  max_input_tokens: 12000
  reserved_output_tokens: 4000

该结构是上下文构建器的内部数据示例。最终发给模型时，需要转换成对应 API 支持的消息格式。

12.3 工具结果如何进入上下文？

工具结果不应一律原样追加。例如，搜索工具返回 50 条网页摘要，真正相关的可能只有 5 条。上下文构建器应先进行去重、筛选和来源标注，再提供给模型。

如果工具返回的是结构化数据，例如数据库查询结果，优先保留必要字段和数据类型，而不是转写成冗长自然语言。

十三、长期运行的 Agent 如何避免“失忆”？

13.1 三层信息模型

可以将长期任务的信息划分为三层：

工作上下文（Working Context）：本轮调用直接需要的内容，生命周期短，受到窗口限制。

任务记忆（Task Memory）：当前项目中的决策、进度、关键事实和待办，跨多轮调用保留。

长期知识（Long-term Knowledge）：跨项目可复用的知识、文档和经验，通常存储在数据库或知识库中。

text

                Model Call
                    ▲
                    │
             Working Context
                    ▲
                    │
               Context Builder
                 ▲       ▲
                 │       │
            Task Memory  Knowledge Base

13.2 重要信息的写入策略

不应将每条对话都自动视为值得长期保存的记忆。可优先保存：

用户明确确认的决策；
长期有效的约束；
已验证的关键事实；
项目阶段性成果；
后续行动需要的参数。

对未经验证的推测，应保留其不确定性标签。

13.3 信息更新与冲突

长期任务中，决策可能发生变化。例如，用户先选择 A 方案，后来改为 B 方案。系统不能把两个方案都当作当前有效要求。

可以为状态记录增加：

json

{
  "field": "selected_plan",
  "value": "B",
  "status": "confirmed",
  "updated_at": "2026-10-27",
  "supersedes": "decision-014"
}

这样可以追踪决策演变，避免旧信息污染当前上下文。

13.4 会话恢复

当 Agent 中断后恢复运行，优先读取：

当前任务状态；
最近检查点；
已确认决策；
未完成操作；
必要的原始资料引用。

随后重新构建工作上下文，而不是依赖一段无限增长的历史消息。

十四、多 Agent 系统中的上下文管理

14.1 为什么不应让所有 Agent 共享全部上下文？

不同 Agent 承担不同职责。研究 Agent 需要原始资料；写作 Agent 需要研究结论与写作规范；审核 Agent 需要稿件、证据和评价标准。让每个 Agent 都读取全部历史，会增加成本与干扰，也可能扩大敏感信息暴露范围。

14.2 按职责分配上下文

text

                 Shared Project State
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
     Research Agent  Writing Agent  Review Agent
          │              │              │
     来源与检索      结构化发现       草稿与证据
          │              │              │
          └──────────────┼──────────────┘
                         ▼
                  Updated Project State

14.3 Agent 之间应传递什么？

比起转发完整聊天记录，更适合传递结构化交接包（Handoff Package）：

yaml

from: ResearchAgent
to: WritingAgent
task: 撰写竞争格局章节
findings:
  - claim: 企业A主要面向中型制造企业
    source_id: doc-011
  - claim: 企业B提供更广泛的集成接口
    source_id: doc-024
uncertainties:
  - 企业C的最新定价尚未核实
required_output:
  - 章节正文
  - 引用列表

这样可以提高信息可追溯性，也便于审核 Agent 检查结论依据。

14.4 权限与隔离

共享上下文不意味着共享全部权限。多 Agent 系统应根据职责限制数据读取范围，并在工具执行层实施权限控制。Prompt 中的“不要访问敏感信息”不能代替真正的访问控制。

十五、上下文管理的常见失败模式

失败模式	典型表现	改进方向
Context Overflow	请求超过模型限制	Token 预算、压缩与截断
Context Dilution	相关证据被大量无关内容淹没	相关性筛选、去重、重排序
Lost in the Middle	长文中间的关键信息未被正确使用	结构化组织、分段处理、针对性检索
Context Drift	历史目标与当前目标不一致	维护当前有效状态与决策版本
Summary Loss	摘要遗漏关键细节	原文保留、来源链接、摘要校验
Stale Context	使用过期资料	时间戳、有效期、重新检索
Tool-output Flooding	工具返回内容过长	工具结果裁剪、结构化提取
Prompt Injection	不可信资料试图覆盖指令	信任边界、权限控制、验证
Cost Explosion	每轮重复发送大量历史	缓存、检索、压缩、分层存储
Cross-agent Leakage	无关 Agent 接触不应读取的信息	按角色过滤上下文和权限

这些问题往往同时出现。例如，简单地扩大上下文窗口可能缓解溢出，却不能解决信息过时、证据冲突和权限边界问题。

十六、如何评估 Context Engineering 的效果？

16.1 不应只测 Token 数量

压缩后的上下文更短，不代表更好。真正的目标是用合理成本完成任务，因此需要同时评估质量、效率和可靠性。

16.2 关键指标

指标	核心问题
Context Utilization	实际使用了多少上下文预算？
Relevant Evidence Coverage	关键证据是否被纳入？
Retrieval Recall	必要材料是否被检索到？
Answer Groundedness	结论是否得到证据支持？
State Consistency	是否遵守最新确认的状态？
Context Freshness	是否使用了过期资料？
Token Cost	单任务消耗多少 Token？
Latency	上下文构建和推理耗时多少？
Recovery Success	中断恢复后能否继续正确执行？
Injection Resistance	不可信内容能否诱导越权行为？

16.3 设计对照实验

可以比较三种方案：

方案 A：完整历史直接拼接；
方案 B：近期历史 + 阶段摘要；
方案 C：结构化状态 + 按需检索 + 近期历史。

使用同一批任务评估成功率、证据准确率、延迟和成本。这样才能判断复杂的上下文管理架构是否真正创造价值。

16.4 回归测试

建议测试以下场景：

早期明确的用户约束在长对话后仍有效；
新决策能够覆盖旧决策；
摘要后仍能找到关键来源；
检索不到资料时不会编造证据；
工具返回恶意指令时不会执行越权操作；
会话中断后能够恢复正确任务状态。

十七、一个完整案例：研究 Agent 的上下文生命周期

假设系统需要完成《某行业竞争格局研究报告》。

阶段一：任务启动

用户提供研究目标和报告要求。系统保存：

text

任务目标：研究行业竞争格局
输出形式：完整研究报告
约束：重要结论必须可追溯

模型首轮上下文主要包括任务规则、用户目标和当前计划。

阶段二：资料收集

Agent 搜索并读取 30 份资料。原始文档保存到知识库或文件存储，检索元数据包含来源和时间。此时不应将全部文档长期堆积在对话中。

阶段三：竞争分析

Context Builder 根据“比较主要企业的产品定位”这一子任务，检索 8 个高相关片段，并结合当前任务状态构建输入。模型生成分析后，系统保存结论、证据 ID 和待验证事项。

阶段四：用户修改方向

用户要求将重点从“产品定位”调整为“商业模式”。系统更新当前目标，并将旧目标标记为已被替代。后续上下文使用最新状态，不再默认沿用旧分析重点。

阶段五：报告写作

写作 Agent 接收：报告结构、已确认结论、相关证据、写作规范，而不是全部搜索日志。模型逐章生成内容，应用保存草稿和引用关系。

阶段六：审核与返工

审核 Agent 获得当前章节、相关来源、验收标准和已知不确定性。审核结果以结构化问题列表返回写作 Agent，必要时重新检索原始证据。

阶段七：中断恢复

系统从任务状态、检查点、已完成章节和待办列表恢复。模型不需要重新阅读此前所有聊天记录，也能继续下一步。

这一案例体现的核心原则是：原始信息持久存储，任务状态结构化管理，模型上下文按需构建。

十八、实践中的选型建议

场景	优先策略	需要注意
简短问答	直接输入必要上下文	避免过度工程化
普通多轮聊天	最近消息 + 必要摘要	保留长期约束
长文档问答	分块检索 + 来源引用	检索遗漏与片段断章取义
大篇幅文档总结	分章节处理 + 分层汇总	摘要误差累积
长期项目 Agent	结构化状态 + 检索 + 检查点	决策版本与恢复机制
多 Agent 协作	共享状态 + 专用交接包	权限与信息隔离
高频重复请求	稳定前缀 + 缓存	命中规则和缓存成本
高风险任务	证据追溯 + 程序化验证	不以模型自检代替审查

18.1 推荐的最小可用实现

对于刚开始构建 Agent 的项目，不必一开始就部署复杂的向量数据库和记忆系统。可以按以下顺序演进：

V1：基础上下文管理。 保存完整消息历史，设置 Token 预算，保留系统规则和近期对话。

V2：摘要与状态。 引入阶段摘要、已确认决策、任务进度和待办字段。

V3：按需检索。 将长文档和历史产出移出当前上下文，通过检索取回。

V4：工程化治理。 加入来源追踪、版本控制、权限隔离、缓存、评估和监控。

每一阶段都应以实际任务的质量和成本指标验证收益。

十九、核心结论

Context 是模型当前推理可使用的信息，Context Window 是其容量限制。 两者不是同一个概念。
上下文窗口以 Token 衡量。 输入、输出、消息格式和多模态内容都可能影响预算。
更长的窗口不自动带来更好的结果。 信息干扰、位置效应、成本和延迟仍然重要。
截断和滑动窗口是基础措施。 长期任务还需要摘要、检索和结构化状态。
摘要是有损压缩。 应保留原始记录及可追溯来源。
检索式构建使模型按需获得信息。 但检索本身需要质量评估。
KV Cache 和 Prompt Caching 优化计算复用，不等于 Agent Memory。
Context Engineering 比 Prompt Engineering 覆盖范围更广。 它管理完整输入环境的动态构建。
长期 Agent 应将状态与对话分离。 关键决策、进度和产出应由持久化系统维护。
多 Agent 不应无差别共享全部上下文。 应按职责提供相关信息，并实施权限隔离。
上下文质量需要被测试。 评价指标应覆盖证据、任务正确性、状态一致性、延迟和成本。

最终可以将上下文管理归纳为一个工程公式：

有效上下文 = 当前任务需要的指令 + 可信且相关的证据 + 最新有效状态 + 必要历史信息 − 冗余、过时与无关内容。

这不是数学上的精确等式，而是 Context Engineering 的设计原则：让模型在有限的窗口中获得足以完成当前任务的信息，而不是获得尽可能多的信息。

二十、参考资料与延伸阅读

20.1 长上下文与信息利用

[1] Liu et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. 研究长上下文中信息位置对模型表现的影响。
论文原文

[2] Vaswani et al. (2017). Attention Is All You Need. Transformer 注意力架构的基础论文。
论文原文

[3] Dao et al. (2022). FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness. 研究高效注意力计算。
论文原文

20.2 检索、记忆与上下文管理

[4] Lewis et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. RAG 基础研究。
论文原文

[5] Packer et al. (2023). MemGPT: Towards LLMs as Operating Systems. 探讨通过分层记忆管理扩展 LLM 应用的有效上下文。
论文原文

[6] Anthropic. Context Windows. 模型上下文窗口的官方说明与使用注意事项。
官方文档

20.3 缓存与推理系统

[7] Kwon et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. 研究推理服务中的 KV Cache 内存管理。
论文原文

[8] OpenAI. Prompt Caching. 模型 API 中重复输入前缀缓存的相关机制。
官方文档

[9] OpenAI. Counting Tokens. 介绍 Token 计数及相关工具。
官方文档

二十一、关联研究

关联文档	研究内容
M3 · Transformer 如何处理和生成信息？	注意力机制与序列处理
M7 · AI 模型如何生成输出？	KV Cache、Prefill 与 Decode
E1 · 如何通过 API 调用 AI 模型？	请求结构与 Token 使用量
E2 · 如何设计和管理模型输入？	Prompt Engineering
E4 · 如何让模型生成结构化结果？	Structured Outputs
E5 · 如何让模型调用外部工具？	工具输出进入上下文
E8 · 如何优化模型推理的性能与成本？	缓存与推理优化
K4 · AI 如何检索外部信息？	Information Retrieval
K5 · 什么是 RAG？它如何工作？	Retrieval-Augmented Generation
A4 · Agent 如何理解和管理当前上下文？	Agent Context
A5 · Agent 如何形成和使用记忆？	Agent Memory
L4 · Agent System 如何运行 Agent？	Agent Engine
L5 · 多 Agent 如何协作与编排？	Orchestration & Collaboration

E3 · 如何管理模型的上下文窗口？ - Context Window ​

专题导读 ​

一、研究概述 ​

1.1 研究目标 ​

1.2 研究边界 ​

二、什么是 Context？ ​

2.1 Context 的基本定义 ​

2.2 上下文不等于聊天记录 ​

2.3 五个容易混淆的概念 ​

三、什么是 Context Window？ ​

3.1 定义 ​

3.2 为什么需要预留输出空间？ ​

3.3 上下文窗口并不等于有效理解范围 ​

四、Token 是如何影响上下文容量的？ ​

4.1 Token 不是字、词或字符 ​

4.2 一个预算示例 ​

4.3 上下文预算与成本预算不是一回事 ​

五、长上下文为什么会带来问题？ ​

5.1 注意力计算与内存开销 ​

5.2 信息干扰 ​

5.3 Lost in the Middle ​

5.4 上下文污染与错误传播 ​

六、上下文管理的第一种方法：截断与滑动窗口 ​

6.1 Truncation：截断 ​

6.2 Sliding Window：滑动窗口 ​

6.3 为什么不能简单删除最早内容？ ​

6.4 分层保留策略 ​

七、第二种方法：摘要与压缩 ​

7.1 Summarization：摘要 ​

7.2 什么信息应该进入摘要？ ​

7.3 结构化摘要示例 ​

7.4 摘要的主要风险 ​

7.5 何时触发摘要？ ​

八、第三种方法：检索式上下文构建 ​

8.1 从“携带全部历史”转向“按需取回” ​

8.2 检索的常见方式 ​

8.3 Chunking：文档分块 ​

8.4 检索结果应附带什么？ ​

8.5 检索不等于正确 ​

九、第四种方法：结构化状态管理 ​

9.1 为什么需要独立于对话的状态？ ​

9.2 示例：研究任务状态 ​

9.3 状态与上下文的关系 ​

9.4 事件日志与检查点 ​

十、第五种方法：Prompt Caching 与 KV Cache ​

10.1 Prompt Caching 是什么？ ​

10.2 KV Cache 是什么？ ​

10.3 二者与 Memory 的区别 ​

十一、什么是 Context Engineering？ ​

11.1 从 Prompt Engineering 到 Context Engineering ​

11.2 两者对比 ​

11.3 Context Builder 架构 ​

十二、如何为 Agent 构建每一轮上下文？ ​

12.1 建议采用七步流程 ​

12.2 一个 Context Package 示例 ​

12.3 工具结果如何进入上下文？ ​

十三、长期运行的 Agent 如何避免“失忆”？ ​

13.1 三层信息模型 ​

13.2 重要信息的写入策略 ​

13.3 信息更新与冲突 ​

13.4 会话恢复 ​

十四、多 Agent 系统中的上下文管理 ​

14.1 为什么不应让所有 Agent 共享全部上下文？ ​

14.2 按职责分配上下文 ​

14.3 Agent 之间应传递什么？ ​

14.4 权限与隔离 ​

十五、上下文管理的常见失败模式 ​

十六、如何评估 Context Engineering 的效果？ ​

16.1 不应只测 Token 数量 ​

16.2 关键指标 ​

16.3 设计对照实验 ​

16.4 回归测试 ​

十七、一个完整案例：研究 Agent 的上下文生命周期 ​

阶段一：任务启动 ​

阶段二：资料收集 ​

阶段三：竞争分析 ​

阶段四：用户修改方向 ​

阶段五：报告写作 ​

阶段六：审核与返工 ​

阶段七：中断恢复 ​

E3 · 如何管理模型的上下文窗口？ - Context Window

专题导读

一、研究概述

1.1 研究目标

1.2 研究边界

二、什么是 Context？

2.1 Context 的基本定义

2.2 上下文不等于聊天记录

2.3 五个容易混淆的概念

三、什么是 Context Window？

3.1 定义

3.2 为什么需要预留输出空间？

3.3 上下文窗口并不等于有效理解范围

四、Token 是如何影响上下文容量的？

4.1 Token 不是字、词或字符

4.2 一个预算示例

4.3 上下文预算与成本预算不是一回事

五、长上下文为什么会带来问题？

5.1 注意力计算与内存开销

5.2 信息干扰

5.3 Lost in the Middle

5.4 上下文污染与错误传播

六、上下文管理的第一种方法：截断与滑动窗口

6.1 Truncation：截断

6.2 Sliding Window：滑动窗口

6.3 为什么不能简单删除最早内容？

6.4 分层保留策略

七、第二种方法：摘要与压缩

7.1 Summarization：摘要

7.2 什么信息应该进入摘要？

7.3 结构化摘要示例

7.4 摘要的主要风险

7.5 何时触发摘要？

八、第三种方法：检索式上下文构建

8.1 从“携带全部历史”转向“按需取回”

8.2 检索的常见方式

8.3 Chunking：文档分块

8.4 检索结果应附带什么？

8.5 检索不等于正确

九、第四种方法：结构化状态管理

9.1 为什么需要独立于对话的状态？

9.2 示例：研究任务状态

9.3 状态与上下文的关系

9.4 事件日志与检查点

十、第五种方法：Prompt Caching 与 KV Cache

10.1 Prompt Caching 是什么？

10.2 KV Cache 是什么？

10.3 二者与 Memory 的区别

十一、什么是 Context Engineering？

11.1 从 Prompt Engineering 到 Context Engineering

11.2 两者对比

11.3 Context Builder 架构

十二、如何为 Agent 构建每一轮上下文？

12.1 建议采用七步流程

12.2 一个 Context Package 示例

12.3 工具结果如何进入上下文？

十三、长期运行的 Agent 如何避免“失忆”？

13.1 三层信息模型

13.2 重要信息的写入策略

13.3 信息更新与冲突

13.4 会话恢复

十四、多 Agent 系统中的上下文管理

14.1 为什么不应让所有 Agent 共享全部上下文？

14.2 按职责分配上下文

14.3 Agent 之间应传递什么？

14.4 权限与隔离

十五、上下文管理的常见失败模式

十六、如何评估 Context Engineering 的效果？

16.1 不应只测 Token 数量

16.2 关键指标

16.3 设计对照实验

16.4 回归测试

十七、一个完整案例：研究 Agent 的上下文生命周期

阶段一：任务启动

阶段二：资料收集

阶段三：竞争分析

阶段四：用户修改方向

阶段五：报告写作

阶段六：审核与返工

阶段七：中断恢复