AI 驅動的大數據自治：TCInsight 智能應對復雜運維挑戰

演講嘉賓｜熊訓德

編輯｜Kitty

策劃｜QCon 全球軟件開發大會

在大數據平臺高速發展的當下，生態擴張與業務量激增，致使大數據分布式組件問題愈發棘手，傳統專家運維模式捉襟見肘。以騰訊大數據龐大的規模為例，面對海量計算單元、繁雜技術棧以及千萬級任務管理，借助 AI 驅動實現大數據系統的故障和問題的快速洞察與自治能力，已成為行業迫切需求。

在 InfoQ 舉辦的 QCon 全球軟件開發大會（北京站）上，騰訊專家工程師熊訓德做了專題演講“AI 驅動的大數據自治：智能應對復雜運維挑戰”，他介紹了如何通過可拔插的決策引擎、以及數據專家自治智能體構建大數據智能管家，讓企業能夠理解如何高效、智能地處理復雜的運維場景，從而大幅提升大數據場景下運維效率與準確性，引領大數據線上系統邁向全面自治的實踐。

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

大數據系統自治背景與挑戰

首先，我簡要介紹一下整個大數據系統，以及其在自治背景下的相關挑戰。大數據系統本身組件眾多，涵蓋了從底層的 IaaS，到存儲、計算框架，以及上層的工具層等多個層面。具體來說，IaaS 層面涉及到機器本身的網絡和性能，而存儲層則包括分布式文件系統（如 HDFS）和對象存儲等。在調度方面，我們有 Kubernetes 和 Hadoop- 體系，以及針對 AI 方面的特定調度機制。再往上一層則是計算框架，例如 Spark 和 Flink 等流計算框架。最上層則是各種工具，這些工具在不同方面的使用都使得整個大數據系統的復雜性顯著增加。

大數據系統本質上是一個分布式系統。如果單機系統已經如此復雜，那么分布式系統則需要考慮數據的溯源以及在不同機器上的分布情況，無論是主從結構（master 和 slave）還是多工作節點（worker）的協作模式，都會使得整個系統在處理問題、查找根源以及故障恢復時變得極為困難。此外，大數據系統的數據處理鏈路通常非常長。例如，數據采集可能來源于多種源頭，如代理（Agent）、MySQL 數據庫，或者在物聯網場景下，可能是汽車或傳感器等設備。采集到的數據需要通過數據接入層，目前常見的架構包括 Kafka 或其他消息隊。接入后，數據會進入計算階段，可能是實時計算（如 Flink）或離線計算（如 Spark）。計算完成后，數據需要存儲到 HDFS 系統或對象存儲中。最后，在數據應用層面，我們可能需要進行預處理以供 AI 使用，進行訓練或推理工作，或者生成商業智能 BI 報表。因此，整個數據鏈路非常長，這也使得我們在進行故障根因分析或自治處理時，需要綜合考慮所有相關場景。

當我們處理大數據故障時，業務部門或客戶往往會提出一個關鍵問題：“何時能夠恢復？能否實現自動恢復，以盡快減少損失？”然而，我們在進行故障恢復或診斷時，高度依賴于運維 SRE 的專家經驗。通常情況下，如果沒有三年以上的大數據運維經驗，很難有效且完善地處理復雜的大數據故障。此外，由于整個診斷和故障恢復的時間鏈路非常長，導致整體效率低下。更糟糕的是，故障可能已經結束，而我們只能進行事后處理，此時大數據系統可能已經遭受了實際的損失。

大數據智能管家技術框架及
關鍵實現路徑

騰訊大數據智能管家 TCInsight 技術架構

基于這些背景，我們團隊在大約五年前提出了構建大數據智能管家 TCInsight 的想法，致力于解決大數據系統自治相關的工作。我們的大數據智能管家整體技術架構分為三層。

第一層是觀測層。它主要負責監控基礎設施即服務（IaaS），包括主機網絡等的監控數據，同時采集日志和關鍵事件。我們還將大數據組件，如 HDFS、Spark、Hive 和 YARN 等的關鍵監控日志事件進行統一上報。

