跨小时或跨天的企业任务怎样可靠运行？使用持久状态、检查点、心跳、恢复和人工接管

先看结果：正确系统行为从146/180升到176/180，关键不是让智能体一直在线

铸川装备集团在12座工厂维护压缩机、泵和冷却设备。一次异常维修从告警开始，要读取遥测与历史工单，形成诊断计划，等待现场技师上传测量，核实备件，提交停机/作业许可，等批准和维护窗口，最后核验遥测并关闭计算机化维护管理系统工单。任务可能20分钟完成，也可能跨三个班次；模型只整理证据、建议下一步和准备草稿，设备隔离、作业许可、实际维修和恢复生产始终由授权人员决定。

早期原型把整件事放在一个执行器进程和一段智能体对话里。执行器重启后它读最近摘要“继续”，却不知道工单是否已创建；审批链接重复点击时同一事件被消费两次；计算机化维护管理系统写入超时后直接重试，产生第二张工单；等待技师两天的任务没有截止日期，静默留在内存。问题不是上下文窗口不够，而是没有独立于执行器的业务状态和外部影响证据。

团队建立420个虚构教学案例：240例用于流程设计、模式和故障修复，180例按时长/设备族封存留置。保持模型、工具和业务评分标准不变，只替换执行层。原型有116个完整正确、22个正确转人工、8个安全停止、18个错误/重复动作、16个丢失/卡死；持久版为145、21、10、2、2。正确系统行为分别146/180=81.11%和176/180=97.78%。

持久版的95分位端到端周期从无法可靠统计变为51.4小时；这不是速度提升，因为样本包含等待人员、备件和维护窗口。恢复测试中36次执行进程崩溃没有丢案例，30次重复回调只产生一次状态迁移，24次未知效果全部先对账，18次跨版本部署均由原版本或显式迁移继续。仍有4个非正确案例：2个错误来自业务主键映射，2个卡死来自未覆盖的旧供应商回调，均保留为发布阻塞项。

公司、设备、系统、人员、样本、时间、阈值和结果全部是教学数据，不代表任何工厂、框架或模型的实绩。本文讨论任务执行可靠性，不提供设备诊断、安全生产或维修建议；现场法规、锁定/挂牌、许可和复产标准由组织合格人员执行。

这是一个虚构教学案例，目标是展示怎样验证执行语义，而不是给某类设备提供故障率或维护周期。正确系统行为也不等于诊断正确率：正确转人工、安全停止都计为正确，是因为系统在证据、权限或时间不足时遵守边界。模型诊断另有领域评估集；即使模型建议完全正确，只要恢复时重复创建工单、接受过期许可或丢失案例，本篇仍判失败。

本文处理任务存活与可恢复，不重新讲工具契约、系统接入或多智能体

E17规定单次工具调用的输入、权限、副作用、幂等和错误；E18规定客户关系、办公自动化和企业资源计划系统的分级接入、部分成功与补偿；E19判断是否需要拆成多智能体。本篇把已经批准的跨时任务放进可恢复执行层，回答服务重启、等待、回调、重试、部署和人工接管后“现在真实进行到哪里”。

长任务不是“单次请求耗时很长”。下载大文件30分钟但可安全从头重来，未必需要复杂编排；一个任务只运行5秒，却写入三个系统并等待第二天审批，也需要持久性。判断维度是是否跨故障边界、是否有不可重复影响、是否等待外部事件、是否必须解释中间状态。

持久执行也不等于某个产品。文章用通用的实例、事件、活动、定时器、租约、效果账本和产物术语；团队可在托管编排器、工作流引擎或自建数据库/队列上实现，但必须用故障测试证明语义，而不是因服务名含“持久化”就放行。

持久性不修复错误的业务定义。设备主数据把旧资产映射到新设备、审批人没有实际授权、计算机化维护管理系统无法标识同一业务意图、维修完成没有可验收证据时，执行层只能更稳定地重放错误。上线前由设备负责人批准主键与终态，由平台负责人批准状态/恢复语义，由每个工具负责人批准幂等与对账方式，由值班负责人确认接管容量；四类责任不能都落到“智能体团队”。

