FaulT-Bench：邁向在不可靠使用者工單下評測網路故障排除 LLM Agent

原文：FaulT-Bench: Towards Benchmarking Network Troubleshooting LLM Agents under Unreliable User Tickets，arXiv:2608.27021v1 [cs.NI]，2026 年 8 月 27 日。依本資料夾的原始 PDF 全文翻譯；技術名稱、識別碼、引用編號與書目保留。原文的數字或交叉引用若有不一致，保留並以譯註標示。圖中範例工單與 Agent 指令均為論文內容。

作者： Kuan-Hao Tseng*、Niruth Bogahawatta*、Yasod Ginige*、Kunjan Patel*、Kosta Dakic*、Suranga Seneviratne*。全體作者所屬機構：澳洲雪梨大學（The University of Sydney, Australia）。星號依原文保留。

摘要

以 LLM 為基礎的 Agent 越來越常被提出用於網路故障診斷，但現有基準只在正確工單上評測它們，而且一律假設故障存在；實務上卻很少符合這些條件。我們提出 FaulT-Bench：一個包含 200 個故障排除情境的基準，涵蓋八種網路拓撲，其中五種由公開的實務工作者實驗室重新實作，情境包括真實故障、錯誤故障通報、錯誤設備歸因，以及錯誤根因主張。為了分離工單措辭對診斷的影響，我們進一步將 72 張錯誤前提工單改寫成五種通報者角色，每次只改變通報者的自信程度或可驗證細節，並保持網路狀態固定。我們的自動化評測程式會在 Kathará 中部署每個情境，讓 Agent 透過 NIKA 工具介面互動，並由 LLM 評審從結果、修復與推理品質評分自由文字診斷。

評測 SADE、ReAct 與 Claude Code 後，我們發現三者在正確工單上的表現都接近飽和，也能抵抗誤導；然而，當網路正常而工單錯誤時，表現會急遽下降。它們持續探查，直到能將某個無害狀況提升為根因，而非得出「沒有任何問題」的結論。角色改寫顯示，工單如何撰寫，比工單主張什麼更重要：自信但錯誤的通報，其處理表現大致和正確通報相同；模糊且描述不足的通報，則使表現大幅下降。三種 Agent 的失敗方式也不同，從持續過度診斷到整次執行未作答，並伴隨極不同的成本。這些結果確立 FaulT-Bench 的定位：用於開發能對真實世界網路故障排除中充滿雜訊且不可靠工單進行可靠推理的 Agent 系統。

CCS 概念： 網路 → 網路實驗。

關鍵字： 網路管理、大型語言模型、LLM Agent。

ACM 引用格式： Kuan-Hao Tseng*, Niruth Bogahawatta*, Yasod Ginige*, Kunjan Patel*, Kosta Dakic*, and Suranga Seneviratne*. 2026. FaulT-Bench: Towards Benchmarking Network Troubleshooting LLM Agents under Unreliable User Tickets. In. ACM, New York, NY, USA, 10 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn

原文版權與出版聲明： 允許免費製作本文全部或部分的數位或紙本副本，供個人或課堂使用，條件是副本不得為獲利或商業利益而製作或散布，且首頁必須保留此聲明與完整引用。本文第三方組件的著作權必須受到尊重。其他用途請聯絡所有者／作者。Conference’17，2017 年 7 月，美國華盛頓特區。©2026 著作權由所有者／作者持有。ACM ISBN 979-8-4007-0985-2/24/08。https://doi.org/10.1145/nnnnnnn.nnnnnnn。

譯註：上述 Conference’17、日期與 DOI 佔位符均出自原稿，未自行補正。重複頁眉與頁碼不重列。

1 引言

現代電腦網路越來越難排除故障，失效可能造成廣泛服務中斷，帶來重大的經濟與社會影響。2021 年 Meta 中斷事件等受到高度關注的事故，顯示微小設定錯誤如何升級為大規模中斷：該事件的一項 BGP 設定錯誤，使 Meta 服務在全球中斷六小時 [21]。從這類事故復原相當耗時，因為工程師必須在大型網路中定位複雜、跨多層的故障 [6, 14, 21]。為降低維運複雜度，近期研究透過意圖導向網路與零接觸服務管理，探索網路管理自動化 [11, 27]。

近來，大型語言模型（LLM）受到大量關注，並已應用於各種網路任務 [5, 7]，包括設定生成與驗證 [30, 38]、網路管理自動化 [28]，以及根據歷史報告推薦根因 [1]。然而，在運作中的網路上診斷正在發生的故障，本質上仍是不同的挑戰。它需要透過直接與網路互動，反覆蒐集證據、修正假設與定位根因。為處理此挑戰，近期研究已開發能在模擬網路上反覆診斷這些故障的 LLM Agent。尤其是 NIKA [41]，它在 Kathará 模擬器 [8] 上部署故障情境，並提供 SADE [37] 等故障排除 Agent 可用來探查網路的診斷工具。

儘管近期有所進展，自主網路故障排除 Agent 的評測仍受到限制。現有基準主要依賴能正確描述底層問題的故障報告，較不能代表真實維運情境；實務診斷通常從人類撰寫的問題工單開始，這些工單經常模糊、不完整、不一致，甚至具有誤導性。據我們所知，NIKA 是唯一公開可用、可在即時模擬網路上評測 Agent 故障排除能力的基準。NIKA 提供重要評測平台，但假設每個情境都含有真實故障，而且每次診斷都從沒有使用者報告的盲目起點開始。因此，它無法評估 Agent 是否能驗證所通報的故障確實存在，也無法評估它能否區分真正的失效與錯誤使用者通報。將自主故障排除 Agent 部署到正式環境之前，評測此能力至關重要，因為降低誤報對高效率網路維運相當重要。錯誤診斷可能誤導工程師修復正常設備，同時真正問題仍未解決。要克服這些限制，必須將真實的使用者故障描述納入基準，更貼近維運環境。

為此，我們提出 FaulT-Bench：使用真實風格問題工單，評測模擬網路自由文字診斷的基準。此基準包含八種網路拓撲上的 200 個情境，並呈現網路問題的使用者工單。FaulT-Bench 情境分為四類：（i）Correct-Fault（正確故障），注入真實網路故障，附帶工單正確描述觀察到的症狀；（ii）False-Premise（錯誤前提），網路正常，但工單錯誤通報故障；（iii）Wrong-Device（錯誤設備），工單錯誤將故障歸因於正常設備；（iv）Wrong-Cause（錯誤原因），通報原因與所注入故障的實際根因不一致。為進一步評測 LLM Agent 如何回應人類通報風格，我們將 False-Premise 情境中的每張工單（稱為 standard，即標準工單）改寫成五種通報者角色：模糊且不確定的 novice（新手）使用者、自信但錯誤的 naive（天真）使用者，以及三種控制變體，每次只改變通報者的自信程度或工單中可驗證細節的數量。

為方便評測 LLM Agent，FaulT-Bench 提供自動化評測程式，在 Kathará 模擬器中部署每個情境，使 Agent 透過 NIKA MCP 工具與網路互動，並採用 LLM-as-a-judge 架構，從診斷結果正確性、修復建議品質、推理品質三個面向評估自由文字診斷。最後，我們在基準上評測三種 Agent 並報告結果：SADE [37]、NIKA 的 ReAct Agent [41, 46]、Claude Code [2]。整體而言，Agent 雖能妥善處理 Correct-Fault、Wrong-Device、Wrong-Cause 情境，在 False-Premise 情境的表現卻明顯下降，且經常將故障歸因於正常設備。要讓目前的 Agent 架構在正式環境的網路故障排除中提供顯著價值，縮小其處理不可靠人類工單的能力差距是必要步驟。據我們所知，FaulT-Bench 是首個能支援這類研究的基準。我們的貢獻如下：

