Google Gemini 托管代理在自主性与控制之间设置钩子

Google Gemini 于 7 月 28 日更新其托管代理技术栈，新增 3.6 Flash、执行钩子、令牌预算、定时触发器和免费层级访问。单看这些功能都只是渐进式改进，但结合起来，它们让 Google 的托管沙盒更像一个能够承载周期性工具调用工作的可靠场所。

如今的竞争不再只是 Google Gemini 与其他模型之间的较量，而是托管基础设施与开发者自主控制的编排体系之间的竞争。Google 希望团队通过一个 API 交出代理循环、远程环境、任务状态、调度以及多项运营控制权。

这一承诺给那些维护自有 worker、队列、容器和策略层的团队带来压力，也引出了一个更棘手的问题：当自主代理能够执行代码、修改文件、安装软件包并访问网络时，便捷的托管运行时能否提供足够的控制力？

Google 的回答聚焦于钩子。这些脚本或 HTTP 处理程序可以在沙盒内工具运行前后立即检查活动。它们在无需开发者重建整个代理运行时的前提下，增加了策略与验证节点。

不过，这个答案仍不完整。一些钩子会在失败时放行，其覆盖范围存在明确边界，公共预览软件也需要谨慎评估。Google 让托管代理更易于运营，但并未使其自动变得值得信任。

Google Gemini 将 3.6 Flash 设为托管代理默认模型

重要变化并非又一次模型发布，而是 Google 升级了让模型执行长时任务的外围系统。

antigravity-preview-05-2026 代理现默认使用 Gemini 3.6 Flash。Google 的托管代理更新称，现有调用无需修改代码即可使用该模型。

开发者也可以通过 agent_config.model 选择模型。文档列出的选项包括 Gemini 3.6 Flash、Gemini 3.5 Flash 和 Gemini 3.5 Flash-Lite。Google 将最后一项定位为优先追求更低延迟和更低消耗的工作负载。

这一默认设置很重要，因为托管代理不只是模型端点。Google 将其描述为运行在隔离 Linux 环境中的可配置代理框架。一次交互可以协调推理、代码执行、文件操作、软件包安装和网页检索。

这种组合改变了风险状况。传统模型响应可以在程序据此行动前接受审查；而代理可能在生成响应的过程中就已经造成后果。

模型可能检查代码仓库、编辑依赖项、运行测试，并在多个步骤中调整方法。当环境允许时，它也可以使用网络访问或已连接的工具。每种能力都会增加一个运营者必须观察和约束的面向。

因此，Google 的 3.6 Flash 默认设置会影响整个循环。不同模型可能改变工具选择、推理时长、错误恢复和令牌消耗，也可能改变代理遵循运营约束的可靠性。

模型选择给开发者提供了有限的退出机制。团队可以固定偏好的模型，而不是接受最新默认值。具名托管代理会保留其配置的模型，而内联交互则可为每个请求指定模型。

这一差异对生产团队应当很重要。静默默认升级在试验期间很方便，但部署期间可预测的行为更重要。评估需要覆盖生产中使用的确切模型、工具、环境、指令和钩子配置。

Google 还向免费层级项目开放了托管代理。开发者可以使用未启用活跃计费的项目测试代理式工作流。该公司并未取消计量或使用限制，但降低了初步试验的门槛。

更广泛的代理概览仍将托管代理标记为公共预览，并建议在敏感工作流中使用代理前审查其操作和输出。

这一警告提供了正确的判断框架。7 月的发布让平台更易获取、运营功能也更完整，但它并未将自主编码环境变成成熟的企业控制平面。

该产品如今覆盖了代理生命周期的更多环节。Google 配置沙盒、运行循环、存储交互状态、公开执行步骤并支持后台工作。开发者可以添加指令、文件、技能、自定义函数和远程 MCP 服务器。

MCP，即 Model Context Protocol，是连接代理与外部工具和数据的标准。远程 MCP 支持扩展了代理在沙盒之外能够访问的范围，也扩大了团队必须审查的权限范围。

结果是一种捆绑式架构。开发者无需自行组装模型、工具路由器、容器服务、调度器、状态存储和回调系统，而可以从 Google 的托管组件开始。

这正是本文讨论的张力所在。捆绑减少了基础设施工作，却也将重要行为迁入托管系统。钩子是 Google 试图在这种权衡中保留开发者控制权的方式。