第二層是服務分析層，主要負責數據實時處理和算法決策洞察。服務分析層分為三個部分。第一部分是實時分析，主要目的是快速處理數據，包括異常收斂。例如，當事件或告警過多時，我們需要迅速整合，否則會給運維 SRE 或研發人員帶來較大挑戰。我們會對數據進行基礎預處理。第二部分是離線服務，主要用于根因分析或自治服務時的離線分析和定時巡檢。在數據量較大時，離線分析尤為重要。第三部分是算法決策，主要涉及模型和算法庫的分析，以及知識庫和評測庫的建設，還包括離線訓練等工作。

第三層是應用層，主要負責大數據運維自治，并對外提供接口。應用層分為兩大塊：自治修復和自治決策。例如，以 Hive 為例，當業務側編寫了一個 SQL 查詢，可能會導致 HDFS 存儲空間被占滿，從而影響其他任務的提交。此時，我們需要快速對該 SQL 進行限制，或者在業務非常關鍵且不能直接終止的情況下，預測可能得存儲和計算量，進行自助彈性伸縮。此外，我們還需要進行冷熱數據分離，以實現成本分析和自助轉冷操作。在自治決策方面，我們需要判斷是否進行參數調優，因為某些參數調整可能需要重啟系統才能生效，這可能會擴大故障范圍。此時，我們需要做出關鍵決策，例如選擇擴容，或者讓 AI 參與具體工作。我們還可以進行錯峰執行，例如在 YARN 的多個隊列中，調整隊列的執行時間，以優化資源分配。

應用層還包括業務洞察部分，主要用于預測分析、成本分析和根因分析等工作。這些工作相對滯后，我們的目標是先恢復系統，然后再進行深入分析。此外，我們還會生成巡檢報表，并進行一鍵健康評估。健康評估在我們的系統中非常重要，它綜合評估了 IaaS、存儲、調度和計算等各個部分的健康狀況，為關鍵自治決策提供依據。

在架構的中間部分是我們的算法或引擎層。引擎分為兩部分：規則引擎和我們自主研發的元啟引擎。元啟引擎結合了 AI 算法和我們內部的混元大模型。規則引擎主要用于執行明確的操作，例如擴容，以緩解問題。對于復雜或關聯性較高的場景，我們會接入算法或大模型，以提升系統的健康狀況。

接下來，我會詳細說明我們在大數據智能管家過程中的一些關鍵思考和實現能力。

分層的大數據運維框架 - 漸進式自治

由于大數據體系的復雜性，TCInsight 實現自治的是一個漸進式的過程。當我們接手一個系統時，不能期望所有大數據運維工作能夠立即實現完全自治。實際上，我們基于一個較為普遍的理念：在沒有一線專家或專業人才的情況下，一線人員或客戶也能夠實現自治處理。

我們根據問題的復雜程度進行分類處理：對于簡單重復且解決方案確定問題，我們直接采用 AI 驅動的方式進行處理。目前，這類問題大約占我們總問題的 10% 左右。然而，剩下的 90% 問題尚未能完全實現自治。對于這部分問題，我們希望通過售后體系中的專項人員和 SRE 的共同努力，借助我們之前提到的平臺層，利用大模型和 AI 增強能力，持續為系統提供支持。

在此基礎上，我們期望通過三年以上經驗的產研人員或 SRE 專家，進一步強化知識庫和工具建設。通過這種逐步積累和優化我們的產品能力，我們希望能夠逐步提高自治的比例，最終使其達到 90% 以上。

多智能決策引擎思考和設計一問題域

在業界，主要有三種常見的方法：顯式編程、基于優化方法的處理以及專家系統。第一種顯式編程對于研發人員來說并不陌生，它本質上是通過編寫規則或工作流來構建一個簡單的規則引擎，從而實現直接的決策。例如，當存儲使用率超過 75% 時，系統自動觸發擴容操作。這種方法簡單直接，但靈活性有限。

第二種是基于優化方法的處理。在大模型尚未普及的時代，我們通過優化模型來提升系統性能。例如，原本只能優化 40% 的系統，通過采用貪婪算法或聚合模型等技術，可以將其優化效果提升至 80% 以上。這種方法更多地依賴于深度學習和大模型的強大能力，能夠更好地處理復雜的優化問題。

第三種是智能全自治域系統。全自治域系統的核心在于利用專家的經驗和知識，盡管專家人數有限，但他們的經驗可以通過系統化的方式賦予平臺更強的能力。專家系統的關鍵在于如何將專家的經驗轉化為可操作的決策邏輯。

