Google Cloud 刚刚将 Agent 生命周期嵌入任意编程 Agent

Google Cloud 推出了一套六阶段工作流，使 AI Agent 能够从本地原型进入生产环境，而无需开发者放弃自己惯用的编程 Agent。这种方式将 Codex、Claude Code、Cursor 和 Windsurf 等工具变成了部署、安全、评估和发布的操作界面。

这正是此次发布的核心矛盾。编程 Agent 已经加快了软件生成速度，但生产部署仍会让开发者在云控制台、身份管理面板、安全产品和测试系统之间来回切换。新的 Agents CLI 试图将这些操作置于同一个对话式界面之后。

更广泛的竞争已不再是谁的模型最擅长编写 Agent 函数，而是哪家云厂商能让整个 Agent 生命周期像一个统一的开发流程。Amazon Bedrock AgentCore 和其他托管平台提供了许多类似的构建模块，但 Google 正在其技术栈前端加入编程 Agent 界面。

Google 以 Industry Watch 演示了这套工作流。这是一款半导体情报 Agent，可将公司声明与 SEC 文件进行比对。该示例涵盖构建、部署、记忆、身份、提示注入防御、自动化评估，以及发布到 Gemini Enterprise。

其意义不止于又一个脚手架工具。Google Cloud 希望让编程 Agent 成为开发者操作其托管服务的控制平面。这样的设计可以减少上下文切换，但并不能消除每个提示背后隐藏的架构和安全决策。

Google Cloud 连接了此前彼此分离的六个阶段

这项发布将编程 Agent 从代码生成器转变为完整生产生命周期的操作工具。

Google 于 2026 年 7 月 29 日发布了这套工作流，作为其 Gemini Enterprise Agent Platform 系列的一部分。其lifecycle walkthrough将开发过程组织为六个阶段：设置、构建、部署、治理、评估和发布。

连接层是 Agents CLI：这是一个命令行软件包，配合用于教会编程 Agent 如何使用 Google 平台的 skills。skill 是一种结构化指令包，为助手提供特定任务的流程和工具知识。

开发者首先运行设置命令。该软件包会检测受支持的编程环境，并为 Google 的 Agent Development Kit（通常称为 ADK）安装生命周期 skills。即便没有编程 Agent，它也可以工作，因为每条底层命令仍可直接从终端运行。

这一差异很重要，因为 Google 并未提出另一款专有编程助手。该公司希望让开发者从自己已经使用的任意助手访问其云工作流。其setup documentation列出了 Antigravity CLI、Claude Code、Codex、Cursor、Windsurf 及其他兼容环境。

安装完成后，这些 skills 会引导助手完成项目创建、本地测试、评估、部署和发布。Developer Knowledge MCP 连接可获取最新文档，而不是完全依赖模型训练数据。MCP 即 Model Context Protocol，它为 AI 应用连接外部工具和信息的方式提供标准化规范。

这一文档连接解决了编程 Agent 的一个常见弱点。云端接口变化很快，而模型可能建议过时的命令、不可用的标志或陈旧的权限模式。最新文档可降低这种风险，但无法保证每项生成的决策都正确。

Google 的 Industry Watch 示例始于一个 ADK 项目，用于监控 Nvidia、AMD、Intel、Micron 和 Broadcom。它使用一个工具获取 SEC 文件，另一个工具收集公开声明，第三个工具则对两类来源进行核对。

核对函数通过确定性代码完成核心比较。它按公司和日期连接记录，区分匹配与未匹配项目，删除近似重复项，并对文件的重要性进行评分。模型负责叙述由此产生的证据，而不是凭空推断文件之间的关系。

这种分工是该示例中最有力的选择之一。语言模型擅长解释，但作为数据库并不可靠，作为规则引擎也缺乏一致性。将连接、分类和验证规则移入常规代码，可让最终答案更易于检查。

编程 Agent 会根据自然语言需求搭建这些函数。随后，开发者可以打开本地 playground，测试诸如过去一周内所选半导体公司发生了哪些变化等问题。

该助手不会取代项目文件。它通过已记录的 CLI 创建和修改文件，将代码、清单和测试保留在代码库中。团队可以沿用现有的版本控制流程审查这些产物。

