Gemini Spark、ChatGPT Work、Claude Cowork，是三大 AI 巨头给出的版本答案；而AI新贵 Muse AI 和 Grok Bot，则从“给 Agent 一台电脑”开始。两条路线正在汇合，而真正卡住所有人的，是权限。

2026 年，AI 产品竞争的重点正在从模型本身往执行层移动。

过去几年，行业习惯用 Benchmark、上下文长度、Coding 能力和推理表现来判断一家 AI 公司有没有领先。现在这些指标仍然重要，但 Google、OpenAI、Anthropic、Meta 和 xAI 最近推出的产品，已经把问题往前推了一步：模型如果足够聪明，下一步该给它什么？

Google 的答案是 Gemini Spark，OpenAI 有 ChatGPT Work，Anthropic 把 Claude Code 的能力扩展到了 Claude Cowork。另一边，Meta 做出了 Muse AI，xAI 推出了 Grok Bot。

它们面对的是同一个目标：让 AI 不只回答问题，而是接手工作。分歧出现在“从哪里开始”。

Google、OpenAI 和 Anthropic 都有一个已经被大量用户接受的 AI 助手，因此它们的路径很自然：先让助手读文件、接应用，再逐步加入浏览器、定时任务、事件触发和 Computer Use。Muse 和 Grok Bot 则省掉了这层演进，直接把 Agent 放进一台可以长期存在的电脑里。

前者更像是在给助手增加权限，后者则先准备好一个工作环境，再讨论边界应该画在哪里。

这两种思路看上去相距很远，但把最近几个月的产品变化放在一起，会发现它们正在靠近。ChatGPT Work 已经有 Cloud Browser，Claude Cowork 背后本来就用了完整的虚拟机隔离，Spark 也不再只是一个聊天窗口。与此同时，Muse 和 Grok Bot 也不可能永远依赖鼠标和网页操作，稳定的 API、Connector、Skill 仍然是效率更高的选择。

行业最后正在收敛到同一批基础能力：Workspace、Memory、Skills、Browser、Computer、Automations、Triggers，以及一套能约束这些能力的权限系统。

这也是为什么 OpenClaw 值得重新拿出来看。

它未必会成为最终赢家，但它很早就把这些东西放在了同一个 Agent 世界里。

三大模型厂商的答案：先从“助手”往外长

Google 是这里最特殊的一家，因为它不缺用户上下文。

Gmail、Calendar、Drive、Docs、Sheets、Keep、Tasks，再加上 Search、Maps、YouTube，已经覆盖了大量个人和工作场景。Spark 因此没有必要先模拟一个人坐在电脑前逐个打开这些应用，它更自然的做法，是直接站在 Google Account 这一层组织任务。

Spark 把 Task、Schedule 和 Skill 放到了很重要的位置。任务负责定义要做什么，Schedule 决定什么时候运行，Skill 则保存处理方式。变化不只在于 Gemini 会做更多事，而在于 AI 被启动的方式发生了变化。

以前用户必须先打开对话框。Spark 可以按照时间、条件或外部事件开始工作。比如每天早上整理邮件和日历，或者在某类邮件出现后启动固定流程。这里最重要的不是自动化本身，而是 Agent 不再完全依赖 Prompt 才开始行动。

OpenAI 的处境不同。它没有 Gmail，也没有 Drive，所以 ChatGPT Work 的路线更像是在 ChatGPT 周围重新搭一个工作入口。

Gmail、Slack、GitHub、Google Drive 和其他企业 SaaS 被接进来之后，ChatGPT 可以跨应用查资料、处理文件，再把结果做成文档、表格或演示。事件触发也已经进入这套体系：新邮件、Slack 消息或 GitHub PR，都可以成为任务的起点。

如果产品停在这里，Work 仍然是一套以 Connector 为中心的 Agent。但 OpenAI 又补上了 Cloud Browser。Agent 可以在独立的云端环境里访问网页、点击按钮、填写表单，用户离开电脑以后任务也可以继续。这一步很关键，因为它承认了一个现实：再完整的 Connector 体系，也覆盖不了所有软件。

