用AI搭建一个「网络运维智能助手」

学习目标

Week 2（Day 9–14）我们逐个击破了 6 个最实用的 AI 应用：企业知识库 RAG、AI 智能体 Agent、AI 编程助手、文档处理自动化、智能问答机器人、数据分析与 BI。今天不是"再做一道题"，而是把这 6 块能力真正拧成一件能帮你干活的武器——一个"网络运维智能助手"（NetOps Assistant）。

学完今天，你应该能够：

1. 说清楚"智能助手"和"一堆工具"的本质区别——它是被编排过的、有路由逻辑的工作流，而不是零散脚本。

2. 用 AI 搭出一个最小可用的助手骨架：能查设备手册（RAG）、能自动跑排查流程（Agent）、能批量解析巡检报告（文档处理）、能 7×24 回答同事问题（问答机器人）、能分析流量 KPI（BI）。

3. 理解"路由"——助手怎么判断"这个问题该翻知识库、还是该调工具、还是该跑分析"。

4. 产出一个端到端的"告警→处置"闭环 Demo，可以直接拿去给领导演示，证明这一周没白学。

核心内容

第一部分：概念理解（用 AI 解释）——为什么是"助手"而不是"工具堆"

打开 ChatGPT / Claude，先把今天的大问题抛给它：

我正在做一个"网络运维智能助手"，想把 RAG 知识库、AI Agent、文档处理、数据 BI 整合到一个系统里。请帮我回答：1. 整合后比单独用每个工具强在哪里？2. 这个助手的宏观架构应该长什么样？3. 哪些任务交给 RAG，哪些交给 Agent，哪些交给文档处理 / BI？4. 如果让你用一句话定义"智能助手"，你会怎么说？

AI 的典型回答（提炼）：单独用 RAG，你只能"问一句答一句"；单独用 Agent，它容易"瞎编"，因为缺少你的私有知识；单独做 BI，分析出来的异常没人能解释清楚。整合后的助手 = 私有知识（RAG）+ 行动力（Agent）+ 数据管道（文档处理）+ 洞察（BI） 四件套，由一个"路由器"统一调度。它同时具备"懂你家的网络、能替你动手、吃得进大量资料、看得懂趋势"这四种能力。

关键理解点（让 AI 进一步解释，并给出生活类比）：

• RAG = 知识层（被动）：负责"知道"。设备手册、故障案例、配置规范，全部在你的私有知识库里。同事问"两台交换机端口聚合不通怎么查"，它从手册里找原文给你，而不是凭空编。就像给助手配了一本你家的"运维百科全书"。

• Agent = 执行层（主动）：负责"做"。自动 ping、自动查 SNMP、自动比对配置、自动生成处置工单。它会自己规划步骤、调工具、看结果、再决定下一步，像一个不知疲倦的初级运维在工程上操作。

• 文档处理 = 管道层（批量）：负责"吞吐"。每天几十份巡检报告、几百条配置备份，AI 批量读、批量抽取字段、批量生成结构化台账。没有它，助手面对海量资料就会"噎住"。

• BI = 洞察层（分析）：负责"看懂"。把流量、延迟、丢包、KPI 变成图表和结论，告诉你"哪条链路在悄悄劣化"，而不是只给你一堆原始数字。

用 AI 画一张架构图（输入：请用文字描述这个助手的架构图，包含路由器、RAG、Agent、文档处理、BI 五层），你会得到类似这样的分层结构：

┌─────────────────────────────────────────────┐│            统一入口 / 路由器（Router）          ││   判断意图：查知识？跑任务？分析数据？│└──────┬──────────────┬──────────────┬─────────┘       │              │              │   ┌───▼───┐      ┌───▼───┐      ┌──▼────┐   │ RAG   │      │ Agent │      │ BI    │   │ 知识库 │      │ 执行  │      │ 分析  │   └───┬───┘      └───┬───┘      └──┬────┘       │              │              │   ┌───▼──────────────▼──────────────▼────┐   │        文档处理管道（数据底座）          │   │   巡检报告 / 配置备份 → 结构化 → 入库     │   └───────────────────────────────────────┘

一句话记住：RAG 让助手"懂你家的网络"，Agent 让助手"替你动手"，文档处理让助手"吃得进大量资料"，BI 让助手"看得懂趋势"。 这四点缺一不可，整合之后才叫"智能助手"，分开用只能叫"几个工具"。

第二部分：动手实验——搭一个最小可用的助手骨架

不用从零写所有代码。我们用 AI-First 的方式：先让 AI 设计目录结构，再逐个模块填充，最后串起来。整个过程你只需要"描述需求 + 审查代码 + 跑起来"。

Step 1：让 AI 设计项目结构

