可恢复执行的状态边界

01从任务边界定义状态

长任务中的失败可能来自模型、工具、网络或业务数据变化。仅保存一份聊天记录，并不能判断哪些动作已经完成、哪些结果已经过期。执行框架需要区分任务意图、运行状态与产物证据。

Axis 的架构讨论以任务契约为起点：输入引用、允许的工具、完成条件与预算共同构成边界。节点状态至少能够表达待执行、运行中、已完成、等待输入与失败；输出则引用具体产物，避免将一段自然语言总结直接当作成功。

02事件与检查点各自保存什么

事件记录“发生了什么”：某工具被请求、某结果被接收、某版本被验证。检查点保存“此刻可继续的状态”：已完成节点、待处理依赖、输入版本与必要上下文。二者关联后，既能快速恢复，也能回看状态从何而来。

持久工作流系统对事件历史与重放的区分，为这种设计提供了工程参考。Temporal 的官方文档强调重放过程中命令与历史的一致性；这是一种可借鉴的约束，不代表 Axis 使用相同实现，也不构成相同保障的声明。

03重放不等于重做外部动作

恢复计算和重发付款、写入数据、发送通知是不同的问题。一次外部写入可能已经成功，但结果在返回途中丢失。如果只根据超时重试，就可能重复执行。工具契约必须声明动作性质，以及如何查询前一次请求的结果。

可行设计包括请求标识、幂等键、写入前版本校验与结果查询。对于不支持幂等的系统，应先核对外部状态，再决定继续、补偿或等待人工判断。“可恢复”意味着能做出有依据的下一步，不意味着任何动作都能自动回滚。

• 只读计算：在输入版本不变时重算。
• 可幂等写入：使用同一逻辑请求标识核验结果。
• 不可幂等动作：先查询外部事实，再恢复流程。

04并行节点必须有合并条件

多智能体并行处理不同子任务时，结果可能来自不同数据版本。汇合节点需要检查依赖是否完成、输出类型是否一致、引用是否仍然有效。如果两条分支基于不同版本形成矛盾结论，直接拼接文本只会隐藏冲突。

我们把合并看作显式步骤：验证输入版本，检查产物约束，记录冲突，必要时只重跑受影响的分支。执行图还应具备循环上限与终止条件，避免在没有新证据时持续重试。

05用故障注入验证恢复能力

恢复能力应通过可重复的中断场景验证：工具成功后响应丢失、节点执行中断、检查点过旧、外部数据变更、并行分支部分失败。每个场景都要给出允许的最终状态，以及禁止重复发生的副作用。

评估记录应包括恢复位置、额外调用量、是否重复写入、产物版本与最终判定。本说明给出 Axis 相关的研究架构与验证方向；实际保证需要对应实现、测试范围和部署条件共同支撑。