钩子将策略置于代理循环内部

环境钩子为开发者提供了一层拦截机制，位于自主工作实际发生的位置，并紧贴工具执行前后。

钩子是绑定到生命周期事件的自定义命令或 HTTP 请求。Google Gemini 支持在其远程沙盒内于工具执行前和工具执行后触发事件。

预执行钩子可以批准或拒绝工具调用。如果它拒绝请求，运行时会跳过该工具并将原因返回给模型。模型随后可以选择另一种方法，或解释为何无法继续。

后执行钩子在工具完成后运行。它无法撤销已完成的操作，但可以格式化文件、运行测试、验证生成的资产，或将审计信息发送到其他位置。

开发者在 .agents/hooks.json 中定义这些控制项。匹配器针对特定容器工具或工具组。一项策略可以检查每次代码执行、每次文件写入或所有文件系统操作。

钩子文档将代码执行和内置文件操作列入支持范围。这些操作包括读取、写入、列出和删除文件。

这种结构创建了多个实用控制点。预执行脚本可以拒绝破坏性 shell 命令，另一个脚本可以阻止访问受限路径，或检查拟议的文件变更是否违反项目策略。

执行后，钩子可以运行 linter、扫描生成的代码、启动测试或记录遥测数据。HTTP 处理程序可以将事件数据发送至已列入允许名单的外部服务，以供集中审查。

Google 的设计将命令钩子保留在沙盒内。脚本通过标准输入接收事件数据，并通过标准输出返回结构化决策。HTTP 钩子则将类似的事件数据发送到外部 HTTPS 端点。

这种安排减少了代理外部的编排代码。运行时会发现钩子配置、调用匹配的处理程序、等待其响应，并将拒绝结果返回到模型上下文中。

它还支持有序处理程序。团队可以对同一工具调用应用多项检查，例如路径验证、命令分析和审批日志记录。多个匹配组可以针对同一事件运行。

这比最终输出过滤器更有用。最终检查可以发现一份糟糕的报告，却无法可靠地撤销已删除的文件或泄露的凭据。工具调用前的关卡可以在执行前阻止相应操作。

在软件维护任务中，这种差异更加清晰。代理可能审计依赖项、修改软件包文件、安装更新并运行测试套件。每个步骤都有不同的运营风险。

团队可以自动允许读取操作，同时审查写入和 shell 命令；也可以拒绝在已批准目录之外进行编辑。每当代理修改代码时，后执行钩子都可以运行格式化和测试。

Google 将专注于 AI 的投资银行 OffDeal 作为早期用户重点介绍。其内部代理会准备演示材料，其中一份演示文稿可能包含超过 30 个公司 logo。

OffDeal 的创始人兼首席技术官表示，在代理创建公司列表后，后执行钩子会运行图像验证流水线。该流水线会在获批文件进入演示文稿前检查候选 logo。

这个例子说明了钩子能够创造价值的场景。模型处理开放式的研究和制作任务，而确定性软件则对产出的资产应用可衡量的要求。

这种方法也适用于文档密集型工作流。代理可以收集更新、创建报告并将文件放入持久化环境。验证钩子可以检查必需章节、文件名或来源清单。

知识工作者已在将生成材料与私有上下文结合，因此来源追踪变得重要。可搜索的AI 知识库可以组织这些上下文，而钩子则治理代理运行时内的操作。

这些层解决的是不同问题。知识组织帮助用户检索和理解信息；执行控制则决定自主 worker 能够如何使用工具和文件。

钩子还通过 HTTP 处理程序支持外部审计流水线。流量经过沙盒网络，必须遵守环境的允许名单。Google 支持基于代理的凭据注入，因此密钥不必存放在钩子文件中。

这种设计减少了容器内凭据的直接暴露，但并未消除精心设计权限的必要性。代理可以使用其环境或连接服务提供的任何权限。

最安全的方法仍是最小权限原则。报告代理可能需要对代码仓库的读取权限，以及写入某一个输出目录的许可。它很少需要广泛的管理凭据。

钩子让此类策略更容易在执行附近表达。它们不能取代身份控制、网络限制、环境隔离或审查关卡，而只是更大系统中的一层。

托管运行时与开发者自有编排体系之争

Google 竞争的对象不仅是其他模型提供商，也包括基础设施团队围绕模型自行构建的体系。

