Open-AutoGLM如何监控执行状态？日志分析实战教程

Open-AutoGLM如何监控执行状态？日志分析实战教程

Open-AutoGLM 是智谱开源的轻量级手机端 AI Agent 框架，专为在资源受限的移动设备场景下实现“自然语言→屏幕理解→自动操作”闭环而设计。它不追求大模型参数规模，而是聚焦于真实任务流中的稳定性、可观察性与可控性——尤其在用户看不见的后台执行过程中，如何确认每一步是否成功、卡在哪、为什么失败，直接决定了这个 AI 助理是否真正可靠。

AutoGLM-Phone 作为其核心实现，是一个基于视觉语言模型（VLM）的手机智能助理框架。它能实时截取手机屏幕画面，结合当前界面状态与用户指令，生成可执行的操作序列（如点击坐标、输入文本、滑动方向），再通过 ADB 精准下发。整个过程无需人工干预，但正因为“全自动”，反而更需要一套清晰、分层、可追溯的日志体系来支撑调试、验证和长期运维。

Phone Agent 进一步强化了这一能力：它不仅支持 USB 和 WiFi 双模 ADB 连接，还内置敏感操作拦截、人工接管入口、远程调试通道，并在关键节点埋点记录意图解析、界面识别、动作规划、ADB 执行结果等全链路信息。这些日志不是冷冰冰的报错堆栈，而是你理解 AI “思考过程”与“行为逻辑”的第一手证据。

那么问题来了：当运行python main.py --device-id ... "打开小红书搜美食"后，终端只刷出几行快速滚动的文字，你真的知道它此刻在做什么吗？是正在截图？还是卡在 OCR 识别？抑或 ADB 命令被拒绝却没报错？本教程不讲怎么部署、不重复安装步骤，而是带你从零开始读懂 Open-AutoGLM 的日志语言，定位真实瓶颈，把“黑盒执行”变成“透明流程”。

1. 日志体系全景：四层结构看懂执行脉络

Open-AutoGLM 的日志不是单一输出流，而是按职责划分为四个逻辑层级，每一层对应不同角色的关注点。理解这个结构，是你高效分析日志的前提。

1.1 应用层日志（User-Facing Log）

这是你在命令行中直接看到的内容，由main.py主程序统一控制输出级别（默认 INFO）。它面向使用者，描述“发生了什么”，语言简洁、带时间戳、有明确阶段标识：

[2024-06-12 14:22:03] INFO ──────────── Task Start ──────────── [2024-06-12 14:22:03] INFO Instruction: 打开小红书搜美食 [2024-06-12 14:22:05] INFO Screen captured & sent to VLM [2024-06-12 14:22:08] INFO 🧠 VLM response parsed: {"action": "LAUNCH_APP", "app_name": "小红书"} [2024-06-12 14:22:09] INFO ⚙ Executing ADB: adb shell am start -n com.xingin.xhs/.activity.SplashActivity [2024-06-12 14:22:11] INFO ADB command succeeded [2024-06-12 14:22:12] INFO 📸 New screenshot taken (retry=0) ... [2024-06-12 14:22:35] INFO Task completed successfully

关键特征：

• 使用符号（/🧠/⚙/📸）直观表达状态，降低阅读负担
• 每条日志对应一个原子动作，不混杂多个逻辑
• 不暴露技术细节（如 ADB 返回码、HTTP 响应体），只反馈结果含义

注意：此层日志默认不记录错误详情（如 ADB timeout 具体秒数），仅提示“❌ ADB command failed”。要深挖原因，需向下一层查看。

1.2 ADB 层日志（Device Interaction Log）

这一层由phone_agent.adb模块内部生成，记录所有与安卓设备的原始交互。它不经过主程序日志器，而是写入独立文件adb_debug.log（默认路径：./logs/adb_debug.log），内容包含完整命令、标准输出、标准错误、执行耗时及返回码。

示例片段：

[2024-06-12 14:22:09.215] DEBUG CMD: adb -s 8A2Y0XQH22002742 shell am start -n com.xingin.xhs/.activity.SplashActivity [2024-06-12 14:22:09.216] DEBUG STDOUT: Starting: Intent { cmp=com.xingin.xhs/.activity.SplashActivity } [2024-06-12 14:22:09.216] DEBUG STDERR: [2024-06-12 14:22:09.216] DEBUG RETURN_CODE: 0 [2024-06-12 14:22:09.216] DEBUG DURATION: 0.321s

关键价值：

• 验证 ADB 命令是否被正确构造与发送
• 判断设备响应是否符合预期（如STDERR是否为空）
• 定位连接类问题（如RETURN_CODE: -1表示设备未连接）
• 分析性能瓶颈（DURATION > 2s可能预示 WiFi 延迟或设备卡顿）

