在IT互聯網技術領域，一個APP或系統背后的技術架構，有web層、server層、中間件、數據庫和底層的操作系統，看起來很復雜。后來大家逐漸形成了較為統一的標準，即通過API接口將不同層級之間串聯起來，最終才能形成一個能提供完善服務的APP應用。

AI領域目前也出現了類似的統一標準或者機制，來實現大模型、智能體等AI工具之間的協作通信。截至目前，AI交互協議共出現了三種代表性的范式，如下圖所示，分別是FC、MCP、A2A。這三大范式分別由不同公司或機構在AI發展的不同階段推出，解決了不同的問題。

圖片

上述三大AI交互協議中，Function Calling負責實現技術細節的點，MCP負責模型之間通信，A2A負責多個Agent之間的協作，基于這三大交易協議，我們基本可以構建一個完善的AI后端服務。

而AG-UI的出現，在我看來正好彌補了AI交互的協議棧的最后一塊短板，可以讓我們更好地構建AI應用，推動AI在工作場景中落地。即AG-UI可以推動AI應用“走向前臺”，讓AI從過去的后臺服務工具，升級為真正的生產力工具。

在半個月前聯合融管理社區的《踐行者》直播中，我曾分享過這樣一個觀點：基于Function Calling、MCP、A2A和AG-UI，我們可以推動服務于測試工作的全流程AI應用。下面是我對這一觀點的闡述：

1、大模型的本質是概率預測機器，本身不具備冪等性，在信息幻覺未被很好的解決之前，AI的落地應用一定要極度收斂，找到具體的應用場景。在場景選擇方面，盡可能貼近標準化場景，或者更易于標準化的場景。

我們日常的測試工作基本都需要經歷需求-編碼-測試-驗收-發布五大階段。其中：

• 需求相對來說不可控，且很難標準化；
• 編碼反而很容易標準化，且目前已經有了很好的最佳實踐和編碼規范；
• 測試和驗收階段對測試同學來說是最可控也最容易標準化的，無論是測試用例、測試數據還是自動化甚至性能測試腳本，都是確定性很強的場景。
• 發布階段，包含發布后的線上驗收和日常巡檢，現在大多都是基于自動化執行，這些都是較為容易可以規范和標準化的場景。

因此我們可以得到這樣一個明確的范圍，即：當前階段AI在研發測試領域落地，有如下幾個確定性較強的應用場景：

• 測試用例生成：特別是基于歷史迭代版本的主流程回歸測試用例diff；
• 測試數據生成：因為業務最小粒度對應的數據，之間都有明確的映射關系(商品對應的款色碼、sku、庫存)；
• 測試腳本生成：無論是自動化測試還是性能測試，都是基于具體的業務場景，有明確的預期目標和結果；
• 線上巡檢監控：線上主流程測試驗收、線上核心場景自動化巡檢、線上監控、線上發布變更(表結構變更-SQL)，同樣具有明確的預期目標和結果；

2、基于上述確定性較強的幾個場景，我們可以借助四大AI交互協議來構建全流程的測試平臺，思路如下：

• Function Calling：實現具體功能，如根據業務和數據映射關系生成測試數據；
• MCP：負責模型和其他工具(Agent)之間的通信，比如底層模型采用Qwen3，測試數據生成模塊封裝成Agent；
• A2A：負責實現多個Agent之間的通信，比如用例生成Agent、數據生成Agent、測試腳本生成Agent之間相互協作；
• AG-UI：實現后臺服務(從大模型到Agent再到具體功能點)和前臺的交互，最終構建為一個完善的AI全流程測試平臺；

3、基于上述第二部分的思路，我們可以實現這樣一個AI全流程測試平臺，具體的功能和工程結構如下：

圖片