116 lines
6.5 KiB
Markdown
116 lines
6.5 KiB
Markdown
# 万字长文解析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/
|