谷歌最强旗舰模型Gemini 3.5 Pro据称已延期数月，编码能力未达预期只是表层原因，人才流失、组织内耗与军方合作争议正在同时拖慢DeepMind。

谷歌的下一代旗舰模型，仍然没有等来发布日期

截至北京时间 2026 年 7 月 24 日，谷歌尚未发布被视为下一代旗舰模型的 Gemini 3.5 Pro，而多家媒体援引内部人士称，其开发进度已经落后原计划数月。

Gemini 3.5 Pro 是谷歌正在开发的新一代高性能通用模型，目标是承担复杂推理、代码生成、多模态理解和企业级智能体任务。 彭博社此前报道称，该模型未能按照原计划推进；Axios 最新采访的六位谷歌 DeepMind 现任及前任员工则表示，员工士气低落、人才流失和内部争议也是延期的重要原因。

谷歌并未公开确认 Gemini 3.5 Pro 的最终发布日期，也没有发布模型参数、基准测试成绩和正式价格。这意味着，外界目前只能确认旗舰模型缺席，无法通过公开跑分判断它究竟比竞争对手落后多少。

Gemini 3.5 Pro 的问题已经不只是一次普通跳票，而是谷歌能否维持前沿模型迭代速度的压力测试。 对一家拥有自研 TPU、全球级数据中心、搜索数据和顶尖研究团队的公司来说，算力与资金都不是最稀缺的资源；真正稀缺的是让研究、产品、安全和商业团队在同一时间表下完成交付的组织能力。

延期数月，编码能力据称是直接瓶颈

AI 编码能力是指模型理解代码库、生成和修改程序、定位缺陷并完成软件工程任务的综合能力。 它与回答一道算法题不同，更接近让模型进入真实项目，在多个文件、依赖关系、测试用例和运行环境之间连续工作。

据彭博社此前援引十位现任及前任谷歌员工的报道，Gemini 3.5 Pro 的直接瓶颈之一是编码表现未达到内部预期。谷歌在 6 月底更新了训练数据，希望改善代码生成效果，但内部测试结果据称仍不理想。

编码能力已经从模型发布会上的展示项目，变成前沿模型最重要的商业入口之一。 企业愿意为代码智能体付费，不是因为它能补全一行函数，而是因为它可以阅读仓库、调用工具、执行测试、修复错误，再根据测试结果继续迭代。这个场景要求模型同时具备长上下文理解、规划、工具使用和低错误率，任何一项短板都会被放大。

谷歌面临的难题是，旗舰模型不能只在少数榜单上追平对手，还必须在真实软件工程流程中保持稳定。 如果模型生成一段代码的成功率是 90%，看上去已经很高；但一个任务若需要连续完成十个相互依赖的步骤，理论上的全流程成功率只有约 35%。前沿模型厂商因此越来越重视多步执行和错误恢复，而不只是单轮代码生成。

目前没有公开证据表明 Gemini 3.5 Pro 在某个具体编码基准上落后多少。谷歌没有发布 SWE-bench、Terminal-Bench 或内部软件工程评测数据，媒体报道也没有给出可复核的分数，因此把“落后数月”直接等同于“性能落后几代”并不严谨。

发布日期的落后仍然会转化为产品层面的落后。 模型晚发布一个月，意味着开发者反馈、企业部署、智能体适配和推理优化也晚一个月；当竞争对手以数周为周期更新时，数月延期足以让对方完成一轮模型、工具链和客户案例的闭环。

小模型持续更新，反而放大了旗舰缺席

轻量模型是以较低推理成本和更短响应时间为目标，主动牺牲部分复杂任务能力的模型。 谷歌近期仍在推进 Gemini 3.6 Flash、Gemini 3.5 Flash-Lite，以及面向网络安全任务的 Gemini 3.5 Flash Cyber，说明 DeepMind 的模型发布管线并未完全停摆。

小模型能够守住调用量，却无法替代旗舰模型建立技术上限。 Flash 类模型适合高并发客服、信息抽取、内容审核和简单代码辅助，但企业在复杂编程、科研分析和自主智能体场景中，首先比较的仍是各家的最强模型。

| 模型或产品线 | 当前状态 | 主要定位 | 编码与复杂推理 | 价格信息 | 现阶段判断 | |—|—|—|—|—|—| | Gemini 3.5 Pro | 据称延期数月，尚未正式发布 | 谷歌下一代旗舰模型 | 据报道未达到内部预期，暂无公开跑分 | 尚未公布 | 决定谷歌能否守住第一梯队上限 | | Gemini 3.6 Flash | 已推出或进入市场投放阶段 | 低延迟、高吞吐任务 | 更强调效率，不以最高能力为首要目标 | 以谷歌正式页面为准 | 能补充产品线，不能替代 Pro | | Gemini 3.5 Flash-Lite | 已推出或进入市场投放阶段 | 成本敏感型批量任务 | 适合结构化处理和轻量生成 | 公开资料未在本次报道中统一列明 | 有利于规模化使用，但难承担复杂智能体 | | Gemini 3.5 Flash Cyber | 面向网络安全的专用版本 | 安全分析与相关工作流 | 侧重垂直领域，而非通用能力上限 | 尚无完整可比价格数据 | 场景明确，但市场范围有限 | | OpenAI、Anthropic旗舰模型 | 持续迭代 | 通用推理、编码与智能体 | 已成为谷歌内部比较对象 | 各家计费结构不同 | 在开发者心智和企业编程场景中施压谷歌 | | Meta AI模型体系 | 持续推进 | 模型能力、开放生态及消费级入口 | 竞争重点因产品而异 | 无法与闭源旗舰直接按单一价格比较 | 高管公开嘲讽反映竞争气氛升温 |

