欧易数字货币交易所 更快、更好、更强

产品工程负责人Kevin Hou的一封长文，让Google Antigravity 2.0最近的争议有了一个官方出口。语气并不修饰，甚至带着一点工程团队常见的直白——在用户过渡体验上“搞砸了”，正在加班修复。

争议点本身不复杂：新版本强制将IDE与Agent Manager拆分为两个独立应用。对习惯在单一界面里完成编码、调用与调试的开发者来说，这种拆分带来的不是功能增强，而是工作流被重新切断了一次。

但如果把视角从“使用体验”拉远一点，这次调整其实更接近一次架构层重写，而不是UI层改版。

Kevin的解释里提到一个核心判断：AI开发工具正在经历第四次范式迁移，从代码补全、智能对话、单智能体协作，进入多智能体并行阶段。这个判断并不新，但Google这次给出的回应方式，是直接在产品结构上做了对应映射。

IDE负责“写代码”，Agent Manager负责“调度智能体”，两者分离意味着开发环境不再以文件或项目为中心，而是以任务编排为中心。某种程度上，代码只是结果，而不是组织单元。

这种变化的压力来自用户行为本身。随着自动化能力提升，一个开发任务背后可能同时运行多个智能体：有的负责生成代码，有的做测试，有的处理依赖冲突，还有的在做文档和接口对齐。如果仍然维持单一工作台结构，很快就会遇到可视化与调度层的瓶颈。

拆分应用，本质是在为“并发智能体密度”做准备。这个指标目前还没有行业统一定义，但已经开始隐约影响产品设计路径。

不过工程逻辑的成立，并不自动等价于用户体验的接受度。社区的负面反馈集中在一个非常现实的问题上：工作流被打断，迁移成本上升，而收益并不直观。Google内部显然低估了这一步骤在“习惯层”上的摩擦。

这种错位在AI开发工具领域并不罕见。过去一年，从Copilot类工具到Agent框架产品，几乎都在经历同一类张力：底层能力快速进化，但界面与认知模型滞后，导致用户感知到的不是能力跃迁，而是工具复杂度上升。

Kevin在回应中提到的另一个判断更值得放在行业背景里看——“工作即产品，而非代码文件即产品”。这句话表面像产品愿景，实质上是在重新定义开发单元。

如果说传统软件开发以代码库为中心，那么多智能体系统更接近任务网络结构：一个产品不再由一组静态代码构成，而是由持续运行的任务流、代理节点与反馈循环组成。代码只是这些流动结构中的某个瞬时状态。

一旦这个逻辑成立，IDE的角色自然会被弱化，取而代之的是“任务编排层”和“智能体调度层”。拆分应用，其实是在提前暴露这种分层结构。

只是问题也在这里出现：行业还没有完全准备好接受这种转变，但产品已经开始按这个方向重构。

Google这次的调整，更像是一次提前透支未来结构的尝试。用户在当下感受到的是割裂，而工程团队看到的是可扩展性。

两者之间的时间差，往往就是新一代开发工具真正的摩擦来源。