Introducing Managed Agents in the Gemini API
Introducing Managed Agents in the Gemini API
原文链接：https://blog.google/innovation-and-ai/technology/developers-tools/managed-agents-gemini-api/ 补充原文：https://ai.google.dev/gemini-api/docs/antigravity-agent 补充原文：https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/managed-agents 来源：Google AI Blog / Google AI for Developers / Google Cloud 发布日期：2026-05-19
速查卡
| 项目 | 内容 |
|---|---|
| 一句话总结 | Google 把内部 agent harness 公开成 Gemini API 的托管运行时，开发者现在可以一键拉起带代码执行、文件操作、网页浏览和状态续接能力的云端 agent。 |
| 大白话版 | Google 不想只卖一个“会回答问题的模型”，它想直接卖一台“能在沙箱里干活的 agent 机器”。 |
| 核心要点 | • Antigravity 成为默认托管 agent • 单次 API 调用即可拉起远程 Linux 环境 • 用 AGENTS.md / SKILL.md 把指令、技能、数据版本化 • 对外接口挂在 Interactions API 与 Google AI Studio 上 |
| 价值评级 | A = 平台级更新，指向 agent runtime 标准化 |
| 适用场景 | 做 coding agent、research agent、browser + file workflow、企业内部自动化与多步任务编排的团队 |
文章背景
这篇文章不是一个普通 API feature announcement，而是 Google 在 I/O 2026 前夜把自己的 agent 战略讲透了一半。
原文最关键的一句是：
“The Gemini API now supports managed agents. Run the Antigravity agent in a secure cloud sandbox, build custom agents with your own instructions, skills and data and define them as versionable files using AGENTS.md and SKILL.md.”
这句话有三层信号：
- Google 已经不满足于只提供模型推理接口，而是开始提供托管 agent 的运行时；
- 它把 agent 的核心资产定义为 instructions、skills、data 和 sandbox，而不是单条 prompt；
- 它明确把
AGENTS.md、SKILL.md这种文件式配置抬到一等公民位置，说明 Google 认同“agent 应该像软件工程资产一样被版本化、审计和迁移”。
如果把这条更新和 OpenAI 最近强化 Agents SDK、Anthropic 围绕 MCP 与连接层继续收权放在一起看，会发现三大厂已经在同一条赛道上对齐：
- 模型层还在卷；
- 但更关键的新战场，已经变成谁能提供更稳的 agent runtime；
- 也就是谁来负责沙箱、会话、工具、状态、审计、权限和复用。
完整内容还原
1. Google 先定义了问题：生产级 agent 过去太难自己搭
原文写得很直白：过去要做 production-grade agent，开发者需要自己管理复杂基础设施、自己搭隔离沙箱、自己处理扩展前的脚手架。这其实就是过去一年所有 serious agent 团队都在补的那层底座：
- 隔离执行环境
- 工具调用编排
- 会话状态管理
- 文件系统与依赖管理
- 长任务的恢复与续跑
- 可审计、可回放的执行痕迹
Google 给出的产品答案是：把这层复杂度托管出去。
2. Antigravity 是默认 agent，不只是一个 demo
原文与文档都明确：
Antigravity是 Gemini API 上的 general-purpose managed agent；- 单次 API 调用就能拉起 agent；
- agent 在 Google 托管的 secure Linux sandbox 中运行；
- 底层由
Gemini 3.5 Flash驱动； - 通过
Interactions API与Google AI Studio提供。
文档里的关键表述是：
“A single API call gives you an agent that reasons, executes code, manages files, and browses the web inside your own secure Linux sandbox, hosted by Google.”
这句话值得逐词拆：
- reasons：不是固定 workflow，而是带推理循环；
- executes code：说明运行时包含代码执行面；
- manages files：说明文件系统是 agent 的内生工作记忆；
- browses the web：说明 Google 直接把网页访问纳入 agent action space；
- secure Linux sandbox：说明安全边界在 runtime 层，不只是 API 参数层。
3. Google 把“agent 定义”从代码逻辑下沉到文件资产
原文说，开发者可以“不写复杂 orchestration code”，而是用 AGENTS.md 和 SKILL.md 等 markdown 文件定义 agent。
这背后的设计判断很重要：
- instruction 不再只是 prompt 文本，而是 versionable artifact；
- skills 不再只是临时塞上下文，而是可挂接、可治理、可迁移的能力模块；
- agent 的行为边界可以被文件化、版本化、审查化。
这意味着 Google 的产品心智不是“让你多写一点 prompt”，而是“让你维护一个 agent repo”。
4. 文档补足了运行时细节：remote environment + tool gating
Google AI for Developers 文档把博客里一句话展开成了更完整的 runtime 语义：
environment="remote"时启用远程环境；- 文件系统能力会自动启用；
- 默认工具集中包含搜索/URL 相关能力；
- 工具集可以被限制，只暴露必要接口；
- context compaction 会在长会话中自动触发，支撑 multi-turn execution。
文档中甚至点名了这一层不是一次性推理，而是可长时间运行的 agent session：
- automatic context compaction
- multi-turn usage
- streaming
- supported tools
这说明它不是“把 code interpreter 改个名字”，而是在把 agent loop 产品化。
5. 企业版文档说明 Google 正把同一套范式往 Cloud 平台上抬
Cloud 文档给出的信号更偏企业控制面：
- 每个 agent 运行在 isolated sandbox environment；
- 默认情况下 agent 无法访问外部系统、网络或凭据；
- 任何越出沙箱的连接都需要开发者显式配置；
- 可以通过外部数据源挂载、network allowlists 等方式定制环境。
这一步很关键，因为它把 consumer/dev-preview 式 agent 拉进了企业治理框架：
- 安全默认拒绝；
- 访问是白名单化的；
- 外部系统接入不是 agent 自由漫游，而是开发者显式配置。
核心技术洞察
1. Google 公开卖的是“agent harness”
这次更新最不该被低估的点，是 Google 自己承认它在开放内部 harness。
原文写道：
“Now, we are opening up our agent harness and infrastructure so you can build your own custom managed agents.”
这和传统 SDK 发布完全不同。SDK 是帮你调 API；harness 是帮你组织 agent 的完整工作循环。两者不是一个量级。
2. AGENTS.md / SKILL.md 的意义，比 markdown 表面大得多
它们代表的是 agent 工程资产化：
- 可版本控制：变更有历史；
- 可迁移：agent 定义能跨环境移动；
- 可审计：企业可以 review 行为说明与技能；
- 可组合：不同技能可以形成 agent 能力栈；
- 可演化：未来可以把使用痕迹回灌为 skill 更新。
这本质上是在把 prompt engineering，升级为 runtime-aware agent engineering。
3. Google 试图把 agent 产品心智从“workflow”推到“runtime”
workflow 产品的核心是预定义流程；runtime 产品的核心是可在边界内自主演化执行。
Google 这次更靠后者。因为它强调的是：
- Linux sandbox
- 代码执行
- 文件系统
- web browsing
- session/state continuation
- versionable files
这是一整套通用执行底座，而不是某个行业模板。
实践指南
🟢 立即可用
-
把 agent 需求拆成四块：instruction、skills、data、environment
- 先别急着写复杂编排器；
- 先问自己哪些应该沉淀为
AGENTS.md，哪些应该沉淀为SKILL.md。
-
明确工具最小暴露集
- 能只给搜索就别给全工具；
- 能只给 sandbox 文件访问就别直接开外网与生产系统。
-
设计“可恢复任务”而不是“单轮 prompt”
- 既然平台提供 multi-turn 和 compaction，就应该把任务设计成可续跑的工作单元。
🟡 需要适配
-
企业内接真实系统时，先做 allowlist 与 mount 设计
- Google Cloud 文档已经给出默认拒绝边界；
- 不要把生产数据库/API 直接暴露给默认 agent。
-
把 skill 写成可验证 procedure
- 如果 skill 只是宽泛建议，它很难稳定复用；
- 最好写成带前置条件、步骤、验证方式的执行手册。
🔴 注意事项
-
文档仍是 rollout / preview 语境
- 这说明能力虽重，但生产 SLA、价格、限制仍可能快速变化。
-
“托管”不等于“更可控”
- 如果团队不主动设计权限、工具和数据边界，托管 agent 一样可能越权或误操作。
-
Google 公开了 runtime，但没有替你解决业务责任归属
- 哪些操作要审批；
- 哪些状态能持久化；
- 哪些外部连接能开放； 这些仍要团队自己定义。
横向对比
| 话题 | Google Managed Agents | OpenAI Agents SDK | Anthropic 当前路线 |
|---|---|---|---|
| 核心卖点 | 托管 agent runtime | SDK + runtime 框架 | 模型 + MCP + 连接层 |
| 执行环境 | Google 托管 secure Linux sandbox | 强调 sandbox / harness，可自定义 | 更偏协议与连接层能力 |
| 资产形式 | AGENTS.md / SKILL.md 文件化 | SDK/guide 驱动，代码式更强 | MCP server / tooling 更突出 |
| 平台方向 | 直接开放内部 harness | 给开发者 runtime 主导权 | 抢工具接入与平台连接层 |
批判性分析
局限性
- 目前公开信息仍偏 capability announcement，价格、配额、恢复语义的精确边界还不够透明；
- 博客里强调了
AGENTS.md/SKILL.md，但没有详细说明 skill 生命周期治理； - 对企业最关键的审计、审批、人类接管链路，公开材料仍讲得不够细。
适用边界
- 非常适合需要快速起一个 cloud agent runtime 的团队；
- 不一定适合对底层执行器、网络拓扑、内部合规要求极度定制的场景；
- 对已经自建完 agent platform 的团队，价值更多是基准对比，而不是直接迁移。
潜在风险
- 平台锁定：一旦 skill、session、sandbox 语义深度绑定 Google runtime，迁移成本会上升；
- 安全错觉：托管环境会让团队误以为默认安全，但真正风险在外部系统接入；
- 成本与可观测性：长会话、多步执行、网页浏览与文件操作如果缺乏细粒度 telemetry，排障会很痛苦。
独立观察
我最在意的不是 Google 又多了一个 agent API，而是它开始把“agent 是什么”定义成了一个标准化运行时单元：
- 有环境；
- 有状态；
- 有技能；
- 有文件；
- 有工具；
- 有可版本化的行为说明。
这说明 2026 年的大厂竞赛，已经从“谁模型更像人”转向“谁能把 agent 变成可托管的软件对象”。从这个角度看，Managed Agents 是今天最有战略重量的 Google 开发者更新之一。