Google Antigravity实战：从AI辅助编码到智能体工程

从写代码到描述工程结果

大多数开发者对AI编程的认知还停留在“补全下一行”或“解释这段代码”的阶段。Google开发者专家、企业云与AI架构师在这场分享中给出了一个更清晰的坐标系：AI与开发者的协作已经经历了代码补全、对话式编程、编码智能体三个阶段，而当下正在进入第四阶段——智能体工程（Agentic Software Engineering）。

这个阶段的关键变化在于交互单位。过去你告诉AI“怎么写”，现在你描述“要什么工程结果”，智能体自行规划、执行、测试、检查文件，并在未达成目标时反复迭代。交互单位从“代码完成”迁移到“工程任务完成”。

这不是文字游戏。当任务单位变成一件完整的工程任务，智能体就必须拥有更多能力：推理并制定计划、浏览网页检索信息、在终端执行命令与安装依赖、读取并修改仓库文件、运行应用、产出计划与测试报告等证据。分享者用一张五层能力图概括了这一结构，最底层醒目地标着“人类审批”——智能体越强大，界定人类审批边界就越重要。

双循环工作流：人类没有消失，只是上移了

演讲者推荐的心智模型是一个双循环结构。内循环是智能体的执行循环：理解意图、制定计划、执行、产出工件、验证。外循环由人类掌控：定义意图、审查计划与产出、审批、决定是否迭代。

开发者并没有从流程中消失，而是移动到更高的抽象层。省下来的是语法级别的检查时间，增加的是对架构、约束、权衡、验证方式和验收标准的思考。

实机演示：一句需求生成一个网站

分享中演示了多个递进案例。第一个是让智能体访问Google News抓取头条，通过浏览器工具（chrome-devtools-mcp）读取DOM并合成信息，执行过程中需要用户授权访问网页。第二个是生成一个技术会议信息站：包含首页日期地点、日程表、8场演讲、每场1至2位讲者。智能体先产出实施计划，用户可以直接编辑计划内容，确认后再生成代码并启动服务器。

第三个案例更接近真实开发：一句“创建一个番茄钟加白噪音的生产力应用，采用农场美学风格”，智能体在独立创建的项目空间中生成文件、启动应用、发现报错后自行修复，最终交付可运行的应用。演示者在环境中还可以切换驱动智能体的模型。

chrome-devtools-mcp 是 Google 开源的 MCP（Model Context Protocol）服务器，它把 Chrome DevTools 的调试、DOM 读取、网络请求捕获、性能分析、控制台日志等能力暴露给 AI 智能体。MCP 本身是一个开放协议，用于标准化大模型与外部工具、数据源之间的调用接口，让智能体可以按需发现并调用工具，而不必把每个工具的集成硬编码进提示词。在本例中，智能体正是通过该服务器读取 Google News 页面结构，再自行解析和合成信息；这类浏览器工具通常还要求显式授权，以限制智能体的访问边界。

玻璃盒原则：工件是工程边界

智能体系统最大的工程障碍是“黑盒问题”——给一个提示，吐出上千行代码，然后宣称“完成了”。这在工程流程中不可接受。

演讲者提出的替代方案是“玻璃盒”：让计划、任务分解、测试、文档全部可见，让另一位工程师能够检查究竟发生了什么。工件在这里的作用不是交付物装饰，而是“智能体意图”与“实际产出”之间的工程边界，使执行过程可审查、可治理。也正因如此，演讲者明确反对让智能体只返回代码作为唯一输出。

有了工件，才能建立验证闭环。番茄钟案例中，智能体生成模拟依赖、在终端执行、从标准输出识别失败、应用修复、完成验证并生成测试——这一整条链路本身就是可审查的证据。

工件（artifact） 在智能体工程语境中泛指智能体在执行过程中产出的可持久化、可检查的中间与最终结果，例如实施计划、任务分解清单、修改过的文件、终端命令与输出、测试报告、截图或架构说明等。它与普通交付物的区别在于：工件承载的是“智能体为什么这样做、做了什么、结果如何”的证据链。正因为工件可被另一位工程师阅读和复核，黑盒式的“一次吐出全部代码”才被替代为可审查的玻璃盒流程，工件由此成为连接人类审批与智能体自治的工程接口。

输入决定输出：规格说明是新的核心技能

分享中反复出现的一个公式是：更好的上下文 + 更清晰的意图 + 更强的约束 = 更高质量的智能体执行。

反过来说，如果规格本身含糊，智能体只会以更快的速度执行含糊的输入。AI没有消除工程严谨性的需求，而是让缺乏严谨性的代价暴露得更快。演讲者举了一个对比：不要只说“建一个应用”，而是给出仓库结构、架构文档、相关接口、既有模式和约束，再明确技术栈限制、架构规范、安全要求、测试覆盖率目标（例如超过90%）以及验收标准，产出质量会有本质差异。

这也解释了为什么规格说明被刻意放在上下文与实现之间——它不是可选步骤，而是决定执行质量的杠杆点。

规格说明（specification） 在这里指面向智能体的结构化任务描述，通常包括目标与非目标、约束条件、接口与数据契约、验收标准以及验证方式。它与传统需求文档的差别在于面向的执行者是智能体：约束需要显式到可判定，验收标准需要可自动验证（如测试通过率、lint 结果），否则智能体无法判断任务是否完成。规格说明之所以被放在上下文与实现之间，是因为上下文提供“环境事实”，规格提供“成功判据”，两者共同决定智能体规划与迭代的质量上限。

治理六问：自主性必须有边界

只能生成文本的智能体破坏力有限；能访问生产系统、仓库、数据库、云资源和外部服务的智能体则完全不同。演讲者列出了六个必须显式设计的治理维度：

• 信任边界：智能体允许在哪些范围内操作
• 工具权限：可以调用哪些工具
• 数据访问限制：可以读取哪些信息
• 验证证据：需要提供什么证据才能让人信任结果
• 可审计性：发生过哪些访问与操作
• 成本控制：是否会意外消耗大量计算或API资源

最后一条有现实场景支撑：某个API被智能体调用数千次导致不可用，这类风险在无边界自主性下并非假设。

信任边界（trust boundary） 原指系统中不同信任级别区域之间的分界，数据跨越边界时需要校验与授权。在智能体场景下，它被扩展为“智能体被允许自主行动的范围”，例如只读仓库、隔离的沙箱分支、非生产环境或受限的云资源配额。与工具权限、数据访问控制不同，信任边界强调的是范围与隔离的整体设计：智能体可以在边界内自由规划和迭代，越界动作则必须触发人类审批。边界划得越清晰，越能在保留自主性的同时控制破坏半径。

落地建议：从小边界开始

对想立刻引入智能体工程的团队，演讲者给出的路径是收敛而非激进：先给智能体一个边界明确的小任务，而不是开放全部权限；提供架构文档、仓库结构、约定和约束；执行前先要计划，并审查计划；明确验收标准；强制验证手段（测试、lint、校验）；在安全敏感、基础设施敏感或高影响操作周围保留人工检查点。

传统AI编码助手与智能体开发环境的差异也在这里显现：后者把多步执行当作核心能力，把测试从“生成测试”推进到“执行并迭代”，把人类角色从提示与代码审查推进到架构、监督与验证。

演讲结尾提出的问题值得记住：不要问“AI能不能读写我的代码”，而要问“智能体能为我的团队执行哪一段工程工作流”。这个问题的答案，决定了你在智能体时代的工程竞争力。