Open-AutoGLM调试模式开启，查看AI思考全过程

Open-AutoGLM调试模式开启，查看AI思考全过程

你有没有想过，当AI在手机上执行“打开小红书搜美食”这条指令时，它到底经历了什么？不是黑箱式的一键完成，而是像一位经验丰富的数字助手——先看清屏幕、再理解你的意图、接着拆解步骤、最后谨慎执行。Open-AutoGLM 的调试模式，正是把这套“AI思考链”完整摊开给你看的窗口。

本文不讲抽象原理，也不堆砌参数配置。我们聚焦一个最实用也最容易被忽略的能力：如何真正看见AI在做什么、为什么这么做、哪里卡住了、又怎么绕过去。你会亲手启动调试模式，逐帧观察视觉理解、意图解析、动作规划、ADB执行四个关键环节的输出，并掌握一套可复用的排查心法——哪怕遇到验证码弹窗、界面加载延迟或模型“答非所问”，也能快速定位是感知偏差、规划失误，还是控制失联。

这不仅是技术验证，更是建立人机协作信任的第一步。

1. 为什么需要“看见AI思考”？

在手机Agent这类强交互、高容错要求的场景中，静默运行等于埋雷。真实使用中，你可能遇到这些典型困惑：

• 指令发出去后毫无反应，是模型没收到？还是ADB断连了？
• AI点错了按钮，是截图识别不准？还是对“搜索框”的语义理解有偏差？
• 执行到登录页突然停住，它是在等你输密码，还是根本没识别出验证码弹窗？
• 远程WiFi连接下操作变慢，是网络延迟导致截图滞后，还是模型推理本身变卡？

这些问题无法靠最终结果反推——因为“失败”没有日志，“卡顿”没有快照，“误解”没有回放。而Open-AutoGLM的调试模式，就是为解决这些“不可见问题”而生。

它不是简单的--verbose开关，而是一套分层可观测机制：

• 视觉层：输出原始截图、OCR识别文本、UI元素坐标框
• 语义层：展示模型对当前界面的自然语言描述（如：“屏幕顶部有搜索栏，中间是3个推荐商品卡片”）
• 规划层：呈现AI生成的动作序列（如：“1. 点击搜索栏 → 2. 输入‘火锅’ → 3. 点击搜索图标”）
• 执行层：记录每条ADB命令、返回状态、耗时及错误详情

这种全链路透明化，让调试从“猜”变成“查”，从“重试”变成“修正”。

2. 调试模式实战：四步开启AI思考回放

调试模式无需修改代码，只需在启动命令中添加两个关键参数。以下以本地USB连接+本地vLLM服务为例（远程WiFi或第三方API同理，仅需替换对应地址）。

2.1 前置确认：确保基础环境就绪

在开启调试前，请务必验证三项基础能力正常：

• ADB连通性
  终端执行adb devices，输出应类似：

  List of devices attached 1234567890abcdef device

  若显示unauthorized，请在手机弹窗点击“允许USB调试”；若为空，检查USB线是否支持数据传输。

• 模型服务可用性
  访问http://localhost:8000/v1/models（假设vLLM端口为8000），应返回JSON格式的模型列表，包含autoglm-phone-9b。

• ADB Keyboard已启用
  进入手机“设置→系统管理→语言与输入法→当前输入法”，确认已切换为“ADB Keyboard”。这是实现无触控文本输入的关键。

重要提醒：调试模式会显著增加日志量，建议将终端输出重定向至文件便于回溯：
python main.py --device-id 1234567890abcdef --base-url http://localhost:8000/v1 --model "autoglm-phone-9b" --verbose "打开小红书搜美食" > debug_log.txt 2>&1

2.2 启动命令：添加--verbose与--debug-screenshot

核心命令如下（请根据实际环境替换设备ID和URL）：

python main.py \ --device-id 1234567890abcdef \ --base-url http://localhost:8000/v1 \ --model "autoglm-phone-9b" \ --verbose \ --debug-screenshot \ "打开小红书搜美食"

• --verbose：激活全链路日志，输出视觉理解、意图解析、动作规划、ADB执行四层信息
• --debug-screenshot：在./debug_screenshots/目录下保存每一步操作前的原始截图（命名含时间戳与步骤序号）

注意：--debug-screenshot会生成大量图片，首次使用建议搭配简单指令（如“回到桌面”）测试流程。

2.3 日志结构解析：读懂AI的“思考笔记”

