多Agent事件驱动自动化中枢——把「手动触发」变成「规则引擎自转」
场景演示
你是否遇到过这些情况：
- "每天早上要手动跑一遍数据汇总，忘了就漏"
- "系统报警后要切换好几个工具查看上下文，手忙脚乱"
- "某个条件满足时，需要同时通知N个人、同时更新N个系统"
这些场景的共同点是：有个"触发条件"，但没人帮你盯守。
事件驱动自动化中枢要解决的就是这件事——你只负责写一次规则，之后系统替你盯着，条件一到，自动执行，全流程闭环。
Step by Step：搭建事件驱动多Agent自动化中枢
Step 1：定义你的事件类型
事件来源分为三类：
| 事件类型 | 触发方式 | 适用场景 |
|---|---|---|
| 定时事件 | cron 表达式，每天/每周/每月固定时间 | 晨报生成、报表推送 |
| 条件事件 | 监控数据满足阈值 | 价格异动、库存预警 |
| 外部事件 | Webhook / API 回调 / 飞书机器人触发 | 工单创建、外部系统通知 |
Step 2：部署监控 Agent（哨兵）
用 taskflow skill 编写哨兵 Agent，专门负责监控事件源：
你是一个事件哨兵 Agent，编号 {agent_id}。
你的职责：
1. 每 {interval} 检查一次 {event_source}
2. 判断是否满足触发条件：{condition}
3. 满足时，将事件写入事件队列：{event_queue}
4. 写入格式：{{"event_type": "...", "payload": {{...}}, "timestamp": "..."}}
示例 Prompt（监控股价异动）：
你是一个股价哨兵 Agent。
每隔 5 分钟检查一次 {股票代码} 的实时价格。
如果当前价格相比昨日收盘价涨跌超过 ±3%，则触发"价格异动"事件。
事件写入本地队列文件 /tmp/event_queue.jsonl，格式：
{{"type": "price_alert", "stock": "600519", "price": 1850, "change_pct": 3.2, "time": "2026-04-28 08:30"}}
Step 3：部署执行 Agent（响应者）
事件入队后，触发对应的执行 Agent：
| 事件类型 | 执行 Agent | 执行动作 |
|---|---|---|
| 价格异动 | 通知 Agent | 推送飞书消息给指定人 |
| 库存预警 | 补货 Agent | 自动在 Bitable 里创建补货工单 |
| 定时晨报 | 晨报 Agent | 生成摘要、写入文档、发送邮件 |
| 工单创建 | 分诊 Agent | 读取内容，判断优先级，写入工单系统 |
示例 Prompt（飞书通知 Agent）：
收到事件：{event_type} = "price_alert"
执行动作：
1. 读取事件中的股票代码、当前价格、涨跌幅
2. 生成一段友好的飞书消息，包含：股票名称、当前价格、涨跌幅、建议
3. 调用飞书 API 推送给 {recipient}
消息格式示例：
📈 茅台（600519）价格异动
当前价：1850元 (+3.2%)
建议：关注是否突破压力位
Step 4：用 Bitable 作为事件日志中枢
所有事件和响应结果都记录到飞书 Bitable，形成可追溯的日志：
字段设计：
- 事件时间
- 事件类型（价格异动/工单创建/定时任务）
- 触发条件
- 响应 Agent
- 执行结果（成功/失败）
- 耗时
这样每次出问题，你都能回溯："这个事件触发了吗？哪个 Agent 响应了？结果如何？"
Step 5：编排多 Agent 联动（核心）
当一个事件需要多个 Agent 协作时，用事件路由 + Agent 编排：
事件路由规则：
IF event.type == "新工单"
THEN:
- Agent_A（分诊）: 判断优先级 → 写入 Bitable
- Agent_B（通知）: 推送给 {责任人的飞书}
- Agent_C（知识库）: 检索相似历史工单 → 回复处理建议
- Agent_D（记录）: 写日志到 Bitable
所有 Agent 并行启动，结果汇总后发给 {管理员}
可复制提示词模板
模板 A：定时哨兵 Agent
你是一个定时哨兵 Agent，名称：{agent_name}。
每 {cron_expression} 执行一次监控任务。
监控目标：{monitor_target}
触发条件：{trigger_condition}
触发时：将事件写入 {event_queue_path}
事件 JSON 格式：
{{"type": "{event_type}", "payload": {{...}}, "ts": "{timestamp}"}}
执行逻辑：
1. 读取当前状态
2. 与上次状态对比
3. 判断是否触发
4. 写入事件队列（JSONL 格式，追加）
5. 返回：监控完成，触发/未触发，原因
模板 B：事件响应 Agent
你是一个事件响应 Agent，名称：{agent_name}。
你的职责：消费事件队列，执行对应动作。
读取事件队列文件：{event_queue_path}
读取未处理事件（pending 标记）
对于每个待处理事件：
1. 解析事件类型：{event_type}
2. 根据类型选择执行剧本：
- {event_type_A} → 执行 {action_A}
- {event_type_B} → 执行 {action_B}
3. 执行完成后，更新事件状态为 "done"
4. 如果执行失败，更新状态为 "failed"，记录错误原因
返回本次处理结果统计：成功N条，失败N条
模板 C：多 Agent 编排协调器
你是一个多 Agent 协调器，名称：{coordinator_name}。
触发事件：{event}
事件类型：{event_type}
编排计划（并行执行）：
1. Agent_1（{agent_1_task}）→ 执行 {action_1}
2. Agent_2（{agent_2_task}）→ 执行 {action_2}
3. Agent_3（{agent_3_task}）→ 执行 {action_3}
汇总规则：等待所有 Agent 返回，汇总结果，生成最终报告。
报告格式：
- 事件：{event_type}
- 响应 Agent：[{agent列表}]
- 各 Agent 结果：[{{name, status, output}...]
- 总体状态：成功/部分成功/失败
使用的 Skills
| Skill | 用途 |
|---|---|
| taskflow | 定义 Agent 工作流、事件队列、状态管理 |
| browser-automation | 监控 Web 页面变化（价格、库存、页面内容） |
| feishu-bitable | 事件日志存储、多 Agent 结果汇总 |
| tavily-search | 事件关联信息检索（如舆情事件关联分析） |
| multi-search-engine | 补充信息采集（市场数据、新闻事件） |
| halo-backend-publisher | 事件报告自动发布为博客 |
价值与注意事项
核心价值
- 零漏单：条件一到立刻触发，不会因为人不在而错过
- 并行响应：多个 Agent 同时启动，响应速度从"分钟级"压缩到"秒级"
- 可追溯：所有事件和响应都记录在 Bitable，可以复盘
- 可扩展：新增事件类型只需新增规则，不改架构
避坑指南
| 坑点 | 解决方案 |
|---|---|
| 事件风暴（频繁触发） | 加去重锁（如 5 分钟内同一事件不重复触发） |
| Agent 超时 | 每个 Agent 设置 timeout，失败写入 dead letter 队列 |
| 事件丢失 | 用 JSONL 追加写而非覆盖，持久化到本地文件 |
| 多 Agent 并行竞争 | 用 Bitable 行锁或文件锁协调，避免重复处理 |
| 循环触发 | 事件处理完成后删除/标记，不重复消费 |
适用边界
✅ 适合：定时任务、价格监控、工单分诊、舆情预警、跨系统联动
❌ 不适合：需要人工判断的复杂决策、实时性要求毫秒级的交易、涉及不可逆操作（建议加人工审批节点）
总结：事件驱动自动化中枢的本质是「你定义规则，系统替你跑」。
一次配置，长期自转，把"要记得做"变成"系统会自动做"。