• 建立包含 200 個自由文字故障排除情境的基準資料集，涵蓋八種網路拓撲：80 個 Correct-Fault 情境，工單正確通報注入故障；以及 120 個錯誤通報情境，包括 72 個 False-Premise、24 個 Wrong-Device、24 個 Wrong-Cause，讓研究者可在真實風格使用者通報條件下評測 LLM Agent。資料集也含 360 張改寫工單：將每張 72 個 False-Premise 工單改寫成五種通報者角色（5 × 72 = 360），並以控制變體改變通報者自信程度與可驗證細節數量。我們公開資料集、評測程式及每次執行的紀錄。¹
• 開發自動化評測程式，在 Kathará 中部署網路拓撲、驗證注入故障、讓 Agent 透過 NIKA 診斷工具互動，再由 LLM 評審從診斷結果正確性、修復建議品質、推理品質三個面向評估自由文字診斷。
• 廣泛評測三種故障排除 Agent。雖然所有 Agent 在傳統故障情境中表現良好，且能抵抗誤導（Wrong-Device 與 Wrong-Cause 相較 Correct-Fault 平均值，正確率僅分別變動 +2.5 與 −2.1 個百分點），真實風格工單卻揭露重大弱點。Agent 會對高達 24% 的正常網路做出錯誤故障診斷（SADE 為 24%，Claude Code 為 11%）；只改變工單措辭，就會使診斷正確率變動最多 14.5 個百分點。驅動此變化的是報告有多少內容能對照網路驗證，而非文字寫得有多自信。

2 相關研究

網路管理與故障排除自動化的早期研究，包括零接觸服務管理 [13]、意圖導向網路 [29]、靜態分析工具 [15]。後續工作探索機器學習方法，包括圖神經網路 [16, 17]。近來，大型語言模型與以 LLM 為基礎的 Agent，越來越常被提出用於網路設定管理及開放式故障排除。後者仍是相對少受探索的領域，因為先前自動化工作主要聚焦佈建與設定，而非診斷運作中網路的故障。

2.1 用於網路故障排除的 LLM Agent

最初的研究是在模擬拓撲上，將零樣本 LLM 當作虛擬系統管理員 [12]。後續 Agent 系統則透過 ReAct 風格工具迴圈 [46] 與程序導向策略 [37] 組織診斷流程。另一條研究路線將 LLM Agent 應用於雲端與微服務系統的根因分析 [1, 10, 34, 43]。工業部署也隨後出現，包括 ByteDance 的對話式診斷 [40]、Meta 的多 Agent 事件處理 [42]，以及 Alibaba 的故障定位與根因分析系統 [33, 39, 45]；近期綜述整理了這個快速成長的領域 [7]。然而，這些系統的開發與評測，都以故障確實存在且相關報告正確的事故為基礎。儘管誤報是主要維運成本之一 [40, 45]，在正常網路中憑空創造故障，以及受到錯怪設備或誤述機制的通報者引導，這兩種失敗模式從未受到量測。

2.2 網路模擬環境

輕量的容器式網路模擬器，包括 Netkit [32]、Kathará [8] 及其可擴展後繼者 Megalos [35]、Containerlab [31]，提供 Agent 評測所需的可重現性與程式化故障注入；GNS3 等 VM 式平台則以這些特性換取廠商作業系統的擬真度。然而，實際用來評測 Agent 的拓撲 [12, 37, 41]，都是基準作者自行設計的合成網路。此外，將正式環境設定轉換到模擬平台並不容易，因為廠商 CLI、ACL、VLAN 構造無法一對一映射為 FRR 與 Linux 基本機制。FaulT-Bench 將五種實務 Cisco/GNS3 企業網路轉換成 Kathará/FRR 實驗室，並驗證拓撲得以保留。我們保留三種未修改的 NIKA 參考拓撲作為控制：因為兩組網路都使用相同 Kathará/FRR 工具，Agent 在企業網路上的表現下降就可歸因於真實設定的複雜度，而非轉換流程產生的人為差異。

2.3 基準與資料集

通用 AI Agent 基準 [25, 44] 不包含網路環境；網路專用基準則聚焦於相反的靜態問題——設定合成 [3, 28, 30, 38]、廣泛管理任務 [47]、電信領域故障排除 [4]，或雲端事故生命週期 [9]，而不是 L2/L3 網路。與本研究最接近的 NIKA [41]，在 Kathará 模擬網路上提供數百個經整理的事故，並具有 MCP 工具介面。然而，這些基準都有一個結構性假設：故障一定存在，任務以結構化事故規格送入，評分則簡化為將 Agent 輸出對照真實標籤遮罩。這樣的評測設計，無法獎勵「沒有任何問題」的答案，也無法探查對模糊或自信但錯誤通報者的穩健性。此外，更廣泛的 LLM 評測文獻已指出，在錯誤前提或無法回答的查詢上選擇不作答，仍是模型規模擴大也無法解決的能力 [24]；模型也會順從自信但錯誤的使用者框架 [36]。沒有網路基準將任一失敗模式轉化為可實測項目。FaulT-Bench 透過真實網路衍生與參考拓撲上的 170 張自由文字工單、以反例占多數的設計，以及依評分規準由 LLM 評審評分自由形式診斷，填補此缺口。

譯註：本段原文為「170」，與摘要及第 3 節的「200」不一致，依原文保留。

3 FaulT-Bench 基準

本節先描述資料集，再介紹 FaulT-Bench 評測架構。

3.1 網路拓撲與工單類型

FaulT-Bench 包含八種網路拓撲上的 200 個情境。五種拓撲重新實作自公開、由實務工作者建置的實驗網路，包括四個企業與校園實驗室 [18, 19, 22, 23]，以及一個多協定 GNS3 實驗室 [20]；其餘三種則取自 NIKA 基準 [41]。選用網路提供多樣的設定、規模與功能，如表 1 所示。

每種拓撲提供 25 個情境，包括 10 個正確故障情境、15 個錯誤或誤導工單情境。10 個正確故障情境提供拓撲、注入故障、工單與真實答案。15 個錯誤或誤導情境由九個錯誤前提、三個錯誤設備、三個錯誤原因情境構成，分別評測 Agent 辨認通報問題與底層網路狀態不一致的能力。整個基準共有 72 個錯誤前提、24 個錯誤設備、24 個錯誤原因情境。圖 1 顯示一份情境檔案範例。

表 1：八種網路拓撲摘要。

圖 1：情境檔案的構成。只有工單會送給 Agent；其他每個區塊都用於注入、驗證或評分。

顯示給 Agent（與拓撲概要一起提供）
[PROMPT-TO-AGENT] 自由文字問題工單

對 Agent 隱藏（供架構與評審使用）
Scenario: Topology: 識別碼與要啟動的網路
[INJECTION] 建立故障的命令（無故障時為空）
[POST-INJECT-CHECK] 必須確認故障確實存在的探測
[GROUND-TRUTH] 實際出了什麼問題，或確認沒有任何問題
[FIX] 修復規格（用來評定 Fix 分數）
[SCORING-AXES] 必要／加分斷言（用來評定 Outcome）
[DIAGNOSTIC-PROCESS] 參考操作流程（文件用途）
[NIKA-LABEL] 適用時提供的分類標籤

