当编码 Agent 遇到 50 万行 iOS 代码

如果只让模型补一个函数，今天的编码 Agent 看起来已经很强；如果让它读一份产品需求、看懂 Figma、进入五十万行陌生代码，再把功能完整接入生产架构，画面立刻变了。

2026 年 2 月发布的 SWE-Bench Mobile，把这个更接近真实工作的场景做成了基准。论文由多伦多大学、小红书、UIUC、UC Berkeley 等机构的研究者共同完成，评测了 Cursor、Codex、Claude Code 与 OpenCode 四种 Agent、共 22 个 Agent–模型组合。最好的组合只完整完成了 12% 的任务。

但“12%”不是最重要的结论。更有价值的是它解释了 Agent 在生产工程里怎样失败：同一个模型换一个 Agent 外壳，成绩能差 6 倍；文件一多，成功率迅速坍塌；最常见的遗漏不是 Swift 语法，而是 Feature Flag、数据模型和跨文件接线。换句话说，瓶颈已经从“能否生成代码”转向“能否理解并完成整个工程闭环”。

这篇论文真正测试的不是模型会不会写 Swift，而是 Agent 能不能把产品意图完整地落进一个已有系统。

01 / THE BENCHMARK把一道题还原成一次真实需求交付

每个 SWE-Bench Mobile 任务都由三部分构成：输入上下文、期望输出与评估配置。输入不是一句 Issue，而是平均约 450 个英文单词的 PRD、可能附带的 Figma 设计，以及一份约 5GB、横跨数千文件的 Swift / Objective-C 生产代码快照。50 个任务中，70% 带 Figma，92% 带参考图片。

任务要求的不是修一个孤立 bug，而是实现实际出现过的产品功能：修改 UI、接入业务逻辑、处理手势、资源、网络和灰度开关。标准答案平均修改 4.2 个文件；难度按文件数、改动行数与架构跨度划分，简单任务通常涉及 1–2 个文件，困难任务则涉及 6 个以上文件或跨模块重构。

这比 HumanEval 或 MBPP 更像软件工程，也比多数从开源 Issue 构造的 SWE-bench 任务更强调新功能开发和多模态输入。移动端又额外引入事件驱动状态、系统生命周期和框架 API，模型不能只靠常见 Python 模式完成任务。

先记住它的裁判方式

论文没有编译 App，也没有在模拟器上点击界面。测试读取 Agent 生成的 unified diff，用 pytest 检查是否改到关键文件、是否加入必要入口、是否移除旧逻辑、相关文件是否协同变化，并用较宽松的模式匹配容忍命名差异。

这个设计让 22 个组合可以在大型私有代码库上批量评测，也避开 iOS 编译与模拟器的不稳定性；代价是它验证的是补丁的结构意图，不是 App 在真实设备上的运行正确性。后面所有数字，都必须带着这条边界来读。

02 / THE 12% CEILINGAgent 经常做对一部分，却交付不了完整功能

Cursor + Opus 4.5、Cursor + Sonnet 4.5，以及 Codex + GLM 4.6 都达到 12% 的任务成功率，处在榜首。这里的“任务成功”非常严格：一道题的全部测试都通过才算成功。与此同时，最高测试通过率达到 28.1%，明显高于 12%。

二者的间隙揭示了一个熟悉的工程现象：Agent 往往能找到方向、写出主要逻辑，却会漏掉某个配套修改，让整个功能无法闭合。它不是完全不会，而是无法稳定地从“局部正确”走到“整体完成”。

复杂度曲线进一步说明了问题。只需修改 1–2 个文件时，平均成功率为 18%；涉及 7 个以上文件时，只剩 2%。补丁小于 50 行时成功率为 20%，超过 200 行时降到 3%。Agent 的软肋不是某一种语法，而是长距离依赖、跨文件一致性与任务记忆。

03 / AGENT SCAFFOLDING同一个大脑，换一套工具链就能差 6 倍

论文最反直觉的结果来自 Claude Opus 4.5：放在 Cursor 中，任务成功率是 12%；放进 OpenCode，只剩 2%。底层模型没有变，差异来自 Agent 如何搜索仓库、组织上下文、调用工具、保存计划与根据反馈迭代。

这意味着采购或设计编码 Agent 时，不能只看模型榜单。模型是推理核心，Agent scaffolding 才决定它在长任务里能否持续拿到正确上下文。一个强模型如果反复搜索错误目录、过早丢弃 PRD 约束，或者没有完成前的全局核对，照样会输给更便宜但脚手架更好的组合。