表格中没有填写未经官方确认的基准分数，也没有把不同上下文长度、缓存机制和推理模式下的价格强行换算。模型比较只有在任务、输入输出规模和推理预算一致时才有意义，单看一个总榜名次很容易得出错误结论。

Meta AI 负责人 Alexandr Wang 已在 X 上用“Gemini？没听说过”公开调侃谷歌，其他竞争对手也在追问更强模型何时就绪。高管间的口水战没有技术含量，但它说明谷歌正在丢失一种更重要的资产：市场默认其下一次发布会带来领先模型的预期。

技术问题背后，是谷歌式组织内耗

组织内耗是多个团队在目标、资源和决策权上相互牵制，最终降低整体交付速度的状态。 对谷歌来说，训练出一个强模型只是第一步，模型还要进入搜索、云服务、Android、YouTube、Workspace 和开发者工具，任何一条产品线都可能提出不同的成本、安全与发布时间要求。

前员工将推动谷歌各部门朝同一方向前进，形容为“把整个海洋的水烧开”。这个比喻并不夸张：Google Cloud、DeepMind 和 Android 团队都在开发面向程序员的 AI 工具，部分消费者产品团队也参与其中，重叠项目会争夺相同的算力、人才和内部渠道。

重复造轮子的问题不在于谷歌缺少项目，而在于太多项目都希望成为统一入口。 一个团队希望模型优先服务云客户，一个团队要求它与 Android 深度结合，另一个团队则要保护搜索广告的用户体验；这些目标单独看都合理，放在同一发布日期前就会互相冲突。

内部算力竞争也会拖慢实验节奏。谷歌虽然拥有自研 TPU 和庞大的数据中心，但前沿训练、后训练、评测以及产品推理都在争夺高端计算资源；当研究人员无法快速重复实验时，训练数据更新后的负面结果就更难被及时定位。

谷歌早期对内部代码使用生成式 AI 的谨慎政策，也可能让它错过了一部分产品反馈窗口。 出于专有代码保护和训练数据治理考虑，谷歌一度限制员工用 Gemini 编写或分析内部代码，相关政策后来有所放宽，但组织级使用习惯不会随着一条政策立即改变。

联合创始人谢尔盖·布林一直在推动 AI 编程产品提速，谷歌首席 AI 架构师 Koray Kavukcuoglu 也在尝试统一内部工具，DeepMind 还组建了专门的 AI 编程团队。这些调整方向是对的，但组织重构的见效周期通常比模型训练周期更长，难以立刻解决 Gemini 3.5 Pro 的发布时间问题。

军方合作争议正在消耗员工士气

谷歌与美国国防部的合作协议，是本轮 DeepMind 员工不满的另一条导火索。 据 Axios 报道，谷歌在 2026 年 4 月达成了一项允许美国军方使用其技术的协议，多名员工在离职面谈中提到了这项合作。

一位知情人士将内部争议描述为一场“持续的战斗”，并称其造成了“情感上的倦怠”。DeepMind 前研究科学家 Alex Turner 也表示，自己因谷歌的军事合同而辞职。

军事合作争议对模型进度的影响不是某段训练代码突然失效，而是团队信任和人员稳定性下降。 前沿模型项目高度依赖经验积累，负责数据、架构、评测和后训练的核心研究员很难被即刻替代；一个关键成员离开，可能让多个实验失去上下文。

DeepMind CEO Demis Hassabis 最近发布了新的 AI 安全框架，但有前员工认为，他在公司内部的可见度不如部分竞争对手 CEO。安全框架能够明确模型风险边界，却不能自动解决员工对技术最终用途的道德分歧。

谷歌曾因 Project Maven 等军事项目遭遇过类似内部反弹，因此这并不是一个全新的管理问题。不同之处在于，2026 年的顶尖 AI 人才拥有更多选择，研究员可以转向 OpenAI、Anthropic 或其他资金充足的实验室，员工不满更容易迅速变成人才流失。

顶尖研究员离职，比一次延期更难修复

人才流失是谷歌当前最具长期破坏性的风险。 据相关报道，Gemini 联合负责人 Noam Shazeer 已离开谷歌并加入 OpenAI，AlphaFold 核心研究者、诺贝尔化学奖得主 John Jumper 则转投 Anthropic。

今年 6 月，Gemini 核心研发人员 Jonas Adler 和 Alexander Pritzel 也被报道离职并加入 Anthropic。这些人员变动的重要性不只体现在履历，而在于他们掌握模型训练过程中大量不会完整写入文档的隐性知识。

前沿模型开发不是按人数线性扩张的工程。新增十名研究员未必能立刻替代一名熟悉训练失败模式、数据配比和评测漏洞的核心成员；新员工需要先理解已有实验，再建立对内部基础设施的判断，补位周期往往以月计算。

人才流动还会形成自我强化。 当研究员认为项目落后时，更容易接受竞争对手邀请；核心人员离开后，剩余团队的负担加重，模型进度进一步受影响；进度继续延误，又会让更多人怀疑项目方向。

