我越来越确定:AI 工具的下一站,不是更聪明,而是接管工作流

这两天，AI 开发者圈里有一条消息不算特别炸，但我越看越觉得，它很可能是今年 AI 编程工具最值得盯的一条线索： Google 准备把 Gemini CLI 迁移到 Antigravity CLI。

按照公开信息，Google 正在 sunset Gemini CLI，转向 Antigravity CLI。Antigravity CLI 被定义为一个 agent-first terminal experience，构建在 Google Antigravity 2.0 平台上。原来 Gemini CLI 里的 Agent Skills、Hooks、Subagents、Extensions 等能力会被保留或迁移，Extensions 变成 plugins，同时新增统一后端上的多 Agent 工作流。

更关键的一点是：从 2026 年 6 月 18 日开始，Gemini CLI 和 Gemini Code Assist IDE extensions 将停止为免费用户，以及 Google AI Pro / Ultra 消费级用户服务请求。企业和 Standard license 用户保留访问。 这听起来像一个产品迁移公告。 但我不这么看。

我认为，这不是 Google 给 CLI 改了个名字，也不是 Gemini CLI 体验不好所以换个壳。它真正说明的是：AI 编程工具正在从 Copilot 时代，进入 Agent 接管时代。 Copilot 时代，AI 是你旁边的副驾驶。你写代码，它补全；你提问题，它回答；你打开 IDE，它像插件一样待命。

Agent 时代，AI 不再满足于坐副驾。它开始要钥匙、要地图、要权限、要任务队列，甚至要接管你的一部分驾驶动作。 表面上变的是 CLI。 底层变的是权力结构。

如果只看新闻表面，Google 的逻辑很顺：Gemini CLI 是旧工具，Antigravity CLI 是新平台。旧工具迁移到新工具，保留核心能力，增强多 Agent 工作流，统一后端体验。 产品经理会觉得，这不就是正常产品迭代吗？ 开发者不一定这么想。 Hacker News 上有一个评论很尖锐，大意是：告别你能控制 API Key 的计量使用，迎接不透明的定价和使用限制。

这句话为什么刺耳？因为它点破了开发者对 AI 工具最敏感的一件事：我到底是在使用一个工具，还是被迁移进一个平台？ 工具和平台是不一样的。 工具像锤子。你买来，用它砸钉子。锤子不会关心你在哪里砸、给谁砸、一天砸多少下。 平台像高速公路。它也让你跑得更快，但它会决定入口、出口、收费站、限速、规则，甚至未来某一天，它可以告诉你：这条路不对普通车开放了，请换到我们的专属车道。

Gemini CLI 到 Antigravity CLI 的迁移，最值得关注的不是“Antigravity 好不好用”，而是 Google 把开发者从一个相对独立的 CLI 工具，推向一个 agent-first 的统一平台。

这背后是一条很清晰的产业逻辑： 模型公司不想只卖模型。它们想控制工作流。 过去一年，大家争的是谁的模型更强、谁的上下文更长、谁的价格更便宜。现在争的东西开始变了：谁能把 Agent 嵌进你的日常工作，谁能成为任务执行的默认入口，谁就能拿到更高的留存、更稳定的收入、更深的用户锁定。 这不是阴谋论。 这是商业基本规律。

《创新者的窘境》作者克莱顿·克里斯坦森提醒我们：破坏性创新往往从边缘开始，但真正改变行业结构的，是它后来重新定义了主流价值网络。

Gemini CLI 这种工具最开始像边缘小工具，开发者用它尝鲜、跑脚本、接自动化。可一旦它背后的能力变成 Agent Runtime，变成多 Agent 编排，变成插件市场，变成统一权限和配额，它就不再是边缘工具了。 它开始变成新的开发工作台。

