代理工程与外部循环：Antigravity与Agents CLI的定位

人工智能发展的下一阶段不再那么依赖更强大的模型，而是更依赖于更完善的工程系统。在2026年的Sequoia Ascent大会上，安德烈·卡帕西指出，该行业正从随意编码转向智能代理工程。在这种模式下，人们负责编写规范、评估流程及约束条件，而智能代理则承担具体的实现任务。

这一转变很重要，因为人工智能并不会取代软件工程这一学科，而是会放大现有学科的作用。谷歌的DORA研究及相关平台指南也指出了同样的方向：那些拥有扎实工程基础的组织，相比那些流程脆弱、验证机制薄弱的组织，能从人工智能辅助的工作流中获得更多收益。虽然人工智能开发工具的采用率很高，但人们对它们的信任度却不高。限制因素已不再是模型本身，而是围绕模型的整个系统：包括规范、评估标准、部署流程以及治理机制。代理式工程正是构建这一系统的实践。

代理式工程的含义

简而言之，这是一种结构化的人工智能辅助开发方式：人类负责整体架构、质量与正确性，而智能体则在既定范围内处理特定的实现任务。Karpathy提出了三个核心原则。

先明确规范。在智能体编写任何代码之前，工程师需以机器可读的格式阐述目标、约束条件及成功标准。人类与智能体之间通过结构化的契约替代模糊的指令。

先评估再信任。单次成功运行并不能说明其可靠性。智能体需要在使用结构化的评估数据集进行测试，并通过指标评分及大语言模型作为评判标准，确保在部署之前其性能具有可重复性。

防护机制与沙箱环境。智能体应被置于具有明确权限、工具钩子及策略门控的安全沙箱中，从而确保其执行过程受到监控。目前仅有12%的企业级AI智能体试点项目能够投入实际应用，而模型本身并非主要原因。真正的障碍在于基础设施的缺失：没有沙箱环境、没有敏感信息扫描功能，也没有策略门控。

当前编码工具的发展现状

任何客观的评估都应首先肯定当今AI编码工具的优异表现，其能力确实令人印象深刻。

这些工具在内部循环式的智能体任务处理方面表现突出：能够拆分任务、编辑多个文件、运行本地终端命令，并能根据编译错误自行修正。它们早已超越了简单的代码生成和自动补全功能。

不过，内循环仅是其中的一半。企业团队不再纠结于智能体是否具备编写和编辑代码的能力，因为到2026年几乎所有主流工具都能做到这一点。更棘手的问题是外循环：即当智能体离开开发者的本地终端后，组织该如何对其进行评估、部署、监控和管理。正是在这里讨论的重点发生了变化。两者的结构差异如下：

这并不意味着其他工具存在缺陷。作为内循环执行的引擎，它们依然是目前最优秀的选择之一。但代码生成仅是起点，那些为开发者本地终端设计的工具本身并不具备管理整个外循环生命周期的功能。要在2026年取得成功，仅仅打造出功能强大的智能体是不够的，还需要相应的基础设施来在生产环境中对它们进行评估、部署和管理。

以智能体CLI作为入门途径

谷歌的方案基于一个核心设计决策。Agents CLI旨在与任何编码助手协同工作，这正是其架构的优势而非缺陷。在安装后，它会基于Agent Development Kit（ADK）添加七项核心功能，涵盖框架搭建、评估、以大语言模型作为评分标准、运行时配置、Cloud Run部署以及Cloud Trace可观测性功能。Claude Code或Cursor的用户使用agents-cli scaffold、agents-cli eval和agents-cli deploy的便捷程度与Antigravity的用户大致相同。

这是有意为之。谷歌并非要在代码生成层面展开竞争，而是认为智能体工程的价值正从编写代码的前端转移到运行、监控和管理智能体的后端。无论开发者选择哪种前端工具，这些CLI命令都能引导他们到达同一个目标：

• agents-cli 可部署到 Cloud Run、GKE 或 Agent Engine，这些都属于 GCP 平台。
• agents-cli 在运行时会将遥测数据发送到 Cloud Trace 和 BigQuery，同样属于 GCP 平台。
• agents-cli 还会将代理程序注册到 Agent Registry 中，该服务也基于 GCP。
• 负责治理功能的 Model Armor、Agent Identity 以及策略控制机制同样运行在 GCP 上。

因此，CLI 是接入入口，而最终所有操作都会在 GCP 上完成。采用该工具的每一个编码助手都会变成生产环境生命周期中的 GCP 客户端。正因如此，“它也兼容 Cursor”这一特点反而有助于实现该战略，而非对其构成威胁：谷歌并不需要用户更换编辑器，只需让他们在 GCP 上运行生产环境，而 CLI 则为各类工具提供了最低门槛的实现路径。

三层同心结构

Google 生态系统由三层嵌套结构组成。每一层都会增添新功能，且无需放弃现有的工具。

最内层是 Agents CLI，可与 Cursor、Claude Code、Codex、Copilot、Antigravity 以及任何支持技能注入的工具兼容。它提供了标准的项目框架搭建方式（agents-cli scaffold）、由大语言模型评分的结构化评估功能（agents-cli eval）、通过单条命令将项目部署到 Cloud Run 或 GKE 的能力（agents-cli deploy），以及自动设置 Cloud Trace 可观测性的功能（agents-cli observe）。不过它不支持多智能体协调、持久化上下文管理以及内置的验证循环。其对用户的宣传点是：保留自己喜欢的编辑器，获得从原型到生产环境的可重复部署流程，并接受项目在 GCP 上运行的事实。