Anthropic 的路径更像一个中间态。

Cowork 不是简单给 Claude 增加几个办公插件，它更接近把 Claude Code 的 Agent Harness 搬进普通知识工作。Claude Code 已经让开发者习惯把一个真实目录交给 Agent，让它读文件、改代码、运行工具并连续工作。Cowork 把这个工作方式扩展到了文档、邮件、Slack、浏览器、Skills 和 Scheduled Tasks。

Anthropic 披露过 Cowork 早期的隔离方式：Agent 运行在一个完整的虚拟机中，有独立的 Linux Kernel、Filesystem 和 Process Table，用户授权的 Workspace 被挂载进去，其他宿主机内容留在边界之外。

这让 Cowork 很难被简单归到“应用型 Agent”一边。它已经有相当明确的 Computer-native 特征。

如果说 Spark 是从账号出发，Work 是从 ChatGPT 出发，那么 Cowork 更像从 Workspace 出发。三家公司走的并不是同一条技术路线，但它们有一个共同点：都是在原有助手的基础上逐步增加行动能力。

Muse 和 Grok Bot：先把电脑给 Agent

Meta 和 xAI 的产品选择更直接。

Meta 对 Muse 的官方描述里有一句很关键的话：

A secure computer with its own browser.

它的 Secure VM 是一个持续存在的独立环境，Agent 可以在里面使用浏览器、访问网站、填写表单和处理任务。产品首先解决的是“Agent 在哪里工作”，而不是“这个网站有没有为 Agent 准备接口”。

这和人类使用电脑的方式很接近。现实中的员工不会因为一个供应商后台没有 API 就停止工作，他会打开网页。Computer Use 的价值也在这里：它不是最高效的工具，却是最后还能处理事情的通用入口。

Grok Bot 把这个思路说得更直白：

Grok Bot is an agent with a computer.

它的 Cloud Computer 里有 Desktop、Filesystem、Terminal、Browser 和 Apps，环境可以持续存在。浏览器 Session、文件和工具不必随着一次对话结束而全部消失，任务也可以在用户自己的电脑关闭之后继续执行。

这和传统聊天产品的差别，不只是多了一个 Computer Use 按钮。

传统路径是先定义一个 Assistant，再决定给它开放哪些工具。Grok Bot 的产品前提更接近：Agent 本来就生活在一个工作环境里，权限系统负责限制它能走多远。

这里所谓“AI 新贵”，指的不是 Meta 或 xAI 的公司体量，而是它们在这一轮 Personal Agent 产品形态中的角色。相比从 Chatbot 演进过来的产品，它们更容易从第一天就告诉用户：这个东西会自己行动，会使用浏览器，也会在后台继续工作。

这种用户契约不一样。

两条路线正在失去边界

如果把这五个产品静态放进一个表格，很容易得到一个整齐的结论：Spark、Work、Cowork 属于应用和工作流路线，Muse、Grok Bot 属于 Computer-native 路线。

现实没有这么干净。

ChatGPT Work 已经在补 Browser 和云端执行环境；Cowork 从一开始就依赖 VM 和 Workspace 隔离。另一边，Muse 和 Grok Bot 也不可能什么事情都靠视觉和鼠标来完成。结构化接口只要稳定，就会比 GUI 操作更便宜、更快，也更容易审计。

所以真正的分歧不是“API 还是电脑”。

成熟的 Agent 两种能力都会需要。API 和 Connector 负责高频、结构化的工作，Browser 和 Computer 负责那些没有接口、接口不完整或者临时出现的场景。

从这个角度看，五家公司不是走向不同终点，而是从不同位置往中间靠。

而中间那个形态，恰好和 OpenClaw 很像。

OpenClaw早就把这些东西放在了一起

重新看 OpenClaw，会发现它最有价值的地方并不是某一项能力做得特别先进，而是它很早就把 Agent 所需的几个部分放进了同一套运行方式里。

