當“正確”並非確定時驗證智慧體行為

現代軟體測試建立在一個脆弱的假設之上：正確行為是可重複的。對於確定性程式碼，這一假設基本成立。但對於像GitHub Copilot Coding Agent（即Agent Mode）這樣的自主智慧體，尤其是當我們探索整合的“計算機使用”前沿時，這一假設幾乎立刻崩潰。

隨著智慧體從簡單的程式碼建議擴充套件到與UI、瀏覽器和IDE等真實環境互動，正確性變得多路徑化。載入螢幕可能出現或消失，時間偏移，多個有效的動作序列可能導向相同的結果。除非我們的GitHub Actions工作流足夠健壯以應對這種變異，否則經常會出現智慧體成功完成任務但測試仍然失敗的情況——即阻止生產的“假陰性”。

本文探討如何從脆弱的逐步指令碼轉向用於智慧體驗證的獨立“信任層”。我們將演示一個關注關鍵結果而非固定路徑的模型，提供一種可解釋、輕量級且適用於實際CI管線的驗證方式。

智慧體驅動驗證的挑戰

假設你負責一個依賴Copilot Agent Mode驗證實際工作流的GitHub Actions管線。該智慧體可能利用計算機使用，在容器化雲環境中導航以進行工作流驗證。週二構建是綠色的，週三測試失敗——儘管程式碼沒有變化。原因是託管執行器上的輕微網路延遲導致載入螢幕多持續了幾秒。智慧體等待、適應，併成功完成了任務。但CI管線仍然將執行標記為失敗——不是因為任務失敗，而是因為執行路徑不再匹配記錄的指令碼或斷言時間。智慧體沒有失敗，驗證失敗了。這暴露了三個反覆出現的痛點：假陰性（任務成功但測試執行器無法容忍變化）、脆弱的基礎設施（測試因時間、渲染或與環境噪聲無關的原因失敗）、合規陷阱（結果可能正確，但因智慧體行為偏離測試預期而被標記為迴歸）。

我們正處於一個過渡期：智慧體系統如GitHub Copilot Coding Agent正在加速開發，但我們傳統的驗證方法仍然僵化。在確定性軟體中，正確性只是將特定輸入與已知輸出匹配。但對於智慧體，中間過程有意是非確定性的。正確性不是關於遵循一組規定的步驟，而是關於“可靠地實現關鍵結果”。為了規模化這些系統，我們需要一個能夠區分“偶然噪聲”（如載入螢幕）和“關鍵失敗”（如未能儲存資料）的驗證框架。正確性從“這發生了嗎？”轉變為“為了成功是真的，必須發生什麼？”

現有測試方法為何失效

傳統測試工具在執行路徑固定時工作良好，但行為分支時它們開始破裂——不是因為工程不良，而是因為它們假設穩定序列。當我們將它們應用於Copilot Coding Agent（包括在容器化環境中導航時）時，四種常見正規化的侷限性變得明顯：基於斷言的測試（需要手動指定每個檢查，且無法處理有效替代路徑）、記錄回放工具（對環境噪聲高度敏感）、視覺迴歸測試（孤立比較截圖，無執行流理解）、ML或acles（需要大量訓練示例，且無法解釋）。這些方法共享一個結構假設：正確性由特定可觀察狀態序列定義。對於智慧體系統，這一假設破裂。要建立開發者信任，我們必須超越檢查線性指令碼，開始驗證結構化行為。

重新定義正確性：關鍵行為與可選行為

為了超越脆弱測試並構建信任層，我們必須從根本上改變“正確”的定義。在智慧體系統中，正確執行不必看起來相同，但必須共享共同邏輯結構。我們可以將智慧體行為分為三類：關鍵狀態（成功必須達到的里程碑，如“搜尋結果”螢幕）、可選變化（偶然狀態如載入旋轉器）、收斂路徑（不同的步驟序列最終在相同結果處匯合）。載入螢幕可能出現也可能不出現，但搜尋結果必須出現。只有其中一個決定正確性。

從直覺到理論：支配分析

“必須有”與“偶然”行為之間的區別源於編譯器理論中的支配關係。在控制流圖中，如果從開始到B的每條路徑都必須經過A，則節點A支配節點B。透過將支配分析應用於智慧體執行軌跡，我們可以自動識別哪些狀態是強制的、哪些是可選的、以及不同路徑在哪裡收斂。這使我們能夠提取一個最小、可解釋的正確性定義。

將執行建模為圖而非指令碼

為了捕捉智慧體行為的複雜性，我們必須摒棄將執行視為線性一維指令碼的做法。我們的框架使用一種稱為字首樹接收器（PTA）的圖結構對行為建模。節點表示可觀察狀態（如UI截圖或程式碼快照），邊表示轉換（點選、按鍵或API呼叫）。圖允許我們表示分支和收斂——這些概念線上性指令碼中無法捕捉。分支解釋了非確定性環境變化，收斂標識不同路徑重新匯合的點，表明智慧體成功導航了變異並返回主任務流。透過將表示從步驟序列轉變為結構化行為模型，我們停止懲罰智慧體走不同路徑，而是開始驗證它們是否遵循邏輯上合理的路徑。

