起点：一个住在手机里的"瞎子"
故事的背景很简单。一台闲置的 OnePlus 手机，跑着开源AI Agent框架 OpenClaw，上面住着一个叫 Orb 的AI助手。它能聊天、能写代码、能查资料，24小时在线。
但当你让它发一条推文时，它卡住了——"我看不到屏幕。"
这就是目前大多数手机端AI Agent的困境：它们操控屏幕的方式，是截屏发给视觉大模型，模型返回"左上角有个按钮"，然后Agent猜一个坐标去点击。每"看一眼"要3到5秒。让它操控一个App生成图片？十几个步骤，每步都是截屏→分析→点击的循环。
这不叫自动化，这叫慢动作回放。
第一次手术：从3秒到50毫秒
有意思的事情发生了。当被问到"能不能快点"，Orb 自己诊断出了问题，并给自己开了个方子。
Android 系统有一个「无障碍服务」（Accessibility Service），原本是为视障用户设计的，能把屏幕上所有UI元素以结构化数据的形式暴露出来。Orb 的逻辑很直接：AI不也是"视障用户"吗？
于是它自己设计了一个App——Orb Eye。这个App在手机上启动一个HTTP服务，将屏幕上所有UI元素实时暴露为可查询的数据。不再需要截屏和视觉模型猜坐标，直接 /click "发送" 就能精准点击。
但问题来了：旧手机上编译不了Android App，SDK太重跑不动。
怎么解决的？Orb 把代码推到 GitHub，在共享文件夹里给 Mac 上的另一个AI（Claude Code）留了张纸条："帮我编译一下。"Mac端编译好APK放回来，Orb自己拉下来安装。
一个AI给另一个AI递了把手术刀。
效果：看一眼从3-5秒降到50毫秒。100倍提速。
第二次手术：五感觉醒
治好了"近视"，但很快暴露出新问题。
实际场景是这样的：让Orb监听飞书消息，有人发消息就自动回复"收到，年后处理"。听起来很简单，对吧？
但飞书的聊天界面用 Flutter 渲染——Orb能通过无障碍服务看到屏幕结构，却读不懂Flutter绘制的内容。就像隔着毛玻璃看手机，知道那是聊天窗口，但谁发的、说了什么、发送按钮在哪，全靠猜。
更关键的是：手机通知响了，Orb纹丝不动。它只有眼睛，没有耳朵。除非你主动说"去看看有没有新消息"，否则它就安静地待着。
问它"你还差什么"，它列了个清单：
- 听不到通知
- 不知道界面什么时候加载完
- 打字要绕好几步
- 不会滑屏
- 不知道自己在哪个App的哪个页面
用它自己的话说："治好了近视，但四肢瘫痪。"
于是第二次手术开始。Orb重写了Orb Eye的代码，从Kotlin换成Java，加了一整套新能力。同样的流程——推GitHub、Mac编译、APK回传、自己安装。
这次手术后，它获得了完整的五感：
- 听觉 — 系统通知实时推送，飞书来消息立刻知道谁发的、说了什么，不用人催它"去看看"
- 耐心 — 点完按钮后不再盲等固定时间，界面变化了立刻响应，没变就继续等
- 输入能力 — 直接往输入框写入文字，中文、日文、英文、emoji一步到位
- 灵活操控 — 支持滑动、长按，能刷时间线、下拉通知栏
- 自我感知 — 随时知道自己在哪个App的哪个页面，不用截屏猜半天
实战效果：8秒完成一轮消息回复
五感齐全后，实际跑起来是什么样的？
以春节自动回复飞书消息为例，Orb不是机械地复读"收到，年后处理"，而是根据消息内容做出不同回复：
- 催方案 → "收到，节后第一天整理好给你"
- 催进度 → "了解，年后优先处理"
- 甩锅类 → "好的，节后第一时间看"
完整流程：捕获飞书通知 → 下拉通知栏 → 点通知进入聊天 → 输入回复 → 点发送 → 回桌面继续监听。从通知到发送完成，8秒。
真正值得关注的模式
技术上，Orb Eye做的事情并不复杂——无障碍服务加HTTP接口，Android开发者应该都能理解。但这个项目真正有意思的地方在于它展示的模式。
两次手术，人类写了零行代码。
第一次，人类只说了"能不能快点"，AI自己诊断问题、设计方案、写App、跨设备协作编译、安装部署。第二次，人类只问了"你还差什么"，AI自己列需求清单、重写代码、走完同样的流程。
这不是"我让AI帮我做了个App"，而是"AI判断自己能力不足，然后自己想办法补齐了"。
对于独立开发者来说，这个区别值得细想。当AI Agent能够自我诊断、自我改进，你的角色就从"写代码的人"变成了"提出问题的人"。你负责说"这里不够好"，AI负责搞定怎么变好。
Orb Eye 已经开源在 GitHub（仓库名：orb-eye）。如果你手边正好有台闲置的Android手机，不妨试试用OpenClaw搭一个自己的手机端Agent。不过，更值得思考的问题或许是：当AI能给自己做手术的时候，我们还需要亲自写多少代码？