用一次失败演练定义生产边界
虚构的市民活动中心使用三个 Agent 整理活动变更：资料读取、说明草拟和内部核对。演示中一次成功不难，真正的问题是外部数据超时、一个角色失败或进程重启后，团队能否知道做到了哪里、哪些结果还能用，以及有没有重复发出通知。本文沿容错、可观测性、状态恢复三条生产防线设计验收，不将“多开几个上下文”当作可靠性方案。 先固定任务版本、输入快照、模型与工具、运行环境和允许副作用。当前例子只生成内部草稿，不自动向公众发送。设定成功、部分完成、待人工处理与失败的含义，明确谁负责值守和最终决定。本文没有运行生产 Agent、安装监控或更改实际服务设置，下面的故障都是合成演练设计。
防线一：分类失败，给重试和回退设上限
将失败分成输入不完整、权限拒绝、暂时性服务故障、业务校验不通过和结果未知。缺少活动日期需要回到材料负责人，不能重复问模型直到它猜出日期；权限拒绝需要正确配置与授权，不应自动换高权限账户。暂时网络故障可以设计受限重试，但次数、间隔、总时间和取消条件必须明确。 外部调用超时不代表操作没发生。只读资料查询通常可以重试，而通知发送或写入任务必须先核对实际结果。为业务动作保留稳定请求标识与结果记录，区分“准备执行”“已确认完成”和“未知待查”；不要让框架重放把同一条通知发送多遍。即使存储了检查点，也需在业务层考虑重复和部分失败。 回退应保持语义。实时活动数据不可用时，可以返回带时间的最后批准版本并标明不是最新，或者暂停生成；不能悄悄用猜测替代。一个角色失败后是否允许其余结果交付，要按字段与业务决定。资料源失败却发布完整通知属于错误降级，不应为了维持流水线绿色而忽略。 如果外部服务持续失败，暂停相关调用并给负责人明确状态，防止大量 Agent 同时重试加重故障。恢复条件和观察窗口要可说明。所谓自愈只适合已定义且可验证的操作，重启服务不能修复错误数据、权限缺口或不兼容版本。多个模型投票也不能把缺失证据变成事实。 本防线产物是错误分类表、重试与回退政策、未知结果核对步骤和故障样例。分别演练短暂故障、持续故障、拒绝访问与超时未知，确认系统不会无限重试，不会让失败角色污染已经通过的产物，也不会在取消后继续执行外部动作。
防线二：用请求链定位，而不是收集全部对话
每次批次有运行编号，每个任务有父子关系、角色、输入版本、开始结束、状态、尝试次数与产物位置。保留必要模型和工具版本、用量与错误类别，帮助判断问题在资料读取、草拟还是核对。日志数量多不等于可观察，关键是能把一次最终输出追溯到对应操作和证据。 开源参考可以从 OpenTelemetry 的追踪机制和 GenAI 语义约定学习操作关联。相关约定仍有版本与发展状态，应固定采用范围并检查实际库支持，不把某个新字段写成所有框架都已实现。标准描述提供共同语言，不会自动为应用安装监控，也不替代权限和业务验收。 默认不把完整提示、用户输入、工具返回或秘密写入日志。诊断信息可能含个人资料，外部可观测平台也可能成为新的数据接收方；先确定采集、脱敏、访问和保留政策。用合成资料验证日志字段，避免以“排错需要”为由永久打开所有内容记录。错误消息与告警同样要检查敏感信息。 告警围绕可行动状态设计：失败率异常、任务卡住、重试激增、预算耗尽、关键产物缺失。每条告警有负责人、触发依据和处置步骤，避免重复噪声让真正问题被忽略。健康检查只说明某些进程或依赖状态，不证明整条活动更新业务已经成功；应另有端到端合成检查。 对经过脱敏的本地运行指标 CSV，可以在故障复盘阶段使用 Exploratory Data Analysis。SkillPI 详情、K-Dense 固定来源与 MIT 许可已核验。它适合检查缺失、分布与异常，前提是明确可读文件和 Python 依赖；它不会安装监控、重启服务或判断某次操作一定安全。 分析前核对一行是任务、尝试还是整次运行，避免把重试数误读成失败任务数。标注采样、缺失和时间单位，比较相同输入下的等待、执行和审查时间。指标相关性不是原因证明，结合实际调用链定位。产物为追踪字段字典、脱敏日志样例、告警规则、处置手册与复盘记录。
防线三：保存可恢复状态，并测试恢复本身
把长任务拆成能解释的状态与产物：已取得资料、已批准事实、草稿版本、核对问题、最终内部交付。每条状态记录关联任务、输入版本和产物摘要，避免只在聊天历史里留“完成”。写入状态和产物的顺序要考虑崩溃，不能状态显示完成但实际文件不存在，也不能新旧版本被混合读取。 根据需要选择存储和一致性机制，明确并发更新由谁拥有、如何检测旧版本提交以及备份怎样恢复。三份文件或一个数据库本身都不是防丢保证，存储权限、写入失败、磁盘容量和损坏同样需要处理。不同 Agent 的独立目录并不自动解决共享状态冲突。 演练在不同节点终止进程：资料读取后、草稿写入后、审查返回前、最终交付标记前。恢复时核对输入是否变化，已确认完成的步骤是否可复用，未知步骤是否需要检查，待人工决定的状态是否仍保持。不要为了赶进度把拒绝结果改成通过，也不要不看实际结果就从头执行所有副作用。 恢复记录需要包括使用的检查点、重新执行步骤、被复用产物、外部动作核对与最终状态。由另一位维护者按手册操作，检查它是否依赖作者记忆。若恢复需要不可用的账户或密钥，提前记录前提，而不是在真实故障时才发现。定期验证备份可读，不能仅凭“备份任务成功”断言业务可恢复。 本防线产物是状态模型、存储与版本策略、恢复手册和故障演练结果。持久化帮助恢复，但并不替代幂等、审查和权限控制；正常运行中还要确认状态保留与删除符合团队数据政策。最终交付应注明本次是否完整、还有哪些任务待决，不能只给一个绿色总状态。
一次可以执行的生产演练请求
“针对合成活动变更流程，列只读与副作用步骤、错误类别、重试上限、回退和取消。设计带运行编号的最小脱敏追踪，再定义检查点与恢复。分别模拟服务超时、权限拒绝、角色失败、进程中断和未知结果，不连接真实通知渠道、不重启生产、不放宽访问。交付设计与实际执行记录分开。”演练应先在认可的环境完成，之后才由负责团队决定真实接入。
FAQ 与常见陷阱
系统崩溃总是 prompt 太长吗？不一定，还可能是依赖、资源、服务限流、状态或权限问题，先看证据。重试越多越可靠？不是，可能放大故障和重复副作用。监控是不是把所有对话存起来？不是，优先采集可关联且最小必要的结构化信息，内容采集另行审阅。 检查点存在就能原样继续吗？需验证版本、产物与重放语义。人工审核是不是只看最高风险项？由任务风险和不确定性设计，也应关注抽样与系统性遗漏，不能一概忽略其他问题。所有 Skill 都兼容编排框架吗？不能保证，调用工具与运行前提不同；sessions_spawn 等名称属于具体环境，不是所有 Agent 的通用接口。 本稿关联的 EDA 只用于本地指标分析，没有把它当作生产编排或自动修复技能。未来新增候选时应核对公开详情、固定源码、许可、依赖与实际步骤，再更新关联。没有合适技能也可以使用官方框架与运维工具，不能为了卡片数量添加无关包。
来源与维护
保留原文中文的失败容错、过程监控、状态持久化和 FAQ，使用原创活动变更与中断演练。参考 LangGraph 容错和执行恢复文档、OpenTelemetry GenAI 约定及关联 EDA 固定源码，移除热度、自动防崩、绝不冲突和免费保证。本归档条目为中文生产主题，不与另一个拆解通信英文变体强行配对。