LLM 上下文管理完全指南——从理论到实践

LLM 上下文管理完全指南——从理论到实践

本文基于 Drew Breunig 的系列文章《How Long Contexts Fail》与《How to Fix Your Context》整理扩展，结合 Claude Code、OpenCode 等产品的工程实践，面向框架开发者与产品使用者双重视角，系统梳理上下文管理的核心理论与落地方法。

---

第一部分：为什么上下文管理如此重要

1.1 "塞得越多越好"的直觉为何是错的

随着大模型上下文窗口不断扩大（Gemini 2.5 和 GPT-4.1 均已支持 100 万 token），一种直觉性的想法开始流行：既然窗口足够大，何不把所有信息都塞进去？ 工具定义、文档、历史记录、指令……一股脑全放进 prompt，让模型自己处理。

这种"上下文即垃圾桶"的做法在实践中会导致一系列严重问题。核心原则只有一条：

放入上下文的每一个 token 都会影响模型的输出，无论好坏。

这正是编程领域那句老话的 AI 版本——“Garbage in, garbage out（垃圾进，垃圾出）”。

1.2 四种上下文失效模式

失效类型	描述
Context Poisoning（上下文污染）	幻觉或错误信息进入上下文后被反复引用，导致模型越走越偏
Context Distraction（上下文干扰）	上下文过长，模型过度依赖历史记录，忽视训练时学到的知识
Context Confusion（上下文混淆）	无关信息干扰模型生成，导致低质量响应
Context Clash（上下文冲突）	上下文中积累的新信息与已有信息相互矛盾

1.3 失效模式的实验证据

这些失效模式并非理论推断，均有实验数据支撑：

失效类型	关键实验数据	来源
Context Confusion（工具过多）	46 工具 → 任务失败；19 工具 → 任务成功	Less is More, arxiv 2411.15399
Context Confusion（工具过多）	全量工具准确率 13.62%；RAG 选择后 43.13%	RAG-MCP, arxiv 2505.03275
Context Clash（多轮冲突）	多轮对话 vs 单轮，平均性能下降 39%；o3 从 98.1 → 64.1	Microsoft & Salesforce, arxiv 2505.06120
Context Distraction（历史过长）	超过 100k token 后 Agent 开始重复历史动作（轶事性）	Gemini 2.5 技术报告
Context Distraction（历史过长）	Llama-3.1-405B 在 32k token 后正确率开始下降	Databricks 长上下文研究

---

第二部分：六种上下文管理策略（框架开发者视角）

2.1 RAG（检索增强生成）

定义： 有选择地将相关信息添加到上下文中，帮助模型生成更好的响应，而非将所有文档一次性塞入。

每当模型上下文窗口扩大，就会出现一轮"RAG 已死"的讨论。Llama 4 Scout 拥有 1000 万 token 的上下文窗口，让人忍不住想"直接全塞进去算了"。但把上下文当垃圾桶，垃圾就会影响你的输出。RAG 的核心价值在于精准检索，而非暴力堆砌。

📌 示例：

假设你在构建一个客服机器人，知识库中有 10,000 篇产品文档。错误做法是将全部文档塞入 prompt；正确做法是用户提问"如何退款？"时，先通过向量检索找到最相关的 3-5 篇退款政策文档，只将这些文档注入 prompt。模型获得的信息精准、无噪声，回答质量显著提升。

---

2.2 Tool Loadout（工具负载优化）

定义： 根据当前任务，只将最相关的工具定义加入上下文，而非一次性加载所有工具。

"Loadout"是游戏术语，指在关卡开始前根据场景选择最合适的武器和装备组合。这里借用这个概念，描述为特定任务选择最相关工具集的行为。

研究数据支撑：

① RAG-MCP（arxiv: 2505.03275）

Tiantian Gan 与 Qiyao Sun 将工具描述存入向量数据库，通过语义检索动态选择工具，提出 RAG-MCP 框架。论文设计了 MCP 压力测试，将候选 MCP 服务器数量从 1 逐步增加到 11,100，测量模型在不同工具池规模下的选择准确率。