Agent 有自己的 Workspace，可以保存文件、上下文和长期状态；Skills 用来沉淀工作方法；Browser 和 Computer Use 负责连接真实软件；Gateway 保持 Session 和状态；Automations 与 Triggers 让任务在没有新 Prompt 的情况下也能被重新唤醒。

这些概念今天分别出现在 Spark、Work、Cowork、Muse 和 Grok Bot 中，只是名字和产品包装不同。

这并不能证明几家大厂是在照着 OpenClaw 做。更合理的解释是，它们独立解决同一个问题以后，开始碰到相似的工程约束。

一个 Agent 如果要长期工作，就需要地方保存状态；如果要重复完成工作，就需要可复用的 Skill；如果要覆盖没有 API 的软件，就需要 Browser 或 Computer；如果不能一直等用户发消息，就需要 Schedule 和 Trigger。

当问题相同，最后出现相似的基础组件并不奇怪。

所以“OpenClaw 没死”并不是一句开源情怀式判断。真正值得讨论的是，它代表的那种 Agent 抽象正在变得主流：模型只是其中一部分，Agent 还需要运行环境、记忆、工具和自动化。

但当这些能力越来越完整，另一个问题马上变得比模型能力更棘手。

权限。

权限开始决定 Agent 能不能真正干活

聊天机器人答错一次，损失通常有限。Agent 如果有权发邮件、删文件、修改代码、操作 CRM、购买商品或者管理服务器，错误会直接变成动作。

这也是为什么 Agent 能力越往前走，安全问题反而越具体。

Google 面对的是 Gmail、Drive 和 Calendar 里真实存在多年的用户资产；OpenAI 的 Work 正在进入企业应用和组织数据；Cowork 需要触碰公司文件和业务流程。对这些公司来说，产品设计不能只看“能不能做”，还要同时考虑授权、审计、撤销、管理员策略和责任归属。

这些要求叠加起来，就形成了所谓的“合规围栏”。

围栏当然有必要。没有清晰的权限和审计机制，大型企业根本不会让 Agent 进入生产环境。但围栏也会制造另一种问题：模型已经有能力连续完成一段工作，产品却频繁把它停下来，让用户确认下一步。

Anthropic 自己公布过一组很能说明问题的数据。

Claude Code 早期遇到修改文件、运行命令等操作时，会大量弹出权限请求。后来他们发现，用户大约批准了 93% 的请求。确认框出现得太频繁以后，人不会越来越谨慎，反而容易形成操作惯性。

这就是 Approval Fatigue。

Anthropic 后来的方向不是继续增加确认步骤，而是把更多工作放进明确的 Sandbox 和 Workspace 边界中。只要 Agent 还在授权范围内，就让它连续执行；真正越界时，由系统层挡住。按照 Anthropic 披露的数据，这种调整让 Permission Prompt 减少了大约 84%。

这组数字比“安全优先”这样的口号更具体。它说明 Agent 时代的权限设计，很可能不会继续沿用传统软件里“每个敏感动作弹一次窗”的思路。

更有效的办法，是提前限定 Agent 能触碰的范围。

“合规围栏”和“主权下放”争的其实是默认权力

Muse 和 Grok Bot 也不是没有安全措施。Computer-native 并不等于无限权限。

差别更多体现在产品默认值上。

从传统大厂的路径看，平台通常先定义一个较低的权限上限，再随着产品成熟逐步开放。用户得到的是一组已经被筛选过的能力。

Computer-native 产品则更愿意把选择往用户这一侧推：Agent 已经有自己的电脑、浏览器和文件环境，平台负责提供隔离、审批、凭据保护和审计，用户再决定这个环境究竟开放到什么程度。

可以把这种思路理解成“Agent 主权下放”。

这里的“主权”不是让用户把 Root 权限一股脑交给模型，而是把“我的 Agent 应该拥有多少行动能力”更多交还给用户决定。

这和平台统一替所有人设定一个很低的权限上限，是两种不同的产品哲学。

OpenClaw 从一开始就站得更靠近后一边。它默认这是用户自己的 Agent：跑在哪里、用什么模型、加载哪些 Skill、访问哪些文件、什么时候自动运行，都由用户自己配置。

