Google Cloud 在 10 月 8 日把一个企业 Agent 描述成了真正的“同事”：它可以在 Gmail、Drive、Slack、Microsoft 365 和命令行之间接着做同一项工作；关掉电脑后，持续数小时或数天的任务仍在云端运行；团队还可以给它一个独立邮箱、日历、Drive 空间和公司目录身份。
这比多一个聊天入口更值得企业认真对待。过去分散在搜索助手、Workspace、编码工具和自定义 Agent 平台里的能力，如今被 Google 收进同一个长期身份：它记得什么、能调用什么工具、由哪个模型执行、做过哪些动作，都要围绕这个身份继续运转。统一身份让权限和日志更容易归责，也把误授权、错误记忆和跨系统误动作集中到一个主体上。
从两套产品到一个长期工作的入口
今年 4 月，Google 的企业 Agent 仍有明显分工。TechCrunch 当时将 Gemini Enterprise Agent Platform 概括为面向 IT 和技术团队的构建、管理平台；业务人员则使用 Gemini Enterprise 应用，消费 IT 发布的 Agent，或用无代码方式处理会议、文件和触发式流程。
10 月的发布把这两条线拉到一个入口里。Google 称新的 Gemini agent 既能聊天、处理知识工作和写代码，也能按目标自主执行任务；它可在网页、手机、桌面端、Workspace、Microsoft 365、Slack 和命令行中出现，还能作为无界面的 Agent 嵌入第三方应用。无论从哪个入口访问，云端都保留同一套上下文、记忆和个性化图谱。
任务因此不再天然受一次会话约束。Gemini 可以定时执行、响应事件，或者临时生成带独立身份的子 Agent，把多步骤工作串行或并行跑上数小时乃至数天。Google 还把记忆分成四类：当前任务的会话记忆、从文件和协作中形成的语义记忆、记录工作方法的程序记忆，以及保存以往动作的情景记忆。
这些描述来自发布页，不能等同于所有客户已经获得完整能力。Google 当前的产品文档确认 Gemini Enterprise 是搜索、助手和 Agent 平台，能够连接企业数据并执行任务；版本对照表则把“构建并发布无代码 Agent”标为预览。发布页没有给出 coworker agent、四类记忆和跨天任务分别在哪些地区、套餐或管理员开关下开放，也没有披露记忆的保留、删除、导出规则和长任务完成率。对采购方而言，第一张验收表应按具体租户逐项记录“可用、预览、仅宣布”，而不是把舞台上的总能力当作合同现状。
独立身份解决归责，不会自动缩小权限
coworker agent 是这次变化最具体的部分。团队描述一个角色后，系统会为 Agent 创建 Workspace 账户，包括邮箱、日历、Drive 和目录条目；同事可以把它加入 Chat 空间、在文档评论里 @ 它，版本历史也显示它自己的名字。Google 表示，它以自身身份行动，只能看到团队主动分享给它的内容。
独立身份的价值在于把“谁做的”从人类委托者手中拆出来。若 Agent 用员工账号代办，每一次读写看起来都像员工本人完成；当 Agent 反复运行、再分派子 Agent 时，事故调查很难区分人的授权、模型的选择和工具的实际调用。独立主体让日志、存储和权限可以围绕 Agent 本身管理。
身份仍只是权限控制的起点。Google 的 Agent Gateway 文档显示，管理员可以用统一访问策略限制 Agent 到 MCP 服务器、其他 Agent 和外部端点的通信；规则可按工具名、是否只读、HTTP 方法和 URL 路径设置允许或拒绝。Agent 身份使用证书和证书绑定令牌，通过 mTLS 与 DPoP 验证。文档还要求先在 dry-run 模式记录本应被拒绝的通信，再切到真正阻断流量的 enforce 模式。
这套机制比“只访问分享给它的文件”更接近可验收控制：测试 Agent 能否读取工单但不能删改数据库，确认拒绝规则是否覆盖临时子 Agent，再从审计日志还原动作。不过，公开材料没有证明 Workspace 中每一种 coworker 操作都已经经过同一套 Gateway 策略。企业需要实测身份是否一路传到连接器和目标系统，而不是只在 Google 一侧留下一个好看的目录账号。
多模型路由降低的是选择成本，不是责任
Google 还把“Agent”和底层模型拆开。Gemini agent 可以在 Google 自有模型与 Anthropic Claude 之间选择，Smart Routing 按任务在性能和成本之间路由；Google 的主张是，当更好的模型出现时，企业的上下文、技能和数据可以留在原处。
这确实降低了逐个应用更换模型的迁移成本，却没有消除供应商、地域和费用差异。10 月 8 日的 Google Cloud 发布记录显示，Claude Opus 5.5 和 Sonnet 5.5 默认关闭，管理员要在控制台接受条款后启用；推理只覆盖 global、美国和欧盟区域，使用量按消费计费，并计入项目支出上限。最新版本对照表还提示，第三方模型不会受普通超额开关约束，启用后会立即产生消费账单。
因此，Smart Routing 不能只用“自动选最佳模型”验收。企业至少要保留每次任务实际选用了哪个模型、为什么切换、花费多少、是否跨区处理，以及换模后工具调用和输出质量是否变化。Google 尚未公布统一 Agent 的路由基准、任务成功率或模型间回退规则，客户也无法仅凭官方列举的效率案例推导自己的回报。
长期记忆让 Agent 更像同事，也扩大了失效半径
统一 Agent 的吸引力来自减少重复交代：它记得团队、项目、工作方法和过去动作，可以在邮件、表格和演示文稿之间延续同一项任务。相同设计也会让错误跨会话延续。一次不准确的语义记忆可能影响后续检索；Agent 自己写入的程序记忆可能把临时做法固化成流程；长期身份一旦获得过宽连接器权限，跨天任务会把一次误判放大为一串动作。
这种风险不只来自 Google 的竞争对手，但竞争对手已经把问题说得很直接。微软 CEO Satya Nadella 在 10 月 10 日主张，应把模型提供者与行动权限分开；微软安全负责人随后把企业 Agent 称为需要持续约束的“内部主体”，认为保护范围必须覆盖身份、权限、数据、端点、网络与运行时。微软也在销售自己的安全产品，这一立场有商业动机；它提出的工程原则仍可被独立验证：非确定性模型不应控制约束自己的权限和唯一证据。
这给企业部署留下了四项比功能演示更重要的测试：用真实角色构造最小权限；向记忆写入错误信息后验证纠正和删除；故意触发高风险工具，确认拒绝、人工批准和停机机制；更换底层模型后复跑同一任务，比较动作轨迹、成本和结果。日志还要能由模型之外的系统保存和查询，否则“每一步都有审计记录”仍可能只是供应商内部的自证。
Google 的统一 Agent 把企业软件竞争从“谁的聊天框回答得好”推向“谁能托管一个长期行动的数字身份”。真正决定它能否成为同事的，不是记住更多内容或跑得更久，而是企业能否随时回答三件事：它现在代表谁、此刻为什么有权执行这一步、出错时谁能在模型之外把它停下来。