🔧 查看方式：

# 实时跟踪（推荐） tail -f logs/adb_debug.log # 或在启动时指定日志路径 python main.py --adb-log-path ./my_adb.log ...

1.3 模型服务层日志（VLM Inference Log）

当 Open-AutoGLM 将截图发送至云端 VLM（如 autoglm-phone-9b）时，服务端（vLLM 或自定义 API）会生成独立推理日志。这部分日志不在客户端，需登录云服务器查看，典型路径为/var/log/autoglm-vlm/下的inference.log。

关键字段包括：

• request_id: 与客户端请求 ID 对应，用于跨端追踪
• input_tokens: 输入 prompt + 截图 base64 编码后 token 数
• output_tokens: 模型实际生成 token 数
• prompt_len,completion_len: 更细粒度长度统计
• time_to_first_token,inter_token_latency: 性能核心指标

示例：

{"request_id": "req_abc123", "input_tokens": 1248, "output_tokens": 87, "prompt_len": 1192, "completion_len": 87, "time_to_first_token": 1.82, "inter_token_latency": 0.14, "timestamp": "2024-06-12T14:22:07.332Z"}

关键价值：

• 区分问题是出在“客户端没发过去”还是“服务端没回过来”
• 判断模型是否过载（time_to_first_token > 3s且并发高）
• 验证输入质量（input_tokens异常高可能因截图分辨率超标）

提示：若使用 vLLM，可通过启动参数--log-level debug开启更详细日志，但会显著增加磁盘 IO。

1.4 系统层日志（OS & ADB Daemon Log）

这是最底层、最原始的日志，来自安卓系统本身和 ADB daemon 进程。它不被 Open-AutoGLM 主动采集，但在排查顽固问题时不可或缺。

• 安卓系统日志（logcat）：记录 App 崩溃、权限拒绝、ANR 等。

  adb logcat -v threadtime | grep -i "xhs\|autoglm"

• ADB daemon 日志：当adb devices无响应或频繁断连时启用。

  # Windows 下重启 ADB 并开启日志 adb kill-server adb -L tcp:5037 logcat

关键价值：

• 发现Permission denied（缺少android.permission.READ_FRAME_BUFFER）
• 捕获ANR in com.xingin.xhs（目标 App 卡死导致截图失败）
• 诊断adbd cannot run as root in production builds（非 root 设备限制）

2. 实战分析：三类高频问题的日志定位法

理论需落地。下面以三个开发者最常遇到的真实场景为例，手把手演示如何组合四层日志，快速定位根因。

2.1 场景一：指令已下发，但手机毫无反应（黑屏/无动作）

现象：终端显示ADB command succeeded，但手机屏幕静止，未启动任何 App。

分析路径：

1. 查应用层日志：确认是否真有ADB command succeeded？还是误读为成功？
   → 若日志实为❌ ADB command failed，跳至第2步；若确为成功，则问题在设备侧。

2. 查 ADB 层日志（adb_debug.log）：

   [2024-06-12 15:10:22.441] DEBUG CMD: adb -s 8A2Y0XQH22002742 shell am start -n com.xingin.xhs/.activity.SplashActivity [2024-06-12 15:10:22.442] DEBUG STDOUT: [2024-06-12 15:10:22.442] DEBUG STDERR: Error: Activity not found [2024-06-12 15:10:22.442] DEBUG RETURN_CODE: 1

   ❗ 关键线索：STDERR明确报错Activity not found，RETURN_CODE: 1（非0即失败）。说明包名或 Activity 名错误。

3. 查系统层日志（logcat）验证：

   adb logcat | grep -i "am\|start" # 输出：ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.xingin.xhs/.activity.SplashActivity} from uid 2000 on display 0 # 但紧接着：ActivityManager: Unable to find explicit activity class {com.xingin.xhs/.activity.SplashActivity}

   结论：App 已安装，但SplashActivity路径变更。需更新app_mapping.json中小红书的启动 Activity。

2.2 场景二：反复截图，但 VLM 始终返回空操作（{"action": "WAIT"}）

现象：日志持续刷📸 New screenshot taken (retry=3)，VLM 响应始终是等待，任务超时失败。

分析路径：

1. 查应用层日志：确认重试次数（retry=3）及最终失败提示。

2. 查 ADB 层日志：验证截图命令是否成功：

   CMD: adb -s 8A2Y0XQH22002742 shell screencap -p /sdcard/autoglm_tmp.png STDOUT: RETURN_CODE: 0 CMD: adb -s 8A2Y0XQH22002742 pull /sdcard/autoglm_tmp.png ./tmp/screenshot_123456.png RETURN_CODE: 0

   截图流程无异常。