1900亿美元支出，让延期变成财务问题

AI 资本开支是科技公司为数据中心、芯片、网络和电力基础设施投入的长期资金。 谷歌最新一季财报超过市场预期，但报道指出，公司自由现金流已经转为负值，重要原因之一正是持续增加的 AI 投资。

谷歌 2026 年总支出预计达到 1900 亿美元。这个数字不应被简单理解为全部用于训练 Gemini，也不应与单一季度资本开支混为一谈，但它足以说明市场对投资回报的要求正在迅速提高。

彭博行业研究分析师 Mandeep Singh 表示，谷歌云业务收入增长 82%，搜索业务收入则略低于华尔街预期。云业务高增长证明 AI 基础设施确实存在需求，但搜索低于预期会放大投资者对核心业务被 AI 改写的担忧。

| 财务与业务指标 | 最新报道口径 | 对 Gemini 3.5 Pro 的含义 | |—|—:|—| | 谷歌 2026 年预计总支出 | 1900 亿美元 | 模型延期会加大市场对投入效率的质疑 | | 谷歌云业务收入增速 | 82% | AI 计算需求强劲，基础设施仍具商业回报 | | 自由现金流 | 已转为负值 | 投资者将更关注模型和产品何时兑现收入 | | 搜索业务表现 | 略低于华尔街预期 | 谷歌必须证明 Gemini 能增强而非侵蚀搜索业务 |

Alphabet 股价此前也对延期报道作出明显反应，相关消息出现后盘中一度跌逾 3%，当日最终收跌 4.44%。股价波动不能证明一个未发布模型的能力，但能反映资本市场已经把 Gemini 3.5 Pro 当作衡量谷歌 AI 执行力的指标。

谷歌还没有掉队，但容错空间正在缩小

谷歌仍然拥有其他实验室难以复制的全栈优势。 从 TPU、数据中心到搜索、Android、Chrome、YouTube 和 Workspace，谷歌可以把模型同时部署到消费端、企业端和开发者端，并通过真实产品获得高频反馈。

Gemini 在多模态输入、搜索信息整合和超大规模分发方面仍有明显基础，谷歌云的增长也说明企业没有停止购买其 AI 基础设施。下一代 Gemini 4 据称已经启动训练，因此 Gemini 3.5 Pro 延期并不等于谷歌的前沿模型路线中断。

谷歌真正落后的可能不是某一项模型能力，而是把研究成果变成稳定产品的速度。 OpenAI 和 Anthropic 的组织更聚焦，可以围绕单一模型快速调整产品和商业策略；谷歌每次升级都必须考虑多个业务部门以及数十亿用户的兼容问题。

谷歌选择不发布一个内部评测不过关的旗舰模型，本身并不是错误。相比带着明显缺陷仓促上线，延期并继续训练通常更负责任，尤其是旗舰模型会直接进入企业代码库和自动化工作流。

延期的合理性取决于它最终换来了什么。 如果 Gemini 3.5 Pro 上线后在真实编码、复杂推理和智能体执行上形成可感知优势，几个月等待可以被视为质量控制；如果模型只是在公开榜单上小幅追平对手，延期就会被解释为组织效率下降。

对开发者而言，当前不应为未发布模型暂停选型

开发者现阶段不应根据传闻为 Gemini 3.5 Pro 预留关键项目档期。 模型尚无确定发布日期、正式价格、上下文规格和可复核跑分，任何围绕它制定的迁移计划都缺乏稳定依据。

企业更合理的做法是使用自己的真实任务集持续评估现有模型。代码场景至少应覆盖仓库级理解、跨文件修改、测试通过率、工具调用成功率、响应延迟和单任务总成本，而不是只比较厂商提供的静态榜单。

谷歌需要用正式发布回答三个问题：模型是否足够强、推理是否足够稳定、价格是否足以支撑规模化部署。 其中任何一个问题没有清晰答案，Gemini 3.5 Pro 都很难扭转市场对谷歌“再次掉队”的判断。

截至 7 月 24 日，最稳妥的结论仍然是：Gemini 3.5 Pro 确实处于外界预期之外的延期状态，但谷歌的技术落后幅度尚无公开数据可以量化。比模型跑分更明确的信号，是人才、组织、文化和资本压力正在同一时间挤压 DeepMind 的交付能力。

参考来源

• IT之家：谷歌旗舰大模型难产背后，军方合作引员工不满 —— 汇总 Axios、彭博社报道，涉及模型延期、员工士气、人才流失与谷歌财务数据。
• 知乎：Gemini 3.5 Pro 难产，谷歌跌入失望陷阱 —— 对 Gemini 3.5 Pro 延期及编码能力瓶颈的补充分析。

Databricks 将把 Genie 接入 Microsoft 365 Copilot，让员工在 Teams 等办公入口直接查询企业数据。真正的价值不在聊天界面，而在身份、权限与数据治理能否原样延伸到办公工作流。

Genie 走进微软办公流：企业数据分析助手不再困在 BI 后台

Databricks 正在把 Genie 接入 Microsoft 365 Copilot，企业员工未来可以在 Teams 等日常办公入口中，直接用自然语言查询 Databricks 里的业务数据。7 月 23 日，Databricks 宣布将与微软的战略合作延长至 2030 年代，并扩大 Azure Databricks、Microsoft 365、Power Platform、Copilot Studio 以及 Azure Cobalt 之间的整合。

