Rabbit 把 Agent 从 R1 里放出来了

Rabbit 正在推出 RabbitOS 3，这是一套无需 R1 硬件即可运行的独立 AI Agent 系统，支持 Windows、Mac 和 Linux。它的核心变化不是又增加了一个聊天入口，而是把 Rabbit 原本绑定在 R1 上的 Agent 能力，扩展成一个可以跨设备调度的云端操作层。

RabbitOS 3 是一个运行在云端、但能够调用本地设备资源完成任务的 Agent 系统。按照 Rabbit 的说法，用户可以把最多 5 台设备接入同一个账户，再为账户配置偏好的 AI 模型；系统会根据任务自动判断应该使用哪台设备、哪些文件、哪些应用，以及哪个模型。

这意味着，Rabbit 不再要求用户先购买一台 R1，才能进入它的 Agent 体系。对一家曾经因为 R1 受到大量质疑的创业公司来说，这次调整的意义比普通版本更新更大：Rabbit 正在把自己从“AI 硬件公司”改造成“跨设备 Agent 平台”。

OS3 到底是什么：不是桌面助手，而是设备调度层

RabbitOS 3 的核心定位，是位于用户、AI 模型和本地设备之间的“总 Agent”。它不只是回答问题，而是负责拆解任务、选择执行环境，并把结果交付给用户。

以一个看似简单的任务为例：用户要求“整理下载文件夹里的会议录音，转写内容，提取行动项，然后把结果发给团队”。传统聊天机器人最多只能生成一份处理建议，用户仍然需要自己找到录音、上传文件、等待转写，再复制结果到邮件或协作软件中。

OS3 试图把这些步骤串起来：

1. 在已连接的设备中找到包含录音文件的电脑；
2. 判断本地文件是否可以直接读取；
3. 选择适合转写和总结的 AI 模型；
4. 调用本地应用或浏览器完成后续操作；
5. 将处理结果返回给用户，或者继续执行发送、归档等动作。

这里最关键的不是模型本身，而是 Agent 能否同时看见多个执行环境。模型负责理解任务和规划步骤，设备节点负责访问本地文件、操作桌面应用，RabbitOS 3 则负责在两者之间做协调。

这与传统的“给每个软件加一个 AI 按钮”不同。后者的边界由应用决定，Agent 只能在当前应用里完成有限动作；OS3 的目标则是让用户直接描述结果，系统再决定应该跨哪些应用和设备完成任务。

接入方式很轻：一行命令把电脑变成 Node

RabbitOS 3 的设备接入方式也体现了它的产品取向。根据目前公开体验信息，用户可以在设置界面复制一行命令，将其粘贴到 Windows、Mac 或 Linux 的终端中，几秒钟内完成 Rabbit Agent 的安装和配置。

安装完成后，这台电脑不再只是运行 Rabbit 客户端的设备，而会成为 OS3 可以调用的一个 Node。Node 是 OS3 管理的本地执行节点，能够在获得授权后参与文件处理、应用操作和任务执行。

这个设计比单独安装一个桌面聊天软件更接近“轻量级控制层”。用户可以把家里的 Mac、办公室的 Windows 电脑，甚至一台 Linux 服务器接入同一个 Rabbit 账户。理想状态下，用户不需要记住文件在哪台机器上，也不需要反复切换不同系统，只需把任务交给 OS3。

不过，安装简单不等于权限问题已经解决。一个能够读取本地文件、调用应用、操作浏览器的 Agent，权限边界远比普通聊天机器人复杂。Rabbit 目前公开信息还没有完整披露不同操作系统下的权限模型、默认授权范围、操作确认机制，以及敏感文件如何隔离。

这将直接决定 OS3 是一个真正可用的生产力工具，还是一个只能在演示环境里工作的自动化玩具。

一个账户最多连接 5 台设备，但“多设备”不是全部

Rabbit 表示，OS3 一个账户最多可以添加 5 台设备，并支持配置用户偏好的 AI 模型。系统会自动判断任务所需的设备、文件、应用和模型。

这个设定解决的是 Agent 产品长期存在的一类问题：模型越来越多，工具越来越多，但用户必须自己决定“这个任务应该交给谁”。

例如，代码任务可能适合使用面向编程的模型，长文档总结可能需要长上下文模型，桌面控制则可能依赖具备视觉或计算机操作能力的 Agent。普通用户不应该被迫理解每个模型的上下文长度、工具调用能力和价格差异。OS3 的产品承诺，是把这些选择隐藏在任务背后。