我们先把时间倒回去看。 早期 AI 编程工具最吸引人的地方，是补全。 你写一半函数，它猜后半段。你写一个注释，它生成代码。你遇到 bug，它帮你解释报错。 这个阶段，AI 的位置很清楚：它是助手。 你是主语。 它是谓语后面的补充成分。 这就是 Copilot 这个词的含义。副驾驶很重要，但方向盘在你手里。你判断需求，你设计架构，你拆任务，你决定是否接受它的代码。

这个模式特别适合早期 AI 编程的技术水平。因为那时候模型能力不够稳定，长任务容易跑偏，工具调用不成熟，代码修改也缺少可验证闭环。最安全的方式就是让 AI 做局部增强。 说白了：AI 负责局部聪明，人类负责整体靠谱。 但问题是，局部聪明的天花板很快就来了。

一个补全工具再强，它也只能在你正在看的上下文里发挥。它不能自己读完整个仓库，不能跨文件重构，不能判断测试失败后的根因，不能持续执行一个多步骤任务，不能在后台开多个分支并行探索。 所以后来出现了 Claude Code、Codex CLI、Gemini CLI、OpenCode、各种基于 MCP 的自动化工作流。 这不是偶然。 这是需求自然演化。

当 AI 只会补全时，人会问：能不能帮我写完整函数？ 当 AI 能写函数时，人会问：能不能帮我改整个模块？ 当 AI 能改模块时，人会问：能不能你自己跑测试、看日志、修 bug、提交 PR？ 人的欲望是连续的。 工具的形态被欲望推着走。 所以 AI 编程从补全走向 Agent，不是某个公司的营销口号，而是工作流的必然结果。 控制论里有一个很重要的概念：反馈闭环。

一个系统要真正自主运行，不能只有“输出”，还要有“感知—判断—行动—反馈—修正”的闭环。早期 Copilot 只有输出。它给你代码，但后续是否正确，靠人检查。 Agent 不一样。 Agent 要读文件、改文件、运行命令、看报错、再修改、再验证。它开始形成闭环。 从 Copilot 到 Agent，本质上是从“生成代码”变成“管理反馈闭环”。 这就是为什么 CLI 重要。

IDE 插件是人类工作界面的附属物。 CLI 是机器工作流的天然入口。 一个 Agent 如果想真正接管任务，它需要的不是漂亮按钮，而是命令行、文件系统、权限、工具调用、日志、测试、Git、CI/CD。 所以你会看到，AI 编程的主战场慢慢从聊天窗口、IDE 插件，转向 CLI 和 Agent Runtime。 这一步看起来很技术，其实很商业。

谁掌握 Runtime，谁掌握工作流。谁掌握工作流，谁掌握下一代软件开发入口。

Antigravity 这个名字挺有意思。 反重力。 Google 想表达的可能是：摆脱传统开发流程的重力，让 Agent 并行工作，让开发效率飞起来。 公开资料里提到，Antigravity 2.0 把 desktop、CLI、SDK、API 统一到一个 single agent harness 上。它不是孤立的 CLI，而是一整套 Agent 平台。 这就很关键。

如果一个产品只是 CLI，那它的价值是命令行体验。 如果一个产品是 harness，那它的价值就是“把模型、工具、权限、任务、插件、协作方式绑在一起”。 harness 这个词很值得琢磨。 它不是 model。 不是 app。 不是 plugin。 它更像一套马具。模型是马，任务是路，人类是骑手，而 harness 决定这匹马怎么被驾驭，往哪跑，能拉多重，什么时候停下来。

所以 Antigravity 的野心不是“再做一个 Gemini CLI”。它真正想做的是开发者 Agent 工作流的控制层。 这里有一个被很多普通用户忽略的点：未来 AI 编程工具的差异，不只来自模型能力，而来自执行环境。 同一个模型，放在不同 harness 里，表现会差很多。 一个没有工具权限的模型，只能聊天。

一个能读仓库、跑测试、调用浏览器、查文档、提交 patch 的模型，才像工程师。 一个能并行开多个子任务、让不同 Agent 分工、管理上下文、记录操作轨迹的系统，才像团队。 这就是从“AI 工具”到“AI 团队”的跃迁。 Google 当然看得明白。 OpenAI 看得明白。 Anthropic 也看得明白。 所以大家都在抢这个位置。