先量原型的16个丢失/卡死和18个错误影响：不要从框架选型开始

240例设计集先跑原型，并保存应用日志、计算机化维护管理系统与办公自动化系统的结果，以及参与人员的事后回忆。原型只能说“执行器成功或失败”，团队把它改写为案例终态与外部影响终态。16个丢失或卡住的案例中，7个因执行器重启丢失内存，4个因审批等待没有截止日期，3个因回调进入错误实例，2个因部署后旧任务没有兼容执行器；18个错误或重复案例中，8个在状态未知后盲目重试，5个重复消费事件，3个使用过期批准继续执行，2个从旧摘要恢复时跳过核验。

基线按时长切片，防止只测试两分钟成功路径：少于2小时45例、2—8小时55例、8—24小时40例、24—72小时30例、超过72小时10例，共180。每例固定告警、设备身份、工具结果、批准、回调和预期终态；时间在测试环境使用可控计时器推进，不真的等待三天。

“完成率”不能掩盖重复外部动作。原型若最终关掉了告警，却建了两张工单、使用过期许可或漏记人工修改，仍是错误。主分母是案例；另外单列未经许可动作、重复效果、丢失实例、错误终端和人工重建分钟。

把编排、活动、业务记录和执行器分开，恢复才有明确对象

编排保存确定性的流程决定：当前状态、等待条件、已接受事件、下一活动和终端；活动执行不确定I/O，如读取遥测、调用模型、写计算机化维护管理系统或发通知；业务系统保存真正的工单、许可和设备状态；执行器只是随时可替换的执行进程。执行器不是任务，聊天线程也不是任务。

编排器不直接访问网络、当前时间或随机数来重算历史决定；这些值作为已记录事件/活动结果进入。否则同一历史在新执行器上重放时可能走另一条分支，出现“过去被改写”。模型调用也属于活动：结果作为版本化产物保存，重放读取旧结果，不再次问模型产生新答案。

业务记录与实例用稳定映射表连接：租户、工厂、设备编号、告警编号、工单编号分别保存，名称只作展示。实例可以说“等待工单483回执”，但计算机化维护管理系统仍然决定工单是否存在；发现冲突就进入对账，不能让编排状态覆盖业务事实。

实例记录先回答身份、版本、状态、等待、所有者和下一截止时间

每个案例创建不可复用的实例编号；同一告警重复启动时，通过起始键映射到已有活跃实例，或明确创建新修订版。实例记录不是整段对话，而是一组能够支持并发控制和恢复判断的字段。大产物只保存引用、哈希和访问控制，不塞进频繁读写的状态记录。

每次迁移都声明“当前状态版本必须为18”，提交成功后变为19；两个执行器收到同一任务时，只有一个比较并设置操作能够成功。失败的一方重新加载历史，不能覆盖胜出者。状态表、事件追加和出站命令应在同一原子边界提交；若无法放进同一事务，就使用可对账的收件箱、发件箱和唯一键，不能先改状态，再“尽量发消息”。

热状态支持按租户/状态/负责人/截止时间查询，但查询索引可重建。审计要从事件历史得到“为什么到这里”，不能把搜索索引当唯一记录。个人身份信息、受限附件和长模型推理不进入实例标签，避免可观测面泄露。

实例创建也有前置门。请求必须包含发起人、租户、设备权威编号、任务目的、允许的最大动作、资料版本和最长存活时间；起始键已对应活跃工单时返回既有实例，已对应终止工单时由策略判断读取旧结果还是创建修订版。不能仅用告警文本哈希去重，因为相同文本可能是两次不同事故；也不能每次刷新页面都启动新任务。

关闭前要检查终止不变性：必需活动均有终态；所有“意图、已发送或状态未知”的外部影响，均已确认、拒绝或交由人工处置；活跃租约与定时器已取消或失效；最终产物引用当前来源；人工决定记录了执行者和权限范围；通知失败也不会被误判为业务未完成。实例完成之后只接受注释、迟到事件和新修订版关联，不再执行原实例动作。

