Event-Driven Agent 实战：Prometheus 告警 → LLM → Tool Calling → 自动恢复

2026/6/16 10:25:07

前言

本文主要描述Event-Driven开发中的ReAct模式，并且使用一个demo，彻底搞懂怎么在实际工作中使用Event-Driven模式

话不多说，我们开始

代码结构

代码地址

.
├── agent.py       # EventDrivenAgent 主逻辑，负责接收事件、调用 LLM、执行工具
├── event_bus.py   # 极简事件总线，负责发布事件和消费事件
├── main.py        # 程序入口，启动事件循环，并模拟 Prometheus 告警
└── tools.py       # 工具注册中心，定义查询 Pod、查询日志、重启服务三个工具

代码解析

event_bus.py，这里用的是 Python 标准库里的 queue.Queue，主要就是模拟从消息队列读取消息
main.py，模拟从消息队列中取出警告
```
event = {"alert_name": "HighErrorRate","service": "order-service"
}publish_event(event)
```
只要队列里来了新事件，它就取出来，然后交给 agent.handle_event(event) 处理

tools.py，定义了三个工具

查 Pod 状态：

def query_pod_status(service):print(f"[Tool] 查询 Pod 状态: {service}")return f"{service} 有 2 个 Pod CrashLoopBackOff"

查服务日志：

def query_logs(service):print(f"[Tool] 查询日志: {service}")return "数据库连接超时 timeout"

重启服务：

def restart_service(service):print(f"[Tool] 重启服务: {service}")return f"{service} 已成功重启"

同时把工具注册到 _TOOL_REGISTRY 里，生成一份 function calling 需要的工具 schema

agent.py，这是与llm打交道的部分
- 调用工具，拿到对应的数据发给llm，llm思考之后返回结果
- 在根据结果判断进行下一步

执行链路

Event-Driven 的特点

以上代码分析之后，其实Event-Driven本质就是：事件驱动+ReAct

模式	关注点	典型链路	适合场景	主要风险
ReAct	边推理边行动	Thought → Action → Observation → Final	排障、检索、代码修改、需要不断补充事实的任务	循环不可控，工具调用次数和 token 成本容易升高
Event-Driven	由事件触发处理	Event → Queue → Handler → Tools → Result	告警处理、消息消费、工单流转、CI/CD、业务事件自动化	需要处理幂等、重试、并发、审计和自动动作风险

Event-Driven 最适合的场景

告警处理，这是最适合的应用场景了，通过告警回调触发
事件驱动的相关事件
- Pod CrashLoopBackOff
- 磁盘使用率超过 90%
- 证书即将过期
- 任务执行失败
- 服务发布完成

而通常一个成熟的 aiops agent 可能是这样：

Prometheus 告警事件触发 Agent           # Event-Driven↓
Agent 先生成排查计划                    # Plan-and-Execute↓
执行过程中根据日志和指标不断调整判断    # ReAct↓
需要恢复动作时走审批或白名单            # Guardrail↓
输出结论并写入工单 / 通知群             # Workflow