摘要arXiv 论文《SWE-Bench Mobile》提出了一个面向工业级移动开发的 Coding Agent 基准。它不是让模型解算法题也不是修一个小 bug而是让 Agent 面对真实 PRD、Figma 设计、大规模 Swift/Objective-C 代码库和测试套件。结果很有冲击力22 个 agent-model 配置中最佳任务成功率只有 12%。这说明当前 Coding Agent 已经能做局部代码工作但距离稳定完成工业级移动功能开发仍有明显差距。背景现有代码基准太像“练习题”过去几年代码模型评测常见于 HumanEval、MBPP、SWE-Bench 等基准。它们推动了模型能力进步但和真实软件工程仍有距离。算法题太短缺少项目上下文传统 SWE-Bench 更接近真实 issue但主要集中在 Python、文本描述和 bug fix。真实移动开发复杂得多。工程师不仅要读需求还要看设计稿理解交互找到相关文件遵守项目已有模式修改多个模块并确保 UI、数据模型和 feature flag 一起工作。SWE-Bench Mobile 正是针对这个缺口设计。它把 Coding Agent 放进一个更接近真实业务开发的环境里PRD Figma 生产级 iOS 代码库 测试。基准怎么设计论文介绍SWE-Bench Mobile 包含 50 个来自真实产品需求的移动开发任务代码库规模约 5GB语言是 Swift 和 Objective-C。每个任务要求 Agent 输出一个 unified diff patch然后由任务对应的 pytest 测试套件检查补丁是否满足需求。这个设计有几个关键点。第一它测试的是 feature implementation而不只是 bug fix。Agent 需要从需求出发把功能真正接进已有工程。第二它包含多模态输入。70% 的任务包含 Figma 设计92% 包含参考图。Agent 不仅要理解文字还要把视觉设计转成代码结构。第三代码库是大规模混合语言项目。Swift/Objective-C 比 Python 更少出现在公开训练数据里也更接近许多企业移动端项目的真实状态。第四评估以 patch 为单位。测试关注 diff 是否触及关键文件、是否包含必要 UI 和数据逻辑、是否满足 PRD 意图而不是只看文本答案。关键结果最佳成功率只有 12%论文评估了四类 Coding AgentCursor、Codex、Claude Code 和 OpenCode组合多个模型总共 22 个配置。最好的配置任务成功率只有 12%。这个数字不高但非常有价值。它提醒我们当前 Agent 在局部任务上看起来很强但一进入工业级移动开发短板会被放大。更细看结果测试通过率最高能到 28.1%明显高于任务成功率。这说明 Agent 经常能做出部分正确修改但很难一次性完成所有要求。它可能改对 UI漏掉数据模型可能找到部分文件漏掉 feature flag可能实现主路径没覆盖边界条件。对研发团队来说这比“能不能写代码”更接近真实问题AI 经常能帮上忙但离“独立完成复杂需求”还有距离。Agent 架构和模型同样重要论文里最值得关注的发现之一是同一个模型在不同 Agent 中表现差异很大。例如 Opus 4.5 在 Cursor 上达到 12%在 OpenCode 上只有 2%相差 6 倍。这说明模型能力不是全部。Agent 的 scaffolding包括代码检索、上下文管理、文件编辑策略、测试迭代、错误恢复和工具编排都会显著影响最终结果。这也解释了为什么商业 Agent 往往比开源替代更强。它们不只是接了一个大模型还在编辑器集成、项目索引、上下文选择、交互循环和失败恢复上投入了大量工程。因此企业评估 AI 编程工具时不应该只问“底层模型是谁”还要问它如何理解项目如何选择上下文如何迭代测试如何处理跨文件修改复杂度会迅速击穿 Agent 能力SWE-Bench Mobile 的结果显示任务复杂度对成功率影响很大。需要修改 1-2 个文件的任务成功率约 18%而需要修改 7 个以上文件的任务只有约 2%。小补丁成功率也明显高于大补丁。这和很多开发者的体感一致。Agent 很擅长局部改动补一个函数、修一个测试、改一个组件。但当任务涉及多个模块、状态流转、UI 设计、配置开关和业务边界时它更容易漏掉关键连接点。工业级开发难点往往不是写某一段代码而是知道哪些地方都要改。当前 Agent 在跨文件推理和项目级一致性上仍然不稳定。对研发团队的实践建议第一不要把复杂需求一次性丢给 Agent。把任务拆成定位、方案、局部实现、测试补齐、回归验证几个阶段更容易得到可靠结果。第二把 Agent 用在部分进度上而不是幻想一次完成。它可以帮助读代码、找入口、生成候选补丁、补测试但最终集成仍需要工程师审查。第三优先建设项目索引和验证工具。Agent 的效果不仅取决于模型还取决于它能否获得正确上下文和快速反馈。第四评估 AI 编程工具时使用自己的真实任务。公开 benchmark 只能提供参考企业代码库的语言、架构、测试、规范都不同。第五关注“部分正确”的价值。即使任务成功率不高只要 Agent 能稳定减少定位和样板代码时间也可能带来生产力提升。风险与限制SWE-Bench Mobile 是非常有价值的基准但也有边界。它基于特定 iOS 生产代码库不一定代表所有移动项目。它使用 diff-based 测试能规模化评估意图和结构但不能完全替代真实编译、模拟器运行和人工 UI 审查。另外论文评估的是一组特定 Agent 和模型配置。工具迭代很快结果会变化。但它揭示的趋势很稳真实工业软件工程远比单点代码生成复杂。结论SWE-Bench Mobile 的核心信号是Coding Agent 已经进入真实工程任务但还没有稳定跨过工业级复杂度门槛。对研发团队来说正确姿势不是高估也不是低估。不要指望 Agent 独立完成复杂移动功能也不要忽视它在代码理解、局部实现和测试迭代中的价值。更务实的路线是把 Agent 纳入工程流程用清晰任务拆分、强验证工具和人工审查把它从“会写代码的助手”逐步变成“能参与软件交付链路的协作者”。参考来源arXivSWE-Bench Mobile: Can Large Language Model Agents Develop Industry-Level Mobile Applications?2026-02-10https://arxiv.org/abs/2602.09540