Agent连15分钟提醒都失败了：理解Agent故障恢复的关键

一个 15 分钟的提醒，听起来是 AI 任务里最简单的一种。

不是研究，不是编码，不是网页浏览。就是：15 分钟后提醒我。

然而这恰恰是很多 agent 容易挂的地方。

我在 r/openclaw 上看到一个帖子，发帖人很合理地抱怨他的助手在 15 分钟后没有发出提醒，这是压垮他的最后一根稻草。这种反应可以理解——如果一个 agent 连闹钟的活都干不了，凭什么信任它去做更难的事？

有趣的是，这通常不是模型的问题。

是架构的问题。

如果你的提醒依赖于 GPT-5、Claude、Grok、Qwen 或 Llama 以某种方式"在 15 分钟后醒来"，那你就不是在建一个提醒系统，而是在建一个乐观的幻觉循环。

错误：让 LLM 做调度器的工作

LLM 擅长语言。

它擅长把：

Remind me in 15 minutes to check the deploy

转换成这样的结构化数据：

{
  "reminder_text": "check the deploy",
  "remind_at": "2026-08-19T14:30:00Z"
}

但它不擅长：

拥有持久化的计时器

保证唤醒行为

这部分应该交给调度器。

整篇文章要说的就是这一句话：

用模型做意图提取。用确定性软件做时间管理。

真正的问题：谁拥有唤醒权？

这是大家容易跳过的部分。

必须有某个进程拥有这个定时器。

不是"agent 会话"。不是"对话状态"。不是"模型记忆"。

Postgres + pg_cron

如果没有调度器拥有唤醒权，你的提醒就是建立在感觉之上的。

OpenClaw：好的原语，但在很多设置里用了错误的心智模型

OpenClaw 可以正确地实现这一点，但前提是你要把 Automations 作为数据源。

一次性提醒应该长这样：

openclaw automations create "2027-02-01T16:00:00Z" \
  --name "Reminder" \
  --session main \
  --system-event "Reminder: check the automations docs draft" \
  --wake now \
  --delete-after-run

这是好的设计，因为调度器拥有执行权。

模型提取意图。自动化运行时拥有计时器。

这种分离很重要。

很多人仍然把 agent 运行时当作模型本身在后台保持着时间。不是的。如果负责调度的进程没有在运行，提醒就不会触发。

那不是 AI 故障。是系统故障。

为什么 n8n靠"无聊"赢了这个领域

我个人最喜欢的提醒工作流方案还是 n8n。

不是因为它花哨。是因为它在正确的地方足够无聊。

Wait 节点才是关键功能。

一个简单的 n8n 提醒流程是这样的：

接收 webhook、Slack 消息、Discord 命令或应用事件

用 GPT-5 或 Claude 解析提醒请求

转换成具体的时间戳

将执行送入 Wait

在正确的时间恢复

Example n8n flow shape

Webhook -> LLM Parse -> Set Fields -> Wait -> Slack/Email/SMS

我喜欢 n8n 的地方在于，暂停的工作流被当作工作流状态来对待，而不是模型状态。

这是正确的抽象。

如果你在为真实用户构建自动化，提醒应该能扛住：

临时的 API 故障

n8n 擅长这些，因为它做事像工作流软件，而不是聊天 demo。

如果你不想用 n8n，用 Postgres

如果你的应用已经跑在 Postgres 上，pg_cron 是一个非常体面的方案。

有时候人们把 Postgres 调度当作 hack。不是的。对于确定性任务执行， Postgres 通常比一个半吊子的 agent 运行时更可信。

Example: scan for due reminders every minute

SELECT cron.schedule(
  'process-reminders',
  '* * * * *',
  $$CALL process_due_reminders();$$
);

然后你的应用逻辑可以这样做：

SELECT id, user_id, reminder_text, remind_at
FROM reminders
WHERE remind_at <= NOW()
  AND sent_at IS NULL;

UPDATE reminders
SET sent_at = NOW()
WHERE id = $1;

这就是无聊。持久化的无聊。恰好是提醒系统需要的品质。

如果你的产品已经有数据库，这种架构通常比试图保持一个长时间运行的 agent 会话存活更简洁。

