可靠自动化：状态、幂等、审批、超时与回滚

先看事故：请求超时，系统却把同一篇简报发布了两次

周予经营一项面向 63 名付费客户的行业情报服务。每周一，她从 12 个固定来源整理 9 项变化，生成网站简报，检查 17 个引用链接，再给客户发邮件。最初的自动化只有“定时触发 → 抓取 → 生成 → 发布 → 发信”。前 7 周一切正常，第 8 周却出现了一次“请求结果未知”的事故。

问题不是“超时时间太短”，而是系统把“调用方没收到确认”误写成“外部动作没发生”。网络断开、执行器崩溃、人工双击、定时任务重叠和供应商延迟都可能制造这种不确定状态。

重建后，每期简报先建立持久任务和操作记录；内容管理系统超时后先按业务键查询，不直接重建；内容审批绑定具体草稿；邮件发送另有受众哈希值和第二道审批。48 个故障用例全部收敛后，系统连续运行 30 期：28 期完成，1 期因来源缺失而阻塞，1 期在发信前回退网站并完成补偿；3 次内容管理系统响应丢失和 2 次邮件响应丢失都没有造成重复外部动作。

本文为虚构教学案例。数字用于展示可靠性设计，不代表任何内容管理系统、邮件平台或行业表现；涉及付款、法律承诺、健康、安全、身份和不可逆客户权益时，应由有经验的工程、安全、隐私或法律人员设计与审阅。

先画边界和不变量：状态机要保护业务承诺，不是给流程多加颜色

周予把动作分成读取、内部写入、可撤回外部写入和不可完全撤回动作。来源抓取失败可以重试；保存快照需防重复；网站版本通常可回退；邮件一旦送达不能真正撤回，只能停止后续发送或更正。不同副作用决定不同状态与恢复策略。

不变量先于状态名。若流程可以从“有草稿”直接跳到“发信成功”，无论看板多漂亮都不可靠。状态机的工作是阻止非法承诺，并保存恢复所需证据。

每条不变量都要有破坏测试。临时移除发布守卫，让“等待内容审批”直接提交内容管理系统，I02 测试必须失败；把发送的受众哈希值改一个字符，旧批准必须被拒；在操作表中预先放入第二条相同操作键的记录，唯一约束必须阻断。只在文档里写“不应该重复”，却没有执行层控制，事故发生时仍会失守。

不变量之间也有顺序：I02 和 I03 保护发布发生前与发生中，I06 约束“完成”声明，I08 保护恢复记录。周予把每个外部动作的先决条件、影响和后置条件并排写清：调用前有批准，调用中有操作记录，调用后有远端回执；缺任何一段都不能推进。

每次运行先建立任务、步骤和操作三类持久记录

任务描述整期目标，步骤记录内部阶段，操作专门记录一次可能产生外部副作用的意图。浏览器窗口、聊天记录和平台通知都不能替代这三类持久状态。

任务状态是业务事实来源；步骤日志解释运行细节；操作解决“请求发出后到底发生了什么”。把三者塞进一个最近错误字符串，会丢掉并发、重试与对账所需信息。

这些记录有不同的保留策略。任务、批准、外部操作和补偿证据随客户交付记录保存；体量很大的调试日志按较短周期清理；来源内容按授权处理。如果原文不能长期保留，可在授权范围内保存不可逆哈希值，用来证明当时使用的是哪个版本。运行表不直接复制 9 项事实正文或 63 个邮件地址，避免为了观察系统而扩大敏感数据面。

写状态使用一个命令处理器：读取任务与版本，验证事件在当前状态合法，核对所需回执，在同一本地事务中追加事件并更新状态/版本。若事件保存成功但状态更新失败，事务整体回滚；若外部系统不在同一事务内，则由操作记录跨越这个边界。这样“记录说发布过但任务仍在草稿”可以被对账发现。

状态转换必须列出事件、前置条件、保存证据和非法路径

主路径为 已创建 → 收集 → 起草 → 检查 → 等待内容审批 → 内容已批准 → 发布 → 已发布 → 等待发送审批 → 发送 → 成功。等待重试、已阻塞、补偿和已补偿是分支；状态不是由页面按钮随意覆盖，而由守卫验证后追加事件。

