从 Claude Code到 Gemini CLI，AI Agent 的上下文管理策略

对于一个与大型语言模型（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 则为最小可运行原型提供了基础模板。这些方案展现出一个共识：上下文不一定要复杂，关键在于是否服务于目标。

以上。