帮我设计一个"网络运维智能助手"的 Python 项目结构，要求：1. 包含 rag / agent / docproc / bi / router 五个模块2. 每个模块职责单一、可独立测试3. 给出文件树和每个文件的作用说明

你会得到类似这样的结构（我们直接采用即可）：

netops-assistant/├── main.py              # 入口：接收问题，交给 router├── router.py            # 意图路由：决定走哪个模块├── rag/knowledge.py     # RAG 知识库问答（封装 Day 9 的 Dify / Chroma）├── agent/troubleshoot.py# 故障排查 Agent（封装 Day 10 的循环）├── docproc/report.py    # 巡检报告解析（封装 Day 12）├── bi/analyze.py        # 流量 / KPI 分析（封装 Day 14）├── data/                # 手册、报告、日志存放└── README.md

Step 2：router.py —— 整个助手的"大脑"

这是今天最关键的一块。它决定"这个问题交给谁"。先用简单规则路由，后续可以让 LLM 自己判断（第三部分会讲）。

python# router.pydef route(question: str) -> str:    """极简意图路由：根据关键词把问题分发到对应模块"""    q = question.lower()    if any(k in q for k in ["手册", "规范", "案例", "怎么配", "manual"]):        return "rag"    if any(k in q for k in ["告警", "不通", "故障", "排查", "自动"]):        return "agent"    if any(k in q for k in ["报告", "巡检", "配置备份", "批量"]):        return "docproc"    if any(k in q for k in ["趋势", "流量", "kpi", "延迟", "丢包", "分析"]):        return "bi"    return "rag"  # 默认走知识库，最安全# 进阶：让 AI 帮你把上面的关键词判断替换成一次 chat 调用（语义路由），准确率更高。

Step 3：agent/troubleshoot.py —— 复用 Day 10 的 Agent 循环

Agent 不重新发明，直接把"排查流程"固化成工具链，并在第一步调用 RAG 找历史案例。

python# agent/troubleshoot.pyfrom rag.knowledge import ask_knowledge   # 复用 Day 9 的 RAGdef troubleshoot(alarm: str):    """收到告警后：先查类似案例 → 再跑排查动作 → 生成处置建议"""    # 1. RAG 找相似历史案例（Day 9 能力）    case = ask_knowledge(f"历史上类似'{alarm}'的故障如何处理？")    # 2. Agent 调工具（ping / snmp / 配置比对）— 这里用伪代码示意    steps = ["检查物理链路", "检查邻居状态", "比对两端配置", "查日志"]    results = {s: run_tool(s) for s in steps}   # run_tool 调用真实命令    # 3. 汇总成处置建议    return f"参考案例：{case}\n排查结果：{results}"

Step 4：docproc/report.py —— 复用 Day 12 的批量解析

python# docproc/report.pyimport globdef parse_reports(folder: str):    """批量读取巡检报告，抽取关键字段，生成结构化台账"""    rows = []    for path in glob.glob(f"{folder}/*.txt"):        text = open(path, encoding="utf-8").read()        # 让 AI 帮你写抽取逻辑（Day 12 学过：让模型输出 JSON）        row = extract_fields_with_ai(text)   # 返回 {设备, 状态, CPU, 内存...}        rows.append(row)    return rows   # 下游 BI 直接消费

Step 5：main.py —— 把四件套串起来

python# main.pyfrom router import routefrom rag.knowledge import ask_knowledgefrom agent.troubleshoot import troubleshootfrom docproc.report import parse_reportsfrom bi.analyze import analyzedef handle(question: str):    target = route(question)    if target == "rag":    return ask_knowledge(question)    if target == "agent":  return troubleshoot(question)    if target == "docproc":return parse_reports("./data/reports")    if target == "bi":     return analyze(question)    return "抱歉，我暂时无法处理这个问题。"if __name__ == "__main__":    print(handle("核心交换机 CPU 告警，怎么排查？"))

运行python main.py，你会看到助手先路由到 agent，再调用 RAG 找案例、跑排查、出建议——这就是"整合"的威力。整个骨架 300 行以内，全部是你用 Day 11 学的"AI 编程助手"辅助写出来的。

第三部分：深入原理——助手如何"决定"用哪个能力

光有规则路由不够。让 AI 解释更高级的路由方式，并回答一个核心问题：助手凭什么知道该用哪个能力？

我的助手现在用关键词路由，准确率一般。请解释：1. 什么是"LLM 语义路由"？为什么比关键词更准？2. 路由错了怎么办？要不要加"兜底 / 澄清"机制？3. 多 Agent 协作时，怎么避免它们互相打架？4. 助手怎么记住"上一句在聊哪台设备"？

AI 提炼的要点（务必理解）：

