恢复对象不只有历史消息#

一次会话恢复至少涉及三类状态：

三者需要共同恢复，却不适合强行写入同一对象。Agent 定义变化较少，AgentState 随 Reply 更新，Workspace 又有独立的存储与回收周期。

因此，“支持 Session 持久化”不能只看是否保存 Message。真正需要验证的是：新的副本能否从外部存储重新得到一致的 Agent、State 与 Workspace。

唤醒信号不是状态来源#

服务端会话可能因为新消息、外部任务完成或子 Agent 上报而重新运行。AgentScope 使用共享队列与信号通知副本，再由调度器尝试启动对应 Session。

这里最重要的边界是：

队列负责通知“需要检查”，持久化状态负责说明“现在应该做什么”。

如果唤醒消息本身携带唯一状态，一旦重复、乱序或丢失，Session 就无法可靠恢复。更稳妥的方式是让消息只提供 Session ID，消费者重新读取 Inbox、AgentState 和 Action 状态。

会话锁也只解决当前哪个副本可以运行。它不能替代持久化状态，更不能说明恢复时应该传入普通消息、确认结果还是外部执行结果。

恢复输入必须保留语义#

“继续执行”并不是一种统一动作。

如果恢复层只保存一段文本，Agent Loop 无法区分“用户说了 yes”和“这是对上一项操作的正式确认”。因此 Checkpoint 除了位置，还要保留中断原因和稳定 Action 身份。

多 Agent 也遵守同一原则。子 Agent 可以被建模为独立 Session：执行期间 Leader 不必持续占用线程；Worker 上报进入持久化 Inbox 后，再唤醒 Leader 重新运行。

这使多副本成为可能，但代价是队列、状态、锁和工作区必须采用一致的 Session 身份。

设计判断：Session 应当可以重新组装#

我会把服务端 Session 设计成“可重新组装的运行”，而不是“长期存活的进程对象”：

1
触发到达
2
  → 获取 Session 执行权
3
  → 读取定义、状态与 Workspace
4
  → 执行一次 Reply
5
  → 保存状态并释放执行权

这套结构适合进程重启、跨副本路由和长时间等待。若服务始终是单进程、短任务且失败后允许从头重试，进程内对象可以更简单；一旦需要跨副本续跑，下面这些条件仍然不能由“存在持久化接口”自动证明：

• 旧持有者恢复后的写入一定会被拒绝；
• 外部 Tool 副作用具有幂等或 Reconcile；
• Action 在跨进程 HITL 中具有稳定身份；
• Workspace 与 AgentState 的更新能够原子一致。

因此，源码中出现共享锁和持久化接口，只能证明恢复控制点存在。生产可靠性还需要故障注入验证。

1
agent_state = session_record.state
2
agent_state.session_id = session_id
3

4
agent = self._agent_cls(
5
    name=agent_record.data.name,
6
    # model, formatter, toolkit ...
7
)

1
SET key <random-token> NX EX <ttl>
2
heartbeat: renew every ttl / 2
3
release: delete only when token matches

1
Msg
2
| list[Msg]
3
| UserConfirmResultEvent
4
| UserInterruptEvent
5
| ExternalExecutionResultEvent
6
| None

参考资料#

• AgentScope GitHub
• AgentScope：State / Session Management