多代理同跑 Xcode 项目：构建为何被静默替换？

实验背景与设置

单个 Claude Code 代理在 Xcode 项目里跑通之后，下一个自然的念头就是多开几个。期望很简单：两个任务，大概花一个任务的时间。FS 但这个期望有个漏洞。iOS 项目共享的不只是文件，还有模拟器、已安装应用和应用保存的数据。FS 作者 Amarildo Lucas 决定亲眼看一看，当两个代理同时撞上那块共享区域时会发生什么。

实验选了一个小型 SwiftUI 天气应用。两个代理各自在自己的 Git worktree 里工作：一个加功能，另一个加测试。两个提示都没有指定模拟器，但两个代理都自动选中了已经启动的 iPhone 18 Pro。FS 为了追踪构建来源，作者给两个 worktree 设了不同的构建版本号：111 和 222，bundle ID 保持一致。FS 完整运行记录公开在 Gist 上。GIST

关键发现与反直觉数据

两个构建都成功，两个代理都报告成功。我查了模拟器上实际安装的内容，结果完全出乎意料：模拟器里运行的是第二个代理的构建，第一个代理的构建 111 已经没了。FS 没有任何代理的输出提到对方，也没人发现自己的构建消失了。

第二件事更隐蔽。代理 A 启动的 app 当时已经不再运行，日志显示新安装过程向正在运行的应用发送了 terminate 请求。FS 两个代理先后安装并启动了各自构建，但共享同一个模拟器，最终只有第二个构建是可见的。

第三件事让我停下读了两遍。构建 111 在 UserDefaults 里保存的城市数据，在构建 222 下依然存在。日志先是"No saved cities found; seeding defaults (2) on first launch"，接着"loadCities loaded 2 cities from UserDefaults"。FS 在已有应用之上安装新构建，数据会保留下来，只有卸载才会清掉。

作者用一句话概括了这个实验的核心：Worktrees keep files apart. They don't keep simulators apart. 工作树让文件隔离，但不能隔离模拟器。FS 整个过程发生了四件事，没有一件引发错误提示，整个冲突都静默地完成了。

对比与交叉验证

预期和现实之间的距离在这份实验记录里很清楚。预期是两个任务大约在一个任务时间内完成，实际发生了构建冲突，模拟器上的最终状态取决于哪个代理最后写入。FS 单代理运行时没有这个问题，因为只有一个写入方。双代理同时运行时，后写覆盖先写，而双方都认为自己成功了。

这篇文章在 Hacker News 上只有 1 点、0 条评论。HN 社区还没有人讨论这个风险。技术分析本身写得很细，作者把四件事一件件列出来，还给了日志证据，但传播范围很有限。

我的判断是，这个问题的杀伤力不在构建失败，而在无声覆盖。开发者的注意力在代码变更上，模拟器的状态却被另一个代理悄悄改掉了。构建号 111 和 222 的对比设计让问题显形，但实际工作中版本号往往一样，连辨别都做不到。多开代理节省的时间，很可能被这种隐蔽的互相踩踏吃回去一部分。要安全地并行跑多个代理，得让它们各用各的模拟器，或者把模拟器的控制权从代理手里收走。

原文：

How to Run Multiple Claude Code Agents on the Same Xcode Project · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月30日