这套设计当然更适合愿意承担配置成本和风险的人，而不是所有普通消费者。但它把一个问题提得很早：如果 Agent 真的是用户的代理人，那么它的最终控制权应该属于谁？

大厂为什么更难放权

这也是三大模型厂商很难绕开的博弈。

任何一家率先大幅开放权限，都可能获得更流畅的 Agent 体验，但第一个严重事故也更可能发生在自己身上。越是拥有大量企业客户、用户数据和监管责任的公司，越难轻易接受这种风险。

所以“再谨慎一点”对单家公司来说往往是理性的。

多一个确认步骤，多一层管理员策略，晚一点开放自动执行，都能降低短期风险。

问题在于，如果所有厂商都选择同样的策略，用户最后得到的可能是一批非常聪明、却仍然不敢独立完成工作的 Agent。

而 Muse、Grok Bot 这类产品的价值，不一定在于它们今天已经把权限问题解决得更好，而在于它们愿意先把“拥有一台电脑的 Agent”这个形态推给普通用户，再围绕真实使用去调整边界。

如果这种模式被证明可行，其他厂商自然会跟进；如果事故频发，行业也会重新收紧。

所谓“权限的囚徒困局”，大致就发生在这里。大家都知道更完整的权限会带来更好的 Agent 体验，但谁先把门打开，谁就先承担出事的概率和责任。

还有一道更现实的墙：Agent 太贵了

权限并不是这类产品唯一的约束。最近几天我在使用 Muse 时，已经能明显感觉到它的可用性在下降。这个变化和 Muse 用户量快速增长发生在同一时间，但截至发稿，Meta 并没有公开确认两者之间存在直接因果关系，所以更准确的说法只能是：容量压力是一个很值得怀疑的因素，而不是已经被证实的结论。

已知的数据足以说明问题的规模。Muse 9 月 8 日首先在美国上线，随后扩展到加拿大；截至 9 月下旬，它仍然只在这两个市场正式开放。Apptopia 估算，Muse 上线前 12 天已经获得约 280 万次安装，其中美国和加拿大的 iOS 下载约 180 万次。对一个刚上线两周、区域范围还很有限的产品来说，这个增长速度已经足够快。TechCrunch 的报道也指出，Muse 当时只在美国和加拿大提供。

这里真正值得注意的不是下载榜，而是 Muse 的运行方式。Meta 官方把 Muse Secure VM 描述为一台 persistent、dedicated virtual machine，并明确说它带有自己的浏览器，可以在后台继续执行任务。这里的 dedicated VM 当然不能简单理解成“每个用户全天独占一台物理服务器”，底层完全可以通过挂起、恢复、共享 GPU 和调度来控制成本。但它仍然比一次请求、一次回复的 Chatbot 重得多。浏览器状态要保存，虚拟机环境要维护，长任务可能持续几分钟甚至几小时，Agent 还会在一个任务里反复调用模型、工具和网页。

Meta 自己也已经在产品层承认这种资源约束。Muse 的官方 FAQ 写得很直接：免费版有 usage limit，用完后要等额度刷新，或者升级付费方案。Meta 对 Muse Secure VM 和使用额度的说明把这一点写得很清楚。

放到 Meta 的资本开支里看，这个问题更有意思。Meta 2025 年的资本开支（包含融资租赁本金支付）是 722.2 亿美元；到 2026 年二季度，公司又把全年资本开支指引提高到 1300 亿至 1450 亿美元。如果 2026 年最终落在这个区间，两年合计就是大约 2022 亿至 2172 亿美元。Meta 2025 年全年财报和2026 年二季度财报都给出了这些数字。

这当然不是 Muse 的预算。Meta 的数据中心、训练集群、核心业务和 Superintelligence Labs 都在消耗这些资本开支。恰恰因为如此，这组数字才有参考意义：一家一年资本开支已经超过千亿美元的公司，面对“给每个普通用户一个可以长期工作的 Agent”这件事，仍然需要用区域开放、免费额度和订阅来控制使用强度。

