2026 年 10 月 9 日

1 / 2

Google Cloud 发布 Gemini agent：企业 agent 开始拥有独立身份、长期记忆和跨模型调度

10 月 8 日，Google Cloud 在 Gemini at Work 2026 活动上公布新的 Gemini agent。Google Cloud 首席执行官 Thomas Kurian 将其定位为统一的企业工作 agent：用户可以通过一个入口交代任务，让系统调用工具、处理文档、运行代码，并在 Gmail、Google Docs、Sheets、Calendar、Slack 或 Microsoft 365 等应用中完成工作。

这次发布的重点并不是新的 Gemini 基础模型。Google 试图把过去分散在企业搜索、办公助手、代码 agent 和自动化工作流中的能力，组织成一个能够跨应用持续运行的系统。

官方将 Gemini agent 描述为能够在云端维持任务状态、记忆和个人化上下文，并根据任务需要选择不同模型。目前的模型选择包括 Google 自家的 Gemini 系列和 Anthropic 的 Claude 系列，未来还计划支持其他闭源及开放模型。Google 同时公布了金融和法律行业专用版本的预览；完整 Gemini agent 的统一公开可用范围、不同企业版本的开通条件和实际价格，尚不能仅从此次主公告中确定。Google Cloud 官方发布 · Reuters

Google 为这套系统提出了一个值得注意的设计：模型、agent 和组织中的工作身份可以分开。

一个普通聊天助手通常代表当前登录的用户操作。它读取用户有权访问的文件，使用用户的工具连接，在用户的会话中返回结果。如果任务需要多人合作，权限和状态往往依附于某个人的账号。

Gemini agent 则允许企业创建所谓的 coworker agent。它可以拥有自己的企业邮箱、日历、Drive 存储空间和通讯录身份，像一位团队成员一样被加入聊天群组、收到邮件或在文档评论中被提及。

例如，市场团队可以创建一个负责活动筹备的 agent。员工在群组里要求它准备发布检查文档，它可以收集材料、生成文件并发回群组；其他同事也可以在文档评论中继续要求修改。它执行操作时使用自己的身份，文档版本历史和审计记录也能够区分哪些动作来自 agent。

Google 强调，这类 agent 只获得团队明确分享给它的上下文和权限，不会自动继承创建者能够访问的所有企业资料。Google Cloud

这种身份设计对企业 agent 很重要，因为长期任务需要回答一个普通聊天产品很少面对的问题：当任务持续数天、涉及多名员工，而且可能在无人监督时继续运行，究竟由谁承担每一次操作？

假设一个 agent 负责定期生成财务报告。它需要读取销售数据库、访问部门文档、运行分析程序，并将结果发送给指定人员。如果所有操作都借用某位员工的完整权限，那么当员工转岗、离职或误分享文件时，agent 的访问边界也会变得难以管理。

独立身份允许企业为 agent 建立自己的权限集合。Google 宣布使用基于角色的细粒度授权、OAuth 身份传递、独立执行环境和审计日志，并通过 Agent Gateway 对进出 agent 的网络流量实施组织政策。

例如，管理员可以规定所有 agent 都不得读取某一保密等级的文件。这条规则由系统层执行，而不只是写在模型的提示词里。

这使安全控制能够部分脱离模型本身的判断。即使模型误解了用户指令，底层权限系统仍然可以拒绝某些资源访问。当然，实际防护效果还取决于身份传递、工具连接和策略执行是否存在漏洞；Google 尚未公布足够的独立安全测试，证明这些机制在各种复杂环境中都能可靠阻断越权操作。Google Cloud

第二个值得展开的部分是记忆。

Google 将 Gemini agent 的记忆分为四类：会话记忆保存当前任务状态；语义记忆记录从文档、人员和其他 agent 交互中获得的组织知识；程序性记忆保存完成某类工作的方法，包括 agent 自己编写的 skills；情景记忆则记录此前执行过的工作。

这四类记忆对应着企业任务中的不同问题。

会话记忆让一个持续三天的任务不必每次重新开始；语义记忆让 agent 理解公司内部的业务术语、项目关系和人员职责；程序性记忆使重复任务可以沿用已经形成的方法；情景记忆则提供过去做过什么、产生过什么结果的历史。

例如，某公司要求 agent 每周制作区域销售报告。第一次运行时，它可能需要探索数据库、确认“净销售额”的内部定义、找到负责审核的人员，并学习报告格式。后续运行时，这些知识可以分别进入语义记忆和程序性记忆，而上周生成的报告及其修订过程可以保存在情景记忆中。

这里仍有两个需要通过实际产品观察的问题。其一是记忆何时更新、如何纠正错误，以及过期信息何时失效；其二是跨团队记忆能否始终遵守权限变化。Google 公告描述了记忆类型及其用途，但没有提供足以判断长期记忆准确率和权限一致性的系统评测。Google Cloud

