对于一个与大型语言模型（LLM）打过交道的开发者来说，上下文管理都是一个绕不开的核心问题。它不仅决定了 AI 的智能程度，也直接关系到系统的性能和成本。
上周研究了各家 Agent 系统的实现，各家的上下文管理策略都不相同。最简单最傻的策略是一个不断累加对话历史，这种策略很快就会遇到 Token 限制和 API 的成本问题。
如果你是一个技术负责人，或者正在开发 AI Agent 相关的产品，需要在性能和成本之间找到平衡点，这篇文章应该对你有一些帮助。
今天所聊的内容是基于对 Claude Code、Manus、Gemini CLI，OpenManus 等多个项目的分析，以及自己在实践中的一些思考。
为什么要做上下文管理？
最新的 LLM 现在提供 128K Token 或更多的上下文窗口。听起来还挺多的，但在真实世界的 Agent 场景中，这通常远远不够。
尤其是当 Agent 与网页或PDF等非结构化数据交互时，Token 数需求会爆炸。
并且，随着 Token 数的增加，模型性能会在超过一定长度后明显下降，这就像让一个人同时记住一本书的所有细节，理论上可能，实际上很难做好。
就算我们的大模型有更多的窗口上下文支持，成本也是一个需要考虑的问题，就算有前缀缓存这样的优化，但传输和预填充每个 Token 都是要付费的。
为了解决这些问题，许多团队选择了压缩策略。但过度激进的压缩不可避免地导致信息丢失。
这个问题的本质在于 Agent 必须根据所有先前状态预测下一个动作——而我们无法可靠地预测哪个观察结果可能在十步之后变得至关重要。从逻辑角度看，任何不可逆的压缩都带有风险。
接下来我们看一看各项目的上下文管理策略，看看从中能否给到各位看官一些启发。
OpenManus 的上下文管理策略
OpenManus 采用了一个相对简单直接的上下文管理方案，主要特点是：
- 轻量级消息列表机制
- 使用固定长度（默认100条）的消息列表作为内存存储
- 采用简单的 FIFO（先进先出）策略，超出限制时截断最早的消息
- 没有智能的上下文压缩或摘要机制
- Token 限制处理
- 实施硬性 token 检查，超限直接抛出异常终止
- 缺乏优雅的降级策略或自适应窗口裁剪
- 在长对话或工具密集场景中容易触碰上限
虽然上下文管理比较简单，但是 OpenManus 为不同使用场景提供了定制化的上下文处理，如浏览器场景会动态注入浏览器状态，截图保存等
总的来说，这是一个原型实现，并不适合作为生产级环境使用，如果要上到生产环境需要自行做精细化的处理和架构。
Manus 的上下文管理策略
Manus 没有开源，但是其官方有发一篇文章出来。
Manus 采用了一种创新的方法：将文件系统作为终极上下文存储，而不是依赖传统的内存中上下文管理。
文件系统作为存储有如下的核心特性：
- 无限容量：文件系统大小不受限制
- 天然持久化：数据自动保存，不会丢失
- 直接操作：智能体可以主动读写文件
- 结构化记忆：不仅是存储，更是结构化的外部记忆系统
相对于传统的将完整的观察结果保存在上下文中，容易超限，Manus 实现了可恢复的信息压缩：
- 观察结果指向外部文件（Document X, File Y）
- 上下文中只保留引用，不保存完整内容
- 需要时可以从文件系统恢复完整信息
具体实现：
- 网页内容可从上下文移除，只保留 URL
- 文档内容可省略，只保留文件路径
- 实现上下文压缩的同时不会永久丢失信息
Manus 团队认为，如果状态空间模型能够掌握基于文件的记忆管理：
- 将长期状态外部化而非保存在上下文中
- SSM 的速度和效率优势可能开启新型智能体
- 基于 SSM 的智能体可能成为神经图灵机的真正继任者
与 OpenManus 的简单消息列表管理，Manus 的方案更加成熟：
- OpenManus：固定长度消息列表，硬性截断，缺乏智能管理
- Manus：文件系统作为无限外部记忆，可恢复压缩，主动记忆管理
Claude Code 的上下文管理
Claude Code 没有开源代码，但是国外有大神反编译其源码（虽然大神自己说:这并非真正意义上的反编译或逆向工程尝试，而更像是对 Claude 团队杰出工作的致敬。）
地址：southbridge-research.notion.site/claude-code…
通过反编译内容的分析，可以大概了解一些其策略和比较巧妙的点：
TodoWrite 工具
Claude Code 引入 TodoWrite 工具，支持模型主动维护自己的 To-Do 列表，替代传统的多 Agent 分工策略。
其优势：
- 专注：Prompt 中反复提醒模型参考 ToDo，始终聚焦目标。
- 灵活：「交错思考」机制使得 ToDo 可动态增删。
- 透明：用户可实时查看计划与进度，提高信任度。
Token 统计的反向遍历
Toke 统计从后往前查找这个细节相当精妙。大部分系统都是傻乎乎地从头遍历，但 Claude Code 意识到了一个关键事实：Token 使用情况的统计信息总是出现在最新的 assistant 回复里。这种”知道去哪找”的优化思路，把原本可能的 O(n) 操作优化到了 O(k)，在高频调用场景下，这种优化带来的性能提升是指数级的。
92% 阈值
留 8% 的缓冲区既保证了压缩过程有足够的时间完成，又避免了频繁触发压缩带来的性能开销。更重要的是，这个缓冲区给了系统一个”反悔”的机会——如果压缩质量不达标，还有空间执行降级策略。
8 段式结构化摘要
Claude Code 的 8 段式结构特别值得借鉴：
markdown
1. Primary Request and Intent - 主要请求和意图
2. Key Technical Concepts - 关键技术概念
3. Files and Code Sections - 文件和代码片段
4. Errors and Fixes - 错误和修复
5. Problem Solving - 问题解决过程
6. All User Messages - 所有用户消息
7. Pending Tasks - 待处理任务
8. Current Work - 当前工作状态
优雅降级
当压缩失败时，系统不会死板地报错或者强行应用低质量的压缩结果，而是有一整套 Plan B、Plan C。从自适应重压缩，到混合模式保留，再到最后的保守截断——每一步都在努力保护用户体验。这种”永不放弃”的设计理念，让系统在各种极端情况下都能稳定运行。
向量化搜索
长期记忆层引入向量搜索，实际上是在为 AI 构建一个”联想记忆”系统。当用户提出新问题时，系统不仅能看到当前对话，还能”回忆”起过去处理过的类似问题。这种跨会话的知识迁移能力，让 Claude Code 从一个简单的对话工具进化成了一个真正的智能编程助手。
Gemini-cli 的上下文管理
Gemini-cli 的上下文管理走了一条和 Claude Code 相似但更加轻量的路线。它的核心理念很简单：文件系统就是天然的数据库。
三层混合存储架构
与 Claude Code 类似，Gemini-cli 也采用了分层设计，但实现更加简洁：
第一层：纯内存工作区
- 存储当前会话的聊天历史、工具调用状态、循环检测状态
- 零延迟访问，不涉及任何 I/O 操作
- 会话结束即清空，不留痕迹
第二层：智能压缩层
- 触发阈值：70%（比 Claude Code 的 92% 更保守）
- 保留策略：最新 30% 的对话历史
- 压缩产物：5 段式结构化摘要
第三层：文件系统持久化
- 全局记忆：
~/.gemini/GEMINI.md - 项目记忆：向上递归查找直到项目根目录
- 子目录上下文：向下扫描并尊重忽略规则
70/30
Gemini-cli 选择了 70% 作为压缩触发点，30% 作为保留比例。这个比例设计很有讲究：
为什么是 70% 而不是 92%？
- 更早介入，避免紧急压缩导致的卡顿
- 给压缩过程留出充足的缓冲空间
- 适合轻量级应用场景，不追求极限性能
30% 保留的合理性
- 刚好覆盖最近 5-10 轮对话
- 足够维持上下文连续性
- 不会让用户感觉”突然失忆”
5 段式压缩：够用就好
相比 Claude Code 的 8 段式结构，Gemini-cli 的压缩更简洁：
markdown
1. overall_goal - 用户的主要目标
2. key_knowledge - 重要技术知识和决策
3. file_system_state - 文件系统当前状态
4. recent_actions - 最近执行的重要操作
5. current_plan - 当前执行计划
忽略规则
Gemini-cli 的 .geminiignore 机制是个亮点：
独立但兼容
- 可以单独在非 git 仓库中生效
- 与
.gitignore并行工作，互不干扰 - 每个工具都有独立的忽略开关
明确的约束
- 修改
.geminiignore需要重启会话才生效 - 这不是 bug，而是 feature——避免运行时状态混乱
Gemini-cli 的设计哲学可以总结为：不求最优，但求够用。
它没有追求理论上的完美压缩比，也没有搞复杂的向量检索，而是用最简单的方案解决了 80% 的问题。这种务实的态度在工程实践中往往更受欢迎——系统简单意味着 bug 少，维护容易，用户上手快。
特别是”文件系统就是数据库”这个理念，虽然听起来有点”土”，但在实际使用中却异常可靠。你不需要担心数据库挂了、连接断了、事务死锁了…文件就在那里，看得见摸得着，出了问题 cat 一下就知道怎么回事。
这种设计思路值得很多过度工程化的项目学习：有时候，简单就是最好的复杂。
小结
上下文是智能的边界，压缩是性能的艺术。
在与大型语言模型打交道的过程中，上下文管理已成为决定智能上限与系统稳健性的关键。虽然现代 LLM 提供了百万级 Token 的窗口，但在实际 Agent 场景中，这远远不够，尤其当涉及非结构化数据（如网页、PDF）时，Token 使用会迅速膨胀。即使有前缀缓存等机制，成本与性能的双重压力仍然存在。因此，上下文压缩成了必选项——但压缩得太激进，又会导致信息丢失，损害 Agent 的决策能力。
聪明的系统不是记住所有，而是记住该记住的。
应对上下文限制的最佳方式不是简单保留或截断历史，而是构建一个具备“记忆力”的智能系统。Claude Code 以三层记忆架构为核心（短期、高速；中期、结构化压缩；长期、跨会话向量化搜索），同时引入 TodoWrite 工具，让模型自我管理计划任务。这使得 Agent 能专注目标、灵活调整、透明运行，形成类人思维般的任务记忆系统。关键机制如 Token 反向遍历、92% 阈值缓冲、8段式摘要结构与优雅降级策略，共同打造了一个稳健又高效的上下文生态。
工程的智慧在于‘够用’，而非‘极致’。
对比 Gemini-cli、OpenManus 与 Manus 的上下文策略，可以看出不同系统在工程实现上的取舍哲学。Gemini-cli 采用实用主义的轻量分层设计，70/30 压缩策略既简单又高效，让用户可控又无需担心性能瓶颈；Manus 则大胆将文件系统作为智能体的“外部大脑”，通过引用而非存储规避 Token 限制；而 OpenManus 则为最小可运行原型提供了基础模板。这些方案展现出一个共识：上下文不一定要复杂，关键在于是否服务于目标。
以上。