值班系统最崩溃的时刻不是半夜被叫醒而是被叫醒之后盯着告警看了五分钟还没看懂这个错误到底是谁的职责、影响多大、该找哪个团队。这不是模型能力问题而是告警链路里缺了最关键的一层结构化上下文。我们每天收到的告警是一堆无规则的文本而人要判断的其实是几个固定问题——这是什么系统、什么级别、影响谁、该谁处理。这些问题如果能在告警到达的第一时间被自动拆解并交给 AI 大模型做分诊值班效率会完全不同。这篇文章要讲的就是这套思路用 Tag 体系把告警变成结构化输入再交给 ClaudeAnthropic 大模型驱动值班分诊。我会从一个真实值班场景切入拆解 Tag 在告警链路中的职责然后给出一套可落地的 Python 值班机器人实现包含环境准备、完整代码、运行验证和常见坑。读完你可以直接在内部监控系统上复刻一版让 Claude 帮你完成告警的初步分类、级别判断和责任人路由。先说结论Claude Tag 不是一个魔法开关它是一套告警标准化 模型上下文的工程方案。它的核心价值不是帮你写值班报告而是把值班链路里最耗时的理解告警环节自动化。1. 这篇文章真正要解决的问题1.1 值班的真正瓶颈是分诊太慢很多团队把值班系统的重点放在如何更早地发现故障上。Prometheus 配了一堆告警规则夜莺、Zabbix、自研监控平台都接上了日志也做了关键字告警。结果却是告警越来越多值班同学越来越累。问题出在哪出在告警产生之后到人工介入之前的这段真空期。一条告警从监控平台弹出到值班同学真正定位问题中间通常要经过这几个动作看告警标题和描述猜这是什么模块。去 Grafana 看指标确认是不是真的异常。去日志平台搜错误码找根因线索。翻团队通讯录或 OnCall 表判断该找谁处理。手动拉群、人、复制粘贴上下文。这五个动作里后面四个都是高度模式化的。尤其是第 4 步很多团队用的是谁在值班谁处理的简单轮询而不是哪个模块的负责人处理。结果就是后端同学半夜被拉起来处理一个前端网关的告警只因他的排班刚好轮到了。Claude 参与值班不是为了替代人做根因分析而是替代人完成理解告警 - 分类 - 路由这段低创造性工作。1.2 Tag 在其中的位置要让 Claude 替人做分诊前提是 Claude 能读懂告警。但大模型的输入是文本告警原文往往长这样[error] connection pool timeout, serviceorder, envprod, host10.0.3.18, errorGet http://order-svc:8080/health: context deadline exceeded人勉强能看懂但模型要稳定地从中提取出业务系统订单、环境生产、故障类型连接超时、建议路由订单服务团队这些字段光靠模型语义理解是不够的因为提示词的微小变化就可能导致分类漂移。Tag 就是来解决这个稳定性的。Tag 是在告警源头就把字段打好的标签它让告警从一段自然语言变成一组结构化键值对。Claude 拿到的是字段清晰的输入分诊就从猜变成了按规则判断。1.3 谁最应该读这篇文章被半夜告警折磨的 SRE、运维、后端开发。正在搭建或优化 OnCall 值班流程的团队。想用 Claude Code 或 Anthropic API 做自动化但不知道从哪入手的开发者。对AI 可观测性方向感兴趣的架构师。如果你只是想让 Claude 帮你写代码这篇文章也有参考价值——你会发现 Claude 在结构化数据处理上的稳定方式与日常问答完全不同。2. Claude Tag 与 Anthropic 值班的核心概念2.1 Tag 到底是什么Tag标签在可观测性领域的含义很明确附加在监控指标、日志或告警事件上的一组键值对用于描述该事件的属性。比如tags: service: order-svc env: prod region: cn-beijing severity: P1 team: order-core alert_source: prometheus常见且合理的 Tag 维度包括Tag 名称含义示例值service业务服务名order-svc、payment-svcenv环境prod、staging、devregion地域 / 集群cn-beijing、us-east-1severity告警级别P0、P1、P2team负责团队order-core、infraalert_source告警来源prometheus、log、synthetic这些 Tag 不是给监控系统内部用的而是给下游消费方用的。过去的下游消费方是值班人现在的下游消费方多了 Claude。2.2 Anthropic 值班形态是什么Anthropic 值班可以理解成Anthropic 系列模型参与值班流程。它有两种常见形态离线分析形态告警产生后后台调用 Claude API把告警原文 Tag 塞进提示词让它输出结构化的分诊建议。交互助手形态值班同学在命令行或聊天工具里通过 Claude Code 问刚才的 P1 告警可能是什么原因模型结合告警上下文给出回答。本文的代码示例采用第一种形态因为它是Tag 驱动最直接的体现也更容易接入现有监控系统。要注意的是Claude 在值班链路中是分诊助手不是最终决策者。它输出的是建议最终拉人、封网、回滚这些动作必须由经过验证的流程来执行。2.3 为什么不直接拿告警原文给 Claude很多人的第一反应是既然 Claude 理解能力强直接把原始告警文本丢给它不就行了吗从实验效果看直接丢原文存在三个问题字段提取不稳定告警文本格式一旦变化模型提取的 service、severity 可能漂移。上下文不可控原始告警里可能夹杂大量无意义信息甚至包含代码堆栈浪费 token 也干扰判断。路由依据不足值班路由依赖的是员工排班表、服务负责人映射这类组织数据告警文本里根本没有必须有额外的结构化 Tag 作为路由输入。所以正确做法是先标准化再交给模型。Tag 就是标准化的产物。3. 值班系统的整体架构设计3.1 完整链路一个 Tag 驱动的 Claude 值班分诊系统整体链路如下监控平台(Prometheus/自研) - 告警事件产生附带原始字段 - Tag 标准化层(把原始字段映射成统一 Tag) - Claude 分诊服务(调用 Anthropic API) - 结构化输出(severity, 根因方向, 建议负责人) - 路由执行(企业微信/钉钉/邮件通知, 创建工单) - 值班人确认 - 反馈闭环这里最关键的是第二层和第三层。第二层决定输入质量第三层决定判断质量。3.2 Tag 标准化层怎么设计标准化层的职责是把不同来源的告警修整成同一套字段。Prometheus 的告警字段和日志告警字段天然不同必须在进入 Claude 之前统一。这里建议维护一份Tag 映射配置核心逻辑是不同来源 - 统一键。示例# 文件路径config/tag_mapping.yaml mapping: prometheus: service_label: service severity_label: severity extra_route: instance log_monitor: app_name: service level: severity query: log_query synthetic: target_service: service check_result: health_status这样无论告警来自哪个源最终给 Claude 看的都是统一结构的输入。3.3 Claude 在分诊链路中的角色边界在编码之前必须明确 Claude 的职责边界让 Claude 做的提取关键信息、判断严重级别、猜测根因方向、推荐负责人团队。不让 Claude 做的直接修改配置、自动重启服务、发送高优通知P0 通知必须人工确认后发出。这个边界写入系统设计里避免AI 误判导致自动变更这种事故。值班场景下AI 的价值是压缩人的判断时间而不是替人承担风险。4. 环境准备Claude Code 与 Anthropic API 接入4.1 你需要准备什么为了让值班分诊服务跑起来需要以下基础环境Python 3.9 及以上版本本文示例基于 Python。一个具备 Anthropic API 访问权限的账号并拿到 API Key。能访问 Anthropic AI 服务的部署环境。一个测试用的告警模拟工具curl 即可。如果你本机已经安装了 Claude Code可以在命令行里通过claude命令交互测试如果没有安装直接用 Python SDK 调用 API 也是一样的。4.2 Anthropic Python SDK 安装推荐使用 Anthropic 官方 Python SDK。安装命令pip install anthropic安装好之后把 API Key 配置到环境变量不要在代码里硬编码export ANTHROPIC_API_KEYsk-ant-... export ANTHROPIC_MODELclaude-sonnet-4-5 # 具体模型名以你的账号可用列表为准注意不同账号可用的模型名可能不同。如果遇到 is not a model this version of claude code recognizes 这类报错说明当前 Claude Code 版本或 API 版本不认你配置的模型名需要去账号后台查看可用的模型标识或用claude model相关命令确认。4.3 验证连通性写一个最小的连通性测试脚本# 文件路径scripts/test_api.py import os from anthropic import Anthropic client Anthropic() model os.getenv(ANTHROPIC_MODEL, claude-sonnet-4-5) resp client.messages.create( modelmodel, max_tokens100, messages[ {role: user, content: 请只回复两个字正常} ] ) print(resp.content[0].text)运行python scripts/test_api.py预期输出正常如果这里连不通后面所有逻辑都不用调试了。常见报错 unable to connect to anthropic services failed to connect to api.anthropic.com 说明部署环境的网络无法访问 Anthropic 服务需要先解决网络连通性问题如果返回 529则表示服务端过载或限流需要实现重试。这一步是整个项目的地基务必先跑通再继续。5. 核心实现Tag 驱动的最小值班分诊机器人下面进入正题。我们实现一个最小但完整的值班分诊服务它包含三个部分Tag 标准化输入模板。Claude 分诊核心逻辑。路由与通知逻辑。5.1 定义告警输入的 JSON 结构先约定 Claude 分诊服务的输入格式。所有告警源在进入分诊服务之前都会被标准化成这个 JSON{ alert_id: alert-20250218-001, title: order-svc 连接池超时, tags: { service: order-svc, env: prod, region: cn-beijing, severity: P1, team: order-core, alert_source: prometheus }, raw_message: Get \http://order-svc:8080/health\: context deadline exceeded, pool_size50, active49 }这里tags是结构化字段raw_message是原始告警两者都保留。结构化的 tags 用于精准路由raw_message 用于给 Claude 提供判断依据。5.2 值班分诊核心代码创建一个 Python 服务文件# 文件路径oncall_bot/dispatcher.py import os import json from typing import Dict, Any from anthropic import Anthropic client Anthropic() MODEL os.getenv(ANTHROPIC_MODEL, claude-sonnet-4-5) # 团队映射Claude 输出的 team_key 到真实群/负责人 TEAM_ROUTE { order-core: 订单核心组, payment-core: 支付核心组, infra: 基础架构组, data-platform: 数据平台组, } SYSTEM_PROMPT 你是一个值班告警分诊助手。你会收到一条标准化告警包含 tags 和 raw_message。 请根据告警信息输出一个 JSON包含以下字段 - severity: P0 / P1 / P2 / P3P0 代表核心服务不可用 - team_key: 建议负责团队必须从给定列表中选择 - root_cause_hint: 一句话根因猜测中文不超过30字 - summary: 给值班人的一句话中文摘要不超过40字 要求 1. 只能输出 JSON不要输出其他内容。 2. team_key 必须从列表中选择order-core, payment-core, infra,># 文件路径oncall_bot/notifier.py import time from typing import Dict, Any def send_notification(alert_payload: Dict[str, Any], dispatch_result: Dict[str, Any]) - None: 根据分诊结果发送通知。生产环境请替换为企业微信/钉钉/飞书 webhook。 team_name { order-core: 订单核心组, payment-core: 支付核心组, infra: 基础架构组, data-platform: 数据平台组, }.get(dispatch_result[team_key], 基础架构组) message ( f[{dispatch_result[severity]}] {alert_payload[title]}\n f负责团队{team_name}\n f根因猜测{dispatch_result[root_cause_hint]}\n f摘要{dispatch_result[summary]}\n f告警ID{alert_payload[alert_id]}\n ) # 生产环境调用 webhook # webhook_url os.getenv(ONCALL_WEBHOOK_URL) # requests.post(webhook_url, json{msgtype: text, text: {content: message}}) print(f[notify] {time.strftime(%Y-%m-%d %H:%M:%S)}\n{message}) def execute_route(alert_payload: Dict[str, Any], dispatch_result: Dict[str, Any]) - None: 执行路由P0 必须人工确认P1/P2 可以自动通知。 severity dispatch_result[severity] if severity P0: # P0 只打印告警不自动发送高优通知等待人工确认 print(f[P0-hold] 告警 {alert_payload[alert_id]} 需要人工确认后手动升级) send_notification(alert_payload, dispatch_result) else: send_notification(alert_payload, dispatch_result)这里刻意把 P0 做了人工确认的缓冲。自动化的第一步不是全程自动化而是把 P1/P2 的初筛和通知做掉P0 保留人在环路中。5.4 主入口与模拟告警最后写一个主入口同时支持从文件读取告警和直接传 JSON# 文件路径oncall_bot/main.py import json import sys from dispatcher import dispatch from notifier import execute_route def main(alert_payload: dict) - None: print( 1. 原始告警 ) print(json.dumps(alert_payload, ensure_asciiFalse, indent2)) print(\n 2. Claude 分诊结果 ) result dispatch(alert_payload) print(json.dumps(result, ensure_asciiFalse, indent2)) print(\n 3. 路由执行 ) execute_route(alert_payload, result) if __name__ __main__: # 用法python main.py alert.json if len(sys.argv) 1: with open(sys.argv[1], r, encodingutf-8) as f: payload json.load(f) else: payload { alert_id: alert-20250218-001, title: order-svc 连接池超时, tags: { service: order-svc, env: prod, region: cn-beijing, severity: P1, team: order-core, alert_source: prometheus }, raw_message: Get \http://order-svc:8080/health\: context deadline exceeded, pool_size50, active49 } main(payload)到这里一个最小可跑的 Tag 驱动值班分诊机器人就完成了。6. 运行结果与效果验证6.1 运行命令在项目目录下执行python oncall_bot/main.py由于主入口自带一个默认告警可以直接看到完整流程。6.2 预期输出正常运行会看到三段输出。第一段是原始告警 1. 原始告警 { alert_id: alert-20250218-001, title: order-svc 连接池超时, tags: { service: order-svc, env: prod, region: cn-beijing, severity: P1, team: order-core, alert_source: prometheus }, raw_message: Get \http://order-svc:8080/health\: context deadline exceeded, pool_size50, active49 }第二段是 Claude 输出的分诊结果类似 2. Claude 分诊结果 { severity: P1, team_key: order-core, root_cause_hint: 连接池耗尽上游服务响应变慢, summary: order-svc 连接池接近占满建议检查上游服务健康状态 }第三段是路由执行 3. 路由执行 [notify] 2025-02-18 02:47:11 [P1] order-svc 连接池超时 负责团队订单核心组 根因猜测连接池耗尽上游服务响应变慢 摘要order-svc 连接池接近占满建议检查上游服务健康状态 告警IDalert-20250218-0016.3 如何判断是否成功分诊结果中的team_key与 Tag 中预置的team一致或合理。输出的 JSON 能被json.loads正常解析。通知逻辑打印出了正确的团队名和摘要。如果 Claude 输出解析失败程序会走兜底逻辑此时排查重点应放在提示词和模型输出格式上。6.4 失败时的第一步排查第一步看 API 是否连通。直接跑python scripts/test_api.py。第二步看模型输出原文。把dispatcher.py里的raw_output打印出来确认模型是否输出了多余文字。第三步看 Tag 是否有值。如果service、env等字段为空Claude 很难做准确判断。7. 常见问题与排查方法Claude Code 和 Anthropic API 在安装、接入和运行时社区反馈比较多的坑集中在下面几类。我把它们整理成表格方便直接对照排查。问题现象可能原因排查方式解决方案执行claude提示不是内部或外部命令 / 无法将 claude 项识别为 cmdlet、函数、脚本文件Claude Code 未安装或未加入 PATH执行claude --version检查安装目录重新安装 Claude Code并把可执行文件路径加入系统 PATH调用 API 时报 unable to connect to anthropic services failed to connect to api.anthropic.com部署环境网络无法访问 Anthropic 服务用curl测试 api.anthropic.com 连通性调整部署环境网络策略确保可以访问 Anthropic 服务返回 HTTP 529Anthropic 服务端过载或限流查看响应头和错误码确认是否为限流在客户端实现指数退避重试并考虑备用模型或降级策略报错 xxx is not a model this version of claude code recognizes配置的模型名在当前版本不认识用 Claude Code 的模型列表命令确认可用模型修改模型名为账号实际可用的标识登录或注册时提示 unfortunately, claude is not available to new users right now账号所在地区或时段受限或注册通道拥挤查看官方可用地区与公告确认账号状态按官方指引申请或等待开放不推荐绕过限制的方式Claude 输出的 JSON 解析失败模型输出了额外文字或 Markdown 代码块打印 raw_output 查看原文在提示词中强调只输出 JSON或对输出做后处理剥离代码块这里特别提醒一点**把 Claude Code 当作本地调试工具把 Anthropic API 当作生产集成方式是更合理的分工。**Claude Code 适合在开发机里交互排查问题而值班分诊服务应该通过 API 调用并做好重试、超时和降级。8. 最佳实践与工程建议8.1 Tag 设计规范Tag 是这套系统的输入地基。我建议在团队内把 Tag 设计成必选 可选两层必选 Tagserviceenvseverityteam可选 Tagregionalert_sourceversionowner所有告警源只要上报必须先补齐必选 Tag。缺 Tag 的告警直接进入人工补录队列不进入自动分诊链路。这个约束能保证 Claude 拿到的输入质量是稳定的。8.2 提示词要固定不要每次自由发挥值班场景里Claude 的判断稳定性比创造性更重要。因此系统提示词写好后用一组历史告警做回归测试确认分诊结果稳定。不要在生产代码里随机改提示词。提示词改动走 MR 测试流程。8.3 上下文压缩与 Token 控制告警原文可能很长尤其是带堆栈的日志告警。传给 Claude 的内容要做两层控制只截取 raw_message 前 2000 字符代码里已经做了。如果告警附带完整堆栈单独存到工单系统不全部塞给模型。这样既能控制成本也能避免长文本干扰判断。8.4 安全边界与最小权限值班系统涉及通知、路由甚至可能有自动变更能力。这里的安全边界必须提前划定Claude 的 API Key使用独立账号权限只到消息接口不关联任何云平台变更权限。通知动作只通过 webhook 发出不授予模型直接调用运维工具的权限。所有自动通知在测试环境验证过再上生产。P0 告警默认不自动升级必须人工确认。8.5 降级策略大模型不可能永远可用。值班链路必须有一个不依赖 Claude 的降级路径Claude 调用超时或失败时直接按 Tag 里的team路由发原始告警给对应团队。529 重试次数达到上限后降级到仅通知不分析。准备一个纯规则的兜底脚本保证 Claude 挂了告警依然能到达值班人手里。8.6 可观测告警链路本身值班系统本身也是系统。建议对以下指标做监控Claude 调用成功率。分诊耗时分位数。JSON 解析失败率。按 team_key 路由的告警数量分布。这些指标能帮你发现Claude 在悄悄躺平的情况。比如解析失败率突然升高很可能不是模型问题而是提示词被误改或者告警输入格式变了。9. 总结与后续学习方向这套 Claude Tag 驱动值班 的方案本质上是把值班链路中最耗时的读告警、找负责人环节用标准化 Tag 大模型分诊替代了。Tag 负责让输入结构化Claude 负责从结构化输入中快速给出分诊建议人只负责最后的确认和处置。建议你下一步这样做先在测试环境用历史告警跑通示例代码观察 Claude 的分类准确率。根据你们的服务列表扩充 TEAM_ROUTE 映射。接一个低优先级业务告警源灰度验证一周再逐步放开。在值班复盘会上对比接入前 vs 接入后的分诊耗时数据。如果想继续深入可以研究这几个方向把告警信息沉淀成向量库让 Claude 做带历史记忆的根因分析把 Claude Code 接进值班命令行让值班人员通过自然语言快速查询告警上下文或者把分诊结果同步回监控平台让 Tag 得到反向补充。最后提醒一句AI 值班系统的目标不是把值班人换掉而是让值班人在被叫醒时手机上已经有一份是什么、影响谁、猜什么原因、建议找谁的摘要。真正决定值班体验的不是模型有多聪明而是告警链路从混乱到标准化的那一小步。