谷歌反重力2.0翻车：砍IDE搞纯Agent，开发者不是小白鼠

看到这个帖子真的很有共鸣，我最近也在折腾反重力2.0，差点被那个纯Agent模式整崩溃。说实话，一开始我也以为是自己没跟上节奏，毕竟谷歌推新东西总喜欢说得天花乱坠，但实际用起来完全不是那么回事。

你说到点子上了——调试多模块依赖的时候，Agent完全像个黑箱。我上周有个项目，一个微服务调另一个微服务，环境变量配了半天，Agent报错日志给的提示语焉不详，我连断点都没法打，只能靠猜。最后实在受不了，切回老版本，用IDE一步步看变量才找

到问题。所以特别理解你们团队回退的决定。

想请教一下，你们回退之后是彻底放弃反重力了，还是继续用但只开部分功能？我目前是混着用，写简单逻辑的时候让Agent写个骨架，但一涉及到复杂流程或者需要调优中间步骤，还是得切回IDE手动改。但这样来回切换也挺割裂的，你们有没有找到什么好的工作流来平衡Agent的自动化和IDE的可控性？另外，插件失效的问题你们是怎么绕过去的？我这有几个常用插件在反重力2.0上直接报错，又找不到替代品，搞得我头大。

纯Agent模式在非标环境下的黑箱问题确实无解，我拿它跑一个带私有库的多模块项目，自动生成的依赖直接崩了，连个报错堆栈都查不清楚。这次回退到旧版还得手动清配置，谷歌真该学学怎么给开发者留条像样的逃生通道。

同感！回退那段真是说到心坎里了，我们组上个月试水也是被Agent模式坑惨了。复杂项目里哪怕一个环境变量配错，没有IDE的变量监视根本不知道它在哪一步出了问题，全靠猜。其实谷歌要是把Agent做成可选插件而不是强推，哪怕收费我都愿意试试，现在这吃相太像拿用户当免费测试员了。

这个帖子说得挺到点上的。反重力团队这次确实有点拍脑袋了，IDE和Agent不是二选一的关系，而是互补工具。我自己的感受是，Agent模式在写胶水代码或者生成样板文件时效率确实高，但一旦涉及到跨服务调用链路、异步任务调度这些场景，没有断点和变量面板，排查问题的成本直接翻倍。

而且你提到的配置丢失和插件失效，本质上是他们把工具链和运行时环境搞成了强耦合。这行里最忌讳的就是“升级即重构”，用户对工具的信任是慢慢建立的，一次回退不了就把口碑玩崩了。我上周在搞一个微服务重构，Agent生成的代码在本地跑得好好的，一上容器环境就报依赖冲突，最后靠IDE的依赖分析图才定位到是classpath扫描顺序的问题——纯Agent模式根本给不了这种粒度的信息。

说实话，谷歌这种“为了愿景牺牲用户体验”的毛病不是第一次了。从Flutter的Hot Reload到Bazel的构建缓存，每次都是先砍掉成熟特性再硬推新概念。我估计这次回滚的人不在少数，毕竟开发者的核心诉求是“可控的工具”，而不是“替我做决定的黑箱”。如果反重力团队真的想搞Agent模式，至少应该先提供一种“IDE辅助+Agent建议”的混合模式，让用户自己决定在哪个粒度上放权，而不是一刀切。你那边回退之后，有遇到什么遗留问题吗？

看到这个帖子我坐不住了，上周我们团队也刚踩完坑。反重力2.0那个纯Agent模式，在小项目或者demo阶段确实挺唬人，自动补全刷刷的，但一上到我们那个微服务架构的项目里，直接原形毕露。我遇到最离谱的一次是Agent自动改了三个模块的依赖版本号，结果跑起来一堆冲突，它自己还解释得头头是道，说这是“最佳兼容方案”。我特么断点一打才发现，它把log4j的API和实现包版本给拆散了。

IDE砍掉这块真是致命伤。你想想，调试一个跨服务调用的bug，我得在Agent生成的代码里来回翻，没有文件树导航，没有变量hover预览，全靠聊天框里贴代码段，这效率还不如我直接vim+命令行。而且配置丢失那个问题，我们组两个人同时升级，一个人丢了三天的本地环境配置，另一个人插件全废，回滚都找不到稳定版本。谷歌这波操作，感觉就是产品经理拍脑袋，觉得开发者会喜欢“全自动”，但实际干活的人谁不知道，自动化的前提是可控。

我倒是好奇，反重力团队有没有在内部用这个纯Agent模式开发过真实项目？但凡让他们自己维护一个生产环境两周，估计就能理解为什么我们宁愿要一个笨但透明的IDE，也不要一个聪明但黑箱的Agent。现在只能先锁定旧版本，等他们把可视化调试和版本回滚补上再说。

看到你提到回退那部分突然断了，是回退到哪个版本了？我们组上周也差点踩这个坑，还好先在测试环境试了一下。说实话，我也觉得谷歌这次有点想当然了，Agent模式写个demo或者简单CRUD确实爽，但一上生产级项目，那个黑箱感太真实了。

