一、四类事件，一条不少

• 用户消息：人说了什么。
• assistant chunk：模型流式吐出的每一小段。
• 工具调用：模型决定调什么、传什么参数。
• 工具结果：工具实际回了什么。

注意第二类：连流式的碎片都要记——6.6.2 单独讲为什么。

二、算一笔账：一轮 3 Step 的流水

用户消息 1 条；每步至少 1 次调用＋1 个结果（6 条）；每步至少 1 段输出（3 条）——

至少 10 条事件。真实流水只会更多（chunk 一条就是一条）。

量不小，但 JSONL 追加很便宜——6.4 说的【便宜地买回过程】。

三、可追溯的三个用途

• 调试：模型当时看见了什么，翻流水就知道——6.8.3 的第一步。
• 审计：干了什么、经没经人批准，条条可查——合规的底气。
• 学习：复盘一次成功的任务，过程本身就是教材。

三个用途共享同一份流水——记一次，处处能用。

四、底线在哪

凡是进入模型上下文的东西，流水里必须有。

• 看见了却没记——追溯断链。
• 记了但不在上下文——那是【想给没给成】，也要记（系统事件）。

这条底线到 6.8.3 会变成一把尺子：判断是模型的锅还是 Harness 的锅，先看模型看见了什么。

五、动手 Demo：模型看见的内容应当可追溯

四类事件，加一轮 3 Step 的流水算术：

events = ["用户消息", "assistant chunk", "工具调用", "工具结果"]
for e in events:
    print("  事件: %s" % e)
print()
n = 1 + 3 * 2 + 3
print("  一轮 3 Step 至少 %d 条事件" % n)
print("  底线: 凡进入上下文的, 流水里必须有")

实跑输出：

--------------------------------------------------------------------
模型看见的内容应当可追溯
--------------------------------------------------------------------
  会话流水里，至少有四类事件：

  事件                记的是什么
  -----------------------------------------------
  用户消息            人说了什么
  assistant chunk     模型流式吐出的每一小段
  工具调用            模型决定调什么、传什么参数
  工具结果            工具实际回了什么
  -----------------------------------------------

  算一笔账：一轮 3 个 Step 的会话，流水里至少几条事件？

    用户消息 1 条
    每步至少 1 次调用 + 1 个结果      6 条
    每步至少 1 段 assistant 输出      3 条
    合计                              至少 10 条

  **模型看见过什么，每一条都有据可查**——这是 6.5 的底线。

连 chunk 都记——时序信息在碎片里，6.6.2 展开。 至少 10 条事件的算术说明：量不小但便宜——JSONL 追加存储。 一条底线记牢：进过上下文的，流水里必须有。

30 秒实验

1. 列出一轮 2 Step 会话的最小流水（几条事件？）。
2. 举一个【看见了却没记】会造成的事故。
3. 说说可追溯的三个用途里，哪个对你最有用。

常见误区

1. 错误：记用户消息和最终回复就够了。——纠正：中间过程才是排查关键——工具调用与结果、连 chunk 都要记。
2. 错误：流水太占地方，抽样记就行。——纠正：追溯不能抽样——缺的那条往往就是要的那条。
3. 错误：可追溯只是给开发者用的。——纠正：调试、审计、学习三用——审计尤其离不开。

• ☐ 下一节（6.6.1 持久会话事件与实时 Agent 能力事件：记录事实和支持干预）

相关笔记

• Session 不是简单的消息数组 —— 事实库的说法从那儿来
• Scope Context：会话级能力从哪里来 —— 记录留下、能力不留
• 日志是调查事故原因的重要线索 —— 日志的价值，安全课讲过一遍
• 🐳 DeepSeek Harness · 索引