从 Google Gemini Agent 看企业 Agent 的权限边界

让助手总结一份项目进展，和让同一个助手读取项目历史、创建表格、编写代码、安排后续任务，再调用多个临时子 Agent 完成其中一部分，是不同程度的委派。

Google 新发布的 Gemini agent 把这些能力放进一个持久化的工作 Agent。按照 Google 的介绍，它能够回答问题、运行代码、调用企业工具、持续执行数小时甚至数天，并出现在 Workspace、Microsoft 365、Slack、命令行、桌面应用和无界面集成中。Google Gemini agent 发布说明

这样的产品很有吸引力：用户可以直接交代结果，不必在多个助手之间反复补充背景。与此同时，身份、上下文、记忆和执行权限也集中到了同一个系统里。

本文依据截至 2026 年 10 月 8 日可读取的 Google 公开资料写成，没有进行产品实测、租户配置审查或漏洞复现。具体行为可能随产品版本、管理员策略、连接器、使用入口和后续文档而变化。

多个入口，共享同一个信任边界

Gemini agent 被描述为一个能够跨网页、移动端、桌面系统、命令行、Workspace、Microsoft 365、Slack 和第三方应用工作的统一 Agent。用户的上下文与个性化信息也会在这些入口之间保持连续。

连续体验减少了重复说明，却也连接了原本采用不同治理方式的环境。内部 Workspace 文档中的对话、Slack 里的请求，以及外部应用触发的无界面任务，并不天然拥有同等的数据访问和执行权限。

因此，问题不只是每个连接器有没有正确登录，还包括任务从一个入口转到另一个入口时，发起位置、受众和策略上下文是否仍然清楚。身份真实，并不意味着每个请求都同样可信。

持久记忆改变了“断开连接”的含义

Google 介绍了四类记忆：服务当前任务的会话记忆，从文档和互动中形成的语义记忆，记录工作方法的程序性记忆，以及保存历史活动的情景记忆。Agent 也可以在用户关闭设备后继续工作。

这些能力之所以有价值，正是因为系统不会每次都从零开始。但权限撤销也因此不再等同于结束一次对话。连接器被移除或文档权限发生变化时，需要关注的不只是后续读取是否失败；此前的信息可能已经影响某个项目、生成的技能、正在运行的任务或已被委派的子 Agent。

这并不是 Gemini 已存在缺陷的证据，而是所有“长期任务 + 学习型上下文”系统都要面对的生命周期问题：哪些派生状态仍会保留，哪些排队任务会停止，权限变化多久才能覆盖任务的每个副本？

子 Agent 有独立身份，不代表委派判断一定正确

Gemini 可以动态创建面向特定任务的临时子 Agent。Google 还介绍了拥有企业邮箱、存储空间和组织身份的长期 Coworker agent。独立身份比 Agent 默默冒用个人身份更清晰：日志能够指出谁执行了动作，权限也能绑定到具体 Agent。

不过，身份只能改善归属，不能判断一次委派是否合理。父 Agent 可能把一个目标拆成许多任务，把上下文交给子 Agent，或让更多系统参与进来。风险取决于具体委派了什么、授权持续多久，以及父 Agent 能否扩展本不该由它继续传递的权限。

真正有用的审计记录，不只写着“Agent B 发送了消息”，还应把 Agent B 与父任务、接收的上下文、当时生效的策略，以及负责这次委派的人或团队联系起来。

工具、技能与 MCP 把配置变成供应链问题

Google 表示，Gemini agent 可以使用企业工具注册表、共享及个人技能、常见业务系统、数据库、桌面文件、Git、Jira，以及公司网络内外的 MCP 服务。技能可以包含指令和工作流，系统也能从过去的工作中形成程序性知识。

这种灵活性让工具目录本身成为生产信任边界的一部分。一个连接器即使通过正确身份认证，也可能暴露范围过大的操作；一项技能创建时安全，之后却可能因下游 API 或业务流程变化而失效；外部 MCP 服务则增加了新的实现方、运营方和更新路径。

集中注册表让发现与管理更方便，但“已经登记”不等于“已经验证”。来源、版本变化、所需权限、数据去向和撤销行为，共同决定一个工具进入目录后能否继续被安全使用。

