Agent的上下文管理方案应如何设计？

## 作用 Agent 上下文管理用于解决对话轮次增多后历史消息填满上下文窗口的问题，避免： - Token 成本持续上升 - 模型响应变慢 - 撞上模型上下文长度上限 - 早期关键约束、事实或偏好丢失，导致 Agent “失忆” 设计目标不是简单缩短对话，而是在 Token 预算内保留完成任务所需的信息，并在需要时精准召回。 ## 原理：三种主流方案 ### 1. 滑动窗口截断 - **做法**：固定只保留最近 N 轮对话，超出窗口后丢弃最旧消息。 - **优点**： - 实现成本极低 - Token 消耗可预测 - 可通过硬上限控制上下文长度 - **缺点**： - 早期关键信息可能被直接删除 - 不适合依赖长期约束或历史事实的任务 - **适用场景**：短任务、单轮或浅层交互。 ### 2. 摘要压缩 - **做法**：每隔 N 轮对旧对话生成摘要，用摘要替换原始消息。 - **优点**： - 相比直接截断能保留更多信息 - 可减少一定 Token 消耗 - **缺点**： - 摘要生成本身会消耗 Token - 属于有损压缩，可能丢失具体报错、版本号、环境变量等精确信息 - **适用场景**：中等对话深度、对细节保留有一定要求但不完全依赖原始细节的任务。 ### 3. 分层记忆 + 按需召回 - **做法**：不把所有对话统一截断或压缩，而是将信息分层存储，并根据当前任务检索相关上下文。 - 可设计为以下层级： - **L0 原始对话**：保存完整原始记录，用于回溯确切措辞、时间戳和来源。 - **L1 原子记忆**：提取事实、偏好、约束、事件等可操作信息。 - **L2 场景记忆**：围绕项目或场景组织知识块，用于恢复工作上下文。 - **L3 用户画像**：保存长期偏好和稳定模式，帮助 Agent 快速理解用户。 - **召回方式**： - L2/L3 提供轻量上下文引导 - 需要具体事实时，通过 BM25、向量检索和 RRF 等方式回退到 L1/L0 - 召回结果应受条目数、字符预算和超时限制，避免记忆内容反过来撑爆上下文 - **适用场景**：长期协作、复杂项目、多 Agent 协作等需要长期记忆和精确召回的场景。 ## 方案选择 | 方案 | Token 控制 | 信息保留 | 实现复杂度 | 适合场景 | | --- | --- | --- | --- | --- | | 滑动窗口截断 | 强，硬上限 | 差，会直接丢弃 | 极低 | 短任务 | | 摘要压缩 | 中，有损节约 | 中，细节可能丢失 | 中 | 中等深度对话 | | 分层记忆 + 按需召回 | 强，可做预算约束 | 强，分层保留 | 中高 | 长期协作、多 Agent | ## 增强设计：结构化索引 对于文档和代码等非对话上下文，还应避免每次全文粘贴，可建立结构化索引： - **Wiki**：将文档处理为结构化页面和链接图，Agent 按需检索相关页面。 - **CodeGraph**：索引代码符号、调用关系和影响路径，在修改代码前先查询影响范围。 ## 推荐设计 较完整的 Agent 上下文管理方案应组合使用： - 最近对话使用滑动窗口保留 - 较旧对话定期摘要 - 关键事实、约束、偏好抽取为原子记忆 - 项目知识和用户画像分层保存 - 通过检索按需召回相关记忆 - 对召回内容设置条目数、Token/字符预算和超时限制 - 对文档、代码等外部资产建立结构化索引，而不是全文载入上下文

