行代码让智能体操作iPhone：会用App但仍难完全自主

编辑 | 王凤枝

如今，Claude Code 和 Codex 也已经可以直接操作 iPhone 了。

近日，开发者肖恩·帕纳（ShawnPana）发布了一个仅有约500行核心代码的开源项目 phone-harness。它既不要求每一款 App 单独开放接口，也不需要对 iPhone 进行越狱，而是借助苹果自带的“iPhone 镜像”功能，让 Claude Code 或 Codex 直接查看并操控一部真实的苹果手机。

截至8月13日，这一项目在 GitHub 上已获得约1660个星标，作者发布的相关帖子浏览量也接近69万次。

在项目提供的最小工作流里，如果智能体要打开天气 App，会先截取 iPhone 镜像窗口，再利用苹果 Vision 框架识别屏幕上的“天气”文字及其坐标，随后模拟一次点击。等界面稳定后，它还会重新截图并识别文本，以确认天气预报页面是否已经成功显示。

整个流程并不会读取 App 的内部结构，也不会调用天气 App 的专用 API。对智能体而言，屏幕上看得见的内容，就是它执行操作的唯一依据。

过去，想让软件代替人完成手机操作，通常离不开两条老路：要么依赖 App 开放 API，要么由开发者针对某个固定界面单独编写脚本。phone-harness 显然没有走这条常规路径：既然人可以盯着屏幕识别按钮并完成点击，AI 智能体同样可以把图形界面直接当作一种通用接口来使用。换句话说，理论上只要某项功能能够通过 iPhone 镜像完成操作，就不必再等待 App 厂商专门为 AI 做接入。

这种方案的代价也很明显：智能体面对的不是结构清晰、权限明确的程序接口，而是一块随时可能变化的手机屏幕。它可能误认按钮，也可能碰到发送、支付或删除等敏感操作。为降低使用风险，项目在说明文档中要求，执行发消息、购买、删除以及修改设置等动作前，智能体必须先征求用户确认。

这个刚刚走红的开源项目，既展示了手机智能体的现实可能，也抛出了一个更实际的问题：当 AI 已经能自己动手操作手机时，它每一步能做什么、不能做什么，又该由谁来决定？

01没有DOM，也没有App API，它怎样找到按钮

phone-harness 仅用约500行核心代码就能让智能体控制 iPhone，关键原因在于它并没有重新实现一套手机控制系统，而是建立在苹果现成的“iPhone 镜像”功能之上。项目真正控制的并不是 iPhone 系统本身，而是 Mac 上已经打开的镜像窗口。

苹果负责将手机画面投射到 Mac，并把鼠标和键盘操作转发回 iPhone；phone-harness 则负责识别屏幕内容、判断点击位置并发出相应指令。它本质上做的，是把苹果原本提供给人类用户的控制入口，进一步交给 AI 智能体来使用。也正因如此，代码规模可以非常精简，但识别错误、异常页面以及敏感操作授权等问题，并不会因此自动消失。

第一步是“看屏幕”。

项目会截取镜像窗口，再使用苹果 Vision 框架进行 OCR（光学字符识别），获取屏幕中的文字及其大致坐标。它拿到的不是 App 内部结构，而只是一张截图和一组文字坐标：既不知道哪个元素是按钮、哪个区域属于输入框，也无法看到像网页 DOM 那样的页面层级关系。

换句话说，智能体拿到的本质上仍是一张图片，只不过图片中的部分文字被额外标注了位置坐标。

第二步才是“执行操作”。

智能体会根据任务目标和当前截图选择一个目标位置，phone-harness 再通过 macOS 的 CGEvent 输入事件，把点击、长按、拖动和键盘输入发送到 Mac 上的镜像窗口，再由 iPhone 镜像转发给手机。因此，这个项目不需要为天气、备忘录或各类第三方 App 分别开发独立控制接口。

智能体完成点击之后，还必须确认操作是否真的生效。界面发生变化后，项目会再次截图、重新识别文字，判断目标页面是否已经打开、所需内容是否已经出现，再决定是继续输入、继续滑动，还是停止操作。看屏幕、选坐标、执行动作、核对结果，由此构成一个不断循环的操作闭环。

这也正是它与传统 API 调用之间最本质的区别。API 会直接告诉调用方可用数据、当前状态，甚至失败原因；而 phone-harness 能依赖的，只有屏幕此刻显示出来的内容。它确实绕开了逐个对接 App 的繁琐流程，但代价同样清晰：智能体必须自己读懂界面、自己判断操作是否真正完成，还要随时应对突然弹出的提示框和不断变化的页面。

02所有App都像能用了，所有App也都可能点错

这套方法最吸引人的地方，在于同一种操作方式可以跨 App 复用。无论是天气、备忘录，还是各种第三方应用，phone-harness 都不需要提前为它们编写专用接口，只需要识别当前画面，再找到对应的文字、图标或按钮进行点击。对它来说，不同 App 的差别，首先只是屏幕布局的差异。

