企业官网建设流程全解析

我见过太多运维朋友把大模型当聊天机器人用，长期停留在“帮我写个脚本”“解释一下这个报错”的层面。说实话，这有点浪费。真正让大模型在运维场景里产生价值的，是把它装进一套自动化流程里，变成一个能干活的应用——比如今天要聊的“告警汇总AI Agent”。

运维这行最磨人的不是技术难题，而是被海量告警淹没：半夜三点钉钉连响几声，打开监控平台一看，几十条告警，有大有小，有的需要立刻处理，有的根本是误报。每天早上还得花半小时把昨晚的告警整理成日报，发给领导。这种重复劳动，其实完全可以交给大模型自动完成。这篇经验贴不聊空理论，直接讲我落地的一个方案：用大模型搭建运维场景AI Agent，自动拉取告警、降噪、分类、生成报告，再推到你的企微群或邮箱。适合被日常告警折磨的运维工程师、SRE，以及想尝试AI Agent却不知道从哪下手的后端开发。

1. 场景剖析：为什么“告警汇总”最适合用Agent做

1.1 告警处理的真实痛点

先还原一下运维工作的日常。假设你管着几十台服务器，上面跑着Java应用、MySQL、Redis，前面还有Nginx做入口。监控平台用的是Prometheus + Alertmanager，或者阿里云监控、腾讯云监控之类。告警规则稍微多配几条，一天下来少说两三百条告警。

这些告警本质是机器发给人的“自然语言消息”，但它们有几个特点：数量大、噪音多、文字格式不统一。有的来自Prometheus，语句是“CPU usage is above 90%”；有的来自脚本推送，格式是“服务A在2024-12-01 03:22:00连不上数据库”。人的精力是有限的，尤其凌晨两三点，你要一条条看，还要判断优先级、找关联、追根因，最后写汇报。这个流程至少四十分钟，而且晚睡早起，第二天状态很差。

传统的自动汇总报告方案一般有两种做法：一是写固定模板，比如“今天共产生X条告警，按级别分布：严重X条，警告X条”，然后填充数字；二是直接在监控大屏截个图丢群里。这两种做法的短板很明显：模板是死的，无法理解告警之间的因果关系，也总结不出“原因是凌晨发布新版本后连接池参数失效”这种结论。截图就更不用说了，领导要看的是结论，不是一排红色数字。

1.2 大模型Agent带来的能力升级

这里就要说到大模型和普通脚本的根本区别。普通脚本处理告警，靠的是正则匹配和穷举规则，你写多少规则它就认多少。但告警场景千奇百怪，规则永远跟不上变化。大模型从底层上改变了这个玩法：它懂自然语言，可以读告警文本、理解上下文、归纳优先级、生成可读性极强的报告。你不需要为每一种异常都写死逻辑，只要给它足够的视角和工具，它就能自己判断“这轮抖动大概率是哪个服务牵头的”。

而AI Agent相比单次调用大模型，核心进步在于四条：第一，它可以反复调用工具，比如去查一下某个服务的实时状态；第二，它有记忆，能够把多轮交互的上下文拼起来；第三，它有规划能力，知道先抓原始告警、再去查关联指标、最后生成报告这个步骤；第四，它可以被嵌入到现有工作流里，比如定时触发、消息推送。换句话说，大模型只是“大脑”，Agent才是“能干活的人”，而运维告警恰好是数据源清晰、动作明确、价值显性化的高适配场景。

我当时选用Agent而不是写死脚本，还有个现实原因：不同来源的告警文案差异太大，有中文有英文，有时间戳有IP，搞规则匹配的工作量比整个项目还大。用大模型，这些问题天然被抹平了。

2. 技术选型：大模型API、Agent框架和告警数据源

2.1 大模型API怎么选

搭建这个Agent，第一步是选一个大模型。当前国内主流的选择有智谱GLM、通义千问、百川、DeepSeek等，它们都提供API接口，而且兼容OpenAI的调用格式。如果你企业内网有条件部署开源模型，比如Qwen系列，当然更可控，但个人学习和快速落地阶段，直接用云API是最省事的方式。

