任务状态、业务状态与检查点
一句话收获：恢复任务前先确认现实，而不是继续旧对话。
这个场景在解决什么问题
这个场景讲的是三种"状态"怎么区分，以及"检查点"（Checkpoint）怎么让任务可恢复。目标（goal）是实现模型外的状态，以及可验证的检查点。观察点（observation）是：同一个任务，同时显示"本地进度"（任务状态）和"外部权威对象"（业务状态）两套信息。
为什么值得单独学？因为很多人把"任务跑到哪了"和"现实世界到底变成什么样了"混成一团，结果恢复任务时继续拿着旧对话当现实。这个场景告诉你：任务状态是"我以为我跑到哪"，业务状态是"现实是什么"，两者必须分开；恢复前先看现实，而不是续旧对话。
先理清这条判断链（文字版）
这个场景的四步讲的是从"两种状态"到"可恢复的检查点"，本质是"任务状态 → 业务状态 → 可信检查点 → 状态一致性"：
- 先记录任务状态——当前阶段、等待主体、预算、失败、未决事项，回答"我跑到哪了"。
- 再从外部系统读业务状态——对象、版本、当前状态，回答"现实是什么"。
- 然后保存可信检查点——目标、阶段、已执行动作、回执、未决项、恢复条件。
- 最后做状态一致性判断——检查点和业务状态一致就继续，不一致就重新判断。
这条链的核心逻辑是：任务状态归 Runtime 管，业务状态以外部系统为准，检查点是两者的"存档"，恢复时要服从当前现实。
逐层详解
第 1 步：任务状态
原文：记录当前阶段、等待主体、预算、失败和未决事项。
白话：任务状态记录的是"这个任务现在跑到哪了"——当前在什么阶段、在等谁（等待主体）、还剩多少预算、有没有失败、还有哪些没解决的事项。
类比：像项目进度看板上的那张卡片——"第 3 阶段、等前端确认、还剩 2 天、上次部署失败、有 3 个待办"。
举例：一个退款任务的任务状态是：阶段 = "等待退款回执"、等待主体 = "支付渠道"、预算 = "还剩 5 轮"、失败 = "无"、未决事项 = "1 个（确认退款到账）"。
为什么重要：任务状态回答运行到哪里。也就是说，任务状态的作用是回答"运行到哪一步了"，它是"进度"层面的信息。
怎么验证（证据点）：
- 阶段明确：当前阶段清晰。
- 等待主体：知道在等谁。
- 剩余动作：还剩多少动作/预算明确。
别踩的坑（边界）：任务显示运行中不证明业务对象未创建。意思是，任务状态显示"还在运行中"，不代表外部业务对象还没被创建——它可能已经创建了，只是任务还没收到回执。
落地检查：任务状态属于 Runtime。也就是说，落地时任务状态应该由 Runtime（运行时）来维护，而不是由模型或聊天记录来"记录"。
第 2 步：业务状态
原文：从外部系统读取对象、版本和当前状态。
白话：业务状态是从外部系统（数据库、第三方平台等）读来的真实情况——对象是什么、版本是多少、当前状态是什么。它回答"现实到底是什么"。
类比：像查银行余额——你以为卡里还有钱（任务状态），但真实余额（业务状态）要以银行系统查出来的为准。
举例：退款任务里，业务状态要从支付渠道系统读：对象 = "订单 123"、版本 = "v7"、当前状态 = "已退款"。这才是事实，而不是任务自己以为的进度。
为什么重要：业务状态回答现实是什么。也就是说，业务状态是"现实"的权威答案，和"我以为"是两码事。
怎么验证（证据点）：
- 对象唯一：业务对象能唯一确定。
- 版本当前：读到的版本是最新的。
- 权威来源：信息来自权威系统。
别踩的坑（边界）：聊天记录不能覆盖业务状态。意思是，聊天记录里写的"应该已经退了吧"不能盖过外部系统里查到的真实状态。
落地检查：业务系统是事实源。也就是说，落地时要把业务系统当成唯一的事实来源（source of truth），其他都只是参考。
第 3 步：可信检查点
原文：保存目标、阶段、已执行动作、回执、未决项和恢复条件。
白话：检查点（Checkpoint）是一份"存档"，保存六样东西：目标、阶段、已经执行过的动作、这些动作的回执、未决项、以及恢复条件。这样进程中断后，能靠它重建任务。
类比：像游戏存档——记录你打到第几关、装备是什么、任务进度、还能怎么继续，下次读档接着玩。
举例：退款任务的检查点存了：目标 = "订单 123 退款"、阶段 = "已发起、等回执"、已执行动作 = "调用了 refund"、回执 = "超时未回"、未决项 = "确认到账"、恢复条件 = "退款状态可查询"。
为什么重要：检查点让进程中断后可重建任务。也就是说，检查点的意义是让"进程死了之后"还能把任务原样重建出来。
怎么验证（证据点）：
- 回执可查：已执行动作的回执能查到。
- 依赖版本：依赖的版本被记录。
- 恢复条件：恢复条件明确。
别踩的坑（边界）：模型摘要不能单独成为检查点。意思是，模型自己生成的一段"总结"，不能单独当作检查点——检查点里的关键项必须是程序能验证的。
落地检查：关键项需要程序验证。也就是说，落地时检查点里的关键信息要能被程序验证，而不是只靠模型口头总结。
第 4 步：状态一致性
原文：检查点与业务状态一致时继续，不一致时重新判断。
白话：恢复任务时，先拿检查点去和当前的业务状态对一下：一致（检查点说的和现实一样）就继续；不一致（现实已经变了）就重新判断，而不是硬按旧检查点往下跑。
类比：像隔了一周再回到装修现场——先核对"图纸上的进度"和"现场实际进度"对不对得上，对得上就接着干，对不上就得重新评估。
举例：恢复退款任务时，检查点说"已发起退款、等回执"，但查业务状态发现"订单已经被退款了"，两者不一致，就不能再按"等回执"继续，而要重新判断下一步。
为什么重要：恢复要服从当前现实。也就是说，恢复不是"机械续上旧进度"，而是"先看现实、再决定怎么走"。
怎么验证（证据点）：
- 版本一致：检查点版本和业务版本一致。
- 权限仍有效：执行权限仍然有效。
- 动作仍需要：原来的动作现在仍然有必要做。
别踩的坑（边界）：读取到检查点不代表可以机械续跑。意思是，找到检查点文件，不等于就能无脑接着跑——还要先核实现实。
落地检查：恢复的是业务意图和证据。也就是说，落地时恢复的应该是"业务意图 + 证据"，而不是"照抄旧对话继续聊天"。
落地可行性小结
本场景涉及的技术栈和落地要点：任务状态（Runtime 维护）、业务状态（外部系统为准）、检查点 Checkpoint、状态一致性、事实源（source of truth）。
真实落地时要注意：任务状态和业务状态要物理分开存放、分开读取，不能混在一个字段里；检查点要包含目标/阶段/已执行动作/回执/未决项/恢复条件六要素，且关键项可被程序验证；恢复前必须做"检查点 vs 业务状态"的一致性比对。常见坑是：用聊天记录当业务状态的事实源；以及恢复时直接机械续跑，不先核对现实是否已经变化。
回顾
- 任务状态回答"我跑到哪"，业务状态回答"现实是什么"，两者必须分开。
- 任务状态归 Runtime 管，业务状态以外部系统为事实源。
- 检查点是可验证的"存档"，模型摘要不能单独当检查点。
- 检查点要含目标/阶段/动作/回执/未决项/恢复条件六要素。
- 恢复前先确认现实（一致性比对），而不是继续旧对话。