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