本项目处于建设实施阶段，尚未整体交付运行。页面描述的是已确定的技术架构与实施中的取舍， 规模类数字来自设计与测算，不是运行后的统计值。已交付项目会单独标注「已交付」。
这个项目难在哪
每个案例的难点都不一样。先把难点说清楚，方案才有意义。
一个机柜断电，会同时产生几十条告警：交换机离线、AP 离线、终端掉线、视频中断，值班员无法判断这是一件事还是几十件事
告警转工单的比例过高，运维团队大部分时间在处理重复工单，真正的隐患没人看
同一个故障，不同的人开出的工单标题、分类、优先级都不一样，事后无法统计
大模型生成工单描述看着漂亮，但经常编造设备型号和处理步骤，反而增加核对成本
项目背景：工单系统的真问题不是填单慢
几乎所有物联网项目交付后，运维都会掉进同一个坑：**平台能报的告警越来越多，能修的人还是那几个。**
一个中等规模的园区，一天几百条告警是常态。值班员的工作变成了在告警列表里挑哪些要处理。挑得对不对，全靠个人经验。经验丰富的人知道「这条 AP 离线和那条交换机离线是一回事」，新人不知道，于是开了两张工单，派给两个班组，两个班组到现场发现是同一个机柜。
所以做这个智能体时，第一个判断就是：**不要做「AI 自动填工单」**。填单只占运维工作量的很小一部分，做了也没多大价值。真正要解决的是三件事：
- 1**这条告警要不要开工单**（降噪）
- 2**这几条告警是不是同一件事**（合并）
- 3**该派给谁、带什么资料去**（派单与知识推荐）
这篇讲的是这三个动作的架构设计。项目目前处在实施阶段，下面写的是已确定的设计方案和取舍理由，不是上线后的运行数据。
动作一：降噪，把告警压到工单的 10%
降噪不是简单设阈值。设阈值的问题是：阈值调高了漏真故障，调低了没效果。智能体用的是**多条件联合判断**，而不是单一阈值。
| 判断维度 | 具体规则 | 作用 |
|---|---|---|
| 持续性 | 告警持续超过 N 分钟才处理，闪断自动忽略 | 过滤网络抖动与设备重启 |
| 重复性 | 同设备同类告警在窗口期内合并计数 | 避免同一问题反复推送 |
| 已知状态 | 设备处于计划维护、检修、停用状态 | 排除计划内停机 |
| 联动性 | 上游设备离线导致的下游告警 | 归并到上游事件 |
| 历史命中 | 同设备同类型告警曾判定为无需处理 | 复用历史判断 |
持续性：闪断不该惊动人
设备离线 30 秒又恢复，这种事一天能发生几十次：AP 重启、交换机端口协商、无线终端漫游。如果每次离线都告警，值班员很快就麻木了。
设计上给每类告警配一个**持续时长门槛**：AP 离线 5 分钟、交换机离线 2 分钟、摄像头离线 10 分钟、传感器数据中断 30 分钟。门槛按「这类设备正常波动有多大」来定，不是拍脑袋。
联动性：一个机柜断电，不该开二十张工单
这是降噪里最有价值的一条。平台必须先有一张**设备依赖拓扑**：交换机下面挂哪些 AP、AP 连哪些终端、机柜供电给哪些设备。有了这张图，就能做因果推断：
- 交换机离线，且它下面 12 个 AP 同时离线 → 根因是交换机，12 条 AP 告警归并。
- 机柜断电（UPS 告警），且柜内 3 台交换机同时离线 → 根因是供电，全部归并。
- 单个 AP 离线，同交换机下其他 AP 正常 → 根因就是这个 AP，独立成单。
**这张拓扑图是整套智能体的地基。** 没有它，模型再强也只能做文本层面的相似度判断，做不到因果判断。所以项目的第一阶段工作不是接模型，是把设备依赖关系补全——这也是最花时间的一步。
设备依赖拓扑在多数项目里是不全的。施工方知道哪个 AP 接哪个交换机，但没录进系统。所以第一版智能体要允许「拓扑缺失」的降级模式：只在有拓扑的地方做归并，没有的地方按时间窗口聚簇，并把这个区的拓扑完整度显示在运维看板上。
动作二：合并，三个维度都要用
降噪解决「要不要报」，合并解决「几条算一条」。合并有三个维度，缺一个都会漏：
| 维度 | 判断依据 | 典型场景 |
|---|---|---|
| 时间 | 告警发生时间在窗口期内 | 同一分钟内批量离线 |
| 空间 | 设备在同一楼栋、同一机房、同一机柜 | 机房空调故障导致多设备高温 |
| 拓扑 | 设备在依赖链上相邻 | 交换机故障导致下属 AP 全掉 |
只用时间维度会误合：同一个小区两台不相关的摄像头同时离线，可能只是巧合。只用空间维度会误合：同一机房里两台设备分别坏了，是两件事。
三个维度是**加权**关系，不是「任一满足即合并」。设计上给每个维度一个权重，累计超过阈值才合并。比如：时间相近（0.3）+ 空间相邻（0.3）+ 拓扑相关（0.4），三项全中才是 1.0，明确合并；只有时间相近和空间相邻，0.6，进入「疑似合并」待人工确认。
合并之后，工单长什么样
合并后的工单不是把多条告警堆在一起，而是要有结构：
- **主告警**：根因那一条，作为工单标题。
- **关联告警**：被归并的若干条，折叠显示，可以展开看详情。
- **影响范围**：自动算出受影响的楼栋、房间、终端数量。
- **建议动作**：基于历史同类工单，给出处理步骤。
「影响范围」这一项在实际运维中很关键。同样是「交换机离线」，影响 3 个终端和影响 300 个终端，优先级完全不同。这个数字必须由系统算出来，不能靠人估。
动作三：派单，先定级再定人
派单分两步：先定优先级，再定承接人。这两步的规则完全不同。
定级：影响面乘以业务权重
| 级别 | 判定条件 | 响应要求 |
|---|---|---|
| 紧急 | 影响核心业务区域或超过 100 个终端 | 15 分钟内响应 |
| 高 | 影响重要区域或 30–100 个终端 | 30 分钟内响应 |
| 中 | 影响一般区域或 10–30 个终端 | 2 小时内响应 |
| 低 | 单点故障，影响 10 个终端以内 | 当日内响应 |
「核心业务区域」这个标签必须提前定义，不能临时判断。比如教学楼上课时段是核心、宿舍夜间是核心、食堂用餐时段是核心。同一个位置，不同时段权重不一样。
定人：技能、位置、负载三要素
派给谁，不能只按「谁在线」。三个因素要一起看：**技能匹配**（会不会修这类设备）、**位置就近**（在不在同一片区）、**当前负载**（手里还有几个单）。
这里有一个真实的取舍：**纯自动派单在多数场景下不如「推荐 + 人工确认」**。因为运维团队通常只有几个人，彼此知根知底，值班员知道「老张今天在 A 栋，顺路」，系统不知道。所以设计上做的是推荐三个候选人并给出理由，由值班员点一下确认。
只有在夜班、节假日这类「值班员不在岗」的场景，才走全自动派单。
动作四：知识推荐，别让模型编步骤
这是最容易做砸的一环。给模型一堆设备手册，让它生成处理步骤，结果经常出现「请检查 XX 型号的 YY 参数」——而这个型号根本没有那个参数。
原因是模型在补全。它知道这类设备通常有这些参数，但不知道眼前这台具体有没有。
设计上的原则是：**检索优先，生成其次。**
| 知识类型 | 来源 | 使用方式 |
|---|---|---|
| 设备手册 | 厂商提供的 PDF | 按型号检索，原文摘录，不改写 |
| 历史工单 | 同型号同故障的已闭环工单 | 展示处置过程与耗时 |
| 现场记录 | 上次维保的备注与照片 | 作为参考，标注时间 |
三条硬规则：
- 1**手册内容必须原文摘录，标注页码。** 不许模型改写，改写了就查不到出处。
- 2**每条建议必须绑定设备型号。** 型号对不上，这条建议就不显示。
- 3**没有匹配到资料时，明确说「未找到」**，不要给通用建议。通用建议在运维场景里等于废话。
第三条最反直觉，但最重要。运维人员对「说了等于没说」的建议容忍度极低，出现两次之后，整个知识推荐功能就会被无视。宁可不给，不要瞎给。
边界：哪些事智能体不做
这个智能体的设计里，明确划了几条不做的事：
- **不做自动处置**。不自动重启设备、不自动下发配置。原因是自动处置一旦误判，影响面比故障本身还大，而且事后无法解释。
- **不做工单关闭判定**。工单能不能关，必须人确认。智能体可以提示「该设备已恢复在线」，但不能替人关单。
- **不做跨系统的根因推断**。如果故障涉及业务系统（比如教务系统连不上），智能体只能给出「网络侧正常」的结论，不去猜业务侧的问题。
这三条边界看起来限制了能力，实际是让系统能被信任的前提。**运维人员不会信任一个会自己动手的系统，但会信任一个判断得准、不乱来的助手。**
几条设计上的判断
- **智能体的第一价值是抑制工单，不是生成工单。** 运维的核心矛盾是告警太多人太少，先解决「不该开的单别开」。
- **设备依赖拓扑是地基。** 没有拓扑，只能做文本相似度；有拓扑，才能做因果归并。先补拓扑，再接模型。
- **合并要用三个维度加权，不能用「任一满足」。** 单维度合并会产生大量误合，误合比不合并更麻烦。
- **影响范围必须由系统算出来。** 影响 3 个终端和 300 个终端，优先级完全不同，靠人估一定出错。
- **纯自动派单不如「推荐 + 确认」。** 小团队里人的上下文比系统全，推荐三个候选加理由，比硬派更实用。
- **知识推荐要检索优先、生成其次。** 手册原文摘录加页码，型号对不上就不显示，找不到就说找不到。
- **不做自动处置、不做自动关单。** 能被信任的前提是边界清楚、不乱动手。
用到的技术
这些技术在其他项目里也用过，完整的协议支持清单和已实测规模见技术能力
有类似的项目？
把你的现场情况说清楚就行，不用先写需求文档。我们会告诉你从哪切入最划算、哪些环节其实可以不花钱。