Shopify 给 AI 智能体做了一套移动端远程开发环境

Shopify 之所以构建 Remote Dev，是因为移动端 AI 智能体工作流撞上了物理瓶颈：问题不在模型质量，而在开发笔记本。只要三到四个工作流并行，Mac 就会被编译器、模拟器和 Android Emulator 争抢 CPU、内存和 GPU，很快吃满。团队还必须让笔记本保持唤醒，有时只要误合盖，工作就会中断。

Shopify 内部的 Slack 智能体 River 已经帮助 Web 和后端工程师把任务交给远端执行，不用占用各自开发机。但 River 当时运行在 Linux 上：它可以编辑 Swift，却无法构建和测试 iOS 应用。换句话说，团队“能分派给智能体的工作”已经超过“能在哪里运行这些工作”的能力。Remote Dev 就是为了补上这一层而构建的基础设施。

他们构建了什么

一次会话，多个智能体

Remote Dev 为每个 River 会话提供独立的移动端开发环境。移动端工程因此可以并行推进：一个智能体调试 Android 问题，另一个实现 iOS 功能，第三个测试 pull request，彼此不抢同一台机器。工程师直接从 Slack 启动这些会话，本地不必再运行 Xcode 或 Android Studio。

工作流可以在后台完成

River 的环境承担的不只是写代码。它可以实现修改、构建应用、运行测试、操作模拟器、收集截图并创建 pull request。构建或测试失败时，它能查看日志、修补问题，然后重试。

过去打断工程师日常工作的琐事现在都可以委托：rebase 分支、解决合并冲突、检查 CI 失败、响应 PR 反馈、分诊崩溃和 review 代码。有些自动化工作流还会在夜里无人触发地运行，自动捡起 bug、实现修复、执行测试并创建 PR。第二天早上，工程师面对的是已经准备好评审的修复。

结果必须被证明

Shopify 认为“能编译”不足以证明功能可用。Remote Dev 让 River 能导航应用、交互元素，并在 iOS 和 Android 上截取屏幕或录制操作。修复 bug 时，它可以先复现问题、录制坏行为，再实现修复，并重复同样的步骤展示 before/after。

River 还能把这些录制自动生成讲解视频：应用运行在 3D 手机渲染中，配上动画和旁白。相比只读 diff，评审者更容易看到改动究竟带来了什么。

没有移动端环境的人也能参与

Web 工程师可以修 bug，设计师可以迭代 UI，产品经理可以从 Slack 里测试功能。剩下的缺口是“亲手试”：截图无法让人真正操作产品。

Shopify 的答案是 Live Preview。iOS Simulator 和 Android Emulator 从 River 的 Remote Dev 环境通过 WebSocket 串流到 Quick 网站；浏览器再把交互回传到远端设备。收到链接的人打开的就是真实运行中的应用。每个 Remote Dev 会话都会自动生成双平台 Live Preview，而且会话可分享，方便多人协作。

Shopify 还加入了 deep linking 和移动端 CLI 的实时串流，评审者可以直接跳到特定页面，并查看 UI 底层正在发生什么。使用者不需要本地配置、不需要安装构建产物，甚至不需要一台 Mac。

基础设施如何工作

iOS 侧是一组远程 Mac，提前装好开发环境和 iOS 模拟器，智能体通过 SSH 连接。Android 更棘手：它的 emulator 依赖硬件虚拟化；如果放进云端 VM，就需要嵌套虚拟化，而 macOS 原生并不支持。Shopify 的做法是让 Android Emulator 运行在一台单独开启嵌套虚拟化的 Linux VM 上，再把它挂到 Mac 会话。这样，智能体在同一个 SSH 会话里可以构建 iOS 和 Android，并在任一平台上测试。

每个智能体申领一台已就绪、已挂载 Android emulator 的 Mac。会话结束后，Mac 会被销毁并准备替换机。空闲机器也会周期性轮换。轮换时间相互错开，让池子始终可用，又不打断活跃会话。