执行后，终端将滚动输出结构化日志。我们以关键片段为例，说明各层含义：

视觉层输出（截图理解）

[DEBUG] Screen capture saved to ./debug_screenshots/20240520_142231_001.png [DEBUG] OCR text detected: - "小红书" (top: 82, left: 120, width: 150, height: 48) - "搜索" (top: 210, left: 80, width: 120, height: 42) - "美食" (top: 280, left: 150, width: 80, height: 36) [DEBUG] VLM description: "主屏幕显示小红书App图标，底部导航栏高亮'首页'，顶部有搜索栏，当前无键盘弹出。"

解读：AI不仅识别文字，还理解布局关系（“底部导航栏高亮”）、状态（“无键盘弹出”）。若此处OCR漏掉“搜索”，则问题在图像预处理或分辨率设置。

语义层输出（意图解析）

[DEBUG] User instruction: "打开小红书搜美食" [DEBUG] Parsed intent: { "app_name": "小红书", "action": "search", "query": "美食", "target_element": "搜索栏" }

解读：模型准确拆解出应用名、动作、搜索词、目标控件。若app_name误判为“微博”，需检查系统提示词或微调模型。

规划层输出（动作序列）

[DEBUG] Action plan: Step 1: Launch app 'com.xingin.xhs' (package name for 小红书) Step 2: Wait for UI to stabilize (max 5s) Step 3: Tap element at (x: 140, y: 231) [Search bar] Step 4: Input text '美食' Step 5: Tap element at (x: 920, y: 231) [Search icon]

解读：坐标(140, 231)来自OCR识别的“搜索”区域中心。若点击位置偏移，可对比截图确认坐标是否匹配实际UI。

执行层输出（ADB反馈）

[DEBUG] Executing ADB: adb -s 1234567890abcdef shell am start -n com.xingin.xhs/.activity.SplashActivity [INFO] ADB success (took 0.82s) [DEBUG] Executing ADB: adb -s 1234567890abcdef shell input tap 140 231 [INFO] ADB success (took 0.15s) [DEBUG] Executing ADB: adb -s 1234567890abcdef shell input text '美食' [INFO] ADB success (took 0.21s)

解读：每条ADB命令附带耗时，便于定位瓶颈。若某步耗时超2秒，大概率是界面未加载完成（需增加--wait-timeout参数）。

2.4 调试模式进阶技巧

• 聚焦特定环节：通过日志关键词快速过滤
  grep "VLM description" debug_log.txt→ 查看所有视觉理解
  grep "Action plan" debug_log.txt→ 定位规划逻辑
  grep "ADB success" debug_log.txt→ 验证执行连通性

• 对比分析法：对同一指令，在不同网络环境（USB/WiFi）或不同模型（9B/多语言版）下分别运行，对比日志差异，精准归因性能波动。

• 人工接管触发：当遇到验证码时，日志会明确提示：
  [WARNING] Sensitive action detected: login screen with captcha. Human takeover required.
  此时可手动输入，再继续执行后续步骤。

3. 从调试日志到问题解决：三个高频场景实战

调试模式的价值，最终体现在快速闭环问题。以下是开发者最常遇到的三类问题及根因定位路径。

3.1 场景一：AI反复点击错误位置，始终打不开目标App

现象：指令“打开抖音”后，AI在桌面不断点击空白区域，抖音图标未被激活。

日志线索：

[DEBUG] VLM description: "桌面有12个应用图标，排列成3行4列。左上角图标为微信，右下角图标为设置。" [DEBUG] Parsed intent: {"app_name": "抖音", "action": "launch"} [DEBUG] Action plan: Step 1: Tap element at (x: 210, y: 450) [assumed position]

根因分析：
VLM描述中完全未提及“抖音”图标，说明模型未能识别该应用。可能原因：

• 图标样式特殊（如动态壁纸遮挡）
• 截图分辨率过低（默认720p可能丢失细节）
• 应用未在系统白名单中（检查config/app_whitelist.json）

解决方案：

1. 提高截图质量：在main.py中修改SCREENSHOT_QUALITY=95（默认80）
2. 手动添加图标坐标：在config/app_positions.json中为抖音补充精确坐标
3. 临时启用全屏OCR：添加参数--ocr-full-screen强制识别所有文字

3.2 场景二：输入文字后无响应，搜索未触发

现象：AI成功点击搜索栏并输入“美食”，但未点击搜索图标，停留在输入状态。

日志线索：

