Google Cloud 推出 Gemini Enterprise Agent Platform，但真正的考验在于控制能力

Google Cloud 于 7 月 29 日将多项 Gemini Enterprise 功能正式推向全面可用，距离其推出扩展后的 Agent Platform 仅三个月。这次发布让持久记忆、七天执行、代理身份、治理、评估和可观测性进入更广泛的生产应用。矛盾显而易见：更长时间的自主运行带来更大价值，但也让软件拥有更多时间和权限去犯下影响重大的错误。

这并非又一套代理构建工具。Google 试图提供一个位于 AI 模型与其可改变的企业系统之间的运行层。该层必须在持续数天的工作流中保留上下文、分配权限、记录操作、执行策略并衡量结果。

Amazon 和 Microsoft 正通过 Bedrock AgentCore 与 Microsoft Foundry 争夺同一个控制点。竞争的核心已不再仅仅是谁提供最强大的模型，而越来越关乎哪家云服务商能让安全团队、开发者和业务负责人认为自主工作足够可控，从而批准其投入使用。

Google Cloud 将其代理预览版转为生产平台

此次发布推动 Gemini Enterprise Agent Platform 从一个雄心勃勃的框架，迈向企业可部署和治理的运营系统。

Google 于 4 月 22 日将当前平台作为 Vertex AI 的演进版本推出。其既定目标是将模型访问、代理开发、部署、安全和优化整合到一个环境中。该公司还表示，未来 Vertex AI 服务和路线图更新将通过 Agent Platform 推出，而不再作为独立产品线发布。

三个月后，Google 已将七项核心功能推向全面可用。Agent Memory Bank 可跨会话保留结构化上下文。Agent Runtime 支持最长七天的异步工作。Agent Identity 为每个代理提供专属身份，用于访问控制和审计。

Agent Gateway、Agent Registry、Agent Evaluation 和 Agent Observability 构成其余控制层。它们共同管理工具连接、编录已部署代理、衡量行为并追踪执行过程。Google 在其 Agent Platform 更新中介绍了这些功能，并将此次发布定位为安全扩展代理规模的一环。

七天运行时是最显眼的变化。传统聊天机器人会在一个会话内回应，随后等待下一次请求。长时间运行的代理则可以在数天内管理销售流程、监测供应链状况，或协调入职流程。

这种持久性改变了工程问题。代理需要持久状态、恢复逻辑、权限边界以及每项操作的记录。当用户关闭应用后，同一流程仍继续运行时，暂时的模型错误会变得更加严重。

Memory Bank 通过将选定事实提取到结构化模式中，解决了这一挑战的一部分。它能够保留偏好、账户历史和先前决策，而无需代理从完整对话记录中重建一切。Google 表示，这一设计可支持低延迟的个性化长期工作。

存储的记忆与原始对话历史之间的差异至关重要。对话记录包含说过的全部内容，其中也包括无关细节和过时指令。结构化记忆则选择预计仍具价值的信息。不过，这一选择过程也创造了新的故障点，因为系统可能保存错误的推断。

因此，Google 将运行时和记忆作为一对功能出售。运行时让工作持续进行，而 Memory Bank 让其上下文保持可用。两项功能单独来看都无法让代理变得可靠，但结合后，开发者便可尝试超出单次请求范围的工作流。

此次发布还将平台的覆盖范围扩展至并非完全由 Google 模型构建的代理。Google 在发布时表示，Model Garden 提供对超过 200 个第一方、第三方和开放模型的访问。这一选择表明，即便客户选择其他供应商的模型，该公司也希望掌控部署和治理环节。

这一战略使 Agent Platform 的意义不止于 Gemini 的分发渠道。Google 正将其定位为异构代理集群的基础设施。如果组织将其身份、注册表、网关和监控服务视为这些代理集群的共享控制机制，该平台便能取得成功。

Google Cloud 为何围绕代理控制展开竞争

企业买家越来越少受到模型可用性的限制，越来越多地受到代理操作所带来的运营风险限制。