因此，Google 的承诺比完全自主的软件开发更有限。开发者提供目标并审查输出，而编程 Agent 则将意图转化为文件和平台操作。

这种更有限的承诺也更可信。它将自动化集中于重复性的集成工作，同时不假装架构、授权或质量保证可以在无人监督的情况下被委托出去。

为什么编程 Agent 正在成为控制平面

Google Cloud 正在争夺的是从 Agent 创意到受治理企业服务的路径，而不只是模型调用。

一个本地 Agent 可能看似完整，却避开了最棘手的生产问题。它可能使用开发者权限过宽的凭据运行，将状态存储在内存中，缺乏部署隔离，也没有可重复的质量关卡。

生产环境带来了另一组要求。该服务需要稳定的托管环境、会话管理、持久记忆、受控网络访问、范围受限的身份、可观测性，以及员工真正能够找到的界面。

每项要求传统上都存在于不同的产品界面中。开发者可能在编辑器中编写代码，从终端部署，在控制台检查身份，在其他位置配置安全，并在另一个系统中审查评估结果。

这种碎片化会因与模型智能无关的原因拖慢团队。开发者必须记住产品名称、资源关系、区域限制、权限和命令语法，才能验证 Agent 的业务价值。

Agents CLI 将这些交互压缩为提示。编程 Agent 选择命令、编辑配置、启动长时间运行的操作，并检查其结果。Google 的CLI reference涵盖项目创建、playground 执行、评估、部署、可观测性以及 Gemini Enterprise 发布。

产品策略很明确。如果开发者留在偏好的编程 Agent 内，Google 就不需要赢得编辑器市场。它需要的是让助手在后续每一步生命周期中都选择 Google Cloud 作为目标平台。

这是一项重要的分发优势。编程助手正越来越多地处于开发任务的起点，而架构默认选项往往正是在此被确定。平台 skill 可以在开发者打开云控制台之前影响这些默认选项。

这种方法也改变了云文档的作用方式。文档不再仅仅为浏览参考页面的人而写，它还会成为编程 Agent 可检索和应用的操作上下文。

因此，结构良好的文档可以直接提升平台采用率。缺失的前置条件、含糊的权限指导和不一致的命令行为，都会变成自动化失败，而不只是文档缺陷。

这一动态给每一家大型云服务商都带来压力。Amazon Bedrock AgentCore 已提供托管运行时、记忆、身份、网关、浏览器工具、代码执行和可观测性。其runtime overview也强调对多种框架、模型和协议的支持。

Google 的差异在于生命周期界面。Agents CLI 试图通过编程 Agent 协调周边服务，同时让 ADK 项目和命令对开发者保持可见。

竞争差距并非绝对。AWS 可以通过命令行工具和编程 Agent skills 提供类似操作。Microsoft 可以将其 Agent 平台连接到 GitHub Copilot 和既有的企业开发工作流。

真正重要的问题是哪家供应商能让这条路径足够连贯，以至于团队不再自行搭建内部平台。企业很少难以找到另一个模型端点；它们真正的难题，是围绕数百个实验建立可重复的控制机制。

标准化的提示驱动工作流可帮助平台团队编写这些控制机制。一家公司可以维护经过批准的 skills，用于身份、日志记录、数据访问、部署区域和评估关卡。

这会带来超越便利性的潜在组织收益。开发者可以调用经过审查的流程，而无需记住每一项底层政策；与此同时，安全团队仍可保留可检查的配置和命令历史。

不过，编程 Agent 不应成为基础设施漂移的隐形来源。生成的配置仍需要版本控制、审查和策略执行。自然语言可以改善访问平台的方式，但不能作为该平台如何配置的唯一记录。

团队还需要在对话之外保留持久的上下文。工程决策、平台限制和故障记录应在编程会话结束后依然可搜索。共享的engineering knowledge base可将这些材料与代码库一同保存。

持久优势将属于能够将对话便利性与传统软件控制相结合的平台。开发者希望减少中断，但企业仍需要证明哪些内容发生了改变、由谁批准，以及是否通过了策略要求。

这一机制不止于生成 Agent 代码

只有当提示能够落实为确定性工具、托管基础设施和可测试的控制机制时，该工作流才能成功。

