实测腾讯Marvis：它真是新一代Agent OS？

Daniel 2026-05-29 11:32 美国

OS 到底意味着什么？

作者: Daniel
编辑: Koji
排版: NCon

贴上“Agent OS”标签的产品，最近像雨后春笋一样往外冒。掰着手指头数一数，市面上至少有五种截然不同的东西都叫这个名字：有给普通人用的桌面 AI 助手，比如 Marvis 和阶跃 AI 桌面伙伴；有给开发者搭建 Agent 的平台，像 CREAO、Dreamer；还有为 Agent 重新设计接口的云服务器系统，比如阿里云那个 Agentic OS；更有 AI 伴侣方向的 ColaOS，以及试图让“软件的第一用户从人变成 Agent”的 remio rOS。

同一个词，至少五种完全不同的含义。这本身就挺有意思的。

5 月 20 日，腾讯 PCG 应用宝团队推出的 Marvis，把自己定位成“操作系统层级 AI 助手”。它的架构很清晰：一个 Marvis Agent 做总调度，底下五个子 Agent 分别管文件、系统操作、应用操控、浏览器和搜索。每天还送 1000 万免费 Token，支持 Windows、Mac 和 Android。

听起来确实很厉害。但问题是，“OS 级”这三个字到底意味着什么？带着这个疑问，我们对 Marvis 做了一轮完整的实测，想看看那个可爱的小马工作台动画背后，每个子 Agent 究竟在用哪些技术完成任务，它和那些没踏入 OS 战场的 Agent 产品，比如 Claude Code，到底有什么本质区别。

子 Agent 实测

1. Computer Agent：依靠丝滑的预建工具

我们先给了 Computer Agent 两个系统操作任务。

任务一：调快触控板跟踪速度。

这个任务在导航栏下面就有示例。Computer Agent 调用了一个叫 mcp_mactools_input_device 的预建 MCP 工具，一步完成。整个过程不到 3 秒，没有试错，没有语法修正，最后还会弹出一个确认的 UI，不会贸然动手。

值得留意的是，任何任务都会先由 Marvis 这个总调度决定由谁来执行，最后再统一由它审核并返回结果。Marvis 的价值在这里就体现出来了：用户只需要说“调快触控板”，LLM 直接就匹配到这个工具，用户完全不需要知道任何终端命令，极致便捷。

任务二：关闭今天没有活跃过的应用程序。

这个任务就没有对应的预建工具了。Computer Agent 开始用 shell 命令自己探索：先试 find -newer 检查文件时间戳，不行；再试 lsappinfo，有点犹豫；想用 sfltool，又放弃了；最终试了 mdls 查 kMDItemLastUsedDate 才找到方法。

打开工作日志一看，每一条命令——lsappinfo、mdls、find、ps、osascript——都是标准的 macOS CLI 工具。换了任何一个通用 Agent，在终端里跑同样的命令，确实能做完全一样的事。

对照结论很清晰：Computer Agent 的可靠性，完全取决于有没有预建 MCP 工具覆盖这个场景。有工具，一步到位，极其丝滑便捷；没工具，退化为 LLM 临场写 shell 脚本。 不过，这个设计确实大幅降低了大部分用户使用 Agent 操作电脑的成本，这毫无疑问是产品上的创新。

2. App Agent：Agent 和 OS 之间的根本冲突

任务：用 Apple Music 播放巴赫 Top Songs 里排名第一的歌曲。

这个任务测试的是 App Agent 操控本地应用的能力。执行链路是这样的：

1. App Agent 加载 mac-desktop-ops skill
2. query apps 查到 Apple Music 的 bundle ID
3. launch app 启动 Apple Music
4. list windows 获取窗口信息
5. dump_ui 尝试读取 UI 结构 → 调用失败
6. capture window 尝试截屏 → 调用失败
7. App Agent 放弃，交回给 Marvis

Marvis 接手后改派 Computer Agent，用 AppleScript 尝试。AppleScript 能打开搜索、输入“Bach”，但卡在了无法点下那个 Bach 按钮，导航到搜索结果页面里的艺人条目。原因是 Apple Music 的 scripting 字典只支持操作本地曲库，不支持浏览在线目录。

Computer Agent 反复尝试了 URL scheme、键盘导航、AppleScript UI scripting，最终也没能完成任务。

dump_ui 失败的原因很直接：它尝试读取 Apple Music 的 Accessibility（macOS 的 AXUIElement API），但 Apple Music 对第三方 Accessibility 访问支持有限。而 capture window 失败，则是因为 Apple Music 涉及 DRM 内容保护，会主动屏蔽截屏。

作为对照，我用 Claude Code 做了同样的任务。Claude Code 直接走 AppleScript 路径，最终也卡在同一个地方：System Events 的 keystroke 注入被 macOS 拒绝。

两个产品撞的是同一面墙：macOS 的 TCC 安全机制。 这个机制的设计意图很清楚，就是阻止第三方程序自动操控其他 app 的 GUI。

Marvis 虽然自称“OS 级”，但在 macOS 看来，它就是一个普通的第三方 app。 真正不受限的，只有 Apple 自己的系统进程。

对照任务：在 Calendar 和 Reminders 里设置每周五 18:00 提醒。

这个任务，Computer Agent 用 AppleScript 顺利完成了。原因也很简单：Calendar 和 Reminders 有完善的 AppleScript 字典，直接暴露了创建、修改、删除事件的接口。

两个 case 形成了鲜明的对照：Marvis 能做什么，完全取决于目标 app 是否暴露了 scripting 接口。 暴露了就能做，没暴露就只能走 GUI。这个边界由 Apple 决定。而上一个时代，面向用户的操作系统，其实主要在做三件事：硬件资源分配、程序隔离和 I/O 通道。

