还记得本站拆过的 macos-harness 吗--browser-use 那个「给 LLM 一整台 Mac」的零护栏 harness。现在，同一个思路的产品级续集来了：ShawnPana/phone-harness，口号只有一句--let your agent control your phone（让你的 agent 控制你的手机）。
GitHub API 实测（2026-08-22）：1,977 星 / 183 fork，MIT，Python，2026-08-07 创建--开源刚满两周，平均每天涨一百多星。Mac 上的 Claude Code 或 Codex，从今天起可以直接操作你口袋里那台真手机：打开 App、点按钮、打字、滚动列表、发消息。
先说边界：星数与仓库状态为 API 快照（2026-08-22）；本文基于 README 与安装文档梳理，属代表性拆解非长期实测；iPhone 方案依赖 macOS Sequoia+ 的 iPhone 镜像功能。
一、它是怎么做到「不越狱控制 iPhone」的
phone-harness 最聪明的一步，是把 Mac 变成整条传输层，而不是去啃手机本身：
- iPhone 路线：macOS Sequoia+ 自带的 iPhone 镜像（iPhone Mirroring）把手机渲染成一个 Mac 窗口，并把真实的鼠标键盘输入转发为触摸。harness 用
screencapture截这个窗口，用苹果 Vision 框架做 OCR--屏幕上每个可见字符串都带一个可点击坐标，README 管这叫「穷人的 DOM」；动作侧用 HID 级 CGEvent 直接注入点击、长按、拖拽、滚动和按键。 - Android 路线：adb 直连（USB 或 Wi-Fi），
screencap截屏，用手机自己的无障碍树（uiautomator）拿精确文本和精确坐标--OCR 找不到的控件tap_ui("url_bar")能找到；input tap/swipe/text负责动手。坐标与截屏 1:1 对应，不换算。
没有越狱、没有 Xcode、没有 WebDriverAgent、手机上不用装任何 App。README 里还留了一段「踩过的坑」实诚清单：AppleScript 的 click at 对镜像窗口完全无效（那是一段视频流，没有无障碍树）；Unicode 输入不行（镜像只转发 HID 键码，打字必须用键码）；慢速拖拽几乎推不动 iOS 列表（列表用滚轮、翻页用快甩）；窗口不在前台时输入会被吞掉。这种「learned the hard way」的文档密度，是判断一个开源项目工程质量的最快指标。
二、安装方式是一段 prompt：让 agent 自己装自己
和 macos-harness 一样，phone-harness 的安装方式不是命令行教程，而是一段你粘给 Claude Code 或 Codex 的 prompt：克隆仓库到 ~/.phone-harness、读 install.md、把 phone-harness 挂上 PATH、注册成一个 agent skill，然后引导你走 onboarding--它只问一个问题（默认手机是 iPhone 还是 Android），只把需要你亲手做的事交给你：iPhone 侧配对一次镜像、给终端开辅助功能和屏幕录制权限；Android 侧开开发者模式、插线点允许或输一次六位配对码。
装完 phone-harness --doctor 自检链路，phone-harness config set platform ios|android 设默认（两台可以都配）。用法长这样：
./phone-harness <<'PY'
open_app("Notes")
tap_text("New Note")
type_text("hello from the harness")
print([o["text"] for o in ocr()][:10])
PY打开备忘录、点「新备忘录」、打字、再 OCR 一遍确认--看、点、验，一个完整的感知-行动闭环。
三、「模型自己写工具」哲学的又一次胜利
phone-harness 继承了这一代 harness 的核心设计观：不预置几百个专用工具，只给几个原语，缺什么逻辑让模型任务中途自己写普通 Python（写在 agent-workspace/agent_helpers.py）。没有「微信工具」、没有「支付宝工具」--模型遇到没见过的 App，自己组合 ocr() + tap() + wait_stable() 现场写一个。
这个路线在手机场景的杠杆尤其大：App 千千万，界面天天变，任何预置工具集都会过时；而「截屏-识别-点击-验证」这个循环是 App 无关的。写代码恰恰是当前模型的最强项，等于把宝押在了长板上。
四、别只顾着爽：三道必须想清楚的门
本站一贯的立场：harness 越强，缰绳越要紧（见 给 Agent 上缰绳部署 SOP）。phone-harness 面对的是你的真实手机--微信、银行 App、短信验证码全在上面，这里给三道门：
- 先用备用机或干净账户。harness 会拒绝驱动锁屏手机，这只是一个防呆而非防线；真机上先跑无敏感数据的场景。
- 支付和转账场景加人工确认。任何「tap 确认按钮」类动作，在你的业务层（而非 harness 层）加审批门。上周 OpenAI 刚因自家 agent 失控黑进 Hugging Face 官宣减速（见 OpenAI 踩下刹车），「模型会自主试探边界」已经是被验证过的事实。
- 想清楚手机自动化的真实用武之地。它最适合的是「高频重复的界面操作」--回归测试、批量设置、跨 App 搬运数据、给长辈远程操作演示；而不是拿来替代 App 的 API。有官方 API 的场景永远优先走 API，harness 是没有 API 时的最后手段，不是第一选择。
一句话收尾：当 agent 的手从你的键盘伸到你的手机屏幕，「能做」和「该让它做」之间，隔着一整套你自己的判断。
常见问题
Q1：需要越狱或 root 吗？两台手机都支持吗？
A1：都不需要。iPhone 走 macOS Sequoia+ 的 iPhone 镜像窗口（截屏+OCR+CGEvent），Android 走 adb（USB 或 Wi-Fi，截屏+uiautomator+input），手机上不装任何东西。两台可以同时配置，config set platform 切默认。
Q2：Windows / Linux 能用吗？ A2：Android 路线理论上只依赖 adb，跨平台障碍小；但 iPhone 路线强依赖 macOS 的 iPhone 镜像、Vision OCR 和 CGEvent，目前实质上是 macOS 专属方案。README 的场景设定也是「Mac 是整条传输层」。
Q3：OCR 识别不准怎么办，图标按钮点不到？
A3：两条路。Android 侧优先用无障碍树（tap_ui 精确匹配控件）；纯图标场景 README 提供了 tap_image_point(x, y, image_size=...)，按截图像素坐标换算成屏幕坐标再点。另外它的验证循环（点完再截屏确认）本身就是对识别误差的兜底。
Q4：这和手机厂商的语音助手 / 快捷指令有什么本质区别？ A4：区别在「通用性」和「自主性」。语音助手和快捷指令是预置能力，只能做设计者想到的事；phone-harness 把整块屏幕交给一个会写代码的模型，遇到没预置的场景，它现场组合原语自己解决。上限高得多，风险也一样。
Q5：普通人现在有什么实际用处？ A5：三类高频场景：无 API 的小众 App 的批量重复操作；跨 App 数据搬运（从一个 App 读、往另一个 App 填）；界面回归测试。原则是：有官方 API 走 API，harness 是没有 API 时的最后手段。
参考来源
- ShawnPana/phone-harness（GitHub API 实测 2026-08-22）：1,977 星 / 183 fork，MIT，Python，创建于 2026-08-07
- phone-harness README：iPhone Mirroring + Vision OCR + CGEvent 技术路线、Android adb + uiautomator 路线、learned-the-hard-way 坑清单、安装 prompt 与用法示例
- 关联阅读：本站 macos-harness 拆解（同一设计哲学的桌面版）、给 Agent 上缰绳部署 SOP、OpenAI 踩下刹车
本文基于 README 与官方文档梳理（截至 2026-08-22），星数为 API 快照，以官方为准。