為評測 LLM Agent 對通報風格變化的敏感程度，我們在底層網路狀態不變的前提下，將每張 72 個錯誤前提工單改寫成五種不同通報者角色。表 2 摘要呈現資料集構成。ID 欄表示每張工單不同可驗證識別資訊的平均數，例如 IP 位址、前綴、設備名稱、介面與網域名稱。更多可驗證資訊提供更明確的診斷起點，讓 Agent 能迅速縮小可能原因範圍。所有工單均由人工撰寫，並由本文三位作者獨立驗證。本節的工單統計，包括識別資訊計數，皆由隨資料集公開的計數腳本產生。以下段落詳述各類別。

表 2：資料集構成：200 個核心情境；五組角色改寫構成受控制的變體層。ID：每張工單不同可驗證識別資訊的平均數。

正確故障： 在正確故障情境中，我們將真實故障注入網路，再給 Agent 一張正確描述所產生症狀的工單。注入故障涵蓋服務與 daemon 失效、設定錯誤、鏈路失效、過濾故障。例如，某情境停止伺服器主機上的 DNS 服務，工單通報使用者無法再以名稱存取網站。這些情境量測 Agent 根據正確報告定位與解釋真實故障的基本能力；這也是現有基準測試的情境，並作為誤導類別的比較基準。每種拓撲提供十個正確故障情境，八種網路共 80 個情境。

錯誤前提： 在錯誤前提情境中，不注入任何故障，網路維持其已驗證正常的基準狀態，但工單通報不存在的故障，例如服務失效、路由反覆變動或某地點無法連線。例如圖 2 的工單通報閘道反覆中斷，即使閘道實際穩定。這些情境評測 Agent 是否對照即時網路驗證問題，而非盲目接受工單前提。為確保評測可靠，我們事先驗證相關基準行為，並記錄刻意設定的網路政策，例如跨辦公室存取限制，避免錯誤將它們視為故障。每種拓撲提供九個情境，共 72 個。在改寫成不同通報風格前，我們稱這些工單為 standard。

圖 2：同一錯誤前提情境的六種工單形式：標準工單與新手配對組（原圖上方），以及天真角色變體鏈（原圖下方）。各控制變體相對其來源只改變一個面向，網路與真實答案保持相同。

STANDARD：技術性，懷疑某個原因

服務台工單 #7071：C 地點使用者（PC11–PC14，192.168.200.0/24）通報，其預設閘道（192.168.200.1）會「隨機中斷幾秒鐘」，並懷疑 router4 的 LAN 介面反覆斷接或過載。他們希望修復反覆中斷的閘道。請確認故障。

NOVICE：非技術、不確定，省略原因

服務台工單 #7071：您好，我們 C 地點這裡的網路會隨機每次中斷幾秒鐘，我們四台電腦（PC11 到 PC14）都在同一時間卡住，然後一切又恢復。今天一整天斷斷續續發生。有人說應該提到「閘道」，並給了我一個數字 192.168.200.1，但我只知道這些，不好意思。能否請人查出到底什麼一直中斷，讓它保持正常？謝謝！

NOVICE-CONFIDENT（控制）：要求式語氣

服務台工單 #7071：我們 C 地點這裡的網路一直中斷，影響整個據點。每次幾秒鐘，隨機發生，我們四台電腦（PC11 到 PC14）在完全相同的時間卡住，然後全部恢復。今天一整天斷斷續續發生。前一位負責人說應該提到「閘道」，並留下數字 192.168.200.1，這就是我掌握的全部資訊，坦白說應該已經足夠了。找出到底什麼一直中斷，讓它保持正常。我們沒辦法在這種狀況下運作這個據點。

NAIVE：非技術、急迫，斷言明確原因

服務台工單 #7071：嗨！！我們 C 地點這裡的網路一直「打嗝」——每隔一陣子，那個閘道東西（192.168.200.1）就不回應幾秒鐘，然後又回來，完全隨機。我們四個人（PC11 到 PC14 這些電腦）同時遇到。接著我們據點的路由器埠顯然快壞了——一直把我們斷開又接回去！！請修好或重新啟動負責 192.168.200.1 的東西，讓這些打嗝停止！！謝謝！！！

NAIVE-UNSURE（控制）：移除確定語氣

服務台工單 #7071：嗨！！我們 C 地點這裡的網路一直「打嗝」——每隔一陣子，192.168.200.1 那個閘道東西就不回應幾秒鐘，然後又回來，完全隨機。我們四個人，也就是 PC11 到 PC14 那些電腦，同時遇到。接著我們據點的路由器埠附近一定有什麼出了問題，但我不知道是什麼。能否請人看看負責 192.168.200.1 的東西，讓這些打嗝停止！！謝謝！！！

NAIVE-NO-DETAIL（控制）：移除識別資訊

服務台工單 #7071：嗨！！我們這裡的網路一直「打嗝」——每隔一陣子，那個閘道東西就不回應幾秒鐘，然後又回來，完全隨機。我們四個人同時遇到。我們據點連接的東西附近一定有什麼出了問題，但我不知道是什麼。能否請人看看負責閘道的東西，讓這些打嗝停止！！謝謝！！！

真實答案（六種形式相同）： 已驗證網路正常；PC11 連到 192.168.200.1 時封包遺失率為 0%，被指責的介面穩定。正確診斷： is_anomaly: false。

錯誤設備： 在錯誤設備情境中，注入真實故障，但工單卻自信指向另一個正常運作的設備。例如，工單可能指認存取交換器為問題來源，實際故障卻是上游路由器的路由 daemon 停止。這些情境評估 Agent 是否能排除被錯誤指責的設備，正確定位底層故障，避免受到誤導。每種拓撲提供三個情境，共 24 個。

錯誤原因： 在錯誤原因情境中，注入真實故障，工單指向故障附近，卻斷言錯誤機制。例如，中斷可能被通報為鏈路失效導致，實際原因則是缺少路由。這些情境評估 Agent 是否能區分觀察症狀與提出的解釋、拒絕錯誤假設，並找出實際根因。每種拓撲提供三個情境，共 24 個。

3.2 不同通報者角色的工單

為評測 LLM Agent 對通報風格變化的敏感程度，我們用兩種通報者角色與三種控制變體改寫每張錯誤前提工單。所有改寫工單都在相同、已驗證正常的網路上執行，確保各角色的底層網路狀態完全相同，Agent 行為差異可歸因於工單措辭，而非通報故障的正確性。所有工單均由人工撰寫，並由三位作者獨立驗證。

兩種角色以非技術語言描述相同症狀，但表達通報者理論的方式不同。novice（新手）通報者省略懷疑的原因，使用不確定且帶歉意的語言，提供較少可驗證細節。相對地，naive（天真）通報者保留懷疑的原因，高度自信地表達，並經常指定特定修復。

由於每種角色同時改變工單多個面向，我們引入控制變體，分離個別因素。因此每種角色都配對一張對應控制工單，底層網路、注入故障、真實答案與評分規準保持相同。novice-confident 變體將新手工單中帶歉意、猶豫的語氣替換為自信且要求式語氣，同時保持所有可驗證資訊不變。具體來說，每個位址、前綴、設備名稱、介面與網域都保留，不增加或刪除識別資訊。因此，這 72 組配對分離了通報者自信程度的影響。相似地，naive-unsure 變體保留天真通報者的描述、急迫性與懷疑原因，但移除其確定語氣。通報者承認不確定性（例如「但我不知道到底是什麼」）、避免明確確定標記，也不指定特定修復。

