文章总结： 该文档介绍了一种基于大语言模型驱动的AndroidAgent方案，用于APK功能的自动化验收测试。核心思路是将功能文档直接交给LLM，让它像真人测试员一样操作手机，逐项验证功能是否与文档描述一致，最终输出结构化验收报告。系统采用四层架构设计，核心机制为ReAct循环，通过工具层实现UI分析、设备操控和文件输出，关键技术包括ADB工具链、LangChain框架和自定义API封装，项目已开源。 综合评分： 89 文章分类： 移动安全,安全工具,AI安全,安全开发,应用安全
开源 | Android Agent：智能体驱动 APK 自动化测试与自动化操作
原创
二进制磨剑 二进制磨剑
二进制磨剑
2026年3月10日 19:10 四川
Android Agent：基于 LLM 驱动的 APK 功能自动化验收测试
当你拿到一个 APK 和一份功能文档，如何让 AI 自动判断”应用做的对不对”？本文介绍一种基于大语言模型 + ADB 工具链的 Android Agent 方案，让 LLM 阅读技术文档、操控真机、逐项比对功能点，最终输出一份结构化的验收报告。
一、为什么需要这样一个 Agent
传统的 Android 自动化测试（Espresso、UI Automator、Appium）都需要人工编写测试脚本——你得知道”点哪个按钮”、”期望看到什么文字”。这意味着：
- • 每换一个 APK，脚本要重写
- • 需求文档更新后，脚本要同步维护
- • 编写脚本本身就是一项开发工作
我们的思路完全不同：把功能文档直接交给 LLM，让它像一个真人测试员一样操作手机，逐项验证功能是否与文档描述一致，最后自己写报告。
核心流程只有一句话：
输入：APK + 功能文档 → Agent 自主操作真机 → 输出：验收报告
二、技术栈
| 层级 | 技术选型 | 作用 | | — | — | — | | LLM 推理 | OpenAI Responses API + httpx | 大模型决策与推理 | | Agent 框架 | LangChain（Tool 抽象） | 工具注册、统一调用接口 | | 设备控制 | ADB + UI Automator | 真机操作（点击、截图、UI 分析） | | 界面解析 | xml.etree.ElementTree | 解析 UI 层级结构 | | 配置管理 | python-dotenv + JSON | API 密钥、目标应用配置 | | 开发语言 | Python 3 | Agent 端全部逻辑 | | 被测应用 | Kotlin + Android SDK | 目标 APK |
三、整体架构
整个系统分为四层
系统架构图
第一层：用户交互层 — interactive_agent.py 是 CLI 入口，接收用户输入的测试任务，将任务传递给 Agent 核心。
第二层：Agent 决策层 — android_agent.py 是系统的大脑。它将系统提示词、当前任务和历史记录组合成 Prompt 发送给 LLM，LLM 返回 JSON 格式的决策（思考、行动、参数、最终答案），Agent 解析后调用对应工具执行，将结果追加到历史记录，进入下一轮。如此循环，直到 LLM 返回 final_answer。
第三层：工具层 — 10 个工具分三类：UI 分析（感知界面）、设备操控（操作手机）、文件输出（生成报告）。采用两层封装：android_tools.py 用 LangChain @tool 提供统一接口，底层 adb_tools.py 通过 subprocess 调用 ADB 命令。
第四层：设备层 — 通过 ADB 与 Android 真机通信。
四、核心机制：ReAct 循环
Agent 的核心是 ReAct 循环（Reasoning + Acting）——每一步 LLM 先思考，再行动，然后观察结果：
ReAct循环流程
每轮循环中：
- 1. 构建 Prompt：将系统提示词 + 任务描述 + 所有历史记录拼接为完整 Prompt
- 2. LLM 推理：大模型返回一个 JSON，包含
thought（思考）、action（工具名）、action_input（参数）、final_answer（最终答案） - 3. 判断终止：如果
final_answer不为空，任务结束 - 4. 执行工具：根据
action调用对应的 ADB 工具 - 5. 记录结果：将执行结果追加到历史记录，供下一轮 LLM 参考
LLM 每次返回的 JSON 格式如下：
{
"thought": "当前在主界面，文档说有4个按钮，我需要逐个点击验证",
"action": "get_clickable_elements",
"action_input": {},
"final_answer": null
}
五、工具
工具是 Agent 与真机交互的桥梁，按职责分为三组：
| 分组 | 工具 | 作用 |
| — | — | — |
| UI 分析 | get_clickable_elements | 获取可点击元素及中心坐标 |
| | get_ui_hierarchy | 获取完整 UI 树结构 |
| | get_current_activity | 获取当前 Activity 名称 |
| | get_app_info | 获取当前应用包名和 Activity |
| 设备操控 | tap(x, y) | 点击屏幕指定坐标 |
| | press_back | 按系统返回键 |
| | launch_app | 启动指定应用 |
| | screenshot | 截取当前屏幕 |
| 文件输出 | write_file | 写入文件（生成报告） |
| | append_file | 追加内容到文件 |
其中最关键的是 get_clickable_elements——它通过 uiautomator dump 获取界面 XML，递归提取所有 clickable="true" 的元素，从 bounds 字段（如 [84,1001][996,1184]）计算中心点坐标。这样 LLM 拿到的不是几千行 XML，而是一个精简的列表：每个元素的文字、ID 和”该点哪里”的坐标。信息密度高，token 消耗低。
六、LLM 接入
项目所用 API 走的中转站，没有直接使用 OpenAI SDK，而是基于 httpx 手动封装了一个兼容 LangChain 的 BaseChatModel，调用 Responses API。这样做有两个原因：
- 1. 绕过 User-Agent 拦截：部分 API 代理会识别并拦截 OpenAI SDK 默认的 User-Agent 头，用 httpx 可以完全控制请求头
- 2. 适配 Responses API：该 API 的请求/响应格式与 Chat Completions 不同，需要自定义解析
同时，系统提示词以 developer 角色发送（而非 system），避免代理覆盖 instructions 字段。
七、提示词
提示词告诉 LLM 三件事：你是谁、你有什么工具、你该怎么工作。
核心设计要点：
- • 角色定位：明确告知 LLM 它是”Android 自动化测试助手，通过 ADB 控制设备”
- • 工具清单：列出全部工具的名称、参数和用途
- • 输出格式：强制要求返回 JSON（thought / action / action_input / final_answer），方便程序解析
- • 工作流程：规范操作顺序——先获取界面元素 → 分析并点击 → 截图记录 → 返回继续
- • 报告约束：明确要求用
write_file生成 Markdown 报告文件，不能只在回答中口头描述
八、运行展示
运行 interactive_agent.py，与 Agent 对话说明任务：
运行截图
最终输出：
最终输出
#
源码地址： https://github.com/Q7h2q9/android_agent
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：二进制磨剑 二进制磨剑 二进制磨剑《开源 | Android Agent：智能体驱动 APK 自动化测试与自动化操作》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论