在明確了這些決策引擎的技術路徑后，我們進一步思考了在大數據領域構建智能決策系統的關鍵問題。首先，數據的可用性至關重要。無論是基于 AI 的訓練還是大模型的應用，數據標注的準確性和完整性是基礎。如果數據標注不足，可能會導致模型出現幻讀甚至錯誤的輸出，從而影響決策的準確性。

其次，系統的可解釋性也是一個關鍵問題。專家和文檔作者需要確保知識庫中的內容不僅系統能夠理解，而且一線人員和客戶也能夠輕松掌握。這一點直接關系到決策的準確性和適用范圍。

最后，實時性要求也不容忽視。我們的目標是先快速恢復系統，后續再進行深入分析。這就要求決策過程和最終的行動必須足夠迅速，以滿足實時性的需求。

綜合考慮以上因素，在決策引擎的選擇上，我們決定結合規則引擎和專家系統的智能決策引擎共同構建了全自治域系統 TCInsight。這種方法既能夠利用規則的明確性和可操作性，又能借助專家系統的靈活性和經驗優勢，逐步提升系統的自治能力和決策準確性。

Al 驅動的規則引擎自治系統

在構建基于規則引擎的知識系統時，我們首先對系統中的各類數據進行了統一管理。這些數據包括指標（metrics）、日志（log）以及事件（event），我們會將它們統一上報至我們內部構建的數據庫適配系統。該系統是基于 Inpara 和 Flink 構建的，數據最終會被存儲到時序數據庫中。隨后，我們利用 Flink 對數據進行預處理，并結合訓練好的模型以及特征庫，對數據進行特征分析。基于這些分析，我們會進行基礎的異常檢測、關聯分析以及趨勢預測等工作，從而形成初步的告警摘要和預測摘要。

例如，我們可能會收到告警信息，提示 HDFS 存儲空間即將用盡，或者 YARN 隊列的等待時間過長，又或者 StarRocks 或 Trino 的 CPU 占用率過高，某個 SQL 查詢掃描的數據量過大，超出了設定的閾值。基于這些信息，我們會生成整體的告警或預測摘要。如果預測顯示 HDFS 的增長趨勢過快，可能會在 5 分鐘內被填滿，我們就會對 IaaS、存儲、引擎和調度等各個層面進行評估，計算它們的健康分數。如果健康分數低于某個閾值，或者即將達到該閾值，我們就會啟動規則引擎進行處理。例如，我們可能會嘗試簡單的擴容操作來緩解問題，或者在業務允許的情況下，直接終止一些不關鍵的 SQL 查詢或任務，以減少資源占用。

在執行這些操作后，我們會制定一個詳細的執行計劃。以擴容為例，在執行擴容操作之前，我們需要先檢查 HDFS 的整體狀態是否正常，數據是否均衡分布，以及 NameNode 和 DataNode 之間的流量是否穩定。因為如果流量過大，可能會導致 DataNode 負載過高，甚至引發更嚴重的問題。只有在確認一切正常后，我們才會通過 IaaS 層擴容機器，并在擴容完成后進行數據均衡操作，以確保系統恢復正常。

完成這些操作后，我們會記錄整個過程的狀態，并進行反饋。如果擴容后監控數據顯示系統恢復正常，那么我們認為這次自治決策是成功的，并將結果記錄下來作為后續處理的參考。然而，如果擴容后情況反而惡化，例如數據傾斜導致 SQL 查詢速度變慢，引擎側的健康分數急劇下降，那么我們會緊急通知專家介入，重新審查整個分析過程。

這種基于規則引擎的處理方式具有高效和準確的特點。目前，在我們系統中，基礎指標的覆蓋率達到 90%，存儲場景的覆蓋率為 50%，任務場景的覆蓋率為 30%。在周期性任務的處理上，我們已經能夠覆蓋 90% 的場景。在異常診斷方面，我們能夠處理 70% 的異常場景，整體數據表現良好。

這并不意味著我們的工作已經完成。實際上，大數據系統的復雜性遠超我們的預期。例如，我們在兩年前曾遇到一個問題：在對 HDFS 進行擴容后，發現數據分布不均衡，導致 Spark 任務的執行速度反而變慢。從常理來看，擴容后資源增加，任務執行速度應該加快，但實際上并非如此。原因在于擴容后數據的均衡性并沒有達到預期，同時業務側提交了大量任務，導致系統整體性能下降。這說明我們目前只能處理已知的情況，而對于一些未考慮到的復雜場景，我們還需要進一步優化和改進。