这次更新的重点不是给 Databricks 再增加一个聊天窗口，而是让数据分析能力进入企业已经在使用的办公工作流。销售负责人不必打开 BI 仪表盘，供应链经理也不必先找到数据分析师，他们可以在 Microsoft 365 Copilot 或 Teams 中直接追问：华东区本周收入为什么下降、哪些 SKU 的库存风险最高、上季度续费率变化来自哪些客户群。

**Databricks Genie 是一套面向企业数据的自然语言分析助手。**它把用户问题转换为对企业数据的分析过程，并结合数据表、字段、指标定义和业务语义生成回答。与通用聊天机器人不同，Genie 的核心对象不是互联网知识，而是被 Databricks 管理和授权的内部数据。

不是把数据复制给 Copilot，而是把 Genie 变成可调用的企业 Agent

这项集成更接近“Agent 调用 Agent”，而不是把 Databricks 数据整体导入 Microsoft 365。Microsoft 365 Copilot 承担用户入口和任务编排，Genie 负责理解数据问题、访问获准的数据资产并返回分析结果，底层数据仍由 Databricks 的数据平台和治理体系管理。

微软与 Databricks 的官方文档显示，目前有两条主要接入路径：第一条是在 Microsoft Teams 中安装 Databricks Genie 应用，再从 Microsoft 365 Copilot 中选择 Genie；第二条是先从 Databricks 建立到 Microsoft Power Platform 的连接，再通过 Copilot Studio 连接 Genie Agents，并将其发布到相应办公场景。

**Copilot Studio 是微软用于构建、连接和发布企业智能体的低代码平台。**它在这套架构中扮演编排层，负责把 Microsoft 365 中的用户请求交给 Genie，而不是替代 Genie 的数据分析能力。

两条接入路径对应不同的企业需求：

1. **Teams 应用路径更适合快速部署。**企业可以把 Genie 放进员工已经使用的沟通界面，减少切换系统的成本。
2. **Copilot Studio 路径更适合流程化集成。**企业可以把 Genie 与审批、通知、客户服务或内部知识助手组合，而不只是提供一个独立聊天入口。
3. **Power Platform 连接更适合已有微软低代码体系的组织。**这类企业通常已经使用 Power Automate、Power Apps 或 Copilot Studio，Genie 可以成为其中一个受控的数据分析节点。

这也意味着，所谓“接入 Microsoft 365”并不等于 Genie 立刻成为 Word、Excel、Outlook 中无处不在的原生按钮。现阶段官方明确描述的主要交互入口是 Microsoft 365 Copilot、Teams 应用以及通过 Copilot Studio 发布的 Agent；企业能否在具体 Office 应用中调用，还取决于管理员配置、租户策略、产品许可与微软侧的功能开放范围。

最关键的变化是权限可以跟着用户走

企业数据助手真正难解决的问题不是自然语言转 SQL，而是“谁有权问什么”。一个能回答收入、员工薪酬、客户名单和供应链成本的机器人，如果只用统一服务账号访问数据库，就可能把原本隔离的数据暴露给不该看到的人。

**企业 OAuth 是将用户身份和授权关系带入外部应用的企业级认证机制。**Databricks 表示，Genie 可以通过企业 OAuth 对来自 Teams、Copilot Studio 或自定义应用的会话进行认证，让每次对话对应到具体用户，而不是让所有请求共享一个高权限账号。

**Unity Catalog 是 Databricks 用于统一管理数据、AI 资产、权限和审计的治理层。**Genie 会遵循用户已有的 Unity Catalog 权限，只访问该用户能够访问的数据；如果一名区域经理没有查看全国客户明细的权限，把问题换成自然语言也不会自动绕过限制。

这套身份链路至少要完成四件事：

• Microsoft 365 能识别当前发起请求的员工；
• Copilot Studio 或 Teams 应用能够把身份安全地传递给 Databricks；
• Databricks 能依据该身份执行对应的数据权限；
• 查询、回答和工具调用能够进入企业审计记录。

权限继承是这次集成最有价值、也最容易被低估的部分。过去企业把聊天机器人接到数据库时，往往需要重新开发登录、权限映射、凭证保管和审计逻辑；如果 OAuth、Copilot Studio 与 Unity Catalog 能完整衔接，部署团队可以少造一套身份系统。

但权限正确不代表答案正确。Genie 即使只能看到获准的数据，仍可能因为指标定义含糊、表之间关系错误、数据更新延迟或自然语言歧义，给出逻辑上合理、业务上错误的结论。

Genie 与 Microsoft 365 Copilot 各自负责什么

Microsoft 365 Copilot 和 Databricks Genie 并不是同一种产品。前者理解邮件、会议、文档和组织协作上下文，后者理解企业数据平台中的表、指标和业务语义，两者组合后才可能完成从“发生了什么”到“为什么发生”的跨系统分析。

