11

3Resources/AI/Agent上下文管理策略.md

@@ -0,0 +1,115 @@
+# 万字长文解析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/