如何解決：結構化的正確性方法

為了將智慧體從實驗性演示推進到生產級基礎設施，我們的團隊開發了一種新穎的驗證演算法，該演算法透過示例學習，而不是依賴僵化指令碼。我們關注一個複雜的非確定性環境：透過“計算機使用”導航Visual Studio Code的AI智慧體。透過觀察僅2-10個成功會話，我們的演算法自動構建一個“基準真值”模型，區分智慧體的有效變異和實際失敗。工作流包括：PTA構建（收整合功軌跡並轉換為圖）、語義合併（使用三層等價檢測合併軌跡，結合快速視覺指標和LLM語義分析）、提取骨架（透過支配分析識別關鍵狀態）。這種方法獨特強大，因為它不需要手動規範，也不需要進行大規模模型訓練。結果模型是實際執行狀態的圖，決策完全可解釋。當驗證失敗時，演算法透過識別哪個關鍵狀態被錯過提供清晰的失敗原因。

狀態等價性：決定兩個狀態何時“相同”是智慧體驗證中最困難的問題。我們使用三層檢測框架：視覺指標（快速感知雜湊和結構相似性）、語義分析（多模態LLM處理模糊情況）、保守合併（僅當模型確定等價時合併狀態）。這不是樸素的畫素比較，也不是“LLM揮手”——透過防禦性和節儉地使用LLM解決特定模糊性，框架既健壯又能檢測實際迴歸。

支配分析提取實質內容：一旦多個軌跡合併為統一圖，演算法應用支配分析隔離任務的骨架。狀態A支配B如果從開始到B的每條路徑必須經過A。我們定義狀態為關鍵如果它是任務成功完成的支配者。透過計算這些數學關係，演算法自動區分“必須有”里程碑和“偶然”噪聲。在VS Code實驗中，“搜尋對話方塊”狀態被識別為關鍵里程碑，因為它是數學支配者——沒有觸發搜尋就不可能到達結果。相反，“載入”螢幕不支配任何東西，因為在更快的執行中它可以被繞過，演算法將其標記為可選變異。透過將這些關鍵節點提取為支配子樹，我們建立了一個最小、可解釋的正確性定義。

驗證新執行：建立支配樹後，驗證新軌跡成為結構性比較。我們使用拓撲子序列匹配：不要求新軌跡與參考完全相同，只要求關鍵狀態以正確相對順序出現。處理額外狀態：如果參考序列是A→B→C，智慧體產生A→X→B→Y→C，測試仍然透過，因為額外狀態被視為偶然噪聲。檢測失敗：僅當關鍵狀態被跳過或以錯誤順序出現時觸發。評分與可解釋性：框架提供覆蓋度指標（匹配關鍵狀態百分比）和失敗原因（如“狀態‘搜尋結果’在‘搜尋對話方塊’後從未達到”）。這使驗證從“黑箱”轉變為開發者可除錯的診斷工具。

評估結果：我們設計了實驗比較支配樹方法與智慧體自我評估（CUA報告自身成功）。結果：支配樹方法準確率100%，精確率100%，召回率100%，F1分數100%，而CUA自我評估準確率82.2%，F1分數69.8%。最顯著的是，智慧體內部自我評估完全無法識別“非缺陷”場景（F1分數0%），而獨立信任層在正確識別失敗是否由智慧體執行錯誤而非產品迴歸方面達到52.2% F1分數。結構性驗證以很大優勢勝出。

整合到開發者工作流：信任層框架設計為整合到GitHub Actions管線（減少環境噪聲導致的假陰性）、迴歸測試（使用過去成功軌跡建立基準真值模型）、智慧體評估（測量關鍵命中率）、UI自動化。目標是將智慧體從“實驗性演示”推進到“生產基礎設施”。

當前侷限和未來工作：需要成功軌跡示例（2-10個）、依賴LLM進行語義等價檢查（引入外部依賴和延遲）、無法檢測狀態持續時間過長。未來工作包括新增時間約束和負約束、層次化抽象（將低階截圖聚類為高階概念）、線上學習（即時重新計算支配者）。

為什麼這很重要：隨著AI智慧體從實驗性演示過渡到核心基礎設施，驗證必須進化。我們不需要黑箱模型評判其他黑箱模型，我們需要可檢查、可推理和可信賴的結構性保證。透過將經典編譯器理論與多模態AI結合，我們展示了從少數示例學習可解釋的魯棒成功定義是可能的。信任層框架提供高效學習、操作魯棒性和完全透明。隨著計算機使用在AI原生開發生命週期中的採用增加，這些保證至關重要。我們的可驗證自主性之旅才剛剛開始。