模型仍然重要，只是不负责计时

这是人们容易矫枉过正的地方。

是的，模型质量很重要。

一个弱的模型可能会误读：

remind me after standup

但那是解析问题，不是调度问题。

用一个强模型做提取，然后让它退出这个循环。

Example: structured output with the OpenAI-compatible API

Since Standard Compute is a drop-in OpenAI API replacement, the same pattern works with existing OpenAI SDKs while giving you predictable flat-rate usage for agent workflows.

import OpenAI from "openai";
import { z } from "zod";

const client = new OpenAI({
  apiKey: process.env.STANDARD_COMPUTE_API_KEY,
  baseURL: "https://api.standardcompute.com/v1"
});

const ReminderRequest = z.object({
  reminder_text: z.string(),
  remind_at: z.string()
});

const response = await client.responses.create({
  model: "gpt-5.4",
  input: "Remind me in 15 minutes to check the deploy"
});

In practice, you'd validate the model output against a schema and then hand the timestamp to your scheduler.

重要的是架构层面：

调度器存储定时器

投递系统发送通知

一旦 remind_at 被提取出来，模型的工作基本上就结束了。

一个可以真正发货的简单实现模式

这是我实际会发货的版本。

Step 1: parse the request

type ReminderRequest = {
  reminder_text: string;
  remind_at: string;
};

Step 2: store durably

INSERT INTO reminders (user_id, reminder_text, remind_at, sent_at)
VALUES ($1, $2, $3, NULL);

Step 3: let a scheduler own execution

Google Calendar event with reminder

Zapier or Make delay/schedule step

Step 4: send and mark complete

UPDATE reminders
SET sent_at = NOW()
WHERE id = $1;

这就是整个系统。

没有模型记忆。没有神奇的唤醒行为。不指望 agent 之后会想起来。

Google Calendar 比人们承认的更靠谱

对于个人提醒，Google Calendar 被低估了。

如果目标是"可靠地在我的手机上通知我"，Google Calendar 已经解决了很多困难的 UX 和投递问题。

有时候正确的 AI 架构是：

app 创建日历事件

Google 发送提醒

这不是不 sophistication。这是更诚实。

很多"AI 原生"提醒系统只是已有软件的更差版本。

该信任哪个方案？

对于个人助手提醒，Google Calendar 是最容易的方案

对于工作流自动化，n8n 是最干净的答案

对于后端产品，Postgres 比人们给它的评价更好

对于 agent 构建者，调度器应该始终比模型优先级高

为什么这个微小的故障很重要

一个被漏掉的 15 分钟提醒听起来微不足道。

它暴露了你的 agent 技术栈是否理解以下区别：

推理 vs 执行

意图提取 vs 持久化调度

"模型说它会做" vs "系统拥有这个工作"

如果你的系统不能可靠地在 15 分钟后唤醒，我不会信任它来处理：

长时间运行的自动化

提醒 bug 是架构泄漏。

它们告诉你系统在哪里在装。

如果你在构建提醒功能，这是我会推荐的模式：

用 GPT-5 或 Claude 提取 reminder_text 和 remind_at

把时间戳存储在持久化状态中

把执行交给 n8n、OpenClaw Automations、Zapier、Make、Google Calendar 或 Postgres

把调度器当作数据源

围绕重试、持久化和幂等性构建故障恢复

如果你在运行大量 agent 工作流，这也是定价开始变得重要的地方。

提醒解析听起来很便宜，直到你有成千上万的自动化、重试、跟进和全天候 agent 一直在调用模型 API。这正是为什么固定费率基础设施有吸引力的原因：你可以让 agent 持续运行，而不用像盯鹰一样盯着 token 计量表。

这就是 Standard Compute 的角度，我认为更多开发者应该关注。它是 OpenAI 兼容的，所以你可以保留现有的 SDK 和工作流，但当 agent 一直在运行时，经济模型比按 token 计费更适合自动化。

不过架构教训仍然是重点：

不要让 Grok、Qwen、Claude 或 GPT-5 做 cron 的工作。

用模型理解请求。用软件记住它。