新功能包包含多项通常位于模型 API 之外的能力。托管代理提供远程环境、多步骤执行、持久状态、令牌控制、定时安排和环境管理。

Google 的 Interactions API 将这些部分连接起来。该接口支持常规模型调用和专用代理，包括托管代理与 Deep Research，也支持后台执行和持续交互。

文档显示，Interactions API于 2026 年 6 月正式发布。Google 建议新项目使用它，同时继续支持较旧的 generateContent 接口。

服务端对话状态使调用方能够使用先前的交互标识符继续工作。当任务暂停、达到预算上限或需要另一条指令时，这一点尤为重要。

Google 新增的 max_total_tokens 设置为自主运行增加了总消耗上限。该限制涵盖任务循环中的输入、输出和思考 token。

当智能体达到这一上限时，执行会以未完成状态暂停。环境状态仍会保留。开发者可以使用新的预算从先前的交互继续执行。

这一机制解决了自主智能体的一个基本问题。调用方通常无法预测一项任务需要多少轮推理和工具调用。看似简单的审计可能会扩展到文件、依赖项、错误和重试。

硬性预算将不可预知的过程转化为有边界的过程。它并不能保证智能体高效使用 token，但能在长期循环消耗更多资源之前，为运营人员提供停止条件。

定时触发器则将同一个智能体从按需助手扩展为周期性工作者。一个触发器会将智能体、环境、提示词和 cron 计划绑定为持久资源。

Cron 是一种常见的周期性任务调度语法。Google 的 Triggers API 通过 beta 端点提供这些计划，并会在运行失败后记录连续失败次数。

每次定时运行都可以复用同一个沙箱。因此，文件能够在多次执行之间保留，使智能体可以在定时任务之间维护工作产物。

这种持久性支持实用型任务。智能体可以每天早晨检查代码仓库、更新迁移报告，或审阅新进入的研究文件。若缺乏清理策略，它也可能累积过期或敏感材料。

Google 新增了 Environments API，以解决这一生命周期中的部分问题。开发者可以列出、检查和删除沙箱会话。他们可以在断开连接后恢复环境标识符，或直接移除已完成的环境。

否则，非活跃环境的文档化生命周期为七天。自动删除能够限制无限期持久化，但无法替代针对敏感工作流的审慎保留规则。

这些功能共同减少了周期性智能体工作所需的外部基础设施。一支小团队可能不再需要自行构建容器启动器、任务调度器、状态存储和 token 监控机制。

这正是托管运行时的价值主张。Google 负责运行执行层，开发者则提供任务、工具、权限、数据和控制措施。

开发者自有编排提供了相反的取舍。团队可以自行选择模型、运行时、策略引擎、队列、存储和可观测性系统，但也要承担每一次集成失败和运营负担。

没有任何一种路径适合所有工作负载。受监管流程可能需要超出公开预览服务能力范围的控制措施。原型或边界明确的内部任务，则可能会从单一托管接口中大幅受益。

Google 自身的 Vertex AI 产品组合体现了这种分层。Agent Engine 提供用于部署和扩展智能体的托管运行时，并提供会话、记忆、评估及相关操作服务。

Gemini API 托管智能体围绕 Antigravity agent 和 Interactions API 提供了更直接的开发者路径。Vertex AI 则面向更广泛的生产部署和企业基础设施需求。

这种重叠可能让购买方感到困惑。团队必须决定，他们需要的是现成的智能体框架、通用的智能体部署平台，还是自定义编排栈。

7 月的更新强化了第一种选择。Google Gemini 现在已提供足够的内置生命周期支持，使开发者能够测试托管编排是否可以替代其现有技术栈的部分组件。

竞争对手也在同一架构层面承受压力。模型质量仍然重要，但智能体构建者越来越多地比较执行环境、工具控制、调度、追踪、状态和故障处理能力。

模型基准测试无法决定这种比较。团队将根据智能体能否可预测地完成真实任务、遵守策略，以及是否留下足够证据让运营人员理解其行为来进行判断。

Google 的优势在于集成。其模型、智能体框架、沙箱、搜索访问、API 接口和云服务能够共享一条产品路径。

这种集成也是一种依赖。采用完整技术栈的团队会更加依赖 Google 的智能体语义、环境行为、配额、预览阶段变更和模型可用性。