Chatbot 和 Personal Agent 在基础设施上并不是同一道题。Chatbot 面对的是“几十亿人随时来问一个问题”；Muse、Grok Bot 这类产品想做的，则更接近“让每个人都养一个持续工作的 AI”。前者可以把大量请求做成相对短暂的推理任务，后者还要承担长期状态、浏览器、虚拟机、工具调用和后台任务带来的资源占用。

这给 Personal Agent 增加了第二个很现实的约束。第一道是权限：平台敢不敢让它做。第二道是成本：平台能不能让它一直做。

也正是在这里，OpenClaw 又显出一种和云端大厂完全不同的经济模型。它把 Agent 运行在用户自己的 Mac、PC 或服务器上时，不只是把权限主权交还给用户，也把一部分基础设施成本一起下放了。用户已经买过的电脑、NAS、家里的 Mac mini，或者一台便宜 VPS，都可以成为 Agent 的长期运行环境。平台不需要为每一个活跃用户维护一套持久云电脑。

这不意味着本地运行一定更便宜，也不意味着云端 Personal Agent 无法规模化。Meta、Google、OpenAI 拥有远比普通用户高效的数据中心和调度能力。但两种产品的成本结构确实不同：云端 Agent 越成功，平台承担的并发和运行成本越大；自托管 Agent 用户越多，更多成本会由用户自己的硬件和电力承担。

所以 OpenClaw 所谓的“主权”，最后并不只有权限这一层。它还包含了另一件很朴素的事情：谁来提供 Agent 生活的那台电脑，谁来支付它一直运行的成本。

最后的答案大概不是更多弹窗

从现在几家的产品方向看，成熟的 Personal Agent 很可能会拥有一个长期存在的工作环境，里面保存文件、浏览器状态、记忆和 Skills，也能按计划或外部事件启动任务。问题已经不只是怎样让它工作，还包括怎样控制权限，以及怎样负担一个长期运行环境的成本。

在权限这一侧，设计会越来越像操作系统，而不是聊天产品。

用户先决定 Agent 能访问哪些工作空间、账号和设备，系统负责把边界做硬。只要任务还在这个范围里，就尽量让 Agent 连续完成；涉及付款、删除关键资产、对外发送敏感信息等高风险操作时，再把决定交回人类。

这种做法没有消除风险，只是把风险从“每一步都要人判断”改成“先控制最大损失范围”。

Anthropic 使用的 Blast Radius 这个词很准确。

AI 犯错几乎不可能被彻底消灭。更现实的问题是，当它犯错时，最多能碰坏多少东西。

OpenClaw没死

回到标题，OpenClaw 是否会成为最大的 Personal Agent 产品，其实并不重要。

更值得看的，是今天几家大厂在补什么。

Spark 正在从 Google Account 里长出任务和自动化能力；ChatGPT Work 把 Connected Apps、事件触发和 Cloud Browser 放到一起；Cowork 把 Claude Code 的 Workspace 思路带到知识工作；Muse 和 Grok Bot 则直接从一台长期存在的电脑开始。

这些产品最后都需要解决同一组问题：状态怎么保存，工作方法怎么复用，没有 API 的软件怎么操作，任务怎么在用户没有发新消息时继续运行，Agent 到底能被授予多少权限，以及一套长期运行环境究竟由谁来买单。

OpenClaw 很早就把这些问题摆在了一起。

它真正留下来的未必是某个具体实现，而是一种关于 Agent 的理解：AI 如果要长期替人工作，就不能永远只是一个等待 Prompt 的聊天窗口。它需要一个可以持续存在的工作环境，也需要一套由用户掌握、由系统约束的权限边界。OpenClaw 的特殊之处还在于，它允许这个环境直接落在用户自己的机器上，于是权限、数据和一部分运行成本都留在了用户这一侧。

从这个意义上说，OpenClaw 确实没有死。

它提出的问题，已经变成了整个行业的问题；而它曾经显得很极客的那套答案，也正在一点点进入主流产品。