事件驱动 vs 定时调度智能体:哪种场景用哪种模式
当用户操作需要即时响应时,使用事件驱动智能体——超过几秒的延迟就会破坏体验。对于时机可预测的批量或周期性工作,使用定时调度智能体。约束:事件驱动智能体必须无状态且快速;定时调度智能体可以有状态且较慢。
每周三。28,400+ 读者。纯干货。
✓ Check your inbox — click the confirmation link to complete sign-up.
✓ You're subscribed!
✓ You're already on the list.
目录
2026年5月更新。
TL;DR: 当用户操作需要即时响应时,使用事件驱动智能体——超过几秒的延迟就会破坏体验。对于时机可预测的批量或周期性工作,使用定时调度智能体。约束:事件驱动智能体必须无状态且快速;定时调度智能体可以有状态且较慢。
[运营者视角] 我在咨询品牌和 Pickleland(德克萨斯州 Pflugerville 的匹克球场馆)中运行超过 30 个生产环境智能体。每一个都属于两种模式之一:由事件触发,或由时钟触发。搞错这点会浪费金钱,并交付糟糕的用户体验。
两种模式的通俗解释
事件驱动智能体因为某件事发生而醒来。来了一笔预订。发布了一条评论。提交了一个表单。触发器是外部的,时机不可预测。任务:快速响应。
定时调度智能体因为时钟说了而醒来。每天早上7点。每个周日下午6点。每小时整点。触发器是内部的,完全可预测。任务:做扎实的工作。
就这些。别过度复杂化。架构来自一个问题的答案:用户或系统现在立刻需要响应,还是可以等到特定时间?
事件驱动:社交评论回复智能体
每当监控的 Facebook 帖子上出现新评论,我的社交回复智能体就会触发。智能体读取评论,分类意图(问题、投诉、称赞、垃圾),起草回复并发布——如果置信度低则标记供人工审核。
整个往返必须在 30 秒内完成,否则回复会显得过时。这是一个事件驱动问题。
以下是处理社交监控服务 webhook 的简化版 Cloudflare Worker:
// workers/social-reply.ts
export default {
async fetch(request: Request, env: Env): Promise<Response> {
if (request.method !== "POST") {
return new Response("Method not allowed", { status: 405 });
}
// 验证 webhook 签名
const sig = request.headers.get("x-webhook-signature") ?? "";
const body = await request.text();
const valid = await verifySignature(body, sig, env.WEBHOOK_SECRET);
if (!valid) return new Response("Unauthorized", { status: 401 });
const event = JSON.parse(body) as SocialCommentEvent;
// 分类并回复 — 保持异步以便快速返回 200
env.REPLY_QUEUE.send(event);
return new Response("OK", { status: 200 });
},
};
// 队列消费者 — 执行实际的 AI 工作
export const queue: ExportedHandlerQueueHandler<Env, SocialCommentEvent> =
async (batch, env) => {
for (const msg of batch.messages) {
const comment = msg.body;
const classification = await classifyComment(comment.text, env);
if (classification.intent === "spam") {
msg.ack();
continue;
}
const reply = await draftReply(comment, classification, env);
if (classification.confidence > 0.85) {
await postReply(comment.postId, comment.id, reply, env);
} else {
await flagForReview(comment, reply, env);
}
msg.ack();
}
};注意两件事。第一,fetch 处理器立即返回 200,并将实际工作卸载到队列。这保持了 webhook 响应速度,防止监控服务重试。第二,队列消费者执行实际的 AI 调用——分类和起草——没有来自打开的 HTTP 连接的时间压力。
定时调度:Pickleland 活动推广智能体
Pickleland 管理场地和活动。每周都需要有人将即将举行的活动推送到合适的 Facebook 群组来填满席位。这是纯粹的周期性批量工作——没有用户操作触发它,也不需要实时发生。
Pickleland 活动推广智能体在 cron 上运行,检查预订系统中未来 4 天的活动,为每个匹配的 Facebook 群组起草特定帖子,并在任何内容发布前提交供我审核。
// workers/event-promoter.ts
export default {
async scheduled(
event: ScheduledEvent,
env: Env,
ctx: ExecutionContext
): Promise<void> {
ctx.waitUntil(runPromoter(env));
},
};
async function runPromoter(env: Env): Promise<void> {
// 从预订系统获取活动
const upcomingEvents = await fetchUpcomingEvents(env, { daysAhead: 4 });
if (upcomingEvents.length === 0) return;
const drafts: PromoDraft[] = [];
for (const event of upcomingEvents) {
// 将每个活动与合适的 FB 群组匹配
const groups = await matchFacebookGroups(event, env);
for (const group of groups) {
const post = await draftPromoPost(event, group, env);
drafts.push({ event, group, post });
}
}
// 将草稿保存到 Airtable 供审核 — 没有任何内容自动发布
await saveDraftsForReview(drafts, env);
// 通过 Slack 通知我
await notifyOperator(
`${drafts.length} 份推广草稿等待审核`,
env
);
}将一切串联起来的 wrangler 配置:
# wrangler.toml
[[triggers]]
crons = ["0 18 * * 0"] # 每周日 18:00 UTC注意定时调度智能体能做而事件驱动不能做的:遍历多个活动,写入数据库,发送摘要通知。它在做批量工作。事件驱动智能体需要保持精简并快速响应。
定时调度:每日简报
每天早上 7 点,我的每日简报智能体运行。它拉取隔夜邮件、我的日历、最重要任务,以及我标记为相关的新闻。将所有内容格式化成单一文档并放入我的 AI Workspace 文件夹。
这是纯调度型。没有任何事件会触发它——我只是每天早上开始工作前需要它。
// workers/daily-brief.ts
export default {
async scheduled(
event: ScheduledEvent,
env: Env,
ctx: ExecutionContext
): Promise<void> {
ctx.waitUntil(buildDailyBrief(env));
},
};
async function buildDailyBrief(env: Env): Promise<void> {
const [emails, calendar, tasks] = await Promise.all([
fetchOvernightEmails(env),
fetchTodayCalendar(env),
fetchTopTasks(env),
]);
const brief = await synthesizeBrief({ emails, calendar, tasks }, env);
await writeToWorkspace(brief, env);
}[[triggers]]
crons = ["0 7 * * *"] # 每天 7:00 UTC并行的 Promise.all 是刻意为之的。定时调度智能体没有等待的人——但它们仍然不应该比必要的更慢。并行获取所有数据源,然后进行一次 AI 合成。
事件驱动何时会失败
我最常见的失败模式:有人构建了一个在处理器中做太多工作的事件驱动智能体。
一笔预订进来。智能体获取客户资料,从三个外部 API 丰富它,运行个性化模型,写入 CRM,发送确认邮件,并更新仪表板。整个过程需要 45 秒。预订平台重试,因为没有足够快地收到 200。现在智能体运行了两次。
修复方式与社交回复智能体相同:立即返回 200,将事件推送到队列,让队列消费者异步处理繁重工作。
另一个失败模式:将事件驱动用于实际上是周期性的工作。“发送每周摘要”不是一个事件。不要将其连接到合成的 cron webhook——使用适当的定时触发器。
定时调度何时会失败
当工作实际上对延迟敏感时,定时调度智能体会失败。如果用户提交表单而处理智能体在 5 分钟 cron 上运行,用户最多会盯着加载指示器看 5 分钟。这不是定时作业——这是伪装成定时的慢速事件驱动作业。
另一个失败:扩展到无限工作的定时调度智能体。如果你的 cron 每分钟运行一次,每次调用可以处理数百条记录,你会很快达到 Cloudflare 的 CPU 限制。要么增加 cron 间隔,添加队列以限制每次调用的工作,要么切换到 Durable Objects 进行长时间运行的协调。
混合模式:预订流水线
一些工作流确实需要两者兼备。Pickleland 预订流水线的工作方式是:
- 事件驱动:新预订 webhook → 确认预订,向客户发送收据,更新可用性。必须在 10 秒内完成。
- 定时调度:每周日 → 审查上周所有预订,生成摘要报告,标记异常(重复预订、异常取消率)。
相同领域,两种模式,两个智能体。事件驱动拥有实时用户体验。定时调度拥有每周运营审查。它们共享一个数据库,但别无其他。
不要试图将它们合并为一个”做所有事情”的智能体。你最终会得到一个对于事件来说太慢、对于批量工作来说与实时流程耦合太紧的东西。
Cloudflare Workers:为何是两者的正确基础设施
Cloudflare Workers 原生支持两种模式:
fetch处理器 → 事件驱动(webhooks、API 调用)scheduled处理器 → cron 调度(通过 wrangler.toml 中的[[triggers]])queue消费者 → 与 HTTP 层解耦的异步处理
边缘部署意味着你的事件驱动智能体在全球范围内快速响应。免费层足够慷慨,可以在不花费任何费用的情况下原型化两种模式。统一的 wrangler.toml 配置意味着你不需要为两种模式管理两套独立的基础设施配置。
Workers 不能很好解决的一件事:需要运行超过几分钟的智能体。对于这些,使用 Durable Objects 或将工作委托给更长时间运行的后端。
运营者的结论
在写一行智能体代码之前先选定模式。事件驱动适用于人在等待的任何事情;定时调度适用于按时钟运行的任何事情。保持事件驱动处理器精简——快速返回,将工作入队。保持定时调度智能体并行——不要将可以并行化的东西序列化。架构很简单。违反它就是复杂性的来源。
每周三。28,400+ 读者。纯干货。
✓ Check your inbox — click the confirmation link to complete sign-up.
✓ You're subscribed!
✓ You're already on the list.
将AI实战手册发送到您的邮箱
每周三。28,400+ 读者。纯干货。
Check your inbox.
We sent you a confirmation email — click the link inside to complete your subscription. Check spam if you don't see it within a minute.
You're subscribed.
Welcome — the next edition lands in your inbox soon.
You're already on the list — look for it every Wednesday.