Google把智能体装进可治理的运行环境：Gemini API 新增 hooks，但生产边界仍在沙箱之外 (2026)

先看结论

Google 在 7 月 28 日更新 Gemini API 的 Managed Agents：antigravity-preview-05-2026 默认使用 Gemini 3.6 Flash，并新增环境 hooks、预算控制、定时触发器和免费层项目支持。1

这次更新的重点不在于模型又换了一版，而在于 Google 把智能体的模型、执行环境、工具调用控制和后台任务放进了同一套 API。对开发团队来说，Managed Agents 开始接近一个可以直接接入业务流程的运行时；对企业治理来说，它仍然只是一个需要围绕权限、网络、审计和故障处理继续加固的沙箱。

更新了哪些能力

能力	官方已确认的变化	读者需要留意的边界
默认模型	Managed Agents 默认切换到 Gemini 3.6 Flash；Google 的模型文档将 `gemini-3.6-flash` 列为 Stable，并称其面向 agentic 和多模态任务平衡速度与智能。1 2	这是默认模型切换，不等于每个业务场景都已经完成效果或成本验证。
环境 hooks	`pre_tool_execution` 可以在工具执行前允许或拒绝调用，`post_tool_execution` 可做格式化、测试和审计。3	hooks 只覆盖沙箱内置的代码执行和文件操作，不覆盖自定义 function 或外部 MCP；post hook 也不能撤销已经完成的动作。
Managed sandbox	单次 API 调用可以创建 Linux 沙箱，让 agent 执行代码、管理文件和浏览网页；同一个环境可跨交互保留文件和已安装软件。4 5	文档列出的环境配额是 4 个 CPU 核心和 16 GB 内存，环境连续闲置 7 天后会被删除，当前仍处于 preview。
后台执行	`background=true` 可让长任务在服务端异步运行，客户端拿到 interaction ID 后轮询状态、接收流式进度或断线重连。6	前一个 interaction 仍在执行时，不能直接链式发起下一个；Managed Agents 链接交互还需要同时提供环境信息。

Google 正在卖的不是一个模型接口

传统模型 API 的基本动作是发送输入、等待输出。Managed Agents 把动作扩展成了一个有状态的执行过程：agent 可以在沙箱里写文件、运行代码、读取网络内容，再把多步结果串起来。Google 将这套能力称为 configurable agent harness，也就是开发者可以配置的 agent 运行框架。4

这会改变开发工作量的分布。团队不必从零搭建任务队列、远程执行环境和部分文件状态管理，但需要开始处理更像基础设施的问题：哪些工具可以调用，哪些文件可以读写，网络允许访问哪些域名，长任务如何恢复，失败后谁来负责重试或人工接管。

Google 的环境文档显示，沙箱默认允许不受限制的出站网络，也可以改成域名白名单或完全关闭网络。这个设置很实用，却也决定了 Managed Agents 能不能直接进入企业内部流程。一个会浏览网页的研究 agent 和一个能读写客户资料的业务 agent，所需要的网络边界完全不同。5

Hooks 有用，但不是完整的安全层

hooks 是这次更新里最值得单独看的部分。一个 pre_tool_execution 脚本可以检查即将执行的工具调用，返回 deny 后阻止动作；post_tool_execution 则适合记录遥测、运行测试或对生成文件做后处理。开发者可以通过 .agents/hooks.json 配置命令或 HTTP 处理器，并用正则匹配一组工具。3

这让「模型自己决定怎么做」和「系统允许它做什么」之间多了一层可编程检查。比如，团队可以拦截高风险的文件删除、限制代码执行，或者把每次工具调用写入审计系统。对于需要把 agent 接入真实工作流的开发者，这比单纯增加一个模型选项更接近生产需求。