Industry Watch 示例表明，Agent 开发不能止步于巧妙的系统提示。其任务需要最新新闻、SEC 文件、可靠的比较方法，以及与真实记录相关联的引用。

普通聊天机器人无法仅凭记忆安全地回答这一问题。“过去一周”会不断变化，而文件标识符必须对应实际提交记录。公开网络内容也可能包含旨在操纵 Agent 的指令。

Google 通过架构来应对这些问题。两个函数获取实时信息，第三个函数执行核对。模型接收结构化结果并进行解释，但不会决定两条记录是否匹配。

这一工具边界限制了模型的权限。它还为日期范围、公司标识符、重复项处理和重要性规则等测试提供了明确位置。

在本地测试后，Agents CLI 会将项目部署到 Agent Runtime。该托管服务为智能体应用提供托管，Sessions 在对话中保留状态，而 Memory Bank 则在不同对话之间存储选定的信息。

持久记忆同时带来价值与风险。记住关注清单或偏好的报告格式可以减少重复配置。治理不善的记忆则可能保留错误、敏感或过时的信息，并将其带入后续决策。

团队需要针对哪些内容可以进入长期记忆、用户如何查看这些记忆，以及何时过期制定明确规则。编码智能体可以生成配置，但产品负责人仍需定义这些政策。

该示例还将确定性计算移入隔离的代码执行沙箱中。这使生成的 Python 与语言模型分离，并限制计算的运行位置。

隔离至关重要，因为智能体越来越多地处理不受信任的输入。新闻标题、文档、工具响应或网站都可能包含试图覆盖系统指令的文本。这类攻击通常被称为间接提示注入。

Google 将 Model Armor 置于提示词、模型响应和不受信任的工具输出之前。该服务会根据配置的模板，筛查内容中的提示注入和越狱模式。

这一防护措施应被视为一道防线，而非保证。攻击者可以改变措辞、利用应用逻辑，或操纵看似可信的来源。即使启用了内容筛查，确定性验证和受限的工具权限仍然必不可少。

身份机制提供了另一层防护。Google 的示例为智能体分配专用主体，并且只请求完成其工作所需的角色。它还将身份与网络访问控制分离开来。

Agent Gateway 可以将出站流量限制为仅访问获批域名。在此示例中，允许的目的地包括 SEC 系统、GDELT 和公司投资者关系信息源。

这一边界能够减少被操纵输入可能造成的损害。即使模型尝试联系未经授权的主机，网络策略也应阻止该请求。

该架构仍依赖谨慎的实施。过于宽泛的域名允许列表、权限过大的服务账号，或接受任意 URL 的工具，都可能削弱周边控制措施。

自然语言配置可以让安全默认设置更容易被提出，但模糊的提示词也可能带来虚假的信心。“让它安全”并不是一份有用的规范。明确指定身份、角色、目的地和禁止操作，能产生更便于审查的结果。

评估是第五阶段，也许是最重要的生产门槛。Google 要求编码智能体生成多轮场景，对任务成功情况和工具使用进行评分，并检测缺乏支持的陈述。

Industry Watch 增加了一项确定性检查：响应中的每个申报标识符和项目代码都必须出现在工具输出中。这将一项宽泛的反幻觉要求转化为通过或失败的条件。

该工作流随后对失败项进行聚类，并且只对由提示词引起的失败应用提示词优化。它会先将修改后的提示词与基线进行比较，再决定是否接受。

这一区分能防止团队把每个缺陷都当作措辞问题。损坏的数据源、错误的关联、缺失的权限或格式不正确的 schema，需要的是工程修复，而不是在系统提示词中再增加一段文字。

Google 更广泛的 Agent Platform 现已将运行时、会话、记忆、治理、评估、追踪和提示词优化纳入同一产品体系。Agents CLI 为编码助手提供了贯穿这一整套能力的路径。

最后，该工作流会将已部署的智能体注册到 Gemini Enterprise 应用中。员工随后可通过现有的工作场所界面访问它，而不是只能使用面向开发者的端点。

发布弥合了一个经常被忽视的缺口。智能体并不会仅仅因为其 API 能够响应就产生价值。它还需要可发现性、适当的访问权限、用户反馈和运营责任归属。