核心实验结果（以 DeepSeek-v3 为主要测试模型）：

方法	工具选择准确率	Prompt Token 数
全量工具直接提示（基线）	13.62%	2,133 tokens
关键词匹配（实际匹配）	18.20%	—
RAG-MCP（本文方法）	43.13%	1,084 tokens

RAG-MCP 将工具选择准确率提升至基线的 3.17 倍，同时将 prompt token 数量减少超过 50%。

⚠️ 注：原文作者 Drew Breunig 提到"超过 30 个工具开始混淆、超过 100 个工具必然失败"，这是对论文压力测试趋势的定性解读，并非论文中的精确阈值数字。

② Less is More（arxiv: 2411.15399）

该论文专注于边缘设备（Edge Device）上的 LLM 函数调用优化，提出无需微调的动态工具选择方案。在 GeoEngine 基准测试（含 46 个地理空间工具）上，对量化版 Llama 3.1 8b 进行测试：给定全部 46 个工具时任务失败，仅给定 19 个相关工具时任务成功。问题根源是上下文混淆，而非超出窗口限制。

在边缘硬件上的综合实验结果（跨多个 LLM）：

指标	改善幅度
执行时间（Execution Time）	最高减少 70%
能耗（Power Consumption）	最高降低 40%
任务成功率（Agentic Success Rate）	显著提升（具体数值因模型而异）

论文结论：即使动态工具选择方法未能提升任务成功率，速度和能耗的收益本身也值得采用，对资源受限的边缘设备尤为关键。

📌 示例：

一个通用 AI 助手集成了几十个 MCP 工具：搜索、日历、邮件、代码执行、数据库查询……当用户说"帮我查一下明天的天气"时，动态工具选择器应该只加载"天气查询"工具，而不是把所有 50 个工具的描述都塞进 prompt。

---

2.3 Context Quarantine（上下文隔离）

定义： 将任务拆分为多个独立的子任务，每个子任务在自己独立的上下文线程中运行，避免上下文相互污染。

这是多智能体（Multi-Agent）架构的核心思想之一。Anthropic 在其多智能体研究系统博客中这样描述：

“搜索的本质是压缩：从海量语料中提炼洞见。子智能体通过并行运行各自的上下文窗口来实现压缩，同时探索问题的不同方面，然后将最重要的 token 汇总给主研究智能体。每个子智能体还提供了关注点分离——独立的工具、提示词和探索路径——减少了路径依赖，实现了彻底、独立的调查。”

实验数据（来源：Anthropic 工程博客）：

以 Claude Opus 4 为主智能体、Claude Sonnet 4 为子智能体的多智能体系统，在 Anthropic 内部研究评估中比单智能体 Claude Opus 4 性能提升 90.2%。

典型任务示例：识别 S&P 500 信息技术板块所有公司的全部董事会成员。单智能体方案因顺序搜索导致上下文不断积累而失败；多智能体方案将任务分解给多个子智能体并行处理，每个子智能体上下文独立、聚焦，最终成功完成任务。

⚠️ 注：该数据来自 Anthropic 内部评估集，非第三方独立基准测试，结论具有参考价值但需注意评测环境的特定性。

适用场景： 可并行化的任务（如批量数据处理、多维度研究）。不适用场景： 需要多个 Agent 共享上下文、实时协作的任务。

---

2.4 Context Pruning（上下文剪枝）

定义： 主动识别并移除上下文中不相关或不再需要的信息。

Agent 在运行过程中会不断积累上下文——工具调用结果、中间文档、历史对话……定期"修剪"这些内容，保留真正有用的部分，是维持上下文质量的重要手段。

工具推荐：Provence（ICLR 2025，Naver 团队）

Provence 是一个专为问答场景设计的高效上下文剪枝工具，体积小（仅 1.75 GB）、速度快、准确率高。

实验数据：

Provence 在 NaturalQuestions、TriviaQA、HotpotQA 等多个主流 QA 基准上进行测试，核心结论：性能下降可忽略不计（negligible to no drop），部分场景下甚至因去除噪声而性能有所提升；无需针对特定领域微调，可直接跨域使用；批处理模式下运行速度显著优于 RECOMP、DSLR 等传统剪枝方法；根据上下文内容自动判断需要剪枝的比例，而非固定裁剪率。

