Google 为什么没有做出 Muse？

Why Didn’t Google Build Muse? — daringfireball.net · 2 小时前 · 💡 观点 / 杂谈

MG Siegler 在 Spyglass 上讨论 Meta 的 Muse 个人助理代理时，观察到两种典型反应：第一种是「我不会把数据交给 Meta」，第二种则更有意思——「为什么 Google 没做这个？」。他给出的短答案是：Google 大概率正在做；但长答案更有价值——Google 缺的是专注。Google 手里并不缺筹码：Gemini 系列模型、Android 与 Chrome 的分发、搜索、Workspace，以及 Project Astra 这类前沿研究，几乎每一项都是做个人助理代理的必需组件。问题在于这些能力散落在多个团队和产品线中：Google Assistant 向 Gemini 的迁移拖了很长时间，Gemini 应用、搜索里的 AI Mode、Android 上的助手入口、Workspace 的侧边栏助手各自为战，没有一个被明确定义为 Muse 那样的个人助理代理。于是当 Meta 用一个定位清晰的产品把个人助理代理这个概念具象化之后，公众的第一反应是问 Google 为什么没有先做出来，而不是问 Google 能不能做——这本身就是对 Google 组织执行力的一次评判。Siegler 的核心观点可以概括为：Google 的落后不是模型能力问题，而是产品聚焦与组织协同问题，在 AI 助手这个被认为最该由 Google 主导的赛道上，它反而把定义品类的机会让给了 Meta、OpenAI 和苹果。这个判断值得放在更长的历史里看：Google 曾经用 Google Now 和 Google Assistant 定义了上下文感知的个人助理，却在生成式 AI 到来后迟迟没有把助手升级为一个有记忆、能跨应用执行任务的代理；反观 Meta，把 Muse 直接摆在个人助理代理的位置上，即便面临数据信任的质疑，也成功占据了话题中心。对读者而言，这篇文章的价值不在于确认 Google 在做，而在于理解为什么一家拥有最强分发和最全组件的公司，会在一场自己发明的比赛里显得迟缓。

核心论点

Siegler 观察到的第一反应是「我不会把数据交给 Meta」，第二反应是「为什么 Google 没做这个」，他认为第二种反应更有意思也更能说明问题：前者只是对 Meta 数据政策的习惯性质疑，后者则隐含了一个前提——个人助理代理这个产品形态本应由 Google 率先做出来，因为 Google 拥有 Gemini 模型、Android 与 Chrome 的分发、搜索与 Workspace 的场景，以及 Project Astra 这类面向实时多模态代理的研究积累，缺的从来不是零件，而是把这些零件组装成一个有明确名字和定位的产品的决心。换句话说，公众的质疑对象已经从能力转向了意志。
Siegler 的短答案是 Google 显然在推进，长答案则是 Google 缺乏专注：它的 AI 助手能力分散在 Google Assistant 向 Gemini 的长期迁移、Gemini 独立应用、搜索中的 AI Mode、Android 系统级入口以及 Workspace 助手等多个方向上，每条线都有自己的路线图和负责人，却没有一条被明确定义为像 Meta Muse 那样的个人助理代理；这种分散让 Google 无法对外讲出一个单一、清晰的产品故事，用户也不知道该去哪里体验 Google 的 Muse。当组织内部的多个团队各自为战时，最容易被牺牲的恰恰是跨产品、跨应用、需要长期打磨的代理体验。
把 Meta、OpenAI、苹果和 Google 放在一起对比可以看出，Meta 用 Muse 抢占了个人助理代理的品类定义权，OpenAI 用 ChatGPT 的记忆与代理能力占住了通用入口，苹果则通过 Siri 的重做把助理绑定在系统与设备上；Google 拥有最强的分发和完整的模型栈，却在助手竞赛中表现得像一个追随者，这说明在 AI 时代，组织聚焦与产品决断力的权重可能不低于模型能力本身，这也是 Siegler 认为这个问题值得追问的真正原因。对做产品的人来说，这比单纯比较模型跑分更有参考价值。

💡 为什么值得读: 它用一个看似简单的问题，把 AI 助手竞赛从模型能力之争拉回到组织聚焦与产品决断力之争，适合任何想理解大公司为什么会在自己发明的赛道上落后的读者。

🏷️ Meta, Muse, Google, AI assistant