声明：本文由 AI 辅助创作，经作者核实与修订。
一次典型的 session 会话
平时用 Google Antigravity 写代码，编码的最佳实践通常是一个会话只做一件事。
但在日常写代码时，这件事很难把握。很多任务我们很难度量它到底会消耗多少 Token，也没办法准确评估手头的任务粒度拆得是不是够细。
实际写起来的状态往往是：感觉一直在往同一个会话里面塞东西。刚开始聊着改着，好像一切都很顺畅。但塞着塞着，模型开始逐渐偏离原本的目标。前面定好的逻辑约束失效了，给出的代码变迟钝了，甚至开始改动一些明令禁止触碰的模块。
这时候很难准确判断：究竟是任务本身的粒度拆得太粗，还是因为在同一个会话里堆了过多的内容，导致模型的能力出现劣化。
偏偏 Antigravity 把整个上下文监控完全藏起来了。
为什么现在的 Coding Agent 都倾向于把上下文藏起来
去看看其他几个主流工具的现状，会发现隐藏底层指标已经成了整个行业的普遍做法。
早期无论是 OpenAI Codex 还是各类模型接口，Token 一直是摆在台面上的计量单位。每次请求花了多少、窗口还剩多少，大家心里都有数。
但现在的 Codex 环境（包括桌面端和 CLI），默认也倾向于把 Token 计数器隐藏起来。用户如果想看，往往需要专门跑到设置里翻找开启选项，或者在终端敲 /status、/statusline 这类命令手动调出。
Claude 也是同样的思路。普通对话界面完全隐藏底层细节，只有在开发者针对性排查时，才提供 /context 命令去查看分布条，或者在达到一定阈值时在后台触发自动压缩。
Cursor 在对话和 Composer 里虽然会对 @ 引入的文件大小有一定感知，但在长对话里，大家同样容易不知不觉把几十个文件的历史塞进同一个上下文。
为什么这些 Agent 工具都不约而同把监控藏起来了？
从产品设计上看，它们都在追求一种无感知的自主代理体验。各个平台希望开发者只管提业务需求，模型在后台调工具、改文件、跑测试，底层的 Token 消耗被视为应该屏蔽掉的底层细节。
再加上现在的底座模型标称容量越来越大（比如 Gemini 标称支持 100 万 Token），更给了产品团队隐藏计数器的理由，让大家觉得这个空间怎么塞都塞不满。
底层确实做了一道兜底：按我的实测，当会话累积到约 220k Tokens 附近时，系统会自动执行 Checkpoint 压缩，折叠历史轮次。
但在实际编码中，这种完全隐藏的设计让开发者失去了尺度感。任务粒度拆得合不合适、会话是不是过载了，完全没有参考依据。
自动压缩，好事坏事？
最近在评论区看到有人聊到这个机制，不少人觉得自动压缩纯粹是坏事，甚至抱怨凭什么擅自压缩，导致自己没法随时往上翻聊天记录。
这件事需要区分具体的场景。自动压缩确实会丢失细节，但在很多时候它是有益的，甚至是必要的保护机制。
最典型的有益场景是服务端 KV Cache 的缓存时效与保活。
大模型服务端的 Prompt Cache 通常有生存时间（TTL）。如果你写到一半离开工位去开会或吃饭，长时间没有新的动作，服务端的缓存就会逐渐失效。
缓存一旦失效，等你几个小时后回来敲下一句话时，服务端就必须把此前长达二十多万 Token 的整个历史重新预填充一遍（冷启动 Re-prefill）。这会导致下一轮响应极其缓慢，还会消耗大量的算力额度。如果会话已经被压缩成一份摘要，需要重新预填充的就只剩摘要的长度，冷启动的代价会小得多。更何况压缩这次操作，会让缓存时间重新刷新顺延。
至于想在会话里留着所有历史记录随时翻看，这是把会话当成了聊天记录查看器。超长上下文天然存在中段信息被忽略的问题（Lost in the middle）。真正的聊天记录在本地的 SQLite 数据库与 transcript.jsonl 日志里都有完整留存，不需要让模型的会话内存去硬扛。正确的做法是把重要的上下文结构化沉淀下来，而不是依赖单个会话做记录管理。
会话 Token 监控与处理实践
既然需要知道会话到底吃了多少东西，我就做了一个常驻在 Mac 菜单栏的小工具 agy-menubar。
交互参考了 macOS 的系统指示器（比如电池电量百分比、CPU 指示器）：用 CoreGraphics 绘制一个 18×18 矢量圆环，把容量分母直接对齐到 220k 实际压缩线。
- 绿色（占用低于 60%）：空间充裕；
- 橙色（占用 60% 至 85%）：上下文开始膨胀；
- 红色（占用达到 85% 以上）：接近 220k 自动压缩线。
点开菜单可以看到详细指标：
Mac 顶部状态栏:
[◎ 104.2k] Mon Oct 19 14:50
点击下拉菜单:
┌──────────────────────────────────────────────┐
│ AI Model Quota Limits │
│ [■■■■■□□□□□□□] 47.4% (104,242 / 220k) │
│ ──────────────────────────────────────────── │
│ 提示词缓存 102,005 (97.8%) │
│ 本轮输入 2,237 │
│ 剩余空间 115,758 (52.6%) │
│ 当前模型 Gemini Flash │
│ ──────────────────────────────────────────── │
│ 切换跟踪会话 ▶ │
│ ✓ 自动跟踪最新活跃会话 │
│ ──────────────────────────────────────────── │
│ 复制会话 ID ⌘C │
│ 在 Finder 中打开日志 ⌘O │
│ 立即刷新 ⌘R │
│ 退出 ⌘Q │
└──────────────────────────────────────────────┘
但是在真实实践里，当菜单栏亮起红色的时候，普通人的第一反应往往不是输入 /compact。
没有人愿意主动去压缩自己的上下文。真实的情况往往是不知道该怎么办，或者只能干瞪眼。因为心里清楚一旦压缩，刚才聊过的某些代码细节、临时约定的变量和局部约束可能就找不回来了。
这种时候其实有两个解法，但使用时机必须分清楚：
系统原生提供的 /compact，适合的是当前这个任务中的某一个具体步骤彻底做完了。比如当前计划里的第一步方案设计做完了，或者核心函数改完并通过了编译测试，代码处于一个明确的稳态，这时可以敲一次 /compact 把刚才做完的步骤固化成摘要，再进下一步。
不建议在任务进行到半途时做 /compact。如果你正改到一半、几个文件处于半生不熟的中间状态，一旦敲了压缩，模型的工作记忆立刻被破坏，直接丢失当前的思路和上下文断点。
另一个解法是 /handoff。如果你排查一个 Bug 试了四五种方案，终端刷了大量的报错日志，上下文已经被这些噪音填满了，这时候敲 /compact，压缩算法会把这些失败的弯路也当作上下文总结进去。更有效的做法是用 /handoff 把当前做好的成果、已经证伪的结论和下一步目标写成一份结构化文档，直接结束当前会话，开一个全新的会话接棒。新会话没有历史噪音，注意力是满格的。
上下文管理的几条实际方法
结合这个监控小工具和实际写代码的体会，在 Antigravity 里做好上下文管理，有几条比较管用的习惯：
-
别被 100 万大窗口麻痹
按我的使用经验，把上下文维持在 50k 到 150k 之间，模型的响应速度和对指令的依从度最好。超过 150k 后，推理延迟和注意力衰减都会逐渐显现。 -
步骤做完再压缩，半途绝不压缩
每完成一个确定性的工程步骤，再考虑做/compact固化成果。不要在改动未完成、上下文正在高速变动时执行压缩。 -
不变量写进规则文件，会话只留眼前的变动
容易被遗忘但必须遵守的规范，写进项目根目录的规则文件里（如AGENTS.md、GEMINI.md或.agents/rules/）。规则文件每轮都会作为强约束载入，不怕被压缩；动态会话只用来讨论当下的代码。 -
留意提示词缓存（Prompt Cache）
观察下拉菜单里的 Prompt Cache 占比。如果缓存命中率维持在 90% 以上，说明前面的系统说明和静态代码索引在被高效复用；如果命中率很低，说明会话刚经历重构或输入发生了大幅抖动。 -
噪音过多时主动切换会话
如果会话被大量排错日志、试错弯路污染，用/handoff把成果交接给新会话，比在旧会话里死磕更有效。
开源与安装
agy-menubar 基于 Python 3 和 macOS 原生 PyObjC 编写，没有引入第三方包，也没有起 Electron。它只读取本地 SQLite WAL 和会话日志，带有文件修改时间缓存，不发起任何网络请求。
在 macOS 终端运行一行命令即可安装：
curl -fsSL https://raw.githubusercontent.com/kuhung/agy-menubar/main/install.sh | bash
安装脚本会把可执行文件放到 ~/.local/bin/agy-menubar，并通过系统的 LaunchAgent 服务自动管理后台常驻。
如果想自定义压缩水位线（例如设为 180k），可以使用参数启动：
agy-menubar --limit 180000
卸载同样只需一行命令：
curl -fsSL https://raw.githubusercontent.com/kuhung/agy-menubar/main/uninstall.sh | bash
代码放在 GitHub 开源，协议是 MIT：
kuhung/agy-menubar
如果你也是每天在 Mac 上用 Antigravity 写代码，经常写着写着不知道会话塞了多少东西，跑一下安装脚本就能常驻在菜单栏。遇到问题或者有需要改进的地方，可以直接在仓库提 Issue。