一个原型代理可以使用有限的数据集和少量工具。生产代理则会接触客户记录、内部应用、凭据、审批链和合规要求。每增加一项连接，都会扩大代理的实用性及其潜在影响范围。

Google Cloud 正以专为代理设计的身份模型作出回应。Agent Identity 是一种原生身份与访问管理类型，并非简单复用的服务账号。Google 表示，它将访问权限绑定到运行时，应用最小权限原则，管理身份生命周期，并生成不可否认的审计记录。

最小权限原则是指，仅授予完成明确定义任务所需的访问权限。这一理念并不新鲜，但代理使其实现更困难。它们的计划可能在执行期间发生变化，并且可能为实现一个广泛目标调用多个工具。

传统服务账号常会在应用发生变化或消失后继续保持活跃。随着团队添加集成，权限也会不断累积。Best Buy 在 Google 的公告中将孤立账号、所有权不明和权限持续扩张描述为反复出现的问题。

专属代理身份创造了更清晰的问责单元。管理员可以追问：哪个代理执行了操作、它访问了什么、谁负责它，以及哪个运行时授权了该操作。当代理无需人工批准每一步便可作出决策时，这种可见性变得至关重要。

Agent Gateway 位于下一道边界。它集中管理代理、模型和工具之间的交互。管理员可以应用身份条件和自然语言规则，同时 Model Armor 会检查流量中的提示注入、工具投毒和数据泄露风险。

提示注入是指恶意或不受信任的内容操纵代理指令。工具投毒则涉及被攻陷的工具描述或响应，从而改变代理行为。当代理能够访问文件、发送消息、更新记录或修改软件时，这两类攻击的后果会更加严重。

Agent Registry 则解决另一类问题：组织蔓延。它提供企业内部代理、服务器和连接的目录。团队可以发现现有组件，而管理员可以识别所有权并监控部署情况。

注册表并不会自动阻止重复或不安全的代理。其直接贡献在于提高可见性。一个组织无法对其中央团队根本不知道存在的软件实施一致控制。

Google 的时机反映出试点项目与受治理的生产系统之间日益扩大的差距。许多团队能够利用模型、提示词和几个 API 组合出实用代理。但拥有统一身份、记忆、评估和事件调查系统的团队则要少得多。

这一差距给云服务商带来压力，因为客户更青睐能够与现有基础设施集成的运营控制能力。身份策略、日志系统、网络控制和数据服务已位于云环境中。当代理平台能够复用这些基础时，其吸引力就会更大。

同样的动态也给独立代理框架带来压力。开放框架可为开发者提供可移植性和灵活性，但企业团队仍需要运行时和治理平面。Google 支持开放标准及其 Agent Development Kit，但托管运营层会鼓励更深入地使用其云服务。

因此，战略奖品远大于模型消费。获胜的平台可以成为企业注册代理、授予权限、检查追踪记录和评估性能的默认场所。一旦这些控制机制围绕某项工作负载建立，迁移它就会变得更复杂。

连接记忆、身份与评估的机制

Google 的核心押注是：当执行、权限、上下文和度量共享同一个控制平面时，自主代理便能变得可管理。

Agent Runtime 提供执行环境。Memory Bank 维护选定的上下文。Agent Identity 决定系统将谁视为执行主体。Agent Gateway 管理对模型和工具的访问，而 Registry 则记录已部署的内容。

Evaluation 和 Observability 形成闭环。Observability 会记录代理做了什么，包括推理轨迹、工具使用、延迟和执行行为。Evaluation 则检验结果是否达到预期标准。

Google 将这两项功能整合在同一引擎上。开发者可以在构建期间和部署之后使用相同的度量逻辑。该公司表示，评估选项包括预定义指标、自定义 Python 函数、基于模型的评判器，以及与 Google DeepMind 共同开发的自适应评分标准。

这种连续性很重要，因为离线基准测试往往无法代表真实运行条件。测试数据集无法预见每个客户请求、工具响应变化或权限状态。在线评估能够在发布后发现性能下降和行为漂移。

行为漂移是指，即使代理声明的目的保持不变，其结果也会随时间改变。模型更新、修订后的提示词、新数据源或经过修改的工具都可能导致这种变化。持续监控有助于团队定位变化从何时开始。