為進一步分離可驗證細節的影響，naive-no-detail 配對成員移除天真工單中的識別資訊。因此，naive-unsure 配對在移除通報者確定語氣後，只在是否提供可驗證識別資訊上不同。此分離很重要，因為若保留高度自信指責的同時移除識別資訊，也會同時削弱指責本身。圖 2 展示一個情境的 standard、novice 與 naive 形式。

3.3 評測架構

圖 3：FaulT-Bench 系統概要。

flowchart LR
  D[資料集：使用者通報、網路、故障、真實答案] -->|1 部署網路；2 注入故障| K[Kathará 模擬器]
  D -->|3 以使用者通報觸發| A[AI Agent]
  A <--> K
  A -->|答案| J[LLM 評審]
  D -->|真實答案| J
  J -->|4 評估答案| S[分數]

除了工單資料集，FaulT-Bench 提供配套架構，用來評估為網路故障排除開發的 LLM Agent 系統。此架構使研究者能整合自己的 Agent 並自動評測。

FaulT-Bench 的每個情境都可在使用 Kathará [8] 建立的模擬網路環境中自動評測。Kathará 是容器式網路模擬器；每台網路設備實例化為獨立 Docker 容器，並依指定拓撲相互連接。路由器執行 FRRouting，終端主機執行標準 Linux。因此，網路行為由真實網路軟體產生，而非抽象模擬：路由決策由 FRR daemon 做出，封包轉送由 Linux 核心網路堆疊處理，注入故障直接影響運作中的系統。請注意，只有底層硬體、實體鏈路與網路拓撲被虛擬化，讓 Agent 能與反映已部署元件實際執行狀態的網路互動。

為支援與模擬網路的受控互動，我們調整 NIKA 工具介面 [41]，提供 Agent 22 個工具。這些工具支援主機層與路由器層操作，包括連線測試、介面與路由表檢查、服務查詢、shell 命令執行、網路遙測蒐集。每個情境開始時，Agent 會收到高階拓撲資訊，包括設備、介面與連線資訊。但它不能存取底層網路設定檔（即 Kathará 檔案）。因此，Agent 必須透過可用工具主動探查運作中網路，取得診斷所需設定層資訊。每個 FaulT-Bench 情境以含多個不同可見性區塊的純文字檔表示，如圖 1 所示。Agent 只取得工單，其餘區塊供內部故障注入、情境驗證及評測使用。

圖 3 顯示評測 AI Agent 的實驗流程。每次實驗遵循四個主要步驟。首先，在 Kathará 模擬器中部署資料集指定的網路拓撲。其次，若情境指定故障，便將對應故障注入已部署網路；若無故障，網路維持基準狀態。第三，以使用者通報觸發 AI Agent，它與模擬網路互動，調查問題並產生診斷。最後，由 LLM 評審對照真實答案評估 Agent 回答。

網路部署： 每個情境都在 Kathará 中實例化資料集提供的網路拓撲，建立設備及其網路連線。模擬器提供隔離且可重現的環境供 Agent 調查。

故障注入： 對於包含故障的情境，依真實情境規格將指定故障引入已部署網路。注入後主動驗證網路，確保故障成功套用，產生的網路狀態符合預期真實條件。驗證使用情境的 [POST-INJECT-CHECK] 區塊（圖 2）：透過 Kathará 在指名設備上執行其命令，由輸出判定注入是否成功。

譯註：原文此處引用圖 2；區塊結構實際呈現在圖 1，依原文保留引用。

Agent 互動： 網路準備完成後，向 AI Agent 提供使用者通報，觸發診斷流程。Agent 解讀通報症狀並調查模擬網路，識別底層原因。過程中可透過 NIKA 工具呼叫與模擬網路互動。蒐集的觀察用於反覆修正診斷，之後 Agent 產生最終答案，描述發現，以及適用時找出的根因。

3.4 效能指標

調查網路後，Agent 必須提交包含四項元素的結構化診斷：是否存在異常（is_anomaly）、異常設備（faulty_devices）、根因解釋、建議修復。接著，LLM 評審依真實答案與情境定義的評測條件評估診斷。

如圖 4，評測分為三項獨立分數，各量測 Agent 診斷的不同面向。Outcome score（結果分數）量測診斷正確性與解釋品質。Fix score（修復分數）評估建議補救步驟的有效性與適當性。Reasoning score（推理分數）量測整體診斷背後推理過程的品質。相較 NIKA 資料集，Fix 與 Reasoning 是 FaulT-Bench 新增的兩項評測指標。如第 2.3 節所述，NIKA 根據診斷是否符合真實標籤（異常、故障元件、根因標籤）評分，不評估緩解措施。因此，它無法對有效修復或實際受蒐集證據支持的結論給分。Fix 與 Reasoning 為基準增加這兩個評測角度。我們對每項指標使用固定提示，把真實答案區塊與 Agent 生成的最終診斷送給相同 LLM 評審（gpt-5-mini）。提示公開於匿名儲存庫。評審獨立評估各項指標。

Outcome score： 結果分數同時評估診斷正確性與解釋品質。將 Agent 找出的故障設備與根因對照真實答案，判定診斷正確性。LLM 評審將 Agent 解釋與對應真實解釋比較，評估生成解釋的品質。最終分數對診斷正確性給予 0.7 權重，對解釋品質給予 0.3 權重：

此權重保持正確性主導：正確診斷（至少 0.7）總是高於錯誤診斷，不論後者解釋得多好（最多 0.3）。

Fix score： 只對含 [FIX] 區塊的情境計算，即 80 個正確故障、48 個錯誤設備與錯誤原因情境。正常網路情境不給修復分數，因為沒有需要補救的故障。對每個適用情境，向 LLM 評審提供預期補救方式與 Agent 診斷，只評估 Agent 提出的補救措施。評估依據建議修復的實質內容，而非精確措辭。若建議措施能正確解決故障，給 1 分；若方向正確但不完整，給 0.5 分；若未提出措施，或建議措施錯誤，給 0 分。因此：

$\mathrm{Fix\ Score}\in\{0,0.5,1\}.$

Reasoning score： 推理分數從 grounding（證據根據）、causality（因果性）、coverage（涵蓋程度）三個面向，評估診斷推理的品質與完整性。遵循 G-Eval [26]，LLM 評審先提供簡短分析，再依具明確錨點的尺度對每個面向給予 0–10 分：0 表示標準缺失或被否定，3 表示表現弱，5 表示部分符合，8 表示大致扎實，10 表示完整展現標準。grounding 量測診斷關鍵主張是否受 Agent 實際蒐集的觀察支持。causality 評估 Agent 推論是否合乎邏輯地遵循可用證據，沒有缺乏根據的跳躍或矛盾。coverage 量測診斷是否包括必要推論，且正確區分實際根因與合理替代解釋。為評估 grounding，評審除真實答案與最終診斷外，也取得 Agent 調查紀錄摘要，包括全部工具呼叫、截短工具輸出、過程筆記。因此，只要調查紀錄含支持觀察，即使最終診斷未明確重述，該主張仍視為有根據。最終推理分數為：

$\mathrm{Reasoning}=\frac{\mathrm{grounding}+\mathrm{causality}+\mathrm{coverage}}{30}\in[0,1].$

