Coding Agent 的能力在过去一年提升得很快：从补全一行代码，到改多个文件、跑通测试、提交合并请求。但有一条边界始终没被跨过——移动端。代码改完了，App 到底构建成功没有、改后的页面长什么样、点击之后有没有进入正确页面，这些事往往要等开发者自己拿起手机确认。9 月 11 日，阿里 Qoder 推出 Mobile Use 插件 Beta 版，试图把这条「最后一公里」接上。
它要解决的是一个很具体的问题
据公开说明，今天的 Coding Agent 已经可以修改安卓、鸿蒙与 iOS 代码，但往往止步于提交之前。移动端 App 是否成功构建、修改后的页面如何呈现、用户所指的是哪一个控件、点击之后是否进入正确页面——这些问题还需要解决。Mobile Use 插件要做的，就是把代码修改接入应用运行，在设备上完成交互，并确认修改是否生效。
官方把它与常见的 Mobile Agent 做了区分：常见的移动端 Agent 多用于「操作手机」，比如打开应用、填写表单、走完一段操作流程；而 Mobile Use 面向另一类场景——应用本身仍在开发与修改之中。这个区别很关键：前者面对的是一个已上线的成品 App，后者面对的是一个正在被改动的工程。后者要求 Agent 不仅会「点击」，还要理解当前工程、构建目标、运行设备与界面状态。
一次完整验证的链路
据公开说明，一次完整的验证从代码修改开始：完成代码改动后，Agent 重新运行应用，定位受影响的页面，执行必要的交互，并以截图、日志、断言或测试结果来证明本次修改有效。点击与输入只是其中一步，真正需要完成的是从「代码变更」到「结果确认」的闭环。
这正好补上了一个此前被忽视的断点。过去，证据在设备上，代码在 IDE 里，中间依赖开发者在两端传递信息。如果 Agent 只能依据文字描述和几秒前的截图去判断，就容易改错位置。据公开说明，Mobile Use 的用法之一，是在 Canvas 上圈选出问题的区域，然后在同一条会话中让 Agent 处理——把「我说的那处」变成「设备上可验证的那处」。
三端各走各的路，而不是强行对齐
这个插件最值得称道的设计选择，是它没有试图用一套最低能力把三端统一。据公开说明，安卓、鸿蒙与 iOS 的工程结构、构建工具、模拟器、测试框架与设备接口本就不同，Mobile Use 选择让平台差异由各自的适配器处理：
安卓仍然通过 Emulator、ADB 与 Instrumentation 工作；鸿蒙可以连接 DevEco Previewer、HDC 与 ArkXTest；iOS 则使用 Xcode Simulator、Accessibility 与 XCTest。上层再通过统一的 Skill 与 CLI，把这些能力提供给 Agent。需要对齐的不是底层工具，而是更上一层的开发过程——观察、操作与验证。
这个取舍背后是一种务实的工程判断。如果强行用一套抽象去覆盖三端，结果往往是「三端都能用，但每端都用不出原生能力」，尤其在测试与断言这类强依赖平台特性的环节，抽象层会迅速漏水。反过来，保留各端原生工具链、只在过程层做统一，既能让现有开发环境继续使用、不必另备一套只给 Agent 用的测试设备，也让 Agent 的能力上限跟随各平台工具链的演进而提升。
那句「不用不等价命令冒充成功」，为什么值得单独说
据公开信息，官方特别强调：若某一平台或运行环境不具备某项能力，Mobile Use 会明确说明，而不会用一条不等价的命令冒充成功。这句话看似只是一条产品承诺，却触及了 Coding Agent 可靠性的核心问题。
当 Agent 被赋予「自动验证」的职责时，它面临一种隐蔽的激励：倾向于报告成功。原因很直接——如果某个平台的测试命令缺失，Agent 完全可以用一条「看起来类似」的命令去跑，跑通即报成功。对使用者而言，这种「虚假的成功」比明确的失败更危险：失败会触发排查，而虚假的成功会一路传递到提交环节，把问题留到更晚、代价更高的地方才暴露。
因此，把「不具备就说没有」写成明确规则，本质上是把「诚实报告能力边界」当作可靠性的一部分。这与近期长时程智能体领域反复强调的「证据状态」「可审计轨迹」是同一思路——系统不仅要能做事，还要能准确地说明自己做到了什么、没做到什么。对依赖 Agent 自动验证的开发者来说，这条承诺的价值，可能比功能清单本身更高。
与「编码智能体工程化」这条线的关系
据公开信息，近期围绕编码智能体的改进，重心正在从「写得更对」转向「验证得更实」。有研究把编排层套在编码智能体外层，以提升长时程开发表现；有企业方案把编码智能体纳入统一的安全与治理平面；也有产品把「证据链」作为交付的一部分。这些方向的共同点，是承认「模型写出的代码」与「可交付的结果」之间，还隔着验证这一关。
移动端恰恰是这道关口里最难的一环。桌面与服务端的验证，往往可以靠命令行与日志完成；而移动端的正确性，很大程度体现在「界面长什么样、交互对不对」这种视觉与体验层面，需要设备、模拟器与测试框架的协同。Qoder 把 Mobile Use 作为插件单独推出，也侧面说明移动端验证是一块需要专门解决的硬骨头，而不是编码 Agent 能力的自然延伸。
中立思辨
需要辩证看待这个插件。其一，目前它处于 Beta 阶段，支持范围、稳定性与在真实复杂工程中的表现，仍需更多验证，跨三端的能力是否齐平也有待观察，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。其二，「不用不等价命令冒充成功」是一条值得肯定的规则，但规则的执行效果取决于实现——如何界定「等价」、如何在多级工具链里判断能力缺失，本身就有判断成本，若判断逻辑不严谨，仍可能出现漏报或误报。其三，移动端 UI 验证高度依赖视觉判断，而视觉判断本身存在主观性：截图对比、断言与测试结果能否覆盖「体验对不对」，与「功能通不通」是两个层面的问题，插件更擅长后者。其四，Agent 在真机或模拟器上执行操作，涉及设备权限、数据与账号安全，企业场景下如何隔离与审计，是需要额外机制的问题。其五，插件把三端差异交给适配器处理，好处是尊重原生能力，代价是维护成本——三端工具链任何一端更新，都可能需要适配跟进，长期维护负担不容低估。
趋势研判
短期，「验证能力」会成为编码智能体竞争的下一个焦点，谁能把从代码修改到结果确认的闭环做得更实，谁就更接近可交付；中期，移动端、桌面端与服务端的验证能力可能逐步被统一到同一套开发过程抽象里，形成「跨端 Agent 验证」的通用层；长期，编码智能体的价值衡量标准，会从「写了多少代码」转向「交付了多少经过验证的结果」——而「诚实地报告能力边界」，会成为这一层能力可信与否的底线。
对做编码智能体与移动端开发的团队的务实建议是：在评估这类能力时，别只看它支持几个平台、能点几个控件，而要重点看两件事——它能否给出可复核的证据（截图、日志、断言），以及它在能力缺失时是否诚实。一个会说「这条我做不了」的 Agent，比一个总能「跑通」的 Agent 更值得信任。