Al 驅動的全自治域系統

基于上述思考，我們提出了一個全新的全自治系統概念。與之前的方法不同，我們在決策過程中引入了大模型的相關分析。無論是當前備受關注的 DeepSeek，還是此前我們接觸過的其他類似模型，其核心優勢在于執行步驟和推理能力。因此，我們開始嘗試將大模型的相關功能融入整個自治決策系統中。

在預測和分析階段，系統仍然會進行數據預處理和特征分析，并開展異常檢測、關聯分析以及趨勢預測等工作。這些信息匯總后，會生成初步的概述信息。然而，與以往不同的是，由于引入了大模型，我們需要構建一個“優先級與目標系統”（以下簡稱“目標系統”）。我們會在這個目標系統中預先定義優先級和目標。例如，對于存儲系統，我們設定存儲使用率不得超過 80%，并且數據不能快速轉冷；對于引擎，我們希望優化其執行時間；對于上層應用，我們要求其不能出現錯誤。這些優先級和目標會被配置到目標系統中，生成診斷建議。

隨后，我們會將這些數據輸入到混元模型中，并結合我們之前的決策分析結果，生成具體的執行步驟。這些執行步驟融合了傳統執行引擎、規則引擎以及傳統深度學習算法或基礎算法的執行計劃。執行計劃生成后，我們會重新預檢測系統狀態，重新評估預測分析結果以及執行計劃可能帶來的狀態變化。

如果發現執行該計劃后系統健康分數可能更低，即情況可能惡化，那么我們的專家團隊會介入。我們會創建一個專家工單，讓專家對執行計劃進行評估，并決定是否停止執行。相反，如果預測和狀態評估顯示執行計劃后系統健康分數將高于目標值，那么我們會執行該計劃，并將執行計劃標記后存入知識庫。

執行完成后，我們會繼續進行預測分析、異常檢測以及整體狀態評估。如果系統健康度如我們預測的那樣有所提升，我們會重新進行標記和分析，以便系統能夠繼續執行后續操作。

數據質量對預測影響 & 優化

在構建整個系統的過程中，我們花費了大量時間進行調試，尤其是在系統上線試運行階段。現在，我想重點介紹一下我們在調試過程中采取的關鍵措施，這些措施讓系統更加穩定，并顯著提高了預測的準確率。

對于從事時序預測研究的人員來說，一個常見的問題是如何處理上報數據中的斷點。這種情況可能由多種原因引起。例如，當系統發生故障時，機器的 CPU 或內存可能已經滿負荷運行，導致在關鍵時刻數據丟失。在分布式系統中，這種數據丟失可能會引發上層系統的亂序操作。假設我們上報的時間是 12 點整，但由于長時間的內存不足（OOM）或 CPU 負載過高，數據可能直到 12 點零 5 秒甚至 12 點零 1 分才上報。然而，故障的實際發生時間并非 12 點零 1 分，但上報時間卻顯示為 12 點零 1 分，這就導致了數據的亂序問題。此外，還可能出現重復上報的情況，即同一條日志或指標連續上報多次，這使得我們難以確定真正的時間點或事件。

這些問題引發了幾個關鍵的挑戰。首先，當數據出現斷點時，我們需要決定是否進行插值。目前業界常用的算法包括直接丟棄數據或采用簡單的插值方法。對于故障場景來說，直接丟棄數據可能并不是一個好方法，因為這些數據代表了當時關鍵的監控指標。即使進行插值，如果處理不當，也可能導致數據不準確。此外，如果數據質量不佳，將嚴重影響我們的預測能力和關鍵異常處理能力。

我們重點對數據質量進行了優化，主要從三個方面入手。首先，我們對時序指標或日志的有效性進行評估。以往最簡單的評估方式是檢查數據是否超過完整性閾值。另一種常見的做法是檢查數據是否滿足差分閾值，或者在 IoT、時序場景中直接進行簡單的拼湊。我們提出了一種基于完整性的實際評估方法。具體來說，我們將每個數據進行分段處理，然后基于自回歸模型對每個分段進行評估檢測。如果數據通過了自回歸分析的評估，我們認為這些數據是可用的。

