前言：“照感觉帮我弄好”真正实现的世界已悄然来到

各位工程师，大家在让 AI 写代码时，到底吐槽过多少次“不对，不是那样”呢？

AI 确实变聪明了，但在此之前，它终究只是个“助理”。在我们搭建好的环境中，它顶多只是个按照指令生成部分代码的存在。然而，今年 Google I/O '26 的发布，彻底颠覆了这个前提。

Google 所推动的，是让 AI 在指令下自律地完成任务、主动调查并产出结果，完全转型为“Agent（智能体）”。而这次发布的 Agent 开发平台——“Google Antigravity”，正是其核心心脏。

本文将从技术人员的视角，深度解构这次的主题演讲（Keynote），从将我们从基础设施构建的“噩梦”中解放出来的新功能，一路聊到 Android 和 Web 开发的未来。

现有挑战：Agent 开发曾是“基础设施的噩梦”

尝试过开发 Agent 型 AI 的朋友应该都很清楚，调整 Prompt（提示词）只是拼图中微不足道的一小块。 为了让 Agent 能够自律地执行代码、使用工具或调用外部 API，一个安全且隔离的执行环境（Sandbox，沙盒）是不可或缺的。如果想靠自己搭建这套环境，还要配合数百万用户的流量进行扩展（Scale），那简直是字面意义上的“基础设施噩梦（infrastructure nightmare）”。

托管型 Agent 的震撼：一键 API Call，Linux 环境手到擒来

针对这个噩梦，Google 给出的答案是整合进 Gemini API 的“托管型 Agent（Managed Agents）”。

令人震惊的是，只需调用一次 Gemini API，伴随着 Agent 本体，Google 托管的远端 Linux 环境（沙盒）就会自动部署完成。 这话说得保守一点，简直是革命性的。基础设施的扩展直接交给 Google 搞定，我们则可以专注于应用程序的逻辑，以及定义赋予 Agent 的“工具”。

“总觉得最近最热门的编程语言，搞不好是 Markdown 呢。”

在展示中，主办方介绍了一个“AI 广播节目 Agent”。它能自动爬取 Hacker News 的最新文章、进行摘要、用多种合成语音做成对话、混入背景音乐并输出为 MP3。这一切完全不需要编写任何编排（Orchestration）逻辑，只需在 Markdown 文件中定义好技能与工具即可完成。

此外，现在还可以从 AI Studio 点击几下直接部署到 Cloud Run，或者导出为 Kotlin 的 Android 应用程序，直接推送到 Google Play 的测试轨道（Test Track）。建置基础设施和环境的繁琐工作，已然成为历史的眼泪。

Antigravity 2.0 & CLI：开发者的全新“任务控制中心”

作为开发工具的 Antigravity 也迎来了大幅进化。“Antigravity 2.0”是在桌面端同时指挥多个 Agent 的“任务控制中心（Mission Control）”。

• 动态子 Agent (Dynamic Sub-agents): 当 Agent 被赋予一项巨大的任务时，它会自己生成负责“QA”或“数据科学”的专业子 Agent，并通过并行处理来完成工作。
• 定时任务功能 (Cron): 例如每天早上帮忙摘要堆积如山的 PR（Pull Request），或者每小时检查一次云端资源的健康状态。利用标准的 cron 排程，就能让 Agent 真正进入“自动驾驶（Autopilot）”模式。

而为了热爱黑色画面（终端）的工程师们，Antigravity CLI 也正式登场。在 Demo 中，工程师将 CI 流水线的构建错误输入进去，并通过语音输入指示：“微调（Fine-tune）Gemma 4，别说废话，只返回 Bash 命令。”接着，Agent 制定了实施计划，并在配备 GPU 的 VM 上直接跑起了基于 LoRA 的训练脚本——这种科幻片般的情节，如今已成为现实。

对 Android 和 Web 的冲击：为了让 Agent 阅读而进行的 UI 开发

这股 Agent-First（智能体优先）的浪潮，也正席卷着各个平台开发领域。

Android 开发：与聪明的伙伴进行结对编程（Pair Programming）

在 Android 开发方面，Android Studio 与 Antigravity 实现了联动。AI 会自动分析 R8 的优化规则、实施深度链接（Deep Link）的路由逻辑等。更厉害的是，据说官方还实验性地公开了“读取 iOS 源码并迁移为 Android 应用（Kotlin）”的助理功能。

Agentic Web 的序幕：走向由“Agent”而非人类阅读的 Web

在 Web 开发领域，业界引入了“如何让 AI Agent 操作网站”的新视角。