这六个阶段构成了一个连贯的机制，因为每个阶段都会为下一阶段产出工件。代码变成已部署的服务，服务获得控制措施，控制措施进入评估，而经过评估的服务最终向用户开放。

“任何编码智能体”仍然通向同一套云技术栈

Google 的接口对编码智能体保持中立，但展示的生产路径仍深度绑定于 Google Cloud 服务。

“任何编码智能体”这一说法描述的是工作流的前端。开发者可以使用多种助手来操作 Agents CLI，CLI 命令也可以在没有助手的情况下运行。

这并不意味着最终的基础设施是云中立的。该示例使用了 ADK、Agent Runtime、Sessions、Memory Bank、代码执行沙箱、IAM、Agent Gateway、Model Armor、评估服务和 Gemini Enterprise。

这一区分并不会否定该方法。每个托管平台都会将自身工具的整合程度做得比外部服务更紧密。当集成能够减少足够多的运维工作时，客户会接受这种耦合。

不过，团队应在三个独立层面评估可移植性。智能体代码是一层，生命周期自动化是另一层，而托管的生产服务构成第三层。

ADK 是开源的，Google 将其描述为模型无关。确定性的 Python 工具通常只需有限改动即可在不同环境之间迁移。如果开发者将其与云 API 分离，诸如对账逻辑之类的业务规则应能保持可移植性。

部署清单、身份绑定、记忆集成、网关策略、评估追踪和企业级发布的可移植性较低。即便核心智能体代码得以保留，迁移这些组件也需要重新设计。

Amazon 清楚地展示了另一种选择。AgentCore Runtime 支持使用多种框架和模型构建的智能体，而其身份系统会为已部署的智能体创建工作负载身份。其身份文档描述了跨部署环境和凭证类型保持稳定的身份。

两个平台都正在趋向相同的生产要求。它们的差异在于封装方式、接口，以及开发者需要自行组装组件的程度。

Google 的编码智能体战略会促使竞争对手推出可比的端到端工作流。当另一家提供商可以将一项请求转化为经过审查的部署序列时，单纯的服务目录将更难构成竞争优势。

这一战略同样会给内部开发者平台团队带来压力。一些企业已经构建了自定义模板，用于搭建智能体、配置身份、设置网关并启动评估流水线。

Agents CLI 将其中一部分工作打包为由供应商支持的工具。内部团队必须判断，其自定义平台是否仍能提供必要的政策、可移植性和集成优势。

质疑的重点在于抽象泄漏。当部署失败时，开发者仍需理解区域、配额、IAM 绑定、服务依赖关系和日志。助手可以检索文档，但无法让这些约束消失。

生成的命令也可能有误或权限范围超出预期。编码智能体可能选择不合适的角色、修改无关资源，或误解组织策略。高影响操作需要预览和人工确认。

因此，团队应将对话式意图与执行权限分离。助手可以准备部署计划、展示拟议变更并运行验证，再获得修改生产资源的权限。

仓库级审查仍然不可或缺。配置、测试、策略文件和生成的代码应一并提交，让审查者能够看到完整变更。

评估同样需要独立的责任归属。如果同一个模型生成智能体、编写测试并评判输出，盲点可能扩散至整个流程。

正如 Industry Watch 所展示的那样，确定性断言可以降低这种风险。团队还应纳入人工整理的案例、历史失败记录、对抗性输入，以及与业务损害相关联的评估标准。

安全叙事也应保持同样的克制。Model Armor 可以筛查输入和输出，但 Google 尚未提供独立证据证明所展示的配置能够阻止每一种间接注入。

安全的工具边界依赖最小权限、严格 schema、目的地控制、经过验证的输出和事件监控。内容过滤能够支持这些控制措施，但无法替代它们。

此外还存在采用问题。开发者已经信任编码智能体进行代码变更，但基础设施访问会提高风险等级。企业将需要制定政策，规定助手可以执行哪些操作，以及哪些环境仍必须由人工控制。

当工作流保持可审查性时，其价值主张最为强大。如果每条提示词都映射到可见的命令、文件、测试和云资源，团队便能在不丢失运营记录的前提下提升速度。

