主题
Chat ownership、心跳与恢复方案
1. 方案摘要
本方案用 owner replica id、token 和 epoch 构成 Chat 写入保护，用副本 heartbeat 与 monitor 识别失联，再通过 fencing、恢复记录和单条 CAS 完成接管。目标是让旧 Runtime 即使延迟返回，也不能覆盖新 owner 的会话状态。
2. 设计目标与非目标
设计目标
- 防止同一 Chat 被多个 Runtime 同时写入。
- 区分正常关停、异常失联和用户主动拒绝。
- 让恢复过程可重试、可观测，并保持消息语义连续。
非目标
- 不保证进程级内存任务在硬件故障后原地继续。
- 不把 sticky routing 当成一致性保证。
- 不新增用户消息来掩盖一次执行中断。
3. 架构范围与视图
Runtime 如何取得 Chat 所有权、保护写入，并在正常重启或副本失联后安全收口和恢复？
本图描述当前 ownership fence、replica heartbeat、失联扫描和恢复 CAS，不把历史 sticky-only 方案作为现状。
图中绿色实线表示当前能力，紫色虚线表示规划或待完善能力。图片用于建立空间关系，本文正文定义方案语义、边界和落地规则。
4. 组件与责任边界
| 组件 | 责任 |
|---|---|
| Ownership claim | 任务启动前 CAS 写入 replica id、token 和递增 epoch。 |
| Ownership guard | session id、终态、归档等写入必须携带本轮 guard。 |
| Heartbeat | Runtime 或组合角色登记副本并更新心跳、任务数和状态。 |
| Replica monitor | Gateway 或组合角色通过独立 leader domain 扫描 suspect 与 expired 副本。 |
| Self-fence | Runtime 发现自身记录失效时进入维护、取消任务并退出。 |
| 正常重启恢复 | 暂停任务、flush、归档、写恢复记录，静默窗口后再派发。 |
| 恢复 claim | Runtime 用 recovery id、token、checkpoint epoch 和 Chat 条件执行单条 CAS。 |
| 恢复语义 | 仅关停直接打断的最后一个未完成工具调用可视为技术性中断；恢复 Agent 续写原 assistant 消息。 |
组件之间只通过明确的输入、输出和生命周期契约协作。上层可以编排下层能力，但不能绕过下层的权限、租户和状态边界直接读写内部对象。
5. 核心设计决策
- Claim 使用 CAS 写入 replica id、token 和递增 epoch。
- 所有关键写入携带完整 ownership guard，旧 epoch/token 自动失效。
- 失联先 suspect，再 CAS expired 和收口 running Chat，最后经过静默窗口恢复。
这些决策共同保证：入口可以替换、执行可以迁移、状态可以恢复，而不会改变用户可见的任务和会话语义。
6. 关键流程与时序
主流程
- Runtime claim Chat owner
- 运行中持续 guarded writes 与 heartbeat
- 正常关停则暂停、归档并创建恢复记录
- 异常失联则 monitor 先 suspect 后 CAS expired
- 匹配旧 guard 的 running Chat 才能失败收口
- Gateway 领取恢复记录并按稳定路由键派发
- 新 Runtime 单条 CAS 取得新 owner 并恢复
流程解释
流程中的每一步都应产生可追踪的上下文：租户、Agent、Chat、Task、运行副本和结果引用。过程事件用于向用户反馈进度，终态写入和结果归档必须在事实源更新后再对外确认。
7. 数据、一致性与状态管理
- 共享数据库是 Chat、Replica 和 Recovery 的事实源。
- 恢复记录使用租约、退避和稳定 route key，避免多个副本重复接管。
- 恢复 Agent 续写原 assistant 消息，不新增用户消息。
当前专题的关键约束
- expired 副本不能复活。
- 旧 Runtime 回调只能发布事件，不能覆盖新 owner 状态。
- 更早的用户拒绝、权限或运行策略拒绝仍然有效。
- 恢复过程续写原 assistant 消息，不新增用户消息。
- 公共副本库与租户 Chat 库之间不依赖跨库事务。
8. 异常、恢复与安全边界
- Runtime 发现自身记录失效时 self-fence，进入维护、取消任务并退出。
- expired 副本不能复活，旧回调只能发布事件不能覆盖状态。
- 关停直接打断的最后一个未完成工具调用可视为技术性中断；更早的用户拒绝、权限或运行策略拒绝仍有效。
异常处理遵循“先阻止错误扩散，再保留可恢复状态，最后由明确的补偿动作完成收口”。任何重试都必须具备幂等条件，任何恢复都必须重新校验租户、权限、版本和 ownership。
9. 部署与扩展边界
- Gateway 或组合角色承担 monitor leader，Runtime 负责 heartbeat 和执行。
- 恢复接口必须具备内部鉴权、route key 和单条 CAS 条件。
部署形态可以变化，但不能把本地内存、临时文件或单副本事件队列当作跨副本事实源。需要横向扩展的能力应先明确共享状态、路由键、健康状态和故障补偿方式。
10. 当前能力与演进计划
当前已落地
- Chat ownership fence
- Runtime heartbeat / monitor / self-fence
- 正常重启的恢复记录、租约与退避
规划或待完善
- 跨副本实时事件适配与完整故障演练
演进方向
- 补齐跨副本实时事件适配、故障演练和恢复指标。
- 增加恢复积压、接管耗时、CAS 冲突和 self-fence 监控。
11. 方案验收要点
- 旧 owner 延迟写入不会改变新 owner 状态。
- 正常关停可以生成恢复记录并在静默窗口后恢复。
- 异常恢复不新增用户消息，原 assistant 消息可以继续生成。
验收时应同时检查正常链路、重复操作、空态或拒绝态、依赖不可用和副本切换，不能只验证图中最短路径。