第三个变化是把模型选择变成 agent 平台的内部调度问题。

Google 明确提出，Gemini agent 可以根据任务选择 Gemini 或 Claude，并通过 Smart Routing 在质量和成本之间取舍。企业不需要为每个工作流固定使用同一个最大模型。

这与传统多模型应用的区别主要在系统组织方式。开发者过去可以自行写一个路由器：简单分类使用小模型，复杂代码任务使用强模型，长文档处理使用另一种模型。Google 现在希望将这类选择与企业工具、记忆、身份和成本管理整合起来。

企业可以设置项目级实时支出上限。达到上限时，相关 agent 暂停执行，由管理员或用户决定是否恢复。由于长程 agent 可能连续运行数小时甚至数天，成本控制必须覆盖模型 token、工具执行和 sandbox 等多个部分，单纯设置每次调用的 token 上限已经不够。

不过，Google 尚未提供一套公开、统一的实验，证明自动路由在相同任务完成率下能够节省多少成本。发布中列举的企业客户效率数据也来自不同工作流和部署环境，不能当作 Gemini agent 对所有企业任务的平均提升幅度。Google Cloud

这次发布还包含一个容易被忽略的企业数据问题：agent 要完成真实工作，必须知道组织内部术语究竟是什么意思。

Google 为数据分析任务引入 Knowledge Catalog，让企业集中定义业务指标、数据集关系和访问规则。这样，当不同 agent 查询“净利润率”或“活跃客户”时，理论上可以引用相同的业务定义，而不必各自猜测数据库字段。

Google 称，Bloomberg Media 在初期开发中通过这种方式将 SQL 查询准确率提高了 63%。这一数字来自特定客户的开发阶段，不能直接推导其他企业的表现，但它说明了为什么企业 agent 的可靠性往往取决于组织数据的整理程度。

如果模型能够写出正确 SQL，却不知道“收入”究竟应该使用订单金额、已结算金额还是扣除退款后的金额，最终结果依然可能错误。统一业务定义、权限和数据来源，是让 agent 在真实企业中工作的基础条件。Google Cloud

因此，Gemini agent 的重要性主要体现在系统边界的变化。Google 正在把 agent 作为企业中一种可以被授权、审计、记忆、调度和计费的长期工作主体来设计。

这套方案的各个组成部分并非全新发明，独立身份、工具注册、模型路由和持久记忆此前都有实践。10 月 8 日的新增在于，Google Cloud 正式将它们组织成统一的企业产品方向，并宣布跨办公软件、数据库、开发工具和行业应用的整合。

接下来值得观察的证据，是这些 agent 在长期任务中的完成率、权限边界是否稳定，以及当任务涉及多名员工和多个外部系统时，组织能否准确追溯和纠正每一步操作。

2 / 2

Google AMIE 临床研究发表于《柳叶刀》：90% 的鉴别诊断覆盖率，究竟证明了什么

10 月 8 日，Google 与美国 Beth Israel Deaconess Medical Center（BIDMC）宣布，其医疗对话 AI 系统 AMIE 的一项真实临床可行性研究发表于《柳叶刀》。

这项研究值得关注的地方，是它将此前主要在模拟病例和患者演员环境中测试的医疗 AI，带入了真实的门诊流程。不过，研究本身并非刚刚开始：实验在 2025 年 4 月至 11 月进行，预印本已于 2026 年 3 月公开。10 月 8 日的新进展是同行评审期刊发表及研究机构的正式介绍。

AMIE 全称为 Articulate Medical Intelligence Explorer。研究团队希望检验，患者在正式见医生之前，是否能够先与 AI 进行一段有临床意义的对话，让 AI 收集症状、整理病史、提出需要与医生讨论的可能诊断，并生成供医生阅读的摘要。Google 公告 · 研究预印本 · BIDMC 新闻稿

研究采用前瞻性、单中心、单组可行性设计。

患者在预约非急诊性质的初级医疗就诊后，可以选择参与实验，并在正式看医生前通过安全网页与 AMIE 进行文字对话。AI 询问症状、相关病史和其他信息，然后生成对话记录、摘要以及可能的诊断方向。患者同意后，这些材料会在就诊前提供给医生。

研究最初有 114 名患者开始 AI 交互，其中 100 人完成对话，98 人随后完成了正式医生就诊。

整个过程中，每一段患者与 AI 的对话都有一名经过培训的医生实时监督。如果出现自伤风险、明显情绪困扰、潜在临床危险，或者患者要求停止，监督医生可以介入。

研究报告称，所有完成的对话均未触发预先定义的安全停止条件。监督医生识别到一次幻觉，并在五个病例中提供额外临床澄清。Google Research · BIDMC

这个结果说明，在研究规定的患者范围、文字交互方式和实时医生监督条件下，AMIE 可以完成预诊对话，而没有出现需要中断的安全事件。

