当几个智能体共同分析资料时，错误通常还停留在文本里；当它们开始预留库存、创建运单或发送通知，错误就可能改变外部世界。一次超时并不证明操作没有发生，一段“任务完成”的总结也不证明业务状态正确。可靠执行需要把模型的判断放入明确的状态与权限边界，并为每个有副作用的操作设计恢复路径。以下以备件补发为假设场景，讨论通用的执行架构与恢复设计。
先把任务表示成可以核验的状态
设想一个备件补发流程：资料智能体核对保修凭证，库存智能体查询可用数量，执行智能体预留备件并创建运单，另一个智能体准备通知。业务完成条件不是这些角色都说“完成”，而是同一补发申请关联了一次有效预留、一张符合条件的运单，以及可核对的处理记录。角色分工可以变化，完成条件必须稳定。
任务状态应区分计划已生成、校验通过、等待执行、结果未知、已确认成功与需要人工处理。特别要保留“结果未知”：如果创建运单请求发出后连接中断，把它直接写成失败并重试，可能产生第二张运单；把它当作成功继续通知，也可能发送不存在的物流信息。未知是需要查证的业务状态，而不是可以省略的异常细节。
每个状态转换都应由可验证条件触发。例如，只有收到承运服务的运单标识并通过查询确认，才能进入已创建状态；智能体的自然语言总结只能解释该状态，不能自行改变它。这样，人工接手时看到的是尚待解决的具体事实，而不是一段需要重新阅读和猜测的对话历史。
工具契约要同时描述结构与业务含义
JSON Schema 可以约束必填字段、数据类型、枚举值及额外字段，是工具输入的基础检查。一个预留工具可要求申请编号、仓库编号、物料编号和正整数数量，并明确拒绝未声明参数。但结构合法不代表操作合理：申请是否属于当前租户、保修是否有效、数量是否超过核准额度，都需要工具服务端根据可信数据验证。
工具契约还应声明它是读取还是写入、需要什么权限、使用哪个对象版本作为前置条件、成功会产生什么记录，以及如何查询执行结果。例如，预留库存时传入已读取的申请修订号；若申请数量已被人工修改，服务端应返回冲突，让流程重新计算。否则，一个参数完全合规的调用仍可能执行过时决定。
输出也要结构化区分已确认成功、确定拒绝、可重试故障和结果未知，并携带业务记录标识与错误类别。凭据由受控执行层注入，不能交给模型在工具参数中选择更高权限账户。来自网页、附件或其他智能体的指令都只是待验证输入；它们不会因为进入了工具调用，就获得修改租户、扩大额度或跳过前置条件的权力。
并行工作需要明确的写入归属
多智能体适合并行完成相互独立的读取与分析，例如核对凭证、查库存和准备通知草稿。依赖关系则应写成任务图：运单地址校验依赖已确认的收件信息，创建运单依赖库存预留成功，正式通知依赖运单状态确认。把这些依赖仅写在提示词里，无法阻止两个执行者因不同理解而提前提交。
为每个业务对象安排明确的写入责任，并让共享状态更新经过版本校验。两个智能体同时基于申请第三版提出不同数量，系统应发现冲突，而不是按最后写入覆盖。可并行结果也需要附带来源版本与完成时间；稍晚返回的库存分析不能覆盖已经取消的申请，更不能把取消状态重新改回待执行。
调度器还要处理工作者失联与任务重新分配。租约可以限制一个执行者持有任务的时间，但到期后的旧执行者仍可能继续运行；因此，关键写入端需要检查递增的执行代次或同类有效性标记，拒绝过期执行者提交。并行度、工具调用量和总执行时限也应设上限，避免智能体相互追问或重复规划不断消耗资源。
幂等标识表达的是同一次业务意图
AWS Builders’ Library 的幂等接口文章讨论了由调用方提供请求标识的设计。对于补发申请，可以在调度层生成稳定的操作标识，并在网络重试、进程重启和执行者更换时保持不变。标识对应“为这份申请执行这次预留”的意图，而不是每次调用的时间戳。若重试时重新生成标识，服务端就无法判断这是同一次操作。
可采用租户、申请、步骤和业务修订的组合作为标识作用域，再记录经过规范化的参数摘要。相同标识携带不同仓库或数量时，应报冲突，不能悄悄复用旧结果。也不能只凭参数相同就去重，因为用户可能合法地提交两次内容相同的补发申请。幂等记录应保留首次结果，重复请求返回可核对的同一业务记录。
真正的保证要由产生副作用的服务执行。在同一数据库内，可以把幂等记录、唯一约束与业务写入放进事务，处理并发请求。若外部承运接口不支持幂等，本地登记“准备调用”无法关闭远端成功后本地崩溃的窗口。还需明确远端去重期限；恢复发生在期限之外时，应先查询既有结果或转交核对，而不是宣称任意时间重试都只执行一次。
检查点记录决策，事务记录已发生的事实
LangGraph 文档把检查点用于保存任务图状态和支持中断后的继续执行；Temporal 文档则强调可重放的工作流逻辑与可能失败的外部活动应分开。无论采用哪个框架，都需要确定恢复时哪些结果应被重用。已经选定的物料、经过校验的地址和模型生成的执行方案应作为版本化决策保存，避免重启后重新推理出另一套参数。
检查点不能自动把远端副作用纳入本地事务。假设运单已经创建，但保存“成功”状态前进程崩溃，恢复程序看到的仍是待执行。可以把操作意图持久化，调用时使用稳定幂等标识，再通过回执或查询确认结果；确认之前保留未知状态。若确需重新规划，必须显式创建新版本，并说明旧操作是否已经生效及如何处理。
对于本地业务更新后需要发送事件的场景，AWS 的事务发件箱模式提供了可借鉴的结构：业务记录与待发送事件在同一数据库事务中提交，再由独立发送者转发。它解决本地写入与事件生成脱节的问题，但发送者仍可能重复投递，消费端需要去重。它也不会把数据库、承运服务和通知系统变成一个全局原子事务。
重试前先判断故障是否允许重复执行
失败分类决定恢复路径。参数错误应修正输入，权限拒绝应停止依赖操作，版本冲突应重新读取当前状态。短暂限流或可确认未执行的服务故障，才适合按策略重试。Temporal 的重试策略文档提供了声明式控制重试的机制；应用仍需选择哪些失败不可重试，并设定最大尝试次数、整体截止时间和退避间隔。
网络超时尤其需要区分读取与写入。对于创建运单这类写入，先根据操作标识或远端回执查询执行状态；查到成功就补记结果，确认未执行且仍满足前置条件时再重试。若远端查询采用最终一致性，暂时“未找到”不一定证明没有创建，需要遵守其一致性说明并设置核对窗口。无法消除不确定性时，应停留在待核对状态。
重试预算需要由整个任务统一管理。工具客户端、任务执行器和上层智能体若各自重试三次，实际调用量可能成倍增加。指定负责重试的层次，并记录每次尝试属于哪个业务操作；退避可以加入随机扰动，减轻同时恢复造成的冲击。达到预算后保留已有成果与未确认步骤，让人工或后续恢复继续处理，而不是从头复制整个流程。
补偿与人工介入都需要具体执行依据
多步骤流程失败后，恢复可能需要继续完成剩余步骤，也可能需要补偿已经发生的操作。预留库存后地址校验失败，可以释放这次预留；运单创建后申请取消，则需要先检查运单是否仍可撤销。补偿必须引用原操作标识，且自身具备幂等能力。释放库存不能简单地把某个总数加回去，否则重复补偿可能制造并不存在的可用量。
补偿通常不等于把历史抹去。已发送的通知不能保证收回，已经交接给承运方的包裹也未必能取消。流程设计时应明确可逆窗口和不可逆边界，把可验证的检查尽量放在不可逆动作之前。无法自动恢复时，交接材料应列出原请求、已确认动作、未知动作、相关回执与建议处理路径，并保留操作者后续决定。
需要人工批准的动作，应把批准绑定到具体对象、参数摘要、权限范围和有效期限。批准后的申请若发生实质修改，原批准不能自动沿用。系统恢复时应重新检查前置条件和批准是否仍有效，但不必把未变化、仍有效的批准全部重复索取。用户需要明确看到将产生的结果，以及该批准允许执行的范围。
用故障注入验证业务不变量
验证可靠性时，可以在请求发出前、远端成功后回执保存前、检查点提交后等边界主动中断执行，再观察恢复结果。还应模拟同一任务被重复投递、两个执行者竞争、人工取消与迟到结果同时到达、凭据失效以及重复补偿。检查重点是业务不变量：一份申请不能多出有效运单，预留量不能失真，未经授权的操作不能发生。
指标需要反映真实后果。任务完成率应以外部业务状态核对为准；重复副作用率应明确统计的是逻辑操作还是尝试次数。同时跟踪未知状态的数量与停留时长、需要人工恢复的比例、恢复耗时、额外调用成本，以及补偿是否成功。模型判断“工具使用正确”可以作为辅助信号，但不能替代对库存、运单和通知记录的实际检查。
执行记录至少要关联任务、步骤、业务操作、调用尝试与远端回执，并记录采用的契约版本和决策版本。用户界面则把这些证据转换成清楚的进度，例如“库存已预留，运单状态待确认”，避免把内部异常直接丢给用户。增加智能体数量之前，先证明现有流程在重复、超时与重启条件下仍能保持这些约束，才有基础扩大自动化范围。