定时 Agent 可以安静运行，但不能安静失败
定时 Agent 失败策略，是让后台运行的 Axon Agent 在失败时被正确记录、正确通知和正确复盘的规则。一个 Schedule 最大的价值，是减少重复、手动、耗时的日常操作；但如果失败是静默的，团队就会在几天后才发现报告没更新、资料没读全、产物没生成。相反，如果所有小波动都通知，又会让用户很快忽略提醒。
OpenAI Agents SDK tracing 强调运行过程可观察；NIST AI Risk Management Framework 也把监测和管理放在 AI 系统治理里。Axon 的产品判断是：定时 Agent 可以安静运行，但不能安静失败。
这和 Scheduled Agent Review Rhythm 一起看更完整。review rhythm 解决周期性检查；定时 Agent 失败策略解决每次异常怎么被接住。
背景任务最怕两种失败
第一种是静默失败。Agent 没有生成产物，或者生成了明显不完整的产物，但界面没有让 owner 知道。第二种是噪音失败。每个轻微网络波动、每个可重试问题都推送给用户，最后用户把通知当成背景噪声。
一个可靠策略要把失败分成三层：
- 可自动恢复：临时读取失败、一次性超时、可重试渲染。
- 需要复查：资料缺失、来源结构变化、产物字段不完整。
- 必须停手：越权访问、外部影响动作、覆盖或删除风险。
定时 Agent 的失败策略不是为了让系统显得复杂，而是为了让后台自动化不会悄悄变坏。
对用户来说，关键不是看到所有日志，而是知道：这次跑了吗、产物在哪里、失败属于哪类、谁要处理、是否影响下一次运行。
通知规则要少，但要硬
一条实用规则可以这样写：
Schedule: 每周一 09:00
Agent: 周报生成
成功: 只写入 run record，不推送
自动恢复: 重试一次，仍失败则进入复查
需要复查: 通知 Agent 负责人，保留半成品
必须停手: 进入 Trust Mode，暂停下一次同类动作
复盘: 周五汇总失败原因和产物质量
这比“失败就通知所有人”更专业。成功不要打扰，轻微失败可以自动恢复，重要失败要路由给 owner，高风险失败必须停下。
如果团队已经在用 Agent 运行状态，失败策略应该体现在 run state 里：状态、失败层级、产物路径、下一步动作。与 Workspace First Agent Delivery 一样，失败也应该留下可检查记录。
三步写清定时失败策略
- 先定义成功：成功时是否通知、产物写到哪里、run record 保留多久。
- 再定义失败分层：哪些自动恢复，哪些通知 owner，哪些进入 Trust Mode。
- 最后定义复盘：相同失败连续出现时，应该改资料来源、改 Schedule，还是改 Agent 工作流。
这三步让定时 Agent 失败策略变成可执行规则，而不是一句“失败后提醒我”。Axon Agent 的 Schedule 越常运行，这个规则越应该具体。
失败不是只给工程师看的
定时 Agent 的失败信息要让业务 owner 能看懂。不要只展示内部错误码，也不要把模型输出全部塞给用户。更好的信息是：“本次未生成完整周报，因为 2 个来源文件缺失；已保留摘要草稿；需要 owner 确认是否跳过缺失来源。”
失败也应该进入复盘
一次失败可能只是偶发；连续三次相同失败就是流程问题。复盘时不应该只问“模型为什么错”，还要问资料来源是否稳定、预检是否缺失、Schedule 是否太频繁、owner 是否收到正确通知。这里可以结合 Agent 运行复盘。
FAQ
Q1：定时 Agent 每次成功都要通知吗？
不一定。高频任务成功时只需要记录，低频或关键任务可以给摘要。通知应该服务判断，不是证明系统在运行。
Q2：失败后应该自动重试几次？
低风险临时失败可以重试一次或少量次数。涉及资料越权、外部影响或覆盖风险时，不应该自动重试。
Q3：失败产物要保留吗？
通常要保留。半成品、错误摘要和失败原因可以帮助 owner 判断是否重跑或修正资料。
Q4：谁接收失败通知？
优先通知 Agent 负责人，而不是整个团队。必要时再升级给构建者或管理员。
Q5：如何避免通知疲劳？
把成功、可恢复失败、需复查失败、必须停手失败分层。只有真正需要人处理的状态才推送。
下一步
开始使用 Axon 的 Schedule 前，先给每个定时 Agent 写一条失败策略。开始使用时定义成功是否通知、失败如何分层、谁接收、何时停手。了解更多时，重点看后台自动化如何可见地失败，而不是只追求安静运行。