| 对比维度 | RabbitOS 3 | Rabbit R1 | 传统聊天机器人 | 桌面自动化工具 | |---|---|---|---|---| | 是否依赖专用硬件 | 不依赖，可运行于 Windows、Mac、Linux | 依赖 R1 作为主要入口 | 通常不依赖专用硬件 | 通常依赖本地脚本或客户端 | | 任务入口 | 桌面站点、消息应用、R1 等 | R1 语音或文字交互 | 网页或 App 对话框 | 工作流编辑器、脚本或录制器 | | 可调用范围 | 多台设备、文件、应用和模型 | 以 R1 及已连接设备为中心 | 主要是模型和少量工具 | 取决于脚本权限和适配器 | | 设备数量 | 一个账户最多 5 台 | 以单台硬件为核心 | 通常不提供跨设备调度 | 视工具而定 | | 主要价值 | 统一调度不同执行环境 | 低门槛的 Agent 硬件入口 | 问答、生成和有限工具调用 | 重复流程自动化 | | 主要风险 | 权限、隐私、误操作和稳定性 | 硬件价值与实际能力不匹配 | 无法完成端到端任务 | 流程脆弱、维护成本高 |

从这个表格可以看出，OS3 真正想竞争的对象并不是某一个聊天机器人，而是“模型加工具加本地自动化”的组合。它试图把原本需要用户自己拼接的多 Agent、桌面自动化和设备管理，包装成一个统一入口。

Rabbit 为什么现在放弃“必须有 R1”

Rabbit 早期的产品逻辑很明确：通过 R1 这台价格相对低廉的专用硬件，掌握传感器、芯片、终端数据和交互入口，再把 Agent 能力放在云端运行。

这个思路有一个现实基础。手机和电脑的操作系统由 Apple、Google、微软等平台控制，创业公司很难直接获得足够深的系统权限。如果 Rabbit 只做一个 App，它的 Agent 可能无法稳定调用其他应用，也难以处理验证码、登录状态和本地设备权限。因此，R1 一度被视为 Rabbit 进入系统层的“侧门”。

但 R1 也暴露出明显问题：用户购买的是一台专用设备，却仍然需要依赖手机、电脑和网页完成大量实际任务；设备本身的硬件能力有限，Agent 的表现又高度依赖云端服务；当用户发现 R1 更像一个遥控器，而不是一个真正独立的计算终端时，硬件的必要性就开始下降。

OS3 的出现，等于 Rabbit 自己承认：真正有价值的不是那块橙色硬件，而是 Agent 对现实设备的控制能力。

这并不意味着 R1 被放弃。Rabbit 仍然可以把 R1 作为一个语音入口、远程控制器或低门槛终端。只是从产品架构上看，R1 不再是进入 Rabbit 生态的门票，而变成了 OS3 可以接入的一个设备节点。

这是一次重要的去硬件化，但也带来一个新问题：如果 Windows、Mac 和 Linux 设备本身就能运行 OS3，用户为什么还需要 R1？Rabbit 必须证明，R1 在语音交互、随身使用、设备控制或特定场景下具备明显优势，而不是简单地让它沦为一个昂贵的快捷键。

OS3 与 Claude Code、浏览器 Agent 的区别

OS3 的竞争力，取决于它能否把不同类型的 Agent 统一起来，而不是单纯再造一个浏览器自动化工具。

Claude Code、Codex CLI 等产品主要面向代码和开发环境。它们可以理解项目结构、读取文件、修改代码并执行命令，但通常围绕一个工作目录和一个终端展开。它们的优势是开发流程深、反馈闭环快；不足是普通用户需要理解项目、权限和命令行环境。

浏览器 Agent 则主要在网页中完成搜索、填写表单、下单或信息整理。它们适合处理网页任务，但对桌面文件、原生应用和跨设备流程的覆盖有限。

RPA 工具可以操作鼠标、键盘和应用界面，但往往依赖固定坐标、录制流程或脆弱的规则。一旦网页改版、窗口位置变化，工作流就可能失效。

RabbitOS 3 的目标，是把这些能力放到一个调度层里：代码任务交给开发 Agent，网页任务交给浏览器 Agent，本地文件交给桌面节点，复杂任务再由总 Agent 负责编排。

| 产品类型 | 最擅长的任务 | 主要限制 | |---|---|---| | RabbitOS 3 | 跨设备、跨应用的复杂任务调度 | 权限、安全和稳定性仍需验证 | | Claude Code、Codex CLI | 代码理解、修改、执行和测试 | 主要围绕开发环境工作 | | 浏览器 Agent | 网页检索、表单填写和浏览器操作 | 难以覆盖本地应用与多设备 | | 传统 RPA | 固定、重复、结构明确的流程 | 对页面变化和异常情况敏感 | | 普通聊天机器人 | 问答、写作、总结和内容生成 | 通常不能真正执行端到端动作 |

如果 OS3 只能把多个模型放在一个聊天框里，它的价值不会比现有聚合式 AI 产品高多少。只有当它能可靠地判断“任务该在哪台机器上执行、需要哪些权限、何时必须征得用户确认”，它才有机会成为真正的 Agent 操作层。

