支付宝与阶跃用 AHA 接通生活服务，少数具名平台试验声明式接口
支付宝与阶跃用 AHA 接通生活服务，少数具名平台试验声明式接口
2026/07/18
支付宝与阶跃 7 月 17 日宣布系统级合作：STEPX Neo 上的 Amoo 可通过 AHA 调用阿宝的充电和咖啡服务，完成地址填写、商品推荐，并生成交由用户确认的订单。AHA 在这次合作中指一套任务协作接口，终端智能体传递用户意图，阿宝调用服务并回传状态；流程不依赖智能体模拟点击支付宝应用。[S1]
7 月 18 日另有媒体转述称，新一代豆包手机对头部应用不再采用读屏和模拟点击，改为要求应用提供 MCP 服务，即由应用主动开放相应数据和可执行动作，团队正与头部应用协商。[S2] 这两项是当天触发的完整新增事实，前者来自合作演示与合作方口径，后者是二手媒体报道，均没有生产成功率或调用规模数据。
当前证据只支持一个收窄判断：支付宝-STEPX、支付宝-OPPO 与被报道的豆包新路线，显示少数具名头部平台处于声明式接口的 exploration，也就是仍在探索和验证的阶段。接口让动作、授权、确认和状态回传的边界更清楚，却把覆盖能力交给应用开放、协议互通和平台入口；Android 同时保留屏幕自动化，因此不能写成行业整体转向、路线扩散、统一标准形成或 GUI 被替代。
STEPX 与 OPPO 提供了两个具名 AHA 试验
STEPX 的演示把意图理解和调度留在终端，把账户、服务履约和支付环节交给阿宝，并在下单前让用户确认。[S1] 7 月 15 日，OPPO 小布也被报道通过 AHA 调用阿宝近 200 项生活服务，资金或隐私相关的关键步骤由用户亲手确认。[S3] “近 200 项”说明合作方披露的服务范围，不代表真实调用量、成功率或独立验证过的覆盖率。
两个具名终端说明少数平台确实在试验同一类分工：终端不必逐个连接生活服务，而是把任务交给服务中枢，再接收执行状态。它可能降低终端逐商家接入的工作量，也让服务方预先限定哪些动作开放、需要哪些数据、何时必须确认。[S1][S3] 代价是终端更依赖阿宝的规则、可用性和服务供给；而且两个事件都依赖支付宝披露，只能证明具名合作，不能独立证明性能，更不能证明这种做法已经扩散。
豆包个案显示应用控制可能改变产品选择
今年 1 月的报道记录，豆包手机用读屏和模拟点击执行跨应用任务后，微信出现环境异常或封号，淘宝触发人机验证，银行应用拒绝在录屏状态下运行。[S4] 这组个案建立了 GUI 路线的具体阻力：它不要求应用适配，覆盖界面更快，但会遇到应用风控、隐私和入口控制。
随后出现的新路线报道，把豆包这一具名产品的选择改为要求头部应用提供 MCP 服务。[S2] 声明式接口允许应用先列出可用动作、数据范围和确认要求，因此能把控制权交还应用方；但包内没有豆包官方技术说明，也没有事故率对照，不能断言应用限制是路线调整的唯一原因，更不能把一个产品的变化上升为行业因果。商业和风控抵制同样可能解释这项调整。
接口边界更清楚，覆盖仍取决于服务方是否开放
声明式接口解决的是“允许做什么、由谁确认、结果怎样返回”，不自动解决“有多少服务愿意开放”。AHA 依赖支付宝聚合服务，媒体所述 MCP 路线仍要逐个争取头部应用；AHA、MCP 与 Android App Functions 也没有公开证据证明能力描述、授权和状态可以互通。[S1][S2][S3]
Android 的正式制度安排还给出一个重要反例：欧盟互操作决定同时列出 App Functions 结构化应用集成，以及在独立虚拟窗口中模拟用户行为的 Computer Control 屏幕自动化，并要求用户同意和安全条件。[S5] 这说明平台级方案仍让两条路线并存。声明式接口适合已适配、高风险且需要服务方履约的任务；未适配的长尾任务仍可能依赖受限 GUI 兜底，但 GUI 继续受界面变化、风控、隐私和任务校验约束。
决策应停留在具名场景的可撤回试验
银行、支付和高频生活服务应用可以选择少数明确场景做 exploration：先列动作清单和风险等级，对查询、下单、支付等动作分别设置授权与确认，再与受限 GUI 方案分开测试。[S1][S3][S4][S5] 手机智能体团队也应分别测量两条路线的覆盖率、任务成功率、人工接管率和高风险动作拦截率；在没有独立数据前，不宜押注单一协议或扩大生产投入。
当前判断保持不变：少数具名平台正在试验声明式接口，部分流程已经呈现明确的授权、确认和状态回传；证据不支持高价值手机任务整体转向、声明式路线扩散、覆盖大多数应用、生产级可靠性或 GUI 退出。只有出现公开协议和跨协议实测、更多非支付宝与非豆包来源的独立采用，以及真实调用量、成功率、人工接管和争议处理数据，才有理由把阶段从 exploration 上调。