原文作者实测：对阿拉米达市维基百科词条针对问题"离开阿拉米达有哪些方式？"进行剪枝，Provence 裁剪掉了 95% 的内容，仅保留与交通出行直接相关的段落，且结果准确。

from transformers import AutoModel

provence = AutoModel.from_pretrained(
    "naver/provence-reranker-debertav3-v1",
    trust_remote_code=True
)

with open('alameda_wiki.md', 'r', encoding='utf-8') as f:
    alameda_wiki = f.read()

question = 'What are my options for leaving Alameda?'
provence_output = provence.process(question, alameda_wiki)

最佳实践建议： 建议以结构化字典的形式维护上下文，在每次 LLM 调用前再将其编译为字符串。这样在剪枝时可以精确控制哪些部分（如主指令、目标）必须保留，哪些部分（如文档内容、历史记录）可以被裁剪或压缩。

context = {
    "system_instructions": "你是一个专业的代码审查助手...",  # 永远保留
    "user_goal": "审查这段 Python 代码的安全性",              # 永远保留
    "retrieved_docs": [doc1, doc2, doc3],                    # 可剪枝
    "tool_call_history": [call1, call2, ..., call50],        # 可剪枝/压缩
    "conversation_history": [msg1, msg2, ..., msg100],       # 可压缩
}

context["retrieved_docs"] = provence.process(current_query, context["retrieved_docs"])
context["tool_call_history"] = summarize_if_too_long(context["tool_call_history"])

final_prompt = compile_context(context)

---

2.5 Context Summarization（上下文摘要压缩）

定义： 将积累的上下文压缩为简洁的摘要，替换原始的冗长内容。

上下文摘要最初是为了应对上下文窗口限制而诞生的。但随着上下文窗口扩大，研究者发现摘要的价值远不止于此——即使没有达到 token 上限，过长的上下文也会导致"上下文干扰"。

实验数据一：Gemini 宝可梦 Agent（来源：Gemini 2.5 技术报告）

Gemini 2.5 Pro 在自主完成《宝可梦蓝》游戏的 Agent 实验中（总计耗时 406.5 小时，上下文超过 100K token），观察到明显的上下文干扰现象：

“在这种 Agent 设置中，观察到当上下文显著超过 10 万 token 时，Agent 表现出倾向于重复其大量历史记录中的动作，而非综合新计划的趋势。这一现象（尽管是轶事性的）突出了长上下文用于检索与长上下文用于多步骤生成推理之间的重要区别。”

⚠️ 注：技术报告原文明确标注此观察为"anecdotal（轶事性）"，即基于观察而非受控实验，不构成严格的定量结论，但方向性参考价值明确。

实验数据二：Databricks 长上下文 RAG 性能研究（来源：Databricks Blog）

Databricks 对多个主流模型在不同上下文长度下的 RAG 任务正确率进行了系统测试：

模型	性能开始下降的上下文长度
Llama-3.1-405B	32k tokens 后开始下降
GPT-4-0125-preview	64k tokens 后开始下降
少数模型	能在全部测试长度内保持稳定

研究还发现一个反直觉的失败模式：在超长上下文下，模型有时会忽略 prompt 中的指令，转而对上下文内容进行摘要，即上下文内容"压制"了任务指令本身。

📌 示例：

一个长期运行的编程助手 Agent，经过 200 轮对话后，上下文中积累了大量调试过程和中间代码片段。

压缩前（原始上下文片段）：

[Turn 1] 用户：帮我写一个排序函数
[Turn 2] 助手：这是冒泡排序实现...（50行代码）
[Turn 3] 用户：有 bug，第 15 行报错
[Turn 4] 助手：修复了，问题是索引越界...
... （重复 196 轮）

压缩后（摘要）：

