我们最近宣布 Sentry 收购了 XcodeBuildMCP——这是我构建的 Model Context Protocol（模型上下文协议，MCP）服务器，用来帮助 AI agent 在 iOS 开发中导航。我们最先被问到的问题之一有点扎心：MCP 真的有必要吗？我们是为工程师做开发者工具的工程师，所以我们做了最“工程师”的事：用实证方法把它搞清楚。
我们搭建并跑了一个评测（eval）：用三种 LLM、三种方案，每种方案各做五个不同的编码练习，总计 1,350 次试验来回答这个问题。我们原本以为 XcodeBuildMCP 会碾压，但事实并不是。
我们测试的三种方案成功率都达到了 99%+。 现代模型从错误中恢复得足够好，完成任务基本是板上钉钉。真正的差异出现在意想不到的地方：时间、成本，以及每种方案是如何花掉上下文预算的。
上下文悖论
MCP 工具会在 agent 做任何事之前，把 schema、描述和一堆样板信息注入上下文。这对工具可用性很有帮助，但上下文不是免费的。
上下文是一种预算。MCP 工具的 schema 会在一开始就把预算花掉；而当 agent 缺少正确信息时，它们会在后续的失败命令与重试中把预算花掉。问题在于：哪一种“花法”更划算。
实验
如上所述，我们在五个任务上对三种方案进行了测试：一个 smoke test（构建、安装、启动）以及 4 个编码练习（修测试、实现缓存、重构一个 API、添加深链功能）。
- Shell（未预置）： 没有 MCP 工具，没有任何引导。agent 通过跑各种命令自己发现 scheme 和 simulator。
- Shell（预置）： 没有 MCP 工具，但我们给了 agent 一份
AGENTS.md，里面写清楚了准确的 scheme、simulator destination，以及项目路径。 - MCP（未预置）： 没有
AGENTS.md，但 agent 可以使用 XcodeBuildMCP 的完整工具套件。
方法
- 3 个模型（claude-opus、claude-sonnet、codex）× 5 个任务 × 3 个场景 × 30 次试验 = 1,350 次运行（其中 9 次基线运行从汇总中排除）。
- 成功率按“每次运行”计算。
- 时间为实际墙钟时间（wall-clock seconds）的中位数。
- Tokens（平均）= 未缓存输入 + 缓存读 + 输出（不含缓存写入）。
- Cost/Trial 使用“等价冷启动”（cold-equivalent）的中位数（把缓存读取按未缓存处理）。
- “真实工具错误（Real tool errors）”不包含 XcodeBuildMCP 的 session_defaults 发现过程、sibling-cascade 错误，以及通过工具上报的构建/测试失败；按每次运行平均。
结果
Metric
| 指标 | Shell（未预置） | Shell（预置） | MCP（未预置） |
|---|---|---|---|
| 任务成功率 | 99.78% (+0.22 pp) | 99.56% (baseline) | 99.78% (+0.22 pp) |
| 中位数耗时 | 185s (+50%) | 123s (baseline) | 133s (+8%) |
| Tokens（平均） | 400K (+17%) | 341K (baseline) | 702K (+106%) |
| 每次试验成本（冷启动等价中位数） | $1.12 (+14%) | $0.98 (baseline) | $2.30 (+135%) |
| 真实工具错误（平均） | 1.04 (+225%) | 0.32 (baseline) | 0.56 (+75%) |
Cost/Trial 使用冷启动等价的中位数成本（把缓存读取按未缓存处理）。在这次运行中，cache read rate 在 shell 方案平均约为 ~91%，在 XcodeBuildMCP 方案约为 ~96%，因此实际计费成本会显著低于冷启动。百分比均相对 Shell（Primed）；任务成功率使用百分点（pp）变化。大多数读者使用订阅制 agent，所以 token 数可能比美元更有参考价值。
三种方案的成功率几乎完全一致。真正的故事在“时间”和“成本”两列。
一个 Markdown 文件在成本上碾压一切
按预期，最便宜、最快的方案不是 MCP，而是一份只有四行构建指令的文本文件。预置的 shell 比未预置 shell 快 34%，token 少 15%，真实工具错误少 70%。
为什么？最小化、精准的上下文。只有构建命令：没有 schema 开销、没有工具描述、没有发现（discovery）循环。agent 知道该跑什么，然后就去跑。
对于构建配置稳定的项目，一份写清楚你“准确命令”的 AGENTS.md 是最直接的路径。别为你不需要的 discovery 买单。
XcodeBuildMCP 减少了对构建配置的猜测
让 agent 构建一个 iOS App，在任何一行代码能编译之前，必须先把三件事搞对：项目路径、scheme 名称、以及有效的 simulator destination。这些东西靠猜是猜不出来的。一个叫 “HackerNews” 的项目，scheme 可能是 “HackerNews”、也可能是 “Hacker News”，甚至可能完全不一样。Simulators 还可能按名称、OS 版本或 UUID 标识。没有引导时，agent 只能通过跑命令、读错误输出来把这些信息“试”出来。
在没有预置的情况下，shell agent 的前几个回合基本都在干这件事。一段真实的未预置运行大概长这样：
xcodebuild test -scheme "Hacker News" -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.2' ...
xcodebuild: error: The project named "HackerNews" does not contain a scheme named "Hacker News".
xcodebuild -list
xcodebuild test -scheme HackerNews -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.2' ...
xcodebuild: error: Unable to find a device matching the provided destination specifier.
xcodebuild test -scheme HackerNews -destination 'platform=iOS Simulator,id=E3BD65D4-6AFC-48FA-9AF3-FE4D1EAE19DA' ...
scheme 错了、simulator 错了、多做 discovery、不断重试。未预置的 shell 平均每次试验会调用 2.56 次 xcodebuild，而预置方案是 1.25 次。
XcodeBuildMCP 把这些猜测消掉了。它的工具不只是返回数据，还会给出可执行的提示，引导 agent 走向正确的下一步调用：
TOOL_CALL mcp__XcodeBuildMCP-Dev__list_schemes {}
TOOL_RESULT ✅ Available schemes: HackerNews, ...
Next Steps:
1. Build the app: build_sim({ scheme: "HackerNews", simulatorName: "iPhone 16" })
2. Show build settings: show_build_settings({ scheme: "HackerNews" })
结果是：中位数耗时比未预置 shell 快 28%，p90 也下降了大约 20%。工具 schema 的开销确实存在，但它换来的，是减少失败命令导致的上下文膨胀（错误输出 + 重试）。把上下文花在“正确的事情”上，比花在“从错误中恢复”上更便宜。
截断问题比你想的更糟
在我们的测试项目里，一次 xcodebuild 调用经常会超过 agent 的截断上限：
Output too large (1.2MB). Full output saved to: .../tool-results/toolu_01BVbVcVHRR7QLzTiqqcz6Gv.txt
TOOL_CALL Bash {"command": "tail -100 /tmp/test_output.txt | grep -A 5 -B 5 \"Test Suite\\|passed\\|failed\""}
49.6% 的 shell-未预置 和 56.9% 的 shell-预置 试验都遇到了截断，中位数保存日志约 ~1.2MB。发生截断时，agent 通常会用 tail 检查结果，这意味着它可能错过日志更早位置出现的关键 warning。一次“成功”的构建，可能其实在输出关于弃用 API 或缺失 entitlement 的警告，但 agent 根本看不到。
XcodeBuildMCP 的 build_sim 工具会过滤输出，只返回 warnings、errors 和状态信息。中位数构建结果约 ~2.1KB，相比 shell 截断日志的中位数减少了 99.8%：
⚠️ Warning: ld: warning: search path '.../Frameworks/Reaper.xcframework' not found
⚠️ Warning: warning: The CFBundleShortVersionString of an app extension ('1.0') must match that of its containing parent app ('3.10').
✅ iOS Simulator Build build succeeded for scheme HackerNews.
总体上，XcodeBuildMCP 的 token 使用量比未预置 shell 高 75%，但构成差别很大。Shell agent 会把大量上下文预算花在被截断的数 MB 构建日志和诊断重试上；XcodeBuildMCP 的 tokens 几乎全是结构化、可执行的数据：warnings、errors、状态消息，以及下一步提示。原始 token 数更高，但噪声显著更低。
工具错误：几乎从来不是问题
在 1,350 次运行里，有 688 次（51%）至少遇到过一次工具错误。几乎没有哪一次因此导致任务失败。模型会读错误、调整，然后继续。
有个细节值得指出：对于 XcodeBuildMCP，原始工具错误计数会产生误导。该工作流在 agent 第一次发现正确的 setup 调用时，会刻意暴露一个“missing session defaults”错误；而且下游失败经常从一个根错误级联出来。下表排除了这些预期的 discovery 错误，以及正确上报的构建/测试失败：
Scenario
| 场景 | 原始工具错误（平均） | 真实工具错误（平均） |
|---|---|---|
| Shell（未预置） | 1.04 | 1.04 |
| Shell（预置） | 0.32 | 0.32 |
| MCP（未预置） | 1.20 | 0.56 |
XcodeBuildMCP 会用结构化的错误消息（经常还会直接建议修复方式）让恢复更容易。但现代模型的恢复能力已经足够强，以至于“错误本身”很少成为瓶颈。
把这些放在一起看
这个评测回答了它想回答的问题：对于简单、边界清晰的编码任务，三种方案都能完成。预置的 AGENTS.md 最快也最省；XcodeBuildMCP 在一开始成本更高，但能减少 discovery 摩擦——这些摩擦会让未预置的运行被错误输出与重试“撑爆”。
评测没能衡量的是 XcodeBuildMCP 的真正上限在哪里。任务足够自洽，以至于 agent 从来不需要 看到 正在运行的 App。但 XcodeBuildMCP 不只是一个构建包装器，它给了 agent 一套闭环：截图、检查 view hierarchy、点按钮、打断点、读控制台。这是简单 shell 命令无法提供的定性能力，而它才是复杂、多回合 agentic 工作流真正需要的东西。
更诚实的结论是：完成任务和 确认 你正确完成了任务，是两件不同的事。前者，一个 AGENTS.md 足够；后者——验证 UI 状态、在 live session 里捕捉回归、调试 agent 刚触发的崩溃——你需要运行时访问能力。这就是评测没测到的缺口，也是 XcodeBuildMCP 试图补上的地方。
所以你实际应该怎么做？
对于已知项目上的日常构建（你只需要 agent 帮你 build 和 install），创建一份写清楚构建参数的 AGENTS.md 就足够了：
# Build Instructions
## iOS Build
- Project: `HackerNews.xcodeproj`
- Scheme: `HackerNews`
- Destination: `platform=iOS Simulator,name=iPhone 17 Pro`
Run: `xcodebuild -project HackerNews.xcodeproj -scheme HackerNews -destination 'platform=iOS Simulator,name=iPhone 17 Pro' build`
最快、最省、没有额外开销。
对于完全闭环的系统： 启用 XcodeBuildMCP，你的 agent 就能更自主地工作，并能检查与验证自己的工作，同时也能调试过程中出现的问题：
{
"mcpServers": {
"XcodeBuildMCP": {
"command": "npx",
"args": ["-y", "xcodebuildmcp@latest", "mcp"]
}
}
}
XcodeBuildMCP v2
在跑完这次评测后，我们发现了很多 XcodeBuildMCP 的改进点，希望能缩小“预置 shell”和“XcodeBuildMCP”之间的差距。事实证明，评测的一个最大价值就在这里：我们获得了之前没有的数据与可见性。我们做了许多改进：缩短工具 schema 描述、默认只启用 simulator 工作流、增加有状态的 session 支持（XcodeBuildMCP 记住你的项目配置），从而不再需要工具在每次调用里携带配置参数；同时减少工具调用开销，等等。
我们用同样的评测框架与任务，测试了一个 XcodeBuildMCP v2 的预发布版本（每个任务每个 agent 15 次试验；n=225）。因为 v2 在写作时尚未发布，它没有被纳入上面的主分析，但它可以作为一个方向性的检查：我们是否能在不丢失 discovery 益处的情况下，降低 XcodeBuildMCP 的上下文开销。
Metric
| 指标 | Shell（未预置） | Shell（预置） | MCP v1（未预置） | MCP v2（未预置） |
|---|---|---|---|---|
| 任务成功率 | 99.78% (+0.22 pp) | 99.56% (baseline) | 99.78% (+0.22 pp) | 100.00% (+0.44 pp) |
| 中位数耗时 | 185s (+50%) | 123s (baseline) | 133s (+8%) | 147s (+20%) |
| Tokens（平均） | 400K (+17%) | 341K (baseline) | 702K (+106%) | 453K (+33%) |
| 每次试验成本（冷启动等价中位数） | $1.12 (+14%) | $0.98 (baseline) | $2.30 (+135%) | $1.27 (+30%) |
| 真实工具错误（平均） | 1.04 (+225%) | 0.32 (baseline) | 0.56 (+75%) | 0.49 (+53%) |
v2 切掉了大部分 token 与成本开销，真实工具错误也呈下降趋势；不过在这次运行里，中位数墙钟时间略慢。如果这些差异在更大样本中仍成立，那么核心结论不变，但 MCP 在 discovery-heavy 的工作流里会在成本上更有竞争力。
XcodeBuildMCP 2.x 现已发布，并进行了进一步优化，以降低上下文开销、提升可靠性。它引入了 CLI 模式和 Agent Skills，让你的 agent 可以在不承担上文提到的前置 token 成本的情况下使用 XcodeBuildMCP。详情见changelog。
v1 数据集（1,350 次运行）与评测 harness 已开源在 GitHub；v2 预览在同一仓库中增加了 225 次运行。