| 产品 | 核心定位 | 主要数据范围 | 典型入口 | 治理基础 | 独立新增价格 | |—|—|—|—|—|—| | Databricks Genie | 自然语言企业数据分析 | Lakehouse 中的表、指标及语义信息 | Databricks、Teams、Microsoft 365 Copilot、Copilot Studio | Unity Catalog、企业 OAuth | 本次合作未公布独立售价 | | Microsoft 365 Copilot | 办公内容理解与任务协作 | 邮件、会议、文档及 Microsoft Graph 上下文 | Teams、Word、Excel、Outlook 等 | Microsoft 365 租户权限与合规体系 | 取决于微软现有许可方案 | | Power BI Copilot | 面向报表和语义模型的辅助分析 | Power BI/Fabric 语义模型与报表 | Power BI、Microsoft Fabric | Fabric 与 Power BI 权限体系 | 取决于容量和许可配置 | | Snowflake Cortex Analyst | Snowflake 数据的自然语言查询 | Snowflake 中的数据与语义模型 | Snowflake 及企业自建应用 | Snowflake 角色与数据治理 | 取决于 Snowflake 用量与产品配置 |

Databricks Genie 相比 Power BI Copilot 的优势在于，它更靠近 Lakehouse 中的原始数据、工程管道和统一治理层。对于数据已经集中在 Databricks、但消费入口分散在 Teams、门户和内部应用中的企业，Genie 可以减少为每个入口重复建设问答逻辑的工作。

Power BI Copilot 的优势则是成熟的报表消费环境和微软 BI 用户基础。企业如果已经围绕 Power BI 语义模型完成指标治理，并不一定需要为了自然语言问答再引入 Genie；反过来，如果大量分析发生在 Databricks SQL、数据科学工作流和 Lakehouse 表上，Genie 与数据资产的距离更近。

Snowflake Cortex Analyst 与 Genie 的竞争逻辑类似，双方都试图把自然语言问题映射到可信的企业指标和查询。它们之间的差别最终不只取决于模型效果，而取决于企业的数据放在哪里、权限体系由谁管理，以及语义层是否已经建设完成。

办公入口会扩大数据分析的用户规模

Genie 进入 Microsoft 365 后，最直接的受益者不是数据工程师，而是没有 SQL 能力的业务负责人。数据团队过去需要处理大量重复问题，例如按地区拆分销售额、解释某周转化率变化、查询库存覆盖天数，这些任务技术难度不高，却不断占用分析资源。

销售场景可以体现这种变化。区域负责人可以在 Teams 讨论业绩时直接询问 Genie：本月目标完成率低于 80% 的客户经理有哪些，并继续追问这些人员的商机数量、平均成交周期和重点流失客户，而不必在会议后再提交取数需求。

供应链场景更适合连续追问。运营人员可以先找出未来两周可能缺货的产品，再按供应商、仓库和预计收入影响拆分，最后让工作流把高风险项目发送给对应负责人；Genie 提供数据解释，Copilot Studio 负责后续通知和流程动作。

财务场景则会更谨慎。预算执行、成本拆分和现金流数据通常涉及行列级权限、敏感字段和严格口径，企业需要先定义“收入”“毛利”“活跃客户”等指标，再允许 Genie 面向更大范围员工开放。

真正的生产力提升不会来自少点两次鼠标，而会来自分析等待时间的缩短。过去一个跨部门数据问题可能要经历提需求、确认口径、排期、写 SQL 和制作报表；进入办公流后，简单问题可以在对话中完成，分析师则集中处理因果判断、实验设计和复杂建模。

语义层质量决定 Genie 是助手还是“数据幻觉机”

自然语言分析的准确率上限由企业的数据语义质量决定。模型可以理解“找出高价值客户”，但数据库里可能同时存在按收入、利润、生命周期价值和续费概率定义的四种高价值客户，缺少明确口径时，再强的模型也只能猜。

企业部署 Genie 前至少需要补齐三类信息：

• **业务术语定义：**明确收入、订单、客户、流失等核心概念的计算规则；
• **数据关系说明：**标记表之间的连接方式、时间字段和主键，避免重复计算；
• **可信查询示例：**提供经过验证的问题和查询逻辑，让 Genie 学会组织内部的表达方式。

Genie 的价值因此与数据团队前期投入成正比。指标体系清晰、Unity Catalog 权限完整、表描述充分的企业，上线后更容易获得稳定回答；数据表命名混乱、同一指标存在多个版本的企业，只会把原有数据债务包装成更自然的语言。

回答可验证性同样重要。企业数据助手不能只输出一段看似专业的结论，还应让用户确认所用数据范围、时间窗口、筛选条件和指标定义；涉及经营决策时，用户还需要能够追溯到对应的数据资产或查询过程。

安全边界不应只停留在“有权限”

企业 OAuth 和 Unity Catalog 解决的是访问控制，但不能覆盖智能体系统的全部风险。Genie 进入办公流后，用户发起查询的频率和范围都会扩大，数据泄露、提示注入、错误汇总和敏感信息被复制到聊天记录中的风险也会随之上升。

企业管理员需要额外关注以下问题：

1. **聊天结果保存在哪里。**查询结果可能进入 Teams 会话、Copilot 历史记录或企业日志，其保留周期不能只看 Databricks 一侧。
2. **敏感字段能否被汇总推断。**用户即使不能读取单条薪酬记录，也可能通过小样本分组反推出个人信息。
3. **Agent 能否调用后续动作。**当 Genie 与工作流连接后，错误回答可能触发通知、工单甚至审批，风险高于单纯聊天。
4. **成本能否被控制。**自然语言的连续追问可能产生多轮模型推理和数据查询，企业需要设置资源、并发和查询预算。
5. **回答是否有审计证据。**关键经营结论应保留身份、数据版本、查询条件和时间戳，避免无法复盘。