在確認數據可用之后，我們面臨的另一個問題是數據的補齊和連接。目前常用的方法包括直接進行差分或簡單的拼接。我們的思路是采用自回歸預測和自回歸拼接的方法。這種方法的優勢在于處理速度快，能夠快速對分段數據進行處理。此外，這種方法既能進行預測，又能完成數據合并操作。通過這種方法，我們顯著提升了數據的有效性，整體提升了 10%。在周期性任務和異常診斷方面，準確性提高了 30% 以上。同時，時序預測的時間也縮短了 28%。

我們在構建大數據專家庫智能體的過程中，嘗試了一種與業界常見的做法略有不同的方案。我們不僅實現了向量檢索，還引入了文本檢索。這種設計的選擇源于我們在構建知識庫時對傳統向量檢索方法的深入思考。

傳統向量檢索在相關性分析方面表現出色，例如在使用 FastText 等工具時，能夠快速識別出與查詢相關的數據。然而，這種方法存在一個明顯的局限性：它無法直接反映召回數據的質量，也就是說，在檢索過程中，我們難以預估數據的相關性是否真正符合需求。為了解決這一問題，我們引入了文本檢索機制。通過文本檢索，我們能夠更清晰地理解數據之間的關聯性，尤其是在知識庫的構建過程中。

當我們構建知識庫時，一個常見的思路是將操作步驟進行分層。以擴容操作為例，它可能與存儲層有很強的相關性，但這種相關性背后的原因并不明確。通過文本檢索，我們可以補充這些缺失的上下文信息，從而更全面地理解數據之間的關系。

大數據系統通常分為多層，包括大數據存儲層、調度、和引擎等等。這些層之間的相關性可能很強，但它們之間的索引空間檢索范圍并不像我們想象的那么大。基于這些考慮，我們采用了騰訊的 ES 的架構，結合文本分析和向量檢索的優勢。這種架構不僅支持大規模的讀寫操作，還具備高效的檢索能力。

通過這種方式，我們能夠更好地處理組件之間或分層之間的關聯關系，使得各部分之間的距離更近，從而提高系統的整體效率。在故障恢復之后，除了通過冷啟動將知識庫連接起來，我們還利用工單系統、客戶反饋和專家系統，結合混元大模型，實現自動化的分類和歸納，持續完善知識庫的建設。

實踐效果與案例分享

A 驅動的 HDFS 存儲規則引擎自治

我們來看基于 HDFS 存儲規則引擎的自治。這里的關鍵在于如何快速抽取和分析 HDFS 的 FSImage，以及如何準確把握特征點。我們知道，HDFS 的源數據是以樹形結構存儲的，而現有的工具無法對這種樹形結構進行并行化處理。為了解決這個問題，我們將工作拆分為兩部分：第一部分是直接分析源數據的表結構，這樣就不需要處理整個樹形結構；第二部分是將樹形結構手動拆分為多個并行部分，從而實現并行化處理。

通過這種方式，我們能夠對表分區和關聯分區進行拆分，并進行關聯分析。同時，我們還能觀察到數據的整體冷熱分布，以及后續一段時間內的增長趨勢。基于這些信息，我們利用規則引擎做出決策，確定關鍵目標。例如，如果當前存儲的健康狀況良好，但成本健康分較低，我們可能會自動執行降冷操作。如果發現整個系統的擴容必要性較高，我們可能會進行柔性擴容或自動剔除操作。

A 驅動的 SparkSql 調優全自治域

接下來分享一個關于 Spark 自動調優的案例。這個想法最初是在項目立項時提出的，當時的想法非常直接：將 Spark 的所有相關信息，包括 SparkSQL、配置信息、上下文信息，以及存儲和引擎等，全部整合到一個系統中。我們甚至將所有的 Executor、邏輯計劃和物理計劃等也納入其中。初步測試結果顯示，這種方法的準確率大約為 30%。然而，我們發現其中約 30% 的結果與實際需求并無相關性，還有 20% 到 40% 的結果存在明顯問題。究其原因，通用的大模型缺乏專家級的領域知識，這導致了準確性的不足，同時還出現了幻覺問題。所以我們引入了貝葉斯和 RL 專家系統建議的優化提升 sparksql 的調優效果。在 POC 和線上，目前實現無人工值守自治調優性能效果比工作五年經驗還好 10%。