模型能力会越来越接近，单点差异会被压缩。真正的护城河会转向三件事： 第一，默认入口。 第二，工作流数据。 第三，执行权限。 默认入口决定你每天打开谁。 工作流数据决定谁最懂你的代码、习惯、项目结构。 执行权限决定谁能真正把事做完。 这三件事叠加起来，就是平台锁定。

经济学里有个词叫交易成本。科斯在《企业的性质》里说，企业之所以存在，是因为市场交易有成本。谁能降低协调成本，谁就能重构组织边界。 AI Agent 也是一样。 如果一个 Agent 平台能把“理解需求—拆任务—改代码—跑测试—修复—交付”这条链路里的交易成本降下来，它就不只是提效工具，而是在重构软件生产的组织边界。 以前你需要一个人盯着 AI。

以后可能是一个人管理一组 Agent。 以前你买的是 token。 以后你买的是完成任务的能力。 这两个商业模式完全不同。

这次迁移引发争议，很大程度上不是因为大家多爱 Gemini CLI。 说实话，很多开发者对 Gemini CLI 的体验评价并不算高。HN 上甚至有人说，它是自己用过最糟糕的 harness 之一。 但大家仍然焦虑。 为什么？ 因为关闭旧 CLI、迁移到新平台这个动作，会让人联想到一个熟悉剧本： 先免费。 再迁移。 再统一。 再限制。 最后收费和规则都变得不透明。

这不是 Google 一家的问题。所有平台型公司都会面对这个诱惑。 一开始，为了吸引开发者，它会强调开放、灵活、低门槛。等使用习惯建立起来，项目依赖形成，团队流程接上去，平台就有了议价权。 这就是路径依赖。 你不是不能换。 你是换起来越来越疼。

心理学里有个“损失厌恶”理论，卡尼曼和特沃斯基证明，人们对损失的痛感通常强于获得同等收益的快感。开发者对平台迁移敏感，本质上也是损失厌恶：我不是不想用新工具，我怕失去原来的控制感。 API Key 自己管，额度自己看，脚本自己跑，失败自己兜底。 这些东西看起来麻烦，但它给开发者一种确定性。

平台统一调度，体验可能更丝滑，但规则由平台定义。配额怎么计算？任务失败怎么算？插件权限怎么开？多 Agent 并发怎么收费？企业用户和个人用户边界在哪里？这些都变成黑箱。 开发者不是反对效率。开发者反对不可解释的控制。 这也是为什么 MCP、ACP、各种开放协议会变得重要。 AI Agent 越强，越需要协议来制衡平台。

否则未来每家模型公司都搞一套自己的 Agent 工作流，开发者就会被切成很多孤岛。今天为 Claude 写一套，明天为 Gemini 写一套，后天为 OpenAI 写一套，最后你不是在开发产品，而是在伺候平台。 这就荒诞了。

《黑客与画家》作者保罗·格雷厄姆说过，黑客喜欢控制自己的工具。不是因为他们控制欲强，而是因为好工具决定了思想能走多远。

AI 编程时代，这句话更重了。 因为工具不再只是工具。 工具开始拥有行动能力。 当工具能行动，权限就是政治。

这次 Antigravity 相关信息里，还有一个很有意思的点：Gemini 3.5 Flash。 Google 的说法是，它生成 token 的速度比其他 frontier models 快 4 倍。Belitsoft 的分析也提到，这对 agentic coding 很重要，因为长计划、多轮推理、大量代码输出都会消耗生成时间。

但文章也提醒了一点：Agent 整体不会因此直接快 4 倍。 我同意这个判断。 这就像你把工厂里某一台机器速度提高 4 倍，不代表整个工厂产能提高 4 倍。因为瓶颈可能在质检、运输、排队、返工、库存、协调。 这就是约束理论。 系统吞吐量由瓶颈决定，不由最炫的部件决定。

