为什么我做了 event-watcher：让 Agent 从被动回答走向事件驱动
我一直在想，为什么现在大多数 AI Agent 用起来感觉还是像一个”高级聊天框”。
你打开会话，提一个问题，它回答，然后你关掉。偶尔你会设一个定时任务，让它每隔一小时自动跑一次。但这两种模式，其实都不是真正意义上”在干活”的 worker。
这是我做 event-watcher 的起点——一个 OpenClaw 的 skill，能让 Agent 监听 Redis Streams 和 webhook，只在特定事件发生时才被唤醒。现在它已经有了 1.5k 的安装量，这个反馈让我觉得值得把背后的思考写清楚。
问题：Agent 只有两种工作模式
现在绝大多数 Agent 的工作模式只有两种：
- 被用户提问触发：用户问，Agent 推理，然后进入等待。
- 被定时器唤醒：每隔固定时间检查一次，机械地跑一遍流程。
这两种都不够。真正的 worker，不是等别人问，也不是定时醒来看看有没有事。真正的 worker 响应的是世界的变化。
想想那些真正在”盯盘”的人：
- 交易员盯着价格走势和仓位风险
- SRE 盯着服务指标等待异常
- 风控员监控交易流水中的异常模式
- 供应链调度员盯着库存和订单状态
他们不是在等别人来问他们问题。他们在盯信号，信号来了才动。大多数高价值的判断，不是 prompt-first（等提示），而是 event-first（等事件）。
现在的 Agent 没有等价的机制。它们没有接收世界事件的入口。在我看来，这比模型能力不足更根本——一个永远不知道风控阈值被击穿的 Agent，无论推理能力多强，都做不了任何事。
核心洞察
让我想清楚这个问题的一个关键点是：Agent 不够主动，不是因为模型不够聪明，而是因为它不知道世界发生了什么。
很多人觉得 Agent 不够主动，就去换更强的模型，调 prompt。但瓶颈往往在更上游：Agent 根本没有收到信号，所以无从反应。
解法不是更聪明的 prompt，而是事件输入。
event-watcher 做的就是这一层：在外部世界和 Agent 会话之间建一个桥，在有意义的事件发生时才把 Agent 唤醒。
它做了什么
event-watcher 支持两种事件来源：
- Redis Streams——适合高吞吐的内部事件总线（消息队列、审计日志、交易流、监控数据）
- Webhook JSONL——适合来自第三方服务、外部 API 或自建系统的信号
但它不是直接把原始事件塞给 Agent。原始事件流是噪声。真正的工作是把它变成高质量的决策触发流：
- 基于 JSON 规则的过滤（支持 AND/OR 逻辑和正则）——只有真正匹配条件的事件才会唤醒 Agent
- 带 TTL 的去重机制——避免同一条件反复触发
- 失败重试——防止因为瞬时错误导致静默丢失
- Session 路由（
sessions_send或agent_gate）——支持更复杂的多 Agent 分发场景
设计目标很简单：事件到达 Agent 时，已经值得它去思考了。
事件驱动认知≠自动化规则
我想说清楚这不是什么。这不是 if-this-then-that 的自动化，不是规则引擎触发固定动作。
我想实现的是我称之为”事件驱动认知”的东西：事件来了，Agent 在上下文中解读它，判断严重程度，然后决定下一步——是执行动作、生成分析、保持观察，还是升级给人工。
Agent 的推理能力还在，变的是何时以及为何介入。触发条件从”有人问我”变成了”世界发生了某件事”。
我认真处理的几个难点
让事件接入跑起来其实不是最难的。真正难的问题在别处。
噪声问题。 接上任何真实事件源，立刻就会被淹没。问题不是”Agent 能收到事件吗”，而是”你能不能把原始事件流变成干净的信号流”。去重、聚合、节流、冷却窗口——这些决定了系统是真正有用还是只是混乱。
动作边界问题。 被动 Agent 的问题是太懒。主动 Agent 的风险是太勤奋。在交易、风控、运维这类高后果场景里，必须清晰划定 Agent 能自主做什么、需要人工确认什么。“只观察”、“生成分析”、“建议动作”、“自动执行”、“必须人工确认”是五种完全不同的权限等级，都要显式定义。没有这个边界，主动性会变成危险性。
状态问题。 如果 Agent 每次收到事件都像第一次见到世界，它就做不好连续决策。一个交易 Agent 至少要知道当前仓位、最近采取过什么行动、这类事件上次怎么处理的。没有记忆支撑的事件驱动会产生前后矛盾的行为。这也是我认为 event-watcher 自然会进化的方向。
我认为这件事会走向哪里
我现在想清楚的框架是：event + state + policy + action。
- Event：世界发生了什么
- State：Agent 对当前上下文和历史的记忆
- Policy：Agent 根据角色目标做出的判断规则
- Action：Agent 在特定权限等级下决定执行什么
event-watcher 目前覆盖的是第一层——为原本没有事件入口的 Agent 提供一个可靠、可配置的事件输入。但第二层和第三层才是让 Agent 从”反应工具”变成”自治 worker”的关键。
我把这件事理解成在给 Agent 补”感知系统”。现在大多数 Agent 推理能力不差，但对变化中的世界是盲的。event-watcher 是修复这个问题的一步——不是让推理更聪明，而是给推理提供真实的触发信号。
下一步在哪里
这还是早期的东西。event-watcher 目前做的是事件输入层——在正确的时机把正确的信号送到 Agent 面前。更难的层在后面：状态和策略——Agent 要记得自己做过什么，理解当前的上下文，清楚自己哪些事可以自主执行、哪些必须等人确认。
这是我接下来想继续深入的方向。如果你在用 OpenClaw，希望 Agent 能响应 Redis Streams 或 webhook 而不是等待提问，event-watcher 在这里。如果你在处理更难的问题——状态连续性、动作边界、多 Agent 路由——很想知道你是怎么想的。