在降本效果相當不錯，之前主要關注的 SparkSQL 本身，沒有考慮存儲和 IaaS 層面的相關影響。在最近我們又升級了這個系統，會將 YARN 調度、HDFS 存儲以及相關的管控日志等信息統一匯總，形成一個詳細的概述。我們的目標是通過調優實現時間消耗的最優化。為此，我們將這些上下文信息輸入模型，并進行在線分析。分析結果不僅包括計算相關的最優參數，還涵蓋了調度配置、內核參數的配置下發等。然而，這些配置下發后并不能立即生效，可能需要執行 SQL 控制操作，或者在某些情況下，進行刷新操作。基于這些分析結果，我們會生成一個調參執行計劃，然后重新提交任務，并對時間消耗的最優化和系統的整體健康度進行評估。

后續發展和思考

目前我們在自治雖然有些突破，但還遠遠不夠。正如之前提到的，我們已經解決了關鍵的 10% 的知識問題，這確實幫助我們解決了許多難題。然而，我們還有許多需要思考和改進的地方。

首先，我們需要持續優化路徑。以 SparkSQL 為例，雖然我們已經對 SQL 進行了優化，但關鍵信息之間的互聯性仍然不足。例如，當我們直接將 HDFS 的最大存儲容量納入考量時，其時間和空間的關聯性處理得并不理想。目前，我們主要依賴簡單的專家系統來判斷優化效果，而這種判斷往往缺乏系統化的分析。因此，我們計劃在未來持續加強這方面的建設。

其次，我們在決策時的目標相對單一。目前，我們的決策主要基于時間預測和健康分的調度，但對于復雜的大數據系統來說，多鏈路決策的完善性仍有待提高。例如，在關鍵決策時刻，我們會引入多智能體。目前，我們對決策準確性的把握還不夠高，準確率可能只有 70% 到 80%。因此，我們需要持續優化決策過程，以提高準確率。

最后，關于專家系統，雖然我們在最后一步會強制讓 SRE 專家介入，但在實際操作中，我們發現專家介入的時機和方式需要進一步優化。例如，在配置下發后，我們可能需要再次介入，因為有些系統配置是立即生效的，而有些則需要存儲后才能生效。因此，我們需要在關鍵節點上進行更精準的知識干預。

除了上述問題，我個人以及我們團隊還需要持續思考和探索后續的應用方向。首先是 agent-Drive 的根因定位（RCA）。我們在故障恢復和根因定位方面還有很大的提升空間。一方面，我們需要更快地響應問題，避免客戶受到影響；另一方面，我們需要提高根因分析的效率。

其次，我們希望實現逐步緩解的操作。目前，我們的操作通常是直接針對目標進行的，但我們認為應該分階段、分層次地觀察和評估每個環節的動作是否對整體健康服務和知識系統有效。雖然我們已經有了一個反應式（Reactive）模型，但它主要集中在直接緩解問題上。我們希望通過逐步緩解的方式，更全面地評估和優化系統。

最后，安全性是我們需要持續關注的一個重要方向。在大模型 RL 或智能體的開發過程中，我們可能會面臨各種安全風險。一方面，我們需要確保優化操作不會引入更大的問題；另一方面，由于多個團隊之間可能共享知識庫，我們需要防止信息泄露或因幻覺問題導致其他團隊誤讀知識庫信息。這將是我們在未來持續探索的方向。

嘉賓介紹

熊訓德，騰訊專家工程師，騰訊云 EMR 技術負責人，有豐富的大數據領域系統架構、開發、專家系統調優經驗。

會議推薦

復雜任務，不再主要依賴冗長提示詞硬扛了。Agent Skills 將專家流程與工具能力封裝為可復用數字技能，由大模型按需調用，推動 AI 從通用助手邁向穩定的專業執行體。圍繞 Skills 平臺化、模型推理增強與垂直場景落地，Agent 時代正在加速到來。

為了深入探討 Agent Skills 在實際應用中的潛力與挑戰，在 4 月 16 日 -18 日舉辦的 QCon 北京大會上，我們特別邀請了 Ubiquiti Quality Assurance 蔡明哲帶來專題演講《從單點輔助到 Agent 閉環：基于 Agent Skills、MCP 與 Playwright 的全鏈路智能化測試實踐》。他將聚焦智能化測試在質量保證中的落地實踐，詳細拆解 Agent Skills、Playwright Agent 與 MCP 的職責分工與組合范式，并介紹如何從案例生成到自動修復實現全流程工程實踐落地。