Event-Driven Agent 实战:Prometheus 告警 → LLM → Tool Calling → 自动恢复
代码结构代码地址. ├── 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 需要的工具 schemaagent.py这是与llm打交道的部分调用工具拿到对应的数据发给llmllm思考之后返回结果在根据结果判断进行下一步执行链路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总结