如果你的应用能自我修复会怎样？

有了 EAS Workflows 和 EAS Simulator，一份 bug 报告可以直接变成一个包含修复的 pull request，还附带一段证明修复有效的录屏。

Agent 开发的未来在于能自我修复的应用。设想用户报告了一个 bug，只有一句简短描述，没有复现步骤，也没有任何证据。通常你只能自己去排查。有了 EAS Workflows 和 EAS Simulator，agent 可以在云端模拟器上复现这个 bug，提出修复方案，并开一个 pull request，附上应用修复前后的证据。你审阅报告、检查改动，再决定是否合并。EAS Workflows 在 Expo 的基础设施上运行 agent。EAS Simulator 则给它一台设备来运行你的应用并验证它的工作。下面以一次 Settings 崩溃为例，看看两者如何配合完成排查。 如果你的应用能自己修复自己呢？

从 bug 报告开始

这个例子里的报告很常见：“Settings 在滚动到底部时崩溃。”它只描述了症状，没有说明如何复现，也没说原因是什么。

给对应的 GitHub issue 加上 repro 标签，就会启动一个 workflow，把报告交给 Claude Code。Agent 的任务是在模拟器上复现故障、找到原因、验证修复，然后才开 PR。

你可以在 issue #9 和 PR #10 中查看这个示例。

让 agent 在云端模拟器上排查

Agent 在 EAS Simulator 上安装应用并打开 Settings。应用立刻崩溃，根本还没开始滚动。

这为排查提供了一个更精确的起点。Agent 在 issue 中贴出它执行的步骤、观察到的行为，以及复现会话的链接。

整个交互通过 agent-device 完成，这是 Callstack 的设备自动化 CLI。它让 agent 能在 EAS Simulator 上查看界面、与应用交互并截图。会话回放则让你事后检查发生了什么。

拿到修复有效的证据

Agent 定位到原因，应用修复，然后重新构建应用，并在第二个模拟器会话中安装。它打开 Settings 并滚动到底部。这一次，界面正常加载，没有崩溃。

这个 PR 把整个排查过程串了起来：原因、改动、前后对比截图，以及两个模拟器会话的链接。它还报告了修复后 22 个 Settings 测试全部通过，lint 和 typecheck 也一样。

你可以顺着报告走一遍复现过程，查看 diff，看着改动后的应用走同一条路径。整个审查在 macOS、Windows 或 Linux 的浏览器里就能完成，不需要在本地搭 iOS Simulator。

把工作流接到你的应用上

这个示例用一个 GitHub Action 把带标签的 issue 编号转发给 EAS Workflows。EAS Workflow 检出仓库、安装依赖，然后启动编码 agent。

第三部分是 agent prompt。它描述应用、模拟器构建 profile，以及 agent 需要完成的排查。它还规定了必须交回哪些证据：一个复现会话 URL、一个验证会话 URL，以及前后对比截图。

这些指令也写明了排查失败时该怎么办。如果 agent 无法复现 bug，就报告它尝试过什么，然后停下。如果修复在模拟器上仍然失败，就报告验证失败，而不是开 PR。对于非视觉行为，prompt 要求在截图之外附上日志或回归测试。

要套用到自己的项目，需要提供应用的构建 profile、导航上下文，以及 Expo、GitHub 和 agent 的凭据。eas-simulator skill 为 agent 提供操作模拟器会话的指引。

prompt 要求 agent 把合并留给人工完成。配置仓库权限和分支保护来支撑这条边界。

这个工作流受 Nathan Schroeder 在 X 上的帖子启发。

试试你自己的流程

从一个你能判断出失败的 bug 和一个能在模拟器上跑起来的应用构建开始。先想清楚一次有用的复现应该展示什么，然后用示例仓库把报告接到你的 agent 上。

你可以只让它复现问题，也可以把修复和验证一并交给它。无论选哪种，都要求 agent 留下足够的证据，让别人能看懂发生了什么。

EAS Simulator 目前处于 early access 阶段。加入 waitlist 即可申请访问权限。想进一步了解如何在自己的机器上使用云端模拟器，请阅读 You don't need a Mac to develop iOS apps。

从 bug 报告开始

让 agent 在云端模拟器上排查

拿到修复有效的证据

把工作流接到你的应用上

试试你自己的流程

相关链接