一、三步走

• 第 1 步 找证据：SQL 查事件流水（session-query-sqlite）——那一轮发生了什么，逐条列出。
• 第 2 步 看视图：stats／turn-outline 定位出问题的那一轮、那一步。
• 第 3 步 判断：按下面的标准分锅。

顺序不能反——先判断后找证据，就会顺着偏见找材料。

二、分锅标准

• 模型没看见所需信息——上下文／检索问题，Harness 的锅。
• 模型看见了却做错——模型的问题。
• 工具结果没进上下文——管线／压缩问题，Harness 的锅（6.6.4）。

核心是第一类与第三类：大量【模型不行】的案例，其实是【模型没看见】——锅在装配。

三、为什么这套方法成立

回头看，它站在本章所有铺垫上：

• 6.4 事实库——流水能查。
• 6.5 可追溯——看见过什么有据。
• 6.6.3 Projection——视图随便切，事实不动。
• 6.6.4 压缩可解释——【被压掉】能指出来。
• 6.8.1 重建——现场能还原。

缺任何一环，三步就断一步——这就是本章叫【全过程】的原因。

四、一个最小工作流

1. 查：那一轮的工具调用与结果，逐条过。
2. 比：工具结果与下一步模型输入——信息进来没有？
3. 判：按分锅标准下结论，必要时重建现场（6.8.1）。

十分钟的查询，胜过十次重试碰运气——这也是对【再跑一遍说不定就好了】的正面回答。

五、动手 Demo：用 Session 调试 Agent

三步走与分锅标准：

steps = ["1 找证据: SQL 查事件流水",
         "2 看视图: stats/outline 定位",
         "3 判断: 按标准分锅"]
for s in steps:
    print("  %s" % s)
print()
print("  没看见信息 -> Harness 的锅")
print("  看见了做错 -> 模型的锅")
print("  结果没进上下文 -> 管线/压缩的锅")

实跑输出：

--------------------------------------------------------------------
用 Session 调试 Agent
--------------------------------------------------------------------
  三步走：

    第 1 步    先找证据：SQL 查事件流水（session-query-sqlite）
    第 2 步    再看视图：stats / turn-outline 定位那一轮
    第 3 步    后判断：是模型的问题，还是 Harness 的问题

  第 3 步的判断标准：

  现象                   判断
  --------------------------------------------------------
  模型没看见所需信息     上下文／检索问题 —— Harness 的锅
  看见了却做错           模型的问题
  工具结果没进上下文     管线／压缩问题 —— Harness 的锅
  --------------------------------------------------------

  一句话：**先找证据，再判断——别上来就怪模型。**
  而【找证据】之所以可能，靠的是 6.4~6.7 那一套可追溯设计。

顺序不能反——先判断后找证据会顺着偏见走。 大量【模型不行】其实是【模型没看见】——锅在装配。 方法站在全章铺垫上——缺一环断一步。

30 秒实验

1. 把三步走背下来，并说出每步用什么包。
2. 举一个【模型没看见】的真实场景，说明该怎么查。
3. 用一句话回答【再跑一遍说不定就好了】。

常见误区

1. 错误：Agent 输出不对，先换模型。——纠正：先查流水——大量案例是模型没看见信息。
2. 错误：调试靠重试碰运气。——纠正：十分钟的查询胜过十次重试——证据链才是解药。
3. 错误：分锅靠感觉。——纠正：标准就三条——没看见／看见做错／结果没进上下文。

• ☐ 下一节（6.9 本章小结）

相关笔记

• Session 不是简单的消息数组 —— 方法的数据地基
• 上下文压缩也必须保持可解释 —— 分锅标准第三条的出处
• 日志是调查事故原因的重要线索 —— 先找证据，再下结论
• 🐳 DeepSeek Harness · 索引