把会话做成只追加日志：Harness 排障为什么离不开事件流

Agent 线上挂了，最怕的不是报错本身，而是说不清「它当时到底看见了什么、调用了什么、被谁拦住了」。很多系统把状态存在可变对象里：上下文被压缩后覆盖，工具结果被摘要替换，权限决策只留在内存。回放时只剩一个最终快照，像看结局不知道剧情。

更稳的做法，是把会话做成只追加（append-only）的事件流：请求、模型输出、工具调用、门禁决策、压缩点、人工审批，一律按时间追加写入。当前视图可以从日志重建，但历史不应被就地改写。dsh 强调 session event / 持久化日志，核心价值就在这里。

一、快照够用吗？不够

快照适合回答「现在怎样」。事件流适合回答「怎么变成这样」。

生产排障通常需要后者：为什么第三次重试换了工具？压缩前后目标是否还在？哪一次 pre-execute 拒绝了部署？如果只有最新状态，这些问题都会变成猜测。

还有一个隐蔽风险：可变状态会鼓励「先改再说」。出了问题，现场已被后续步骤污染。只追加日志保留了当时的证据链，即使后来状态继续前进，历史仍可复核。

二、事件流里至少该有什么

不必一上来做成完整溯源平台，先保证这几类事件落盘：

• 用户目标与后续修订
• 每轮模型请求的摘要元数据（模型名、token、是否压缩后）
• 工具调用：名称、参数摘要、结果摘要、耗时、成功/失败
• 权限与沙箱决策：允许、拒绝、原因
• 检查点与压缩边界
• 人工介入：批准、驳回、接管

注意是「摘要 + 可定位引用」，不是把所有大文件内容反复塞进日志。大产物放对象存储，日志里留哈希和路径即可。

三、只追加带来的三个工程收益

可回放：按事件重建任一时刻的上下文视图，定位漂移发生在哪一步。

可审计：谁在何时授权了副作用，事后能证明，而不是口头回忆。

可分叉：从某个边界 fork 出新会话做对照实验，而不污染原轨迹。这对评测和事故复盘都很值钱。

代价是存储与治理。日志会增长，所以要有保留策略、脱敏规则、以及「热日志 / 冷归档」分层。但这些成本，通常低于「出事了却没有证据」。

四、和记忆、压缩怎么分工

事件流不是长期记忆，也不是给模型看的全部上下文。

• 事件流：系统真相，服务于人、审计、回放
• 热上下文：当前决策所需的最小信息
• 外置记忆：跨会话仍有用的结构化事实

压缩可以改写热上下文，不应默默改写事件流。否则你就失去了判断压缩是否伤及目标与禁止事项的基准线。

一个常见误区是把「对话摘要」当成事件流。摘要会丢细节，也带模型偏见；事件流应尽量记录发生过的动作与决策，而不是事后叙述。

五、落地时的最小闭环

1. 先把工具调用和权限决策写成事件
2. 每次压缩前后各打一个边界事件
3. 提供「导出某会话事件 JSONL」的能力
4. 事故复盘强制基于事件流，而不是聊天截图

如果连这四步都做不到，所谓可观测性多半只是打了几行 info 日志。

也可以加一条团队约定：没有事件 ID 的线上结论，不算正式复盘结论。这会倒逼链路真正把关键动作记全。

结语

Harness 要让 Agent 可运营，先得让它的行为可叙述。只追加的会话事件流，是把「模型当时怎么想的」从玄学变成工程对象的基础件。状态可以重建，历史不应被覆盖——这条原则一旦立住，超时熔断、权限门禁、会话压缩才有统一的排障抓手。