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.15399Context Confusion工具过多全量工具准确率 13.62%RAG 选择后 43.13%RAG-MCP, arxiv 2505.03275Context Clash多轮冲突多轮对话 vs 单轮平均性能下降39%o3 从 98.1 → 64.1Microsoft Salesforce, arxiv 2505.06120Context 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-MCParxiv: 2505.03275Tiantian 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 tokensRAG-MCP 将工具选择准确率提升至基线的3.17 倍同时将 prompt token 数量减少超过 50%。⚠️ 注原文作者 Drew Breunig 提到超过 30 个工具开始混淆、超过 100 个工具必然失败这是对论文压力测试趋势的定性解读并非论文中的精确阈值数字。② Less is Morearxiv: 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%。典型任务示例识别 SP 500 信息技术板块所有公司的全部董事会成员。单智能体方案因顺序搜索导致上下文不断积累而失败多智能体方案将任务分解给多个子智能体并行处理每个子智能体上下文独立、聚焦最终成功完成任务。⚠️ 注该数据来自 Anthropic 内部评估集非第三方独立基准测试结论具有参考价值但需注意评测环境的特定性。适用场景可并行化的任务如批量数据处理、多维度研究。不适用场景需要多个 Agent 共享上下文、实时协作的任务。2.4 Context Pruning上下文剪枝定义主动识别并移除上下文中不相关或不再需要的信息。Agent 在运行过程中会不断积累上下文——工具调用结果、中间文档、历史对话……定期修剪这些内容保留真正有用的部分是维持上下文质量的重要手段。工具推荐ProvenceICLR 2025Naver 团队Provence 是一个专为问答场景设计的高效上下文剪枝工具体积小仅 1.75 GB、速度快、准确率高。实验数据Provence 在 NaturalQuestions、TriviaQA、HotpotQA 等多个主流 QA 基准上进行测试核心结论性能下降可忽略不计negligible to no drop部分场景下甚至因去除噪声而性能有所提升无需针对特定领域微调可直接跨域使用批处理模式下运行速度显著优于 RECOMP、DSLR 等传统剪枝方法根据上下文内容自动判断需要剪枝的比例而非固定裁剪率。原文作者实测对阿拉米达市维基百科词条针对问题离开阿拉米达有哪些方式进行剪枝Provence 裁剪掉了95% 的内容仅保留与交通出行直接相关的段落且结果准确。fromtransformersimportAutoModel provenceAutoModel.from_pretrained(naver/provence-reranker-debertav3-v1,trust_remote_codeTrue)withopen(alameda_wiki.md,r,encodingutf-8)asf:alameda_wikif.read()questionWhat are my options for leaving Alameda?provence_outputprovence.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_promptcompile_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 BlogDatabricks 对多个主流模型在不同上下文长度下的 RAG 任务正确率进行了系统测试模型性能开始下降的上下文长度Llama-3.1-405B32k tokens后开始下降GPT-4-0125-preview64k 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.3700.57054%零售中等难度0.7830.8123.7%此外在SWE-bench上添加 think 工具的 Claude 3.7 Sonnet 平均性能提升1.6%最终得分达到0.623。Anthropic 识别的三个适用场景工具输出分析当模型需要仔细处理之前工具调用的输出且可能需要回溯其方法时策略密集型环境当模型需要遵循详细指南并验证合规性时顺序决策当每个动作都建立在前一个动作之上且错误代价高昂时 示例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 的 AgentContext Quarantine上下文污染、上下文干扰高可并行化的复杂任务Context Pruning上下文混淆、上下文干扰中长文档处理、信息密集型任务Context Summarization上下文干扰历史过长中长对话、长期运行的 AgentContext 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.mdClaude Code和opencode.json的context.instructionsOpenCode是跨会话的永久记忆——每次新会话都会自动加载。这是最重要的长期投资。一份好的 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 Breunig2025-06-26How Long Contexts Fail — Drew Breunig2025-06-22学术论文RAG-MCP — Tiantian Gan Qiyao Sun2025。工具选择准确率从 13.62% 提升至 43.13%3.17xprompt token 减少超 50%。Less is More — 边缘设备 LLM 函数调用优化2024。执行时间最高减少 70%能耗最高降低 40%46 工具失败 vs 19 工具成功的对比实验。Provence — ICLR 2025Naver 团队。在 NaturalQuestions、TriviaQA、HotpotQA 等基准上实现近零性能损失的大幅剪枝。LLMs Get Lost In Multi-Turn Conversation — Microsoft Salesforce2025。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”