1. 值班夜里的告警为什么需要 AI 先看一眼Zabbix 的告警本身不复杂复杂的是告警背后的上下文。凌晨两点收到一条CPU load too high你打开面板发现这台机器同时还有内存上涨、磁盘 IO 抖动、某个服务端口响应变慢真正的问题可能藏在三条告警的交叉点里。值班的人最怕的不是告警多而是每条告警都要手动去翻历史数据、查主机详情、对比基线等你看完故障已经扩大了。我想要的链路其实很朴素Zabbix 触发告警后把事件通过 Webhook 推给 OpenClawOpenClaw 调用大模型做一次根因摘要再把结论回写到告警备注或者推送到值班群。这样值班的人第一眼看到的不是原始指标而是一段人话总结比如“web-server-01 的 CPU 从 10:20 开始爬升同时内存使用率上涨 18%疑似某个批处理任务未释放连接”。这条链路涉及三个关键角色Zabbix 负责产生事件OpenClaw 负责编排和调用模型TaoToken 负责把模型调用统一到一个 Key 上。为什么要统一 Key因为 OpenClaw 里可能同时跑着摘要 Agent、深度分析 Agent、甚至 Claude Code 做代码级排查如果每个 Agent 都配一套 Key轮换、限额、审计都会变成灾难。TaoToken 的模型对话、Coding Plan、API Keys 三块能力刚好覆盖这个场景对话接口给摘要用Coding Plan 给长期编码 Agent 用API Keys 统一管理所有调用凭证。这篇适合正在做监控告警自动化的运维同学尤其是已经在用 Zabbix、想引入大模型但不想把链路搞得太重的场景。下面我会给出 TaoToken 统一 Key 的config.toml骨架、Zabbix Webhook 脚本片段、MCP 侧配置以及一次模拟告警的端到端验证动作。你跟着做能跑通一条最小可用的 AI 告警摘要链路。2. TaoToken 前置统一 Key 与 config.toml 骨架在动手接 Zabbix 之前先把模型调用这一层收口。TaoToken 的定位是模型网关你可以在一个控制台里管理多个模型的调用凭证OpenClaw 侧只需要认一个 Base URL 和一个 Key。这样做的好处是后面无论你加多少个 Agent、换多少个模型Zabbix 和 OpenClaw 的配置都不用动。先到 TaoToken 控制台创建一个 API Key。路径是 console进去之后在 API Keys 页面新建一个 Key建议按用途命名比如openclaw-zabbix-summary方便后面审计时知道这个 Key 是给告警链路用的。创建完把 Key 复制出来只显示一次。然后配置 OpenClaw 的模型提供方。OpenClaw 的配置文件通常在~/.openclaw/openclaw.json但为了统一管理我建议把模型相关的配置抽到一个独立的config.toml里OpenClaw 启动时读取。下面是一个骨架# ~/.openclaw/config.toml [gateway] bind lan port 18789 [models.providers.taotoken] base_url https://taotoken.net/api api_key sk-你的TaoToken统一Key api openai-completions [[models.providers.taotoken.models]] id claude-sonnet-4-5 name Claude Sonnet 4.5 [[models.providers.taotoken.models]] id claude-haiku-4-5 name Claude Haiku 4.5 [agents.defaults] model taotoken/claude-haiku-4-5 scopes [operator.read] [[agents.list]] id zabbix-summary name 告警摘要员 model taotoken/claude-haiku-4-5 skills [zabbix-alert-handler] scopes [operator.read] [[agents.list]] id zabbix-deep name 深度分析员 model taotoken/claude-sonnet-4-5 skills [zabbix-alert-handler] scopes [operator.read]这里有两个 Agentzabbix-summary用 Haiku 做快速摘要zabbix-deep用 Sonnet 做深度分析。两者共用同一个 TaoToken Key但模型不同。如果你后面要接 Claude Code 做代码级排查可以在 Coding Plan 里单独开一个长期编码的额度和告警链路的 Key 分开避免互相影响。注意base_url填https://taotoken.net/api不要带多余的路径。OpenClaw 会自动拼接/v1/chat/completions这类端点。配置写完后重启 OpenClaw 网关openclaw gateway restart openclaw healthopenclaw health返回ok说明模型提供方已经加载成功。如果报provider not found检查config.toml里的[models.providers.taotoken]段名是否和 Agent 里引用的taotoken/前缀一致。3. 可复制配置Zabbix Webhook 与 OpenClaw hooks这一节是整条链路的核心。Zabbix 侧要能把告警事件 POST 出去OpenClaw 侧要能接收并路由到对应的 Agent。3.1 OpenClaw 开启 Webhook 服务在~/.openclaw/openclaw.json里加上 hooks 配置{ hooks: { enabled: true, token: your-secret-token-here, path: /hooks/zabbix, defaultSessionKey: hook:zabbix, allowRequestSessionKey: false, allowedSessionKeyPrefixes: [hook:], allowedAgentIds: [zabbix-summary, zabbix-deep], mappings: [ { match: { path: zabbix }, transform: { handler: inline, code: module.exports (payload) { const severity payload.severity || 0; const agentId severity 4 ? zabbix-deep : zabbix-summary; return { agentId: agentId, message: payload }; } } } ] } }这段配置做了三件事开启 Webhook 服务、设置共享 token 做请求校验、根据告警严重程度路由到不同 Agent。severity 4走深度分析其余走快速摘要。allowedAgentIds限制了 Webhook 只能路由到这两个 Agent避免越权。设置环境变量并重启export OPENCLAW_HOOKS_TOKENyour-secret-token-here openclaw gateway restart验证 Webhook 端点是否可达curl -X POST http://127.0.0.1:18789/hooks/zabbix \ -H Content-Type: application/json \ -H X-Webhook-Token: your-secret-token-here \ -d {severity:2,hostname:test,trigger_name:ping,message:test}返回{status:accepted}就说明 OpenClaw 侧通了。3.2 Zabbix 媒体类型配置进入 Zabbix 后台路径是管理 → 媒体类型 → 创建媒体类型类型选 Webhook。参数里填参数值urlhttp://你的OpenClawIP:18789/hooks/zabbixtokenyour-secret-token-hereScript 部分写 JavaScriptvar params JSON.parse(value); var payload { eventid: params.eventid, severity: parseInt(params.severity), trigger_name: params.trigger_name, trigger_status: params.trigger_status, hostname: params.hostname, ip: params.ip, message: params.message, timestamp: new Date().toISOString() }; var req new HttpRequest(); req.addHeader(Content-Type: application/json); req.addHeader(X-Webhook-Token, params.token); var resp req.post(params.url, JSON.stringify(payload)); if (req.getStatus() 200 req.getStatus() 300) { return OK; } else { throw Webhook failed: HTTP req.getStatus() - resp; }保存后在配置 → 动作里创建一个新动作操作步骤选发送消息接收用户和媒体类型选你刚创建的 Webhook。触发条件可以先用默认的Problem状态方便测试。3.3 MCP 侧配置让 Agent 能回查 Zabbix摘要 Agent 如果只能看到 Webhook 推过来的那点字段分析深度有限。更好的做法是让 Agent 通过 MCP 回查 Zabbix 的主机详情和历史数据。安装 MCP 适配器openclaw plugins install mcp-adapter然后在~/.openclaw/openclaw.json的plugins.entries.mcp-adapter.config.servers里加上 Zabbix MCP{ name: zabbix, transport: stdio, command: npx, args: [-y, nks-hub/zabbix-mcp], env: { ZABBIX_URL: https://your-zabbix-server.com, ZABBIX_API_TOKEN: your-zabbix-api-token } }验证插件加载openclaw plugins list输出里mcp-adapter状态为loaded即可。这样 Agent 在处理告警时可以调用host_get、history_get、problem_get这些工具去拉上下文摘要就不再是干巴巴的一句话。4. 验证请求模拟一次告警的端到端动作配置写完最怕的是“看起来都对跑起来不通”。下面用一条模拟告警走完整链路。先手动构造一个 Zabbix 风格的 payload直接 POST 给 OpenClawcurl -X POST http://127.0.0.1:18789/hooks/zabbix \ -H Content-Type: application/json \ -H X-Webhook-Token: your-secret-token-here \ -d { eventid: 12345, severity: 4, trigger_name: CPU load too high, trigger_status: PROBLEM, hostname: web-server-01, ip: 192.168.1.10, message: CPU load average is 5.2 (threshold: 3.0), timestamp: 2026-07-31T10:30:00.000Z }因为severity是 4路由会命中zabbix-deepAgent。OpenClaw 收到后会加载zabbix-alert-handler技能按技能里的步骤执行提取字段、通过 MCP 查询主机详情和历史数据、生成结构化报告、推送到微信通道。观察 OpenClaw 日志openclaw logs --follow你应该能看到类似这样的输出[hooks] received zabbix event eventid12345 severity4 [router] matched agentIdzabbix-deep [agent:zabbix-deep] loading skill zabbix-alert-handler [mcp:zabbix] host_get hostnameweb-server-01 [mcp:zabbix] history_get itemids[...] time_from... time_till... [agent:zabbix-deep] report generated, sending to wechat如果微信通道配好了值班群会收到一条格式化的报告包含告警信息、趋势分析、关联分析、排查链路和根因推断。这就是端到端跑通的标志。再测一条低严重度的curl -X POST http://127.0.0.1:18789/hooks/zabbix \ -H Content-Type: application/json \ -H X-Webhook-Token: your-secret-token-here \ -d {eventid:12346,severity:2,hostname:db-server-02,trigger_name:disk usage,message:disk /data 85%}这条会走zabbix-summary输出更简短只给告警信息和建议措施。两条都通了说明路由决策生效。5. 本篇常见错排查链路跑不通问题通常集中在几个地方。下面是我踩过的坑和对应的排查动作。Webhook 返回 401 或 403。先检查X-Webhook-Token请求头是否和OPENCLAW_HOOKS_TOKEN环境变量一致。注意环境变量是在启动 OpenClaw 的 shell 里设置的如果你用 systemd 管理要写进 unit 文件的Environment。另外openclaw gateway restart之后环境变量不会自动继承需要重新 export 再重启。Zabbix 侧报Webhook failed: HTTP 000。这是连接层失败不是应用层。检查 OpenClaw 的gateway.bind是不是lan如果是localhostZabbix 服务器访问不到。还要确认防火墙放行了 18789 端口。用curl从 Zabbix 服务器上直接测 OpenClaw 的地址能通再回来看 Zabbix 配置。Agent 没有加载技能。检查~/.openclaw/skills/zabbix-alert-handler/SKILL.md是否存在以及agents.list里对应 Agent 的skills字段是否写了对的名字。技能名要和文件夹名一致。改完配置要重启网关。MCP 工具调用失败。先单独测 MCP 服务器能不能起来ZABBIX_URLhttps://your-zabbix-server.com ZABBIX_API_TOKENxxx npx -y nks-hub/zabbix-mcp如果这里就报错说明 Zabbix API Token 或者 URL 有问题。Zabbix 的 API Token 在用户设置 → API tokens里创建注意权限要给到读取主机和历史的范围。模型调用超时或 429。这是 TaoToken 侧的限额问题。到 console 里检查这个 Key 的额度是否用完或者当前模型是否限流。如果是长期编码 Agent 和告警 Agent 共用 Key建议在 Coding Plan 里给编码 Agent 单独开额度避免告警高峰期被编码任务挤占。告警重复推送。Zabbix 的恢复消息也会触发 Webhook如果技能里没区分PROBLEM和RESOLVED恢复时也会跑一遍分析。在 SKILL.md 里加一个判断trigger_status为RESOLVED时只发一条简短恢复通知不做深度分析。6. 把链路收口到统一 Key整条链路跑通之后你会发现最省心的地方是模型调用这一层被 TaoToken 收口了。Zabbix 只管推事件OpenClaw 只管编排模型换不换、加不加新 Agent都只改config.toml里的 provider 段Zabbix 侧的 Webhook 配置一行都不用动。如果你还在调试接入阶段建议先把 API Keys 和接入文档过一遍确认 Key 的权限和额度符合预期。想先验证模型输出质量可以直接在模型对话里贴一段告警 JSON看摘要效果再决定用哪个模型。如果后面要把 Claude Code 接进来做代码级根因排查长期编码的场景更适合走 Coding Plan和告警链路的 Key 分开管理互不影响。我自己的做法是告警摘要用 Haiku深度分析用 Sonnet代码排查用 Coding Plan 里的额度三个用途三个 Key但都从同一个控制台管。这样值班的时候模型调用出问题只需要看一个地方。