模型选择可以降低其中一部分依赖，但无法消除全部依赖。周边框架仍属于 Google。钩子、触发器、交互状态和环境管理均使用平台特定接口。

因此，真正的竞争考验是运营可移植性。开发者需要了解：如果需求发生变化，他们能够多容易地在其他地方复现策略、评估和任务状态。

Google Gemini Hooks 仍存在重要缺口

Hooks 提升了控制能力，但其故障行为和覆盖范围意味着它们无法充当绝对的安全边界。

最重要的限制出现在 Google 自身的文档中。如果命令 hook 崩溃、超时、返回无效输出，或遇到某些错误，运行时会允许该工具调用继续执行。

这种故障开放行为可防止失效的策略脚本让智能体陷入死锁。但这也意味着，失效的安全关卡可能会放行原本应阻止的操作。

这种取舍适用于格式化或遥测 hook。失败的 linter 未必应当冻结所有工作流。但当 hook 用于保护破坏性命令、受限数据或受监管操作时，这就更难接受。

团队必须按后果对 hooks 进行分类。便利性检查可以故障开放。关键授权决策还应依赖 hook 之外的控制措施，例如受限凭证和只读资源。

Hook 覆盖范围也存在另一条边界。Google 表示，环境 hooks 会拦截在沙箱内运行的内置工具。它们不会针对容器外处理的自定义函数调用或远程 MCP 工具触发。

这一区别很重要，因为外部工具可能带来严重后果。自定义函数可能更新客户记录、发送消息或启动部署。沙箱 hook 不会自动约束此类调用。

开发者需要在每一个外部工具边界部署独立的授权与验证机制。接收服务应验证调用方身份、校验参数、执行权限控制并记录操作日志。

执行后的 hooks 也无法撤销已完成的工作。它们可以发现异常文件或验证失败，但原始工具操作已经发生。撤销需要应用程序特定的恢复机制。

配置完整性同样值得重视。Hook 文件和脚本可以位于可写环境中。拥有足够文件系统或代码执行访问权限的智能体，可能会修改这些控制措施。

Google 建议在需要严格防篡改时使用只读代码仓库源。对于敏感部署，这项建议应被视为基础要求。

网络访问创造了另一个开放边缘。根据智能体文档，托管智能体环境默认拥有不受限制的出站访问。开发者可以应用允许列表或禁用访问。

默认开放网络简化了研究和软件包安装，但也增加了接触不可信内容、意外下载以及数据离开环境的风险。

Hooks 可以检查部分操作，但网络策略不应依赖模型行为。对于只需访问特定服务的智能体，显式允许列表提供了更清晰的边界。

提示词注入同样仍然相关。检索网页或代码仓库内容的智能体，可能会遇到意在重定向其行为的文本。工具权限决定了这种重定向可能造成多大危害。

没有任何模型默认设置能够消除这一问题。Gemini 3.6 Flash 或许能改进推理和工具使用，但运营人员仍需要受限权限、可信来源，以及对重要输出的验证。

持久化沙箱在带来益处的同时，也增加了运营风险。在定时运行之间复用文件可以支持连续性，也可能将损坏状态、过时指令或被污染内容带入后续执行。

因此，定时任务需要可复现性检查。团队应了解每次运行由哪个模型、智能体定义、环境来源、hook 版本和提示词产生。

触发器同样需要故障管理。连续失败计数器很有帮助，但仍需有人定义告警阈值和修复措施。没有责任归属的周期性自主运行，会变成周期性的静默失败。

Token 预算也存在类似限制。最大值可以防止无边界消耗，但无法保证有效完成。智能体可能会将全部额度花在无效路径上。

运营人员需要 token 使用量之外的任务级指标。完成率、验证成功率、重试次数、人工修正和回滚频率，更能说明智能体是否提供了可靠价值。

公开预览状态带来了产品不确定性。接口、限制、支持的工具或行为都可能在正式可用前发生变化。生产采用者应隔离平台特定代码，并在可能的情况下固定配置。

缺乏独立性能数据是另一个缺口。Google 将 Gemini 3.6 Flash 描述为在推理、编码和工具使用方面较为均衡。该公告并未提供托管智能体工作流的对比任务结果。

开发者不应仅凭模型名称推断生产可靠性。他们需要基于自身的代码仓库、数据、权限和故障案例进行评估。

