Session、事件与 JSON-RPC：连续性如何变成企业证据

DeepSeek Harness 的 session 以 append-only 事件保存请求、上下文、assistant chunk、message 和 turn/end 等事实。Projection 读取这些事件恢复当前视图。相比只保存最终聊天文本，这让失败、重启和调试都有更清晰的时间线。

然而 session header 并不天然包含完整依赖闭包、effective config、Provider/模型能力、repo mode、权限与 sandbox receipt。同一个 session id 在模型能力改变后可能无法继续；研究中的无密钥恢复就经历了能力不匹配，再通过补齐模型 metadata 才在重启后成功。

所以企业平台要保存 ExecutionSessionRef：它从属于 TaskRun，并把 external session id 与 Runtime artifact、config、model、repo、permission 和 process ownership 绑定。

在已验证的 rc.6 JSON-RPC 实验中，initialize 建立 Runtime，session/prompt 返回 receipt，之后通过 session.event 与 session.status 收到变化，最终 session 日志出现 assistant message 和 turn/end completed。这个链路可以运行，但因果关联并不自动完美。

事件是 Runtime 范围广播，一个进程还可能容纳多个 session；高层 SDK 从 receipt 到 whole-agent idle 的区间推断结果，不能把最后一条 assistant message 天然归因给当前 prompt。因此相关性必须诚实标注为 exact、receipt_interval 或 unattributed。

Lumi 首版最安全的约束，是一个 TaskRun 独占一个进程与一个 session。它牺牲部分资源效率，却大幅简化事件归属、取消范围和故障爆炸半径。等协议真正支持 per-session cancel 和明确 causality，再讨论 multiplex。

当前 JSON-RPC 面缺少可靠的 per-session mid-turn cancel。若一个 TaskRun 独占进程，平台可以通过终止整个进程实现 cancel；但如果 Agent 刚向远端系统提交请求后进程崩溃，平台可能无法知道远端动作究竟成功还是失败。

把这种情况自动标记 failed 并重试，会制造重复发布、重复支付或重复通知。更诚实的状态是 outcome_unknown：停止自动推进，生成可操作的 recovery Attention，让人或专用 verifier 核验外部事实。

这也是为什么协议不仅是一组方法。企业协议还要定义状态机、幂等、重放、超时、证据保留、权限批准和人工接管。技术上“连得通”只是第一步。

最低限度应有 protocol negotiation、Runtime identity、config/closure digest、TaskRun ownership、event cursor、payload class、redaction version、cancel semantics 和 approval capability。Provider 发生时间只能作为参考，平台自己的 append sequence 才是审计排序。

server-to-client approval 如果不受支持，平台不能在运行中假装有人批准。需要交互授权的任务应在 admission 阶段拒绝，或者由 Lumi 先完成人类决策，再把结果作为明确 Grant 交给 Runtime。

用户界面同样属于协议的一部分：Runtime lane 可以显示 starting、running、idle、degraded、outcome_unknown、terminated；Task lane 与 Acceptance lane保持独立。精确命名能减少操作错误。