但 hooks 的覆盖范围需要原样保留。它只能拦截沙箱里的 code_execution、read_file、write_file 等内置工具，不能拦截自定义 function calling 或外部 MCP。更关键的是，官方文档说明，脚本崩溃、超时、HTTP 请求失败或输出无法识别时，运行时会把 pre hook 当作允许执行处理；post hook 的结果则不会阻止主流程。3

所以，hooks 更像执行层的安全闸门和审计接口，不是覆盖所有外部动作的统一权限系统。只要业务 agent 还要调用企业 API、支付系统、CRM 或第三方 MCP，关键权限仍需要放在这些系统自己的鉴权和审批层里。

后台执行让 agent 进入业务流程，但也带来状态问题

Google 的后台执行文档把 Managed Agents 放进了一个更具体的业务场景：深度研究、复杂推理和多步骤执行可能超过普通 HTTP 请求的约 60 秒限制，因此 API 允许任务在服务端继续运行。客户端拿到 interaction ID 后，可以查询 in_progress、requires_action、completed、failed 和 cancelled 等状态。6

这类机制适合研究报告、代码生成、文件处理和需要人工确认的流程。它也意味着应用不能只保存一次请求和一次回复，而要保存任务状态、工具调用记录、重连位置和取消逻辑。Interactions API 文档还说明，服务端会保存 interaction 以支持 previous_interaction_id、后台执行和可观测性；paid tier 默认保留 55 天，free tier 默认保留 1 天。7

对于企业使用者，这里有一个容易被忽略的选择：状态保留越方便，数据治理责任越重。关闭存储会失去跨交互延续和后台执行能力，保留状态则要回答数据保存多久、谁可以读取、如何删除，以及这些 interaction 是否包含敏感信息。

对行业竞争的三个观察点

第一，agent 平台的竞争正在从「谁的模型回答更好」扩展到「谁能把执行过程管住」。默认模型只是入口，环境复用、后台任务、工具权限和审计接口决定了一个 agent 能否进入真实业务。Google 这次把它们同时更新，说明产品竞争已经开始围绕运行时展开。这个判断是基于能力组合的推断，不代表 Google 已经披露了企业部署规模或客户效果。

第二，沙箱资源和生命周期会成为选型参数。4 核 CPU、16 GB 内存、闲置 7 天删除等限制，对轻量研究和代码任务可能够用，对长时间运行的数据处理、重型构建或持续在线服务则未必合适。官方文档也提醒环境仍处于 preview，功能和 schema 可能变化。5

第三，治理边界不能只看平台宣传中的「secure sandbox」。实际评估时应逐项核对：网络默认是否开放、外部工具是否绕过 hooks、hook 失败时是 fail-open 还是 fail-closed、interaction 保存多久、任务能否被取消，以及人工确认发生在哪个环节。Google 当前公开文档已经给出了这些配置点，但没有替企业完成权限设计。

接下来观察什么

后续判断 Managed Agents 是否真的从开发者预览走向生产平台，可以看四个具体信号：

hooks 是否扩展到自定义 function 和外部 MCP，而不是只覆盖沙箱内置工具。
环境资源、冷启动、闲置删除和长期任务限制是否有更明确的正式版承诺。
Google 是否披露可验证的客户部署、任务成功率、成本或故障恢复数据。
企业能否把网络白名单、凭据注入、interaction 保留和人工审批接进现有的安全体系。

Google 这次更新已经把 agent 的「思考」和「执行」放在同一产品里，但生产系统真正关心的，是每一次执行能否被授权、记录、暂停和追责。现在能确认的是运行时能力已经补齐了一部分；能否承担关键业务，还要看沙箱之外的权限系统和实际部署数据。

References

1
Gemini API Managed Agents 更新说明blog.google
2
Gemini API 模型文档ai.google.dev
3
Hooks 文档ai.google.dev
4
Managed Agents 总览ai.google.dev
5
Managed Agents 环境文档ai.google.dev
6
后台执行文档ai.google.dev
7
Interactions API 文档ai.google.dev