Databricks 官方文档也单独提示了 Teams 应用的限制项，这说明当前集成仍需要按具体租户、区域和功能可用性进行验证。企业不应把演示中的顺畅对话直接等同于可全员上线的生产能力。

微软拿入口，Databricks拿数据层

这次合作延长至 2030 年代，说明双方瞄准的不是一个插件，而是企业 AI 基础设施的长期绑定。Databricks 表示将加大对 Azure 的投入，并扩大使用 Azure Databricks 来运行自身核心业务运营和分析，这相当于它也在用自家与微软联合提供的云上产品验证规模化能力。

微软的收益是让 Microsoft 365 Copilot 获得更深的企业数据访问能力。办公助手如果只能总结邮件和会议，很容易停留在内容整理层；接入 Genie 这类数据 Agent 后，它才有机会回答经营问题，并把分析结果带入会议、协作和自动化流程。

Databricks 的收益是获得 Microsoft 365 的分发入口。企业数据平台通常由工程师和分析师使用，而 Teams 和 Microsoft 365 面向的是全体知识工作者；Genie 一旦进入这些入口，潜在用户规模会从数据团队扩展到销售、财务、运营和管理层。

双方还计划增加对 Microsoft Azure Cobalt 的使用。**Azure Cobalt 是微软自研的 Arm 架构云端处理器系列。**Databricks 此次只表示会通过增加使用 Cobalt 提升性能和效率，尚未披露具体实例规格、迁移比例、成本降幅或查询性能数据，因此现阶段更适合把它理解为基础设施合作信号，而不是可以量化的产品性能升级。

这次更新有用，但不会自动消灭 BI

Genie 接入 Microsoft 365 是一个实用方向，因为企业员工更愿意在熟悉的办公入口提问，而不是学习另一个分析产品。不过，它替代的首先是临时取数、简单拆分和重复问答，而不是经过审计的财务报表、固定经营看板或复杂的数据科学工作。

传统 BI 仍然适合持续监控和统一展示。管理者每天需要查看的核心指标，不应该每次都通过自然语言重新生成；自然语言助手更适合处理看板之外的追问，例如某个指标为什么变化、哪些客户贡献了差异、是否存在异常分组。

Genie 的竞争力最终取决于三个指标：回答是否可信、权限是否完整、从提问到结果是否足够快。Databricks 与微软目前没有公布此次集成的独立价格、端到端延迟、查询准确率或企业部署规模，因此暂时无法用统一跑分判断它对 Power BI Copilot、Snowflake Cortex Analyst 等产品的领先幅度。

可以确定的是，企业数据助手正在从独立聊天页面转向办公软件中的基础能力。模型本身会逐渐商品化，真正形成壁垒的将是身份链路、语义层、数据治理和工作流分发，而这恰好是微软与 Databricks 各自最擅长的部分。

参考来源

按指定的可访问域名范围，以下权威来源未附站外超链接，仅保留来源名称与内容说明。

• **Databricks 与微软扩大合作公告：**说明双方将战略合作延长至 2030 年代，并推进 Genie、Microsoft 365、Azure Databricks 与 Azure Cobalt 的整合。
• **Databricks Genie on Microsoft 365 Copilot 官方文档：**说明 Teams 应用和 Power Platform/Copilot Studio 两种部署路径，以及在 Microsoft 365 Copilot 中选择 Genie 的方式。
• **Microsoft Learn：Databricks Genie on Microsoft 365 Copilot：**说明 Azure Databricks 与 Microsoft 365 Copilot 的连接、安装和使用流程。
• **Databricks 官方博客《Use Genie Everywhere with Enterprise OAuth》：**说明企业 OAuth、Teams、Copilot Studio、SDK 与自定义应用中的身份和权限治理方式。
• **36氪 7 月 23 日快讯：**转述 Databricks 与微软延长战略合作及扩大 Azure 投入的最新消息。

ActiveVision 最新测试显示，GPT-5.5 得分仅为 10.6%，远低于人类的 96.1%。模型能识图、写代码，却仍难以在变化环境中持续观察并主动操作。

GPT-5.5 在主动视觉测试中只拿到 10.6%

GPT-5.5 在新基准 ActiveVision 上只解决了 10.6% 的测试项目，并在 17 项任务中的 11 项得分为零。同期参与评测的 Claude Fable 5 得分更低，仅为 3.5%；三名人类参与者的平均成绩则达到 96.1%。

这组结果来自本周公开的预印本论文，论文编号为 arXiv:2607.16165。研究者使用了 GPT-5.5 对外开放的最高推理强度档位，但它与人类之间依然相差 85.5 个百分点；按得分比例计算，人类成绩约为 GPT-5.5 的 9.1 倍。

ActiveVision 是一套测试模型能否通过反复观察、判断和操作完成视觉任务的基准，而不是让模型对一张静态图片做一次性描述。它包含 17 项任务，分属 3 个类别，设计目标是迫使模型持续获取新的视觉信息，而不能只靠第一眼生成答案。