禁止路径包括“等待内容审批 → 已发布”“内容已批准 → 发送”“发布超时 → 已创建”和“已阻塞 → 成功”。恢复不是手工把状态改绿，而是补足证据后触发一条合法事件。

已阻塞也不是终点垃圾桶。记录阻塞原因枚举、人工负责人、所需证据、恢复事件和过期时间：缺来源恢复到收集，权限修复后重新执行原步骤，内容冲突回检查，审批过期则重新收集/检查而不是从已批准继续。不同原因共用一个“重试”按钮会绕过原守卫。

状态图还写终端语义：成功、已补偿和保护性关闭都不可由执行器继续；需要新意图时建立新任务版本并用取代连接。历史任务不改写为“最终成功”，否则无法解释当时是否已对客户产生影响。

用版本号、租约和心跳防止两个执行器同时推进同一任务

第 8 周事故也可能由两个定时器同时领取任务造成。任务行保存状态版本；更新时要求“当前版本必须为 16”，只有一个执行器能将它写成 17，另一个收到冲突后重新读取。领取时还建立短租约，执行器每 30 秒报告一次心跳，租约过期后才能被另一个执行器接管。

租约表示临时执行权，不表示外部动作没有发生。新执行器接管发布状态时，第一步读取操作并查询内容管理系统，而不是因租约换人就重发请求。

隔离令牌随每次租约递增，并传给支持条件写入的内部工具。执行器 01 拿到令牌 7 后暂停，工作节点 02 接管并获得令牌 8；即使执行器 01 稍后恢复，它的内部写入也会因令牌过旧而被拒。无法接收令牌的外部内容管理系统，则依靠操作键、远端查询和本地操作记录保护，不能把租约误当成跨系统锁。

清理程序不会在租约刚过期时同时启动多个接管。它先用原子比较更新把负责人从旧令牌切到新令牌，保存恢复来源和最后一次心跳，再根据任务状态选择恢复入口。起草阶段可以重新生成；发布和发送阶段只能先对账。同样是“执行器失联”，所在状态不同，恢复动作也不同。

幂等键标识业务意图，不是给每次网络请求生成一个新通用唯一标识符

本例的任务键可以读作“周报：2026 年第 30 周：中文”。发布操作还要加入内容哈希值；邮件操作还要加入公开网页地址、受众哈希值和正文哈希值。同一意图的重试必须复用同一个操作键。参数变了却沿用旧键，应返回“意图不一致”；重试时生成新键，服务端就无法知道它们属于同一次业务动作。

RFC 9110 将幂等方法解释为：重复发送相同请求，服务端的预期效果应与只发送一次相同；它也提醒，若无法确认原请求未生效，就不要自动重试非幂等请求。业务接口仍要按自己的意图设计，HTTP 方法名本身不能替代唯一约束、参数比较和结果保存。

键还有作用域与寿命。第 30 周的中文简报与英文简报是两个任务键；同一期重新发布新内容，因为草稿哈希值不同，也构成新的发布意图；但单纯的网络重试必须沿用旧键。外部服务若只保留键 24 小时，48 小时后到达的延迟请求可能不再被去重。因此本地操作记录要长期保存远端编号，超出服务窗口后禁止自动重提。键的过期策略是接口合同的一部分。

同键参数冲突不能“以第一次为准”静默成功。若第一次请求D-8f3c，第二次误带D-91aa，系统返回意图不一致并同时保存两组哈希值供调查；否则调用方可能误以为新内容已发布。随机通用唯一标识符只保证碰撞少，不表达同一次业务意图，重跑时生成新通用唯一标识符反而破坏幂等。

完整走一遍：创建已经成功但响应丢失，怎样收敛到文章 18427

第 30 周的内容 D-8f3c 获批后，系统先把操作状态写为“已准备”，再发送带操作键的创建请求。30 秒后连接断开，操作改为“状态未知”而不是“失败”，任务也停留在发布阶段。恢复执行器按操作键查询内容管理系统，找到文章 18427；确认外部键、草稿哈希值和任务编号一致后，才保存远端编号并探测公开页面。

已准备 → 请求已发送 → 状态未知
  → 按操作键
  → 找到文章 18427
  → 核对意图哈希值 + 内容哈希值
  → 已确认 → 公开页探测 → 已发布

