几个月前，我们认真讨论过一个听起来很简单、做起来却很别扭的问题：

怎么让一个在云端和我聊天的 AI，真正碰到我自己的电脑？

不是上传一份 ZIP，不是把仓库同步到另一个云端沙箱，也不是让本地 Codex 和网页里的 ChatGPT 互相传话。我们想要的是更直接的东西：模型仍然可以运行在远端，但它能够在明确授权下读取本机文件、进入真实仓库、运行命令、看进程，并把结果带回当前对话。

2026 年 10 月 4 日，这件事第一次在我们的日常工程环境里变得很具体。

我在 ChatGPT 里接入了 Remote Desktop Commander。Mira 先确认一台 Mac 在线，然后列出桌面目录，找到了：

Desktop/
└─ codespace/
   ├─ agent-publisher/
   ├─ dr-card-ios/
   └─ mira-desktop/

接下来它已经可以直接读取文件、搜索目录、启动进程、跑 Git 和开发命令。

最有意思的是：本地 Codex 走不走中转，和这条链路没有关系。

它不是“两个 Agent 互相配合”，而是另一种更干净的结构。

一、它到底做了什么#

Remote Desktop Commander 官方把自己定义为一个 hosted Remote MCP server。电脑上运行一个很小的 device agent；ChatGPT、Claude、Cursor、VS Code、Gemini CLI 等支持 Remote MCP 的客户端，通过 OAuth 连接到托管服务，再由服务把工具调用转发到已经配对的设备。

官方公开的结构大致是：

sequenceDiagram
    participant AI as ChatGPT / Claude / Cursor
    participant Relay as Remote MCP Relay
    participant Device as 本地 Device Agent
    participant Host as 真实电脑

    AI->>Relay: MCP tool call
    Relay->>Device: 转发到已配对设备
    Device->>Host: 读文件 / 跑命令 / 管进程
    Host-->>Device: 本地结果
    Device-->>Relay: 返回结果
    Relay-->>AI: MCP response

它支持的工具并不神秘，反而非常“工程”：

  • 文件读取、批量读取、目录浏览、文件信息；
  • 文件搜索；
  • 写文件、块级编辑、移动与创建目录；
  • 启动命令、读取持续输出、向交互式进程发送输入；
  • 管理长运行 session 和系统进程；
  • 连接多台设备、查看状态和调用记录。

这些能力一旦进入同一个对话，体验会发生一个很大的变化。

以前我和 Mira 讨论工程问题时，经常存在一层人为搬运：

Mira 提建议
→ 我回本机执行
→ 我贴日志
→ Mira 再判断
→ 我再执行

Remote Desktop Commander 把它压成了：

Mira 判断
→ 调用本机能力
→ 得到真实结果
→ 继续判断

少掉的不是几次复制粘贴，而是一整层上下文损耗。

二、真正有价值的不是“远控”#

如果只把它理解成“ChatGPT 终于能远程控制电脑”，其实低估了这件事。

它更重要的价值，是把两个过去经常绑死的东西拆开了：

模型在哪里，和执行在哪里，不再是同一个问题。

模型可以在 ChatGPT、Claude 或别的云端服务里；文件、Git 仓库、编译器、数据库、设备 SDK 和已经配置好的开发环境，仍然留在自己的电脑上。

这意味着一个 Agent 不必为了“有手”就同时拥有一整套云开发机。

Reasoning Plane
模型、上下文、规划、对话
        │
        │ MCP
        ▼
Execution Plane
文件、Shell、Git、进程、真实开发环境

这条边界对个人开发者尤其有价值。

我的 Mac 上已经有正确的 Node、pnpm、Git 配置，有实际的 Mira 工作区，也可能有正在运行的开发服务器。再开一个云端 workspace，往往意味着重新同步代码、重新装依赖、重新处理凭据，还要面对“云端环境和我真实环境究竟差了什么”。

Remote Desktop Commander 没有解决所有工程问题，但它换了一个方向：

不要复制整个工作环境，直接把现有工作环境暴露成受控能力。

三、几个马上就能玩的场景#

1. 手机上处理真实电脑里的工程现场#

Remote Desktop Commander 的 ChatGPT 页面直接把“从手机控制自己的电脑”作为卖点。

