为什么智能体需要一块真实的屏幕。
如果智能体只是填写网页表单，浏览器沙盒就够用了。可一旦工作延伸到原生应用，沙盒就走到了尽头。真实桌面是最干净的智能体运行环境：人能用的，智能体也能用。
只活在无头浏览器里的智能体，没法打开 Final Cut，没法把视频文件从 Finder 拖进创作工具，没法在“预览”里签署 PDF，没法运行 .dmg 或 .exe 安装程序，没法给另一个应用授予屏幕录制权限，没法用系统文件选择器挑选文件，也扛不住操作系统突然弹出的模态对话框。而真实工作流恰恰大多发生在这些环节，无头浏览器里的智能体往往就在这里悄悄失败。
虚拟化容器（各大实验室主推的“智能体电脑”模式）补上了其中一部分缺口，却带来了新的问题。镜像通常是一个极简的 Linux 桌面，只预装了寥寥几个应用，超出这个范围的一切都够不着。容器与用户真实的工作毫无延续性：没有用户安装的应用、登录过的账号、保存的文件，也没有授予过的权限。每次运行智能体，都是从一台空白的、并不属于用户的机器开始。
Remio 的设计走的是另一条路。通过我们正在构建的运行时接入的智能体，将获得用户真实的桌面，也就是用户日常使用的那台 Mac、PC 或 Linux 电脑，走的还是人类用户今天已在使用的同一条远程桌面会话。用户装的每个应用都在，登录的每个账号都在，所有文件也都在。智能体不会是某个合成环境里的租户，而是用户真实工作站上的客人：用户允许它进来多久，它就待多久，不会多一刻。
智能体将要用到的管线，早已在为人类运行。
如今 Remio 用户发出的每一次点击、每一次按键、每一次滚动，都已经通过操作系统自带的原生输入子系统送达主机，与实体鼠标或键盘产生的事件完全一致。这条管线并非设想：它正是 Remio 此刻在真实 Mac、PC 或 Linux 电脑上为人类服务的基础。而且并非巧合，它也恰恰是智能体运行时可以直接接入的底座：无需单独的面向智能体的 API，无需把模拟按键塞进窗口的事件队列，也无需用辅助功能垫片去冒充一次真实的点击。
设计承诺：如果它发布，智能体的输入在主机端将与人类输入无从区分，因为它走的是完全相同的管线，而不是专为智能体另建的一条平行通道。
这比听上去更重要，也是我们认为 Remio 的架构不只是“方便”，而是真正适合作为智能体运行时起点的原因。那些在应用层伪造输入的智能体平台，例如把模拟按键塞进窗口事件队列，或者用辅助功能 API 直接驱动界面元素，总是不断碰壁：受保护的输入框拒绝接收输入，原生快捷键失灵，应用之间无法拖放，焦点管理也会乱套。走操作系统级输入管线，今天的人类会话就已经绕开了这一切。把它扩展到智能体会话，仍是我们要做的设计工作，但承担最难部分的底座已经在运行。
按设计，权限边界将原样延续。人只需一次性授予 Remio 主机应用的辅助功能与输入监控权限，就已经管控着人类会话发出的每一个输入事件。我们的设计承诺是：智能体会话将受同一份授权约束，智能体自己无法持有单独的权限，也不会获得比人类已为应用打开的那扇门更宽的通道。
屏幕访问，以及智能体将如何使用它。
Remio 的屏幕采集管线如今就在把主机的实时画面串流给人类客户端：完整画面、硬件编码、实时传输。智能体运行时还需要同一份数据的几种形态：按需截取的静态画面、更小的区域、屏幕内容的结构化读取。这些额外形态，目前都还没有出现在已发布的代码中。
如今已经提供的是实时串流：主机屏幕持续采集，硬件编码，并通过人类客户端已在使用的同一条加密通道送达。智能体运行时将复用同一条管线来完成自己的静态截取，比如按需取一帧，或只取模型已经知道要看的那块区域，而不是另起炉灶搭建第二条采集通路。这样复用是我们已经敲定的设计选择，并不是在声称它今天已经存在。
对于更擅长处理文字而非像素的智能体，设计中构想了一种文字稿模式：借助平台自带的 OCR（macOS 上的 Vision 框架，Windows 上的 Windows OCR API）返回屏幕上的文字及其边界框，而不必让视觉模型参与其中。这部分目前一行代码都还没写。把它列入计划，是因为它能让智能体不必把任何一帧画面发给模型，就把一次文字匹配变成一次精准点击。只要我们做得好，这将是实打实的效率提升。
为了获得最高保真度的结构化访问，设计中还构想了读取焦点窗口的操作系统辅助功能树，也就是屏幕阅读器遍历的那棵树：带标签的按钮、文本框、菜单和角色层级。这部分同样尚未存在。而且在我们构想的所有版本里，输入管线的那条规则都会延续：智能体会话看到的内容，恰好就是主机的屏幕录制权限已允许人类会话看到的内容，不多一分。如果某块显示器的该权限被关闭，智能体将从那块显示器得不到任何内容，与人类客户端今天的情形一样。
在动手写智能体代码之前，我们先立下的底线。
这些不是留待以后再做、希望到时能做好的功能，而是整个 Agent Runtime 设计在发布前必须满足的约束。我们趁着还没有代码需要迁就它们的时候，现在就先定下来。
每一个 Remio 会话，无论由人还是智能体发起，开始的方式都一样：由人从主机屏幕上读出六位数字码，并在客户端输入。我们没有考虑过任何让智能体自己创建会话、持有可以悄悄刷新的令牌，或在配对它的人决定结束之后继续保有访问权限的设计。下一次运行智能体，需要人再次配对：按设计，每一次都有一个新的“人在回路”环节。
智能体会话进行期间，主机和客户端都会显示持续、醒目的提示，并提供可以立即结束会话的“停止”控件，坐在主机键盘前的任何人都能使用，而不仅仅是发起会话的那个人。智能体执行的每一个操作都会写入审计日志，供人随时查看。目前已发布的代码中还没有这些内容，这是设计必须达到的标准。
权限边界与上面的输入和屏幕部分一脉相承：智能体会话继承的，恰好是人类会话已经遵守的主机操作系统级权限（屏幕录制、辅助功能），不会更宽。它不会获得自己的提权授权，也没有办法扩大人类已为 Remio 应用划定的范围。如果我们正在设计的某项能力无法装进这个边界，它就不会发布。
目前还没有 SDK，这是我们正在设计的雏形。
Remio 尚未发布智能体 SDK、API 或面向智能体的连接规范。我们手里有的，是设计中反复回到的一份简短的基础能力清单（输入、屏幕访问、结构化界面读取），以及一个承诺：无论最终发布什么，从第一天起都与模型无关。
我们一再回到的形态刻意保持精简：几个输入原语（一次点击、一次按键），几个视觉原语（一帧静态画面、一块区域），以及一个结构化界面读取。这只是草图，并非规范：一样都还没发布，具体接口也尚未确定。我们现在承诺的是形态，而非语法。
与模型无关是设计要求，不是以后再说的愿景。无论规划工作流的模型是 Claude、GPT、Gemini，还是你自己运行的模型，最终发布的东西都会以同样的方式工作。我们不会围绕某一家厂商的工具调用格式来构建它，因为一旦把运行时绑定到某个模型的接口上，我们就许下了错误的承诺。
桌面运行时和智能体自己的运行时是两回事，我们也打算一直保持这样。Remio 负责把智能体的操作送到真实桌面上；模型、规划循环以及它在哪里运行，完全由构建智能体的人决定。我们不打算自己托管模型，也不打算对模型计量或设限。
这套设计不是为哪些场景而建的。
真实桌面运行时适合某些智能体工作流，也不适合另一些。下面是简短而坦诚的划分，即使这一切尚未发布。
Remio 不是为只需要一个网页浏览器的智能体而建的，比如抓取网页、填写表单、读取仪表盘。完整的远程桌面会话对一个浏览器标签页来说是大材小用，而 Remio 并不打算在这个领域竞争。
Remio 也不是为需要几十个一次性环境的智能体而建的：每个任务一个、每次全新状态、并行执行。Remio 围绕持续的、由人配对的会话构建，形态恰恰相反：并发低、连续性高、带着用户真实的上下文。
如果我们按本页描述的方式构建 Agent Runtime，那么当智能体需要真实的操作系统桌面、原生应用、用户实际安装的软件、用户真实的账号和文件，以及由人在回路的会话边界时，它就是正确答案。比如，替有残障的用户操作桌面的无障碍智能体；针对真实操作系统应用的 AI 辅助 QA；必须用到用户已拥有的某个原生工具的智能体工作流；以及任何“在我的监督下，用我自己的机器和上面的一切”这种天然诉求的任务。对于这些场景，一旦发布，Remio 就会成为那个运行时。
关于我们正在设计的 Agent Runtime 的常见问题。
这套设计通常会引出五个问题，下面都是坦诚的回答，包括那些诚实的答案是“目前还没有”的问题。
现在能用 Claude、GPT 或其他 AI 智能体，通过 Remio 控制我的电脑吗？
智能体能否不经人，自己启动一个 Remio 会话？
主机怎么知道连接的是智能体而不是人？
智能体能看到或触及比人类会话更多的内容吗？
Remio 的 Agent Runtime 支持哪些 AI 模型？
今天已经实现：为人类打造的快速、私密的桌面。将来：也为他们的智能体服务。
安装 Remio，以最快、最私密的方式连接你自己的 Mac、PC 或 Linux 电脑：原生输入、原生屏幕访问、端到端加密，无需账号。本页描述的 Agent Runtime 尚未发布，我们也不承诺日期，但正是这套相同的架构，让我们觉得它值得去做。