Agent Gateway 与 Sandbox 是重要的架构声明

Google 描述了独立 Agent 身份、由安全管理员批准的细粒度角色权限、基于 OAuth 的身份传递，以及归属于 Agent 的审计记录。Google 还表示，任务在具有网络边界的 Agent Sandbox 中执行，Agent 之间及其与外部系统之间的流量会经过 Agent Gateway；Agent Platform 更新则提到 Model Armor 对提示注入、工具投毒和数据泄露的防护。Google 治理架构说明 · Agent Platform 更新

这些控制覆盖了正确的层次：身份、授权、执行隔离、网络策略和流量检查。实际效果仍取决于配置和覆盖范围。网关只能执行已经定义的策略，沙箱也无法判断某项获准的业务操作是否合理。

例如，发邮件可能属于允许的动作，但把邮件发给不可信文档临时引入的收件人，未必仍在授权范围内。真正困难的控制往往绑定在动作细节上，例如收件人、目标位置、金额、仓库或数据分类，而不只是工具名称。

费用上限无法覆盖所有爆炸半径

Google 表示，项目级费用上限可以在 Token 与沙箱成本达到阈值时暂停 Agent。对于持久化任务和多 Agent 协作，这是一个具体的运维边界。

费用只是爆炸半径的一个维度。一个成本很低的动作，也可能发送敏感信息、覆盖记录、合并错误变更，或者一次联系大量对象。长时间运行的 Agent 还涉及动作次数、持续时间、并发扩散、目标范围和重复外部副作用。

一个项目完全可能在预算范围内造成严重业务错误。费用限制与动作限制回答的是两个不同的问题，成熟部署需要同时看见它们。

模型路由让 Agent 不再等于某个固定模型

Google 把 Gemini agent 与每项任务实际使用的模型分开。平台可以在 Gemini 模型和 Anthropic Claude 模型之间路由，未来还计划支持更多模型；用户的上下文、工具和技能则继续保留在 Agent 层。

这有利于兼顾任务效果与成本，但也意味着产品名称不再对应一种固定的推理行为。同一个项目中的两个任务可能由不同模型处理，路由策略也可能随时间变化。一次回归既可能来自模型，也可能来自路由策略、技能、连接器或编排层。

Google Agent Platform 提供共用评估引擎和执行追踪。若这些记录要支持事故复盘，就需要保留每一步使用的模型与策略版本，而不能只记录最终的 Agent 名称。

被拦截的动作也是审计证据

Google 表示，每项操作都会写入审计记录并归属于 Agent 身份。这能帮助事故调查回答一个重要问题：究竟是哪一个非人类主体接触了系统？

更完整的还原还包括尝试过但未成功的动作、网关拒绝、审批变化、子 Agent 创建、工具参数，以及影响动作的上下文。成功调用说明发生了什么，被拦截和中止的调用则经常揭示差一点发生什么。

记录如何保留和导出同样重要。如果调查所需证据只存在于被审查的同一个管理边界里，组织在严重事故中可能难以及时保全它。

采用决策的核心是权限，而不只是智能

Gemini agent 的公开架构对身份、沙箱、集中策略、可观测性和费用控制给出了较明确的说明。这比把 Agent 当作“聊天界面加一组 API 密钥”更接近企业系统应有的起点。

尚未回答的问题都与具体部署有关：权限变化如何传递到活动任务和记忆，破坏性操作审批如何绑定到准确动作，子 Agent 委派如何限制，外部 MCP 工具如何治理，以及重试如何避免重复副作用。公开架构资料能够帮助团队找到问题，真正的答案仍要来自租户配置和执行记录。

最终的产品判断，不只是一个通用 Agent 是否足够聪明、能否完成更多工作，而是同一份权限应该在多少设备、应用、模型、记忆和委派 Agent 之间保持连续，以及情况变化后，这些权限是否仍然能够被收窄、观察和撤销。

延伸阅读：生产级 AI Agent 护栏架构、生产就绪度检查清单，以及适用于客户自有工具适配层的 Agent Production Starter。