[DEBUG] OCR text detected: "美食" (top: 231, left: 150, width: 120, height: 42) [DEBUG] VLM description: "搜索栏内显示'美食'，右侧有放大镜图标。" [DEBUG] Action plan: Step 4: Input text '美食' → Step 5: Tap element at (x: 920, y: 231) [Search icon] [DEBUG] Executing ADB: adb -s ... shell input tap 920 231 [ERROR] ADB failed: Command timed out after 3s

根因分析：
ADB命令超时，而非坐标错误。常见于：

• WiFi连接下ADB延迟过高（>1s）
• 手机启用了“省电模式”，限制后台ADB服务
• 搜索图标被软键盘遮挡（日志中VLM description未提键盘，但实际已弹出）

解决方案：

1. USB直连替代WiFi（优先）
2. 关闭手机省电模式
3. 在输入后强制收起键盘：添加动作Step 4.5: adb shell input keyevent 4（返回键）

3.3 场景三：多步骤任务中途停止，无错误提示

现象：指令“打开淘宝搜无线耳机→点击第一个商品→加入购物车”执行到第二步后静默退出。

日志线索：

[DEBUG] Action plan: Step 1: Launch Taobao... [INFO] ADB success [DEBUG] Action plan: Step 2: Tap first product card... [INFO] ADB success [DEBUG] Action plan: Step 3: Tap 'Add to cart' button... [DEBUG] Executing ADB: adb -s ... shell input tap 520 890 [INFO] ADB success [INFO] Task completed successfully.

根因分析：
日志显示“Task completed”，但实际未加入购物车。问题在于：

• “Add to cart”按钮在点击时未处于可点击状态（如需滑动到视图内）
• 模型规划了动作，但未校验执行结果（如按钮点击后是否出现toast提示）

解决方案：

1. 启用动作后校验：添加参数--verify-after-action，要求AI在每次点击后重新截图并确认UI变化
2. 增加滚动动作：在规划中插入Step 2.5: Swipe from (500,1200) to (500,800)确保按钮可见
3. 自定义回调函数：在phone_agent/callbacks.py中实现on_action_success，检测toast文本“已加入购物车”

4. 调试模式下的工程化建议

调试不是终点，而是优化起点。基于数百次真实调试经验，我们总结出三条落地建议：

4.1 建立“截图-日志-行为”三维索引

将每次调试生成的截图、日志、ADB命令导出为结构化数据集：

• screenshots/20240520_142231_001.png
• logs/20240520_142231.log
• adb_commands/20240520_142231.sh

用脚本自动关联三者，形成可检索的故障库。例如：搜索关键词“验证码”，即可调取所有相关截图与日志，加速同类问题复现。

4.2 用调试日志反哺模型微调

收集高频失败案例的日志，提炼特征：

• 视觉层：哪些UI元素常被漏识别？（如深色背景上的白色文字）
• 语义层：哪些指令表述易被误解？（如“搜附近” vs “搜周边”）
• 规划层：哪些动作序列常出错？（如长按未触发菜单）

将这些样本整理为SFT数据，针对性微调VLM或规划模块，比盲目扩大训练数据更高效。

4.3 将调试能力产品化：为终端用户设计“透明模式”

在面向业务方的部署中，可将调试模式封装为可选功能：

• 用户端：APP内开启“AI操作回放”，以动画形式展示AI每一步思考与操作
• 运维端：后台实时推送关键节点日志（如“已识别搜索框”、“正在输入...”），替代黑屏等待

这不仅能降低用户疑虑，更能将调试成本前置到产品设计阶段。

5. 总结：让AI思考成为可触摸的工程资产

Open-AutoGLM的调试模式，远不止于排错工具。它把AI的“认知过程”转化为可读、可查、可存、可优化的工程资产。当你第一次看到日志中清晰呈现“AI认为这个蓝色按钮是搜索图标”，你就不再把它当作魔法，而是一个可以理解、可以讨论、可以改进的协作伙伴。

真正的智能体价值，不在于它能多快完成任务，而在于当任务受阻时，你能多快理解它、帮助它、教会它。调试模式，就是这份理解力的起点。

现在，打开你的终端，输入那条带--verbose的命令——这一次，你不是在指挥AI，而是在和它一起工作。

--- > **获取更多AI镜像** > > 想探索更多AI镜像和应用场景？访问 [CSDN星图镜像广场](https://ai.csdn.net/?utm_source=mirror_blog_end)，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。