状态未知必须被当成正式状态。只有外部证据，或语义明确的幂等重试，才能消除它；不能靠“通常 30 秒没回就是失败”来猜。

时间线继续到邮件：09:14 的前两次公开探测都读到旧缓存，第 3 次才在 09:14:42 看到文章 18427 和内容 D-8f3c，任务由此进入“已发布”。09:18，周予批准发送；09:19:05，邮件平台接受活动，但响应再次丢失。系统没有新建活动，而是用本地保存的活动创建键查询，并在 09:20:11 找到活动 930。受众哈希值与正文哈希值一致后，才保存远端编号。两次“状态未知”遵循同一原则，但查询字段、等待窗口和完成证据并不相同。

对账回执要保存查询时间、查询参数摘要、返回对象数、选定的远端编号、意图比较结果和操作者。若外部搜索采用最终一致性，第一次“未找到”不能当作“绝对不存在”，还要按照平台已知的可见延迟等待。既没有可靠查询、创建动作又不具备幂等语义的系统，不适合自动重试高影响写入，应停在人工操作。

错误分类先决定动作：瞬态、永久、业务、状态未知和人工不是一回事

同一个 HTTP 500，在只读抓取中可能只是瞬态错误；在创建请求发出后响应丢失时，却代表副作用未知。错误分类必须绑定具体操作，不能只按状态码全局处理。

适配器负责把平台原始错误映射为内部类别，并保存原始代码供审计。例如，内容管理系统返回 409 时，如果同时返回同一外部键对应的对象，它就是待核对候选；如果标识符已被别的任务占用，则属于业务冲突。邮件平台返回 429 时，可以按照响应中的建议等待时间重试；但如果邮件已被接受，只是后续查询遇到 429，发送操作仍然是状态未知，不能重新发信。映射表要按工具版本测试，不能让大模型临场阅读错误文字，再决定高影响动作。

每个类别有负责人：瞬态由执行器，输入由内容负责人，认证由账户负责人，业务由周予，不变量违背由事件负责人。最近错误写错误类别、工具、操作、尝试、原始记录和下一步动作；一句“调用失败，请重试”既无法路由责任，也无法判断能否安全重试。

重试策略要有范围、间隔、抖动、上限和总预算

周予为每个工具分别写策略，而不是统一规定“失败重试 3 次”。来源抓取在 20 秒调用超时后最多尝试 3 次，等待约 30 秒、2 分钟和 10 分钟，并加入小幅随机抖动；遇到 429，优先遵循服务端给出的等待提示。AI 草稿的结构错误只修一次；事实检查失败不靠重新生成碰运气；内容管理系统或邮件处于未知状态时，先查询。

重试层不能叠加失控：开发工具包 3 次 × 应用 3 次 × 工作流 3 次，会把一次业务意图放大成最多 27 次外部调用。配置时要盘点所有重试层，只保留一个可观察的总预算。无限重试既会拖延任务，也可能加重依赖方的故障。

预算按任务累计，而不只按单个步骤。12 个来源若各自重试 3 次，极端情况下会产生 36 次请求，并把任务拖过 10:30。因此，收集阶段设置 15 分钟总截止时间和 3 个并发上限。第一个来源原计划等待 10 分钟，也可能被任务截止时间截断；此时策略返回“预算耗尽”，而不是继续跑完整个重试序列。可靠性设计必须服从业务时效。

抖动用于避免多个运行同刻重试，不代表等待随意。回执保存策略版本、基础延迟、服务器提示、实际延迟和尝试。若7天重试率升至基线2倍，先查依赖和负载，不通过提高最大尝试次数把告警压下去。电路开启时新请求快速失败并进入可见被阻止/重试等待，给下游恢复空间。

超时至少有调用、步骤、任务、租约和审批五种时钟

超时不是远端动作已经取消的证据。客户端停止等待后，内容管理系统或邮件平台可能仍在继续处理；因此，调用超时只改变本地掌握的信息。任务截止时间则代表业务决定：超过 10:30，宁可人工通知或延期，也不能为了“完成自动化”而发送未经核对的内容。

截止日期沿调用链向下传，内部步骤不能各自拿满默认超时。09:58开始公开探测时，距离任务截止日期只剩32分钟；发送复核至少保留10分钟人工窗口，系统可在10:20停止自动路径。审批计时使用可靠服务器时间并记录时区，不能用浏览器本地时钟决定过期。

