别再让AI Agent裸奔cron：8条可靠性铁律

让AI Agent直接挂在cron上跑，就像让一个聪明但健忘的员工独自值夜班——平时没事，出事就是大事。我见过太多团队把精力花在对比GPT-5和Claude谁更聪明上，却让无人值守的任务靠运气运行。真正让Agent活下来的，不是更强的模型，而是把它当成无聊的后台任务来对待。

原文作者说得很直接：他做过最大的改进跟prompt毫无关系，而是停止把Agent当成魔法推理机器，开始当成普通的background job。这个思维转变修复的生产问题，比任何一次模型升级都多。

一句话架构：cron负责派活，不负责干活

核心原则只有一条：Cron should create work, not do work.

标准模式是——cron、GitHub Actions、webhook或n8n定时器只负责把任务丢进队列；队列持久化存储；worker执行Agent步骤；监控验证触发真的发生了；失败的任务要么重试，要么进死信队列。

不性感，但极其有效。如果你经历过同一个任务还在跑下一个就开始了、或者机器恰好在错误的时间重启，你就明白为什么“调度是一次请求，不是一份保证”。

坏模式是让cron直接跑完整Agent逻辑：*/15 * * * * node run-agent.js。好模式是只入队：*/15 * * * * node enqueue-agent-job.js，再由脚本写入BullMQ、SQS或Cloudflare Queues。如果你用n8n，queue mode本身就推着你往这个方向走——主进程管定时器和webhook，worker单独执行任务，比那些单进程demo工作流靠谱得多。

规则1-2：入队与幂等，别让LLM背锅

重复触发是幂等问题，不是AI问题

同一个任务触发两次时，很多人的第一反应是加AI逻辑判断。别这么干。重复抑制不是GPT-5该解决的问题，是幂等性问题。

最干净的修法是用业务派生的key，比如customer-123-daily-summary-2026-10-17、account-42-invoice-followup-2026-10-17、ticket-9981-first-response。这个key代表你只希望发生一次的业务事件。

BullMQ允许你在queue.add时传入jobId，相同ID在旧任务仍存在时会被忽略。但这里有个坑：去重只在旧任务还在时有效。如果你激进地清理已完成或失败的任务，去重窗口就跟着消失了。

方案	得到什么	失去什么
保留更多已完成/失败任务	更长的去重窗口	更多Redis存储压力
激进自动清理	更低存储成本	依赖队列历史时幂等变弱
独立幂等存储	强重复保护	更多活动部件

作者的判断是：如果副作用重要，就用独立的幂等记录。发邮件、扣款、建Zendesk工单、发Discord消息、写CRM——这些都值得一张agent_idempotency表，用insert ... on conflict do nothing判断是否已处理。队列历史有用，但不该是你唯一的记忆。

幂等性（Idempotency） 的核心定义是：同一个操作执行一次与执行多次，对系统状态产生的副作用完全相同。在分布式系统中，由于网络超时、重试、调度器抖动等原因，"至少一次"投递几乎是常态，因此幂等是保证正确性的基础手段。常见的实现路径有三类：一是数据库唯一约束（如 insert ... on conflict do nothing），二是业务派生的去重键，三是外部幂等服务（如支付场景中的幂等令牌）。需要区分的是，幂等与"去重"不完全等价：去重关注的是"不重复处理"，而幂等关注的是"重复处理也不破坏状态"。对于发邮件、扣款这类不可逆副作用，仅靠去重窗口并不可靠，必须落到独立的幂等记录上，才能跨越队列清理、进程重启等边界持续生效。

规则3-4：重试放对层，选你能运维的队列

在worker步骤里重试模型调用

重试是好事，但在错误的层重试就是灾难。作者推荐的分工是：编排层决定下一步做什么，worker步骤做非确定性工作，LLM调用和API调用发生在可重试的执行步骤内，副作用只在幂等检查之后发生。

这意味着GPT-5、Claude Opus 4.6、Grok 4.20、OpenAI兼容端点、CRM API、webhook，全都住在worker层，而不是某个“Agent大脑”里。

指数退避比很多人以为的更重要。BullMQ的指数退避公式是2 ^ (attempts - 1) * delay。基础延迟3000ms时，第7次尝试要等192秒，约3.2分钟。当OpenAI、Anthropic或你的CRM正在经历糟糕的一小时，你希望重试拉长到真实时间尺度，而不是每隔几秒猛锤供应商。

顺便说一句，如果你的Agent整天重试、扇出、总结、分类、恢复，按token计费会把可靠性工作变成预算问题。这正是flat-rate的OpenAI兼容基础设施对Agent密集型系统有吸引力的原因——你可以为健壮性而构建，而不用每次工作流多跑几次就盯着token账单。

选那个你凌晨2点能跑对的队列

人们爱问哪个队列或编排工具最好。真正的问题通常是：哪个是你们团队在凌晨2点还能正确运维的？

工具	适用场景
BullMQ	Node.js worker，需要自定义job ID、重试和Redis持久化
Temporal	多步骤Agent，确定性编排和activity级重试真正重要时
n8n queue mode	从n8n起步但需要真正worker分离的7×24自动化
AWS SQS	想要AWS原生托管队列
Cloudflare Queues	托管队列，批量处理和边缘友好架构

简单Agent，BullMQ + Redis + Healthchecks.io往往就够。如果Agent有长时间等待、分支逻辑、审批和多个外部系统，Temporal就从过度工程变成基本自尊。

