定时 AI 数字员工治理：自动执行、状态监控与风险控制
定时AI数字员工 很容易被误解成“设置一个时间，让 Agent 自动跑”。真实企业场景更复杂：每天数据可能缺失，每周模板可能更新，月末任务可能涉及外发和审批，失败后还要有人知道该重跑、跳过还是升级处理。否则，自动化会把重复、手动、耗时的问题变成更隐蔽的风险。OpenAI Codex 文档展示了后台、并行和云环境任务的 Agent 工作方式，这类长期运行能力提醒我们：越能自动执行，越需要治理机制。参考 Codex documentation。
定时不是治理，定时只是触发器
定时器只能回答“什么时候运行”，不能回答“运行前输入是否完整、运行中状态是什么、运行后谁验收、失败时怎么办”。定时AI数字员工 必须有运行日历、输入检查、状态记录、产物验收和升级规则。没有这些规则，团队只是在把人工盯任务换成事后查事故。
Axon 里，Agent 负责周期执行逻辑，Skills 负责稳定动作，workspace 保存产物，Trust Mode 处理高风险确认。可以先读 定时执行与人工验收文章，再结合 Trust Mode 邮件确认边界 设计风险动作。
定时任务的目标不是“无人看管”，而是“该自动的自动，该确认的确认，该升级的升级”。
运行日历：把时间、输入和验收写在一起
定时AI数字员工 的运行日历不应该只有 cron。它还应写明输入来源、截止时间、预检查、产物、验收人和失败策略。
run_calendar:
name: weekly-market-risk-brief
cadence: every_monday_08_30
input_cutoff: sunday_22_00
preflight:
- source_links_available
- previous_week_brief_exists
- output_template_exists
artifacts:
- sources.md
- risk-table.xlsx
- brief-draft.md
reviewer: research_lead
failure_policy:
missing_input: skip_and_notify
skill_error: retry_once
high_risk_output: require_approval
- 第一步：把触发时间和输入截止时间分开，避免边跑边等资料。
- 第二步：运行前做 preflight，缺资料时不要硬跑。
- 第三步：产物命名固定，方便每周对比。
- 第四步：失败原因分类，不要只显示“任务失败”。
- 第五步：每周复盘一次跳过、重试和人工修改记录。
失败策略：跳过、重试还是升级
跳过
当关键输入缺失、模板不存在或验收人未配置时，应跳过并通知负责人。继续运行只会产生不可用产物。
重试
当网络、临时接口或非关键 Skill 出错时，可以重试一次。若重复失败，应保存日志并进入人工处理。
升级
当输出涉及外发、发布、覆盖、敏感数据或业务判断时，必须升级到人工确认。若流程需要从零搭建，可参考 AI Build 组装第一个 Agent；涉及 PDF 和邮件时可看 Research PDF Email Agent 工作流。
| 情况 | 默认动作 | 记录内容 |
|---|---|---|
| 输入缺失 | 跳过并通知 | 缺哪个字段 |
| 临时失败 | 重试一次 | Skill 和错误信息 |
| 风险动作 | 等待确认 | 审批人和原因 |
| 连续失败 | 升级负责人 | 最近三次 runId |
FAQ
Q1: 定时AI数字员工 可以完全无人值守吗？
低风险任务可以逐步减少人工参与，但高风险动作仍应确认。治理目标是减少无意义盯守，不是取消责任边界。
Q2: 定时任务失败后是否应该自动重跑？
不一定。临时技术失败可以重试，输入缺失应跳过并通知，高风险结果应等待人工判断。
Q3: 运行日历需要谁维护？
业务负责人负责节奏、输入和验收，运营或管理员负责状态和失败策略。两者缺一不可。
Q4: 怎样判断定时任务是否值得长期运行？
看四个指标：人工节省时间、失败率、人工修改比例、业务产物是否真的被使用。只看运行次数没有意义。
下一步
开始使用 Axon 时，为一个每周任务补上运行日历和 failure_policy，再连续观察三次运行。了解更多 Agent 与 Trust Mode 后，把定时AI数字员工 做成可治理的运营流程，而不是孤立的自动提醒。