设想一个商品调价场景。
运营人员请 AI 助手把一款商品的售价从 129 元调整到 119 元。助手核对商品和门店，提交了一张审批单。负责人看过具体内容，点击“批准”，页面随即变绿。
十分钟后，运营人员打开商品页，价格仍然是 129 元。回到助手的对话，最后一条消息还是“等待审批”。
“我已经批准了，为什么还没改？”
助手如果只看聊天，很可能回答：“请再确认一次。”负责人又点了一次。有人刷新页面，有人重新发起任务，还有人准备直接进后台手动修改。
一次本应减少操作的自动化，把几个人又拉回了同一项工作。
但商品没变化，还不足以说明批准丢了。决定可能已经保存，只是原任务没得到续办；任务可能已接回，但仍被暂停；也可能已经请求业务系统，却被当前权限或商品状态挡住。
人的决定、决定被保存、原工作继续，以及业务动作完成，都需要各自的依据。 把它们压成一个“已批准”，异常发生以后就很难知道该修哪里。
批准的内容，需要能带回原来的工作
先看这位负责人到底批准了什么。
是某个门店的指定商品，从 129 元改到 119 元；还是允许 AI 自行调整所有相似商品？是立即生效，还是下周活动开始时生效？使用哪个业务身份，目标又是哪套商品系统？
这些区别不能只留在聊天里。审批记录需要关联原来的工作和具体操作，保存人实际看过、同意过的内容。后台接手续办时，才能把这个决定带回正确的位置。
不然，聊天中同样一句“改成 119”，可能对应不同门店，也可能对应两项相似但独立的工作。按最新消息去拼参数，或从几张已批准的单子里挑一张，都可能把人的同意用错地方。
用户无需记住任务编号，应用却应保留这层关系。负责人在手机上批准，运营人员在电脑上继续，系统仍应找到同一份决定和同一项原工作。
这也是为什么“让用户再说一遍”不能成为通用恢复方案。人重新表达目标时，可能省略了此前条件，也可能顺手改了生效时间。应用如果把这句话当成全新任务，原审批和新操作之间的关系反而更难核对。
遇到卡住的任务，先找回已保存的原决定及其范围。原内容确实没变，就处理续办问题；新的要求改变了批准内容，则把变化清楚交给有权决定的人。
审批可以让人控制重要动作。要让这份控制在故障后仍然有效，就得保存人批准的具体对象和条件，而不只是一个绿色状态。
保存批准以后，还有一段衔接可能断开
假设系统采用一个看起来很直观的流程：先保存批准，再通知任务执行器继续。
正常情况下，两步很快完成。可如果批准已经写入，通知尚未发出时进程退出，就会留下一个尴尬状态：查审批，它已经通过；查原任务，它仍然在等待。
页面可以一直显示绿色，后台也没有新的错误请求。只看成功率或接口是否在线，很容易漏掉这项没有继续的工作。
AWS 对事务性发件箱的说明讨论了这类双写缺口：保存数据与发送通知可能只有一项成功。一个可行思路是在同一事务中保存数据和待发记录，随后再由处理器推进；消息仍可能重复，接收方还需要相应保护。AWS 官方说明
放回调价场景，批准保存以后，“还有哪项原工作需要继续”也应成为可查的记录。即使当时的处理进程退出，后续接手者仍能知道这段责任尚未完成。
具体系统可以选择适合自己的实现。需要达到的目标很明确：临时衔接失败以后，原决定仍有去处，待办仍有负责人，也有后续推进和故障告警；不能让它只存在于某个已经退出的进程里。
产品提示也应跟上真实状态。“批准已记录，续办待处理”比笼统的“操作失败，请重试”准确。前者告诉负责人，他刚才的决定有效保存了，系统还欠下一步；后者容易使人反复点击，甚至重新建单。
反过来，如果决定根本没有保存，也不能因为按钮曾经变绿，就向用户保证批准已完成。界面反馈需要依据持久记录，才能经得起刷新和换设备。
修复卡点，应接回原工作的下一步
知道有待续办记录以后，恢复仍需谨慎。
执行器没有接到原任务，可以继续推进原任务；如果任务已经接到，只是确认没有回来，就需要核对原来的接收记录。每次恢复都生成新任务，会让同一份批准有机会开启多次执行。
哪怕这次只是把价格设为 119 元，重复动作也可能触发商品变更通知、搜索更新或外部渠道同步。不能因为最后价格相同，就认为重复执行没有代价。
接收原工作和标记这份决定已经被接续，需要有明确的一致性关系。后续再收到同一决定，系统才能识别它是在补一段尚未完成的衔接，还是已经被处理过的重复通知。
BailingHub Core 0.9.2 的公开可靠性文档给出了一个具体例子：决定已保存而补续失败时，接口返回 503，同时标明 decision_recorded=true 和 continuation_pending=true，支持使用原决策标识补续。其既有队列路径把原任务入队与决策标记一起保存，避免确认丢失后因同一决定再入队。Core 0.9.2 可靠性说明
这套机制以配套迁移和仓储接入就绪为前提。已经消费的审批，以及没有新补续记录的历史决定，也不会被自动回填或重排。
因此，接入方只按“遇到 503 就从头重试”的通用策略处理，会漏掉重要信息。需要先读清决定是否保存、续办是否待处理，再按接口约定恢复。错误码和业务状态应当一起理解。
这种去重也有范围。避免同一决定重复入队，没有替下游商品系统保证所有业务效果只发生一次。业务接口仍要落实自己的重复操作保护和最终授权。
拒绝决定则应沿着另一条路径处理：保存拒绝及其依据，结束不被允许的动作。不能因为后台正在补续，就把所有审批记录都当成需要执行的任务。
谁接着做，要在接入时说清楚
接回原任务以后，谁负责推进它？
这个问题在接入 AI 时经常被略过。审批页属于中枢，聊天框在客户端，工具又连着业务后台。每一层都觉得自己已经完成了负责的部分，用户却仍在等待结果。
有的路径把工作交给服务端队列，批准后由既有执行机制接回原任务。另一些路径由本地 Agent 调用工具，审批决定需要回到原客户端，再由它继续工作。
这两种路径应按各自契约接续。Core 的 Agent 直调模式仍由原本地 Agent 使用原调用标识显式续执行，批准不会自动启动中枢里的模型循环。客户端已经关闭或暂时离线，就需要准确显示当前等待的责任方。
这不要求负责人再批准一次。已经保存的决定可以等待原客户端接回；真正缺的是负责继续的应用及其执行条件。
相邻框架也体现了这种责任。LangGraph 的官方中断文档要求用原 thread_id 和显式 resume 继续保存的检查点；恢复会从中断所在节点的开头重新执行，节点内 interrupt 之前的代码会再次运行。选用这类机制时，需要检查恢复点和副作用的位置。LangGraph 官方中断文档
对接企业系统时，开发者应说明：决定向哪里保存，哪一方得知它，哪一方重新执行原步骤，以及那一方不在线时如何接手。产品人员则需要让用户看得见这些衔接，而不必理解全部技术细节。
例如，页面可以显示“审批已通过，等待原客户端继续”，或“原任务已接回，等待执行”。它们都比一直停留在“等待审批”更能帮助人安排下一步。
保留聊天可以帮助接手者理解背景，可靠的续办则需要把决定、原工作和执行方连起来。采用本地 Agent 接入时，模型网关负责模型接入、计量与异步结算；模型循环、工作编排和长期记忆仍由客户端承担。
有效批准，还要经过当前业务条件
任务终于继续，并不等于商品一定能完成调价。
负责人批准时，运营人员可能有这家门店的调价权限。续办时，该权限已经被撤销；或者商品被另一位管理员下架，活动价格也已由别的流程调整。
原决定说明当时允许什么，业务系统还需要判断当前是否可以执行。批准不能替代真实业务身份、当前权限和商品状态，也不能允许应用遇到阻挡时偷偷换成管理员凭据。
同时，不必把每一次临时故障都升级成人的重新审批。原对象和参数没有变化、授权仍有效、业务条件也满足时，可以按既有约定继续。发生实质变化，再说明具体差异，交给有权决定的人。
例如，商品仍是 129 元，原调价条件也有效，可以继续原动作。若商品已被人工改为 109 元，就需要按业务接口的条件和原任务意图处理，避免把新的人工决定覆盖掉。
如果原任务已经暂停，审批通过也不应绕过暂停。如果原调用结果仍不确定，则先核对那次动作的证据，不能把新收到的批准当成它此前从未执行过的证明。
最后的完成反馈也要落到具体结果。任务入队，说明工作被接回；接口受理，说明业务系统接到了请求。商品详情确认新价格，才支持对应范围内的调价结果。涉及外部渠道同步，还要按原约定核对那些渠道，不能提前一起宣布完成。
用户真正需要的是准确的进度和能继续处理的路径。卡在权限，就找有权接手的人；卡在商品状态，就展示变化；卡在客户端离线，就等正确执行方恢复。原因说清楚，人工介入也能更快落到具体位置。
验收时，可以故意让批准后的衔接断一次
企业评估 AI 助手，经常能看到很流畅的审批演示：发起任务、负责人同意、助手执行、页面报告成功。
这条顺利路径有必要验证，故障后的接续同样值得验收。否则，一次成功演示掩盖的问题，会在网络波动、电脑休眠或服务重启时落到业务人员身上。
可以在隔离环境里设置几个断点：决定保存后暂时无法入队，任务接收成功却丢失确认，负责处理的进程退出，以及同一决定被重复提交。还可以加入拒绝、原任务暂停、客户端离线和业务权限变化的情形。
观察原决定是否保留，续办是否仍可查，恢复有没有沿用原工作，已接续的决定会不会再次生成执行。再检查页面是否准确表达当前进度，负责人与运营人员能否看懂哪里需要接手。
这些是建议验收的故障条件，具体测试结论应记录实际版本、配置和覆盖范围。Core 的公开专项测试可以帮助理解给定条件下的机制；它们不能替真实业务接口完成最终验收。
还可以换一个更贴近日常工作的问题：同一项调价，负责人到底需要批准几次？运营人员需要重复描述几次？系统中断以后，接手者要花多久才知道原工作走到了哪里？
这些重复注意力也是自动化成本。应用能保存有效决定、接回原工作，并把当前阻挡说清楚，审批才会成为一个有意义的控制点，而不是故障后的反复点击。
这也是我们讨论 Agent-to-Business 时关注的衔接。ACC 是独立的能力治理声明契约；Core 提供其公开接入、治理与补续机制；客户端编排工作，业务系统负责真实执行和最终判断。Core 能力与公开证据边界
回到开篇那句话：“我已经批准了，AI为什么还停在那里？”
系统应当能找到原决定，指出原工作停在哪一步，并让正确的一方接回它。让有效批准在中断以后仍然有去处，人的一次认真判断，才不会被后续故障白白消耗。
