一、两路事件

• 持久会话事件：落盘、append-only——管回放、重建、审计。
• 实时能力事件：内存里、进行时——管展示、干预、界面联动。

实测对应：前者是 session-persistence-jsonl，后者是 agent-loop推进过程中发出的进行时事件。

进行时的事件不会都进流水，流水里的也不为界面实时服务——各干各的。

二、为什么实时事件要单独存在

【支持干预】需要它：

• 界面上能看进度——靠进行时的事件流。
• 能打断、能插话——需要对还没落盘的当下做反应。
• 能联动能力（比如临时换预设）——要挂在活着的过程上。

等落盘再反应，黄花菜都凉了——实时事件就是为【当下】生的。

三、为什么持久事件要 append-only

• 改不了历史：审计的前提——6.4 讲过。
• 顺序即事实：append 的顺序就是发生顺序，不用猜。
• 可重放：从头读一遍就是完整过程（6.8.1 的材料）。

实时事件恰恰相反：用过即弃，不承担历史责任——它轻装上阵才有实时性。

四、两路的交接

进行时的事件最终会沉淀为持久流水——干活的过程被记账。

• 干预了什么（打断、改参数），持久流水里也会留记录。
• 所以【有人插过手】这件事是可追溯的——审计不打折。

实时负责当下，持久负责历史；交接处有账——两平面各管各的寿命，又是 3.2 那条【它该活多久】的老标准。

五、动手 Demo：持久事件与实时事件

两路事件的三栏对照：

rows = [
    ("在哪", "落盘, append-only", "内存里, 进行时"),
    ("干什么用", "回放、重建、审计", "展示、干预、联动界面"),
    ("实测对应", "session-persistence-jsonl", "agent-loop 推进过程"),
]
for a, b, c in rows:
    print("  %-8s | %-26s | %s" % (a, b, c))
print()
print("  实时负责当下, 持久负责历史; 交接处有账")

实跑输出：

--------------------------------------------------------------------
持久事件与实时事件
--------------------------------------------------------------------
  同一轮工作，事件分两路走：

               持久会话事件                  实时 Agent 能力事件
  -----------------------------------------------------------------
  在哪         落盘，append-only             内存里，进行时
  干什么用     回放、重建、审计              展示、干预、联动界面
  实测对应     session-persistence-jsonl     agent-loop 的推进过程
  -----------------------------------------------------------------

  为什么实时事件也要单独记？因为【支持干预】需要它：
  界面上能打断、能插话、能看进度，靠的是**进行时**的事件流；
  而事后回放靠的是**完成时**的持久流水。

  两路各管各的，**谁也不冒充谁**——又是两平面思想的影子。

为当下生的和为历史生的不能混——寿命不同（4.5.2 的老道理）。 干预也会留痕——审计不打折。 append-only 的三个理由：改不了历史、顺序即事实、可重放。

30 秒实验

1. 各举一个持久事件与实时事件的例子。
2. 解释：为什么界面打断必须靠实时事件，不能等落盘。
3. 说说【有人插过手】怎么从流水里查出来。

常见误区

1. 错误：事件记一份就够了，界面直接读流水。——纠正：实时性不够——干预需要内存里的进行时事件。
2. 错误：实时事件用完就丢，等于没记过。——纠正：它沉淀为持久流水——干预本身也留痕。
3. 错误：持久流水可以修改补录。——纠正：append-only——改历史是审计的灾难。

• ☐ 下一节（6.6.2 为什么还要保留 assistant/chunk）

相关笔记

• 模型看见的内容应当可追溯 —— 记什么的清单
• Approval 与 Sandbox 为什么必须放在不同层 —— 寿命不同就分层的先例
• 本章小结 —— 两平面思想第三次出现
• 🐳 DeepSeek Harness · 索引