事件日志

记录意图、执行、结果与验证状态的有序事件历史。

事件日志记录系统观察到的意图、执行与结果，不能把所有payload都当成已验证事实。模型说“邮件已发送”、工具返回“请求已受理”、外部系统出现投递回执，是不同事件。记录这种差别，才能回放状态并解释任务为何被判成功或结果未知。

OpenCode固定研发源码把Session、顺序消息、pending和inbox拆成不同表，使用唯一顺序索引。DeepSeek Harness公开loop从session日志派生下一请求。实现方式可以不同，但都提醒持久历史需要稳定身份、顺序和可解释边界，而不是一个不断覆盖的聊天字符串。

业务事件建议包括event_id、序号、actor、父事件、Task/Run引用、操作ID、时间、schema版本和payload引用。工具意图先写入，再发生副作用；成功与失败回执随后追加。摘要是projection，状态可从已提交事件重建。不能只保存流式token而没有最终tool状态，也不能让客户端将临时文字直接写成task.completed。

不可变追加不等于永远保留所有敏感内容。payload可独立加密和按策略删除，日志保留最小必要的删除证明；访问调试内容也要权限与审计。保留期与采样影响可回放范围，应公开为运维合同。测试检查重复事件去重、乱序回调、schema升级和payload删除后状态解释，尤其避免流式快照导致无界存储放大。

一个最小事件链可以是操作请求、授权通过、外部提交、回执确认、后置验证。它们必须允许中间停在unknown，而非强迫每条请求立即出现成功或失败。回放器只依据明确事件转换状态，不从自然语言“应该已经完成”推断事实；这也使事件schema升级更容易审查。

事件时间也应区分发生、接收和提交，延迟回调不能以到达顺序改写事实先后。跨服务可用相关ID串联，不必把所有敏感原文复制到一个全局日志。

实践重点：区分模型声明、工具回执和验证结论；敏感payload独立保留。

验证抓手：按序回放可重建状态；删除payload后保留最小必要证明。

常见误区：日志里出现成功文字就视为真实外部效果。

OpenCode：session_v2与消息表源码；DeepSeek Harness：事件日志驱动循环。