AI Agent 做代码任务时，生成 token 只是其中一环。它还要读文件、理解上下文、调用工具、等待命令、分析测试结果、处理权限、做回滚、避免误改。 真正决定效率的，不是模型嘴巴有多快，而是闭环跑得多稳。 一个能快速生成大量错误代码的 Agent，不叫效率高。 叫事故快。 所以我对“4 倍更快”这种表述会保持兴奋，但不会迷信。 对开发者和企业来说，更重要的指标应该是：

一次任务完成率。 错误回滚成本。 可解释性。 权限安全。 上下文保持能力。 工具调用成功率。 测试闭环稳定性。 这几个指标才是真正的 Agent 生产力。

这也是为什么 Antigravity 如果只靠 Gemini 3.5 Flash 的速度，不足以形成长期优势。它必须证明自己在 harness 层做得更好：多 Agent 如何分工，任务如何排队，失败如何恢复，插件如何治理，权限如何隔离，开发者如何把它接进自己的真实工作流。 否则它只是一个更快的聊天终端。 而行业已经不缺聊天终端了。

过去我们评价 AI 编程工具，经常问： 谁代码写得更好？ 谁推理更强？ 谁上下文更长？ 谁价格更便宜？ 这些问题还重要，但不够了。 新的问题应该是： 谁更能融入真实工程流程？ 谁能管理复杂任务？ 谁能让人类从执行者变成监督者？ 谁能把个人工作流沉淀成可复用资产？ 这才是工作流战争。

我自己这段时间折腾 AI 编程工具，最大的感受是：模型强不强，只决定上限；工作流顺不顺，决定你会不会每天用。 很多工具第一次 demo 很惊艳，但一到真实项目就掉链子。 原因很简单：真实工作不是“写一个函数”。真实工作是处理一堆不干净的上下文。 需求不完整。 代码有历史包袱。 测试不稳定。 依赖版本混乱。 文档过期。 业务方临时变更。 权限和安全不能乱开。 这才是真实世界。

AI 编程工具如果只在干净 demo 里表现好，没有意义。它必须进入脏活累活，进入工程系统的毛细血管。 所以我更愿意把未来的 AI 编程分成三层： 底层是模型层。它负责语言、推理、代码生成、多模态理解。 中层是 Agent Runtime。它负责工具调用、上下文管理、任务状态、权限、回滚、并发。

上层是工作流层。它负责把 AI 嵌进人的实际流程：需求、研发、测试、部署、复盘、知识库。 过去一年，大家盯着底层模型。 接下来一年，我建议更多盯中层和上层。 因为模型层会继续卷，但工作流层才会决定谁真正吃到利润。 幂律分布告诉我们，技术生态里的收益经常极度集中。不是所有工具都能活下来，最后会形成少数默认入口。浏览器如此，搜索如此，移动操作系统如此，云服务如此。

AI 编程也大概率如此。 最终留下来的，不一定是单次回答最惊艳的工具，而是那个最常被打开、最深嵌入流程、最难被替换的系统。 这就是为什么 Google 要做 Antigravity。 不是为了赢一次 CLI 口碑。 而是为了抢下一代开发入口。

很多非开发者可能会问：这不就是程序员圈子的事吗？跟我有什么关系？ 关系很大。 因为今天发生在开发者身上的事，明天会发生在所有知识工作者身上。 先是写代码。 然后是写文章。 然后是做 PPT。 然后是做销售线索。 然后是做财务分析。 然后是做客户交付。 每个领域都会经历同样的迁移： 从 AI 聊天助手，到 AI 工具插件，再到 AI Agent 工作流平台。

你现在觉得“我只是让 AI 帮我写点东西”，很快就会变成“我把一个任务交给 AI，它自己查资料、生成方案、写文档、做表格、发消息、跟进反馈”。 到那时候，你要面对的问题就不只是“哪个模型回答好”，而是： 你的工作流掌握在谁手里？ 你的数据沉淀在哪里？ 你的自动化流程能不能迁移？ 你的个人方法论有没有变成自己的资产？ 如果没有，你会越来越像一个租户。

