03c - 上下文窗口管理策略

本文是《AI Agent 实战手册》第 3 章第 3 节。上一节：规则文件编写指南 | 下一节：上下文工程实战清单

概述

每个 LLM 都有一个上下文窗口——它能在单次请求中处理的最大 token 数。从 GPT-4o 的 128K 到 Gemini 2.5 Pro 的 1M+，窗口越来越大，但”更大”不等于”更好”。研究表明，模型准确率在约 32K token 处就开始下降，中间位置的信息容易被忽略（“Lost in the Middle”效应）。本节讲解不同模型的上下文窗口特性，以及压缩、优先级、分块等实用管理策略。

1. 2026 年主流模型上下文窗口一览

工具推荐

模型	上下文窗口	有效窗口（推荐）	价格（输入/百万 token）	适用场景
Claude 4 Opus	200K	~130K	$15	复杂推理、长文档分析
Claude 4 Sonnet	200K	~130K	$3	日常编码、平衡性价比
GPT-4o	128K	~90K	$2.50	通用任务、多模态
GPT-4.5	128K	~90K	$75	深度推理（成本高）
Gemini 2.5 Pro	1M（2M beta）	~500K	$1.25（<200K）/ $2.50（>200K）	超长文档、大代码库
Gemini 2.5 Flash	1M	~500K	$0.15	高吞吐、成本敏感
DeepSeek V3	128K	~80K	$0.27	预算有限的编码任务
Qwen 3	128K	~80K	开源免费 / API 按量	自托管、中文场景

有效窗口：模型在该 token 数以内能保持较高准确率的实际范围。超过此范围，准确率可能显著下降。

关键认知：窗口大小 ≠ 有效利用


准确率
  ↑
  │ ████████████
  │ ████████████████
  │ ████████████████████
  │ ████████████████████████
  │ ████████████████████████████
  │ ████████████████████████████████
  │ ████████████████████████████████████▄▄▄▄
  │ ████████████████████████████████████████████▄▄▄▄▄▄
  └──────────────────────────────────────────────────────→ Token 数
       8K    32K    64K    128K    200K    500K    1M

  ← 高准确率区 →← 衰减区 →←  不可靠区  →

核心原则： 把上下文窗口当预算来管理——不是越多越好，而是每个 token 都要有价值。

2. 上下文窗口的四种失败模式

在管理策略之前，先理解上下文可能出什么问题：

失败模式	表现	原因	解决方向
中毒（Poisoning）	模型基于错误信息推理	过时或错误的数据混入上下文	信息验证、来源标注
干扰（Distraction）	模型忽略关键信息	无关信息过多，注意力被分散	信息筛选、优先级排序
混淆（Confusion）	模型输出格式混乱	上下文中格式不一致	统一格式、结构化输入
冲突（Clash）	模型行为不一致	不同来源的信息相互矛盾	去重、冲突检测

3. 六大管理策略

策略一：优先级排序（Prioritization）

不是所有信息都同等重要。按优先级分配上下文空间：

优先级金字塔：


        ┌─────────┐
        │ 系统指令 │  ← 最高优先级，始终保留
        │ 规则文件 │
        ├─────────┤
        │ 当前任务 │  ← 高优先级
        │ 相关代码 │
        ├─────────┤
        │ 项目文档 │  ← 中优先级
        │ API 规范 │
        ├─────────┤
        │ 对话历史 │  ← 低优先级，可压缩
        │ 参考资料 │
        └─────────┘

操作步骤：

系统指令和规则文件（~5-10% 窗口）：始终完整保留
当前任务直接相关的代码和文件（~40-50% 窗口）：完整包含
间接相关的上下文（~20-30% 窗口）：按相关度排序，截取最相关部分
对话历史和参考资料（~10-20% 窗口）：压缩或摘要

策略二：压缩（Compression）

当信息量超过窗口容量时，通过压缩保留核心内容。

压缩技术：

技术	方法	压缩比	适用场景
摘要压缩	用 LLM 生成对话/文档摘要	5-10x	长对话历史
选择性截取	只保留函数签名，去掉实现	3-5x	大型代码文件
关键信息提取	提取关键实体和关系	10-20x	长文档分析
滑动窗口	保留最近 N 轮对话	固定大小	多轮对话
分层摘要	越旧的信息压缩越狠	递增	超长会话

摘要压缩示例：


# 原始对话历史（~8000 tokens）
[20 轮关于用户认证模块的讨论...]

