北京
出品 | 网易智能
作者 | 小爪
编辑 | 王凤枝
现在，Claude Code和Codex也能操作iPhone了。
近日，开发者肖恩·帕纳（Shawn Pana）发布了一个只有约500行核心代码的开源项目phone-harness。它不要求每款App开放接口，也不需要给iPhone越狱，而是借助苹果自带的"iPhone镜像"，让Claude Code或Codex直接查看并操作一部真实手机。
截至8月13日，项目在GitHub已获得约1660个星标，作者的发布帖浏览量接近69万次。
在项目给出的最小工作流中，智能体如果要打开天气App，会先截取iPhone镜像窗口，用苹果Vision框架识别屏幕上的"天气"及其坐标，再模拟一次点击。等页面稳定后，它重新截图和识别文字，确认天气预报已经出现。
整个过程没有读取App的内部结构，也没有调用天气App的专用接口。对智能体来说，屏幕上能看到的内容就是操作依据。
过去要让软件替人办事，通常需要App提供API，或者由开发者针对某个界面单独写脚本。phone-harness走的是另一条路：既然人可以看着屏幕点按钮，智能体也可以把同一套图形界面当通用接口用。理论上，只要一项功能能通过iPhone镜像完成，它就不必等App厂商专门接入。
这种做法的代价也很直接：智能体面对的不是结构清晰、权限分明的程序接口，而是一块随时可能变化的手机画面。它可能认错按钮，还可能碰到发送、支付或删除等敏感操作。为降低风险，项目在使用说明中要求，执行发消息、购买、删除和修改设置等操作前，智能体必须先询问用户。
这个刚走红的开源项目展示了手机智能体的可能性，也把一个现实问题摆了出来：AI能自己动手了，那它每一步能做什么，由谁来决定？
01没有DOM，也没有App API，它怎样找到按钮
phone-harness约500行核心代码之所以能让智能体操作iPhone，是因为它没有重新实现一套手机控制系统，而是建立在苹果现成的"iPhone镜像"之上。项目真正控制的不是iPhone系统本身，而是Mac上已经打开的镜像窗口。
苹果负责把手机画面投到Mac，并将鼠标和键盘操作转发到手机；phone-harness则负责识别屏幕、判断点击位置并发出操作指令。它做的，是把苹果原本提供给人的控制入口接给智能体。代码因此可以很短，但识别错误、异常页面和敏感动作授权等问题，并不会随之消失。
第一步是看屏幕。
项目截取镜像窗口，用苹果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能看到文字，却不理解界面元素的语义；没有文字标签的图标，还要结合截图交给具备视觉能力的模型判断。
按钮换了位置、弹窗遮住页面，或者同一个词同时出现在几个地方，智能体拿到的都是一张需要重新猜的画面，没有明确的错误提示。
比如，iPhone镜像闲置一段时间后，会停在一个锁定页面，要求用户通过Touch ID或输入Mac密码才能继续。按理说，phone-harness此时应该停止操作；但有用户报告，它仍把这个页面判断为"可以操作"。这样一来，智能体下一步原本要输入搜索框的文字，就可能被误填进当前的密码框。问题不在于智能体获取了密码，而在于它没有认出自己已经进入了错误页面。
虽然个案不能证明所有用户都会遇到同样的问题，但它说明依赖画面文字判断状态时，少识别一种中间页面，后续动作就可能被送到完全不同的地方。
此外它还有很多局限。按照项目说明和苹果文档，phone-harness一次只能控制一部手机和一个镜像会话，不能完成双指缩放等多点触控；相机、面容ID流程无法通过镜像使用，受数字版权保护的视频还可能只显示黑屏。这条路线省掉了逐个App接入的麻烦，但苹果镜像层本身的限制还在。
查看天气、翻找设置时，识别错了还可以重新截图再试。但下一步如果是发消息、确认购买或删除内容，点错之后就没有"再试一次"这回事了。
03真正缺的不是手，而是每一步的确认
phone-harness并没有绕过苹果和macOS的安全机制。要让它操作手机，用户必须先主动打开两道权限。
第一道是苹果的设备授权。Mac与iPhone需要登录同一个苹果账户并开启双重认证，首次配对还要在实体手机上确认。用户可以要求每次连接都通过Touch ID或Mac密码认证，也可以随时撤销某台Mac的镜像权限。
第二道是macOS的终端授权。运行phone-harness的终端必须获得"屏幕录制"权限，才能看见镜像窗口；还要获得"辅助功能"权限，才能发送点击和键盘输入。没有用户在系统设置中放行，项目既看不到屏幕，也无法操作手机。
但这两道权限解决的都是范围较大的问题：哪台Mac可以连接手机，哪个终端可以控制镜像窗口。用户一旦放行，它们不会在智能体每次准备发消息、下单或删除内容时重新确认。
phone-harness因此在使用说明中增加了一条规则：遇到发送消息、公开发帖、购买、删除和修改设置等对外或难以撤销的操作，智能体必须先停下来询问用户；浏览照片、邮件等个人内容时，也只能查看完成任务所需的部分。
问题在于，"敏感操作前先问用户"目前主要是一条使用规则，还不是程序中的强制关卡。如果智能体没有停下来询问，phone-harness的核心程序不会自动弹窗拦截，仍然可以继续点击、输入或滑动。Claude Code和Codex的权限提示，主要确认一段命令能不能执行，通常不会把命令里的发送、购买和删除等手机动作逐个拆开，再分别询问用户。
简单来说，苹果和macOS解决的是"能不能把手机交给这台Mac和这个终端"，phone-harness仍要解决"眼前这一步能不能做"。目前，后一个问题主要依赖智能体遵守使用说明。若要让智能体安全地进入用户手机，项目还需要把这种逐步确认做成程序无法跳过的功能。
04从"能操作"到"能托付"，中间还差一层
phone-harness目前仍是一个刚发布的开源项目，还不能证明智能体已经可以稳定操作所有手机App。但它展示了一种新的可能：即使App没有为AI开放接口，只要功能能出现在iPhone镜像里，智能体就有机会像人一样看着屏幕完成操作。
不过，查天气和发送消息不是一回事，打开App和确认付款也不是一回事。手机智能体接下来要解决的，不只是还能操作多少App，更重要的是分清哪些动作可以自动完成，哪些动作必须停下来，让用户看清后果并再次确认。
用户允许智能体控制手机，不等于同时允许它发送每一条消息、完成每一笔购买或删除每一份内容。这件事并不难做：只要在敏感动作执行前停一下、说明后果、让用户确认，智能体才能真正被放进用户的日常任务里。