删除与保留分开。业务保留期结束后可清除原附件或敏感字段，但必须按治理要求保留足以证明动作、批准和处置的最小记录；删除产物后事件保存墓碑、原哈希和删除依据，不留下指向空文件却显示“证据齐全”的状态。法律保全或调查冻结时，普通清理任务不能继续删除。

事件历史记录事实与决定，检查点只加速恢复，不能替代历史

历史只追加已经发生的事件，例如实例启动、告警快照已接受、活动已调度、活动结果已记录、审批已收到、定时器触发、外部影响已确认、人工接管。每项事件都要记录事件编号、实例、序列、发生时间和入库时间、执行者、类型、负载引用及哈希、因果关系和数据结构版本。

检查点是“重放到序列100后的可信快照”，保存状态、已接受事件的编号和校验和；它损坏或版本不兼容时，可从更早的检查点与事件历史重建。不能只保存“第六步完成”后删除前因，否则无法证明使用了哪个设备、哪个输入哈希和谁批准。

历史不保存未经筛选的全部提示词和附件；产物存储按保留规则与访问控制保存必要输入、输出，事件只保存引用。对于诊断建议，应保留最终提示模板及版本、选定的上下文引用、模型与工具版本、输出产物和人工修正，而不是暴露模型的隐藏推理。

状态机把等待、部分成功、结果未知和人工接管写成一等状态

“运行中/失败/完成”太粗。维修案例至少区分收集上下文、等待技术测量、准备工单、工单对账、等待审批、等待窗口、验证修复、人工接管以及已完成/已取消/安全停止。状态未知不是异常消息，而是需要查询目标系统的状态。

START -> COLLECT_CONTEXT -> WAIT_TECH_MEASURE
WAIT_TECH_MEASURE --event--> PREPARE_WORK_ORDER
WAIT_TECH_MEASURE --timer--> HUMAN_TAKEOVER
PREPARE_WORK_ORDER -> EFFECT_INTENT -> CREATE_WO
CREATE_WO --receipt--> WAIT_APPROVAL
CREATE_WO --timeout/unknown--> RECONCILE_WO
WAIT_APPROVAL --valid approval--> WAIT_WINDOW
WAIT_APPROVAL --reject/expire--> CANCELLED | HUMAN_TAKEOVER
WAIT_WINDOW --window event--> VERIFY_REPAIR
VERIFY_REPAIR --evidence pass--> COMPLETED
Any state --unsafe identity/permission--> SAFE_STOP
Any nonterminal --owner takeover--> HUMAN_TAKEOVER

状态迁移函数校验当前状态、事件结构、实例与租户、期望版本和业务前置条件。迟到的技术测量在实例完成后只记为晚到事件，不重新打开终态；需要继续工作时，由负责人创建新修订版，并记录它与原实例的父子关系。

完整走例：执行器在计算机化维护管理系统超时后崩溃，新执行器先对账而不是再建工单

案例C-088在19:42收到压缩机振动告警A771，实例MX-0088固定设备P4-COMP-17和遥测快照S55。上下文活动读取计算机化维护管理系统历史与手册，模型产物A-DIAG-8提出“现场复核传感器安装与振动值”，没有下达维修动作。系统进入等待技术测量，并创建22:00触发的持久化定时器；20:15，技师事件EV-44到达，测量值、设备、采集人和附件哈希通过数据结构与权限检查。

协调者生成工单草稿，轮班负责人确认负载h9。提交前，外部影响账本写入操作OP-WO-88、目标系统、创建意图、幂等键、负载哈希和授权记录AUTH-17。20:18调用发出，计算机化维护管理系统实际创建了工单483，但响应在网络中丢失，活动被记为状态未知。20:19执行器崩溃；租约到期后，执行器7从历史重建进度，进入工单对账，按操作键查询系统，找到工单483的回执，确认影响已发生并转入等待审批。它没有重新调用模型，也没有再次创建工单。