真正的难点不是调用模型，而是控制现实世界

AI Agent 行业已经证明，生成一段文字并不难，难的是让系统连续执行十几个步骤，而且每一步都不出错。

OS3 面临的第一个难题是权限。读取文件、发送邮件、修改代码、操作浏览器和执行命令，风险等级完全不同。一个好的系统应该支持分级授权：读取普通文件可以自动完成，删除文件、发送外部消息或进行支付则必须明确确认。

第二个难题是任务失败后的恢复。现实任务经常会遇到登录过期、页面变化、网络中断、弹窗遮挡和权限不足。Agent 不能只会输出“操作失败”，还需要知道失败发生在哪一步，以及是否可以换一台设备、换一个模型或采用另一种路径继续执行。

第三个难题是隐私。OS3 可能需要处理本地文档、浏览历史、聊天记录、代码仓库和企业资料。Rabbit 必须说明哪些数据会上传到云端，哪些操作只在本地完成，模型供应商是否能看到用户内容，以及设备节点之间如何进行身份认证。

第四个难题是可验证性。用户需要知道 Agent 到底做了什么，而不是只得到一个看似完整的结果。任务日志、操作回放、文件变更记录和撤销机制，可能比“支持多少模型”更重要。

目前公开资料尚未给出 RabbitOS 3 的完整定价、模型清单、调用额度、企业管理能力和安全审计细节。因此，现阶段更适合把它看作一次产品架构升级，而不是已经成熟的通用电脑操作系统。

Rabbit 这次押注对不对

RabbitOS 3 的方向是对的，但它的成功门槛比发布一个新模型更高。

从用户角度看，OS3 解决了一个真实痛点：AI 工具正在变多，但工作流反而越来越碎片化。用户需要在不同模型、不同应用和不同设备之间来回切换，真正消耗时间的不是生成内容，而是把内容放进正确的流程里。

从 Rabbit 角度看，去掉 R1 硬件限制可以扩大潜在用户规模，也能让产品更快获得真实使用反馈。用户不必先购买设备，再判断 Agent 是否有用；Rabbit 也不必把每次能力升级都绑定到一台有限的硬件上。

但这同时削弱了 Rabbit 原本最容易讲清楚的产品故事。过去它可以说“买一台 R1，让 AI 替你操作”；现在它要解释的是“把所有设备接入 OS3，让一个总 Agent 调度它们”。后者能力更强，却也更复杂，更容易陷入权限、安全和稳定性的泥潭。

我的判断是：RabbitOS 3 比 R1 更接近 Rabbit 真正应该做的产品，但它还没有证明自己已经解决了 Agent 最难的部分。Rabbit 过去的问题不是缺少概念，而是演示效果与长期可用性之间存在距离。OS3 能否翻身，不看它能接入多少模型，而看它能否连续几周稳定完成用户真正依赖的任务。

如果它能够做到“知道文件在哪、知道该用哪个模型、知道该在哪台电脑执行，并在高风险动作前停下来询问”，Rabbit 就有机会成为跨设备 Agent 的入口。如果它只是把聊天、浏览器自动化和几个桌面命令包装在一起，那么 R1 的故事可能会以另一种形式继续重演。

结语：硬件退到后台，Agent 开始争夺系统入口

RabbitOS 3 的发布，反映了 AI 产品竞争正在从“谁的模型更强”转向“谁能更完整地接管任务链路”。模型是大脑，工具是手脚，设备节点是执行环境，而 OS3 试图成为负责协调这一切的神经系统。

这种系统一旦成熟，用户不再需要先打开某个 App，再寻找功能入口，而是直接描述目标。问题在于，AI 要真正进入操作系统，就必须同时面对权限、隐私、错误恢复和责任边界。

Rabbit 已经把最受争议的 R1 从必需品变成了可选入口。接下来，它需要证明的不是 Agent 能不能做一次精彩演示，而是能不能在 Windows、Mac 和 Linux 上，稳定、可控、可追溯地完成用户每天都会重复的工作。

这场竞争才刚刚开始。真正的“Agent 操作系统”，最终不会只属于最会宣传的公司，而会属于那个最懂得如何安全地使用用户设备的产品。

参考来源

• 知乎：Rabbit 做了个“所有 Agents 的 Agent” —— 对 RabbitOS 3 的设备接入方式、Node 架构和早期体验进行介绍。
• 知乎：RabbitOS 3 相关体验资料 —— 补充说明 Rabbit 将多个设备、模型与 Agent 统一调度的产品思路。
• 品玩：对话 Rabbit 创始人吕骋：做 AI Agent，向所有人开战 —— 回顾 Rabbit 早期为何选择 R1 硬件，以及公司对云端 Agent 和系统入口的判断。
• 知乎：RabbitOS Intern 与通用 Agent 方向 —— 提供 Rabbit 早期通用 Agent 产品路线的背景信息。