Gemini 托管代理解析:Google 2026 年的企业代理平台
Google 的 Managed Agents API 为开发者提供了一个全托管、沙箱化的自治代理运行时——内置集中治理、与 Workspace 的深度集成以及企业级安全能力。

每一家大型云平台都在竞相回答同一个问题:如何让企业部署自治 AI 代理,同时又不牺牲控制力、安全性或合规性?Google 的答案是 Managed Agents API——它是 Gemini Enterprise Agent Platform 面向开发者的核心,前身名为 Vertex AI Agent Platform。
不同于面向消费者的 Gemini Agent,或无需代码的 Workspace Studio,Managed Agents 是专为需要沙箱化运行时、可配置网络策略、集中治理以及与企业数据深度集成的团队而打造的。这是 Google 针对 agentic enterprise 基础设施层的布局——也是任何云厂商推出过的最完整代理技术栈之一。
下面将介绍它是什么、如何工作,以及对于在企业代理平台上构建或评估的团队意味着什么。
什么是 Gemini Managed Agents?
在 Google 的术语中,managed agent 是一种自治 AI 代理,它运行在 Google 托管的、沙箱化的 Linux 环境中——通过 Google 的 Agent Platform 上的 Managed Agents API 进行部署、治理和编排。
这与通过串联 Gemini API 调用构建的轻量级“agent”模式有着实质性区别。managed agent 运行在专用运行时中(由 Google 的 Antigravity harness 驱动),可以跨多步骤工作流进行推理、执行代码、调用工具、访问挂载的企业数据,并与外部服务交互——同时始终处于 Google 代你管理的、严格且可配置的安全边界之内。
实际效果是:开发者通过配置定义 agent 应该具备哪些能力,而 Google 负责基础设施——无需管理虚拟机,无需编排容器,也无需自行构建沙箱。
Managed Agents API:控制平面与数据平面
Managed Agents API 分为两个层面,对应熟悉的云计算模式:控制平面和数据平面。
Agents API(控制平面)
Agents API 负责 managed agent 的生命周期——创建、配置、更新,以及在组织层面进行治理。通过这个 API,开发者可以:
- 通过配置(YAML/JSON 风格)定义 agent,指定其工具、数据挂载、环境变量以及出站网络允许列表。
- 挂载企业数据源——包括 Workspace 数据、内部文档存储或外部 API——供 agent 在执行期间访问。
- 应用与 Gemini Enterprise 的 DLP 和访问控制规则一致的安全与治理策略。
- 以编程方式管理 agent 生命周期事件(创建、更新、禁用、审计),方便集成到现有 CI/CD 或基础设施工具链中。
将预配与运行时调用分离是有意为之:这样 IT 和安全团队可以在任何用户与 agent 交互之前,就先治理 agent 能做什么。
Interactions API(数据平面)
Interactions API 是运行时接口——应用程序实际与正在运行的 managed agent 进行交互的方式。通过这个 API,调用方可以:
- 向特定 agent 实例发送提示词和任务。
- 在 agent 推理并执行工具调用时,接收流式或批量响应。
- 根据日志配置,观察中间步骤——规划、工具调用、代码执行等。
控制平面/数据平面的拆分意味着,一个 agent 定义可以服务多个调用方,而每个调用方都不需要了解 agent 的内部实现。它还使得在控制平面更换 agent 配置而不影响下游应用变得更容易。
Antigravity 沙箱运行时
managed agent 的执行环境是 Google 的 Antigravity harness——一个按 agent 预配的 Linux 沙箱,为多步骤 agentic 工作提供安全、隔离的环境。
在这个沙箱中,managed agent 可以:
- 推理与规划,使用 Gemini 模型(包括为更长 agentic 工作流调优的 Gemini 3.5 Flash,以及适用于更复杂任务的 Gemini 3.1 Pro)。
- 调用工具——网页搜索、代码执行、函数调用,以及通过外部连接器定义的自定义工具。
- 执行代码、读写文件,并在遵守 agent 配置中定义的网络约束下完成多步骤工作流。
Google 全权管理这个沙箱。开发者通过 Agents API 配置行为;平台负责隔离、资源限制和安全边界。这正是其核心基础设施押注:企业更愿意配置治理策略,而不是自己运营沙箱化运行时。
更广义的 Gemini Enterprise Agent Platform
Managed Agents API 只是 Google 所称的 Gemini Enterprise Agent Platform 更大技术栈中的一层。对于任何评估或基于它构建的团队来说,理解 managed agent 在这个技术栈中的位置至关重要。
| 层级 | 界面 | 适用对象 |
|---|---|---|
| 无需代码 | Workspace Studio / Agent Designer | 用于构建自动化的业务用户,无需编写代码 |
| 低代码 | Agent Studio(GUI) | 希望使用可视化设计环境的运营人员 |
| 专业代码 | Agent Development Kit(ADK) | 在 Vertex AI Agent Engine 上构建完全自定义代理的开发者 |
| 托管运行时 | Managed Agents API | 需要沙箱化、可治理、配置驱动型代理的开发者 |
| 治理层 | Gemini Enterprise app | 负责监管所有代理类型的 IT/安全管理员 |
每一层都会向上汇入 Gemini Enterprise,后者为组织中的每一个 agent 提供集中视图——包括 Google 构建的、员工构建的、自定义 ADK agent,以及第三方合作伙伴 agent——全部处于同一套可见性和策略控制之下。
Workspace Studio Agents 与 Managed Agents:有什么区别?
Google 的 agent 叙事中一个常见的混淆点,是 Workspace Studio agents 与 Managed Agents API agents 的关系。它们解决的是技术栈不同层次、不同的问题。
Workspace Studio 是无需代码/低代码界面,供日常业务用户设计、管理和共享 AI agents(“flows”),以自动化 Gmail、Drive、Chat、Sheets 以及 Asana、Jira、Slack、Salesforce、Mailchimp 等已连接的第三方应用中的工作。这些 agents 旨在通过自然语言提示词、预构建步骤、模板、webhooks 和 Apps Script 步骤在几分钟内完成构建——无需工程支持。
Managed Agents 则面向需要更深控制的开发者:沙箱化运行时、可配置网络允许列表、自定义工具定义、数据挂载以及企业安全策略。对于复杂的后台工作流、多系统自动化,以及治理和可审计性不可妥协的场景,它们是更合适的选择。
随着时间推进,Google 正在把这些层级连接起来。Workspace Studio agents 可以调用基于 Agent Platform 构建的自定义 agent,而两者都会通过 Gemini Enterprise 的治理控制台呈现。整个技术栈被设计为可组合的——不同团队可以在最符合自身技能和需求的层级上构建。
Google 内置的 Agents:参考实现
除了面向开发者的 API 之外,Google 还推出了多个第一方 agent,用来展示平台能力——同时也作为 managed agent 适用工作流的参考实现。
Deep Research 会执行数百次网页与企业搜索,制定研究策略,并将结果整合成结构化报告。原本可能需要团队花数周手工整理的内容,现在几个小时就能完成。
NotebookLM Enterprise 是一款 AI 驱动的研究与写作 agent,可在密集的文档来源中进行总结、提取和问答——基于组织自身内容,并通过 Gemini Enterprise 进行治理。
Gemini Code Assist 和 CodeMender 面向开发者生产力与安全。CodeMender 会特别识别代码库中的漏洞,建议并测试修复方案,并在开发者批准后应用补丁——形成一个闭环安全工作流。
Gemini Spark(我们在单独的 Gemini Spark 深度解析 中有详细介绍)是 Gemini Enterprise 中一个持久化的个人 AI agent,可跨 Workspace 和自定义连接器执行多步骤任务,运行周期性工作流,学习新技能,并在发送邮件等高风险操作前请求批准。
Gemini Apps 中的 Gemini Agent 则是面向消费者的版本——它是一个 Labs 功能,允许用户委派多步骤任务,例如邮件分类、起草回复、日历重组和网页研究。它需要 Google AI Ultra 订阅,目前仅在部分地区可用。
这些内置 agents 共同体现了 Google 的思路:公开“自用”,展示场景,再让企业团队复制或扩展这些模式。
安全、治理与合规
集中式治理是 Google 在这个平台上押注的核心差异化能力。对于 IT 和安全团队而言,其控制项包括:
集中可见性。 Gemini Enterprise app 提供一个统一控制台,管理员可以看到组织中的每一个 agent——包括 Google 构建的、员工构建的、自定义 ADK agent 和第三方合作伙伴 agent——以及它们的配置、访问级别和状态。
沙箱化执行。 每个 managed agent 都运行在 Google 托管的 Linux 沙箱中,并带有可配置的网络允许列表。agent 只能访问其配置中明确允许的外部服务,从而降低未授权数据访问或横向移动的风险。
通过 Agent Gateway 执行策略。 agent 到外部数据源和服务的流量会经过一个 Agent Gateway,它负责执行 DLP(数据泄露防护)和安全策略。agent 使用有范围限制的凭据来认证外部工具,而不是广泛开放的 API 密钥。
可审计性。 管理员可以检查和审计 agent 活动日志,以满足要求完整记录 agent 做了什么、何时做、为何这么做的合规要求。
面向消费者的 Gemini Agent 还增加了额外的用户侧安全护栏:明确的安全提示(包括建议不要在聊天中输入密码),以及提醒不要安排高风险的重复性操作,因为模型可能会出错。
开发者体验与模式
对于将 Managed Agents API 集成到现有基础设施中的团队来说,其体验是配置驱动、REST-first 的。常见实现模式包括:
通过配置文件声明式定义 agent,指定工具、技能、数据连接和运行时约束——然后像其他基础设施即代码工件一样将这些配置提交到版本控制中。
使用 Agents API 以编程方式在 CI/CD 管道中创建和更新 agent,使 agent 部署遵循与应用部署相同的审查和批准流程。
通过后端服务、编排层或其他 agent 调用 Interactions API——并借助 Agent-to-Agent(A2A)协议,让 managed agent 能够跨系统互相调用。
Antigravity 2.0 提供独立桌面应用和 CLI,让构建者在部署到托管平台之前,获得更多开发阶段的控制、定制和本地编排测试工具。
Managed Agents 擅长的使用场景
该平台针对复杂的多步骤工作流进行了优化,这类工作流能从沙箱执行和企业数据 grounding 中获益。已记录的使用场景包括:
跨系统自动化——使用连接器和自定义工具在 Workspace、Jira、Salesforce 和内部系统之间编排工作流,而无需为每一对系统构建自定义集成中间件。
研究与分析——使用类似 Deep Research 的 agents,基于网页内容和内部文档执行多步骤市场研究、竞品分析和尽职调查工作流。
知识管理——借助类似 NotebookLM 的 agents,在密集的企业文档存储中进行总结、问答和洞察提取,并与 Workspace 和 Drive 集成。
开发者生产力与代码安全——通过 Code Assist 和 CodeMender 实现自动化代码审查、重构和安全补丁修复,并在每个关键步骤设置人工审批关卡。
周期性工作流自动化——使用 Workspace Studio 处理日常自动化(邮件摘要、会前简报、支持分流),而使用 Managed Agents 处理需要自定义工具或严格治理的更复杂编排。
生态:Marketplace、合作伙伴与 ADK
除了核心 API 之外,Google 还构建了一个 Agent Marketplace,让组织可以发现、评估并部署由合作伙伴构建的 agent。Marketplace 可按行业、使用场景和验证状态进行筛选(包括 Gemini Enterprise 兼容性认证)。
第三方集成覆盖常见企业工具生态:Asana、Jira、Mailchimp、Salesforce、Slack、Teams 等——可通过 Workspace Studio 中的连接器、webhooks 和自定义步骤访问。
Agent Development Kit(ADK) 是为追求最大控制权的团队准备的专业代码路径。ADK agents 是完全自定义的实现,托管在 Vertex AI Agent Engine 上,但会与 managed agents 一起通过 Gemini Enterprise 展示和治理。ADK 与 managed agents 是互补关系,而非竞争关系:managed agents 处理配置驱动的自治工作流这一通用场景;ADK 则处理需要定制编排逻辑的场景。
构建者需要考虑的权衡
对于正在构建 agentic 产品或评估企业代理平台的团队来说,Gemini managed agents 提供了托管基础设施、治理工具和 Workspace 集成的强大组合。但这些权衡也需要坦诚看待。
厂商锁定是真实存在的。 Antigravity 运行时、Agents API 和 Agent Gateway 都是 Google 专有的。基于这套技术栈构建的 agent 与 Google Cloud 有着实质性耦合。需要在本地、混合云或多云环境中运行 agent 的团队,会发现该平台存在限制。
数据驻留和合规约束 取决于 Google Cloud 的区域可用性,未必能满足所有监管体系。对数据主权要求严格的团队,在承诺使用前应先确认区域可用性。
模型灵活性有限。 managed agent 运行在 Gemini 模型上。希望把特定负载路由到其他前沿模型——或出于成本和隐私原因使用开源模型——的组织,需要额外架构来实现这种灵活性。
治理对合适的组织来说是优势,而不是限制。 企业 IT 和安全团队往往把集中治理视为前提条件,而不是锦上添花。对这些组织而言,Gemini Enterprise 的可见性和策略控制可以加速内部对 agent 部署的审批。
对于正在构建独立、开源 AI coworkers 或多模型编排平台的团队,实际路径往往是集成:把 Gemini managed agents 视为一个部署目标,同时保持核心编排逻辑与云厂商无关。
Gemini Managed Agents 在竞争格局中的位置
| 能力 | Gemini Managed Agents | Microsoft Azure AI Agents | AWS Bedrock Agents |
|---|---|---|---|
| 托管沙箱运行时 | 是(Antigravity) | 部分 | 部分 |
| 原生 Workspace 集成 | 深度集成(Gmail、Drive、Docs 等) | Microsoft 365 原生 | 有限 |
| 无需代码的 agent 构建器 | Workspace Studio | Copilot Studio | 无对应产品 |
| 集中式治理控制台 | Gemini Enterprise app | Azure AI Foundry | AWS Console |
| Agent-to-Agent 协议 | A2A(原生) | 有限 | 有限 |
| Agent Marketplace | 是 | 有限 | 有限 |
| 开源模型支持 | 否(仅 Gemini) | 部分(通过 Azure OpenAI 等) | 是(广泛模型目录) |
| 专业代码 SDK | ADK + Vertex AI Agent Engine | Semantic Kernel / Promptflow | Bedrock AgentCore |
对 Google 来说,最明显的优势是 Workspace 深度集成,再加上从无需代码到专业代码的完整谱系,让不同团队都能在匹配自身技能的层级上构建。相较 AWS,最明显的差距在于模型广度——Bedrock 的多模型目录让团队在不离开托管基础设施的情况下拥有更多灵活性。
最终结论
Gemini managed agents 是 Google 对“agentic enterprise”平台最完整的一次描绘:沙箱化运行时、配置驱动的开发者 API、面向业务用户的无代码界面、第一方参考 agents、集中治理,以及第三方扩展 marketplace。这些组件之间的衔接是连贯的。
对企业买家来说,真正的问题不是平台是否具备能力——显然具备——而是 Google Cloud 锁定、仅支持 Gemini 模型,以及数据驻留限制这些权衡,是否适合自身场景。对于已经深度投入 Google Workspace 和 Google Cloud 的组织,答案很可能是肯定的。对于需要模型灵活性或混合云部署的组织来说,这种托管便利性会带来值得认真评估的架构约束。
这对 Eigent 的意义
Gemini 的托管代理架构——沙箱化运行时、受治理的工具访问、agent-to-agent 协同——反映了一组基础设施层面的押注,而 Eigent 正在以开放、模型无关的基础独立构建这些能力。路线图上包括:更深入支持 隔离的 agent 工作空间,以复制托管运行时的沙箱保障;以及可跨 Gemini、Claude、GPT 和本地模型工作的 多代理编排协议——这样团队就不必为了获得企业级代理协同而被迫选择单一供应商。
常见问题
什么是 Gemini managed agents?
Gemini managed agents 是运行在 Google 托管的、沙箱化 Linux 环境中的自治 AI 代理,通过 Gemini Enterprise Agent Platform 上的 Managed Agents API 进行预配和治理。开发者配置 agent——指定工具、数据挂载和网络策略——而 Google 负责底层基础设施、安全和运行时。
Managed Agents API 与直接使用 Gemini API 有什么不同?
直接使用 Gemini API 需要你自己构建编排、工具调用逻辑、沙箱和治理。Managed Agents API 提供了一个全托管运行时(Antigravity harness),由 Google 负责这些基础设施。权衡是:灵活性更低,但运维开销也更小。
什么是 Antigravity harness?
Antigravity 是 Google 为 managed agent 提供的代理执行运行时。它会为每个 agent 预配一个 Linux 沙箱,agent 可以在其中使用 Gemini 模型进行推理、执行代码、调用工具、访问挂载的数据源,并完成多步骤工作流——全部运行在 agent 配置中定义的安全约束之内。
Workspace Studio 与 Managed Agents API 有什么区别?
Workspace Studio 是一个面向业务用户的无代码/低代码界面,用于在 Gmail、Drive、Docs、Sheets 和第三方应用之间构建和共享自动化 agents。Managed Agents API 则是面向开发者的 API,用于创建更复杂、具备沙箱运行时、自定义工具和企业安全控制的 agents。两者是互补的:Workspace Studio 用于日常用户构建的自动化,Managed Agents 用于后台或安全敏感型工作流。
什么是 Agent Development Kit(ADK)?
Agent Development Kit 是 Google 面向专业代码的 SDK,用于在 Vertex AI Agent Engine 上构建完全自定义的 AI agents。与配置驱动的 Managed Agents API 相比,ADK agents 在定制编排逻辑方面提供了最大的灵活性,但开发工作量也更大。ADK 和 managed agents 都通过 Gemini Enterprise 进行治理。
Managed Agents API 是否支持 Gemini 以外的模型?
不支持。Managed Agents API 专为 Gemini 模型设计(包括 Gemini 3.5 Flash 和 Gemini 3.1 Pro)。希望将工作负载路由到其他前沿模型或开源模型的团队,需要在 Google 托管栈之外构建一个模型无关的编排层。
Gemini Enterprise 提供哪些治理控制?
Gemini Enterprise 提供一个集中控制台,管理员可以查看组织中的所有 agents(包括 Google 构建的、员工构建的、自定义的和第三方的)、管理访问策略、通过 Agent Gateway 执行 DLP 规则,并审计 agent 活动。managed agents 运行在带有可配置网络允许列表的沙箱环境中,限制 agent 可访问的外部服务。
Gemini Enterprise Agent Platform 与 Vertex AI Agent Platform 是同一个产品吗?
是的。Google 将 Vertex AI Agent Platform 更名为 Gemini Enterprise Agent Platform,作为其将 Gemini 定位为企业 AI 技术栈品牌的更广泛战略的一部分。底层基础设施和 API 保持不变;品牌调整反映了 Google 正在将其 AI 产品统一到 Gemini 这个总品牌之下。
Recent Posts

Claude Tag:Anthropic 面向 Slack 的全天候 AI 队友
了解 Claude Tag 是什么、@Claude 如何在 Slack 频道中工作,以及 Anthropic 的全天候 AI 队友如何支持团队协作与自动化。

Claude 香港教程:界面、提示词与粤语内容
面向香港用户的实用 Claude 教程:界面导览、粤语与繁体中文提示词模板、编码技巧,以及一个免费替代方案。

如何在香港使用 Claude:完整指南
香港 IP 无法访问 Claude.ai?本指南解释原因,并介绍 VPN 和手机号验证绕过方案、企业可用的 AWS 方案,以及一个免费替代方案。