这些时间来自故障演练中的压缩计时器，不代表真实设备事故的处置时序。随后，办公自动化系统中的审批绑定工单483、负载h9、批准人权限范围和过期时间；维护窗口事件到达后，系统只提示授权技师执行，等待技师回传完成证据；验证环节读取新的遥测和工单记录，生成关闭包供负责人确认。若对账没有找到工单，而目标系统又不能按操作键保证唯一，系统就转人工接管，绝不用“可能没成功”作为重试理由。

这条走例从原始告警、模型建议、人工测量、效果意图、状态未知、执行器恢复、对账回执到最终等待批准均可由事件/产物重建；对话摘要只用于界面阅读，不驱动迁移。

把同一走例换成三种故障，能检验设计是否真的通用。若执行器在意图提交后、请求发出前崩溃，新执行器可以用同一个操作编号安全地完成首次调用；若在目标执行后、回执写入前崩溃，实例进入状态未知并查询；若回执已经持久化后旧执行器迟到返回，它只被识别为重复尝试，不再触发状态迁移。三种日志表面上都可能是“调用超时或执行器消失”，恢复动作却必须由持久证据，而不是错误字符串决定。

若办公自动化批准在执行器离线期间到达，收件箱先保存并验签，恢复后按等待审批和负载 h9消费；若批准先到、实例尚停在创建工单，则待定到允许状态但不得越过“工单回执已确认”的屏障。若其间工单内容被人工改为h10，旧批准失效，系统请求新批准。这样等待不是暂停全部事实更新，而是用版本前置条件保护下一动作。

最终关闭也不是模型写一句“维修成功”。它包含告警/设备映射表、诊断与人工修正、工单/许可收据、实际执行人和时间、维修后遥测窗口、仍未关闭的风险、负责人决定以及每个来源版本。缺维修后证据时进入等待验证或人工，不因达到72小时自动已完成。

检查点按可验证边界保存，不按每句话或固定五分钟机械切片

编排每个有业务意义的事件都持久化；大活动内部的检查点只保存可安全恢复的进度。批量读取2,000个遥测块，可在每100块记录最后稳定游标和结果哈希；一次原子CMMS 创建不能声称做到70%，只记录意图、状态未知或回执。模型流式生成到一半通常不能作为业务产物，失败后用同输入/版本重试或转人工。

检查点频率要在重复成本、历史与存储成本、来源波动性和外部影响边界之间取舍。重新读取五分钟遥测的成本低，可以少存；耗时两小时的受控解析应分块；任何外部写入前先持久化意图，成功后持久化回执。检查点负载要有数据结构、版本、校验和、访问控制与保留期，不能只是序列化执行器内存，然后祈祷以后还能加载。

来源可能改变时，恢复不从“页101”盲续：先验证快照/版本；若遥测窗口允许追加，用水印；若文档被替换，旧运行保留旧快照或显式已失效。把新资料悄悄接在旧结论后会制造不可解释的混合证据。

外部影响用操作身份、回执和对账闭环，幂等键不是万能护身符

每个可能改变外部系统的活动，都要先创建影响记录。操作编号表达业务意图，例如“为实例MX-0088创建一张对应负载h9的维修工单”；尝试编号只表示某一次传输。所有重试复用操作编号和幂等键；负载哈希发生变化时，必须创建新操作或重新取得人工批准，不能让同一个键代表不同意图。

重试只适合合同明确的瞬态类、预算内且影响幂等；验证、权限、冲突不重试。超时无法说明目标没执行，先按操作键、业务对照表或回执查询对账。若目标既不接受幂等键又无法查询，自动重试非幂等创建是不安全设计：改为人工、目标适配层或先创建可取消草稿。

幂等记录有作用域和生命周期。键按租户 + 操作唯一，保存时间覆盖最大重试、晚到交付和业务重复风险；若目标30分钟后忘记键而队列能迟到24小时，本地“幂等”不成立。返回相同回执前还要验证负载哈希，防止同键代表不同意图。

补偿不是删除历史。错误创建工单后，取消是新操作，记录批准、原因、目标回执和不可逆后果；若已派工或产生费用，不能只把实例状态改回准备。E18处理跨系统补偿，本篇强调恢复进程不能把补偿误当重试。