超时后还要区分“请求取消”和“已经取消”。纯内部渲染可以取消并清理候选项；对外部发布发送取消请求，本身也只是一项新操作，必须查询是否生效。用户点击“取消”表示改变了意图，不代表远端已经恢复原状；界面应分别显示“已请求取消”“已确认取消”或“状态未知”。

审批必须绑定对象、证据、范围和有效期，不能只存一个“已批准”

内容审批包展示 12 个来源快照、9 项事实及其位置、17 个链接、警告、草稿哈希值和计划执行的外部动作。批准记录写明执行者、授权范围“发布”、哈希值 D-8f3c、检查回执 C-441 和过期时间。正文任何字节或关键元数据发生变化，旧审批都不能再用于发布。

发布后第二道发送审批先访问公开统一资源定位符，确认页面哈希值、标题、17个链接与预期，再显示63名受众的分组和抑制结果。把“发布并通知”合成一个按钮会让网页错误在人工看到之前传播。

审批可以撤销。周予若在发布前发现来源更正，就记录“审批已撤销”事件；守卫要确认审批尚未撤销，且产物仍与获批版本一致。若发布已经执行，撤销不能假装请求从未发生，任务应转入状态未知或补偿，并先查询远端。批准界面因此要显示操作是否已经开始，以及此刻撤销可能产生的实际效果。

代理审批、批量批准和永久批准不用于首版。周予若无法在24小时内审，任务过期；系统不会因“这类周报以前都批”自动延续许可。审批时间是重要运行成本，最近 30视图分别统计等待内容与发送复核，避免把人工瓶颈误诊为模型慢。

来源、草稿和检查产物都要冻结，批准后重新生成必须重新审

12 个来源分别保存网页地址、抓取时间、内容哈希值和许可范围；抓取失败时，不能让 AI 凭记忆补事实。事实表中的 9 项声明全部有来源位置，17 个链接的检查回执区分 200、重定向、超时和已阻塞。草稿、事实表、链接报告和渲染页面共同组成审批内容包。

AI若在内容管理系统写入前“顺手润色”一个段落，哈希值变化就回到检查和等待内容审批。批准保护的是具体产物，不是对主题的泛化许可。

计算哈希值前先规范化明确可忽略的元数据，例如构建时间不进入内容哈希值，但标题、正文、引用、链接和语言都进入；否则每次导出产生新哈希值导致无意义重审，或反过来漏掉重要变化。哈希规则本身有版本，批准记录“哈希规则版本=2”，升级算法时不能直接比较旧值。

来源在审批后变化也会使包过期。系统不持续联网偷偷替换12个快照，而是保存截止；若监控发现关键来源更新，生成源变更警告，由周予决定是否回收集。已批准事实不会因网页后来改变而被历史重写。

外部写入先记录意图，再执行，再保存远端编号和验证回执

发布与发送都使用意图日志。先在本地事务中创建已准备的操作并关联任务；执行器领取后才调用外部平台；响应成功先保存远端编号，再推进任务。若进程在外部成功和本地保存之间崩溃，恢复可按操作键查询，而不是丢失关联。

外部平台即使原生支持幂等键，本地仍要保存自己的操作记录。Stripe 当前接口文档说明，其幂等请求会按键保存首次结果，后续相同键返回相同结果，并对参数不一致作出约束；这是特定产品的语义。使用任何平台，都应核对键的保留期、参数比较、并发和错误结果规则，不能假设所有接口都一样。

“已准备”的操作与任务转换在同一个本地事务中提交，目标类似事务性出站队列：不允许任务已经进入发布，却找不到待执行意图。执行器按操作编号领取，并标记为执行中。外部结果无法与本地数据库原子提交，所以仍要保留状态未知和对账路径；出站队列能减少丢请求，却不能消灭跨系统的不确定性。

操作不可变意图与可变执行分开：操作键、意图哈希值、目标固定；尝试、状态、远端编号和最近观察更新并留事件。人工不得在同操作里换标识符或受众来“修复失败”，因为那已是新意图。仪表盘可据此区分同一意图的多次尝试与两个不同业务动作。

邮件是无法回退点：状态查询、受众抑制和更正都要单独设计

