Apify Tasks 与 Schedules：把一次成功运行变成可复查流程

证据口径：本页于 2026-07-30 按 Actor tasks、Schedules 与 Webhook events 官方文档核对。本页没有新建本站账户里的 Task 或 Schedule，也不声称完成新的实测。

Task 与 Schedule 解决的是两个不同问题：

对象	它保存什么	什么时候用
Actor	程序、版本、输入输出规则	决定“用哪个工具”
Task	某个 Actor 的一套可复用输入与运行选项	决定“用什么配置跑”
Schedule	触发时间、时区以及要运行的 Actor/Task	决定“什么时候跑”

不要把第一次试跑直接设成每天运行。先验证小样本，再把那套输入保存成 Task；Schedule 只负责触发，不会自动判断结果是否仍然有业务价值。

从一次成功运行到定时任务

1. 缩小输入：用人工能检查完的小样本跑通 Actor。
2. 核对三件事：Dataset 的关键字段、Runs 中的状态、Billing 中的实际费用。
3. Save as new task：给 Task 起能说明目标与地区的名字，例如 shanghai-coffee-leads，不要用 test-2。
4. 再运行 Task 一次：确认保存后的输入没有丢字段，运行选项与第一次一致。
5. 创建 Schedule：选择 Task、时区和 cron/频率；先用较低频率观察。
6. 定义验收：每次运行至少检查状态、结果量、关键字段空值与费用。

启用前，先核对未来五次

按当前官方文档，新建 Schedule 默认是 Disabled。配置 cron 和时区后，先在 Next runs 展开未来五次触发时间，逐项核对日期、星期和业务时区；若跨越夏令时切换，也要确认显示时间符合预期。确认无误后再 Enable，不要把“已经创建”当成“已经运行”。

Schedule 支持时区和夏令时变化，但触发仍可能因系统负载或服务器关闭而延迟。它适合周期采集，不适合承诺某一秒必定启动的实时 SLA。

频率不是越高越好

数据变化速度	起步频率	先观察什么
商家资料、类目名单	每周或每月	新增、关闭、电话/网站变化
商品价格和库存	每日或按业务窗口	同一 SKU 的时间戳、价格与卖家
搜索结果、广告素材	每周	查询环境是否一致、素材是否真变化
临时研究样本	手动运行	是否值得建立持续监控

频率应由决策周期决定，而不是由 Schedule 能不能做到决定。没有人会查看的每日结果，只是在制造费用和存储。

运行前要固定的输入

• 目标 URL、关键词、地区、语言和设备环境。
• 结果上限与翻页范围。
• Actor build/version 策略与运行超时。
• 输出必须保留的来源 URL、查询条件和采集时间。
• 费用上限或人工审批点。

Schedule 可以覆盖 Actor/Task 的部分输入，但这会让“控制台里保存的 Task”与“实际定时跑的输入”不一致。若必须覆盖，记录覆盖字段，并在变更后重新小样本验证。

失败不只等于红色状态

信号	可能原因	处理
Run failed / timed out	目标站变化、输入扩大、资源不足	读日志，缩小输入，避免盲目重复触发
Succeeded 但 0 条	查询无结果、登录/地区变化、Actor 失效	用已知会返回的最小输入复测
条数骤降	页面结构、过滤条件或分页改变	抽查原始 URL 与字段，不只看总数
费用骤升	新计费事件、数量或重试增加	暂停 Schedule，回到 Pricing 与 Billing 对账
重复写入下游	webhook/工作流重试没有幂等键	用 Run ID + item 标识去重

两层告警，不能互相替代

层级	当前机制能告诉你什么	仍要自己检查什么
Schedule 通知	官方当前明确说明：配置错误导致 Actor / Task 无法启动时会发邮件	不能据此推断 run 已完成或数据合格
Run webhook	可订阅 Succeeded、Failed、Aborted、Timed out 等运行事件	只覆盖已订阅的事件，不检查输出内容
业务验收	由你的检查规则判断结果是否可用	结果数、关键字段空值、异常波动、费用与下游去重

自动化的完成标准不是“Schedule 显示 Enabled”或 webhook 收到 Succeeded，而是每次运行都能被定位、对账和解释，数据也通过业务验收。