最近在探索本地化 AI Agent 的工程实践时一个组合让我非常兴奋DSH Qwen3.8通过本地部署大模型结合设备控制能力和自动化执行框架可以让 AI 从“回答问题”进化到“解决问题”。本文记录一个实际探索方向使用 AI Agent 驱动 Android 真机自动完成 App 测试回归、日志分析和结果总结。最终总共跑了近3个小时~~在240K上下文的本地部署QWEN3.8 27B环境下完美完成。一、为什么需要本地化 AI Agent过去几年大模型发展非常快。我们已经习惯ChatGPT 帮助写代码Copilot 辅助开发大模型生成测试用例但是在真实企业环境中还有一个重要问题AI 如何进入真实工作流例如一个 Android 项目每天产生新的 APK。传统流程开发提交代码 ↓ 构建 APK ↓ 测试人员安装 ↓ 人工执行测试 ↓ 记录问题 ↓ 提交 Bug这个过程重复耗时容易遗漏而 AI Agent 的目标是提交 APK ↓ AI Agent ↓ 连接真实 Android 设备 ↓ 自动执行测试 ↓ 分析异常 ↓ 生成测试报告二、DSH Qwen3.8 的组合价值很多人认为 AI 的核心只是模型。实际上真正落地需要三个部分大模型 工具能力 业务环境其中Qwen3.8负责理解和推理Qwen 系列模型具备中文理解能力代码分析能力任务规划能力Agent 调度能力它负责理解测试目标制定执行计划分析异常原因生成总结报告DSH连接真实世界如果没有执行能力大模型只能停留在文本层面。DSH 可以帮助 AI连接设备执行动作获取状态驱动工具链例如AI: 打开APP执行登录测试 ↓ Agent调用: adb uiautomator scrcpy ↓ 真实手机执行操作这一步非常关键。因为AI 真正产生价值的地方是它可以影响现实环境。三、Android 真机回归测试 Agent 实践本次探索目标打造一个 Android 自动化回归 Agent。整体流程用户需求 ↓ Test Planning Agent ↓ Android Device Agent ↓ 真机执行测试 ↓ 日志/截图/状态采集 ↓ Qwen3.8 分析 ↓ 自动生成报告四、实际运行过程下面是实际开发过程截图到最后完成时结果如下任务 12 已完成安装 adb 并确认真机连接安装 uiautomator2 并验证设备可控安装 Android SDK (platform-36/build-tools) JDK17 scrcpy解决 loopback 改写问题docker 构建容器编写 src/device_test.py设备驱动证据录制LLM 回归执行集成到 main.py 评审流程并行执行、合并报告/PDF/邮件集成视觉模型 qwen3-vl:8b截图观察最终复核修复 JDK user.home 陷阱镜像 passwd 条目编译 plugincenter 内部库并发布到本地 maven验证 app 仓库能构建出 APK含内部依赖端到端验证一次完整回归含构建重启服务 最终总结2 轮 · 320 步| LLM 145m36s · 工具调用 117m40s| 首 token 平均 3.4s · 30 tok/s| 缓存命中 96%| 输入 41.3M tok从任务列表可以看到adb 真机连接uiautomator2 环境验证Android SDK 配置scrcpy 调试APK 构建验证自动化测试流程集成整个流程已经不是传统脚本固定步骤 ↓ 执行 ↓ 结束而是观察环境 ↓ 理解状态 ↓ 决定下一步动作 ↓ 执行 ↓ 根据结果调整这就是 Agent 和自动化脚本最大的区别。五、为什么这个方向值得推广很多企业想使用 AI但遇到现实限制1. 数据安全业务数据用户数据测试数据日志代码不能全部上传公网。本地部署可以解决企业数据 ↓ 内部模型 ↓ 内部Agent ↓ 内部系统2. 专业场景需要定制通用 AI 不一定懂企业 App测试流程内部规范但是本地 Agent 可以结合企业知识库自动化工具私有数据形成专属 AI 工程助手。六、未来方向我认为未来的软件工程会出现大量AI QA Engineer每天自动拉取最新APK ↓ 安装测试 ↓ 执行1000条Case ↓ 分析失败原因 ↓ 生成日报 ↓ 通知开发AI 不再只是帮工程师写代码而会变成和工程师一起完成整个软件生命周期。七、总结DSH Qwen3.8 这个组合最大的意义不是让 AI 聊天更聪明。而是让 AI 具备进入真实工程环境的能力。从模型走向模型 Agent 工具 业务这是本地 AI 真正落地的方向。未来属于那些敢于把 AI 接入真实生产流程的人。