银行App没有API，AI智能体就直接操控手机

当应用永远不开门，智能体从何入手

大多数银行类App都没有对外开放的接口，而且这种状态很可能永远不会改变。对于AI智能体而言，这意味着一道硬墙：任何本可以帮你处理事务的智能体，走到登录界面那一步就被挡住了。没有API，就没有合法的程序化入口。

既然应用这扇门永远不会打开，剩下的思路就变得有趣起来——不去敲门，而是直接把手机本身交给智能体操作。这正是一种新的技术路线所做的事：通过一根线缆，从 Mac 连接手机，让智能体以人类使用触屏的方式，直接驱动真实设备。

把屏幕变成文本，而不是图片

这套方案最核心的巧思，在于它把屏幕内容以文本而非图像的形式传给智能体。这个区别看似微小，影响却很大。

当屏幕以图片形式传递时，智能体只能依赖视觉模型去"猜"像素里有什么——哪里是按钮、哪里是输入框，识别误差难以避免。而当屏幕以文本形式呈现时，智能体读到的是真实的标签（labels），它知道这个元素叫什么、代表什么功能，而不是对画面做概率性推断。

更有意思的是，即便是那些禁止截屏的App，这套方案依然能把界面绘制成线框图（wireframes），而非真实截图呈现出来。这意味着那些出于安全考虑屏蔽图像捕获的敏感应用，依然能被结构化地"读懂"。

这里的"文本化读取"在技术上依赖的是系统级的无障碍访问树（Accessibility Tree）。iOS 和 Android 系统为了支持视障用户使用屏幕阅读器，在每个 UI 元素背后都维护了一棵描述其语义的树状结构，记录了按钮名称、输入框类型、元素层级等元数据。通过 USB 连接和调试协议（如 iOS 的 XCTest 框架或 Android 的 UIAutomator），外部程序可以直接读取这棵树，而完全不需要对屏幕像素进行任何图像识别。这与 GPT-4V 或 Gemini 那类"截图→视觉理解→操作"的路线在架构上截然不同：前者是确定性的结构化读取，后者是概率性的感知推断。正因如此，即便 App 禁用了截图 API（常见于支付、银行类应用），无障碍树依然可读，线框图的生成本质上也是对这棵树的可视化重建，而非对屏幕像素的捕获。

诚实的第三种结果：unknown

每一次点击操作返回时，都会被明确标记为三种状态之一：成功、失败，或者真正意义上的未知（unknown）。

第三种答案才是最诚实的。现实中大量自动化工具会刻意回避"不确定"这个状态，倾向于给出一个确定的成功或失败判断，哪怕它并不真的知道结果。这种假装确定的行为，在金融操作这种高风险场景里尤其危险——一笔转账到底成没成，含糊不得。

如实承认"我也不知道这次点击的结果"，反而让整个系统更值得信任。它把判断权交还给用户，而不是用虚假的确定性掩盖风险。

可回放、开源且免费

这套工具还支持回放已录制的操作流程，也就是说同一件事务只需成功执行一次，之后可以重放，不必为同一个任务重复踩坑、重复付出错误成本。对于需要周期性重复的操作，这是实用的效率提升。

在授权上，它采用 MIT 许可证，完全免费，并通过一个工具服务器（tool server）与智能体通信，接入方式相对标准化。

这里提到的**工具服务器（tool server）**对应的是 AI 智能体生态中的 MCP（Model Context Protocol） 或类似的工具调用协议。其工作方式是：智能体（如 Claude、GPT）通过标准化的函数调用接口向工具服务器发送指令（例如"点击坐标 X,Y"或"在输入框中输入文字"），服务器再将这些指令转译为对物理设备的实际操作，并将执行结果（含上文所述的成功/失败/未知状态）返回给智能体。这种架构的好处是智能体本身与设备操控逻辑解耦——更换智能体模型或设备类型，不需要重写核心逻辑。回放功能也是在工具服务器层面实现的，通过记录操作序列的 JSON 日志，可在不重新调用大模型的情况下直接重执行，从而节省推理成本。

真实的成本在哪里

天下没有免费的午餐。这套方案的代价是实打实的：你需要一台 Mac、一根线缆，以及每次点击大约四秒的耗时。

四秒一次点击，意味着它不适合追求高速批量操作的场景，更像是面向那些"没有别的办法"的受限环境——当目标应用铁了心不开放任何接口时，用物理设备操控成为唯一可行的路径。

一个值得思考的方向

这个思路揭示了AI智能体落地过程中一个被低估的现实：并非所有系统都愿意或能够提供API。银行、政务、各类封闭生态，都可能长期保持这种封闭状态。

与其等待这些系统开放，不如换个角度——让智能体像人一样使用设备。文本化的界面读取、诚实的状态反馈、可回放的执行记录，这些设计让"手机即入口"从一个粗糙的点子变成了一个工程上说得通的方案。

正如原作者所言：你的银行从来就不打算为你开门，那么现在，手机本身就是那扇门。