企业官网建设流程全解析

网站建设商虎小程序,wordpress站点的根目录,龙江人社app二维码图片,做英文网站 用阿里服务器行吗Open-AutoGLM如何查看设备列表#xff1f;list_devices用法详解 Open-AutoGLM 是智谱开源的轻量级手机端 AI Agent 框架#xff0c;专为在资源受限的本地环境运行多模态智能体而设计。它不依赖云端大模型推理服务也能完成基础屏幕理解与操作规划#xff0c;但更常见的是作为…Open-AutoGLM如何查看设备列表list_devices用法详解Open-AutoGLM 是智谱开源的轻量级手机端 AI Agent 框架专为在资源受限的本地环境运行多模态智能体而设计。它不依赖云端大模型推理服务也能完成基础屏幕理解与操作规划但更常见的是作为“控制中枢”连接远端部署的 AutoGLM-Phone 模型服务实现自然语言驱动的真机自动化。AutoGLM-Phone 是一个基于视觉语言模型的 AI 手机智能助理框架。它能以多模态方式理解屏幕内容并通过 ADB 自动操控设备。用户只需用自然语言下指令如“打开小红书搜美食”模型即可解析意图、理解界面并自动规划、执行操作流程无需手动点击。Phone Agent 是基于 AutoGLM 构建的手机端智能助理框架它能够以多模态方式理解手机屏幕内容并通过自动化操作帮助用户完成任务。系统通过 ADBAndroid Debug Bridge来控制设备以视觉语言模型进行屏幕感知再结合智能规划能力生成并执行操作流程。用户只需用自然语言描述需求如“打开小红书搜索美食”Phone Agent 即可自动解析意图、理解当前界面、规划下一步动作并完成整个流程。系统还内置敏感操作确认机制并支持在登录或验证码场景下进行人工接管。同时它提供远程 ADB 调试能力可通过 WiFi 或网络连接设备实现灵活的远程控制与开发。在实际使用中“连上哪台设备”是所有操作的第一步。而list_devices()这个函数就是 Open-AutoGLM 控制端最直接、最可靠的设备发现入口。它不依赖图形界面不调用外部 shell 命令封装而是通过 Python 原生逻辑与 ADB 协议深度交互返回结构化、可编程的设备信息。本文将带你从零开始彻底搞懂list_devices是什么、怎么用、为什么可靠以及它在真实工作流中扮演的关键角色。1. list_devices 是什么不是 adb devices 的简单包装list_devices()是 Open-AutoGLM 提供的一个核心工具函数位于phone_agent.adb模块中。它看起来像adb devices的 Python 封装但实际远不止于此。1.1 它返回的是对象不是字符串当你在终端输入adb devices得到的是类似这样的纯文本输出List of devices attached 0123456789ABCDEF device 192.168.1.100:5555 device而list_devices()返回的是一个List[Device]—— 每个Device都是一个带属性的 Python 对象包含device_id: 设备唯一标识如0123456789ABCDEF或192.168.1.100:5555state: 当前连接状态device、offline、unauthorized等connection_type: 连接类型USB、WIFI、UNKNOWN这是adb devices原生不提供的关键信息is_online: 布尔值是否真正可通信会尝试 ping 或握手验证这意味着你不用再写正则去解析adb devices输出也不用担心空格、换行、中文乱码等问题。直接用点号访问属性代码清晰又健壮。1.2 它做了三件事发现 分类 验证list_devices()的内部逻辑分三步执行执行adb devices -l获取带详细信息的设备列表含 USB 序列号、型号、连接方式等解析并归类根据transport_id、IP 地址格式、端口是否存在等自动判断是 USB 还是 WiFi 连接轻量级连通性探测对每个设备 ID 尝试发送一个极简的adb get-state命令过滤掉已断开但未清理的“幽灵设备”这使得它比裸调adb devices更适合集成进自动化脚本——你拿到的永远是“此刻真正可用”的设备清单。2. 如何正确调用 list_devices三种典型用法list_devices()使用极其简单但不同场景下调用方式略有差异。下面展示三种最常用、也最实用的用法。2.1 基础用法直接列出所有在线设备这是最直观的方式适合调试和快速确认环境状态。from phone_agent.adb import list_devices devices list_devices() if not devices: print( 未检测到任何已连接的安卓设备) else: print(f 发现 {len(devices)} 台在线设备) for i, dev in enumerate(devices, 1): conn_type USB if dev.connection_type.name USB else WiFi status 在线 if dev.is_online else 离线 print(f{i}. {dev.device_id} | {conn_type} | {status})运行后你会看到类似这样的输出发现 2 台在线设备 1. 0123456789ABCDEF | USB | 在线 2. 192.168.1.100:5555 | WiFi | 在线注意这里和是为了演示可读性加入的符号实际生产代码中建议用文字如[在线]/[离线]避免终端兼容性问题。2.2 条件筛选只取 USB 设备或只取 WiFi 设备在混合环境中比如同时插着真机又连着模拟器你可能只想操作某类设备。list_devices()返回的是标准 Python 列表筛选非常自然from phone_agent.adb import list_devices from phone_agent.adb.enums import ConnectionType # 获取所有 USB 连接的设备 usb_devices [d for d in list_devices() if d.connection_type ConnectionType.USB] print(fUSB 设备{[d.device_id for d in usb_devices]}) # 获取所有 WiFi 连接的设备常用于远程测试 wifi_devices [d for d in list_devices() if d.connection_type ConnectionType.WIFI] print(fWiFi 设备{[d.device_id for d in wifi_devices]}) # 获取第一台可用的设备常用在单设备 CI 流水线中 first_device next((d for d in list_devices() if d.is_online), None) if first_device: print(f默认使用设备{first_device.device_id}) else: raise RuntimeError(没有找到可用设备请检查 ADB 连接)这种写法完全摆脱了字符串匹配语义清晰、IDE 可补全、类型安全是工程化脚本的推荐写法。2.3 结合 ADBConnection 使用先连再查确保上下文一致list_devices()是独立函数但它与ADBConnection类高度协同。后者管理连接生命周期前者提供设备视图。典型配合如下from phone_agent.adb import ADBConnection, list_devices # 创建连接管理器不立即连接任何设备 conn ADBConnection() # 先列出所有设备选一个目标 all_devices list_devices() target_device next((d for d in all_devices if d.is_online and d.connection_type ConnectionType.USB), None) if not target_device: raise ValueError(未找到可用的 USB 设备) # 使用该设备 ID 建立连接上下文 success, msg conn.connect(target_device.device_id) if not success: raise RuntimeError(f连接失败{msg}) print(f 已成功连接至 {target_device.device_id}) # 此时你可以放心调用 conn 的其他方法如截图、点击、输入等 # conn.screenshot(home.png) # conn.tap(100, 200)这种方式把“发现”、“选择”、“连接”三个步骤解耦又串联逻辑清晰便于单元测试和异常处理。3. list_devices 的底层原理它到底怎么工作的理解原理才能用得更稳、排错更快。我们拆解list_devices()的执行链条。3.1 第一步调用 adb devices -l 并解析list_devices()内部首先执行adb devices -l这个-l参数会输出设备的详细信息例如List of devices attached 0123456789ABCDEF device product:star2 model:Redmi_K30_Ultra device:star2 transport_id:1 192.168.1.100:5555 device product:generic model:Android_SDK_built_for_x86 device:generic transport_id:2它会逐行解析提取device_id第一列、state第二列并根据transport_id和 IP 格式推断connection_type。3.2 第二步连接类型智能识别识别规则非常务实device_id 格式推断 connection_type依据纯十六进制字符串如0123...USBADB 默认 USB 设备 ID 格式包含:且符合 IPv4/IPv6 端口如192.168.1.100:5555WIFIADB over TCP/IP 标准格式其他情况如emulator-5554UNKNOWN保留扩展性这个判断不依赖操作系统命令纯 Python 实现跨平台稳定。3.3 第三步轻量握手验证 is_online对每个解析出的device_idlist_devices()会执行adb -s device_id get-state 2/dev/null如果返回device则is_online True如果超时、返回offline或报错则设为False。这个过程耗时极短通常 200ms但能有效剔除adb devices显示为device实际已断开的“假在线”设备。4. 常见问题与排查指南为什么 list_devices 有时为空list_devices()返回空列表是新手最常遇到的问题。别急按以下顺序逐一排查90% 的情况都能解决。4.1 检查 ADB 是否真的可用list_devices()本质依赖adb命令行工具。先确认它在终端中能正常运行# Windows/macOS/Linux 统一验证 adb version # 应输出类似Android Debug Bridge version 1.0.41 adb devices # 应显示设备列表且状态为 device不是 unauthorized 或空白如果adb version报错“command not found”说明 ADB 未安装或未加入 PATH请回看“硬件与环境准备”章节重新配置。4.2 检查手机 USB 调试是否授权这是最隐蔽的坑。即使adb devices显示设备 ID如果手机弹出的“允许 USB 调试”对话框被忽略或点了“拒绝”ADB 实际无法通信。正确做法断开 USB 线关闭手机开发者选项中的“USB 调试”重新开启“USB 调试”重新连接 USB 线手机屏幕上必须出现授权弹窗并点击“允许”此时adb devices应显示devicelist_devices()也会返回该设备。4.3 检查 WiFi 连接是否真正生效WiFi 连接需两步先 USB 启用tcpip再adb connect。很多人漏掉第一步# 必须先用 USB 连接执行否则 adb connect 会失败 adb tcpip 5555 # 断开 USB再连接 WiFi adb connect 192.168.1.100:5555验证 WiFi 连接是否成功adb devices # 应显示 IP:port adb -s 192.168.1.100:5555 shell getprop ro.product.model # 应返回手机型号如果list_devices()找不到 WiFi 设备大概率是adb connect未成功或手机与电脑不在同一局域网。4.4 检查 Python 环境是否干净list_devices()依赖subprocess调用系统adb。如果你在虚拟环境中安装了adb-shell或其他 ADB 封装库可能造成冲突。推荐做法不要pip install adb这是另一个同名库非 Google ADB确保which adbmacOS/Linux或where adbWindows指向你手动下载的 platform-tools 中的adb在 Python 中临时打印路径验证import subprocess result subprocess.run([adb, --version], capture_outputTrue, textTrue) print(ADB 路径与版本, result.stdout)5. 进阶技巧把 list_devices 变成你的自动化“设备管家”list_devices()的价值不仅在于“看到设备”更在于它能成为你自动化流程的智能调度起点。以下是两个真实可用的进阶模式。5.1 多设备轮询自动选择响应最快的设备在 CI/CD 或批量测试场景中你可能有多个设备待命。与其固定写死--device-id不如让脚本自己选import time from phone_agent.adb import list_devices def select_fastest_device(): devices list_devices() if not devices: raise RuntimeError(无可用设备) # 对每台设备测速执行一个极简命令如 get-state记录耗时 speeds [] for dev in devices: if not dev.is_online: continue start time.time() try: # 不捕获输出只看是否成功 subprocess.run( [adb, -s, dev.device_id, get-state], timeout3, stdoutsubprocess.DEVNULL, stderrsubprocess.DEVNULL ) elapsed time.time() - start speeds.append((dev, elapsed)) except Exception: continue if not speeds: raise RuntimeError(所有设备均无响应) # 返回耗时最短的设备 fastest_dev, _ min(speeds, keylambda x: x[1]) return fastest_dev # 使用 target select_fastest_device() print(f自动选择最快设备{target.device_id})这个技巧让脚本具备了“自适应”能力特别适合云测平台或实验室多机房环境。5.2 设备状态监控做成一个常驻守护进程你可以把它变成一个简单的设备看门狗实时监控设备上下线import time from phone_agent.adb import list_devices def monitor_devices(interval5): last_seen set() print( 设备监控已启动CtrlC 停止...) while True: current {d.device_id for d in list_devices()} # 新增设备 new_devices current - last_seen if new_devices: print(f 新设备接入{, .join(new_devices)}) # 离线设备 gone_devices last_seen - current if gone_devices: print(f❌ 设备离线{, .join(gone_devices)}) last_seen current time.sleep(interval) # 启动监控在后台线程或单独脚本中运行 # monitor_devices()这种模式可用于无人值守的自动化测试机房或作为开发调试时的辅助工具。6. 总结list_devices 是 Open-AutoGLM 的“设备感知神经”list_devices()看似只是一个简单的工具函数但它承载着 Open-AutoGLM 框架对设备连接层的深刻理解它不只是罗列 ID而是提供可编程的设备上下文它不满足于“存在”而追求“可用”它不依赖黑盒命令而通过结构化数据赋能上层逻辑。掌握它你就掌握了 Open-AutoGLM 自动化流程的第一把钥匙——从此设备连接不再是靠人肉adb devices查看、复制、粘贴的繁琐步骤而是一行代码、一次筛选、一个决策的自然延伸。无论你是刚接触手机 AI Agent 的新手还是正在构建企业级自动化平台的工程师list_devices()都值得你花十分钟真正理解它、信任它、用好它。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。