它还不能证明 AMIE 可以在无人监督的情况下安全服务大量患者。样本规模只有约百人，研究对象来自一家学术医疗中心，而且参与者整体比该门诊的普通就诊人群更年轻。罕见但严重的错误，也很难通过如此规模的实验充分排除。

研究中的监督机制本身是系统安全的一部分，不能在解释结果时把它省略。

更值得仔细理解的是诊断成绩。

Google 公布，AMIE 的鉴别诊断列表在 90% 的病例中包含患者最终诊断；前三个候选诊断的覆盖率为 75%；如果只看 AI 排在第一位的诊断，准确率为 56%。

这三个数字描述的是明显不同的能力。

鉴别诊断是医生面对症状时提出的一组可能解释。例如，一位患者出现胸痛，系统可能同时考虑肌肉骨骼问题、胃食管反流、肺部疾病和心血管问题。提出一组合理候选，可以帮助医生安排后续询问和检查，但它不等于已经确定病因。

因此，90% 的含义是最终诊断出现在 AMIE 提出的前七个候选中。这个结果支持它具有一定的诊断方向覆盖能力，却不能理解为 AI 有 90% 的概率直接给出正确诊断。

56% 的第一候选准确率更接近通常所说的“最可能诊断是否正确”，但即使这个指标也不能直接与完整临床诊断能力画等号，因为 AMIE 没有进行体格检查，也无法查看患者完整电子病历。研究预印本 · Google Research

研究还安排了盲法临床评价，让没有参与实际就诊的医生评估 AMIE 和初级医疗医生提出的鉴别诊断与管理方案。

在整体鉴别诊断质量、管理方案适当性和安全性方面，研究没有发现具有统计显著性的差异。但在管理方案的实用性和成本效益方面，真实医生表现更好。

这组比较也需要结合双方获得的信息来理解。实际医生可以与患者面对面交流，获取更多病史、观察外观、进行检查，并结合本地医疗资源作出决定；AMIE 主要依赖就诊前的文字对话。

因此，这项研究没有建立一个双方拥有完全相同信息、执行完全相同任务的诊断竞赛。它比较的是两种不同工作条件下产生的临床推理材料，并尝试判断 AI 预诊结果是否具有实际使用价值。Google Research

医生对摘要的评价提供了另一种证据。

Google 在 10 月 8 日的公告中表示，临床医生认为 AMIE 摘要在约 75% 的病例中帮助了就诊准备，并在超过一半的病例中影响了他们的诊疗思路。

部分受访医生描述，预先阅读 AI 收集的信息后，正式就诊可以更快进入核实症状、讨论诊断和共同决策的阶段，而不必从头收集所有基础信息。

这说明 AI 预诊可能改变医生与患者的时间分配。但“医生觉得摘要有帮助”与“患者获得了更好的医疗结果”之间仍然存在明显距离。

研究没有设置不使用 AMIE 的随机对照组，因此无法判断使用 AI 是否实际缩短了平均就诊时间、减少了漏诊、降低了医疗费用，或者改善了患者长期健康结果。医生可能认为某份摘要很有用，但如果阅读摘要本身耗费了额外时间，整体工作负担也未必下降。Google 公告 · Google Research

患者体验同样具有两面性。

研究发现，参与者对 AI 的态度在交互后有所改善，并且这种变化在完成医生就诊后仍然存在。患者普遍认为 AMIE 的对话礼貌、解释清楚，能够帮助他们整理自己的症状。

但 BIDMC 同时指出，患者仍然担忧向系统披露医疗信息的保密性，以及 AI 是否始终诚实可信。这些问题与模型回答是否流畅属于不同层面。

医疗对话需要患者提供大量私人信息。即使模型能准确询问症状，患者仍需要理解数据由谁保存、医生能看到什么、AI 会不会遗漏重要信息，以及最终由谁承担诊疗责任。BIDMC

这项研究还提示，医疗 AI 的评测对象正在发生变化。

此前很多医疗模型研究主要依靠医学考试题、病例报告或患者演员。它们适合测量知识、推理和模拟对话能力，却无法完整反映真实患者的表达方式、焦虑、信息遗漏，以及医生如何使用 AI 生成的材料。

AMIE 研究将评价扩展到真实患者参与、医生实时监督、就诊前后体验，以及 AI 输出进入实际诊疗流程后的作用。

这使研究结果更加接近真实医疗环境，也让结论受到更多实际条件约束。模型是否安全，取决于患者范围、监督方式和干预标准；模型是否有用，取决于医生是否能够利用摘要；模型是否改善医疗，则需要进一步通过对照研究和患者结局测量。

10 月 8 日发表于《柳叶刀》的这项工作，提供了一个经过真实门诊流程检验的可行性样本。它支持继续研究 AI 辅助问诊和就诊准备，但距离证明无人监督的医疗 AI 可以独立诊断、改善患者结局或替代初级医疗医生，还有明确的证据缺口。