• WebMCP (Origin Trial): 这是一项浏览器标准草案，允许网站端向 Agent 定义并公开“该如何使用本网站的 API 或工具”。
• Chrome DevTools for Agents: 实现了让 AI Agent 自己读取 Lighthouse 报告、编写代码修复错误、并重新执行测试的闭环。我们再也不需要当个复制粘贴错误信息的“人类剪贴板”了。
• HTML in Canvas API: 这是一个将实际的 DOM 元素直接渲染到 Canvas 环境中的疯狂（且棒透了的）API。借此，Canvas 内的元素将变得可搜索、可翻译，且 Agent 也能进行操作。

专家视角的深入考察：

震撼全场的 Gemini 3.5 Flash。然而，真正的革命在于“价格”与“速度”之后

作为主题演讲的开场，最令人震惊的无疑是 Gemini 3.5 Flash 的发布。

Gemini 3.5 Flash 的冲击 与以往的模型相比，速度至少提升了 4 倍，且成本压倒性地便宜。

性能的提升固然重要，但从工程师的角度来看，真正恐怖的是这种“极速与低价化”。

在此之前，将大型语言模型（LLM）嵌入到生产环境的系统（特别是要求实时性的流水线）时，瓶颈总是卡在“响应过慢（Latency）”以及“Token 消耗带来的沉没成本”。相信很多人都曾流着泪感叹过：“虽然很聪明，但这速度慢到根本没法用在业务系统上啊。”

而 Flash 则用硬实力把这道墙给砸了。如此一来，以往只能用于批处理（Batch Processing）的 LLM，如今嵌入到 UI 后端或互动式开发工具的“Inline（内联）”门槛已被剧烈降低。

Antigravity 2.0 发布！这才是升华为“动真格的开发工具”

而我个人最为欢呼雀跃的，则是开发平台“Antigravity 2.0”的大版本更新。

老实交代，在此之前我一直挺担心的。说到 Google，他们有太多前科了：好不容易推出了一个针对开发者的服务（比如 Firebase Studio，或是以前存在过的各种 Studio 系工具），却在某天突然毫无预警地宣布“不玩了！”并直接关闭或放弃维护。那时我心里总在犯嘀咕：“Antigravity 该不会也步入后尘，成为历史的一夜情吧……”

然而，这次“2.0”厚重的更新内容砸下来，明确展现了 Google 的意志：他们要把这款产品当作“未来开发工具的核心主轴，动真格地培养”。

早期的版本如果说得难听点，给人的印象不过是“借了 VS Code 的外壳，勉强把 AI 功能缝合在一起的纸糊玩具”。但在这次的 2.0 中，融入了大量的控制工程方法（Harness Engineering）。

这项进化让工具本身的价值，从“让 AI 写代码”的单纯维度，升华为了“将 LLM 能力发挥到极致的治理环境（Harness）”。据称，在前面提到的 Gemini 3.5 Flash 四倍速度提升的加持下，配合 Antigravity 2.0 侧的优化，在特定开发任务中，预期能带来较以往提升 6 倍以上的效率。

我们人类只需要模糊地输入“抽象的概念”或“暧昧的需求”，AI 端就会自律地建立假设、设计、验证并执行。一个将这种思考闭环以爆发般速度运转的环境，已经蓄势待发。

CLI 的复兴，与 AI 时代“软件架构”的妙手

在这次的发布中，我认为在技术上最硬核、也最优美的，莫过于以下产品之间的联动配合：

• Antigravity 2.0（GUI） & Android CLI
• Android Studio（GUI） & Antigravity CLI

GUI（界面点击）与 CLI（命令行操作）的双刀流。乍看之下，这似乎是个怀旧复古的更新。然而，在 AI 时代的语境下，提供这个“CLI”具有极其关键的意义。

为什么是现在？为什么是 CLI（CommandLine Interface）？

追溯历史，CLI 的本质是“计算机与人类通过单行文字进行对话的最简界面”。而如今，我们与 LLM（Prompt）进行的对话，本质上也是“单行的文字回应”。也就是说，CLI 本身就是对 AI（Agent）而言最容易处理的界面。

这次 Google 的设计思想是这样的：

人类使用倍感亲切的 GUI（Antigravity 2.0 或 Android Studio）。 然而，在幕后自动化、自律化执行复杂处理的 AI Agent 们，则通过调用轻量且可靠的“CLI”，从后门来控制系统。

例如，当人类在 Android Studio（GUI）中进行开发时，背景的 AI Agent 会主动调用“Antigravity CLI”来编译并验证传感器处理的代码，并将结果通过“Antigravity CLI”与云端的 LLM 同步，进一步优化代码——。