## 作用 Agent 上下文管理的目标不是简单拼接 Prompt，而是在有限 token、延迟、成本和模型注意力范围内，设计一套可持续维护信息生命周期的信息架构： - **支持长任务依赖**：长时运行任务可能在很后的步骤依赖早期读取的约定、决策或状态，不能只靠完整历史消息。 - **提升上下文使用效率**：大窗口不等于效果好，信息过多会造成注意力分散和“上下文腐化”。 - **控制成本与延迟**：超长上下文会增加推理时间和费用；上下文频繁变化还会导致 KV cache 失效。 - **明确信息去向**：每块信息都应被明确地保留、压缩、检索或丢弃，并记录原因。 - **控制失败模式**：上下文系统设计的关键，是判断在具体场景中哪种失败最可接受、可观测、可恢复。 ## 原理与设计方案 ### 1. 先明确三个工程问题 - **谁来做管理决策** - 模型自己管理； - 确定性外部策略管理； - 另一个 LLM 负责观察和压缩； - 通过形式化原语管理； - 使用经过 RL 训练的上下文管理器。 - **管理什么粒度的信息** - Token 级； - 消息级； - Episode / 任务片段级； - 状态级。 - **失败时会发生什么** - 压缩失败：可能造成不可预测的信息损失； - 驱逐失败：可能错误丢弃仍可恢复或仍需要的内容； - 检索失败：相关信息没有在需要时进入上下文窗口。 ### 2. 五类可选方案 - **CLM：让模型原生管理上下文文件** - 决策主体：模型自己； - 粒度：文件级； - 优点：灵活，适合模型直接维护工作资料； - 风险：上下文管理能力会与完成任务的能力竞争，模型可能同时背负“做事”和“记忆管理”两重负担。 - **CMV：用虚拟内存和状态 DAG 快照管理** - 决策主体：形式化原语； - 粒度：状态级； - 核心机制：虚拟内存、无损失修剪、状态快照； - 风险：对推理密集型会话的收益可能有限，修剪策略也需要评估缓存兼容性。 - **ContextDB：构建统一记忆操作系统** - 决策主体：RL 训练得到的管理器； - 粒度：Token 级； - 核心机制：统一记忆 OS、多图表示； - 风险：存在跨领域迁移和泛化不确定性，更适合有平台和训练资源的团队。 - **Observational Memory：双 Agent 观察与压缩** - 决策主体：Observer / Reflector 两个 LLM； - 粒度：消息级观察日志； - 核心机制：观察、反思、压缩，并考虑缓存兼容； - 风险：压缩质量不稳定时，错误会在后续任务中累积。 - **CWL：确定性结构化驱逐** - 决策主体：确定性外部策略； - 粒度：Episode 级依赖图节点； - 核心机制：基于结构化依赖执行驱逐； - 风险：当 Agent 缺乏足够元认知、依赖关系识别不准时，策略可能失效。 ### 3. 设计时必须考虑的约束 - **推理基础设施兼容性** - 高频、低延迟场景要优先考虑 prompt caching； - 避免上下文压缩或重排导致缓存频繁失效； - CLM 和 Observational Memory 在缓存设计上更有优势，CMV 的修剪策略需要谨慎评估。 - **失败的可观测性与可审计性** - CMV、CWL 等确定性方案更容易审计“为什么保留或删除”； - CLM、Observational Memory 等 LLM 驱动方案需要额外日志和追踪机制，解释管理决策来源。 - **边际收益拐点** - 信息过少会导致模型猜测； - 信息过多会导致注意力分散； - 应在 token 预算内为每个信息块给出保留、压缩或丢弃的明确理由。 ### 4. 推荐落地路线 1. **诊断先行** - 判断问题来自信息不足、信息过多、任务边界切割错误，还是缓存失效造成成本失控。 2. **从确定性方案建立基线** - 缺少训练资源时，可优先采用 CWL 的结构化驱逐或 CMV 的无损失修剪； - 同时建立上下文装配报告，记录每块信息的来源、状态和处理原因。 3. **再引入智能压缩** - 当确定性策略无法处理复杂语义压缩时，再引入 Observer / Reflector； - 重点验证压缩质量、错误累积和缓存兼容性。 4. **最后评估系统化方案** - ContextDB、CLM 更适合有专门平台团队或训练资源的组织； - 引入前要评估跨领域泛化、可解释性、审计和基础设施成本。 核心原则是：**先用确定性方案建立可观测、可审计的基线，再用智能压缩突破语义处理边界，最后在有资源时用系统化记忆平台统一管理。选型不应追求“最优方案”，而应选择当前场景下失败模式最可接受的方案。**