成本数据也反对“越贵越强”的直觉。Codex + GLM 4.6 用不到 Cursor + Opus 4.5 一半的单题成本拿到同样的 12%；OpenCode + Opus 4.5 反而是表中最贵、表现又很低的一组。低价同样不自动等于高性价比：OpenCode + GLM 4.6 虽然 API 便宜，却平均运行 32.5 分钟。真正应该比较的是完成一个合格任务的总成本，而不是 token 单价。

04 / FAILURE ANATOMYAgent 漏掉的，恰恰是生产系统的隐性知识

研究者分析了最佳配置的失败信息。最突出的一类是遗漏 Feature Flag，占 54%；其次是遗漏或未更新数据模型，占 22%。漏改关键文件和漏做 UI 组件各占约 11%–15%，缺少必要方法约占 9%。

Feature Flag 是很典型的生产约定。功能逻辑本身可能很简单，但成熟 App 需要灰度发布、A/B 实验和紧急关闭。需求文档、设计稿与局部代码不一定会把这套组织知识重复写一遍，人类工程师依靠长期经验补齐它，Agent 则容易把“界面已经出现”误判为“功能已经完成”。

因此，提升可靠性的第一步未必是换模型，而是把隐性规则显式化：仓库级指令应列出 Feature Flag、数据模型、埋点、路由、兼容性和测试要求；Agent 在动手前先生成影响面清单，完成后再按清单逐项反查。对多文件任务，文件依赖图和符号级检索会比反复全文搜索更重要。

# 完成定义不再只是“主逻辑已写”
feature entry point   ✓
data model / state   ✓
feature flag         ✓
analytics / routing  ✓
UI states / fallback ✓
tests and build      ✓

05 / PROMPTING复杂提示词没有赢，防御式编程赢了

论文还在 Claude Code + GLM 4.6 上测试了 12 种提示策略。Baseline 与“防御式编程”提示的完整任务成功率都是 10%，但后者把单项测试通过率从 19.3% 提升到 26.7%，增加了 7.4 个百分点。它没有多完成整道题，却更好地处理了边界情况。

相反，角色描述很长、检查清单繁复、上下文堆得很多的提示，任务成功率只有 4%。论文给出的信号不是“永远少写提示词”，而是：工作流说明越复杂，越可能挤占 Agent 对真实需求和代码的注意力；能直接约束代码质量的短规则，比表演式的推理仪式更有用。

好的提示词不是替 Agent 写一篇项目管理手册，而是把最容易漏掉的工程不变量放到它眼前。

06 / LIMITS为什么这篇论文还不能证明“Agent 只能完成 12%”

首先，样本只有一个公司的单一 iOS 代码库和 50 个任务。它很真实，但不能代表 Android、Flutter、React Native 或所有企业架构。其次，提示词消融只在一个 Agent–模型组合上完成，别的模型可能对同一策略反应不同；论文中的 API 价格也只是实验当时的快照。

更关键的是 diff-based evaluation。它可以查出结构遗漏，却无法发现界面像素偏差、生命周期错误、内存问题、并发竞态或特定系统版本上的崩溃；模式匹配也可能错罚结构不同但行为正确的实现，或放过“看起来改对、运行却失败”的补丁。作者已把模拟器运行评测列为后续工作。

最后，私有代码与隐藏测试能减少训练数据污染，也保护企业资产，但外部研究者无法完全审计任务分布和裁判细节。把结果理解为一个高价值的工业切片，比把 12% 当作普遍自然定律更准确。

07 / PRACTICE今天怎样把 Agent 放进真实团队

这项研究支持的不是“停用 Agent”，而是一种更清醒的分工。Agent 已经能在复杂仓库中产生实质进展，却还不适合独自承担交付责任。团队应把它当成高吞吐的协作者，并让完成定义、验证层和权限边界跟上生成速度。

选择工具时，用自己的仓库做端到端评测，记录任务成功率、人工接管次数、耗时和总成本；不要用单轮代码生成分数代替系统能力。提示词则保持短而可执行：优先强调输入校验、错误处理、Feature Flag、兼容性与完成前的全局复查。

SWE-Bench Mobile 最终把一个模糊争论变成了可测问题：Agent 不只是要写出代码，还要理解 PRD、读取视觉设计、找到正确文件、服从生产约定并交出完整补丁。最高 12% 并不是终点，而是一条清楚的工程路线图——下一代编码 Agent 的进步，将更多来自更好的上下文、工具、记忆与验证闭环，而不只是更大的模型。