房子很漂亮，水电很方便，但地不是你的。 平台一改规则，你就得搬家。 这也是我一直提醒自己的地方：AI Native 超级个体不能只追新工具。 追工具是低阶兴奋。 沉淀工作流才是高阶复利。 今天用 Claude Code，明天用 Codex，后天用 Antigravity，都没问题。工具可以换。但你要把自己的需求拆解方式、提示词资产、案例库、测试标准、交付流程、复盘机制沉淀下来。

工具是船。工作流是航海术。船会换，航海术才跟着你走。 《原则》作者瑞·达利欧说：痛苦加反思等于进步。放到 AI 工具使用上，我想改一句：工具加反思，才等于资产。只用不反思，最后只是平台的活跃用户。

对企业来说，Antigravity 这种平台化 Agent 工具会很诱人。 它听起来能降本增效。 它能让开发更快。 它能让多 Agent 并行。 它能把很多重复性工程任务自动化。 这些都对。 但企业真正要想清楚的不是“要不要用”，而是“怎么治理”。 Agent 和普通 SaaS 最大的区别，是它有行动能力。 普通 SaaS 只是让人操作。 Agent 可以替人操作。

这带来的风险完全不同。 一个员工点错按钮，责任链条比较清楚。一个 Agent 自动修改代码、调用 API、生成文档、发起部署，如果出事，责任怎么划？权限怎么控？日志怎么留？审批怎么接？数据怎么隔离？ 这不是 IT 部门的小问题。 这是企业治理问题。 所以我认为，企业引入 Agent 编程工具，要从第一天就建立三条线： 第一条，权限边界。

Agent 能读什么，能写什么，能执行什么命令，能不能访问生产环境，必须分层控制。 第二条，审计链路。 Agent 做过什么、为什么做、改了哪些文件、运行了哪些命令、失败在哪里，必须可追踪。 第三条，人类验收。 关键任务不能让 Agent 自己闭环到生产结果，至少要有人类 checkpoint。尤其是涉及数据、安全、财务、客户承诺的任务。

这听起来保守，但我觉得这是企业落地 AI 的基本盘。 不要把 Agent 想象成一个聪明实习生。 更准确的比喻是：它是一个速度极快、记忆不稳定、权限很敏感的外包团队。 你当然可以用它。 但你不能没有管理制度。

我越来越相信，未来开发者的工作会发生一个结构性变化：从亲手写代码，转向设计任务、管理 Agent、验收结果。 这不是说人不写代码了。 高手仍然会写。 而且越到关键架构、复杂抽象、系统设计，人类判断越重要。 但大量中低复杂度的实现工作，会逐渐被 Agent 承接。 开发者的价值会迁移到更上游： 定义问题。 拆解任务。 设计约束。 提供上下文。 建立验证标准。 判断结果质量。

沉淀可复用流程。 这其实很像从“工匠”到“工头”的变化。 不是贬低。 是职责升级。 一个人亲手搬砖，效率有上限。一个人能组织十个靠谱工人，产能就变了。但前提是，他要懂图纸、懂材料、懂验收、懂风险。 AI Agent 时代也是如此。 如果你只是把任务丢给 AI，然后期待奇迹，你会被反噬。

如果你能把任务拆得足够清楚，把上下文喂得足够准确，把验收标准设得足够硬，Agent 就会变成杠杆。 杠杆从不替代人。杠杆放大人。你混乱，它放大混乱。你清晰，它放大清晰。 这就是我对“AI Native”的理解：不是会用很多工具，而是能把自己的认知结构变成 AI 可执行的工作流。

我的判断比较明确：Google 做 Antigravity CLI 迁移，是正确方向，但执行风险不小。 正确的地方在于，它看到了 Agent 工作流才是下一代入口。

