事件驱动 AI Agent 是什么？
事件驱动的 AI Agent 不会不断轮询等待工作。它会等待一个信号——API 请求、定时器、文件存入存储、队列中的消息——然后做出反应。
这种模型是构建高性价比、响应迅速且可扩展的 Agent 的基础。Agent 只在实际有工作需要处理时才运行，而不是为空闲算力付费。事件驱动 Agent 将算力成本变成了与工作负载直接相关的可变支出。
事件驱动 Agent 的构成
核心上，事件驱动 Agent 有三个组件：
事件源
信号的来源。常见的事件源包括：
- Webhook。 外部服务在特定事件发生时发送 HTTP 回调——支付完成、代码仓库推送、表单提交。
- 消息队列。 服务将消息发布到队列，Agent 按能力消费。这使 Agent 与生产系统解耦，在流量高峰提供缓冲。
- 数据库变更流。 数据库记录的变更——插入、更新、删除——流式传输到 Agent，实现响应式数据处理。
- 定时器。 按特定间隔或绝对时间触发的时间触发器（详见定时运行的 AI Agent）。
- 其他 Agent。 Agent 可以发出事件触发其他 Agent，实现多步协调。
触发逻辑
Agent 必须决定是否对给定事件采取行动以及如何解读它。包括：
- 过滤：忽略不需要行动的事件。
- 补充：在开始主工作流前拉取额外上下文。
- 路由：将事件导向 Agent 内正确的处理器。
执行处理器
处理事件并产生结果的 Agent 工作流。处理器调用语言模型、执行工具、存储结果，并可能为下游消费者发出新事件。
关键点是分离：Agent 不管理事件源。它接收事件并做出反应。这让事件驱动 Agent 天然可组合——你可以串联它们、扇出到多个 Agent、或插入处理步骤，而无需修改 Agent 本身。
事件驱动 Agent 实际如何工作
考虑一个事件驱动的内容审核 Agent：
- 用户上传图片到存储桶。
- 存储系统发出"文件已创建"事件。
- Agent 接收事件，获取文件，通过审核模型运行。
- 如果内容被标记，Agent 发送通知并将文件移至人工审核队列。
- 如果内容安全，Agent 更新数据库记录并发出"内容已批准"事件供下游系统使用。
Agent 只在第 3 到 5 步运行。两次上传之间，算力成本为零。如果上传量从每小时 10 次激增到每小时 10,000 次，Agent 自动扩容——每个上传事件触发一次独立执行。
事件驱动 vs. 定时 Agent
| 维度 | 事件驱动 | 定时 |
|---|---|---|
| 触发来源 | 外部信号（Webhook、队列、流） | 基于时间（cron、间隔） |
| 算力成本 | 空闲时为零；按事件付费 | 无论有没有工作都运行 |
| 延迟 | 事件发生后即时反应 | 最多一个间隔的延迟 |
| 工作负载模式 | 可变，不可预测 | 固定，可预测 |
| 最适合 | 实时工作流 | 批处理 |
许多生产系统两者兼用：定时 Agent 每五分钟运行健康检查，事件驱动 Agent 处理实时用户交互。
事件驱动 Agent 设计模式
扇出模式
一个事件并行触发多个 Agent。"新订单"事件可同时触发支付处理 Agent、库存更新 Agent、物流安排 Agent 和客户通知 Agent。每个 Agent 独立运行，处理自己的职责。
这种模式提高吞吐量和弹性。如果通知 Agent 失败，支付和库存 Agent 不受影响。
流水线模式
事件流经一串 Agent。Agent A 接收事件，处理，发出新事件触发 Agent B。Agent B 处理，发出事件触发 Agent C。流水线中的每个 Agent 有单一职责。
这种模式适合每一步依赖上一步结果的工作流。流水线可以包含分支——基于结果将事件路由到不同下游 Agent 的条件逻辑。
有状态事件序列模式
Agent 在相关事件序列中保持上下文。例如，客服 Agent 收到初始咨询事件，然后随着对话进展收到后续事件。Agent 必须将每个后续事件连接到正确的对话上下文。
这种模式需要仔细的状态管理。Agent 必须在每个事件后存储上下文，在下一个相关事件到达时检索它。方法包括：
- 使用按会话或对话标识符索引的数据库或键值存储。
- 在事件载荷之间传递累积上下文。
- 使用长上下文模型，在其上下文窗口内保持跨事件序列的状态。
事件驱动架构对 Agent 的好处
成本效率。 算力资源仅在实际处理期间消耗。事件之间的空闲时间没有成本。对于处理可变工作负载的 Agent，这可以显著降低基础设施成本。
响应性。 事件到达时立即处理，没有轮询间隔延迟。事件驱动 Agent 在事件发生后毫秒级内做出反应（冷启动时间除外）。
可扩展性。 每个事件独立处理，Agent 随事件率自然扩展。高流量时段自动触发更多并发执行。
弹性。 如果 Agent 在处理过程中失败，事件可以重试或路由到死信队列进行分析。下游系统不会被阻塞，因为 Agent 异步运行。
可组合性。 事件驱动 Agent 可以组合成更大的工作流，无需紧耦合。每个 Agent 发布事件，其他 Agent 订阅，形成松散连接的系统。
常见注意事项
事件排序
事件驱动系统可能乱序处理事件，特别是多个事件同时到达时。如果顺序重要，在事件中包含序列标识符，并在 Agent 中添加排序逻辑。
重复事件
事件源可能多次投递同一事件。设计 Agent 为幂等的——处理同一事件两次应产生与处理一次相同的结果。需要时使用幂等键或去重检查。
可观测性
事件在系统和 Agent 之间流动，因此追踪变得至关重要。在事件中包含关联标识符，以跟踪请求在多个 Agent 和服务之间的旅程。记录每个事件的接收、处理状态和任何发出的后续事件。
OpenClaw 与事件驱动 Agent
OpenClaw 的技能架构天然支持事件驱动模式。技能被设计为模块化能力，可以由事件触发——Webhook、定时器、消息——且只在触发时执行。多个技能可以监听同一事件源，实现扇出模式。技能也可以发出事件触发下游技能，实现流水线模式，无需中心化的编排代码。
这使得 OpenClaw 非常适合构建可组合的事件驱动工作流。每个技能处理一个职责，技能之间的事件流提供协调。了解更多：AI Agent 工作流是什么 和定时运行的 AI Agent。
下一步
先识别你的系统中可以由 Agent 处理的事件——文件上传、数据库变更、用户操作、外部 Webhook。定义触发条件、处理事件的 Agent 逻辑、以及供下游消费者使用的输出事件。从简单的扇出模式开始，根据需要添加流水线复杂度。
查看教程页获取实践示例。