不过，评估无法消除主观判断。基于模型的评判器可能继承负责评估的模型本身的偏见或弱点。自定义指标可能针对易于衡量的代理指标进行优化，却忽视真正重要的业务结果。

生产团队仍需要明确的成功标准。客户支持代理可以按照解决质量、策略合规性、升级判断准确性和客户投入程度进行衡量。若只关注响应速度，可能会奖励自信却错误的答案。

当评估能够触发运营行动时，集成式架构会更加有用。评分下降可能导致降低代理权限、将工作转交人工，或暂停工作流。Google 的公告描述了监控能力，但客户仍必须设计适当的干预策略。

AT&T 提供了一个具体的记忆案例。该公司表示，其销售代理使用 Memory Bank 汇总先前客户互动中的事实，使对话能够在间隔后继续。它也在努力实现应用、语音和网页渠道之间的连续性。

这一案例说明了好处与风险。被记住的上下文可以避免客户重复提供信息。错误或过于宽泛的记忆也可能跨渠道传播，并影响后续决策。

Commerzbank 展示了治理层面的需求。该行表示，正评估 Agent Registry 和 Agent Gateway 在可发现性、政策执行、访问管理、可观测性和审计方面的作用。其兴趣说明，为什么集中式控制层会吸引受监管机构。

WellSky 表示，其使用集中式注册表对代理进行编目、版本管理和全生命周期管理。公司将该目录与合规政策和生产审批相连接。这更接近软件资产管理，而非面向消费者的 AI 功能。

CodeMender 将同一机制延伸至软件安全领域。Google 将其描述为一款托管代理，可发现、验证并提出代码漏洞修复建议。核心推理在云端运行，而编译、测试和漏洞利用模拟则在客户自管的沙盒或隔离虚拟机中运行。

CodeMender 设计保留了人工审批环节。开发者会以本地 diff 的形式收到拟议变更，代理不会直接将其提交至生产代码库。Google 还表示，客户代码不会被用于训练其基础模型。

这一边界具有启发意义。CodeMender 自动执行分析和补丁创建，但并未免除开发者责任。人工审查步骤恰好在错误变更可能引入新漏洞或扰乱生产环境之处限制了自主性。

知识密集型代理同样需要类似边界。团队可使用可搜索的知识库来整理内部证据，但检索本身并不授权代理采取行动。上下文、权限和验证仍是彼此独立的设计决策。

AWS 和 Microsoft 正在构建相同的控制层

Google 的功能组合通过集成实现差异化，而非处于一个没有竞争的类别之中，因为其最大的云服务竞争对手如今也提供了类似的代理基础设施。

Amazon Bedrock AgentCore 将代理逻辑与其托管基础设施分离。其 Runtime 提供隔离、扩展、会话、身份验证关卡和可观测性基础能力。开发者仍可控制编排循环，并连接 Memory、Gateway、Identity 及其他服务。

AgentCore runtime可托管使用不同框架编写的代码。这种方式吸引了希望使用托管基础设施、但不愿采用单一代理框架的团队。它也使 Amazon 的竞争应对方案能够与 Google 的平台直接比较。

AWS 为自动化工作负载提供专门的身份和凭证服务。根据其身份文档，AgentCore Identity 支持身份验证、授权、第三方凭证和审计追踪。其工作负载身份遵循既有身份模式，同时增加了代理专属属性。

Microsoft Foundry Agent Service 同样将运行时、编排、身份、安全和可观测性结合起来。其托管运行时可以隔离会话，Microsoft Entra 则提供身份和基于角色的访问控制。Application Insights 支持追踪和生产监控。

Microsoft 还通过 Microsoft 365 和 Copilot 具备额外的分发优势。已经使用 Entra、Teams、SharePoint 和 Microsoft 365 的组织，可以将 Foundry 视为其现有工作环境的延伸。Google 也可通过 Google Workspace 及其云数据产品提出类似主张。

