本文来自 KAUST、电子科技大学（UESTC）和都灵理工大学（Politecnico di Torino）的合作研究，第一作者是电子科技大学的王志浩，通讯作者为 KAUST 副教授 Marco Canini。

研究团队提出了 NIKA——一个面向 LLM 驱动网络故障诊断和排障的基准测试框架。它是目前最大的公开网络排障 Agent 基准，涵盖 640 个真实网络故障场景、54 类网络问题、5 种网络拓扑，并提供了即插即用的编排平台，让 AI 研究者无需网络领域知识也能快速评估自己的 Agent 设计。

有意思的是，即便用上 GPT-5 这样最强的模型，在根因分析（RCA）任务上也只有 67.3% 的准确率——网络排障远没有被「解决」。

论文链接：https://github.com/sands-lab/nika

代码开源：https://github.com/zhihao1998/LLM4NetLab

网络排障到底难在哪

网络故障是生产环境中的家常便饭。硬件老化、配置错误、软件 Bug，随时可能导致服务降级甚至宕机。大型云厂商每周要处理超过 200 起网络事故，其中相当一部分还得靠工程师手动排查。

一次典型的排障流程是这样的：工程师先收到一张工单，上面写着「A 区域到 B 区域延迟升高」之类的模糊症状描述。然后开始逐一排查——查告警日志、查流量遥测数据、主动发 ping 探测、逐步缩小故障范围。一个事故可能产生上百条告警，工程师要在这些信号中做关联分析、因果推断，直到找到根因。整个过程繁琐、耗时、容易出错。

所以学界和工业界都在尝试让 LLM Agent 来做这件事。阿里云的 BiAn 在 357 起真实事故中实现了 95.5% 的故障设备定位准确率；Meta 的 Confucius 把多智能体 LLM 框架部署到了生产网络；字节跳动的 NetAssistant 当起了 on-call 工程师的副驾驶。这些系统证明了 LLM 排障这条路走得通。

但问题也随之而来。

评估缺口：大家各搞各的，怎么比

BiAn、Confucius、NetAssistant——这些系统的评估都是在各自公司内部做的，数据集不公开，评估场景有限披露。NetConfEval 虽然是公开基准，但它只关注静态配置生成，根本不支持动态的在线排障场景。换句话说，学界目前没有一个统一的、公开的基准来系统性地比较不同 Agent 设计在网络排障上的表现。

这对 AI 研究者来说是个大麻烦。想评估一个 Agent 设计好不好，要自己搭网络环境、模拟故障、写评估脚本——门槛极高，而且没有领域知识很容易搞错。对于网络方向以外的研究者，这个门槛基本劝退。

NIKA 要解决的就是这个问题。

框架设计：选故障、接 Agent、出报告

NIKA 的设计思路可以概括为三个字：「零门槛」。研究者只需要做两件事：从基准题库中选一个故障场景，然后把自己的 Agent 接上去。剩下的——网络环境部署、故障注入、流量生成、工具集成、性能评估——NIKA 全部自动完成。

框架核心包含三个组件。

事故规范（Incident Specification）。每个故障场景由三元组 $(N, \mathcal{I}, \mathcal{T})$ 定义：网络场景 $N$ 描述拓扑和配置，网络问题 $\mathcal{I}$ 定义具体故障（哪个设备的哪个组件出了什么问题），流量负载 $\mathcal{T}$ 描述正常流量和触发流量。这种模块化设计让同一个底层故障可以在不同拓扑、不同流量模式下产生大量变体——640 个事故就是这么组合出来的。

编排器（Orchestrator）。拿到事故规范后，编排器负责在容器化的网络模拟器 Kathará 上部署拓扑、注入故障、生成流量，并在 Agent 运行期间进行全程编排。

Agent 访问层（AAL）。这是 Agent 与网络环境之间的网关。通过 Model Context Protocol（MCP），NIKA 暴露了超过 30 个结构化工具接口，覆盖主动探测（ping、traceroute、iperf）、被动遥测（端口计数器、流表查询、日志检索）和遥测存储查询（InfluxDB、Sketch）三大类。Agent 不需要直接操作底层 CLI，调用 MCP 工具就行。