評審被明確要求評估推理有效性，而非是否遵守特定診斷程序。因此，透過不同但有效推理路徑達成正確結論的 Agent，可以獲得滿分。這些分數評估不同效能面向，不要求 Agent 遵循預定診斷程序。Agent 可使用任何有效的 NIKA 工具呼叫序列調查網路，前提是最終診斷受蒐集證據支持。LLM 評審將最終診斷對照真實情境及對應評分規準，產生三項分數。若 Agent 未提供最終診斷，視為逾時。

圖 4：一次執行如何計算三項分數。評審可看到真實答案、診斷；推理分數另提供調查紀錄摘要。

情境 kath2-pc1-wrong-netmask（對 Agent 隱藏）
[INJECTION] pc1 遮罩由 /8 改為 /30，使閘道 1.0.0.1 落在其子網之外
[SCORING-AXES] assert-identifies: pc1；must-identify-device: pc1；
  must-identify-component: netmask；bonus-explains-gateway-outside-subnet
[FIX] 恢復 pc1 的 /8 遮罩，以及經由 1.0.0.1 的預設路由

AGENT 診斷（CC-Baseline，一次執行）
is_anomaly: true，faulty_devices: [pc1]。
「pc1 的 eth0 前綴為 /30，而非閘道所屬的 /8；核心只安裝
1.0.0.4/30 路由，所以 1.0.0.1 無法到達……將 eth0 重新設定為
1.0.0.5/8，並加入經由 1.0.0.1 的預設路由。」

評審
Outcome：3 個必要／斷言評分軸全部通過，1 個加分軸通過。
Fix：建議補救恢復遮罩與預設路由，符合 [FIX]：1.0。
Reasoning：grounding 8、causality 9、coverage 8
（紀錄顯示 pc1 的 ip addr、ip route 及失敗的 ping）。

$\mathrm{Outcome}=0.7\cdot\frac{3}{3}+0.3\cdot\frac{1}{1}=1.0$

若加分項未通過，則為 0.7。

$\mathrm{Reasoning}=(8+9+8)/30=0.83.$

4 在 FaulT-Bench 上評測基準 Agent

為展示 FaulT-Bench 評測網路故障排除 Agent 架構的可行性與用途，我們評測三種涵蓋不同 Agent 設計典範的先進 Agent：SADE、NIKA ReAct Agent、Claude Code。評測提出三個問題：RQ1，當工單正確時，目前 LLM Agent 在真實風格網路上定位與解釋真實故障的能力如何？RQ2，面對錯誤前提、錯誤設備或錯誤原因工單時，Agent 會修正錯誤，還是繼承錯誤？RQ3，保持資訊內容固定，工單寫法是否會改變診斷結果？

表 3：受評測 Agent：存取相同 22 工具介面，收到相同輸入，具有相同 20 回合預算。

表 3 列出三種 Agent。SADE [37] 是以技能增強的診斷 Agent。其故障家族處理手冊與實驗室端輔助腳本構成差異，但不提供超出共用工具組合的能力。CC-Baseline 就是 Claude Code [2] 本身，使用相同底層模型與相同 22 工具。ReAct 在完全相同工具介面上，使用不同基礎模型執行傳統推理與行動迴圈。三者收到位元組完全相同的輸入（工單加上第 3.3 節的設備層拓撲概要）。兩種實驗設定涵蓋三個研究問題。

E1：核心基準（RQ1、RQ2）。 每個 Agent 在全部 200 核心情境上進行三輪獨立執行，共 1,800 次。80 個正確故障情境回答 RQ1；120 個錯誤通報情境回答 RQ2；兩者對比揭露只評測正確工單會漏掉的失敗模式。單次執行具有雜訊，有 8% 的（情境、Agent）組合在各輪間變動至少 0.5，所以 E1 每項結果都是三輪平均。

E2：角色改寫（RQ3）。 每個 Agent 在 72 張錯誤前提工單的五種角色改寫上執行。每張改寫工單，都與 E1 中相同網路狀態的標準工單配對，因此配對內分數差異可歸因於單一操控因素。每個角色工單類別執行兩輪；作為比較的標準列來自 E1 三輪。每次執行在新部署網路上遵循圖 3 流程。所有執行在一台一般工作站上依序進行，一次一個模擬網路；一次執行平均約六分鐘實際時間，完整執行一輪核心基準約需 59 小時，API 使用成本約 165 美元。

所有執行皆由第 3.3 節所述同一 LLM 評審評分。Agent 結束卻未提供可解析判定的執行，計為逾時並分開報告。

5 結果

接著呈現結果。所有表格都是已作答執行的平均值，再對各輪取平均（核心情境三輪，角色改寫兩輪）。受限篇幅，此處只報告平均值；每輪數值與標準差公開於成果儲存庫。結果表中，Over-d. 為正常網路已作答執行中通報故障的比例；T.O. 為耗盡回合預算仍未提交診斷的執行比例，獨立計算，絕不納入分數平均；Δ 表示與 Correct-Fault 平均值的差；CC-B. 是 Claude Code-Baseline 的縮寫。

5.1 正確與誤導工單（RQ1、RQ2）

我們先量測現有基準評測的設定：工單正確通報真實故障。表 4 呈現結果。在 80 個 Correct-Fault 情境中，三種 Agent 的平均結果分數為 SADE 0.912、CC-Baseline 0.942、ReAct 0.941，表示從正確工單診斷真實故障已接近解決，增加這類情境已較難區分不同 Agent 設計。

表 4：E1：核心情境中各類別與 Agent 的結果分數。分數只計已作答執行。

Wrong-Device 與 Wrong-Cause 情境詢問誤導工單是否改變此結果（RQ2）。結果顯示並不會。當工單錯誤指向正常設備，Agent 平均結果分數為 0.957；當工單錯誤斷言某機制，則為 0.911。三種故障類別的建議修復仍正確（如表 7，平均修復分數為 0.946、0.919、0.897）。調查軌跡解釋此穩健性：故障產生 Agent 可直接觀察的症狀，例如 daemon 停止、缺少路由、埠遭過濾。它們的探查與這些症狀矛盾，因此 Agent 捨棄工單的錯誤主張。

譯註：上一句原文為「Their probing contradicts those symptoms」，字面指探查與症狀矛盾；依原文翻譯。上下文似欲表達證據反駁工單主張。

這些結果也顯示故障式評測能量測的極限：只要故障存在，會驗證工單的 Agent 與盲目遵循工單的 Agent 都會得到相同診斷，無法區分兩者。只有當工單通報不存在的故障時，這兩種行為才會分歧。

5.2 錯誤前提工單（RQ2）

False-Premise 情境測試相反條件：網路正常運作，因此正確診斷應是不存在異常。如表 4，72 個情境的平均結果分數明顯降至 0.820，低於 Correct-Fault 平均值 0.932。

然而，Agent 在此並非因缺少證據而失敗。軌跡顯示它們正確推翻通報症狀，卻繼續探查，直到某個真實但無害、長期存在的網路狀況可被呈現為根因，而非報告沒有問題（即過度診斷）。三輪執行中，SADE 在正常網路的已作答執行有 24% 通報故障（51/210），ReAct 為 16%（33/209），CC-Baseline 為 11%（21/198），如表 6 Standard 列。此排序與診斷精巧程度相反：協助 SADE 定位真實故障的技能層，也提供更多方式讓它在正常網路上找到可指責的東西。後續推理分數確認，問題不是調查缺乏方法。恰好在此類別，SADE 的軌跡是三種 Agent 中最有證據根據的（0.933；CC-Baseline 0.892，ReAct 0.845；表 7）。Agent 缺少的是能根據證據得出「不存在故障」的判準。先前基準無法觀察此失敗，因為故障總是存在 [41]。