• 语义路由（Semantic Routing）：把"意图判断"本身也交给一次 LLM 调用，让模型理解"核心交换机 CPU 告警"属于"故障排查 / agent"而非"知识问答"。比死板关键词灵活得多，还能处理同义表达（"崩了""挂了""down 了"都归到 agent）。这是生产环境推荐做法。

• 兜底与澄清机制：路由不确定时，不要硬选。两个策略：① 让助手反问"你是想查手册，还是让我自动排查？"；② 同时并发调用 RAG + Agent，再把两份结果融合。前者更省 token，后者更稳。

• 多 Agent 协作与隔离：当多个 Agent 同时跑（比如一个查网络、一个查安全），要给每个 Agent 独立的"工作区"和清晰的职责边界，避免它们改同一个配置文件互相覆盖。可用 LangGraph / CrewAI 编排（Day 18 会展开）。

• 记忆与状态（Memory）：助手必须记住"上一句在聊哪台设备、什么故障"，所以需要一个 session 级别的内存（Day 6 学过多轮对话的 messages 列表）。否则每次提问都像失忆，体验极差。

• 可控性闸门：生产环境里，Agent 调真实工具（重启端口、改配置）必须加"人工确认"闸门，绝不能让它自己乱动生产设备。这是从"玩具"到"生产系统"的分水岭。

安全提醒：智能助手越强，越要设边界。永远遵循"只读操作自动跑、写操作人工确认、高危操作双人复核"三原则。把 Agent 的"动手权限"分级管理，是运维 AI 落地的生命线。

第四部分：实战应用——一个真实的"告警 → 处置"闭环

把今天所有模块串成一个能演示的闭环。场景：凌晨 2 点收到"某汇聚交换机端口 down"告警，助手自动完成下面六步，全程无需人醒着：

1. 收告警（agent 入口）2. 查知识库：找历史同类端口 down 的处置 SOP（rag）3. 调工具：ping 对端、查光模块、查日志（agent 工具）4. 读最新巡检报告：确认该端口近期是否有劣化趋势（docproc）5. 出 BI 结论：这条链路过去 7 天丢包率曲线（bi）6. 生成处置工单 + 推送值班人（Day 13 问答机器人入口）

完整可运行骨架（核心逻辑，工具调用为示意，真实环境替换为你的命令）：

pythondef alert_pipeline(alarm: dict):    host = alarm["device"]    # ① 知识库找 SOP    sop = ask_knowledge(f"{host} 端口 down 标准处置流程")    # ② Agent 执行排查工具    diag = {        "ping":   run_tool(f"ping {host}"),        "optical":run_tool(f"snmpget {host} opticalPower"),        "log":    run_tool(f"grep down /var/log/{host}.log"),    }    # ③ 文档处理：读最近巡检报告    trend = parse_reports("./data/reports")    # ④ BI：分析该端口 7 天丢包    insight = analyze(f"{host} 端口 7 天丢包趋势")    # ⑤ 汇总工单    advice = "更换光模块" if "光衰" in str(diag) else "检查物理链路"    ticket = f"""【告警处置工单】设备：{host}参考SOP：{sop}诊断：{diag}趋势：{trend}结论：{insight}建议：{advice}"""    notify_oncall(ticket)   # 推送给值班人（Day 13 入口）    return ticket

把这个脚本接上你 Day 9 的 Dify 知识库、Day 10 的 Agent、Day 12 的报告解析、Day 14 的 BI 分析函数，一个能 7×24 自动处置常见告警的网络运维智能助手就成型了。它不是 PPT 上的概念，而是你亲手用这一周六块能力拼出来的真实系统。

演示话术（给领导看）："这套助手接入了我们的设备手册和巡检数据，告警来了能自动找历史案例、跑排查、读趋势、出工单，把平均故障定位时间从 30 分钟压到 3 分钟。"——这句话，就是你 Week 2 全部学习的价值证明。

今日产出

• ✅ 一个可运行的"网络运维智能助手"项目骨架（netops-assistant/），含 router / rag / agent / docproc / bi 五个模块。

• ✅ 一条端到端的"告警→查案例→排查→读报告→出结论→生成工单"闭环逻辑。

• ✅ 一份说明"为什么整合比单用更强"的架构图与文字总结。

• ✅ 把 Day 9–14 六块能力真正复用、串起来的实战经验，以及一段可演示的话术。

关键学习

一句话总结：这一周你不是在学 6 个孤立工具，而是在攒一套"智能助手"的零件。今天把它们装起来，明天（Week 3）我们学"怎么用 AI 把这些零件写得更专业、更省成本、更可控"——正式进入 AI IDE 与开发工作流周，先把 Day 0 的环境坑填平，再用 Cursor / Claude Code 把工程能力拉满。