状态未知对账按证据强弱排序。第一层用目标系统原生幂等键/操作查询；第二层用已批准业务主键、负载哈希和创建时间窗口精确匹配；第三层让目标负责人查看审计记录。只能按设备名模糊找到三张候选工单时，结果是模糊而非未找到。只有权威查询明确未执行且原批准仍有效，才允许同操作重发。

对账本身也会失败，因此它是独立活动，有超时、权限和重试预算；不能在异常处理捕获里临时做一次无日志查询。若目标查询权限在夜间过期，系统等待值班人员重新授权或人工核实，不借用写入账户做读取。回执一旦确认，后续目标修改作为新源修订版处理，不改写当时影响已发生的事实。

租约和心跳回答“谁在做、是否还有进展”，不能证明业务影响没发生

队列投递任务后，执行器取得有期限的租约，其中包含活动编号、尝试次数、执行器和到期时间；长活动定期发送心跳，并附带小型检查点。租约过期后可以调度新尝试，但旧执行器可能仍在运行，因此目标调用仍须幂等，提交结果时还要检查尝试编号和状态版本。租约只能减少并发冲突，不能保证外部动作只发生一次。

心跳包含最后完成单元、来源水位和取消检查点，不塞完整产物。连续心跳表示进程活着，不表示结果正确；对于需要长时间轮询的外部任务，最好记录作业编号，并用定时器或短轮询活动查询，而不是让执行器占用线程三天，不断发送“仍然存活”。等待人员或维护窗口时不发心跳，而是使用持久化定时器和外部事件。

取消分已请求、已确认和效果已结算。执行器收到取消后停止新动作、保存检查点、确认已发出的影响并返回已取消/部分完成；若无法中断目标作业，实例进入取消待处理并持续对账。强杀进程不能替代取消协议。

心跳的内容同样要验真。执行器不能只在主线程卡死时由旁路线程持续发“活着”；进度字段必须随已完成单位单调前进，超过无进展阈值即使有心跳也报警。反之，某些短活动根本不需要心跳，过密心跳只增加写入和假信号。每类活动用故障演练决定频率，不复制一个全局30秒数字。

租约围栏令牌随每次尝试递增，支持的目标适配器拒绝旧令牌写入；不支持围栏的系统仍依赖操作幂等和提交前状态检查。旧执行器恢复网络后，看到租约/尝试已过期就停止并上报晚到结果，不能因“我的计算更早开始”覆盖新尝试的产物。

人工审批使用外部事件与持久化定时器竞速，链接、决定和证据都绑定实例版本

等待审批时，系统保存预期事件类型、实例、工单与负载哈希、合格审批人的权限范围、一次性随机值、签发与过期时间、截止日期和备用负责人。审批页面从系统实时读取待批内容；回调只提交决策、执行者、事件编号和绑定哈希，服务端重新鉴权。邮件链接即使泄露、转发或过期，也不能仅凭链接完成批准。

定时器与审批事件竞争时，只有一个比较并设置操作能够完成状态迁移。若22:00的定时器先提交，实例就进入审批已过期并通知负责人；22:00:01到达的批准只能记作晚到事件，不能继续维修。负责人可以检查当前材料后创建新的审批请求和版本。不能让定时器线程先发取消、回调线程又发执行，双方都认为自己成功。

人工队列显示等待原因、所需决定、证据、已发生影响、截止日期和接管按钮；不只发一封无人追踪的邮件。提醒频率与升级路径写在策略，三次提醒不是三次审批事件。缺负责人或超过最大年龄进入人工接管/安全停止，不无限等待。

人员身份在等待期间会变化。批准人在发出决定时，要重新验证雇佣状态、岗位、厂区权限范围、职责分离和临时授权，不能沿用两天前发送链接时的权限快照；同时把当时的认证决策编号持久化，日后离职也不会使历史批准“消失”。紧急代理人必须有明确委托记录，不能由平台管理员临时把自己加进业务批准组。