# 压缩后摘要（~500 tokens）
## 认证模块讨论摘要
- 决定使用 JWT + refresh token 方案
- token 过期时间：access 15min，refresh 7d
- 使用 bcrypt 哈希密码，cost factor 12
- 认证中间件放在 src/middleware/auth.ts
- 已完成：登录、注册 API
- 待完成：密码重置、OAuth 集成

策略三：分块（Chunking）

将大型输入拆分为可管理的块，按需加载。

分块策略：


大型代码库（100+ 文件）
    │
    ├── 第一步：加载项目结构概览（目录树 + README）
    │
    ├── 第二步：根据任务，加载相关模块的接口定义
    │
    ├── 第三步：加载需要修改的具体文件
    │
    └── 第四步：按需加载测试文件和文档

代码文件分块技巧：

大文件先加载函数签名和类型定义，需要时再加载完整实现
使用 AST 解析提取代码结构，而不是盲目截取
按依赖关系组织加载顺序——先加载被依赖的模块

策略四：隔离（Isolation）

将复杂任务分解为独立的子任务，每个子任务有自己的上下文空间。

隔离模式：


主任务：重构用户模块
    │
    ├── 子任务 1：重构数据模型
    │   上下文：schema.prisma + models/ + types/
    │
    ├── 子任务 2：重构 API 路由
    │   上下文：api/users/ + middleware/ + 子任务 1 的输出
    │
    └── 子任务 3：更新测试
        上下文：tests/users/ + 子任务 1&2 的输出

在 AI 编码工具中的实现：

Claude Code：使用 subagent 机制，每个子任务在独立上下文中执行
Kiro：使用 Spec-Driven 工作流，将大任务拆分为独立的 task
Cursor：使用 Composer 的多文件编辑，每次聚焦一个模块

策略五：检索增强（RAG）

不把所有信息塞进上下文，而是按需从外部存储中检索。

适用场景：

项目文档库（几十到几百篇文档）
大型代码库（无法全部放入上下文）
历史对话和决策记录

工具推荐：

工具	用途	价格	适用场景
Cursor @codebase	代码库语义搜索	包含在 Cursor Pro 中	大型代码库检索
Cody (Sourcegraph)	代码智能搜索	免费 / $9/月 (Pro)	多仓库代码搜索
MCP + 向量数据库	自定义知识库检索	取决于向量数据库	项目文档、API 文档
Greptile	代码库 AI 搜索	$40/月起	代码理解和搜索

策略六：语义缓存（Semantic Caching）

缓存常见查询的结果，避免重复消耗上下文空间和 API 调用。

工作原理：


用户查询 → 语义相似度匹配 → 命中缓存？
                                  │
                          是 ←────┤────→ 否
                          │              │
                     返回缓存结果    正常 LLM 调用
                                        │
                                   缓存结果

工具推荐：

工具	用途	价格	适用场景
GPTCache	开源语义缓存	免费	自托管、高度定制
Redis + 向量扩展	通用缓存 + 语义搜索	免费（自托管）/ $5/月起（云）	生产环境
Helicone	API 代理 + 缓存	免费起步	快速集成、成本监控

4. 按模型窗口大小的策略决策树

128K 窗口（GPT-4o、DeepSeek V3）


项目规模？
├── 小型（<50 文件）
│   └── 直接加载相关文件 + 规则文件
│       有效利用：~90K tokens
│
├── 中型（50-200 文件）
│   └── 优先级排序 + 选择性加载
│       规则文件（~5K）+ 相关代码（~60K）+ 对话历史摘要（~10K）
│
└── 大型（200+ 文件）
    └── 分块 + RAG + 隔离
        每次只加载一个模块的上下文

200K 窗口（Claude 4 Sonnet/Opus）


项目规模？
├── 小型（<50 文件）
│   └── 可以加载大部分代码库 + 完整文档
│       有效利用：~130K tokens
│
├── 中型（50-200 文件）
│   └── 加载核心模块完整代码 + 接口定义 + 文档
│       规则文件（~5K）+ 核心代码（~80K）+ 接口（~20K）+ 文档（~15K）
│
└── 大型（200+ 文件）
    └── 优先级排序 + 压缩 + 选择性加载
        比 128K 窗口多出的空间用于加载更多上下文

1M+ 窗口（Gemini 2.5 Pro）


项目规模？
├── 小-中型（<200 文件）
│   └── 可以加载整个代码库
│       但仍建议优先级排序，避免"干扰"失败模式
│
├── 大型（200-1000 文件）
│   └── 加载完整代码库 + 文档
│       有效利用：~500K tokens
│       注意：超过 200K token 后价格翻倍
│
└── 超大型（1000+ 文件）
    └── 仍需分块和 RAG
        即使 1M 窗口也无法容纳所有内容
        且超长上下文的准确率会下降