发送操作键包含任务、公开网页地址、邮件正文哈希值和受众哈希值。创建活动后先保存活动编号；真正发送前，再检查抑制名单和 63 人计数。响应超时时按活动编号或操作键查询，绝不另建活动。提供商“已接受”不等于邮件“已送达”，回执要分别记录已接受、已送达、退信和投诉。

第 30 周最终回执为已接受 63、已送达 62、已退信 1；成功只表示计划动作已经完成并留下状态记录，不等于 63 人都阅读了邮件。退信进入人工客户维护队列，不触发智能体自行猜测邮箱。

受众哈希值由排序后的收件人编号和抑制名单版本生成，不把完整地址写进批准记录。发送前重新计算：若有人退订，哈希值变化会使旧审批失效；即使受众人数减少，也不能自动沿用许可，因为授权范围已经改变。重新审批页要突出新增、移除及其原因；任何新增收件人都需人工确认。

邮件状态轮询也有上限，不能让执行器一直等待所有供应商的最终状态。平台接受活动后，任务可以记录为“发送结果待确认”并释放租约，再由定时任务轮询；30 分钟后仍有待定项，本例会改为“等待观察”并通知人工查询，而不是提前记为成功。业务状态名必须与对客户的承诺一致，不能为了让完成率好看而提前成功。

回滚、补偿、对账和转发修复是四种不同恢复

代码部署错误可把应用产物回到上一版，称回滚；网站内容可把当前版本指回已批准旧版，但已产生的统一资源定位符访问/缓存仍需处理；邮件只能补偿；状态未知先对账；数据迁移若不可安全回退则转发修复。一个“撤销”按钮无法覆盖这些语义。

Microsoft Azure 架构中心的补偿事务模式强调补偿是业务特定、可能失败、需记录进度并可恢复，而且不一定把系统恢复成初始状态。本文借用这一分布式恢复思想；63人邮件案例仍需按实际服务能力和客户沟通责任处理。

补偿计划逐项记录原操作、当前远端状态、补偿动作、先决条件、负责人和验证方法。例如，在把文章 18427 回退到版本 v29 前，先确认当前仍是错误的 v30；若他人已发布 v31，直接指回 v29 会覆盖新工作，必须转人工或采用向前修复。补偿不能无条件执行“反操作”。

补偿自身使用独立幂等键，也必须能够暂停后恢复。步骤 1 关闭自动发送，步骤 2 切回网站，步骤 3 验证公开页面哈希值，步骤 4 处理缓存和重定向，步骤 5 决定如何沟通；若步骤 3 失败，状态继续保持“补偿中”，已完成的步骤不重复产生副作用。恢复完成后记为“已补偿”，原发布事件仍然保留。

事件记录、告警和三个日常视图让一个人看得懂自动化现在在做什么

事件日志只追加、不改写：序列、任务、操作、发件人与收件人、执行者、时间、原因和证据位置。日志不写完整客户内容或令牌。指标从事件和操作记录中计算，不能用聊天摘要猜运行历史。

成功率不是唯一指标；“失败可见、状态不乱、外部副作用不重复、能在预算内恢复”更接近可靠性的工作定义。

指标分母必须明确。重试率按工具调用计算，还是按任务计算，会得出不同结论；本例同时记录 19/360 次来源调用和受影响的运行数。未知时长从“请求已发送”算到“已确认”或“已锁定”；审批等待从进入等待状态算到批准或过期；平均恢复时间从事件确认算到所有不变量恢复，不能把告警前的潜伏时间丢掉。

告警必须带着处置所需的信息。重复远端对象消息要包含任务、操作键、两个远端编号、哈希值、最近一次批准和冻结结果；只发一句“检测到异常”，会迫使周予在压力下重新调查。每月演练一次未知发布，每季度演练一次补偿；若运行手册离开作者的记忆就无法执行，应视为失败。

用 48 个故障场景验收状态转换和恢复，不只跑一次正常演示

测试同时检查任务状态、事件、操作记录和模拟远端对象数。只断言最终成功，会漏掉“先发了两次再删一条”这种严重的过程错误。故障注入在非生产环境执行；涉及邮件时使用沙盒收件组，不能拿 63 名真实客户做演练。

