Open-AutoGLM日志查看技巧，快速定位问题所在
本文聚焦于 Open-AutoGLM 实际部署与调试过程中的日志分析实战经验，不讲原理、不堆概念，只分享你在连接失败、操作卡顿、模型无响应时，该看哪几行日志、怎么看、为什么这么看。所有技巧均来自真实设备调试现场，覆盖 USB/WiFi 连接、ADB 异常、模型服务通信、动作执行失败等高频问题。
1. 日志体系概览：三类日志，各司其职
Open-AutoGLM 的日志不是一锅粥，而是分层设计的“侦察兵网络”。理解每类日志的职责，是高效排查的第一步。
1.1 控制端（本地电脑）日志：你的“操作台仪表盘”
这是你运行python main.py时终端输出的内容，也是最先看到、最需关注的日志。它不记录底层细节，但精准反映“你做了什么”和“系统反馈了什么”。
典型内容：
- 设备连接状态（
Connected to device: emulator-5554） - 当前步骤编号与屏幕信息摘要（
Step 3: current_app=抖音, screenshot_size=1080x2400） - AI 推理耗时（
Inference time: 2.41s, first token: 0.27s） - 动作执行结果（
Executed Tap at [520, 310] -> success） - 关键错误提示（
ERROR: ADB command failed: adb shell input tap 520 310）
- 设备连接状态（
核心价值：它是问题定位的起点。如果任务卡在某一步，这里会明确告诉你卡在哪、执行了什么动作、结果是成功还是失败。
1.2 ADB 系统日志（logcat）：设备的“心跳监测仪”
这是 Android 设备自身的运行日志，通过adb logcat命令获取。它不关心你的 AI 指令，只忠实记录设备每一秒发生了什么——系统服务启动、应用崩溃、权限拒绝、输入法切换……所有与 Open-AutoGLM 操作强相关的底层事件，都藏在这里。
典型内容：
I/ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.ss.android.ugc.aweme/.main.MainActivity}（AI 启动抖音）W/InputMethodManager: Starting input on non-focused client com.android.adbkeyboard/.AdbIME（ADB Keyboard 切换成功）E/AndroidRuntime: FATAL EXCEPTION: main Process: com.tencent.mm ... java.lang.SecurityException: Permission Denial: starting Intent（微信启动被拒）
核心价值：当控制端日志只显示“执行失败”，而你不知道为什么时，logcat 就是真相的唯一来源。它能告诉你，是应用没权限？还是系统阻止了截图？或是输入法根本没切过去？
1.3 模型服务端日志：AI 的“思维日记”
这是运行 vLLM 或 SGLang 服务端时产生的日志（例如python -m vllm.entrypoints.openai.api_server ...的输出）。它记录模型加载、请求接收、推理过程、显存使用等，是判断“AI 是否在线”、“是否理解指令”、“有无资源瓶颈”的关键。
典型内容：
INFO: Started server process [12345]（服务启动成功）INFO: Received request for model autoglm-phone-9b（收到请求）WARNING: OOM when allocating tensor with shape...（显存不足警告）INFO: Request processed in 2.34s（单次请求耗时）
核心价值：当你发现控制端日志里 AI 总是“无响应”或“返回乱码”，问题大概率出在这里。它能帮你区分：是网络不通？是模型没加载？还是显存炸了？
2. 高频问题诊断：按现象反查日志路径
别再大海捞针。以下是最常见的 5 类故障，以及你应该立刻打开、重点扫描的日志位置和关键词。
2.1 “adb devices 显示 device，但 main.py 报错连接失败”
现象：adb devices能看到设备，但运行python main.py --device-id XXX "任务"时，报错类似Connection refused或Device not found。
日志路径与关键词：
- 第一步：检查控制端日志开头几行
找到Connecting to device: XXX后的下一行。如果出现ERROR: Failed to get device IP或ERROR: ADB command 'adb -s XXX shell getprop ro.build.version.release' failed，说明 ADB 通信本身就有问题。 - 第二步：立即执行
adb -s XXX shell echo test
这不是看日志，而是做验证。如果这句命令也失败，问题就彻底锁定在 ADB 层。此时，跳过所有其他日志，直接看 ADB 自身状态：
如果# 在终端执行，观察输出 adb version adb kill-server && adb start-server adb -s XXX shell getprop ro.product.modelgetprop命令超时或报错，说明设备 USB 调试未真正生效，或驱动异常。此时adb logcat和模型日志完全无关，无需查看。
2.2 “任务执行到一半卡住，日志停在某一步不动”
现象：日志显示Step 5: current_app=小红书...，然后就再也没有新输出，程序既不报错也不继续。
日志路径与关键词：
- 第一步：紧盯控制端日志的最后一条
它一定是Executing action: do(action="XXX", ...)。记下这个动作类型（如Tap,Type,Swipe）。 - 第二步：立刻打开 ADB logcat，过滤关键词
不要全屏滚动，用Ctrl+F搜索：- 如果是
Tap或Swipe：搜索input tap、input swipe、MotionEvent。如果完全搜不到，说明 ADB 命令根本没发出去，问题在控制端代码逻辑或设备连接中断。 - 如果是
Type：搜索ADB_INPUT_TEXT、AdbIME、InputMethodService。如果看到W/InputMethodService: Not allowed to switch to com.android.adbkeyboard，说明 ADB Keyboard 未被授权，需手动在手机设置中开启“ADB Keyboard”的“允许显示在其他应用上”权限。
- 如果是
- 第三步：检查设备屏幕
卡住时，手机屏幕是否停留在某个加载动画（如抖音的“正在加载”）？如果是，日志里必然有Waiting for app to load...，这是正常等待，不是故障。耐心等 10 秒，日志会继续。
2.3 “AI 返回的动作明显错误，比如在微信里点坐标[10,10]（左上角）”
现象：日志显示AI action: do(action="Tap", element=[10, 10])，但这个坐标在当前屏幕上毫无意义（比如是个状态栏）。
日志路径与关键词：
- 第一步：确认控制端日志中该步骤的截图尺寸
找到Step X: ... screenshot_size=WIDTHxHEIGHT。如果尺寸是1080x2400，但你手机实际是1440x3200，说明 ADB 截图命令失败，返回了默认尺寸的黑图或缩略图。此时 AI 是在“瞎猜”。 - 第二步：检查 ADB logcat 中的截图相关日志
搜索screencap、tmp.png、Status: -1。如果看到Status: -1，说明截图被系统拒绝（常见于支付、银行类 App），AI 收到的是黑屏，自然无法准确定位。此时日志里应紧接着出现is_sensitive=True或Take_over required提示。 - 第三步：回溯上一步日志
查看Step X-1的current_app是什么。如果上一步是System Home，这一步却在微信里点坐标，说明 AI 错误地认为已经进入了微信，问题出在get_current_app()函数的识别上。此时去phone_agent/adb/device.py查看get_current_app的实现，并在 logcat 中搜索dumpsys window的输出，看它是否真的解析出了正确的包名。
2.4 “中文输入全是乱码或空格，日志里显示 type_text 成功”
现象：控制端日志显示Executed Type text '你好世界' -> success，但手机上输入框里是????或一堆空格。
日志路径与关键词：
- 第一步：检查控制端日志中 ADB Keyboard 的切换过程
找到Switching to ADB Keyboard...和ADB Keyboard activated这样的日志。如果没有，说明切换失败。 - 第二步：强制在 ADB logcat 中搜索
AdbIME
执行adb logcat | grep AdbIME，然后在手机上手动触发一次输入（比如用adb shell am broadcast -a ADB_INPUT_TEXT --es msg "test"）。如果 logcat 里完全没有AdbIME相关输出，说明 APK 根本没安装或没启用。此时去手机“设置 > 语言与输入法 > 当前输入法”，确认ADB Keyboard已被选中。 - 第三步：检查文本编码
在phone_agent/adb/input.py中，找到type_text函数。确保encoded_text = text.replace(" ", "%s")这行之后，发送的广播命令是am broadcast -a ADB_INPUT_TEXT --es msg "你好世界"。如果日志里显示发送的是am broadcast ... --es msg "hello"，说明代码逻辑被意外修改，或环境变量PHONE_AGENT_LANG设置错误。
2.5 “模型服务端日志疯狂刷 WARNING，但控制端一切正常”
现象：vLLM 服务端日志里不断出现WARNING: GPU memory usage is high或WARNING: Prefill is slow，而main.py运行流畅，AI 响应也快。
日志路径与关键词：
- 这不是故障，是预警。这类日志意味着你的 GPU 正在高负荷运转，但尚未达到崩溃阈值。
- 关键判断点：看日志里是否有
ERROR或CRITICAL字样。只要没有，且控制端的Inference time数值稳定（比如始终在 2.0-2.5s），就可以忽略这些 WARNING。 - 何时需要干预？当
Inference time开始剧烈波动（如从 2s 跳到 8s），或出现OOM（Out of Memory）字样时，才需行动。此时，不要改代码，先调参数：
参数调整后，重启服务，观察 WARNING 是否减少、# 启动 vLLM 时，增加显存限制和最大长度 python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --gpu-memory-utilization 0.8 \ --max-model-len 4096 \ --port 8000Inference time是否回归稳定。
3. 日志精读实战：从一行报错读懂整个链路
理论不如实战。我们来解剖一个真实案例的日志片段，看看如何像侦探一样抽丝剥茧。
3.1 案例背景
用户报告：“运行python main.py "打开淘宝搜索iPhone"，程序在Step 2卡住，日志最后是Executing action: do(action="Type", text="iPhone")，手机淘宝搜索框没任何反应。”
3.2 日志片段还原
[INFO] Step 2: current_app=淘宝, screenshot_size=1080x2400 [INFO] Building message for model... [INFO] AI response received in 1.82s [INFO] Parsed action: {'_metadata': 'do', 'action': 'Type', 'text': 'iPhone'} [INFO] Executing action: do(action="Type", text="iPhone") [INFO] Switching to ADB Keyboard... [INFO] ADB Keyboard activated [INFO] Sending broadcast: am broadcast -a ADB_INPUT_TEXT --es msg "iPhone" [INFO] Restoring original input method... [INFO] Executed Type text 'iPhone' -> success3.3 逐行精读与推理
| 日志行 | 关键词/信息 | 推理结论 | 下一步动作 |
|---|---|---|---|
Step 2: current_app=淘宝 | 当前应用正确 | AI 知道在淘宝，没问题 | —— |
Parsed action: ... 'text': 'iPhone' | AI 输出的文本正确 | Prompt 工程有效，AI 理解了任务 | —— |
Switching to ADB Keyboard...ADB Keyboard activated | 切换日志存在 | 输入法切换流程已触发 | 检查手机设置中 ADB Keyboard 是否启用 |
Sending broadcast: ... msg "iPhone" | 广播命令已发出 | 控制端代码执行无误 | 立刻看 ADB logcat |
Restoring original input method... | 恢复流程也执行了 | 代码逻辑完整 | —— |
Executed Type text ... -> success | 这是最大的陷阱！success只代表 Python 脚本里的subprocess.run(...)命令执行成功，并不代表广播真的被 ADB Keyboard 接收到了！ | 问题一定在 ADB Keyboard 的接收端 | 在手机上打开ADB Keyboard的设置，看“接收广播”开关是否打开 |
最终定位：用户手机上的 ADB Keyboard 应用，其“接收广播”权限被手动关闭了。虽然控制端日志显示success，但广播根本没送达。打开该开关后，问题立即解决。
核心教训：-> success不等于“功能成功”，它只代表“命令发出去了”。真正的功能成功，必须由 ADB logcat 或设备屏幕来验证。
4. 效率工具箱：三条命令，省下 90% 的日志时间
别再手动翻日志。掌握这三个命令，让问题定位从“找线索”变成“查答案”。
4.1 一键过滤并高亮关键事件（Linux/macOS）
# 监控所有与 Open-AutoGLM 相关的实时日志流 adb logcat | grep -E "(ADB_INPUT_TEXT|AdbIME|screencap|dumpsys|com\.android\.adbkeyboard)" --color=always # 解释：-E 表示扩展正则，--color=always 让关键词高亮，一眼就能抓住重点4.2 快速定位最近一次截图失败（Windows/Linux/macOS）
# 查看最近 50 行 logcat，专门找截图失败线索 adb logcat -t 50 | findstr /i "screencap Status: -1 Failed" # Linux/macOS 替代命令 adb logcat -t 50 | grep -i "screencap\|Status: -1\|Failed"4.3 检查 ADB Keyboard 是否在前台（终极验证）
# 这条命令直接告诉你，此刻哪个输入法在“掌权” adb shell settings get secure default_input_method # 正常输出示例：com.android.adbkeyboard/.AdbIME # 如果输出是 com.sohu.inputmethod.sogouoem/.SogouIMEService，说明 ADB Keyboard 被切走了5. 总结：日志不是文档，是你的对话伙伴
日志不是冰冷的记录，而是 Open-AutoGLM 与你进行的一场无声对话。它不会主动告诉你“我哪里坏了”，但它会诚实地回答你每一个具体的问题。
- 当你问“设备连上了吗？”→ 看控制端日志第一行
Connecting to...和adb devices输出。 - 当你问“AI 看到屏幕了吗？”→ 看控制端日志里的
screenshot_size和 ADB logcat 里的screencap结果。 - 当你问“点击为什么没反应？”→ 看 ADB logcat 里有没有
input tap的执行日志，以及MotionEvent的上报日志。 - 当你问“中文为什么输不出？”→ 看 ADB logcat 里有没有
ADB_INPUT_TEXT的接收日志，以及default_input_method的当前值。
记住，最高效的调试者，不是那个翻遍所有日志的人，而是那个每次只问一个问题、并精准找到答案所在那一行日志的人。
--- > **获取更多AI镜像** > > 想探索更多AI镜像和应用场景？访问 [CSDN星图镜像广场](https://ai.csdn.net/?utm_source=mirror_blog_end)，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
