Gemini 企业通用 Agent：统一体验的背后必须是分层身份与策略控制面
2026 年 10 月 8 日，Google Cloud 在 Gemini at Work 2026 中提出面向工作的统一 Agent：它可在 Gmail、Drive、Docs、Slides、Sheets、Chat 和 Calendar 中以内联方式出现，共享记忆、技能与控制，并扩展到数据分析和行业场景。平台侧强调身份、策略、授权、沙箱、网络网关、多模型路由和支出上限。
“一个 Agent 到处工作”对用户很自然，但对平台是一个高难度命题。邮件、文件、数据仓库和日历拥有完全不同的权限与数据语义；统一体验不能被实现为一个拥有所有权限的超级服务账号。
统一的是任务上下文和交互入口，不应统一成一份无限权限凭证。
身份必须随每个动作传播
用户在 Docs 中要求“总结并发给项目组”，读取文档和发送邮件是两个独立授权。Agent 要携带用户主体、设备与会话上下文访问每项资源，并在动作升级时重新检查权限。文档分享范围变化、用户离职或会话超时，都应立即影响后续步骤。
长期记忆也不能脱离 ACL。记住某份财务文档中的事实，不代表下周仍可以向同一用户展示。记忆条目应保留来源、敏感级别、授权快照和过期条件；读取时重新做策略判断。
技能层负责能力，策略层负责允许
一个 Sheets 分析技能可以定义如何查询和生成公式，但不能自行决定可访问哪个表、能否导出到外部。工具注册表保存 schema、风险等级和 owner；策略引擎结合用户、数据、动作与目的决定是否允许。沙箱承载代码执行，网络网关限制外部目的地。
这种分层可以让技能跨 Workspace、数据平台和行业应用复用，同时保持控制一致。若每个技能都内置自己的权限判断，规则会漂移，审计也难以统一。
多模型路由不能破坏数据边界
统一 Agent 可能根据任务选择不同模型。路由器不仅考虑质量、延迟和成本，还要考虑数据能否发送给该模型、所在区域和保留策略。高敏感任务可能必须使用指定部署；模型降级时也不能把数据发往未经批准的路径。
支出上限应覆盖模型、工具、查询和运行时。用户看到的是一个 Agent，平台却必须把每次任务成本归因到部门、应用和数据源，并在预算不足时解释哪些步骤未完成。
统一 Agent 的验收应从跨应用任务开始
单独测试 Gmail 摘要或 Sheets 公式不足以验证架构。应构造跨系统流程：从邮件提取请求，读取受限文件，分析数据，在文档中形成草稿，等待审批后再发送。测试中途撤销文件权限、切换组织、让外部文档包含提示注入，并检查 Agent 是否停止。
同时度量任务完成率、权限拒绝正确率、人工确认次数、跨应用上下文丢失和数据来源可追溯性。统一 Agent 的竞争力并不只是覆盖多少产品，而是它能否在切换工具时仍维持同一条身份链、证据链和责任链。