Antigravity 那个反复读同一文件的死循环，Gemini 模型几乎 100% 中招

看到论坛里有人贴 Antigravity agent 的截图，三小时还在同一个文件里打转，换 Claude 两分钟就收工。这个对比太刺眼了，忍不住想聊聊。
bug 现象：不是卡住，是原地打转
有用户反馈，Antigravity agent 在处理代码问题时，不会直奔主题去改代码，而是陷入一种奇怪的重复行为——它开始逐个分析项目文件，读完 NfcTerminalPage.tsx，跳到 App.tsx，然后再绕回 NfcTerminalPage.tsx，像被设定好路径的机器人，无限循环。截图显示，三小时后 agent 还在同样的文件里逐行"分析"，进度条没动过，控制台输出却在持续滚动。
这不是慢，这是在假装干活。你 cancel 掉任务，它就停；你不 cancel，它能跑到天荒地老。有用户统计过，Gemini 3.7 Flash 触发这个问题的概率接近百分之百， autonomous workflow 在这种表现下完全没法用。
模型之间的差距不是一点点
同一个任务，切到 Claude Sonnet 4.6 的时候，情况完全不同。截图里 Claude 的执行轨迹很干净：读文件、定位问题、改代码、收工，两分钟内走完流程。Thinking 模式下也没有出现反复回读的情况，每一步都在往前推进。
这里的关键差异不在"快慢"，而在 agent 是否具备"我已经读过这个文件了"的判断力。Claude 在上下文里记住了自己读过什么，不会把已经分析过的代码片段重新当成新信息处理。Gemini 的问题恰恰在这里——它读了，但没"记住"自己读过，下次轮到同样的上下文窗口时，又从头开始读。
这不是 prompt 写得不好，是 agent 循环的逻辑缺陷
有人可能会想，是不是用户给的 prompt 不够明确，导致 agent 不知道下一步该干嘛。但从截图和描述来看，任务本身是 straightforward 的——修一个代码问题。agent 的推理链路没有断，它知道自己要修什么，问题出在"读文件"这个动作被错误地设计成了循环的终点。
正常的 agent 循环应该是：读文件 → 分析 → 判断是否需要读更多 → 定位问题 → 修改 → 验证 → 结束。而 Gemini 在 Antigravity 里的实际路径是：读文件 → 分析 → 判断需要读更多 → 重新读已经读过的文件 → 分析 → 再判断需要读更多 → 再读一遍……每一步看起来都在前进，实际上一直在原地踏步。
这说明 agent 的"下一步决策"逻辑里，缺少一个关键的去重机制。当上下文里已经包含某个文件的内容时，agent 不应该再把它列为"待读取"的目标。Claude 的 agent 实现里显然有这个检查，Gemini 的没有，或者有但没生效。
对实际工作流的杀伤力
如果你在用 Antigravity 做 autonomous coding——让它自己读 PR、自己修 bug、自己提 commit——这种无限循环等于把整个流程废掉。你不可能一直盯着屏幕等它结束，等它自己意识到该停，它永远不会。
更麻烦的是，这种循环不是偶发的。Gemini 3.7 Flash 几乎每次必中，说明这不是某个特定 prompt 触发的 edge case，而是模型与 agent 框架交互时的系统性问题。今天碰巧修好了，明天换个任务可能又触发。稳定性这关过不了，autonomous workflow 就只是个演示功能。
反过来看 Claude Sonnet 4.6 在 Antigravity 上的表现，至少目前是能用的。不是因为它"更快"，而是因为它在每一步决策上都更稳——知道什么该读、什么该跳过、什么时候该停。这种判断力对 agent 来说比推理能力更底层，没有它，再强的模型也只是在空转。
一点判断
Gemini 系列模型在纯对话和单步推理上其实不差，但在需要多步工具调用的 agent 场景里，上下文去重和进度感知是硬伤。这不是 prompt engineering 能补的，需要 agent 框架侧加防护——比如在调用文件读取工具前，先查一遍"这个文件的内容是否已经在上下文里"，如果在，直接跳过并标记为已完成。
Antigravity 如果想在 Gemini 上可用，这个去重机制必须是框架层的，而不是指望模型自己"记性好"。模型记性不好，框架就得替它记。