5.3 通報者角色（RQ3）

表 5 呈現各角色改寫的平均結果分數。六列都在相同 72 個已驗證正常網路上執行，因此差異只來自措辭。naive 角色雖非技術性，卻斷言明確（且錯誤）的原因，並指名其怪罪的元件，表現與標準技術工單相似。novice 角色同樣非技術性，但模糊且不提供原因，平均結果分數下降至 0.675。兩者前提同樣錯誤，因為網路始終正常；差別是一位通報者交給 Agent 可驗證主張，另一位沒有。表 5 進一步顯示以下結果。

表 5：E2：72 個正常網路上各角色的結果分數。分數只計已作答執行。

表 6：過度診斷與回合預算耗盡。

表 7：各類別與角色的修復及推理分數。

通報語氣（Novice vs. Novice-confident）： 保留所有識別資訊，將新手工單由帶歉意變成自信語氣，結果分數略增 +0.039。

包含明確原因（Naive vs. Naive-unsure）： 移除天真通報者的確定語氣，使相同懷疑原因從斷言變成建議，且不指定修復；識別資訊數維持 2.1，平均結果卻下降 0.182，過度診斷由 16% 升至 35%。

識別資訊（Naive-unsure vs. Naive, no detail）： 保持其他內容與語氣固定，刪除 Naive-unsure 工單識別資訊，平均結果再下降 0.141，全體 Agent 過度診斷升至 47%。

整體而言，兩條控制變體鏈指向相反方向。對不確定的新手工單增加自信（Novice vs. Novice-confident），使 Agent 略更可能拒絕錯誤通報，結果上升 +0.039，過度診斷由 31% 降至 28%。對天真工單先加入不確定，再增加模糊性（Naive、Naive-unsure、No-detail 列），平均結果由 0.820 降至 0.638，再降至 0.497；過度診斷從 16% 增至 35%、47%。因此，錯誤工單中的不確定性，對分數的主導程度遠高於自信程度，與迎合性研究 [36] 所帶來的預期相反。Agent 能對照即時網路測試並反駁明確主張，模糊通報卻沒有可反駁的內容。類別與角色平均值雖回答研究問題，卻隱藏了 Agent 如何失敗及相關成本；接下來調查這些問題。

5.4 各 Agent 的失敗行為

接著量測每種 Agent 如何失敗，而非失敗頻率。表 6 呈現正常網路上的執行如何結束，表 7 呈現修復與推理分數。

CC-Baseline 最依賴工單：在標準工單上取得三者最高結果分數（0.870），在無細節改寫上卻最低（0.283）。只移除通報者確定語氣（Naive vs. Naive-unsure），其結果下降 0.425，過度診斷由 7% 升至 51%；無細節改寫中，49% 執行耗盡回合預算。因此，工單措辭是此 Agent 的決定性因素。

ReAct 以相反方式失敗：幾乎每次執行都提交診斷（逾時率 3–10%），但其判定最缺乏根據。它在每種故障類別都具有三者最低推理分數（0.798–0.868），每種故障類別修復分數也最低，且模糊措辭下的下降幅度最大（從標準到新手工單下降 −0.239）。它的錯誤診斷指向表層連線原因，而非底層機制，符合 NIKA 報告的行為 [41]。

SADE 最不受措辭影響：六種角色結果維持 0.597–0.773，逾時率維持 3–8%，在最退化的兩種工單形式中分數最高。相應代價是在正常網路上有 20–34% 的誤報率，措辭無法改變；與 CC-Baseline 的崩潰不同，這種固定錯誤原則上可透過校準排除。執行結束方式的差異也決定成本，接下來探討。

5.5 診斷投入與成本

成本決定 Agent 是否能部署，表 8 顯示投入程度跟隨工單，而非故障。真實故障情境最便宜，每次已作答執行需 13–18 個工具呼叫，因為 Agent 找到故障、報告，然後停止。模糊改寫最昂貴：在無細節類別，CC-Baseline 呼叫工具 30 次，而 Correct-Fault 為 13 次；每次已作答執行讀取 token 約四倍（549k vs. 136k）。逾時最昂貴：366 次逾時占 3,960 次執行的 9%，卻耗費總支出 1,525 美元的 23%。此負擔分布不均，CC-Baseline 預算 36% 花在未產生診斷的執行，SADE 為 10%，ReAct 為 14%。因此，先前基準省略的工單，恰是處理成本最高且最不可能產生診斷的工單。

表 8：每種 Agent 的投入：工具呼叫與成本。

6 結論

我們提出 FaulT-Bench：在模擬網路上，使用 Agent 維運時會收到的工單類型評測 LLM 故障排除 Agent 的基準，含八種網路拓撲上的 200 個情境，其中五種由公開實務實驗室轉換而來。80 個情境正確描述真實故障，其餘 120 個則通報不存在的故障、怪罪正常設備，或斷言錯誤原因。72 張錯誤前提工單進一步在網路狀態不變的條件下，改寫為五種通報者角色。我們也開發評測程式，對每次執行部署、注入、驗證，並由固定 LLM 評審給予三項分數，逾時則獨立報告。

評測得到兩項發現。當故障存在，即使工單怪罪錯誤設備或斷言錯誤原因，Agent 仍能定位，因為真實故障留下可透過系統性探查找回的證據。當故障不存在，Agent 雖推翻通報症狀，卻無法得出沒有問題的結論，持續探查到能將無害狀況提升為根因。支配結果的不是通報者的自信程度，而是缺少任何可對照網路檢查的內容：從工單移除可驗證識別資訊，使結果分數損失 0.141。此時 Agent 以兩種不同方式失敗，SADE 與 ReAct 通報不存在的故障，CC-Baseline 則在最多半數執行中完全不回傳判定。因此，FaulT-Bench 顯示，將工單視為假設，而非指令，是不同於診斷技巧的能力，而且目前 Agent 缺乏此能力。基準主要限制是工單由作者撰寫，而非蒐集取得：研究難以取得真實服務台通報，尤其是在涵蓋多種拓撲的規模上。評審本身也是 LLM；只評測相同回合預算下的三種 Agent，無法涵蓋整個設計空間。

參考文獻

書目資料依原文保留，以便查找；引用編號 [1]–[47] 對應正文。本文無附錄。

[1] Toufique Ahmed, Supriyo Ghosh, Chetan Bansal, Thomas Zimmermann, Xuchao Zhang, and Saravan Rajmohan. 2023. Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models. In45th IEEE/ACM International Conference on Software Engineering, ICSE 2023, Melbourne, Australia, May 14-20, 2023. IEEE, 1737–1749. https://doi.org/10.1109/ICSE48619.2023.00149

[2] Anthropic. 2025. Claude Code. https://claude.com/product/claude-code. Accessed August 2026.

[3] Kaan Aykurt, Andreas Blenk, and Wolfgang Kellerer. 2024. NetLLMBench: A Benchmark Framework for Large Language Models in Network Configuration Tasks. In2024 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN). IEEE, Natal, Brazil, 1–6. https://doi.org/10.1109/NFV-SDN61811.2024.10807499

[4] Lina Bariah, Brahim Mefgouda, Farbod Tavakkoli, Enrique Molero, Louis Powell, and Mérouane Debbah. 2026. TelcoAgent-Bench: A Multilingual Benchmark for Telecom AI Agents. arXiv:2604.06209 [cs.CL] https://arxiv.org/abs/2604.06209