这件事真正有用的场景，并不是躺在床上让 AI 帮你乱改代码，而是一些天然适合远程处理的小闭环：

查看 CI 前的本地 build 是否结束
查看某个 watcher / dev server 的输出
读取日志定位错误
确认仓库当前 branch / status
做一个已经边界清楚的小修复
跑定向测试并读取结果

如果任务需要大量视觉验证、真机操作或高风险系统改动，人还是应该回到电脑前。

但“我只是想知道它为什么红了”这种工作，不再要求人必须坐在那台机器前面。

2. 让真正的本地数据参与一次性分析#

有些数据没有必要先传到一个专门的云盘，再让 AI 从云盘读取。

如果文件就在工作机上，Agent 可以先搜索，再按需读取具体内容。对于日志、CSV、项目文档、测试产物、临时导出文件，这种“就地取材”非常自然。

当然，这里有一个必须说清楚的边界：

本地执行不等于数据不离机。

被读取的文件内容和工具结果，仍然需要经过 Remote MCP relay 返回给远端 AI 客户端。官方说明传输使用 HTTPS/TLS，并称中继数据在完成转发后不保留；但这依然不是“全部计算都在本机”的本地模型方案。

所以 Local-first 不能偷换成 Local-only。

3. 把已经配好的机器当成一个长期能力节点#

官方支持一个账号配对多台电脑。

这意味着未来完全可以出现一种很朴素的个人基础设施：

MacBook
→ 日常开发 / Xcode / 移动端

Windows + GPU
→ CUDA / 本地模型 / Windows 构建

办公室机器
→ 公司网络 / 内部服务

家里的常开主机
→ 长任务 / 下载 / 自动化

Agent 不需要假装这些机器是一个统一“超级电脑”。

它只需要知道：这次任务应该落在哪个 execution node。

这比把所有能力硬塞进一台云 Agent VM 更接近真实世界。

4. 不同模型共享同一套“手”#

Remote Desktop Commander 同时支持 ChatGPT、Claude、Cursor、VS Code 和 Gemini CLI。

这件事很值得注意：执行平面开始具有模型无关性。

今天觉得 ChatGPT 更适合产品和工程判断，就让 ChatGPT 用；某个代码任务 Claude 更合适，就让 Claude 用；本地编辑器里 Cursor 更顺手，就让 Cursor 用。

如果它们最终都通过同一种 MCP contract 访问同一台机器，那么“换脑子”不再意味着“重新长一双手”。

四、这和 Mira 有什么关系#

这次实验让我最在意的，不是 Mira 要不要立刻集成 Remote Desktop Commander。

而是它把我们之前讨论的一条路线从抽象概念变成了一个已经有人做出来、而且今天真的能用的产品形态：

远端或移动端负责模型交互，Desktop 负责提供本地执行能力。

Mira Desktop 当前已经有自己的 Tool Runtime、Harness 和 External MCP 能力。代码和当前工程文档都明确区分 Tool Exposure、Availability、Approval、Execution 与 Evidence；terminal_session 也是完整的 host shell / PTY runtime，而不是一个假的命令沙箱。

Remote Desktop Commander 给出的启发，不是“再做一个 terminal tool”，而是多了一层：

Mira Mobile / Web / Remote Agent
            │
            │ authenticated remote capability protocol
            ▼
       Mira Desktop
            │
            ├─ Files
            ├─ Terminal / Process
            ├─ Git
            ├─ Local services
            └─ future device capabilities

这和“手机端自己拥有一切”是两条完全不同的产品路线。

手机没有必要复制桌面的开发环境。它只需要拥有模型、任务上下文和授权交互；真正依赖本机的能力，可以由 Desktop 提供。

Remote Desktop Commander 已经证明这条网络形态成立。

Mira 真正需要继续回答的，是它自己的治理问题：

  • 哪些能力允许被远程暴露；
  • Tool discovery 和 Tool exposure 怎么分；
  • 哪些动作只读，哪些必须逐次审批；
  • 一次批准绑定的是哪一个 exact invocation；
  • 远程执行失败以后怎么恢复；
  • 工具结果怎样进入 Evidence；
  • 手机端看到的是“工具调用成功”，还是“用户任务真的完成”。