【会话摘要】
- 已完成：实现了快速排序算法（位于 sort.py），修复了 3 个边界条件 bug
- 当前目标：优化排序算法的内存占用
- 关键约束：需兼容 Python 3.8+，不能使用第三方库
- 已知问题：大数组（>10万元素）时性能下降

实施建议： 将摘要压缩作为独立的 LLM 调用阶段，明确告知压缩模型哪些信息必须保留（当前目标、关键约束、已知问题），哪些可以丢弃（已解决的中间步骤）。

---

2.6 Context Offloading（上下文卸载）

定义： 将信息存储在 LLM 上下文之外，通过工具按需读写，避免上下文膨胀。

Anthropic 的 “think” 工具是这一模式的典型实现——本质上是一个草稿本（scratchpad），为模型提供在工具调用之间进行推理和记录的专属空间。

实验数据（来源：Anthropic 工程博客）：

Anthropic 使用 τ-bench（含航空和零售两个真实客服领域）对 Claude 3.7 Sonnet 进行测试，评估指标为 pass^1（单次通过率）：

测试域	基线（无 think 工具）	加入 think 工具 + 优化 prompt	相对提升
航空（高难度，政策复杂）	0.370	0.570	+54%
零售（中等难度）	0.783	0.812	+3.7%

此外，在 SWE-bench 上，添加 think 工具的 Claude 3.7 Sonnet 平均性能提升 1.6%，最终得分达到 0.623。

Anthropic 识别的三个适用场景：

1. 工具输出分析： 当模型需要仔细处理之前工具调用的输出，且可能需要回溯其方法时
2. 策略密集型环境： 当模型需要遵循详细指南并验证合规性时
3. 顺序决策： 当每个动作都建立在前一个动作之上，且错误代价高昂时

📌 示例：

tools = [
    {
        "name": "write_scratchpad",
        "description": "将中间推理结果、待办事项或临时笔记写入草稿本，不占用主上下文",
        "parameters": {"note": "string", "category": "enum[reasoning, todo, finding]"}
    },
    {
        "name": "read_scratchpad",
        "description": "读取草稿本中的特定类别笔记",
        "parameters": {"category": "enum[reasoning, todo, finding, all]"}
    },
    {
        "name": "write_memory",
        "description": "将重要结论持久化存储，跨会话可用",
        "parameters": {"key": "string", "value": "string"}
    }
]
# Agent 工作流：
# 1. 开始任务时，先读取 memory 中的历史结论
# 2. 推理过程写入 scratchpad（不污染主上下文）
# 3. 最终结论写入 memory 持久化
# 4. 主上下文始终保持简洁

---

2.7 策略对比与选型指南

策略	解决的核心问题	实施复杂度	适用场景
RAG	上下文混淆、上下文干扰	中	知识库问答、文档检索
Tool Loadout	上下文混淆（工具过多）	低-中	工具数量 > 10 的 Agent
Context Quarantine	上下文污染、上下文干扰	高	可并行化的复杂任务
Context Pruning	上下文混淆、上下文干扰	中	长文档处理、信息密集型任务
Context Summarization	上下文干扰（历史过长）	中	长对话、长期运行的 Agent
Context Offloading	上下文干扰、上下文混淆	低	多步骤推理、策略密集型任务

---

第三部分：Agent 产品使用者的实践指南

上述六种策略是写给框架开发者的，但使用者其实也在"管理上下文"——只不过用的是自然语言而非代码。你每次说"帮我读一下这个文件"、每次开新会话、每次执行 /clear，本质上都是在做上下文管理决策。

3.1 失效模式在日常使用中的具体表现

上下文污染（Context Poisoning）——错误信息被反复引用

典型场景：你让 Claude Code 分析一个 bug，它给出了一个错误的诊断（比如误判了某个变量的类型）。你没有明确纠正，而是继续追问。此后，这个错误诊断就成了"既成事实"留在上下文里，后续所有回答都建立在这个错误前提上。

识别信号：Agent 的建议越来越奇怪，且逻辑自洽但与实际代码不符。

上下文干扰（Context Distraction）——历史太长导致模型"走神"