申请人撤回、设备事故升级或现场已经人工处理，都以结构化外部事件进入。撤回不一定能取消已创建的工单，系统先检查外部影响，再由负责人决定关闭、保留还是标记关联；现场已经先行处理时，则创建“按实际执行”证据，不让智能体倒填一个虚构的事前批准。持久化编排的作用是保留真实偏差，不是把所有现实强行改写成预设成功路径。

回调按至少一次和乱序设计：收件箱先验签、去重、绑定，再触发迁移

外部系统可能重复投递、乱序、延迟，也可能在实例尚未进入等待状态时提前发送。入口先验证签名或身份、租户、数据结构、大小和时间戳，把事件按唯一事件编号写入收件箱；随后再匹配实例和预期状态。重复事件返回既有处理结果；未知实例进入隔离调查，不能直接丢弃；未来可能接受的事件可以暂存，但必须有保留期限和负责人。

事件发生时间用于业务解释，入库时间与事件序列决定处理顺序；不能相信发送方时钟，并以此重排已经提交的历史。需要约束业务先后顺序时，应使用来源修订版、因果关系编号和状态前置条件。例如，“维修完成”必须引用当前工单483和许可版本，不能仅因时间戳看起来较晚就接受。

收件箱保留处理状态、匹配实例、转换序列与原因，便于重放适配器，但不能重复触发业务迁移。修复解析器后重放隔离事件时仍使用原事件编号；若原案例已人工关闭，只能补充证据，由负责人决定是否创建新修订版。

重试策略按错误语义、外部影响和剩余截止日期分层，不把无限重试当可靠

读取遥测遇到速率限制时，可以采用指数退避并加入随机抖动；模型服务短暂不可用时，可以在预算内重试；权限拒绝、设备编号错误、业务冲突和不支持的数据结构，应立即转交负责人。每次重试都要记录尝试次数、错误类别、下次调度时间和已消耗预算。总体截止日期只剩5分钟时，不应启动预计需要20分钟的第三次调用。

重试风暴可让故障扩大：队列按租户/工具限流，断路器暂停新活动，已有案例的定时器/人工入口仍服务；抖动避免同一时刻唤醒。毒丸消息超过适配器预算进入死信队列，但实例必须显式等待适配器/人工，不能消息去了死信队列而业务界面还显示运行中。

重试成功也不删除先前失败。历史保留每次尝试，指标以操作/工单为分母，避免十次尝试后成功被报成“100%可用”。值班人员能从最终案例下钻到错误序列，但用户界面只显示可行动的当前状态。

部署不能让正在运行的历史换一套过去：版本、兼容执行器和迁移都要显式

长任务运行时，代码、状态模式、工具、提示词、模型策略和审批评分标准都会升级。实例在启动时固定工作流/代码版本；重放旧历史由兼容执行器执行，或在已定义的安全状态运行迁移。不能部署后让所有旧案例自动套新分支，因为它们的历史里没有新分支过去应产生的事件。

部署期间并行保留新旧执行器：新实例进入第五版，第四版实例继续由兼容执行器处理；先在后台重放历史并做小范围生产验证，再逐步扩大。退役旧执行器前，应查询所有未终止的第四版实例，按状态、存续时间和下次唤醒时间分组，逐个排空、迁移或人工关闭。删除旧容器镜像不等于运行中的任务已经迁移完成。

迁移本身也是带前置条件的状态迁移：读取旧历史和检查点，生成新状态及映射报告，试运行验证后，再用比较并设置提交，并记录迁移事件。已经发生的外部影响不能重做；无法确认的案例转入对账或人工处理。回滚只能把新流量重新路由给旧代码，已经由第五版产生的事件仍需兼容方案，不能假定软件回滚会撤销业务动作。

升级前抽取每种旧状态与历史形态作为黄金重放语料库，至少覆盖等待、状态未知、人工和各终端；新代码对它们重放应得到相同命令序列，除非命中显式版本标记。只测试新建案例不会发现两个月前的等待审批在新枚举下无法反序列化，也不会发现旧定时器被重复安排。