任何使用 Agents CLI 的工具都需要云层，因为代理程序实际上就是在那里运行的。它包括：

• Cloud Run、GKE 以及用于可扩展托管服务的代理平台
• Cloud Trace，可实现完整的执行路径追踪，并提供符合 OTel 标准的遥测数据
• BigQuery Agent Analytics，可用于查看所有已部署代理程序的仪表板
• Agent Registry，用于对代理程序进行管理、版本控制及共享的中央目录
• Model Armor，可防止数据泄露并过滤不安全内容
• Agent Identity，提供与可验证的人类身份或服务主体关联的加密标识
• Agent2Agent（A2A）协议，用于在协调多台代理程序时实现它们之间的通信

其理由在于，独立的编码助手通常依赖外部云基础设施来进行生产部署、监控和管理，且无法提供集成的企业级运行时环境。这属于架构层面的差异而非竞争因素。Claude Code与Cloud Run并无竞争关系，因为两者处于不同的层级。

Antigravity的独特优势

如果所有人都能使用子代理和上下文文件，那Antigravity的竞争优势何在？答案并非某个单一功能，而是与生产层的深度整合。

Claude Code中的子代理在终端内运行：它们负责编写代码、执行测试并生成输出。而部署这些代码、实时监控其运行状态、管理大量代理以及协调不同服务间的代理工作则都需由用户来完成，因为Claude Code对Cloud Run实例、可观测性流程或相关管理策略一无所知。它只是一种开发工具。Antigravity的子代理则能实现更多功能：

• 可通过Agents CLI直接部署到Cloud Run、GKE或代理平台，因为该CLI是原生工具而非第三方插件。
• 在调试过程中可查询Cloud Trace的遥测数据，因为Antigravity能够读取GCP的可观测性数据。
• 可将已完成任务的代理注册到Agent Registry中，因为发布功能是其内置的工作流。
• 可通过A2A协议与已部署的代理进行协调，因为通信层属于同一个生态系统。

Claude Code的子代理是功能强大的开发工具，而Antigravity的子代理则因共享相同的供应商技术栈而具备对生产环境的认知能力。它拥有其他工具目前还无法比拟的四大功能：

1. 多界面一致性：同一个代理上下文可同时覆盖桌面IDE、命令行界面、用于编程开发的SDK以及托管API。工作流可能从IDE开始，接着在终端继续执行，并由CI/CD系统触发。Claude Code主要运行在终端中，而Cursor则以IDE为核心。
2. 原生命令行集成：scaffold、eval、deploy和observe等功能是与Antigravity共同设计的，因此该代理能够原生理解命令行，并无需进行任何提示工程即可串联各生命周期指令。

具备 GCP 感知能力的上下文。代理能够将 Cloud Trace 数据、Agent Registry 条目以及部署元数据整合到其工作上下文中，因此负责排查生产问题的代理可在同一会话中查看遥测数据、审查已部署代理的配置，并提出修复方案。

企业级可发现性。许多自定义代理被隔离在私有端点 URL 后，仅其创建者能够访问，且需要手动共享凭证。内置的发布流程解决了这一问题：只需告知 CLI 将代理注册到 Gemini Enterprise，即可运行 agents-cli publish 命令，该代理便会作为安全且可被发现的工具出现在整个组织内的 Gemini Enterprise 应用中。内置的 IAM 机制负责管理访问权限，各团队无需自行搭建基础设施即可使用该功能。

生态系统对比

为便于对比，下表展示了这些工具在哪些方面相同，又在哪些方面存在差异。

在对比的上半部分，这三种生态系统在架构上趋于一致，都具有出色的代码生成能力、并行子代理协调功能以及用于处理长时间运行任务的托管云沙箱。而下半部分则体现了谷歌所宣称的额外企业价值优势：其他竞争平台会将代码、数据及凭证移至专有的第三方运行时环境中，而谷歌则通过 Agent Runtime、Agent Identity、Model Armor 和 Agent Registry，让企业能够在自身的 Google Cloud 环境内执行、识别、认证、管理和监控代理。这种差异在实际应用中也有体现：GCP 提供原生的遥测功能、统一的四层部署框架，以及开箱即用的模型管理机制。

坦率地说，本地内循环能力正在不断提升，而基础设施层正是垂直集成存在差距的领域。

如何决策

对于管理者和工程师而言，决策框架其实很简单。那些以加快内循环速度为目标的团队应继续使用现有的工具。Claude Code、Cursor和Copilot表现优异，且每月都在持续改进。如果需要更强的生命周期管理功能，还可以加入Agents CLI，等团队准备就绪后再将其部署到GCP上。

那些从人工智能辅助编码转向由智能体驱动的工作流的机构则面临不同的需求。群体管理、基于评估的质量控制、受监管行业的合规要求以及多智能体协作都需要不同的架构，而谷歌是为数不多的能够提供从编码智能体到评估、部署、可观测性及合规管理的全套垂直集成解决方案的供应商之一。

这一情况并不取决于模型本身的优劣，因为各模型都在不断趋同。关键在于基础设施的整合程度：即从编写代理代码到在生产环境中运行受管控的代理集群之间的距离。无论团队从哪种编辑器开始，谷歌都将这一距离缩短到了其他任何公司都无法企及的程度。