| 参与者或模型 | ActiveVision 得分 | 零分任务 | 与人类差距 | |—|—:|—:|—:| | GPT-5.5（最高公开推理强度） | 10.6% | 11/17 | 85.5 个百分点 | | Claude Fable 5 | 3.5% | 论文摘要未单列 | 92.6 个百分点 | | 人类参与者（3 人平均） | 96.1% | 未披露 | — |

GPT-5.5 虽然比 Claude Fable 5 高出 7.1 个百分点，得分约为后者的 3 倍，但这并不意味着它已经接近可用。10.6% 在真实产品里意味着绝大多数操作链都会中途失败，而 11 项任务直接归零，则说明模型面对的不是偶发识别错误，而是一整类能力缺失。

ActiveVision 测的不是“看图答题”

主动视觉是智能体根据当前观察主动选择下一步动作，并利用动作带来的新画面继续推理的能力。它与传统视觉问答最大的区别在于，输入不是固定的：模型点击、移动、缩放或改变视角之后，环境会发生变化，模型必须重新确认状态。

传统多模态评测更像把一张卷子拍下来交给模型，而 ActiveVision 更像让模型坐到电脑前亲自完成任务。前者只需要把图像压缩成一次性的语义表示，后者则要求模型循环执行“观察—形成假设—采取动作—检查结果—修正计划”。

这个差别看起来只是多了几轮交互，实际却把错误来源成倍放大。一条包含 10 个步骤的操作链，即使模型每一步成功率都有 90%，整条链全部正确的概率也只有约 34.9%；如果单步可靠性降至 80%，最终成功率会跌到约 10.7%，恰好接近 GPT-5.5 此次的整体成绩。

ActiveVision 因此暴露的是系统级可靠性，而不只是单张图片的识别准确率。模型可能第一步看对了按钮，第二步却没有确认点击是否生效；也可能正确识别局部元素，却忘记当前任务进行到了哪里；还可能在操作失败后继续沿用旧状态推理，最终让整条行动链偏离目标。

同一个 GPT-5.5，静态视觉能拿 76.12%

GPT-5.5 的低分不能简单归结为视觉编码器太弱，因为它在静态视觉测试中的表现并不差。Roboflow 公布的第三方 Vision Evals 显示，GPT-5.5 综合准确率为 76.12%，在 63 个参评模型中排名第四。

| 测试项目 | GPT-5.5 成绩 | 主要考察能力 | |—|—:|—| | Roboflow Vision Evals 综合成绩 | 76.12% | 静态图像理解与视觉问答 | | 文档理解 | 88.9% | OCR、版面结构和文字关系 | | 缺陷检测 | 86.7% | 发现图像中的异常区域 | | 对象理解 | 85.7% | 识别物体及其语义属性 | | 精确计数 | 30.0% | 对重复目标进行准确计数 | | ActiveVision | 10.6% | 反复观察、操作与状态更新 |

这两组成绩并不矛盾，反而清楚展示了前沿模型能力的“锯齿状边界”。GPT-5.5 可以读懂复杂文档、判断物体属性，也能在缺陷检测任务中取得 86.7%，但一旦视觉信息需要随着动作持续更新，它的能力就从 70%—80% 档位跌到 10.6%。

第三方分析认为，GPT-5.5 采用了基于 32×32 patch 的视觉编码方式，这有利于处理高分辨率文档、图表和结构化布局。Patch 可以理解为模型观察图片时使用的小方格：图片先被切成网格，再转换为视觉 token 进入模型。它能帮助模型“读懂画面”，却不会自动赋予模型稳定的行动闭环。

精确计数只有 30% 也是同一种问题的较轻版本。模型可以知道画面里有很多相似物体，却容易重复计算、遗漏目标或失去空间对应关系；在主动操作里，这种空间追踪误差还会与历史状态、动作反馈和任务目标叠加，最终形成连续失败。

会写代码，也没有补上视觉闭环

ActiveVision 最值得关注的发现不是前沿模型又输掉了一次新跑分，而是模型无法靠自己写代码修补能力缺口。论文专门观察了模型能否生成辅助程序来完成任务，但代码能力没有顺利转化为主动视觉能力。

这对 GPT-5.5 尤其刺眼，因为编码和智能体执行正是它这一代的主打方向。公开数据中，GPT-5.5 在 Terminal-Bench 2.0 上达到 82.7%，比 GPT-5.4 提高 7.6 个百分点；BrowseComp 成绩为 84.4%，提高 1.7 个百分点。GPT-5.5 Pro 在 BrowseComp 上还可以达到 90.1%。

| 基准 | GPT-5.5 成绩 | 任务性质 | 能否直接代表主动视觉 | |—|—:|—|—| | Terminal-Bench 2.0 | 82.7% | 终端环境中的编码与执行 | 不能 | | BrowseComp | 84.4% | 浏览、检索与信息整合 | 不能 | | GPT-5.5 Pro BrowseComp | 90.1% | 更高强度的浏览推理 | 不能 | | ActiveVision | 10.6% | 视觉反馈驱动的连续操作 | 可以直接衡量 |

代码不能救场的原因并不神秘：程序可以放大、裁切、标记和比较图像，却不能替模型决定什么时候应该重新观察，也不能保证模型正确理解程序输出。只要模型对环境状态的表征已经错了，它就可能写出逻辑正确但输入错误的工具，然后更自信地沿着错误路径前进。

