# 万字长文解析Agent框架中的上下文管理策略 **来源**: [知乎](https://zhuanlan.zhihu.com/p/2012088406826562496) **收录时间**: 2026-04-09 **标签**: #Agent #上下文管理 #LLM #ClaudeCode --- ## 0x00. 写在前面 今年春节前后，至少9家国内的厂商密集地发布了他们旗舰版本的模型（比如GLM5、MiniMaxM2.5、Qwen3.5），可以发现大模型领域的竞争焦点从通用能力转向了Agent落地、编程能力这两大方向。 随着Claude Code、OpenClaw等Agent Scaffold的爆火，各大厂商也纷纷将自己的定位锁定在Agentic Engineering上，从"chatbots that respond" 转向 "agents that act"。 --- ## 0x01. 背景 ### （1）什么叫上下文工程（Context Engineering）？ "上下文工程"简单来说，就是在一些LLM的约束下（如上下文窗口大小、注意力长度的限制），优化上下文token的效用，从而持续获得理想输出的工程实践。 一个好的context engineering追求用最少的、信号最强的token集合，最大化期望输出的概率。 如果说之前早期的"Prompt Engineering"适用于单轮文本生成任务；那么"Context Engineering"就适用于需要多轮推理、长时间运行的智能体，需管理不断演变的上下文状态。 ### （2）为什么Context Engineering对构建一个强大智能体来说至关重要？ Agent 每调用一次工具，就会返回一个工具的Observation，这个结果会被追加到聊天记录中。生产环境中的 Agent 可能会进行长达数百轮的对话，因此随着时间的推移，历史记录message会越来越长。 **上下文腐败（context rot）**：虽然现在的LLM能够接受越来越长的序列了，但它们和人类一样，会随着上下文增长而出现注意力涣散的现象，模型准确回忆信息的能力会下降，而且推理也会变慢。 导致这种现象的原因包括： - **注意力分散**：每个token都关注上下文中的所有其他token，形成了 n^2 级别的两两关系 - **训练数据偏差**：模型在训练时接触的长序列远少于短序列 - **位置编码插值**：可以让模型适应更长的序列，但通常会牺牲一定的精度 --- ## 0x02. 上下文工程 ### （1）上下文卸载与检索（Context Offload & Retrieval） #### (a) 将上下文卸载到文件系统（紧凑化, Compaction） Manus提出了一个核心理念：**将文件系统视为终极上下文**。这是因为文件系统天然具有无限容量、持久化、可随机访问的特性。 这种"可逆压缩"确保上下文长度缩减的同时，信息并未真正丢失——它们只是被卸载到文件系统中了，随时可以重新加载进来。 #### (b) 检索：推理前检索 vs "Just-in-time"检索 **RAG（Retrieval-Augmented Generation）**：预先对知识库的文本进行向量化，然后在推理前预先检索相关片段。 **Just-in-time检索**：让 LLM 自己生成搜索命令，像人类一样主动探索大文件或者代码库。 Claude Code 在处理大型的数据时，会生成一些复杂的 Bash 命令进行查询（如ripgrep、jq、find等），利用自己对代码的深刻理解，使用精细而复杂的正则表达式定位相关代码块。 ### （2）上下文摘要(Context Summarization) 当上下文窗口即将被填满，且没有办法进一步做紧凑化的时候，我们不得不采用另一种手段：摘要化。这是一种有损压缩，它会将对话历史浓缩成一段摘要，从而释放空间。 **Claude Code的压缩流程**： - 自动触发：监控当前上下文的 token 使用量，接近上限时自动触发 - 手动触发：用户可通过/compact命令主动执行压缩 摘要包含：主要请求和意图、关键技术概念、文件和代码段、错误和修复、问题解决、用户所有消息、待办任务、当前工作、可选下一步 ### （3）上下文隔离（多智能体架构） 面对一个复杂的任务，我们可以将任务分解，然后由主智能体协调多个专门化的子智能体（sub-agents）来处理具体任务。 **多智能体架构的好处**： - **节省主Agent的上下文**：subagent的上下文和主agent是隔离的 - **权限控制**：限制 subagent 可用的工具 - **特定领域专业化**：为特定领域编写专门的系统提示 - **节约调用成本**：可以把某些简单的任务路由到更快、更便宜的模型 **Claude Code的subagent分类**： - **Explore**：只读 agent，专门用于搜索和分析代码库（使用 Haiku） - **Plan**：负责理解代码库并进行规划（使用 Sonnet/Opus） - **General-Purpose**：全能型 agent（使用 Sonnet/Opus） **运行模式**： - **前台运行模式**：subagent 运行时阻塞主对话，用户实时决定要不要accept操作 - **后台运行模式**：subagent 在后台运行，启动前收集权限，运行中自动拒绝未批准的操作 **调用关系**： - **并行调用**：多个 subagent 同时独立运行 - **链式调用**：多个 subagent 顺序执行，后一个依赖于前一个的输出 ### （4）上下文缓存 **KV Cache（KV缓存）**：Transformer 模型在生成每个 token 时，需要计算所有之前 token 的Key和Value向量，用于注意力机制的计算，这些 KV 向量就构成了上下文的状态。KV Cache就是将这些中间计算结果保存下来，当后续请求包含相同的前缀时，可以直接复用。 **Prefill（预填充）**：只在生成第一个输出 token 之前，模型对所有输入 token 进行并行处理的阶段。 **为什么缓存对 agent 来说至关重要？** - Agent 的工作流程是多轮工具调用的重复 - 平均Agent的输入输出 token 比高达 100:1 - 以 Claude Sonnet 为例，缓存的输入 token 价格为 0.30 美元/百万 token，而未缓存的则高达 3 美元/百万 token，相差 10 倍！ **Claude Code的缓存策略**： - **核心原则**：上下文只追加，不修改 - **自动缓存**：在请求顶层添加cache_control字段，系统自动将最后一个可缓存的内容块作为缓存断点 - **手动缓存**：对稳定性极高的内容（如system prompt、工具定义）使用显式断点 - 最多4个缓存断点（包括显式和自动缓存） --- ## 参考链接 - https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents - https://minusx.ai/blog/decoding-claude-code/#21-use-claudemd-for-collaborating-on-user-context-and-preferences - https://manus.im/en/blog/Context-Engineering-for-AI-Agents-Lessons-from-Buliding-Manus - https://platform.claude.com/docs/