典型场景：一个长达 2 小时的 Claude Code 会话，前期讨论了大量架构设计，中期做了很多文件读取，后期你问一个简单问题，Agent 却给出了掺杂大量前期历史信息的冗长回答，甚至开始重复之前已经完成的步骤。

识别信号：回答变得啰嗦、重复，或者开始"回头"做已经完成的事情。

上下文混淆（Context Confusion）——无关信息干扰判断

典型场景：你在 OpenCode 里配置了十几个 MCP 工具（数据库、邮件、日历、搜索……），然后让 Agent 帮你写一个简单的排序函数。Agent 却尝试调用数据库工具查询数据，或者在回答里夹杂了与任务无关的工具使用建议。

识别信号：Agent 调用了与当前任务明显无关的工具，或者回答里出现了不相关的信息。

上下文冲突（Context Clash）——前后信息互相矛盾

典型场景：你在会话开始时说"使用 PostgreSQL"，中途又粘贴了一段 MySQL 的示例代码，后来又说"参考这个 SQLite 的文档"。Agent 开始在三种数据库之间摇摆，给出混乱的建议。

识别信号：Agent 的回答前后矛盾，或者在同一个回答里混用了不同的技术栈。

---

3.2 六种策略的使用者操作版

策略一：RAG 思维——精准投喂，而非全量倾倒

不要把整个项目的所有文件都让 Agent 读一遍。要像一个精准的检索系统一样，只给 Agent 它当前任务真正需要的信息。

❌ 低效做法：
"帮我优化这个项目，先把所有文件都读一遍了解背景"

✅ 高效做法：
"我需要优化 src/api/user.ts 里的 getUserById 函数的性能。
相关的数据库 schema 在 db/schema.sql 的第 45-60 行，
请只读这两个文件的相关部分，然后给出优化建议"

在 Claude Code 中：用 @文件名 精确引用文件；指定行号范围如 @src/auth.ts:45-80；先问"你需要读哪些文件来完成这个任务？"，让 Agent 自己声明依赖，再确认。

---

策略二：Tool Loadout——按需启用工具，避免工具过载

在 OpenCode 的 opencode.json 中，根据当前工作阶段只保留必要的工具集：

// 纯代码编写阶段，不需要数据库和外部 API 工具
{
  "mcp": {
    "servers": {
      "filesystem": { "command": "npx", "args": ["@anthropic/mcp-server-filesystem", "./src"] }
    }
  }
}

在 Claude Code 中，可以通过明确告知 Agent 不要使用某些能力来模拟工具卸载：

"这个任务只需要读写文件，不需要执行任何 shell 命令，
也不需要访问网络。请只使用文件读写工具完成任务。"

---

策略三：Context Quarantine——用新会话隔离不同任务

这是最容易被忽视、但收益最高的策略。黄金法则：一个会话，一个聚焦目标。

会话 1：探索阶段
"帮我分析 auth 模块的现有架构，不要修改任何代码，
只需要给我一份架构分析报告"
→ 保存报告到文件，结束会话

会话 2：设计阶段（新开）
"基于这份架构分析（粘贴报告），设计 OAuth 接入方案，
不要写代码，只需要给出设计文档"
→ 保存设计文档，结束会话

会话 3：实现阶段（新开）
"按照这个设计方案（粘贴文档），实现 OAuth 登录功能"
→ 专注实现，上下文干净

OpenCode 的 Plan/Build 双 Agent 模式正是这个思想的产品化实现：Plan Agent 负责分析和设计（只读），Build Agent 负责实现（可写）。使用时应该有意识地切换，而不是一直停留在 Build 模式。

---

策略四：Context Pruning——主动清理，而非被动等待压缩

在 Claude Code 中：

• /compact：压缩历史对话，保留关键信息，适合同一任务继续推进时使用
• /clear：完全清空对话，适合切换到不相关任务时使用
• /rewind：回退到某个历史节点，适合发现 Agent 走偏时使用

关键判断：

需要 /compact 的信号：
- 上下文使用率超过 50%（用 /cost 查看）
- Agent 开始重复之前的步骤
- 回答变得冗长但仍在正轨上