模型版本变更尤其不能伪装成代码迁移。已经接受的A-DIAG-8在恢复时仍是历史事实；需要新模型复核时创建审查新模型活动和新产物，保留两者及负责人选择，不覆盖旧输出。政策明确禁止的旧结果则冻结案例并转人工，不自动用新模型继续产生外部动作。

人工接管不是把全部聊天记录扔给值班员，而是冻结自动化并交付可决策的包

触发条件包括关键权限或身份冲突、无法对账的非幂等影响、截止日期或重试预算耗尽、旧版本没有兼容执行器、来源被撤回、人员主动接管或安全事件。接管时先用比较并设置把实例置为人工接管，阻止新的活动和外部影响，取消或收口租约，再生成交接包。

人工动作也通过受权工具写事件/效果回执，不直接改数据库状态。操作员若在计算机化维护管理系统找到WO-483，提交确认现有含回执；若确认未创建，标记未找到后系统可在新批准下重试；若决定结束，取消附原因和已发生影响处置。自由文本备注是附件，不代替结构化决策。

接管后默认不自动恢复。负责人必须显式恢复，并选择工作流版本、允许的下一状态和新的截止日期；系统重新验证身份、资料版本、权限和仍在进行中的外部影响。值班员关掉告警但未处理工单时，实例仍保持部分完成或人工处理状态，不能为了降低存续时间而改成已完成。

可观测性以实例、等待、影响和恢复结果为中心，不用令牌流证明活着

可见性面让业务查看案例状态/负责人/截止日期，让运维查看队列/租赁/重试/版本，让审计查看事件/效果链；三者按权限分离。追踪连接实例→事件→活动尝试→工具操作→目标回执→产物，不把受限负载复制进每条日志。

“最后更新时间”不能区分正常等待和任务卡死。每个等待都要有原因、预期事件、负责人和下次唤醒时间；查询应找出已过唤醒时间却没有触发定时器、租约过期却没有重新调度、状态未知超过对账服务时限、终态仍有活跃定时器或任务等不变量。定期清理器只能发出修复命令或事件，不能越过历史直接改状态。

成本要按每个正确案例计算，包括历史与存储、状态转换、模型与工具调用、执行器时间、人工分钟和事故损失。等待两天不应占用执行器，但会占用持久记录和运营注意力；千万条细碎事件同样有成本。优化时应先保证执行语义，再通过检查点、把过长历史切分为有关联的新任务、产物归档和合理的事件粒度控制成本。

安全监控还要关联异常启动量、同一执行者批量批准、跨租户回调、重复使用随机数、短时大量状态未知与旧执行器持续写入。事件负载先做模式/大小限制再持久化，避免攻击者用超大回调拖垮历史；外部文本和附件仍是不可信数据，不能借回调改变系统指令、工具权限或允许动作。

灾备验收从备份恢复编排存储、产物和外部影响账本后，要逐个与计算机化维护管理系统和办公自动化系统对账。若目标系统在备份点之前已经执行，但回执在备份点之后才写入，恢复后会看到状态未知；此时必须通过操作键找回结果，不能重新发送。恢复点目标不仅表示“最多丢几分钟日志”，还要说明这几分钟内可能有多少外部影响需要人工或自动重建证据。跨区域切换时，实例、事件和操作编号必须保持全局唯一，避免两个区域各自接管同一案例。

用180例故障留置验收恢复路径：只跑成功路径无法证明持久化

故障注入覆盖执行器、消息、目标系统、人员、权限和部署。每例只在预设窗口注入主要故障，允许记录次生现象；预期终态事先冻结。测试计时器、队列和目标存根均可控；真实集成另在后台只读比较，不在生产工单上制造危险影响。

持久版结果中145 完成、21 正确接管、10 安全停止、2 错误、2 卡住=180；正确行为176。36次崩溃全部恢复，30次重复全去重，24次状态未知均进入对账，22次人工超时/拒绝均由计时器/结构化决策落终态，20次延迟事件未重开终端，18次部署走原版本或迁移，14次权限过期无借权，16次毒丸消息都进入隔离且案例可见。

