王一

这次真冤枉Argon了，真正拖后腿是反重力！ 最近真的被Gemini折磨疯了，Gemini每次发布看似跑分挺高，但是在agent中的表现极其拉跨，最大的槽点就是经常性失忆，跑长任务写着写着就跟脑梗了一样，以下几点尤为突出： 明明没执行过的单元测试，张嘴就敢说全部通过； 开局反复强调的业务红线，写着写着全当耳旁风； 刚解决的依赖冲突，转头又改回去踩一遍。 现在全网都在吐槽Argon额度少性能一般还降智。 今天我实在受不了，挂代理抓包看了一下客户端请求，才发现大家全骂错对象了。 Google宣称 Gemini Argon上下文窗口为1M，但是事情却没那么简单！翻出反重力内置调度器配置那一刻，我整个人都绷不住了。 界面上大字标着 1,048,576 Token的超大上下文，合着全是幌子， 反重力底层的调度器里，清清楚楚写着这几行配置： { "strategy": "CHECKPOINT_STRATEGY_SAME_MODEL", "token_threshold": "50000", "max_token_ceiling": "256000", "max_overhead_ratio": "0.15", "max_user_requests": 10, "is_sync": true, "include_last_user_message": true, "include_conversation_log": false, "include_running_task_snapshots": true, "include_subagent_snapshots": true, "include_artifact_snapshots": true } 解释一下最重要的几处配置： token_threshold: 50000：在消耗50K token之前agent处于安全区，自由发挥，上下文历史原汁原味地保留。一旦累计到50K，系统并不会粗暴突然掐死，而是进入待命状态。 is_sync: true:意思是同步等待。系统在等一个合适的时机，也就是逻辑断点，一旦等到，立刻强制执行压缩！ 所谓逻辑断点，就是Agent在写代码时告一段落的停顿点，主要有这三种： 完成 task.md 的一个小步骤：比如它刚刚把清单里的 [ ] 修改勾选成了[x]； 切换子代理：主Agent把活派给子 Agent，或者子 Agent 把结果汇报给主 Agent 时； 用户对话达到 10 次（max_user_requests: 10）：你跟它来回扯皮聊了 10 轮。 也就是说只要 Token过了50K，Agent 一旦停下来触发逻辑断点，系统反手就强制压缩。 max_token_ceiling: 256000：意思当Token消耗到 256K时，系统不管它正在改代码、读日志还是在干嘛，直接强制截断。这是用来兜底、防止服务器被无限死循环撑爆的防线。 然而就像刚才说的，现实是绝大多数会话在50K至70K时就被强制压缩，远早于256K上限。 include_conversation_log: false：它会直接把你前面所有的聊天记录、工具调用、报错日志全部删干净，一条都不留。 搞清楚配置后现在还原一下业务场景： 0 ~ 40K：你提了需求，Agent读了项目结构、3 个相关代码文件，写出了task.md计划。此时一切正常。 40K ~ 55K：agent修改了第一个文件，跑了一次终端测试，产生了一些报错和输出日志。此时token消耗来到50K！ 55K： Agent解决完第一个小报错，顺手在task.md上打了个勾 [x]，准备开始改第二个文件。 逻辑断点此时被触发！系统发现当前上下文已经消耗55K的token，而且刚好处于完成一个小步骤的停顿点，立刻强制执行压缩，把你前55K窗口里的报错历史、聊天记录直接删除！只保留一个16K的残缺总结。 这就是为什么大家普遍觉得Agron思考挺全面，但是跑长任务跑着跑着，模型就突然跟脑抽了一样失忆的根本技术原因。 然而最难绷的是看他们内部的系统提示词，Google自己的工程师都快被搞崩溃了，在提示词里求爷爷告奶奶地加：“求你分清文件是真改了还是只读了”、“千万别把没测的代码标为通过”。但是依然毫无卵用，该忘还是忘。 基于此我总结了一套3个避坑操作： 1. 重要的规矩约束千万别只在聊天框里说。核心规范、禁动文件，全部老老实实写进项目的 rule 文件或 task.md 里，因为只要有文件它能一直读到。 2. 坚决不要开长会话 别指望一个对话窗口跑完整个大工程。写完一个小功能或模块，直接开新会话，把任务拆开了搞。 3. 永远不要信它嘴里说的测试通过 它说改好了别当真。必须逼它在终端里敲真实测试命令，或者切其他agent进行审查。