Cron 驱动的 Agent：你睡觉时自动运行的工作流
2026 年怎么建按计划自主运行的 cron 驱动 AI Agent：架构、幂等性和失败处理，以及常驻自动化的成本陷阱。
TL;DR — Cron 驱动的 Agent 按计划运行，而不是等你提示——日报、监控、周期性研究。架构很简单（调度器触发 Agent 运行），但难的是幂等性（跑两次怎么办？）、失败处理（凌晨 3 点 LLM 宕机怎么办？）、成本控制（每分钟醒一次的 Agent 很快变贵）。下面讲怎么建一个不会拿账单吓到你的。
从被动到主动的转变
大多数 Agent 是被动的：你问，它答。Cron 驱动的 Agent 反转了这个——它按计划醒来，没人提示就干活。建一个 cron 驱动的 Agent，你就从”你操作的工具”变成”你不在时处理事情的同事”。
我建过或见过效果好的具体例子：
- 早 7 点的 Agent 读隔夜的 GitHub issue、分类、把摘要发到 Slack
- 每夜的 Agent 回顾当天工作、整合记忆（这本质上就是 Anthropic 的 “Dreaming” 做的）
- 每周的 Agent 研究一个主题、起草一份报告
- 监控 Agent 每 15 分钟查一个指标，只在出问题时 ping 你
Hermes Agent 把 cron 系统作为五大支柱之一，正是因为计划性自主是助手区别于工具的地方。我们来建这个模式。
基本架构
最简单地说，cron 驱动的 Agent 就是一个调度器加一次 Agent 运行：
调度器 (cron) ──> 触发 ──> Agent 运行 ──> 动作 (Slack 发帖、邮件等)
│ │
│ └──> 把结果持久化到记忆
└──> 下一个计划时间调度器可以是字面意义的 cron、云调度器、或框架内建的 cron（比如 Hermes 的）。它触发时，启动一次带预定义任务的 Agent 运行（“总结隔夜 issue”），Agent 用它有的工具干活、采取动作、持久化任何值得记的东西。
# 一个 cron 驱动的 Agent 定义
jobs:
- name: morning-triage
schedule: "0 7 * * *" # 每天早 7 点
task: |
读取昨天下午 6 点以来开的 GitHub issue。
按严重程度分类。把摘要发到 #eng-standup。
tools: [github, slack]
model: anthropic/claude-sonnet-4这是 happy path。现在讲真正要紧的部分。
幂等性：跑两次怎么办？
调度器会重试。网络会打嗝。如果第一次运行超时、调度器重试，你的早 7 点任务可能触发两次。如果你的 Agent 不幂等，那意味着两条 Slack 帖、两封邮件，或更糟——两次购买、两次部署。
设计每个 cron Agent 时都假设它可能为单个计划时段运行不止一次：
- 用幂等键。 给每次计划运行打一个唯一键（如
morning-triage-2026-06-04）。动作前先查这个键是否已完成。 - 让动作 check-then-act。 “如果今天还没发过就发摘要”胜过”发摘要”。
- 把计算和副作用分开。 Agent 可以安全地重跑推理；只把不可逆动作（Slack 发帖）卡在幂等检查后面。
这是 cron Agent 在生产里出错最常见的方式。Agent 逻辑没问题，它只是跑了两次、重复发帖了。
失败处理：凌晨 3 点 LLM 宕机怎么办？
被动 Agent 的失败是可见的——你就坐在那，看到报错。Cron Agent 在你睡觉时凌晨 3 点静默失败。你直到早晨摘要没来才发现。
为无人值守的失败而建：
- 带退避的重试应对瞬时错误（供应商 503、超时）。但要封顶——别对一个畸形请求错误永远重试。
- 死人开关。 如果一个该每天跑的任务 25 小时没成功，告警。成功的缺席才是信号，不是错误的出现。
- 供应商故障转移。 单供应商 Agent 在那个供应商凌晨 3 点宕机时就死了。这就是带自动故障转移的 LLM 网关赚回成本的地方——一个供应商宕机，运行路由到另一个而不是失败。
# Cron Agent 指向带故障转移的网关
OPENAI_API_BASE=https://api.sandbase.ai/v1
OPENAI_API_KEY=your-sandbase-api-key
MODEL=anthropic/claude-sonnet-4用 SandBase，凌晨 3 点的供应商宕机不会杀死你的每夜任务——流量自动故障转移。对无人值守的自动化，这种韧性是”跑得好好的”和”静默坏了一周”的区别。
成本控制：常驻的陷阱
账单惊吓场景：你设一个监控 Agent 每分钟跑一次，每次运行加载 3000 token 上下文并调用前沿模型，一个月后你盯着一张惊人的发票。一个一天醒 1440 次的 Agent 累积起来很可观。
怎么让 cron Agent 便宜：
- 把计划调到合适大小。 它真需要每分钟跑，还是每 15 分钟？大多数监控容忍比你下意识设的更粗的间隔。
- 日常运行用便宜模型。 每夜摘要不需要你最贵的模型。把计划性的体力活路由到预算模型，把强模型留给推理质量要紧的时候。
- 削减上下文。 Cron Agent 经常每次运行重载同样臃肿的上下文。只加载任务需要的。（记忆架构指南里的分层记忆方法在这适用——只要温上下文，除非需要否则跳过昂贵的冷查询。）
- 尽早短路。 监控 Agent 应该便宜地查”有什么不对吗？“再启动昂贵的推理。大多数运行应该几乎啥也没干就早退。
把计划性工作通过 SandBase 路由，让你给高频任务分配便宜模型、给偶尔的重任务分配强模型，全在同一套配置里。
一个把它串起来的模式
在生产里好用的 cron Agent 有共同的形状：一个便宜快速的”我该做点什么吗？“检查频繁运行，只在有必要时升级到昂贵推理。只在指标出问题时 ping 你的监控 Agent 是经典例子——99% 的运行是便宜的空操作，1% 是真告警。
这让成本跟实际事件成比例，而不是跟计划频率成比例，这正是常驻自动化的全部要义。
FAQ
Q：cron Agent 和普通定时脚本有什么区别？
定时脚本跑固定代码。cron Agent 按计划跑一个 LLM 推理循环——它能适应它发现的东西、动态用工具、做静态脚本做不了的判断。代价是它不那么可预测，且每次运行烧 token。
Q：怎么阻止 cron Agent 做两次同样的事？
幂等键。给每次计划运行打唯一标识，采取任何不可逆动作前查它是否已完成。把副作用（发帖、邮件、购买）卡在那个检查后面，即使你让推理自由重跑。
Q：任务触发时我的 LLM 供应商宕机了怎么办？
单供应商时任务静默失败。用带自动故障转移的 LLM 网关（如 SandBase），让运行路由到另一个供应商而不是死掉。再加个死人开关，在预期运行没成功时告警。
Q：怎么让计划性 Agent 不变贵？
把计划调到合适大小（每 15 分钟胜过每分钟）、日常运行用便宜模型、削减每次加载的上下文、尽早短路让大多数运行几乎啥也不做。成本应该跟真实事件走，不是跟计划频率走。
Q：现有框架能做这个，还是我得自己建？
Hermes Agent 有内建 cron 系统。其他的，你可以把调度器（系统 cron、云调度器）和 Agent 运行配对。调度是简单的部分——幂等性、失败处理、成本控制才是你真正需要设计的。