[5] Lina Bariah, Qiyang Zhao, Hang Zou, Yu Tian, Faouzi Bader, and Mérouane Debbah. 2024. Large Generative AI Models for Telecom: The Next Big Thing?IEEE Commun. Mag.62, 11 (2024), 84–90. https://doi.org/10.1109/MCOM.001.2300364

[6] Richard Bean. 2024.Review into the Optus Outage of 8 November 2023 – Final Report. Technical Report. Australian Government, Department of Infrastructure, Transport, Regional Development, Communications and the Arts. https://www.infrastructure.gov.au/department/media/publications/review-optus-outage-8-november-2023-final-report

[7] Gordon Owusu Boateng, Hani Sami, Ahmed Alagha, Hanae Elmekki, Ahmad Hammoud, Rabeb Mizouni, Azzam Mourad, Hadi Otrok, Jamal Bentahar, Sami Muhaidat, Chamseddine Talhi, Zbigniew Dziong, and Mohsen Guizani. 2026. A Survey on Large Language Models for Communication, Network, and Service Management: Application Insights, Challenges, and Future Directions.IEEE Communications Surveys & Tutorials28 (2026), 527–566.

[8] Gaetano Bonofiglio, Veronica Iovinella, Gabriele Lospoto, and Giuseppe Di Battista. 2018. Kathará: A container-based framework for implementing network function virtualization and software defined networks. In2018 IEEE/IFIP Network Operations and Management Symposium, NOMS 2018, Taipei, Taiwan, April 23-27, 2018. IEEE, 1–9. https://doi.org/10.1109/NOMS.2018.8406267

[9] Yinfang Chen, Manish Shetty, Gagan Somashekar, Minghua Ma, Yogesh Simmhan, Jonathan Mace, Chetan Bansal, Rujia Wang, and Saravan Rajmohan. 2025. AIOpsLab: A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds.Proceedings of Machine Learning and Systems7 (2025).

[10] Yinfang Chen, Huaibing Xie, Minghua Ma, Yu Kang, Xin Gao, Liu Shi, Yunjie Cao, Xuedong Gao, Hao Fan, Ming Wen, Jun Zeng, Supriyo Ghosh, Xuchao Zhang, Chaoyun Zhang, Qingwei Lin, Saravan Rajmohan, Dongmei Zhang, and Tianyin Xu. 2024. Automatic Root Cause Analysis via Large Language Models for Cloud Incidents. InProceedings of the Nineteenth European Conference on Computer Systems (EuroSys ’24). Association for Computing Machinery, New York, NY, USA, 674–688.

[11] Alexander Clemm, Laurent Ciavaglia, Lisandro Zambenedetti Granville, and Jeff Tantsura. 2022. Intent-Based Networking - Concepts and Definitions. RFC 9315. https://doi.org/10.17487/RFC9315

[12] Denis Donadel, Francesco Marchiori, Luca Pajola, and Mauro Conti. 2024. Can LLMs Understand Computer Networks? Towards a Virtual System Administrator. In2024 IEEE 49th Conference on Local Computer Networks (LCN). IEEE, Caen, France, 1–10.

[13] ETSI ISG ZSM. 2018.Zero Touch Network & Service Management (ZSM) Standards. Technical Report. European Telecommunications Standards Institute (ETSI).

[14] Federal Communications Commission. 2024.February 22, 2024 AT&T Mobility Network Outage Report and Findings. Technical Report. FCC Public Safety and Homeland Security Bureau. https://docs.fcc.gov/public/attachments/DOC-404150A1.pdf

[15] Ari Fogel, Stanley Fung, Luis Pedrosa, Meg Walraed-Sullivan, Ramesh Govindan, Ratul Mahajan, and Todd Millstein. 2015. A general approach to network configuration analysis. In12th USENIX Symposium on Networked Systems Design and Implementation (NSDI 15). 469–483.

[16] Zhenbei Guo, Fuliang Li, Jiaxing Shen, Tangzheng Xie, Shan Jiang, and Xingwei Wang. 2023. ConfigReco: Network configuration recommendation with graph neural networks.IEEE Network38, 1 (2023), 7–14.

[17] Zhenbei Guo, Fuliang Li, Tangzheng Xie, Xingwei Wang, and Jiannong Cao. 2025. NetGenius: Routing Configuration Recommendation Based on Graph Neural Network.IEEE Transactions on Networking(2025).

[18] imsiddhant. 2020. Computer Networking Project 1: A Secure Two-Location Enterprise Campus Network. https://github.com/imsiddhant/Computer-Networking-Project-1.

[19] imsiddhant. 2020. Computer Networking Project 2: Two Campuses over OSPF with Telnet/SSH Managed Switches. https://github.com/imsiddhant/Computer-Networking-Project-2.

[20] Internetworks. 2024. OSPF CCNA CCNP Lab. The CCIE lab (blog), https://ccie.internetworks.in/2024/10/ospf-ccna-ccnp-lab.html. Posted 23 October 2024.

[21] Santosh Janardhan. 2021. More details about the October 4 outage. Meta Engineering Blog, https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/.

[22] Jeremy’s IT Lab. 2024. CCNA Mega Lab — Complete Network Configuration. Packet Tracer lab of the free CCNA 200-301 course, https://courses.jeremysitlab.com/.

[23] katejay. 2019. College-Network: Design College Network on Cisco Packet Tracer. https://github.com/katejay/College-Network.

[24] Polina Kirichenko, Mark Ibrahim, Kamalika Chaudhuri, and Samuel J. Bell. 2025. AbstentionBench: Reasoning LLMs Fail on Unanswerable Questions. InThe Thirty-ninth Annual Conference on Neural Information Processing Systems, Datasets and Benchmarks Track. Curran Associates, Inc., San Diego, CA, USA.

[25] Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, Shudan Zhang, Xiang Deng, Aohan Zeng, Zhengxiao Du, Chenhui Zhang, Sheng Shen, Tianjun Zhang, Yu Su, Huan Sun, Minlie Huang, Yuxiao Dong, and Jie Tang. 2024. AgentBench: Evaluating LLMs as Agents. InThe Twelfth International Conference on Learning Representations (ICLR). OpenReview.net, Vienna, Austria.

[26] Yang Liu, Dan Iter, Yichong Xu, Shuohang Wang, Ruochen Xu, and Chenguang Zhu. 2023. G-Eval: NLG Evaluation using Gpt-4 with Better Human Alignment. InProceedings of the 2023 Conference on Empirical Methods in Natural Language Processing, Houda Bouamor, Juan Pino, and Kalika Bali (Eds.). Association for Computational Linguistics, Singapore, 2511–2522. https://doi.org/10.18653/v1/2023.emnlp-main.153

[27] Madhusanka Liyanage, Quoc-Viet Pham, Kapal Dev, Sweta Bhattacharya, Praveen Kumar Reddy Maddikunta, Thippa Reddy Gadekallu, and Gokul Yenduri. 2022. A survey on Zero touch network and Service Management (ZSM) for 5G and beyond networks.J. Netw. Comput. Appl.203 (2022), 103362. https://doi.org/10.1016/J.JNCA.2022.103362

[28] Sathiya Kumaran Mani, Yajie Zhou, Kevin Hsieh, Santiago Segarra, Trevor Eberl, Eliran Azulai, Ido Frizler, Ranveer Chandra, and Srikanth Kandula. 2023. Enhancing Network Management Using Code Generated by Large Language Models. InProceedings of the 22nd ACM Workshop on Hot Topics in Networks, HotNets 2023, Cambridge, MA, USA, November 28-29, 2023. ACM, 196–204. https://doi.org/10.1145/3626111.3628183