macOS 每一代都在收紧权限：沙盒、SIP、公证制度、TCC 权限弹窗……本质原因就是，OS 的安全模型假设“程序是不可信的”，自动化能力被视为攻击面。

3. Browser Agent：技术路径最成熟的一个

任务：去 12306 查 6 月 1 日北京到上海最早的高铁几点出发。

Browser Agent 打开了一个可视化的 Chromium 浏览器窗口，通过 Chrome DevTools Protocol 直接操控 DOM。从工作日志可以看到，它在用 Ja vaScript 检查表单值、设置车站代码、用 eval 点击按钮，最终成功返回结果。

这是 Marvis 所有 Agent 里技术路径最成熟的一个。 原因也很直接：浏览器本身已经提供了结构化的程序接口。App Agent 在 macOS 原生应用上没有这样的接口可用，而 Browser Agent 是站在 Playwright 和 CDP 这个已经被业界验证多年的生态上的。

我用 Claude Code 配合 Chrome DevTools MCP server 做了同样的任务，操作方式完全一样。Marvis 的差异化在于：用户不需要自己安装 Playwright 或配置 MCP，说一句“查 12306”就直接打开浏览器开始操控，又一次大幅降低了使用成本。

Marvis 的并行调度能力

Marvis 的卖点，除了子 Agent 进行了能力预装，提升了使用丝滑度，另一个就是父-子 Agent 的架构。

我们测试了两个需要多 Agent 协作的任务，想看看 Marvis 作为总调度 Agent，能否准确地分配任务、进行 Agent 间通信，以及并行调度不同的子 Agent。

任务一： 搜索 6 月 1 日北京天气预报，整理成 markdown 文档保存到桌面，然后在日历里创建当天提醒“带伞”。

Marvis 的执行策略很有章法：先让 Search Agent 查天气——后续步骤依赖这个结果——然后并行派发 File Agent 写文档和 Computer Agent 创日历事件。任务规划完全正确，两个后续任务确实同时开始执行，大概 10 秒就完成了。

任务二： 去京东搜索 AirPods Pro，把前 3 个结果的名称和价格整理成表格，保存为 Excel 到桌面，然后设明天的提醒让我比价。

Marvis 同样做了依赖分析：先让 Browser Agent 抓取数据——这个任务耗时较长，还遇到了反爬和登录墙——拿到结果后并行派发 File Agent 用 Python 生成 Excel 和 Computer Agent 设提醒。

遇到需要登录验证时，会弹出清晰易懂的选项卡让用户协助。用户提交后，Agent 进程没有中断，正常执行完毕。

两个 case 都顺利完成。Marvis 展示了依赖识别和并行调度能力：知道哪些步骤有先后依赖，哪些可以同时进行。 Agent 之间的信息传递也没有断裂，Search 和 Browser 的结果被正确传给了后续 Agent。

这里值得单独说一下 Marvis 的多 Agent 调度策略。目前大部分 Agent 同样支持并行子任务调度，但很多时候需要用户在显式描述任务拆分逻辑。Marvis 把这一步完全接管了：用户只说一句自然语言目标，总调度 Agent 自动做依赖分析、决定串行还是并行、分配给对应的子 Agent，全程无需用户干预执行顺序。

产品体验上打磨得相当不错，从“用户编排任务”变成了“用户只描述目标”。遇到的 bad case，主要是模型能力的问题。

所有实测的技术栈汇总

Agent OS 应该是什么样的？

把 Marvis 做的事拆开来看，其实不复杂：预配置的 MCP 工具、AppleScript/CDP、多 Agent 路由，再加上一套精心设计的 UI 和产品交互。

体验确实很丝滑，这些组合在一起是一个好产品。不过，它在技术上并没有超出“CLI + GUI Agent + 浏览器自动化”这个已知范畴。

那“OS”这个词到底指什么？

我们仔细想一想，传统 OS 管理的对象是进程、窗口、权限、通知。如果 Agent 时代有一个真正的 OS，那么它管理的对象应该完全不同：

• 任务——有状态机、有目标、可恢复、可取消、可审计
• 上下文——用户当前状态、历史偏好、跨 app 的工作记忆
• 能力——app 不再作为前台入口，而是作为后台能力提供者
• 授权——按任务临时授予权限，任务结束即收回
• 任务流——把碎片事件组织成可执行目标，取代通知中心

按这个标准来看，Marvis 做到了“任务拆解和调度”这一层，但还差得远：它没有做到“任务状态管理”——不能暂停、恢复、回滚一个进行中的任务；没有做到“按任务授权”——还是传统的按 app 授予；也没有做到“把 app 变成能力提供者”——它依然在 hack 现有 app 的 GUI，而不是 app 主动暴露能力接口。

更根本的问题是：Marvis 跑在 macOS 和 Windows 上面，它是 OS 的用户，受 OS 的权限限制。

结论

Marvis 是一个做得不错的桌面 Agent 产品。它对普通用户的价值是真实的：零配置，说人话就能操控电脑，不需要自己装 Playwright，也不需要知道 AppleScript 语法。预建 MCP 工具库的覆盖面越大，这个产品的体验就越好。

但现在市面上所有这些“Agent OS”产品，和 OS 之间其实都隔着一个身份问题：

想当 OS，但跑在别人的 OS 上面。

能做出真正 Agent OS 的角色，想来无非四种：拥有操作系统的平台方，比如 Apple、Google、Microsoft 以及各大手机厂商；从头做新设备的人，为 AI 硬件设计新的操作系统；微信——它的小程序生态已经让微信本身成为了一个类 OS 的存在；以及那些在内核层就为 Agent 重新设计接口的人。

期待 Agent 的 Android 时代到来。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：实测腾讯Marvis：它真是新一代Agent OS？要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题