我需要提醒几个选型依据：一是上下文长度，至少需要8K以上，因为一次要喂几十条甚至上百条告警，上下文太短会截断；二是模型能力，建议选支持工具调用的版本，否则Agent框架发挥不了全部潜力；三是成本，汇总告警这种任务使用中等规模模型足够，不一定非要买最强型号，按token计费，一天几千条告警的token消耗其实非常便宜，基本几分钱级别。

我实际用的是兼容OpenAI接口的国内云模型，自然语言理解能力完全够用，成本也很低。如果你有私有化需求，用vLLM或Ollama部署一个7B/14B的Qwen模型，效果也相当不错，前提是你的服务器有GPU。

2.2 Agent框架选择的经验

现在市面上Agent框架很多，我评估过LangChain、LangGraph，以及国内一些现成的Agent平台。我的结论是：如果你追求代码可控、自定义能力强，直接用LangChain或LangGraph写Python脚本；如果你不想写代码，可以用Coze之类的一站式平台快速搭一个。但考虑到我们初衷是“嵌进运维体系”，要拉监控API、推企微消息、跑定时调度，我更推荐用代码方案，至少逻辑透明、方便调试。

以LangChain为例，它的核心概念是Tool（工具）和LLM。你可以定义两个工具：一个查告警列表，一个发企微消息。Agent收到任务后，先调用查告警工具拿到数据，再让大模型总结，最后调用发消息工具推送。这种“感知-决策-行动”的循环，就是Agent和普通代码最大的区别。

2.3 告警数据从哪里来

告警数据源决定了Agent吃什么。常见情况有三种：第一种是Prometheus生态的Alertmanager，这个最标准，有HTTP API可以直接拉JSON数据；第二种是云厂商监控平台的API，比如腾讯云、阿里云，需要申请密钥，拿到告警历史记录；第三种是最原始的场景，你自己写脚本巡检，输出一个文本文件或推到Redis。无论哪种，在Agent眼里都是“一个返回告警列表的函数”，这就是抽象。

我强烈建议在工程上做一层“告警归一化”：把各种格式的告警统一转换成结构化的JSON，字段尽量固定为alert_name、severity（critical/warning/info）、start_time、summary、labels等。这一步非常关键，虽然大模型能读懂非结构化文本，但统一字段后Prompt好写、报告好排，后续做聚合分析也方便。具体做法是写一个适配器，用正则或JSON解析各自平台，然后吐出标准列表。

3. 手把手搭建：一个能自动汇总结论推送的Agent

3.1 环境准备与密钥管理

先交代我的环境：一台Linux服务器，Python 3.10，已经配置好能访问目标监控平台。你需要准备两样东西：大模型的API Key，以及监控平台API的访问密钥。建议用环境变量去存密钥，不要硬编码到代码里，尤其要是有同事会看你的仓库。这里分享一个习惯：写一个.env文件，用pydantic或dotenv加载，再在.gitignore里把.env拉黑，省得哪天手滑把它提交到代码库。

依赖方面，核心就是langchain、langgraph、openai（或你用的SDK）、requests、apscheduler、tenacity。安装命令很常规，我就不啰嗦了。如果访问外网拉包受限，记得配置内网pip源。

3.2 写一个告警数据拉取器

这一层统一做告警数据获取。以Alertmanager为例，调用它的/api/v2/alerts接口，把结果转成我们定义的标准结构。