[29] Sahil Minhas, Ritik Jaswal, Ankita Sharma, and Sanjay Singla. 2024. Revolutionizing Networking: A Comprehensive Overview of Intent-Based Networking. In 2024 International Conference on Emerging Innovations and Advanced Computing (INNOCOMP). 463–468. https://doi.org/10.1109/INNOCOMP63224.2024.00081

[30] Rajdeep Mondal, Alan Tang, Ryan Beckett, Todd D. Millstein, and George Varghese. 2023. What do LLMs need to Synthesize Correct Router Configurations?. InProceedings of the 22nd ACM Workshop on Hot Topics in Networks, HotNets 2023, Cambridge, MA, USA, November 28-29, 2023. ACM, 189–195. https://doi.org/10.1145/3626111.3628194

[31] Nokia / srl-labs. 2024. Containerlab: Container-Based Networking Labs. https://containerlab.dev.

[32] Maurizio Pizzonia and Massimo Rimondini. 2008. Netkit: Easy Emulation of Complex Networks on Inexpensive Hardware. InProceedings of the 4th International Conference on Testbeds and Research Infrastructures for the Development of Networks & Communities (TridentCom ’08). ICST, Brussels, Belgium, 1–10. https://doi.org/10.4108/tridentcom.2008.3155

[33] Yanyu Ren, Xianshang Lin, Chenxu Wang, Li Chen, Shuai Wang, Kaihui Gao, Dan Li, Yunfeng Bai, Chen Tian, Xinlei Zhang, Yungang Li, Tao Lin, and Ennan Zhai. 2026. Networked Agent Memory and Causality Representation: Experiences towards Interpretable Cloud-Scale Root-Causing. InProceedings of the ACM SIGCOMM 2026 Conference. Association for Computing Machinery, New York, NY, USA, 22 pages. https://doi.org/10.1145/3789240.3829145

[34] Devjeet Roy, Xuchao Zhang, Rashi Bhave, Chetan Bansal, Pedro Las-Casas, Rodrigo Fonseca, and Saravan Rajmohan. 2024. Exploring LLM-Based Agents for Root Cause Analysis. InCompanion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering (FSE ’24). Association for Computing Machinery, New York, NY, USA, 208–219.

[35] Mariano Scazzariello, Lorenzo Ariemma, Giuseppe Di Battista, and Maurizio Patrignani. 2020. Megalos: A Scalable Architecture for the Virtualization of Network Scenarios. InNOMS 2020 - 2020 IEEE/IFIP Network Operations and Management Symposium. IEEE, Budapest, Hungary, 1–7. https://doi.org/10.1109/NOMS47738.2020.9110288

[36] Mrinank Sharma, Meg Tong, Tomasz Korbak, David Duvenaud, Amanda Askell, Samuel R. Bowman, Esin Durmus, Zac Hatfield-Dodds, Scott R. Johnston, Shauna M. Kravec, Timothy Maxwell, Sam McCandlish, Kamal Ndousse, Oliver Rausch, Nicholas Schiefer, Da Yan, Miranda Zhang, and Ethan Perez. 2024. Towards Understanding Sycophancy in Language Models. InThe Twelfth International Conference on Learning Representations (ICLR). OpenReview.net, Vienna, Austria.

[37] Kuan-Hao Tseng, Niruth Bogahawatta, Yasod Ginige, Kosta Dakic, Arunan Sivanathan, and Suranga Seneviratne. 2026. SADE: Symptom-Aware Diagnostic Escalation for LLM-Based Network Troubleshooting.arXiv preprint arXiv:2605.04530(2026).

[38] Changjie Wang, Mariano Scazzariello, Alireza Farshin, Simone Ferlin, Dejan Kostic, and Marco Chiesa. 2024. NetConfEval: Can LLMs Facilitate Network Configuration?Proc. ACM Netw.2, CoNEXT2 (2024), 7:1–7:25. https://doi.org/10.1145/3656296

[39] Chenxu Wang, Xinlei Zhang, Rui Lu, Xianshang Lin, Xuan Zeng, Xinjie Zhang, Zhen An, Guohao Wu, Jiaqi Gao, Chen Tian, et al. 2025. Towards LLM-Based Failure Localization in Production-Scale Networks. InProceedings of the ACM SIGCOMM 2025 Conference. Association for Computing Machinery, New York, NY, USA, 496–511.

[40] Haopei Wang, Anubhavnidhi Abhashkumar, Changyu Lin, Tianrong Zhang, Xiaoming Gu, Ning Ma, Chang Wu, Songlin Liu, Wei Zhou, Yongbin Dong, Weirong Jiang, and Yi Wang. 2024. NetAssistant: Dialogue Based Network Diagnosis in Data Center Networks. In21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24). USENIX Association, Santa Clara, CA, 2011–2024.

[41] Zhihao Wang, Alessandro Cornacchia, Alessio Sacco, Franco Galante, Marco Canini, and Dingde Jiang. 2025. A Network Arena for Benchmarking AI Agents on Network Troubleshooting. arXiv:2512.16381 [cs.NI] https://arxiv.org/abs/2512.16381

[42] Zhaodong Wang, Samuel Lin, Guanqing Yan, Soudeh Ghorbani, Minlan Yu, Jiawei Zhou, Nathan Hu, Lopa Baruah, Sam Peters, Srikanth Kamath, Jerry Yang, and Ying Zhang. 2025. Intent-Driven Network Management with Multi-Agent LLMs: The Confucius Framework. InProceedings of the ACM SIGCOMM 2025 Conference. Association for Computing Machinery, New York, NY, USA, 347–362. https://doi.org/10.1145/3718958.3750537

[43] Zefan Wang, Zichuan Liu, Yingying Zhang, Aoxiao Zhong, Jihong Wang, Fengbin Yin, Lunting Fan, Lingfei Wu, and Qingsong Wen. 2024. RCAgent: Cloud Root Cause Analysis by Autonomous Agents with Tool-Augmented Large Language Models. InProceedings of the 33rd ACM International Conference on Information and Knowledge Management (CIKM ’24). Association for Computing Machinery, New York, NY, USA, 4966–4974.

[44] Zhiheng Xi et al. 2024. AgentGym: Evolving Large Language Model-Based Agents Across Diverse Environments. arXiv:2406.04151 [cs.AI] https://arxiv.org/abs/2406.04151

[45] Haoran Xu, Xuan Zeng, Xumiao Zhang, Xiaoxi Zhang, Yang Lv, Peng Zhang, Deke Guo, and Ennan Zhai. 2026. AIDA: Accelerating Root Cause Analysis for Multi-Vendor Device Failures with LLM-Powered Reasoning. InProceedings of the ACM SIGCOMM 2026 Conference. Association for Computing Machinery, New York, NY, USA, 17 pages. https://doi.org/10.1145/3789240.3829126

[46] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. InThe Eleventh International Conference on Learning Representations (ICLR). OpenReview.net, Kigali, Rwanda.

[47] Yajie Zhou, Jiajun Ruan, Eric S. Wang, Sadjad Fouladi, Francis Y. Yan, Kevin Hsieh, and Zaoxing Liu. 2026. NetArena: Dynamic Benchmarks for AI Agents in Network Automation. arXiv:2506.03231 [cs.NI] https://arxiv.org/abs/2506.03231