48 个案例还要冻结预期事件序列。例如，内容管理系统状态未知的案例应依次出现“发布已开始 → 请求已发送 → 状态未知 → 开始对账 → 远端已确认 → 已发布”，且创建调用次数必须为 1。若实现直接从状态未知跳到已发布，缺少查询证据，即使远端对象数最终为 1 也算失败。并发案例让两个执行器交错执行，用来验证旧隔离令牌不能再写状态。

修复一项失败后，要重跑全部 48 项，并保留三类非故障基线：正常运行不应因可靠性控制而明显变慢；人工审批不能在超时后被自动视为批准；监控故障不应导致客户内容写入调试日志。恢复功能本身也可能制造新风险，不能只测试事故分支。

30 期运行账本：恢复成功不等于没有问题

30 期共计划 360 次来源读取。期间出现 19 次瞬态错误：6 次域名解析失败、8 次超时、5 次速率限制；18 次在预算内恢复，1 次关键来源持续缺失，任务阻塞且没有发布。6 次 AI 结构错误均在一次修正内通过；3 次事实证据失败全部转人工，没有盲目重新生成。

网站已补偿的那一期没有计入成功，也没有发送邮件；修正来源后创建新的任务版本，而不是改写历史状态。30 期只是小规模案例证据，不能证明未来没有故障；它能证明的是，设计中预期的几类故障可以留下证据并收敛。

28 期成功中，24 期没有异常，4 期至少经历一次可恢复事件。因此，“完成率 28/30”不能说明恢复设计是否有效；还要分别检查 5 个未知操作是否都在预算内完成对账、重复计数是否为 0、未批准发布是否为 0，以及人工接管时是否拿到了完整证据。已阻塞与已补偿说明保护机制生效，不能全都藏进一个模糊的失败数里。

运行账本还记录人工时间：内容审批中位数7分钟、发送审批3分钟、异常对账最长11分钟。自动化节省未在本文计算，因为没有重建人工基线；可靠性文章不把“30期跑完”顺便包装成效率收益。

把事故运行手册写成查询—冻结—判断—恢复—验证—沟通，而不是“重启试试”

演练场景是内容管理系统出现两条使用同一操作键的对象。系统自动冻结，不删除其中任何一条；人工比较哈希值和访问记录，选择 18427 作为规范版本，将另一条下架并记录重定向与缓存处理，同时确认邮件尚未发送。运行手册在 16 分钟内完成技术处置，客户沟通另由周予决定。若补偿步骤本身失败，状态继续保持“补偿中”并告警，不能手工改成正常。

演练结束后再做一次证据盘点：两个远端对象仍可由事件追溯；规范页面的哈希值与获批的 D-8f3c 一致；重复网页地址不再公开返回冲突内容；调度器和撰写程序只在负责人确认后恢复；下一期使用新的任务键。少一项都不能关闭事件。“用户现在看不见错误”不代表内部一致性已经恢复。

复制这份最小可靠运行包，从一个会写外部系统的步骤开始改

最小包包含任务结构、状态转换表、不变量、操作与幂等表、错误与重试策略、审批方式、超时表、补偿矩阵、事件日志、仪表盘和故障集。先选择现有自动化中最危险的一项外部写入，不必一次重建全部流程。

本案例参考了五类公开资料：RFC 9110 对 HTTP 幂等语义及非幂等请求自动重试边界的说明；AWS Builders' Library 对客户端请求标识、同一意图重试和延迟请求等接口设计问题的讨论；Microsoft 对有限重试、退避、抖动以及避免层叠和无限重试的建议；Azure 补偿事务模式对业务特定补偿、进度记录、幂等补偿和人工介入的说明；Stripe 幂等请求文档提供的一种具体接口实现。产品细节和键的保留期会变化，实际使用必须以目标服务的最新文档和测试结果为准。

• RFC 9110：HTTP Semantics，Idempotent Methods
• AWS Builders' Library：Making retries safe with idempotent APIs
• Microsoft：Recommendations for handling transient faults
• Microsoft：Compensating Transaction pattern
• Stripe API：Idempotent requests

今天先选一个会写入外部系统的动作，补齐五个答案：业务意图键是什么；请求超时后怎样查询实际结果；哪类错误可以重试、总预算是多少；审批绑定哪个具体哈希值；已经产生副作用后怎样补偿。任何一项只能回答“平台应该会处理”，就先停在草稿或人工批准，不让自动化直接写入生产系统。