基于四大AI交互协议的AI测试平台架构

📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

---

在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全流程测试平台，具体的功能和工程结构如下：

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

​​