Temporal 是一个持久化执行（durable execution）平台，与 BullMQ 这类任务队列的抽象层级不同。BullMQ 管理的是"作业"，重试以整个 job 为单位；Temporal 管理的是"工作流"，工作流代码本身被持久化，每个 activity（外部调用、LLM 调用）都有独立的超时、重试和状态记录，进程崩溃后可从断点恢复而非从头重跑。这让它天然适合有长时间等待、人工审批、多分支和多个外部系统的 Agent 编排。代价是概念更多（workflow、activity、task queue、determinism 约束），运维复杂度和学习曲线显著高于 Redis 队列。因此判断标准不是"谁更强"，而是团队是否具备在故障时定位工作流状态的能力——这正是"凌晨 2 点能跑对"的实际含义。

规则5-6：死信队列和心跳监控，缺一不可

死信队列不是可选项

只要你的Agent接触真实流量，就需要一个地方放毒任务——不是以后，是现在。因为有些失败是暂时的（限流、502、模型超时、临时网络故障），有些失败是永久的（畸形payload、账号已删除、不可能的状态、缺失必填字段）。它们不该待在同一个重试循环里永远转。

死信payload至少该包含：原始输入、错误类别、堆栈或失败原因、尝试次数、时间戳、来源队列名。作者的死信规则很清晰：网络和模型失败重试，畸形输入快速进死信，死信队列要在仪表盘可见，先手动重处理再考虑自动重处理。

如果死信队列变成一个没人看的坟场，你建的不是可靠性，是鸵鸟心态。

死信队列（Dead Letter Queue，DLQ） 源自消息队列的经典模式：当一条消息被消费失败达到最大重试次数，或无法被路由时，它不会被直接丢弃，而是转入一个专门的队列等待人工或程序化处理。DLQ 的价值在于把"暂时性失败"与"永久性失败"分流——前者在重试中自愈，后者被隔离以免阻塞正常流量、耗尽重试配额或掩盖真实故障。设计 DLQ 时有几个实践要点：死信消息应保留完整原始上下文（输入、错误类型、尝试次数、时间戳、来源队列），以便复现；DLQ 必须有监控和告警，否则会退化为无人问津的"坟场"；重处理应优先手动触发，确认根因修复后再考虑自动化，避免把同一批毒任务反复灌回主队列。

心跳监控抓的是日志抓不到的失败

这是团队最常跳过的一环。他们花几天对比GPT-5和Claude，然后让无人值守任务靠感觉运行。

Healthchecks.io是最简单的做法之一：在cron命令后追加curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here。这能抓住的远不止“cron有没有启动”，还包括机器宕机、cron守护进程问题、非零退出、任务运行过久、缺失成功完成。

无人值守Agent的最低监控清单：每个定时触发器一个心跳、队列深度告警、死信队列告警、worker错误率告警，以及“X小时内没有成功运行”告警。最后这条是杀手锏——很多Agent不会大声失败，它们只是悄悄停止做有用的事。

心跳监控（Heartbeat / Dead Man's Switch） 与常规指标监控方向相反：它不检测"是否出错"，而是检测"是否应该发生的事没有发生"。其原理是让任务在成功执行后主动向监控服务 ping 一次，监控端预设一个期望周期，一旦超过阈值未收到 ping 就触发告警。这种"反向监控"能捕捉日志和错误率指标天然漏掉的静默失败：cron 守护进程崩溃、机器宕机、任务卡死但未退出、非零退出码被吞掉、任务运行时间异常拉长等。对于无人值守的 Agent，静默停止往往比显式报错更危险，因为它不产生任何错误日志，团队可能数周后才通过业务数据发现。实现上，Healthchecks.io、Cronitor 等服务的 ping URL 即可满足最低需求，关键是每个定时触发器都要有独立的心跳，并配套"X 小时内无成功运行"的告警。

规则7-8：模型故障切换是策略，不是魔法

显式策略，而非prompt魔法

作者不希望worker哲学地决定哪个模型“感觉对”，他要规则。比如：GPT-5超时两次就路由到Claude Opus 4.6；Claude被限流就路由到Grok 4.20或Qwen；如果fallback模型改变了输出形状，副作用之前先校验schema。

故障切换逻辑放在worker的策略层，那里本来就有重试、超时和schema校验。写一个callModelWithFailover，按provider列表逐个尝试，每个带超时，成功后先validateResponseSchema再返回。如果你用OpenAI兼容工具，切换供应商不用重写整个应用，这让显式故障切换变得容易落地。

关键不是“用魔法路由”，而是：把模型选择变成运维策略，而不是隐藏行为。

这周就能上线的技术栈

如果要在周五前上线一个7×24无人值守Agent，作者会这么搭：触发层用cron、GitHub Actions、webhook或n8n定时器；队列层用BullMQ on Redis，或托管方案SQS/Cloudflare Queues；幂等用业务派生key；worker用无状态Node.js worker或n8n queue mode；重试用指数退避；死信隔离毒任务；健康检查用Healthchecks.io心跳加队列告警；模型故障切换用显式超时和fallback规则；计算层用不惩罚重试的OpenAI兼容端点。

项目结构也不复杂：enqueue/放入队脚本，workers/放worker，lib/放幂等、模型路由和schema，monitoring/放心跳脚本。这套栈不光鲜，这正是它值得信任的原因。

最后的提醒

大多数Agent内容都在谈记忆、规划、自主性和推理。这些当然重要。但一个平庸的Agent配上好的队列、幂等、重试和监控，会打败一个会重复运行、悄悄死掉、对副作用无限重试、周末消失的聪明Agent。

如果只记一句话：**先让Agent变得无聊，再让它变得聪明。**聪明是可选配置，无聊才是生产环境里的生存技能。

无论你是在n8n、Make、Zapier、OpenClaw^广告还是自建Node.js worker上构建Agent，先优化可靠性，再优化模型聪明度。当你那个“简单的cron Agent”第一次遇到真实流量时，这个取舍会变得一目了然。