import requests from datetime import datetime, timezone ALERTMANAGER_URL = "http://your-monitor-alertmanager:9093" def fetch_alerts(): resp = requests.get(f"{ALERTMANAGER_URL}/api/v2/alerts", timeout=5) resp.raise_for_status() raw_alerts = resp.json() normalized = [] for item in raw_alerts: labels = item.get("labels", {}) test = item.get("annotations", {}) normalized.append({ "name": labels.get("alertname", "unknown"), "severity": labels.get("severity", "warning"), "start_time": item.get("startsAt", ""), "end_time": item.get("endsAt", ""), "summary": test.get("summary", ""), "description": test.get("description", ""), # 可选：把service/instance这些标签也带进summary "instance": labels.get("instance", ""), }) return normalized

这次我没有做复杂过滤，先把所有告警拿过来再让大模型筛。一个细节：凌晨拉告警时，Alertmanager的活跃告警和已解决告警是分开的，你如果要做日报，建议拿resolved状态的历史告警，拉最后一个时间窗口的数据。可以通过API参数传入时间段，比如“过去12小时”。

如果你的告警源是云监控，思路完全一样，只是接口和鉴权方式不同。云厂商的API大多要签名，强烈建议用官方SDK，不要自己造HMAC的轮子，坑特别多。

3.3 Prompt模板设计实战

Prompt是Agent的灵魂。以我的经验，把Prompt写成一个系统提示词+用户数据拼接的方式是最好维护的。系统提示词定义角色、任务、输出格式；用户部分塞原始告警JSON。下面是我调试过很多版最终用得顺手的模板：

SYSTEM_PROMPT = """你是资深运维专家。你会收到一组告警数据，需要完成以下任务： 1. 把所有告警按严重级别（Critical/Warning/Info）分类，并统计数量。 2. 识别告警之间的关联关系，判断是否存在共同根因。例如多个实例同时CPU高，可能指向同一台宿主机故障。 3. 针对主要告警给出可能原因和初步排查建议。 4. 生成一份运维告警日报，要求包含：概述、分类统计、关联分析、处置建议、待跟进事项。 必须用中文输出，使用Markdown格式。不要编造不存在的告警数据。如果数据量过大，优先分析Critical级别。"""

这里有两个细节值得单独说。首先，一定要让大模型区分“归纳”和“编造”。告警原始数据里没有出现的信息，不能凭空生成。我在模板里写了“不要编造不存在的告警数据”，这能显著降低幻觉。其次，要让大模型按优先级处理，因为一次喂进来的数据可能很多，如果模型上下文塞满了，它容易在次要告警上反复纠缠，所以要引导它“优先分析Critical级别”。

用户数据部分的拼接很简单，就是“{{告警时间窗口}}内的告警如下：json {一堆JSON}”。JSON本身就是一种结构化的自然语言，大模型看得很好，我们不需要在Prompt里额外重复字段含义。

3.4 主流程：组装Agent并生成报告

LangChain最灵活的Agent模型是LangGraph，你可以用节点图的方式定义“拉数据—分析—推报告”的流程，但第一次跑通，直接用简单的AgentExecutor就够了。下面是我这个项目的核心代码：

import os, json from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage, SystemMessage from tenacity import retry, stop_after_attempt, wait_exponential # 配置大模型客户端 llm = ChatOpenAI( base_url=os.getenv("LLM_BASE_URL"), api_key=os.getenv("LLM_API_KEY"), model="glm-4-plus", # 示例，换你自己的 temperature=0.2, ) @retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=2, max=10)) def generate_report(alerts): # 控制输入长度，防止超出上下文 if len(alerts) > 200: alerts = [a for a in alerts if a.get("severity") == "critical"][:200] + \ [a for a in alerts if a.get("severity") in ("warning", "info")][:200] text_alerts = json.dumps(alerts, ensure_ascii=False, indent=2) messages = [ SystemMessage(content=SYSTEM_PROMPT), HumanMessage(content=f"当前窗口的告警数据如下：\n{text_alerts}") ] resp = llm.invoke(messages) return resp.content

代码里我加了tenacity重试，应对API偶发错误，指数退避策略很有效。temperature调到0.2，让回答更稳定，不要让它自由发挥地话痨。

生成报告之后，剩下就是格式化。报告是Markdown文本，可以直接保存在文件里，另外做一部分更结构化的输出，比如把告警分类统计存成单独的JSON字段，这样方便后续入数据库做分析。不过刚开始跑通时，只保存Markdown就够了，路要一步一步走。

3.5 定时调度与消息推送

Agent写好了，接下来就是让它“自动跑”。我建议用APScheduler在脚本进程里做定时任务，也可以用系统cron。个人经验是APScheduler更灵活，可以定义“每小时拉一次快报、每天早上八点半拉一次日报”。调度任务本身不复杂，下面是一个基础框架：

import datetime from apscheduler.schedulers.blocking import BlockingScheduler def daily_report_job(): alerts = fetch_alerts() if not alerts: # 没有告警也要推个“无异常”，防止领导以为挂了 alerts = [{"name": "无告警", "severity": "info", "summary": "当前无未恢复告警"}] report = generate_report(alerts) push_to_wecom(report) # 推企微机器人 push_to_email(report) # 或者发邮件 scheduler = BlockingScheduler() scheduler.add_job(daily_report_job, trigger="cron", hour=8, minute=30) scheduler.start()

推送这一步，企微机器人最简单：构建一个Markdown消息体POST到webhook地址，5分钟就能配好。邮件的话用SMTPLIB发HTML邮件，需要把Markdown转成HTML，稍微多一点代码。如果公司用钉钉或飞书，原理大同小异，只要看下对应的接受消息API格式就行。

推到群里注意一个细节：报告开头最好放一句“这是AI自动生成的运维日报”，避免同事和领导误以为是人工写的，在出现误差时也能留个预期管理。而且对你自己来说，这也是免责声明。

4. 运行中的常见问题与排查实录

4.1 API限流和上下文的双瓶颈

大模型API毕竟是外部服务，并发和限流是跑生产环境时第一个坎。我遇到的情况是：早上八点半正好是各团队都跑报告的时段，云模型偶尔会返回429限流。解决手段有三层：第一，把定时任务错峰，比如八点二十跑，避开高峰；第二，加上重试和退避机制，我用的tenacity；第三，如果单次请求量太大，把告警分批喂给大模型，每个批次500条，最后合并。

上下文长度是另一个坑。我之前出现过“告警一多，模型回答直接截断”的情况。后来做了两个措施：限制喂进去的告警数量，以及在Prompt里明确要求“如果数据量过大，优先分析Critical级别”。再往上，如果你真的每天上几千条告警，建议先做规则降噪，把“连续N次心跳失败”这类明显噪音在进入大模型之前就滤掉。用大模型干活不代表放弃规则，两者是互补的。

4.2 大模型“编数据”问题怎么治

幻觉是生成式模型的核心局限，在运维报告场景尤其危险。我在测试阶段就遇到过一次：明明某台机器没有网络告警，大模型却在报告里写“网络出口带宽使用率持续过高，建议扩容”。后来排查，发现是因为我把Prometheus的标签instance当作告警内容喂了进去，模型看到了一个ECM的IP和带宽阈值，就脑补出了结论。

解决办法我总结出三条：第一，Prompt里明确写“只能基于给定的告警数据做归纳总结，不得推断数据中不存在的指标”；第二，在代码层做事实核查，比如把报告里提到的IP地址回查告警原数据，如果出现原数据里没有的IP，就用规则剔除；第三，用较低temperature，并且可以试试开启模型自带的“严格模式”或“JSON输出模式”。做AI Agent一定要有“输出校验”这个环节，和写传统代码的断言是一类思想。

4.3 告警重复与噪音的降噪策略

告警降噪是运维的老话题，在Agent里如何降噪才是关键点。我推荐的策略是分两层：第一层是前置规则降噪，比如相同告警在5分钟内多次触发，只保留一条；某个IP在半小时内连续Critical，合并成一个“持续性的故障事件”。第二层是利用大模型做“语义聚合”，把表述不同但本质同一的告警识别出来，比如“MySQL连接数过高”和“连接池满”在凌晨发布时大概率是同一根因，这种语义级的判断规则做不来，但大模型天生就能做。

这一层做完效果非常直观，我的日报里告警数量从每天两百多条骤减到每天三四十条，领导看到的是“主要事件”，而不是“惊吓清单”。

4.4 安全与权限的实际落点

很多运维朋友容易忽略一点：Agent背后的大模型API是要访问内网监控数据的，密钥安全性一旦出问题，等于把整个监控面暴露给了外部。我在项目里用的几个安全习惯：密钥全部走环境变量，不允许落到代码仓库；API Key权限最小化，监控API只给只读权限；推送webhook链接也视为敏感信息，如果泄露，外部人员可以向公司群发钓鱼消息。

运行时权限更隐蔽：Agent去查监控API用的账户，建议用一个专门的只读账号，不要用管理员账号。另外，大模型生成的报告在推到公开群前，先落库保留原始数据，方便审计回溯。这些都是生产事故换来的教训，强烈建议一开始就照做。

5. 进阶扩展：让Agent从“能用”变成“好用”

5.1 挂上RAG，让Agent读懂你公司的资产和架构

第一个进阶方向是RAG（检索增强生成）。默认情况下，大模型不知道你公司有哪些业务线、每台服务器的用途、IP对应关系。结果就是报告虽然文字通顺，但涉及实际资产时会“说外行话”。你可以把资产信息、拓扑关系、历史故障记录做一个知识库，用向量数据库存起来，让Agent在分析告警之前先去检索“这台机器是做什么的”，把检索结果拼进上下文再生成报告。

这样生成出来的日报会专业得多，比如原本只写“cpu_monitor实例CPU超过90%”，挂上RAG后会变成“订单中台常用的应用节点CPU超过90%，与上周扩容预案相关联”。这是量变到质变的差距。

5.2 对接工单系统，打通闭环

光生成报告还不够，下一步是让Agent具备执行力。现在这个Agent只做“分析”和“通报”，但运维完整流程里还有一个动作：把严重告警转工单、分配给负责人。你可以给Agent加一个工具，订阅告警事件，当某条告警连续触发超过阈值时，自动调用工单系统的API，用大模型填好标题、描述、建议排查方向，然后创建任务。

这里真正要小心的是“太冲动”。工单一旦创建，就牵扯到人力和考核，所以我在设计时加了“人工确认”路由：Critical级别建议直接提单，但不是自动提，而是推给值班长一条消息，让他确认后一键提单。大模型先帮你写好单，人来拍板，这样既提效，又不失控。

5.3 多集群、多环境的规模化策略

最后聊一下规模化。如果你要负责多个环境（开发、预发、生产）或多个业务集群，直接把单一Agent复制N份是笨办法。我的做法是：做一个统一的“告警汇总调度中心”，用选项参数区分环境，Agent实例是无状态的，每次运行通过入参拿到对应的API配置和Prompt变量。

调度中心负责维护每个环境的告警源列表、报告产生时间、推送对象，然后把任务分发给Agent。这样你在群里看到的每个环境日报，实际上都是同一个代码跑出来的，只是配置不同，后续维护成本极低。如果哪天想换大模型，也只需要改配置中心的一个字段。

再往后，还可以把历史报告存进数据库，做周报、月报的自动化整合，甚至用大模型对比上周同期告警趋势，主动预警容量问题。这一步我已经开始跑了，目前效果还不错，准备沉淀成一个小工具。

我个人在实际操作中的体会是，搭建运维场景AI Agent，难点并非写代码本身，而是理解“模型边界”。它擅长归纳、总结、生成文本，但不擅长精确计算和事实核查。你要做的，是在它周围套上数据拉取、清洗、校验、推送这些传统工程框架，让它在最适合的位置发挥能力。踩过几次坑之后，你就会发现，大模型并不玄学，它只是你工具箱里一把新钥匙而已。

最后再分享一个小技巧：刚开始跑的时候，别追求全面覆盖所有告警源，先接一个最重要的监控源（比如所有线上机器的Critical级别告警），跑通完整链路，再逐步扩展。这个节奏能帮你快速看到效果，也方便你在团队里拿实际输出说话，后面争取资源就从容多了。