手机Agent不是“稳定API”：真正要评估的是接口契约、数据稳定性和权限边界

AH-0160拆解Airtap，用一个手机Agent操作真实Android应用，并把它描述成某种“App API”。

这篇技术内容很值得留下，因为它抓到了一个正在扩大的方向：

> 当官方API不存在、能力不足或覆盖不到App内流程时，Agent可以通过UI层完成操作。

截至2026-08-14，Airtap官方仍明确提供：

• 云手机；
• 物理设备AutoPilot；
• 定时Routine；
• 任务历史；
• 通过SKILLS.md接入Claude、Codex、OpenClaw等Agent。

官方GitHub airtap-ai/airtap-skill 也仍公开，README提供Claude Code/Codex安装方式和任务创建、查询、追加、取消等能力。

但这不意味着：

手机Agent = 官方API。

这是本篇最需要重新定义的地方。

一、接口稳定和数据稳定是两件事

源作者做了两次相同任务，操作步骤基本一致，但拿到的“热门”结果重合很低。

这个观察很有价值。

UI Agent通常至少有三层稳定性：

1. Task Contract

你给Agent的任务描述是否稳定。

2. Interface Contract

Agent调用层返回的字段、状态、任务ID、错误码是否稳定。

3. Data/Experience Layer

App此刻给这个账号、地点、时间显示了什么。

第三层可以非常不稳定。

原因可能包括：

• 个性化推荐；
• A/B测试；
• 登录状态；
• 地理位置；
• 时间；
• 内容更新；
• 排序算法；
• UI版本。

所以：

> 结构可重复，不代表结果可重复。

二、UI Agent不能继承官方API的语义保证

官方API通常明确规定：

• Endpoint；
• Schema；
• Authentication；
• Rate Limit；
• Version；
• Error；
• Deprecation。

UI Agent操作App时依赖的是：

当前界面。

界面不是为机器契约设计的。

按钮可能改名。

布局可能变化。

弹窗可能出现。

App可能要求重新登录。

推荐流本身也可能因账号画像变化。

因此“能连续跑几次”只能证明：

当前条件下可运行。

不能证明：

长期API稳定性。

三、延迟必须进入产品设计

源文实测单次任务达到分钟级。

这对很多后台任务没问题。

比如：

• 每天一次巡检；
• 每周一次信息收集；
• 夜间批处理；
• 低频报表。

但如果你要：

• 实时搜索；
• 即时客服；
• 高频数据接口；
• 用户等待页面；

分钟级延迟就可能不合适。

所以Mobile Agent必须先分类：

Async Workflow 允许分钟级。

Interactive Workflow 需要秒级。

Real-time Workflow 通常不适合UI Agent。

四、登录态不是“配置细节”，是权限边界

一旦Agent操作真实账号，风险模型完全变化。

它可能：

• 看见私信；
• 点赞；
• 发布；
• 下单；
• 修改设置；
• 删除内容；
• 发送消息。

所以每个任务必须区分：

Read 只看。

Draft 生成但不提交。

Write 会产生外部状态变化。

Transaction 涉及钱、订单、账户或高后果动作。

越往下，Human Approval要求越高。

五、“能看到节点树”不是鼓励逆向平台的理由

源文讨论了Android resource-id、节点树、选择器和爬虫反推。

这部分不进入公开操作教程。

原因不是技术本身不能研究。

而是当它被用于：

• 绕过平台限制；
• 未授权持续抓取；
• 规避滑块/设备指纹；
• 批量账号；
• 反检测；

就从“自动化能力”进入平台规避和滥用。

alphahole保留的是：

UI Agent Reliability

不提供：

Platform Evasion Playbook。

六、任务恢复比“自动化成功一次”更重要

手机Agent很容易遇到：

• 网络失败；
• App崩溃；
• Agent中断；
• 登录过期；
• 权限弹窗；
• 页面结构变化。

所以成熟系统必须设计：

Task ID 任务唯一标识。

State Queued / Running / Waiting / Completed / Failed。

Retry 什么错误可以重试。

Idempotency 重试会不会重复发帖、重复购买、重复提交。

Resume 中断后从哪里继续。

Human Escalation 什么时候必须叫人。

这比“Agent能点App”更接近生产级能力。

七、隐私声明必须区分“产品官方主张”和“独立验证”

Airtap官网当前声称：

• 密码字段被屏蔽；
• Agent不读取密码；
• 云手机隔离；
• 会话在退出时清除。

这些属于：

CURRENT_VENDOR_CLAIM。

在没有独立安全审计材料时，不能升级成：

已独立证明的数据安全事实。

因此企业或高敏感用户还应继续检查：

• Privacy Policy；
• Terms；
• 数据保留；
• 第三方处理商；
• 截图/任务日志；
• 访问控制；
• 删除路径；
• 合规要求。

八、真正适合手机Agent的任务长什么样？

适合：

• 没有高质量API；
• UI任务低频；
• 允许异步；
• 错误可恢复；
• 操作结果可验证；
• 权限范围清楚；
• 人工有替代路径。

不适合：

• 高频实时数据；
• 高价值金融交易；
• 一次错误不可逆；
• 强平台禁止自动化；
• 大规模未授权采集；
• 需要精确一致数据的分析。

九、它最大的商业价值可能不是“替代API”，而是补齐最后一公里

很多企业系统已经有API。

真正缺的是：

“最后一步还只能让人打开App点一下。”

Mobile Agent有机会做的，就是：

> 把API世界和UI世界接起来。

例如： 系统已经判断某个任务该执行。

但最终动作发生在：

• 一个没有API的App；
• 一个旧系统；
• 一个内部移动端；
• 一个必须走真实UI的流程。

这时手机Agent是Adapter。

不是“万能API”。

网站资产：Mobile Agent Contract Lab

本批实际生成 mobile_agent_contract_lab.html。

你输入一个手机自动化任务，它会检查：

Task / Latency / Interface Contract / Data Stability / Authentication / Permission / Write Risk / Retry / Idempotency / Human Approval / Privacy / Platform Rule / Recovery。

输出：

GOOD ASYNC FIT / UI FRAGILE / REAL-TIME MISMATCH / PERMISSION RISK / PLATFORM REVIEW / HUMAN GATE REQUIRED

这比问：

“这个Agent能不能抓小红书？”

更成熟。

真正的问题应该是：

> 这个任务即使技术上能跑，能不能稳定、合规、可恢复地进入生产？