如果继续维护一个相对独立、体验一般、商业闭环不强的 Gemini CLI，Google 很难在 AI 编程工具战里占据主动。把它收进 Antigravity 2.0 平台，统一 desktop、CLI、SDK、API，这符合平台竞争逻辑。 风险在于，Google 的历史包袱太重。

开发者对 Google 关闭产品有心理阴影。Gemini CLI 迁移如果处理不好，很容易被解读为又一次“先给你用，再把你赶走”。 尤其是当消费级 Pro / Ultra 用户发现旧 CLI 停止服务，而企业用户保留访问时，这会进一步强化一种感觉：个人开发者被迫迁移，企业客户被优先保护。 商业上可以理解。 情绪上很危险。 开发者生态不是只靠功能建立的，也靠信任建立。

信任这个东西很奇怪。它建立得很慢，崩得很快。 Google 如果想让 Antigravity 真正赢，需要回答几个问题： 程序化调用是否继续开放？ Agent Client Protocol 或类似开放协议怎么支持？ MCP 生态如何兼容？ 配额和计费如何透明？ 个人开发者迁移成本如何降低？ 旧工作流怎么保留？

如果这些问题回答不好，Antigravity 会面临一个尴尬局面：技术方向对，但开发者不信。 而在开发者工具领域，不信任是致命伤。

这类新闻看完，不要只停留在“Google 又搞了个新东西”。 真正该做的是调整自己的 AI 工具策略。 我建议分三步。 第一，把工具依赖和工作流资产分开。 你可以用 Antigravity，也可以用 Claude Code、Codex、OpenCode、Hermes、各种 MCP 工具。但不要把所有方法论都锁死在某一个平台里。

把你的提示词、任务拆解模板、验收标准、常用脚本、项目规范沉淀在自己可控的地方。 比如本地仓库、Markdown、知识库、Git。 第二，优先选择支持开放协议和可迁移结构的工具。 未来 Agent 工具一定会变多。你不可能每次都重建工作流。谁支持 MCP、插件、脚本、Git 标准流程、可导出的配置，谁就更值得长期投入。 第三，训练自己成为 Agent 经理，而不是提示词乞丐。

不要只会问：“帮我写一个函数。” 要学会说： 这是项目背景。 这是目标。 这是约束。 这是允许修改的范围。 这是禁止触碰的文件。 这是测试命令。 这是验收标准。 失败后先诊断，不要乱改。 这才是 Agent 时代的基本表达能力。 说得再直白一点：未来不会用 AI 的人会被淘汰，只会命令 AI 的人也会被淘汰。真正有竞争力的人，是能把 AI 纳入自己系统的人。

AI 圈每天都有新模型、新产品、新名字。 今天 Gemini CLI 迁移到 Antigravity CLI，明天可能又有另一个平台发布更强的 Agent。信息流会让人误以为，最重要的事情是追上每一个新工具。 不是。 最重要的事情，是看懂工具背后的结构变化。 这次结构变化就是：AI 编程正在从 Copilot 时代进入 Agent 接管时代。

从“辅助你写代码”，到“替你执行任务”。 从“模型能力竞争”，到“工作流入口竞争”。 从“谁回答更好”，到“谁掌握闭环”。 从“开发者调用工具”，到“平台调度开发者工作流”。 这才是重点。

《孙子兵法》里说：“善战者，求之于势，不责于人。”

看 AI 工具也是一样。不要只盯某个产品好不好用，要看势。 势变了，打法就要变。 Copilot 时代，你要学会和 AI 对话。 Agent 时代，你要学会给 AI 建制度。 因为接下来真正稀缺的，不是会写提示词的人。 而是能设计任务系统、控制风险边界、沉淀工作流资产的人。 工具会越来越聪明。 平台会越来越强势。

你的选择只有一个：要么成为平台工作流里的一个用户，要么把平台能力拆解、吸收、重组，变成自己的生产系统。 别只做工具消费者。做工作流所有者。