OpenClaw调试技巧：捕获千问3.5-27B的中间推理过程与决策

1. 为什么需要调试OpenClaw的中间过程？

上周我尝试用OpenClaw自动整理三个月积压的会议录音时，遇到了一个诡异现象：AI能准确转录音频，却在关键的时间戳标记环节反复出错。查看最终日志只能看到"任务失败"的结论，却无法定位模型到底在哪一步产生了误判。这个经历让我意识到——当OpenClaw执行复杂任务链时，仅看输入输出就像在调试黑箱。

与直接调用API不同，OpenClaw的独特之处在于它需要多轮模型决策。比如一个简单的"截图并识别文字"任务，实际包含：

1. 模型决定截图范围
2. 调用截图工具获取图像
3. 选择OCR服务处理图像
4. 对识别结果进行后处理

每个环节都可能出错，而默认日志往往只记录最终动作。这就是为什么我们需要深入捕获中间推理过程——不是为了看模型说了什么，而是看它为什么这样决策。

2. 配置千问3.5-27B的详细日志

2.1 修改OpenClaw核心配置

首先定位到配置文件（通常位于~/.openclaw/openclaw.json），在模型提供者配置段增加日志参数：

{
  "models": {
    "providers": {
      "qwen-portal": {
        "baseUrl": "http://your-qwen-endpoint",
        "logging": {
          "level": "debug",
          "persist": true,
          "logDir": "/tmp/openclaw_logs"
        }
      }
    }
  }
}

关键参数说明：

• level: debug：启用包括思维链(CoT)在内的完整日志
• persist: true：日志持久化到磁盘而非内存
• logDir：建议指定到/tmp目录避免权限问题

2.2 启动网关时加载调试模式

通过环境变量开启更底层的调试信息：

OPENCLAW_LOG_LEVEL=trace openclaw gateway --port 18789

不同日志级别的区别：

• error：仅关键错误（默认值）
• info：包含任务起止时间（适合生产环境）
• debug：记录完整的模型输入输出
• trace：额外包含鼠标移动、窗口焦点等系统级事件

3. 拦截模型请求与响应

3.1 使用mitmproxy捕获HTTP流量

对于通过API接入的千问3.5-27B模型，可以通过中间人代理捕获原始数据：

# 安装mitmproxy
pip install mitmproxy

# 启动代理并重定向流量
mitmproxy --mode upstream:http://your-qwen-endpoint --set upstream_cert=false

然后在OpenClaw配置中将baseUrl改为http://127.0.0.1:8080。所有请求将经过代理，我们能在控制台看到类似这样的原始数据：

>> 请求
{
  "model": "qwen3-32b",
  "messages": [
    {"role": "system", "content": "你是一个擅长分析屏幕信息的助手..."},
    {"role": "user", "content": "当前窗口的标题是什么？"}
  ]
}

<< 响应
{
  "choices": [{
    "message": {
      "content": "让我先检查活动窗口...",
      "tool_calls": [
        {
          "name": "get_active_window",
          "arguments": {}
        }
      ]
    }
  }]
}

3.2 解析思维链日志

OpenClaw的debug日志会记录模型的完整思考过程。例如处理"截图并识别文字"任务时，典型的日志可能包含：

[THOUGHT] 需要先确定截图区域
[ACTION] 调用 get_screen_resolution 工具
[OBSERVATION] 屏幕分辨率: 1920x1080
[THOUGHT] 用户未指定区域，默认截取中心50%区域
[ACTION] 调用 capture_screenshot 工具
[OBSERVATION] 截图保存为/tmp/shot.png
[THOUGHT] 需要选择OCR服务...

这种结构化的日志比原始API响应更易分析，可以通过grep快速定位问题环节：

cat /tmp/openclaw_logs/qwen.log | grep -A 5 -B 5 "THOUGHT.*截图"

4. 可视化任务拆解步骤

4.1 安装Graphviz可视化工具

# macOS
brew install graphviz

# Ubuntu
sudo apt install graphviz

4.2 生成任务流程图

OpenClaw内置了任务图导出功能。在调试模式下执行任务后，运行：

openclaw debug --task-id TASK_ID --export-dot | dot -Tpng > task_flow.png

这会生成类似下图的流程图：

[用户请求]
  │
  ▼
[思考]是否需要截图？
  │
  ├─是─▶[调用截图工具]
  │       │
  │       ▼
  │    [思考]OCR服务选择
  │
  └─否─▶[直接处理文本]

图表中的菱形节点代表模型决策点，矩形节点代表具体动作，箭头上的标签会显示模型使用的判断依据。

5. 实战调试案例：解决截图偏移问题

最近我在开发自动填写网页表单的Skill时，遇到一个典型问题：模型能正确识别输入框位置，但实际点击总是偏移20像素左右。以下是排查过程：

5.1 复现问题并收集数据

1. 开启trace级别日志
2. 执行表单填写任务3次
3. 导出所有鼠标事件日志：

cat /tmp/openclaw_logs/system.log | grep "mouse_move" > moves.csv

5.2 分析坐标偏差

用Python分析采集到的坐标数据：

import pandas as pd

df = pd.read_csv('moves.csv')
# 计算目标点与实际点击点的差值
df['x_diff'] = df['target_x'] - df['actual_x'] 
df['y_diff'] = df['target_y'] - df['actual_y']
print(df.describe())

输出显示x方向平均偏移23像素，y方向偏移17像素，存在系统性偏差。

5.3 定位问题根源

结合模型日志发现关键线索：

[THOUGHT] 输入框坐标为(120,300)，需考虑浏览器缩放
[ACTION] 设置鼠标位置为(143,317)

最终发现是模型训练数据基于96DPI设计，而我的显示器是125DPI。在配置文件中添加校准参数后问题解决：

{
  "display": {
    "dpi_scaling": 1.3 
  }
}

6. 高级技巧：保存决策快照

对于复杂任务，建议在关键决策点保存屏幕快照。修改Skill代码添加：

from openclaw.tools import screenshot

def on_decision(point):
    img = screenshot(f"decision_{point}.png")
    log.debug(f"Saved snapshot at {point}")

然后在配置中注册回调：

{
  "debug": {
    "decision_points": ["pre_ocr", "post_ocr", "pre_submit"],
    "callback": "on_decision"
  }
}

这些快照将与日志自动关联，形成完整的调试上下文。

---

获取更多AI镜像

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