工具之间并没有采用“模仿人类画面去点击控制”这种低效的方式，而是大胆地将“CLI 配置为 AI 间通讯的协议”。这种作为软件架构的切入角度实在精妙，身为工程师不得不为之折服。

MCP（Model Context Protocol）降级为单纯的“水管”，真正的视角移向 Agent 控制体

冷静地看待这场架构进化后，对于最近吵得沸沸扬扬的 MCP（Model Context Protocol）的未来预测，恐怕也需要做出修正了。

先前市场上似乎有一种风潮，认为“熟知 MCP 规范的 MCP 开发工程师”需求将会大增。但看过这次 Google 的 CLI 生态系展示后，MCP 很有可能只会作为一种“用于轻量数据传输的标准协议（水管）”，走向商品化（Commoditisation）的未来。就像网络世界里的“HTTP 协议”一样，现在没有人会臭屁地说“我是个精通调用 HTTP 的专家”。

未来的技术价值（以及我们的主战场），将不再是 MCP 本身的开发，而是移向更高层次的维度——“如何灵活运用 CLI 等界面，构建出自律且具备高附加价值的 AI Agent 控制体系（控制平台）”。

Web 开发者也需密切注意！“Web MCP”与“HTML in Canvas API”带来的未来

此外，在 Web 前端与平台的层面上，官方也悄悄投下了一颗威力巨大的定时炸弹。那就是“Web MCP with Browser Agents”与“HTML in Canvas API”。

1. Web MCP with Browser Agents：浏览器右上角的 Gemini 将能领会“你网站”的意图

目前，Chrome 右上角默认常驻着 Gemini 的侧边栏，但在此之前，它顶多只能从外部做到“抓取当前开启的网页并进行摘要”。

而如果将这次发布的“Web MCP”机制埋进自己的网站中，当用户向右上角的 Gemini 发问时，Gemini 就会检测到网站侧的 Web MCP 代码，并直接将网站开发者所意图的、精确的数据源与上下文（Context）喂给 LLM。

这能让浏览器的内置功能在不产生幻觉（胡说八道）的情况下，提供完全符合自身 Web 服务逻辑的精确协助。这是 Web 开发者绝对必须跟进的全新范式。

2. HTML in Canvas API：突破渲染负载极限的前端救星

说到 Canvas 元素，虽然它在游戏或丰富的数据可视化中能发挥压倒性的渲染效能，但缺点是无法在内部配置 DOM（HTML 元素），导致处理复杂的 UI 或文本时简直像地狱般痛苦。

而通过新设的“HTML in Canvas API”，我们将能直接把 HTML 的结构描述，带入 Canvas 那极速的渲染上下文（Rendering Context）中。由于利用 Canvas 开发互动式 UI 的难度剧烈下降，Web 应用程序的 UI 表现力势必将迈向更高阶的舞台。

结语：为了不让钱包被 AI 绑架，工程师现在该做的架构选择

经历了这次的 Google I/O 2026，我们在未来的系统设计中必须意识到的，是优化“AI 处理的三层结构（分层架构）”：

1. 本地/边缘层（如 Gemma 4）： 在设备在地端运行的轻量模型。隐私保护、零延迟、完全免费的任务都在这里处理。
2. 中间/服务层（各种 CLI 或特化型 API）： 不直接调用云端 LLM，而是通过经过优化的中介服务（如 Google 提供的各种 CLI 联动）来进行摘要与过滤。
3. 重型/云端 LLM 层（如 Gemini Ultra）： 仅在面对真正复杂且上下文庞大的推理最终阶段时才使用。

如果盲目盲从某家“名字以 A 开头、最近有点排他、不管三七二十一总之疯狂消耗 Token 的流派”的 AI 企业，公司的预算（Token 费用）再多也不够烧。

既然 Google 已经把 Antigravity 2.0、各种 CLI 生态系，以及像 Gemma 4 这类地端模型的路线图（为 Gemini 4 铺路）漂亮地排在我们面前，现在正是考验我们工程师“交通指挥”设计能力的时候了——“哪些任务该分流到本地，哪些任务该用中介 CLI 优化，哪里该交给大容量 LLM”。

技术武器已经全面到位。接下来，就让我们诚心祈祷 Google 不要把这群迷人的“玩具（工具群）”留下一堆 Bug 就不管，而是能以最高品质送到我们手上了（笑）。

那么，感谢 Google I/O，让我们装备上全新武器，迈向 AGI 时代吧！