第 26 章　让自动化稳定运行：重试、断点、日志与通知

创建一项定时任务，只解决了“什么时候开始”。法律资讯追踪还会遇到出处网站打不开、账号过期、正文为空、同一文件重复收录，以及结果生成后通知失败。本章接续第11章的创建操作和第19章的资讯案例，说明怎样使这些异常可以发现、恢复和停用。

以下以“指定专题公开法规更新检查”为教学任务，说明自动化的可靠性方法。文中的状态文件和指令是设计示例，不能据此声称 WorkBuddy 已内置事务控制、自动去重或完整审计系统；实际实现需要核对当前工具能力。本章不创建真实定时任务，也不替读者发送通知。

先写清正常结果与无结果

任务范围可以是：每天固定时间检查负责人选定的官方公开栏目，只追踪指定专题，输出新增文件、出处链接、发布日期及需进一步核验的问题。先在同样范围手动试跑数次，确认输入和输出基本稳定，再考虑定时。建议至少三次；这是便于发现差异的实践门槛，不是可靠性的保证。

必须区分三种情况：检查成功且有新增；检查成功但没有新增；出处无法检查。后两者都可能产生空表，但含义完全不同。若出处失联却输出“今日无更新”，使用者会误以为已经完成全面检查。因此输出开头就应列出处覆盖和异常。

任务：专题公开法规更新检查（教学配置）
范围：[专题]；出处：[逐个官方栏目URL]；时间：[时区和频率]
输出：新增条目、原文链接、标题、发布/实施日期、专题相关性、待核实项
禁止：不推断未取得正文的条款；不把转载时间当发布日期；不自动对外发送
成功无新增：明确说明已成功检查哪些栏目和检查时间
出处失败：列缺失栏目与影响，不写“全部检查无更新”
负责人：[姓名或角色]；停用入口：[实际核对后填写]

把运行分成有出口的步骤

可以按“等待触发—检查出处—获取—去重筛选—保存—通知”设计。每一步规定成功条件和失败出口。例如获取完成需有出处地址及取得时间，保存完成需实际产物存在，通知完成需有工具回执或目标侧可核对记录。不能因为模型说“已发出”就记为发送成功。

图26-1：自动化配置示例，展示从手动任务转向定时配置的思路；图中原案例为资讯选题，并非本章法律专题任务已经运行的截图。

不必照搬原例“几个出处正常就完整输出”的阈值。法律专题可能只有一个关键官方栏目，缺它就无法形成完整结论。先把出处区分为必需与补充：必需出处失败时只输出覆盖不足说明；补充出处失败时可以输出已取得内容，但显著标记缺项。条目数量少也不等于失败，公开法规并不会每天按数量发布。

只对临时故障重试

网络超时、临时服务错误可能适合等待后重试；认证失效、没有权限、地址错误需要人工处理。重复调用不会自动解决权限问题，反而增加费用或触发限制。实际等待时间与次数应结合服务说明设定；遇到服务返回等待要求时遵循对应规则，不无限重试。

对具有外部效果的动作还要更谨慎。如果通知请求超时，可能是发送失败，也可能目标已经收到但回执丢失。此时先核对目标记录，无法确认就标为“发送状态未知”，交人工处理。不能看到超时就无条件再发。查询重试与发送重试，应分别设计。

用批次与稳定编号防止重复写入

给每次逻辑运行一个批次号，例如 legal-update-2026-11-02-专题甲。手动补跑和原定时运行如果处理相同窗口，应先检查是否已有完成记录，避免重复写同一结果。条目也需要稳定识别依据：官方文件标识、原始地址与版本信息通常比标题更有用，标题相同不表示同一文件，地址变化也未必表示新文件。

补跑前请核对同一专题、日期窗口和出处是否已有批次。
已完成的读取与保存步骤尽量复用，不重新发送已有成功回执的通知。
发现同一条目已存在时报告匹配依据；不能确定是否重复时列为待核对。
若系统不支持可靠的去重与状态保存，请停在本地结果草稿，交人工确认。

“幂等”就是重复执行不会造成重复外部效果。仅在提示词里写这三个字无法保证做到；需要保存状态、核对已有记录，必要时由实际系统提供唯一约束。多人同时补跑还可能争抢同一批次，应指定一个运行负责人，或使用经验证的互斥机制。

断点、日志与降级结果

若获取与筛选已完成，通知失败，应保存结果与当前步骤，恢复时从通知核对开始。可以采用下面的最小记录，它是字段示例，实际存储方式由实现者选择：

{
  "batch_id": "legal-update-2026-11-02-topic-a",
  "scope_version": "v1",
  "state": "saved_notification_unknown",
  "completed_steps": ["fetch", "filter", "save"],
  "source_coverage": "required_source_missing",
  "artifact": "result-2026-11-02.md",
  "notification_receipt": null,
  "next_action": "check_target_before_retry"
}

日志保存批次、起止时间、出处状态、条目数量、产物位置、失败类型与恢复决定。凭据、完整案卷或客户私聊不应为了排错整段进入日志。需要进一步调查时，通过受控入口回看材料，日志只保留必要定位。

降级交付必须诚实：正文取得但附件失败，就写“附件未取得”；部分出处失败，就说明本次覆盖范围。保存可用结果比全部丢失好，但不得把局部结果包装为完整检查，也不能沿用昨天的内容冒充今天的新结果。

通知和演练要能推动处理

可行动的异常通知至少包括批次、失败步骤、影响、已保存产物、下一步和负责人。例如：“必需出处甲超时，本批次未形成完整更新结论；本地草稿已保存，请负责人检查出处后决定补跑。”没有新增且运行正常时，按约定保持安静或只记运行账本；不要为了证明系统在工作每天打扰所有人。

启用前模拟五种情况：正常有新增、正常无新增、必需出处失联、重复触发、通知回执未知。逐项看它是否区分状态、保留成果、避免重复，并能被停用。演练应使用虚构数据或隔离测试目标，不能用真实客户群试错。

运行后关注按时触发、出处覆盖、人工补跑次数、重复写入、通知状态未知次数和总成本。指标持续变化时先检查出处或配置，暂停扩展任务。自动化可靠的标志，是正常时少打扰人，异常时有人知道发生了什么、哪些结果还能用以及如何恢复。