这些问题恰好也是 Mira Harness 这一年来一直在处理的事情。

所以我反而不想把这次发现理解成“别人把 Mira 想做的东西抢先做了”。

更准确的说法是：有人把我们一直关心的一条执行边界，做成了一个足够简单的可用产品。

这很好。

工程设计最怕的不是别人先做出来，而是一套架构只能在白板上自洽。

五、它也把安全问题放大了#

这种能力越好用，安全边界越不能靠想象。

Remote Desktop Commander 自己的 Security Policy 写得很直接：

工具以当前操作系统用户权限执行。

官方同时明确说明，allowedDirectories、命令 blocklist 之类的限制只是 guardrail，不是安全 sandbox。连接的 AI 账号如果被攻破，或者 Agent 被恶意 prompt injection 诱导执行危险操作，这些软限制不能被当作强安全边界。

官方建议包括：

  • AI 与 Remote Desktop Commander 账号开启 MFA；
  • 只连接自己信任的客户端；
  • 不需要时停掉 device agent；
  • 高风险环境放进 container、VM 或专用机器；
  • 对敏感机器限制暴露面。

这里有一个非常现实的产品教训：

“Agent 有完整 Shell”从来不是一个单独的 feature，它一定同时是权限系统、审批系统和证据系统的问题。

而且产品仍处于 beta。官方仓库最近的公开 Issue 里，已经有人记录 ChatGPT 安全提示误拦截无人值守流程、写入调用在到达设备前被客户端安全检查拦截，以及设备显示 online 但本地执行 child 已断开的假健康状态。

这些问题不意味着 Remote Desktop Commander 不值得用。

恰恰相反，它们说明 Remote Agent 一旦从 Demo 变成真实基础设施，“能调用工具”只是最早的一层。

后面真正难的是：

身份是谁
→ 能看到什么
→ 能调用什么
→ 哪一次调用被批准
→ 调用到底有没有到达
→ 本机到底执行了什么
→ 返回结果能不能证明任务完成

这也是为什么我们在 Mira 里一直强调 Approval、Trace、Evidence，而不是只统计“Agent 有多少工具”。

六、最值得借鉴的是“薄”#

Remote Desktop Commander 让我喜欢的一点，是它没有试图重新发明整个 Coding Agent。

它只是把自己放在一个很窄的位置：

把一台真实电脑变成远程 MCP execution endpoint。

模型不是它的，聊天 UI 不是它的，代码 Agent 也不是它的。

它只负责：

身份连接
设备连接
工具 contract
调用转发
本地执行
结果返回

这其实是一种很成熟的克制。

Mira 未来如果继续做 Desktop ↔ Mobile、Agent ↔ Host、甚至多设备协作，也应该警惕把所有东西揉进一个“大 Agent”。

模型可以替换，UI 可以替换，甚至编排层都可以替换。

真正值得长期稳定下来的，是几个边界：

  • 用户拥有的设备；
  • 明确暴露的 capability；
  • 可审计的 invocation；
  • 可以撤销的授权；
  • 能够回到真实环境核验的 Evidence。

七、几个月前的问题，现在有了一个现实答案#

几个月前我们问的是：

怎么把 Mira 接到我的电脑？

今天更准确的问题已经变成：

一个远端智能体，应该通过什么边界使用我电脑上的真实能力？

Remote Desktop Commander 给出的答案不是唯一答案，但它已经足够清楚：

模型不必住在电脑里。
执行也不必搬到云上。
中间需要的是一条可授权、可发现、可调用、可撤销的能力协议。

这也是 MCP 真正开始变得有意思的地方。

2026 年 7 月发布的 MCP 新规范进一步把协议核心推向普通 HTTP 基础设施，并持续加强授权机制。Remote MCP 不再只是“本地 stdio 工具的远程版”，它正在慢慢变成 Agent 世界里一种真正的基础连接层。

而对 Mira 来说，这次最重要的收获可能非常朴素：

我们不一定需要把“一个完整的 AI”塞进每一台设备。

有时候，只要让智能和执行之间那根线足够清楚，就够了。

参考资料#

Tomz Dang × Mira

上一篇← Mira 稳定性周报：从个人仓库走进组织工程