Microsoft 还允许客户注册部分外部托管的代理，以实现可观测性和评估。其外部代理控制使用 OpenTelemetry 追踪，使 Foundry 无需托管或调用代理运行时即可对其进行监控。一些相关能力仍处于预览阶段，包括对外部代理进行人工评估和红队扫描。

因此，这三个平台体现了同一论点的不同版本。企业代理需要托管执行、持久上下文、身份、工具治理和监控。云服务商希望这些服务成为每个代理之下的标准基础。

Google 的优势在于其新近可用技术栈的连贯性。Runtime、Memory Bank、Identity、Gateway、Registry、Evaluation 和 Observability 共享同一产品体系。Gemini Enterprise 还可以通过受控应用向员工分发代理。

其挑战在于证明统一技术栈能够带来更好的运营成果。相似的功能名称并不能证明可靠性更高。客户将评判集成质量、政策精确度、事件响应、区域可用性、框架支持，以及运营每个系统所需的投入。

可移植性仍是另一个悬而未决的问题。Google 表示 Agent Platform 支持第三方模型和开放标准。但围绕其身份类型、记忆模式、注册表、评估引擎和网关政策构建的代理，迁移成本可能很高。

AWS 和 Microsoft 也会形成类似依赖。其托管服务通过替客户做出平台特定选择来减少工程工作量。这种权衡在云计算中很常见，但自主代理提高了风险，因为治理数据和行为历史也会与供应商绑定。

因此，企业应区分模型可移植性与运营可移植性。切换代理背后的模型可能只需更改配置；迁移其身份历史、持久记忆、评估记录、网关政策和审计追踪，则是规模更大的迁移工作。

竞争不会由最长的功能清单决定。关键在于某个平台能否减少通过安全审查并维持可靠生产行为所需的工作。这些成果需要发布公告之外的证据。

尚未解决的风险是治理能否跟上步伐

代理控制可降低已知风险，但更长的运行时间和更广泛的工具访问会带来仪表板无法自动解决的失效模式。

一个运行七天的代理有更多机会遇到过期数据、相互冲突的指令、失效凭证和意外的工具行为。它还可能通过后续决策放大早期错误。因此，运行时长既是一项能力，也是风险放大器。

持久记忆带来了另一种张力。当代理记住偏好和过往决策时，个性化效果会提升；而当团队必须决定系统应提取什么信息、保留多久，以及用户如何纠正这些信息时，治理会变得更困难。

结构化模式提供了约束，但模式设计本身是一项政策选择。销售代理可能需要客户的产品兴趣，却无需保留敏感个人细节。内部代理可能需要项目决策，却不应将每条推测性评论都视为既定事实。

Agent Identity 可以显示哪个软件实体执行了某项操作，但这并不必然解释该操作为何发生。完整调查可能需要代理指令、模型版本、检索到的上下文、工具响应、记忆状态、政策决策和评估结果。

可观测性可以收集大部分此类证据。然而，记录所有内容会带来隐私和存储问题。详细的推理追踪可能包含客户信息、机密文件或敏感工具输出。

团队必须决定哪些追踪记录可以安全保留，以及谁可以查看它们。他们还需要制定与法律义务一致的保留期限和脱敏政策。集中化有助于执行这些选择，但并不会让选择本身变得简单。

自然语言网关规则也应受到同样审视。它们使政策更易于表达，但安全控制必须在对抗性条件下表现可预测。组织应测试等价请求是否获得一致决策，以及政策冲突是否能够安全地失败。

Google 表示，Model Armor 有助于防御提示注入、工具投毒和数据泄露。这些保护措施应被视为分层系统中的控制手段，而非代理安全的证明。没有任何过滤器可以预见每一条恶意指令或受损集成。

Google 公告中的客户表述令人鼓舞，但仍有局限。它们描述的是选定部署和评估，而非独立的比较性测量。此次更新并未提供全平台错误率、安全事件率或运营投入量化下降的数据。

对于一项刚刚可用的产品而言，这种缺失可以理解。但这也意味着，买家不应将正式可用性视为其在每种工作负载中都已具备成熟性能的证据。最有力的验证将来自在可衡量控制下持续的生产使用。