有效的测试集应同时包含常规任务和对抗性任务。它应衡量智能体如何应对模糊指令、工具失败、恶意内容、不可用依赖项和被拒绝的操作。

团队还应测试 hooks 本身。适用于一种命令格式的策略，可能会遗漏以不同方式表达的等价操作。正则匹配器识别的是工具名称，而非每一种语义后果。

最强的部署模式使用重叠控制措施。限制凭证、限制网络、保护配置来源、验证工具参数、检查输出，并对高影响操作要求人工批准。

Google Gemini hooks 很适合纳入这种分层模型。只有当团队将单一拦截点误认为完整治理时，它们才会变得危险。

三个信号将显示托管智能体是否已准备就绪

下一项考验是在真实约束下的采用情况，而不是 Google 为预览版增加了多少功能。

第一个信号是 hooks 能否经受生产环境故障模式的考验。开发者应关注已文档化的可靠性指标、更丰富的强制执行选项，以及对关键 hook 故障更清晰的处理方式。

针对选定策略提供故障关闭模式，将强化 Google 的控制能力叙事。它能让运营人员在强制关卡崩溃或不可访问时停止执行。

更细粒度的覆盖范围同样重要。当前 hooks 聚焦于内置沙箱工具。若能将策略集成扩展至外部函数和 MCP 调用，将减少碎片化的授权逻辑。

如果 Google 提供这些控制措施，托管编排的价值主张将更具说服力。如果高后果操作仍需要无关的策略系统，开发者就会把更多基础设施保留在运行时之外。

第二个信号是预览和 beta 组件迈向稳定服务承诺的路径。托管智能体仍处于公开预览阶段，而 Triggers API 使用 beta 端点。

团队应关注正式可用、版本承诺、区域覆盖、配额、支持策略和迁移指导。这些细节决定了一个成功原型能否成为可维护的产品。

稳定性将增强 Google 关于其 API 可承载周期性工作器的主张。频繁的行为变化或模糊的服务边界，则会促使关键工作负载采用由开发者自主掌控的编排方式。

第三个信号是可衡量的用户采用情况。最有价值的证据将来自可重复执行的工作负载：它们以更少的人工干预和更少的自定义基础设施组件完成任务。

OffDeal 的徽标验证流水线提供了一个具体案例。更多案例应披露代理执行了什么操作、适用哪些控制措施、如何处理失败，以及仍需保留多少人工审核。

团队不应只看精心打磨的演示。只有当一个周期性代理能够应对不完整数据、被拒绝的操作、网络故障、模型变更和中断的运行时，它才真正具有价值。

同样的测试也适用于内部场景。先从一个输出可验证的边界明确工作流开始。仅授予代理完成任务所需的最低权限，并记录每一次工具操作。

设置 token 上限并限制网络访问。将强制性策略文件置于受保护的来源中。在启用定时调度前，使用固定评估案例反复运行该工作流。

随后衡量完成质量、策略拒绝、重试、人工修正和环境清理情况。将这些结果与现有的人工流程或编排流程进行比较。

Google Gemini 现在提供了一条可信的路径，用于测试这种托管式方案。Gemini 3.6 Flash 提供默认的推理引擎，而 hooks、预算、触发器和持久化环境则覆盖了更多运营层面的需求。

此次发布并未终结托管式编排与开发者自主编排之间的竞争，但让这种竞争具备了实践条件。团队如今可以比较实际运行的系统，而不再只是讨论抽象的代理框架。

对开发者而言，眼下的问题很具体：如今哪项边界明确的任务消耗了过多编排工作？选择一项操作可逆、输出可观察且成功标准清晰的任务。

对企业采购方而言，问题在于控制：托管运行时能否满足既有的身份、网络、审计、保留和审批要求？功能清单无法替代这项审查。

对知识工作者而言，问题在于信任：代理能否展示它改了什么、为何改动，以及通过了哪些验证？没有这些证据的自主性只会增加审核工作。

Google 后续发布将揭示 hooks 会成为可靠的策略层，还是仅仅停留在运营便利功能。到那之前，托管代理应仅用于具备分层控制措施、可衡量的试点项目。

选择一个周期性工作流，明确其允许执行的操作，并在将其纳入调度前测试每一条失败路径。这种纪律将证明 Google Gemini 是真正消除了基础设施，还是仅仅将其迁移到了别处。