深度解码 Gemini CLI：状态栏那个跳动的 Memory 到底是什么？

在使用 Gemini CLI尤其是在开启了实验性功能后时细心的开发者可能会注意到状态栏右下角出现了一个memory: XXX MB的指标。这个数字有时是 100 多 MB有时甚至达到 200 MB 以上而且在对话过程中会“跳动”甚至逐渐减小。这到底是已用 RAM 内存还是某种磁盘缓存为什么它不像上下文 Token 数那样稳定增长今天我们就来拆解 Gemini CLI分层记忆系统 (Memory V2)的核心机制。核心定义它是“工作记忆”的物理体积简单来说状态栏显示的Memory数值代表的是当前会话活跃上下文Active Context的序列化物理大小。与传统的 LLM 聊天界面不同Gemini CLI 是一个高度集成的工程工具。你的每一轮对话不仅仅包含文字它更像是一个精密打包的数据包其构成如下多层级指令来自全局、项目、子目录的GEMINI.md文件。工具输出数千行的代码搜索结果Grep、文件内容Read、Shell 命令输出。多模态数据你上传的屏幕截图或图片。技能与 MCP 数据已加载的 33 个技能Skills及其背后的 API 文档。当这些数据被打包准备发给 Gemini 模型时CLI 会计算它们的物理体积。152.8 MB 的数值说明你的“大脑”里此时正装着相当庞大的背景资料。为什么数字会变小——按需加载与自动压缩用户经常观察到一个有趣的现象开始工作后Memory 数字会逐渐变小且不稳定。这主要归功于两项核心技术1. jitContext (Just-In-Time Context)如果你的项目有几百个文件全部塞进上下文会瞬间挤爆 Token 限制。jitContext开启后CLI 不会一次性加载所有GEMINI.md。当你切换到不同的子目录工作或者任务目标改变时CLI 会动态地“卸载”不再相关的背景指令并“装载”当前需要的指令。这种“快进快出”的机制导致了 Memory 数值的上下波动。2. Context Compaction (上下文压缩)为了节省昂贵的 Token 费用并提高响应速度Gemini CLI 内置了类似“压路机”的机制。它会自动检测历史对话中的冗余信息将巨大的中间日志输出进行摘要化Summarization或直接剪枝Pruning。当你深入讨论某个问题时CLI 正在后台帮你清理掉那些过时的过程数据。Memory V2像代码一样管理记忆在配置中我们经常能看到memoryV2: true。这代表了 Gemini CLI 最新的记忆架构。它将记忆从“黑盒子数据库”改成了透明的、可提交到 Git 的 Markdown 文件体系。Global全局偏好如“我喜欢用 TypeScript”。Project项目规范如“本仓库使用 Vitest”。Subdirectory子模块知识。Private本地私有笔记如本地测试环境 IP。常用管理命令如果你想看看 AI 现在到底“记得”什么或者觉得上下文太重了可以使用以下交互式命令/memory show展示当前模型能看到的所有指令和事实。/memory inbox查看autoMemory帮你自动挖掘出来的经验片段。/memory prune手动清理那些不再需要的持久化记忆。总结那个跳动的MB数值其实是 Gemini CLI动态管理上下文健康度的体现。它不是传统的资源占用指标而是你与 AI 协作时的信息通量。下次看到数字变小请不必担心那通常意味着 CLI 成功地帮你精简了知识负担让模型能更专注地解决当下的问题。