预热池是关键工程

原来的首次 checkout 和应用编译要超过 30 分钟。如果收到请求才准备机器，每次委托都要先付这笔启动成本。因此 Shopify 维持一个预热 Mac 池：main 已经 checkout，工具已经安装，应用已经构建，缓存已经热好。

智能体申领 Mac 后同步自己的分支，启动一个预构建 Android VM 实例。代码 checkout 可以留在本地或云端，变更同步到 Mac 上执行构建和脚本。结果是从申请机器到在真实设备上检查代码变化只要几分钟，而不是超过 30 分钟。

问题	Remote Dev 的解法
几路并行移动构建就把笔记本吃满。	由受管资源池为每个智能体分配独立远端环境。
Linux 能编辑 Swift，但不能构建或测试 iOS。	智能体通过 SSH 使用远程 Mac 和 iOS 模拟器。
macOS 缺少原生嵌套虚拟化，难以在云端运行 Android emulator。	Android emulator 运行在单独的 Linux VM 上，再挂载到 Mac 会话。
冷启动 checkout 和编译超过 30 分钟。	预热 Mac 提前准备 main、工具、构建和缓存。
评审者要本地安装构建产物，还需要 Mac。	Live Preview 把运行中的应用串流到浏览器链接。

教 River 使用这套基础设施

有了基础设施还不够。River 仍会说 iOS 构建不能在 Linux 上运行，因此只能写代码、不能验证结果。Shopify 创建了一个 skill，教智能体如何测试修改并证明结果。这条路迭代了几次：River 有时忘记远程 Mac 的存在，有时在与远端机器通信时保持沉默，有时长时间不回应用户。

两个改动最关键：一是用一个 CLI 封装复杂的 SSH 参数，让智能体不用处理底层细节；二是不再用 sleep 或 timeout 等长时间任务，而是使用 River 可实时观察的 tmux pane。智能体与远端工作流保持连续交互，而不是发一条命令后盲目等待。

让改变真正落地

技术切换还必须克服习惯。移动端开发者过去习惯本地模拟器和亲手测试，早期 River 又给一些人留下构建慢、不稳定的印象。Shopify 用内部故事和广告推动迁移，甚至做了一个模仿经典 Mac vs PC 广告的 AI 生成短片，让大家看到新工作流确实变了。

数据变化很明显：River 最初只创建 6% 的已合并移动端 pull request，后来升至 61%，本地开发趋势被反转。这个数字不只是采用率；它说明智能体生成的移动端改动已经进入人类评审者愿意合并的状态。

在公司内部“公开构建”

River 天生支持多人协作，所以 Shopify 能观察不同人如何使用同一个智能体：用户在哪里卡住、哪里被指引方向带偏、哪里拒绝访问工具，全部可见。

为了把反馈变成系统化循环，Shopify 使用了 Jev——一个很快、成本很低的分类模型。Jev 观察移动端 River 对话，给每条消息打多个问题标签；Shopify 再按结果质量分类对话，把失败样本交给 LLM 寻找改进。River 用这种方式为未来的会话改进自己。

这只是开始

Remote Dev 起点是给 River 一个移动端开发环境，但它同时改变了三件事：谁可以参与、团队如何协作、以及多少工作可以安全委托。Shopify 正在加入实时监控应用健康的工作流，让 AI 智能体为崩溃修复自动开 PR，随后快速评审。它也在用多个智能体并行做 bug bash，模拟不同商户，覆盖不同设备、语言和用户流程。

真正的启发是：智能体不只是接在聊天窗口上的模型。它需要一个能安全并行的隔离环境，需要平台支持才能构建和测试真实目标，还需要能生成证据，证明结果确实可用。

来源：We gave AI agents a mobile dev environment，Shopify Engineering，2026 年 10 月 22 日。