3. 查模型服务层日志（inference.log）：

   {"request_id": "req_xyz789", "input_tokens": 256, "output_tokens": 12, "prompt_len": 244, "completion_len": 12}

   ❗input_tokens仅 256，远低于正常值（通常 >1000）。说明截图未被正确编码传入！

4. 回溯代码：检查phone_agent/vision.py中encode_screenshot()函数，发现cv2.imencode('.png', img)[1].tobytes()被错误替换为img.tobytes()，导致传入的是原始像素而非 PNG 字节流。

结论：客户端图像编码逻辑缺陷，VLM 收到无效输入，故返回安全兜底动作WAIT。

2.3 场景三：WiFi 连接下任务执行缓慢，延迟高达 8 秒/步

现象：USB 连接流畅，WiFi 下每步操作耗时翻倍，DURATION日志显示3.216s。

分析路径：

1. 查 ADB 层日志：确认DURATION确实增长，且CMD一致（排除命令差异）。

2. 查系统层日志（ADB daemon）：

   adb -L tcp:5037 logcat | grep -i "usb\|wifi\|connect" # 输出：adbd: usb: disconnected, wifi: connected to 192.168.1.100:5555 # adbd: transport: write failed: Broken pipe

   ❗Broken pipe表明 WiFi 连接不稳定。

3. 网络诊断：

   # 测试设备 IP 连通性 ping 192.168.1.100 # 测试 ADB 端口 telnet 192.168.1.100 5555 # 测试丢包率 mtr --report 192.168.1.100

   发现mtr显示 15% 丢包率。

结论：WiFi 环境干扰严重，非代码问题。建议：改用 5GHz 频段、缩短距离、或回归 USB 连接。

3. 日志增强技巧：让关键信息一目了然

默认日志足够用，但稍作配置，可大幅提升排查效率。

3.1 自定义日志级别与格式

Open-AutoGLM 使用标准logging模块，支持通过环境变量或代码动态调整：

# 在 main.py 开头添加（覆盖默认配置） import logging logging.getLogger("phone_agent").setLevel(logging.DEBUG) # 激活模块内 DEBUG 日志 logging.getLogger("adb").setLevel(logging.DEBUG) # 自定义格式（更清晰的时间+模块+行号） formatter = logging.Formatter( '[%(asctime)s] %(levelname)-6s %(name)s:%(lineno)d - %(message)s', datefmt='%Y-%m-%d %H:%M:%S' )

效果：

[2024-06-12 16:05:22] DEBUG phone_agent.vision:42 - Screenshot saved to ./tmp/screenshot_789.png (1280x720) [2024-06-12 16:05:22] DEBUG adb:156 - ADB command 'shell getprop ro.build.version.release' returned '13'

3.2 关键事件打标（Request ID 关联）

为实现端到端追踪，在发起请求时注入唯一 ID，并贯穿所有日志层：

# main.py 中 import uuid request_id = str(uuid.uuid4())[:8] os.environ["AUTOGLM_REQUEST_ID"] = request_id # ADB 模块中 logging.debug(f"[{os.getenv('AUTOGLM_REQUEST_ID', 'N/A')}] CMD: {cmd}") # VLM 请求头中 headers = {"X-Request-ID": request_id}

这样，你在adb_debug.log、inference.log、main.log中搜索abc123de，即可一次性拉出同一任务的全链路日志。

3.3 日志归档与轮转

避免日志文件无限增长，修改logging配置启用轮转：

from logging.handlers import RotatingFileHandler handler = RotatingFileHandler( 'logs/main.log', maxBytes=10*1024*1024, # 10MB backupCount=5, # 保留5个历史文件 encoding='utf-8' )

4. 总结：日志不是副产品，而是核心能力

监控执行状态，本质是构建对 AI Agent 行为的“可观测性”。Open-AutoGLM 的日志设计并非简单堆砌信息，而是分层解耦、各司其职：

• 应用层日志是你的操作仪表盘，告诉你“现在到哪一步了”；
• ADB 层日志是设备通信的录音笔，记录“到底发了什么、收到了什么”；
• 模型服务层日志是云端大脑的体检报告，揭示“推理是否健康、响应是否及时”；
• 系统层日志是底层硬件的警报器，预警“设备是否就绪、权限是否到位”。

掌握这四层日志的协同分析方法，你将不再依赖“重试”或“换设备”这种模糊策略，而是能精准定位：是包名写错了？是截图编码漏了？还是 WiFi 信号差？每一次失败，都成为一次深度理解框架的机会。

真正的 AI 工程化，始于对执行过程的完全掌控。而日志，就是你握在手中的第一把钥匙。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。