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

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

圖片

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

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

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

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

我們?nèi)粘５臏y試工作基本都需要經(jīng)歷需求-編碼-測試-驗收-發(fā)布五大階段。其中：

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

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

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

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

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

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

圖片