Android Agent Automation Docs | 安卓手机自动化与 Agent 化执行研究库

如果要把这套方案交给工程团队实现，应该把它理解为一个“面向真机的任务执行平台”，而不是一个简单脚本仓库。

目标架构

Web Console / API / Webhook
           |
           v
     Task Orchestrator
           |
           +---------------------------+
           |                           |
           v                           v
   Planner Service               Policy Engine
           |                           |
           +-------------+-------------+
                         |
                         v
                  Device Gateway
             +------+------+------+
             |             |      |
             v             v      v
           ADB     UiAutomator2   Vision
             \             |      /
              \            |     /
               +-----------+----+
                           |
                           v
                    Real Device Pool
                           |
                           v
                   Artifact & Audit Store

模块拆分

1. `task-orchestrator`

职责：

接受任务
选择设备
绑定账号上下文
保存任务状态
发起 planner 推理
汇总审计信息

建议接口：

POST /api/tasks
{
  "platform": "taobao",
  "goal": "查找适合办公室的无线鼠标",
  "constraints": {
    "max_price": 129
  },
  "approval_mode": "before_submit_order"
}

2. `planner-service`

职责：

把自然语言任务翻译成结构化步骤
根据屏幕理解决定下一步
生成受约束的 tool call

建议输出：

{
  "state": "search_results",
  "next_tool": "tap_text",
  "arguments": {
    "text": "自营"
  },
  "reason": "优先筛选京东自营结果"
}

3. `policy-engine`

职责：

校验动作是否被允许
判断是否需要人工审批
阻断敏感动作

关键规则：

current_state 不匹配时不执行
命中支付页直接阻断
命中验证码页直接阻断
命中地址编辑页需要审批

4. `device-gateway`

职责：

提供统一设备控制接口
隐藏 ADB、UiAutomator2、OCR 的差异

建议暴露的内部命令：

launch_app
get_foreground_app
dump_ui
tap
tap_text
input_text
scroll
go_back
take_screenshot
start_screen_recording
stop_screen_recording

技术选型建议

Planner

可选：

OpenClaw 作为 agent control plane
Midscene 作为 Android AI operator / skill
自建基于 LLM + tool schema 的 planner

推荐：保留接口抽象，不把业务逻辑写死在某一家 agent runtime 里。

Execution

推荐优先级：

openatx/uiautomator2
ADB
必要时接 Appium 兼容现有 QA
Airtest 只做兜底，不做主路径

Storage

至少保存：

task
task_step
device
account_binding
artifact
approval_request

Artifact Store

按任务目录保存：

/storage/tasks/{task_id}/
  screenshots/
  screen-recording.mp4
  ui-dumps/
  action-log.jsonl
  final-summary.json

关键数据对象

Task

{
  "id": "tsk_001",
  "platform": "pdd",
  "goal": "寻找 20kg 猫粮",
  "status": "running",
  "current_state": "product_detail",
  "approval_mode": "before_submit_order"
}

Step Log

{
  "step_index": 12,
  "state_before": "search_results",
  "tool": "tap_text",
  "arguments": {
    "text": "销量"
  },
  "result": "success",
  "screenshot": "screenshots/0012.png",
  "duration_ms": 842
}

Approval Request

{
  "task_id": "tsk_001",
  "approval_type": "submit_order",
  "amount": 118.9,
  "address_summary": "上海市浦东新区 ...",
  "expires_at": "2026-03-29T12:10:00+08:00"
}

购物业务特有的系统要求

1. 同账号单设备锁

同一购物账号同一时刻只能绑定一台设备执行任务，避免：

异地登录
风控升高
状态串线

2. 页面与状态双判定

不能只靠 UI 文本判断当前状态，也不能只靠 activity 判断。

建议：

foreground app
activity
关键文本
最近动作

四项联合判断。

3. 可人工接管

任务在任意一步都应支持：

暂停
接管
继续
结束

如果不能接管，这个平台就不适合真实购物业务。

与开放平台 API 的衔接

当你有平台 API 能力时，架构要支持混合模式：

商品搜索与下单用 API
优惠券、运营活动页、人审页用 UI Agent
订单状态回写 orchestrator

这部分在长期会显著降低 UI 脆弱性。

监控指标

task_success_rate
reach_checkout_rate
approval_block_rate
captcha_hit_rate
login_failure_rate
median_steps_per_task
mean_recovery_time

结论

这套系统真正的难点不在于“让模型看懂屏幕”，而在于把 Agent 放进一套受控、可回放、可审批、可审计的执行平台里。平台先立住，模型才有价值。

系统架构蓝图