当 Desktop 端返回了与输入不匹配的输出，先打开请求日志核对当时的实际输入、输出和耗时。日志能告诉你请求是否按预期送达、参数是否被改写、响应是否被截断，但它不会告诉你模型为什么说错。处理方向是先还原请求记录，再确认异常发生在前置参数、网络阶段还是响应解析阶段。

判断方向：先用请求 ID 把一条请求的输入、输出、耗时拼回同一份记录，再决定是否调整参数或重试。操作动作：打开日志目录，按时间或 ID 过滤，对比同参请求。验证方式：连续多次相同请求，看输出波动是否依然存在。风险边界：请求日志不一定包含模型内部推理细节，不能仅凭日志断言模型故障。

找到请求日志的存储位置和格式

打开日志目录通常可以从 Desktop 的“帮助”菜单中看到“打开日志目录”入口；没有入口时，Linux 下一般位于 ~/.local/share/DeepSeekHarness/logs/，macOS 在 ~/Library/Logs/DeepSeek Harness/，Windows 在 %USERPROFILE%\.deepseek-harness\logs\。命名规则一般为 harness-YYYY-MM-DD.log，启动新会话时可能增加 -N 后缀（如 harness-2025-06-14-01.log）。

每行字段不统一，但常见字段如下表。

不同版本的字段名可能不同，先用 less 查看原始日志确认。

用请求 ID 关联输入与输出

请求ID通常在每行日志的固定位置，如 request_id=req_9f3b8c2a，也可能在 JSON 字段中。提取完整记录：

grep 'req_9f3b8c2a' harness-*.log
jq 'select(.request_id=="req_9f3b8c2a")' harness-2025-06-14.log
grep -C 5 'req_9f3b8c2a' harness-*.log

如果日志中只有一行包含全部信息，那上面的命令已经足够；如果输入输出分散在多行，则用 awk 按时间戳范围截取。

过滤超时与高延迟请求

耗时字段通常名为 duration_ms、elapsed_ms 或 latency。过滤超过一定阈值的请求（例如5秒）：

grep -E 'duration_ms=[0-9]{5,}' harness-*.log
jq -c 'select(.duration_ms > 5000)' harness-*.log
grep -oP 'duration_ms=\K[0-9]+' harness-*.log | sort -nr | head -20
awk '{match($0,/duration_ms=([0-9]+)/,a); if(a[1]>5000) print}' harness-*.log

这里要注意，grep -P 在 macOS 下需要安装 GNU grep，或者改用 sed/awk。

对比同参数请求的两次输出差异

差异对比前，先确保两次请求的模型名、temperature、max_tokens、输入文本完全一致。用以下命令把两次请求各存成文件：

grep 'req_A' harness-2025-06-14.log > case_A.log
grep 'req_B' harness-2025-06-15.log > case_B.log
grep -oP 'output_preview=\K[^,}]+' case_A.log > out_A.txt
grep -oP 'output_preview=\K[^,}]+' case_B.log > out_B.txt
diff -u out_A.txt out_B.txt

如果差异过大，再对比完整请求记录：

diff -u case_A.log case_B.log

需要重点对比的字段：input_preview、model、temperature、max_tokens、duration_ms、status、error_msg。若两次参数一致、输入一致，输出仍明显变化，那更可能是采样随机性或服务端状态变化；若要进一步确认，需连续多次请求，记录每次输出，看是否在稳定区间波动。风险边界：日志中的 input_preview 和 output_preview 可能是被截断的，diff 差异可能只来自截断位置变化，此时需要查看完整输入输出（如果日志有完整存档）。