对于高影响操作，人工审查仍然必要。CodeMender 通过要求开发者批准补丁展示了这一原则。金融转账、账户关闭、生产变更和具有法律意义的通信，同样应设置明确边界。

适当的自主程度取决于可逆性。当某项操作易于检查和撤销时，代理可以获得更多自由。不可逆或对外可见的决策则需要更严格的权限、更强的评估和可靠的升级机制。

公司还需要在平台团队之外明确责任归属。安全人员可以定义访问规则，业务负责人则定义可接受的结果。法务和隐私团队决定哪些信息可以进入记忆或日志。

若缺乏共同责任，Agent Registry 可能沦为无人积极治理的系统目录。评估仪表板可以产生分数，却没有相应处置流程。身份记录可以在事件发生后确定归因，却无法阻止事件发生。

Google 已组装出构成可信控制平面所需的组件。剩余问题是，组织能否将这些组件转化为可执行的运营实践。技术可以揭示一项决策，但问责仍属于人。

Gemini Enterprise 扩展后值得关注的事项

下一阶段将通过真实采用情况、经验证的治理成果和竞争性回应来衡量，而非通过更多代理演示。

第一个信号是关于七天工作流的生产证据。客户应记录完成率、人工干预频率、恢复行为，以及在多个步骤中累积的失败数量。可靠的长时运行表现将强化 Google 关于 Agent Runtime 超越短时聊天会话的主张。

较低的完成率则会指向相反结论。这将表明，持久执行的到来速度快于规划可靠性的提升。重要衡量标准不是代理是否能保持活跃七天，而是它是否能在既定限制内完成有用工作。

第二个信号是 Agent Identity 和 Gateway 在审计和事件处理中的表现。企业需要证据证明权限始终收敛、凭证生命周期能够正确结束，以及调查人员可以重建重要操作。金融、医疗保健和电信行业的成功审查将支持 Google 的治理论点。

安全团队还应审查被阻止的事件，而不仅是成功部署。有价值的披露应包括遭拦截的注入尝试、被拒绝的工具调用、政策冲突，以及识别行为异常代理所需的时间。汇总报告可帮助买家比较控制措施，同时不暴露客户细节。

第三个信号来自 AWS 和 Microsoft 的回应。两者都已提供运行时、身份、记忆、网关和可观测性服务。它们接下来的发布将显示，Google 是否已建立起实质性领先优势，还是仅仅达到了正在形成的云端基线。

框架和遥测数据的可移植性将尤为重要。Microsoft 对外部托管 Agent 追踪记录的支持提供了一种思路。AWS 则强调其托管运行时内的框架灵活性。Google 必须证明，其统一体验并不要求客户放弃实用的选择权。

采购方应使用同一套具有代表性的工作流测试每个平台。测试应包括一项长时间运行的任务、一次权限变更、一条注入式指令、一次工具失败、一次记忆修正，以及一次评估回归。功能清单无法揭示完整系统在压力下的实际表现。

开发者还应询问，该平台是否能让故障变得可理解。只有当追踪记录能够将结果关联到对应的指令、上下文、工具、策略和模型时，它才有价值。如果系统无法梳理这些关系，更多遥测数据反而可能加剧混乱。

知识工作者也有类似顾虑。持久运行的 Agent 将越来越多地基于笔记、文档、会议记录和历史决策采取行动。个人AI 工作流有助于整理这些上下文，但企业级行动仍需要明确的权限与审核。

Google Cloud 现已将其主要 Agent 控制能力推向全面可用阶段。这是一次重要的产品转变，但并不意味着自主化企业工作已经得到解决。真正的考验始于 Agent 连续运行数日、跨越系统边界，并遭遇其构建者未曾预见的情境之时。

在扩大 Agent 的权限之前，先问一个务实的问题：你的团队能否重建、停止并安全撤销它最可能造成的严重损害行为？如果答案并不确定，应先利用这些新控制能力收窄工作流范围。全面可用让更广泛的部署成为可能；证据、责任归属与严格的边界，才能让它变得负责任。