2个错误源于设备映射把旧资产编号指向已经替换的设备，说明持久性无法修复主数据；2个卡住源于旧供应商适配器把回调写成没有实例归属的消息，而且隔离队列没有触发负责人时限告警。修复要求落实来源映射负责人并增加未知实例告警，不能依靠增加模型重试。任何未授权物理操作、重复维修工单和丢失实例的阈值都为0，本轮也均为0。

案例判定由平台评审与维修业务负责人分工：平台验证事件、定时器、租约、重试和效果不变性，业务负责人判断所用设备/许可/关闭证据是否适用。分歧保留原因并由预定裁决人处理；不能因最终工单“看起来对”忽略中间重复动作，也不能因系统安全停止没有完成维修就一律判失败。

每个故障切片报告分母和终态，不只列通过测试数。一次工作进程崩溃后先产生重复工单、再由人取消，最终状态虽可关闭，仍属错误/重复；一次权限过期正确转人工是正确行为。修复后重跑完整180例，而不是只重跑失败4例，防止去重修复破坏正常回调或版本路由。

放行还做属性/不变性测试：终端不可迁移、一个操作只能绑定一个语义意图、已确认必须有回执、等待必须有负责人 + 截止日期、活跃活动必须有租约、人工接管不能自动发新影响。随机组合崩溃与重新投递，寻找示例测试没有列出的交互故障。

发布从只读回放到小范围生产验证，再覆盖跨班次和真实部署

发布分六级推进：第0级只重放历史事件；第1级对真实案例做后台只读比较，并与人工工单对照；第2级在沙箱执行故障注入；第3级在生产环境只创建非运营草稿；第4级才允许经过批准的短任务产生低风险影响；第5级再纳入跨班次等待。每级只增加一种持久性风险，不能同时替换模型、工具和编排器。

小范围生产验证按工厂、设备风险、工作流版本、目标影响和支持窗口路由；高危设备与不可撤销动作继续保持人工。功能开关可以停止新实例或某类活动，但不能删除现有历史。紧急停止应冻结新的外部影响，同时允许读取、对账、定时器和人工接管继续运行；否则简单地“关系统”，反而会让状态未知和待审批任务更危险。

容量规划要关注到期定时器峰值、班次回调、目标系统限流、多个版本并存的执行器和对账队列。演练跨区域或存储故障时，要验证恢复点目标、恢复时间目标、备份恢复后的事件唯一性和业务系统对账；不能只看容器实例是否自动重启。

交付持久化执行包：今天先让一个跨时任务经得起三次故障

来源边界：Microsoft持久化函数概述用于核验“运行时管理状态、检查点、重试和恢复”的产品事实，外部事件资料用于核验异步等待、至少一次回调、唯一事件编号去重和定时器超时；Temporal的事件历史与活动资料用于核验事件回放、活动结果持久化、心跳检查点与活动幂等建议；AWS步骤函数资料用于核验标准工作流与快速工作流在时长、状态持久性和执行语义上的差异，AWS构建者资料库用于核验客户端请求编号、幂等重试、延迟请求和“相同编号、不同意图”问题。文章只抽取设计检查项，不要求选择这些产品，也不声称它们会自动解决业务幂等或人工责任。来源核验于2026-07-21。

• Microsoft Learn：Durable Functions overview
• Microsoft Learn：Handle external events in durable orchestrations
• Temporal Documentation：Event History
• Temporal Documentation：Activities
• AWS Step Functions：Choosing workflow type
• Amazon Builders’ Library：Making retries safe with idempotent APIs

今天选一个确实会等待、会写外部系统且不能安全从头重来的任务，不要先迁移全部流程。填一份实例记录和效果账本，画出等待/未知/人工/终止；准备同一案例依次注入执行器在写入前崩溃、写入后响应丢失、回调重复三次。只有新执行器能从历史解释当前状态、对账而不重复影响、定时器能把无人响应交给明确负责人，才加入跨版本部署与72小时等待；否则保持人工流程，并先修业务主键、工具契约和来源所有权。