主动视觉真正缺少的是“感知策略”，而不是另一个图像处理函数。一个可靠智能体需要知道当前证据是否充分、某次点击有没有成功、界面是否发生了预期变化，以及什么时候应该放弃原计划重新定位目标。这些判断无法靠一次代码生成完成。

高推理强度为什么仍然不够

增加推理 token 主要改善的是模型在已有信息上的搜索深度，却无法保证它主动获得了正确的新信息。模型如果从第一帧就误认目标位置，后续再长的思维链也可能只是在错误地图上做更复杂的规划。

视觉行动任务至少同时依赖四层能力：

1. 视觉定位能力：准确找到目标元素，而不只是说出画面中“存在一个按钮”。
2. 状态记忆能力：记住已经执行的动作、当前进度与环境变化。
3. 反馈校验能力：每次操作后确认结果，而不是默认动作已经成功。
4. 恢复规划能力：发现界面不符合预期时回退、重试或更换策略。

任何一层出现短板，都会让高推理强度失去意义。当前模型常见的工作方式是先根据首帧形成一个完整计划，再连续执行多个动作；人类则更倾向于每做一步就扫一眼界面，用低成本反馈修正下一步。后者看起来没有长篇推理，实际却拥有更密集的闭环校验。

人类 96.1% 的成绩说明这些任务并非依靠冷门知识或超人视觉才能完成。尽管只有 3 名人类参与者，样本规模不足以代表完整人群分布，但接近满分的平均结果仍足以表明：ActiveVision 的主要难点来自模型架构和交互策略，而不是任务本身含糊不清。

10.6% 对视觉智能体意味着什么

ActiveVision 的结果直接给“截图驱动型智能体”泼了一盆冷水。只要产品需要模型根据连续截图控制桌面软件、网页、工业界面或远程设备，静态视觉问答跑分就不能作为可靠性的替代指标。

浏览器智能体可能因为 DOM 和无障碍树而显得比纯视觉智能体成熟。结构化页面会直接告诉模型某个元素是按钮、输入框还是链接，相当于给它一份机器可读的地图；ActiveVision 这类任务则更接近只给截图，让模型自己完成定位和状态跟踪，难度自然更高。

机器人场景面临的风险还会进一步放大。网页点错按钮通常可以撤销，但机械臂抓错位置、移动设备误判障碍物或工业系统重复执行指令，都可能产生物理成本。10.6% 的成功率意味着这类模型目前更适合作为建议者和异常提示器，而不是脱离监督的最终执行者。

现阶段更现实的产品路线是限制动作空间，并给视觉模型加上外部校验。开发者可以让模型每次只选择少量预定义动作，要求关键操作前后保存截图，对高风险步骤使用传统视觉算法或规则系统复核，并在状态变化不明确时强制停止，而不是让模型凭自然语言计划一路执行到底。

GPT-5.5 仍然强，但强得并不均匀

GPT-5.5 不是一款视觉能力差的模型，而是一款在视觉语义理解和视觉行动之间存在巨大断层的模型。它在文档、对象和缺陷理解上表现靠前，在终端编码与网页研究中也有领先成绩，但这些能力尚未组合成稳定的主动操作系统。

这种断层也解释了为什么演示视频常常比真实部署更惊艳。演示可以挑选成功路径、固定窗口尺寸并避免意外弹窗，生产环境却会出现加载延迟、遮挡、动画、焦点丢失和状态不同步；模型只要漏掉一次反馈，后续步骤就可能全部失效。

价格同样会放大这一问题。GPT-5.5 的公开价格为每百万输入 token 5 美元、每百万输出 token 30 美元，上下文窗口为 100 万 token；GPT-5.5 Pro 则分别达到 30 美元和 180 美元。主动视觉需要重复上传画面并进行多轮推理，如果成功率仍只有 10.6%，更高推理预算很容易变成昂贵的重复试错。

| 模型 | 输入价格 | 输出价格 | 上下文窗口 | ActiveVision 已披露成绩 | |—|—:|—:|—:|—:| | GPT-5.5 | 5 美元/百万 token | 30 美元/百万 token | 100 万 token | 10.6% | | GPT-5.5 Pro | 30 美元/百万 token | 180 美元/百万 token | 公开信息未在论文摘要中对应说明 | 未单列 |

ActiveVision 的价值正在于把“会看”和“会做”拆开评估。模型读懂一张截图，并不等于它能在十张连续截图中保持同一目标；模型会生成自动化脚本，也不等于它能判断脚本何时失效。对开发者而言，这比又一个综合多模态分数更接近真实产品问题。

真正的突破要看闭环成功率

下一代视觉智能体的关键指标不应只是单帧准确率，而应包括长链任务成功率、动作后复核率、错误恢复率和平均无故障步数。只有这些指标同步提高，模型才可能从“能解释界面”走向“能可靠操作界面”。

GPT-5.5 的 10.6% 也不意味着主动视觉没有进展空间。模型厂商可以引入更细粒度的视觉记忆、显式状态表示、动作前后差分检测，以及针对失败恢复的强化学习；基准设计者则需要继续区分识别错误、动作错误、记忆错误和恢复失败，避免把所有问题压成一个总分。

目前最稳妥的结论是：GPT-5.5 已经是强大的静态视觉理解模型和编码模型，但还不是可靠的视觉操作模型。它看得懂很多东西，也能写出复杂程序；真正困难的是让它在每一次动作之后重新看清现实，并承认现实可能没有按计划发展。