定时 Agent 撞车，通常不是时间没排好这么简单

定时 Agent 冲突控制，是团队检查多个 Axon Agent 在 Schedule、资料刷新、workspace artifacts 和下游 Workflows 之间是否会互相踩踏的运营动作。没有这层控制，团队很容易每周重复处理同类低效问题：上游资料还没刷新，下游 Agent 已经开始写报告；一个 Agent 正在覆盖 artifact，另一个 Agent 正好读取旧版本；失败重试挤占下一个定时窗口，最后 owner 只能手动倒查，既耗时又容易出错。看起来只是时间没排好，实际是依赖没有被看见。

OpenAI Agents tracing 说明运行轨迹对理解 Agent 状态很重要；NIST AI Risk Management Framework 也把监测和治理纳入 AI 管理过程。Axon 的观点是：Schedule 不是 cron 表，Schedule 是工作流承诺。承诺里必须包括来源、产物、owner 和下游。

这篇文章连接 Agent 下游依赖检查、定时 Agent 失败策略、Agent 资料刷新窗口 和 Workspace Artifact Continuation。它用一个常见事故来说明：准时运行不等于正确运行。

一次典型撞车

周一 09:00，客户反馈采集 Agent 还在等待新 CSV。09:05，摘要 Agent 按时启动，读取了上周的反馈目录。09:10，报告 Agent 读取摘要 artifact，生成给管理层看的周报。09:30，owner 发现数字和客服系统不一致，所有人开始手动倒查。

没有任何一个 Agent 看起来“坏了”。每个 Agent 都按自己的 Schedule 运行。问题在于它们没有共享同一个依赖地图。

Schedule 冲突不是时间冲突本身，而是一个 Agent 以为前置条件已经满足，另一个工作流其实还没完成。

定时 Agent 冲突控制要先问四个问题：

• 上游资料什么时候才算可用？
• 中间 artifact 什么时候才算 accepted？
• 下游 Agent 是否允许读取 draft？
• 上游失败或延迟时，下游应该等待、跳过还是降级？

把时间表改成依赖表

只列运行时间是不够的。更有用的是把 Schedule 写成依赖表。

09:00 source-refresh-agent
requires: customer-feedback.csv uploaded
produces: workspace/sources/current-feedback/
accepted_by: support operations owner

09:15 feedback-summary-agent
requires: current-feedback accepted
produces: workspace/artifacts/weekly-feedback-summary.md
fallback: if source not accepted, stop as needs_source

09:30 leadership-report-agent
requires: weekly-feedback-summary accepted
produces: workspace/artifacts/leadership-report.md
fallback: if summary missing, publish no report and notify owner

这比“每 15 分钟跑一个任务”更可控。它让 Schedule 知道哪些 artifact 是草稿，哪些已经验收，哪些失败会影响下游。

三种常见冲突

1. 来源冲突：下游开始时，上游资料还没刷新。
2. artifact 冲突：一个 Agent 读取的产物还没 accepted，或正在被覆盖。
3. 恢复冲突：上游失败重试占用了下游窗口，导致下游读取半成品。

这些冲突都不应该靠人每天盯。它们应该变成 Schedule 的运行规则。

冲突后不要只改时间

很多团队遇到撞车后，会把下游任务往后挪十分钟。这有时有用，但不是根治。如果上游资料偶尔延迟半小时，挪十分钟没有意义。更可靠的做法是让下游检查前置 artifact 状态。

一个恢复规则可以很短：

if required_artifact.status != accepted:
  stop_state: waiting_dependency
  notify: report owner
  retry: once after 20 minutes
  after_retry: skip this run and record reason

这条规则让定时 Agent 冲突控制从“猜时间”变成“看状态”。它也避免下游为了准时而交付错误产物。

FAQ

Q1：定时 Agent 冲突控制是不是只要错开运行时间？

不是。错开时间只能解决一部分问题。更重要的是确认来源、artifact 和下游依赖是否达到可读取状态。

Q2：下游 Agent 可以读取 draft artifact 吗？

只有在工作流明确允许时可以。默认更稳的做法是读取 accepted artifact。

Q3：上游失败时下游应该自动继续吗？

通常不应该。应根据规则等待、跳过、降级或通知 owner。

Q4：冲突记录要保存多久？

重要 recurring workflows 应该保存。冲突记录能帮助团队调整 Schedule、来源窗口和恢复规则。

Q5：多个 Agent 共用同一个 artifact 怎么办？

要明确写入 owner、读取 owner、覆盖规则和版本复查方式，避免读写同时发生。

下一步

开始使用 Axon Schedule 前，为关键链路做一次定时 Agent 冲突控制：列出上游来源、中间 artifact、下游 Agent、accepted 状态和失败恢复规则。了解更多时，不要只看任务是否准时，也要看它是否在正确的依赖状态下运行；开始使用时，先让每个下游 Agent 学会等待正确的前置条件。