需要 /clear 的信号：
- 切换到完全不同的任务
- Agent 明显被之前的错误信息带偏
- 已经 compact 过 2-3 次（多次压缩会导致摘要质量下降）
- 感觉 Agent 在"绕圈子"

清理前的关键动作——先保存，再清理：

"在我们清空上下文之前，请总结：
1. 已完成的工作（列出修改的文件）
2. 当前进展状态
3. 下一步待完成的任务
4. 本次会话中确定的重要约束和决策
请将这些内容写入 .claude/session-handoff.md"

---

策略五：Context Summarization——用 CLAUDE.md / opencode.json 做持久化摘要

CLAUDE.md（Claude Code）和 opencode.json 的 context.instructions（OpenCode）是跨会话的"永久记忆"——每次新会话都会自动加载。这是最重要的长期投资。

一份好的 CLAUDE.md 示例：

# CLAUDE.md

## 项目概述
这是一个基于 FastAPI + PostgreSQL 的电商后端服务。
主要模块：用户认证、商品管理、订单处理、支付集成。

## 技术栈
- Python 3.11, FastAPI 0.104
- PostgreSQL 15（价格字段统一用分/整数存储，禁止用浮点数）
- Redis 用于会话缓存和限流
- 测试框架：pytest + httpx

## 编码规范
- 所有 API 响应统一用 schemas/ 目录下的 Pydantic 模型
- 数据库操作必须通过 repositories/ 层，禁止在 router 里直接写 SQL
- 错误处理统一用 app/exceptions.py 中定义的异常类

## 重要决策记录
- 2026-03-15：放弃 JWT，改用 server-side session（安全审计要求）
- 2026-03-20：商品搜索改用 Elasticsearch，不再用 PostgreSQL 全文搜索

## 禁止事项（DO NOT）
- 不要修改 alembic/versions/ 下的已有迁移文件
- 不要在 main.py 里添加业务逻辑
- 不要使用 float 存储金额

## 当前工作焦点
（每次会话后更新）
- 正在开发：订单退款流程
- 待处理：支付回调的幂等性问题

维护原则：控制在 3000 token 以内；定期更新，过时的信息比没有信息更危险；把"禁止事项"单独列出，这是防止 Agent 犯重复错误的最有效手段。

---

策略六：Context Offloading——用外部存储替代上下文记忆

不要让 Agent 把所有中间结果都"记在脑子里"，而是主动让它写到文件里：

✅ 好的工作流：
"分析这个模块的所有依赖关系，
把分析结果写入 .claude/analysis/auth-deps.md，
然后告诉我你发现了什么关键问题"
（Agent 写文件 → 上下文只保留摘要 → 需要时再读文件）

❌ 低效工作流：
"分析这个模块的所有依赖关系，把所有细节都告诉我"
（Agent 把大量分析内容输出到上下文 → 上下文迅速膨胀）

对于复杂任务，在开始前就建立一个工作草稿本：

"我们要重构认证模块，这是一个复杂任务。
请先创建 .claude/refactor-plan.md 作为我们的工作草稿本，
在整个过程中，把重要的决策、发现的问题、完成的步骤都记录在这里。
这样即使我们需要清空上下文，也不会丢失进度。"

---

3.3 综合实战：一个完整的 Claude Code 工作流

把以上六种策略整合成一个可复用的工作流：

阶段 0：会话前准备（5分钟投资，节省数小时）
├── 检查 CLAUDE.md 是否需要更新
├── 确认本次会话的单一目标
└── 准备好相关文件的精确路径

阶段 1：探索（新会话 / Plan 模式）
├── 只读取必要文件（精确指定路径和行号）
├── 让 Agent 输出分析报告到文件
└── 不要在这个阶段修改任何代码

阶段 2：设计（可继续或新会话）
├── 基于分析报告（引用文件，不是粘贴全文）制定方案
├── 让 Agent 把设计方案写入文件
└── 明确确认方案后再进入实现

阶段 3：实现（新会话 / Build 模式）
├── 引用设计文档作为上下文
├── 每完成一个子任务，让 Agent 更新进度文件
├── 监控上下文使用率（/cost）
└── 超过 50% 时主动 /compact，并先保存状态

