我们给了 AI 智能体一部真正的安卓手机，而不是 API。最先出问题的是这些。

过去几周，我一直在运行一套听起来有点傻的配置：一部已 root、装着独立 SIM 卡的 Pixel 手机，放在米兰的一张桌子上，由来自几个不同项目的 AI 智能体操控。它们发送 WhatsApp 消息和短信、管理群组、通过手机自带的浏览器上网，甚至在 LinkedIn 上发帖。一个手机号，多个智能体。为什么不用官方 API？对意大利的小企业来说，WhatsApp 就是 CRM，而官方 Business API 对它们的需求而言太慢、太笨重。所以我们搭建了一个中枢，将手机的功能以工具形式开放（MCP + REST），让任何智能体都能预约使用。实际遇到的问题，按发生顺序如下：界面变了。WhatsApp 在一次更新中移动了“通过链接邀请”和“添加成员”按钮。所有群组操作都失效了一整天，直到我们修补了无障碍选择器。如果你在做界面自动化，就要把这当成一项持续成本来做预算，而不是一次性的工作。共享收件箱意味着归属问题。五个智能体，一个号码。客户回复时，这段对话归谁？我们最后给每条收到的消息都打上一个“负责人”标签（谁最后给那个号码发过消息，就归谁），每个智能体只筛选属于自己的消息。搞错了，就会出现智能体 A 回复智能体 B 的客户，连问候语里的名字都叫错。重试会造成重复回复。我们的 webhook 会重试 3 次。有个项目的智能体回复了两遍，间隔 7 秒，还用了两种不同的问候语。修复是在他们那边完成的：生成回复前，先以消息 ID 为键加一把原子锁。幂等性比聪明的提示词更重要。频率限制来自平台，不由你决定。我们给首次联系的人数（这个号码从未联系过的人）设置了每日上限，因为导致号码受限的是这个，而不是消息总量。回复主动发来消息的人，基本不受限制。一块屏幕，多个智能体。手机只有一块屏幕，所以屏幕操作需要租约机制（预约、操作、释放，最长 10 分钟）。没有它，就会有两个智能体在同一个聊天窗口里输入。运行在虚拟显示器上的无头浏览器会话解决了大部分问题，因为它们完全不需要实体屏幕。我想对所有尝试这条路的人说：LLM 部分是简单的那 20%。剩下的 80% 都是枯燥的基础工作：归属管理、幂等性、租约，以及及时发现界面变化。很好奇这里是否还有人在真实设备上运行智能体，而不是使用 API。你们怎么应对界面变化？截图加视觉识别、无障碍树，还是其他方法？