通用决策流程图


开始
  │
  ▼
估算任务所需上下文大小
  │
  ▼
是否超过有效窗口的 70%？ ──否──→ 直接加载，注意优先级排序
  │
  是
  │
  ▼
能否拆分为独立子任务？ ──是──→ 隔离执行，每个子任务独立上下文
  │
  否
  │
  ▼
能否用摘要替代完整内容？ ──是──→ 压缩非核心信息
  │
  否
  │
  ▼
能否按需检索？ ──是──→ 使用 RAG，只加载检索结果
  │
  否
  │
  ▼
考虑使用更大窗口的模型（如 Gemini 2.5 Pro）
或重新评估任务范围

5. 实用技巧

Token 估算速查

内容类型	大约 token 数
1 行代码	~15-25 tokens
1 个函数（20 行）	~300-500 tokens
1 个文件（200 行）	~3,000-5,000 tokens
1 篇文档（1000 字）	~1,500-2,000 tokens
package.json	~500-1,000 tokens
完整 README	~1,000-3,000 tokens

提示词模板：上下文预算规划


我需要完成以下任务：[任务描述]

请帮我规划上下文预算：
1. 列出完成此任务需要的所有信息源
2. 按优先级排序（必需 / 重要 / 可选）
3. 估算每个信息源的 token 数
4. 如果总量超过 [窗口大小]，建议哪些可以压缩或省略

实战案例：管理一个 500 文件 Rust 项目的上下文

场景

需要在一个 500 文件的 Rust 项目中重构错误处理模块，从 anyhow 迁移到自定义错误类型。

策略组合

第一步：隔离 — 将任务拆分为子任务

定义新的错误类型枚举（src/error.rs）
迁移核心模块（src/sync_engine.rs、src/transfer.rs）
迁移辅助模块（src/config.rs、src/diff.rs）
更新测试

第二步：优先级排序 — 每个子任务的上下文

子任务 1：规则文件（5K）+ 现有 error.rs（2K）+ 所有 anyhow::Result 的 grep 结果（3K）= ~10K tokens
子任务 2：规则文件（5K）+ 新 error.rs（3K）+ sync_engine.rs（8K）+ transfer.rs（6K）= ~22K tokens

第三步：压缩 — 对话历史

子任务 1 完成后，将结果压缩为摘要（“已定义 SyncError、ConfigError、TransferError 三个错误枚举”）
子任务 2 使用压缩后的摘要而非完整对话历史

结果： 每个子任务的上下文控制在 30K tokens 以内，远低于 128K 窗口限制，模型准确率保持在高水平。

避坑指南

❌ 常见错误

把整个代码库塞进 1M 窗口
- 问题：即使窗口够大，无关信息会触发”干扰”失败模式，且成本高昂
- 正确做法：即使用 Gemini 1M 窗口，也要做优先级排序
忽略”Lost in the Middle”效应
- 问题：模型对上下文中间位置的信息关注度最低
- 正确做法：最重要的信息放在上下文的开头和结尾
从不压缩对话历史
- 问题：长对话中早期信息被截断，关键决策丢失
- 正确做法：定期生成对话摘要，替代完整历史
用 token 数而非信息密度衡量上下文质量
- 问题：100K tokens 的低质量上下文不如 20K tokens 的高质量上下文
- 正确做法：关注信息的相关性和密度，而非绝对数量
不考虑成本
- 问题：大量上下文意味着高额 API 费用，尤其是 GPT-4.5（$75/M tokens）
- 正确做法：在质量和成本之间找平衡，使用更便宜的模型处理简单任务

✅ 最佳实践

把上下文窗口当预算管理——每个 token 都要有价值
建立”上下文预算”习惯：任务开始前估算需要多少上下文
使用工具监控实际 token 使用量（LangSmith、Helicone 等）
对于重复性任务，建立上下文模板，避免每次从零组装

参考来源

Context Window Management for LLM Apps — Redis （2026-02）
LLM Context Management: 5 Strategies — Fast.io （2025）
Best LLMs for Extended Context Windows in 2026 — AIMultiple （2026-01）
Top Techniques to Manage Context Length — Agenta （2025-12）
How to Tackle Chunking and Context Windows — Typedef AI （2026-01）
Context Window Management — Waylandz （2026-01）
Investigating Token Limits — OrionAI （2025-06）

📖 返回总览与导航 | 上一节：规则文件编写指南 | 下一节：上下文工程实战清单