阶段 4：验证（可新会话）
├── 清空上下文，只带入"需要验证的内容"
├── 让 Agent 专注于测试和验证
└── 发现问题时，明确纠正错误信息（防止上下文污染）

阶段 5：会话收尾
├── 让 Agent 生成交接文档
├── 更新 CLAUDE.md 中的"当前工作焦点"
└── 清空会话

---

3.4 快速诊断：你的上下文出了什么问题？

症状	可能的失效类型	推荐操作
Agent 反复建议你已否定的方案	上下文污染	/rewind 回退，或 /clear 重开并明确纠正
回答越来越长、越来越啰嗦	上下文干扰	/compact 压缩，或 /clear 重开
Agent 调用了不相关的工具	上下文混淆	明确告知"只使用 X 工具"，或减少启用的 MCP
前后建议自相矛盾	上下文冲突	检查是否引入了矛盾信息，/clear 重开并统一信息源
新会话需要重新解释项目背景	缺乏持久化摘要	建立并维护 CLAUDE.md
上下文很快就满了	信息投喂过多	精确引用文件，让 Agent 把中间结果写到文件

---

第四部分：核心结论

4.1 给框架开发者

正如 Andrej Karpathy 所说，Agent 设计师的核心工作是"把上下文窗口填得恰到好处"——智能地部署工具、信息和定期的上下文维护。

上下文不是免费的。现代大模型的超大上下文窗口是强大的能力，但绝不是粗放管理信息的借口。在构建或优化 Agent 时，始终问自己：

“上下文中的每一个 token，都在为最终输出贡献价值吗？”

4.2 给产品使用者

把 Agent 想象成一位工作记忆有限的极其聪明的同事：

• 他在当前会话里记得所有细节，但下次见面就忘了（→ 维护 CLAUDE.md）
• 给他的信息越杂，他越容易分心（→ 精准投喂）
• 一次只交代一件事，他做得最好（→ 会话隔离）
• 如果他走偏了，越早纠正越好（→ 主动 /rewind 或 /clear）
• 让他把重要结论写下来，而不是全靠记忆（→ 外部存储）

上下文管理的本质，是在有限的"工作记忆"里，始终保持信噪比最高的状态。

---

参考资料

原始文章

• How to Fix Your Context — Drew Breunig，2025-06-26
• How Long Contexts Fail — Drew Breunig，2025-06-22

学术论文

• RAG-MCP — Tiantian Gan & Qiyao Sun（2025）。工具选择准确率从 13.62% 提升至 43.13%（+3.17x），prompt token 减少超 50%。
• Less is More — 边缘设备 LLM 函数调用优化（2024）。执行时间最高减少 70%，能耗最高降低 40%；46 工具失败 vs 19 工具成功的对比实验。
• Provence — ICLR 2025，Naver 团队。在 NaturalQuestions、TriviaQA、HotpotQA 等基准上实现近零性能损失的大幅剪枝。
• LLMs Get Lost In Multi-Turn Conversation — Microsoft & Salesforce（2025）。200K+ 次模拟，15 个 SOTA 模型，多轮对话相比单轮平均性能下降 39%；o3 从 98.1 降至 64.1。

工程实践

• Anthropic 多智能体研究系统 — 上下文隔离的工程实践，多智能体系统比单智能体性能提升 90.2%
• Anthropic “think” 工具 — 上下文卸载的典型实现，τ-bench 航空领域提升 54%
• Gemini 2.5 技术报告 — 宝可梦 Agent 实验，上下文污染与干扰的真实案例

基准测试与工具

• Berkeley Function Calling Leaderboard — 工具调用能力评测
• Databricks 长上下文 RAG 性能研究 — 不同模型的上下文干扰临界点数据
• Context Management Strategies for OpenCode — OpenCode 上下文管理完整指南
• The Ultimate Guide to Claude Code Context Management — Claude Code 上下文管理实践
• Andrej Karpathy 关于上下文管理的推文 — “pack the context windows just right”