但这种通用性恰恰来自于它对 App 内部结构几乎一无所知。项目文档也明确指出，OCR 只能识别文字，却无法真正理解界面元素的语义；对于没有文字标签的图标，还需要结合截图交给具备视觉能力的模型来进一步判断。

如果按钮位置变化、弹窗遮挡页面，或者同一个词同时出现在多个位置，智能体面对的仍然是一张需要重新判断的画面，并不会收到像 API 那样清晰明确的错误提示。

例如，iPhone 镜像在闲置一段时间后，可能会停留在一个锁定页面，要求用户通过 Touch ID 或输入 Mac 密码才能继续。按理说，phone-harness 在这种情况下应该停止后续操作；但有用户反馈，它仍然把这个页面识别为“可继续操作”。这样一来，智能体下一步原本打算输入到搜索框里的内容，就有可能被误填进当前的密码框。问题不在于智能体获取了密码，而在于它没有识别出自己已经进入了错误页面。

虽然个别案例并不能说明所有用户都会遇到同样的问题，但它至少证明了一点：当系统主要依赖屏幕文字来判断状态时，只要漏掉一种中间页面，后续动作就可能被发送到完全错误的地方。

除此之外，它还存在不少现实局限。根据项目说明和苹果官方文档，phone-harness 一次只能控制一部手机和一个镜像会话，无法完成双指缩放等多点触控操作；相机、面容 ID 相关流程也不能通过镜像直接使用，受数字版权保护的视频内容还可能只显示黑屏。也就是说，这条路径虽然省去了逐个 App 接入 AI 的麻烦，但苹果 iPhone 镜像本身的能力边界依然存在。

在查看天气、翻找设置时，即便识别错了，通常还可以重新截图再尝试一次。但如果下一步动作是发消息、确认购买或者删除内容，那么一旦点错，就往往不存在“再试一次”的机会。

03真正缺的不是手，而是每一步的确认

phone-harness 并没有绕过苹果或 macOS 的安全机制。要让它真正操作 iPhone，用户首先必须主动开启两道关键权限。

第一道是苹果侧的设备授权。Mac 与 iPhone 需要登录同一个苹果账户，并开启双重认证；首次配对时，还需要在实体 iPhone 上手动确认。用户可以设置为每次连接都必须通过 Touch ID 或 Mac 密码认证，也可以随时撤销某台 Mac 的 iPhone 镜像权限。

第二道是 macOS 终端权限授权。运行 phone-harness 的终端必须获得“屏幕录制”权限，才能看到 iPhone 镜像窗口；同时还必须拥有“辅助功能”权限，才能执行点击和键盘输入。没有用户在系统设置中明确放行，这个项目既无法读取屏幕内容，也无法真正操作手机。

但这两道权限解决的，本质上都是范围更大的访问控制问题：哪台 Mac 可以连接这部 iPhone，哪个终端可以操作镜像窗口。用户一旦授权，它们并不会在智能体每次准备发消息、下单购买或删除内容时再次逐项确认。

因此，phone-harness 在使用说明中额外增加了一条规则：当遇到发送消息、公开发帖、购买、删除以及修改设置等对外或难以撤销的操作时，智能体必须先停下来询问用户；在浏览照片、邮件等个人内容时，也只能查看完成任务所需的最小范围。

问题在于，“敏感操作前先询问用户”目前主要还是一条使用规范，还不是程序内部的强制拦截机制。如果智能体没有停下来征求确认，phone-harness 的核心程序并不会自动弹窗阻止，仍然能够继续点击、输入或滑动。Claude Code 和 Codex 的权限提示，主要确认的是某段命令是否可以执行，通常不会把命令中包含的发送、购买、删除等手机动作逐条拆开，再分别向用户发起确认。

简单来说，苹果和 macOS 解决的是“能不能把这部手机交给这台 Mac 和这个终端来控制”，而 phone-harness 仍然需要解决“当前这一步到底能不能做”。目前，后一个问题主要依赖智能体自觉遵守使用说明。若想让 AI 智能体更安全地进入用户手机，项目还需要把这种逐步确认机制做成程序层面无法跳过的功能。

04从“能操作”到“能托付”，中间还差一层

phone-harness 目前仍是一个刚刚发布的开源项目，还无法证明智能体已经可以稳定操作所有手机 App。但它确实展示了一种新的方向：即使 App 没有专门为 AI 开放接口，只要某项功能能够出现在 iPhone 镜像中，智能体就有机会像人一样看着屏幕完成操作。

不过，查询天气和发送消息显然不是一回事，打开 App 和确认付款也完全不是一个级别的问题。手机 AI 智能体接下来真正要解决的，不只是还能操作多少 App，更关键的是区分清楚：哪些动作可以自动完成，哪些动作必须暂停下来，让用户看清后果并再次确认。

用户允许智能体控制手机，并不等于默认允许它发送每一条消息、完成每一笔购买，或删除每一份重要内容。这件事其实并不复杂：只要在敏感操作执行前停一下、说明可能后果，并让用户明确确认，智能体才有可能真正被放心地放进用户的日常任务流程中。