AAL 还做了三件重要的事：一是访问控制——通过声明式策略限制 Agent 的操作范围（比如租户级 Agent 只能查自己那片网络）；二是可观测性——每次工具调用都被记录下来，连同当时的真实网络状态快照一起存储，方便事后分析 Agent 的推理过程；三是评估——根据排障目标（检测 / 定位 / 根因分析）自动计算准确率、检测时间、Token 消耗等指标。

排障目标本身也分三个层级，难度递增：「检测」只需要判断网络是否异常（二分类）；「定位」要找出故障设备和组件（多分类）；「根因分析」还得推断出具体根因。每个层级都有对应的评估器。

GPT-5 表现如何：检测还行，根因分析差点意思

研究者用 NIKA 构建了 150 个事故子集，在三个后端模型上做了评估：GPT-OSS（20B 开源模型）、GPT-5-mini 和 GPT-5。每个事故随机选择故障设备和组件，跑两轮。GPT-5 全程最优：检测准确率比 GPT-5-mini 高约 20 个百分点，定位准确率接近后者的两倍，RCA 准确率则超出 2.5 倍。

但「最优」不等于「够好」。GPT-5 的检测准确率达到 96.7%，定位 82.0%，RCA 只有 67.3%。随着任务难度递增，模型的短板越来越明显。

按故障类型细分后，差异更加突出。链路故障（Link Failure）的定位准确率高达 97%——这类故障信号直接，Agent 查查接口状态就能发现。但资源争用（Resource Contention）只有 58%。研究者分析了推理轨迹后发现问题所在：面对 CRC 错误、队列丢包、非对称丢包这些持续存在的信号，Agent 倾向于给出「链路不稳定」「瞬时拥塞」这类模糊结论，而不是深挖背后的真正原因。

换句话说，Agent 知道「哪里不对」，但说不清「为什么不对」。

工具使用模式的对比也揭示了差异。成功的案例中，GPT-5-mini 主要依赖网络层的高层检查（比如查主机配置），而 GPT-5 会更广泛地使用应用层诊断工具（比如执行 shell 命令、测试 Web 连通性）。NIKA 基准中的不少故障影响应用性能但不完全破坏连通性，GPT-5-mini 对应用层工具的忽视直接拖了后腿。有意思的是，在 GPT-5-mini 失败的案例中，应用层工具反而出现得更频繁——说明它知道该用，但不会有效整合进推理过程。

一个值得关注的发现是工具调用错误率极低。GPT-5-mini 平均 1.6%，GPT-5 只有 0.7%，而且大多是参数格式不匹配之类的小问题。这和之前工作中报告的严重工具幻觉问题形成鲜明对比——结构化的 MCP 接口确实能大幅减少 Agent 的工具调用错误。

最后是拓扑规模的影响。检测准确率随网络规模变化不大——异常症状不会被网络变大「稀释」。但定位和 RCA 随着规模增大明显退化，平均节点数从 11 增长到 101 时，Token 消耗几乎翻倍。更大的网络意味着更多上下文需要处理，精确锁定故障点的难度水涨船高。

总结

NIKA 填补了网络排障 Agent 领域长期缺失的公开基准空白。具体来说，它做了四件事：

• 提出了网络排障 Agent 基准测试的问题形式化方法，覆盖检测、定位、根因分析三个层级
• 设计了模块化的编排平台，通过 MCP 暴露 30+ 工具接口，AI 研究者只需关注 Agent 设计本身
• 在 GPT-OSS、GPT-5-mini、GPT-5 上完成了系统性评估，发现即使是 SOTA 模型在根因分析上仍有很大提升空间
• 开源了完整框架，并公开了 900+ 条 Agent 推理轨迹

未来，如何让 Agent 在面对间接症状时做出更深层的推理，而不仅仅停留在浅层的连通性解释上，仍是值得进一步探索的重要方向。NIKA 的模块化设计也为社区贡献新的故障场景和网络拓扑留下了充足空间。