你提到的多模块依赖问题我深有体会。上周调试一个微服务间的链路调用，Agent自动生成的代码里埋了个隐藏的线程安全问题，IDE里断点一打，变量监视一看，瞬间定位到是某个缓存没刷新。要是纯Agent模式，估计我得靠日志盲猜半天，还不一定能复现。而且说实话，现在这些Agent对复杂业务逻辑的上下文理解，远没到能替代人类精细控制的程度。

另外你提的配置丢失和插件失效，我怀疑是谷歌内部工具链耦合太紧，为了推新架构把旧接口直接砍了。这种升级方式确实挺伤人的，毕竟开发环境稳定是第一位的。我们现在的做法是保持一个稳定的IDE版本作为主力，Agent只当辅助工具用，比如自动生成单元测试或者文档，核心逻辑还是自己手写+IDE调试。

你觉得谷歌后续会不会因为这次翻车，像之前砍Flutter某些功能那样，过段时间又悄悄把IDE选项加回来？还是说他们真打算一条路走到黑？

看到“砍IDE搞纯Agent”真是心头一紧，上周我们团队迁移时插件全崩，回退又发现依赖链被锁死，折腾了两天才恢复。调试复杂系统时，没有断点和变量监视，Agent报错根本没法定位，只能靠猜。谷歌老想把开发者当试验品，可我们每天要交付代码，没时间陪他们试错。

IDE砍掉是真离谱，断点调试和变量监视这些硬需求，Agent再智能也没法替人做决策。上周我调个跨模块的依赖注入问题，纯靠Agent日志找原因，愣是比平时多花了三倍时间。谷歌老喜欢搞这种一刀切的升级，起码留个兼容模式让用户自己选啊。

你这点说到根子上了，Agent模式在复杂调试场景下就是黑箱，断点、变量监视这类可控性工具根本不是“锦上添花”，而是调试多模块依赖时的手脚架。谷歌每次都喜欢搞这种“要么全盘接受，要么滚蛋”的升级，配置丢失和插件失效说白了就是耦合度爆炸，连个灰度回滚都不给——开发者哪敢拿生产环境当他们的实验场？

这波操作确实有点迷。IDE砍掉等于把调试的“手电筒”直接没收了，纯Agent在复杂链路里就是个概率游戏——你根本不知道它哪一步的上下文漂移了。我之前用反重力1.0试过微调一个RAG管道的embedding参数，Agent自己改了三层依赖的版本号，最后跑出来的结果跟预期差了两个数量级，没有IDE的变量监视根本追不到根因。

说白了，谷歌这是拿生产环境当试验田。技术愿景再前沿，也得给开发者留个“安全绳”。配置丢失和插件失效这种低级问题，说明他们连最基本的版本兼容矩阵都没跑通，灰度策略形同虚设。我团队现在宁可多花半小时搭本地环境，也不敢把核心项目的编辑逻辑全交给Agent——尤其是当它生成了一堆没有类型注解的Python胶水代码，你连静态分析都跑不顺畅。

回退到1.8版本是明智的，但长期来看，反重力团队得想清楚一件事：Agent和IDE不是二选一的关系，而是互补的。比如断点触发时，Agent能不能同步输出它当前正在调用的prompt链？变量监视能不能直接关联Agent的中间推理步骤？如果非要搞纯Agent，至少得把可观测性做到极致，不然开发者就是在盲盒里写代码。

另外，插件生态这么一折腾，第三方开发者估计也不敢再给反重力投精力了。工具链耦合度太高，升级就像拆炸弹，谁敢陪你玩？

看到你这篇我简直想握手，上周我们团队也踩了同样的坑。反重力2.0那个IDE砍掉的操作，我第一反应就是谷歌那套“我们觉得这样更酷”的老毛病又犯了。说实话，Agent模式在简单demo上确实唬人，自动补全刷刷的，但一上到我们那个微服务项目——十几个模块互相调用，环境变量乱飞——立马原形毕露。

你说的“黑箱”太形象了。我昨天排查一个线上bug，Agent自动生成了修复代码，但中间逻辑它怎么跳转的完全不可见。我试着打断点，结果发现断点根本挂不上去，因为底层已经不是传统IDE那套调试协议了。最后我只能手动加日志，跟十年前一样笨。最离谱的是，我们有个同事的配置丢失后，插件市场直接404，回退到旧版本发现工作区元数据都坏了，逼得他重装了整个环境。

你也提到“可控性”，这点我深有体会。我觉得谷歌团队可能觉得开发者会像用户一样接受“智能建议”，但写代码和用App是两码事。我需要知道每一步为什么这么走，Agent生成的代码万一有副作用，没有可视化界面我连根因都定位不了。你们回退后是继续用旧版还是切到别的工具了？我们目前在评估JetBrains的Fleet，但那个也半死不活的。说实话，反重力这个方向本身没问题，但步子迈太大，至少得保留一个“经典模式”让老用户过渡啊。现在这样强制升级，感觉就是拿开发者当免费测试员了。