当开发者因为助手听起来很自信而批准自己并不理解的操作时，这一主张便会被削弱。便利可以缩短安全工作流，但也可能缩短有人发现不安全假设前的停顿。

Google Cloud 已展示了一条从自然语言意图到生产控制措施的可信路径。但它尚未证明生产判断本身可以被自动化取代。

三个信号将检验 Google Cloud 的生命周期押注

下一项考验在于团队是否采用完整工作流，而不是开发者能否完成教程。

第一个信号是能否在 Google 的 Industry Watch 示例之外实现可重复使用。开发者应关注涵盖受监管数据、多智能体系统、内部工具和面向客户工作负载的生产案例研究。

这些案例需要展示的不只是部署成功。有价值的证据包括更短的发布周期、更少的配置失败、一致的评估关卡，以及清晰的事件处理流程。

不同编码智能体之间的广泛采用将强化 Google 的接口战略。如果大多数用户仍局限于 Google 自有的助手，“任何编码智能体”的定位就会显得不那么重要。

第二个信号是竞争对手如何打包自身的生命周期自动化。AWS 已通过 AgentCore 覆盖了所需类别，而 Microsoft 在开发者工具与企业身份之间拥有深度连接。

任一提供商推出可比的、由技能驱动的工作流，都会削弱 Google 的接口优势。竞争将重新转向运行时可靠性、治理覆盖范围、生态系统集成和迁移成本。

较慢的响应将给 Google 留出时间，把 Agents CLI 确立为从代码走向生产的预期路径。开发者往往会保留第一个能够可靠处理部署和安全、且不迫使他们重建内部模板的工作流。

第三个信号是治理能否经受真实组织环境的检验。团队应考察审计追踪、策略执行、审批控制、生成的权限范围、评估历史和回滚行为。

成功的部署将证明，编码智能体的操作仍然可见且可归因。失败则会揭示，对话式自动化是否只是用自信的回应掩盖了同样的云复杂性。

随着平台扩展，应关注 Google 如何处理区域限制和服务前置条件。最初的演示将工作负载保持在一个区域内，因为代码执行沙箱存在区域限制。

成熟的工作流应当及早发现此类约束，说明其后果，并拒绝不安全或不兼容的操作。它还应区分前置条件缺失与需要更高权限的操作。

开发者不应只通过顺利路径测试这套抽象，还应通过失败场景加以检验。撤销某项权限、阻断一个端点、引入格式错误的工具响应，并让对抗性输入通过评估套件。

随后检查编码智能体能否识别真正发生故障的层级。一个有价值的生命周期助手不应将身份问题当作提示词问题，也不应把数据缺陷视为模型问题。

平台团队可以从范围有限的内部智能体开始：其工具仅具备只读权限，且输出能够被独立验证。他们应记录每项生成的变更，并将评估结果与代码一同保留。

知识工作者也应关注这一点，因为最终的发布阶段决定了这些系统能否触达普通员工。部署在熟悉的工作场所应用中、受到治理的智能体，更有可能成为重复性流程的一部分。

开发者也应关注，因为围绕智能体代码展开的重复性工作正变得可自动化。关键技能正从记住每一条控制台路径，转向精确规定架构、权限、证据和失败条件。

企业采购方也应关注，因为界面会影响对平台的长期依赖。即使工作流在编码智能体层面看似可移植，仍可能逐渐积累在运营上替换成本高昂的托管服务。

Google Cloud 的押注是，生命周期层面的便利性将盖过这一担忧。该公司提供了一条涵盖代码生成、托管部署、安全控制、评估和员工分发的对话式路径。

如果 Agents CLI 能成为开发者意图与可审查基础设施之间可靠的翻译器，这一押注便能奏效。如果团队发现助手隐藏了重要决策，或生成了他们无法放心审计的控制措施，这一押注便会失败。

正确的应对方式既不是立即拒绝，也不是不加约束地采用。选择一个可验证的用例，明确工具边界，要求确定性测试，并将生成的基础设施与你现有的生产标准进行对比。

如果这一流程经得起检验，编码智能体就不只是更快的编辑器。它将成为智能体生命周期的实用操作界面，同时由人工审查者继续对进入生产环境的系统负责。