AINTMA：面向自主测试管理的代理式AI架构，集成生成式智能、安全云通信与自适应质量分析

# 引言
来源：https://arxiv.org/html/2607.20452  
AINTMA：融合生成式智能、安全云通信与自适应质量分析的自主测试管理智能体AI架构

Vinil Pasupuleti¹,ᵃ, Shyalendar Reddy Allala²,ᵇ, Siva Rama Krishna Varma Bayyavarapu³,ᶜ, Shrey Tyagi⁴,ᵈ, Srinivasateja Songa⁵,ᵉ

¹国际商业机器公司（IBM），美国南卡罗来纳州  
²Global Atlantic Financial，美国印第安纳州  
³Docusign，美国印第安纳州  
⁴Salesforce Inc，美国北卡罗来纳州  
⁵The Home Depot，美国佐治亚州  

ᵃ通讯作者：[email protected]  
ᵇ[email protected]  
ᶜ[email protected]  
ᵈ[email protected]  
ᵉ[email protected]  

###### 摘要

现代软件质量保证需要能够在分布式云环境中进行自适应决策的智能自主系统。本文提出AINTMA（自主智能测试管理架构），一个将传统测试管理转变为自主质量智能生态系统的多智能体AI系统。AINTMA部署了六个专门化AI智能体（测试发现、风险评估、强化学习优先级排序、执行编排、生成式质量智能和云安全监控），通过基于云原生微服务基础设施的安全多智能体通信框架进行协调。生成式质量智能体采用大语言模型生成简明易懂的质量叙述、缺陷风险摘要以及数据增强的测试建议。RL优先级排序智能体将测试选择建模为马尔可夫决策过程，从大规模历史测试执行数据（47个特征，滚动36个月窗口）中学习上下文策略。安全云通信通过零信任API网关（带OAuth2/JWT认证）、加密的智能体间消息传递和多租户隔离来强制执行。在12个异构软件项目上为期18个月的评估显示：测试优先级排序准确率88.4%（APFD，对比随机51.2%，最佳商业基线82.1%）；测试周期时间减少43%；缺陷逃逸率从8.3%降至2.1%；9个月回收期时ROI为340%。该智能体架构可扩展到50,000+个测试用例，响应时间低于400毫秒，生成式智能模块获得4.3/5.0的开发人员有用性评级。AINTMA证明，结合自主多智能体协调、生成式智能和安全智能连接的智能体AI，能够从根本上推进云规模企业环境中的软件质量管理。

关键词：智能体AI，生成式AI，测试管理，多智能体系统，云安全，强化学习，数据分析，智能连接

企业CI/CD流水线速度很快。一次提交可以在不到三十分钟内触发完整的回归测试，而无需任何人动手。但尚未自动化的是建立在此之上的判断层。这次变更哪些测试真正重要？自上次迭代以来，风险在哪里悄然累积？今天早上的结果对周五发布的版本意味着什么？这些问题仍然由人来回答，而且通常是在压力下，回答的质量完全取决于谁有空。现有的工具如Jira、TestRail和Zephyr并非为此设计。它们是工作流工具。它们并不尝试进行自主推理。智能体AI改变了这里实际可能的范围：能够在其环境中推理、跨步骤规划并相互协调的智能体[¹,²]可以承担目前将质量工程师束缚在仪表盘前的认知工作。

我们构建AINTMA是为了测试一个多智能体系统是否能够在生产环境中处理所有这些认知工作。它不是现有TMS的包装器，而是一个全新设计：六个专门化的智能体各自负责一个任务，通过带类型化的发布-订阅网格进行通信，并全程采用零信任安全。其理念是专门化能让每个智能体真正擅长自己的工作，而不是在所有方面都表现平庸。这一理念在18个月的实际运行中是否成立，正是本文报告的内容。

先前的工作涵盖了其中的部分内容。测试优先级排序有坚实的RL文献基础，可追溯到Spieker等人[³]。使用LLM生成测试[⁴]进展迅速。自主CI/CD[⁵,⁶]和AI辅助测试[⁷,⁸]也都有所进展。但将RL优先级排序、LLM生成的质量叙述和零信任智能体间安全结合在一起并在一个生产部署中实现，这此前尚未完成。这正是AINTMA所做的。

主要贡献在于架构：六个智能体、类型化事件网格、零信任通信。但还有另外四个值得注意的点。第3.4节描述的GQIA读取分析数据并生成报告，这些报告会根据阅读者是工程师、经理还是高管而截然不同。基于马尔可夫决策过程的RL优先级排序智能体在三年的CI历史数据上训练，在12个项目上达到了88.4%的APFD。零信任通信层对每条智能体间消息进行签名并维护完整的审计日志。实地研究本身——跨越50,000+个测试用例的18个月——产生了第5节中的数字。

## 相关工作

### 智能体AI系统

自主软件智能体的理论根源可追溯到20世纪90年代初[¹]。此后的大部分时间里，技术并未跟上理论。能够进行通用推理而非狭窄训练的LLM开始改变这一状况，大概是从2022年左右开始。

Park等人[⁹]进行了一次早期演示：基于LLM的智能体表现出远超基于规则系统的社交行为。Yao等人[¹⁰]通过ReAct为该类智能体提供了实用模板，并迅速传播到实际系统中。Cognition的Devin[¹¹]向着完全自主软件工程迈进。MetaGPT[¹²]则走向了不同的方向，探讨将专业角色分配给不同智能体是否会在复杂软件任务上击败单个通才。结果确实如此，这影响了我们构建AINTMA的方式。Pasupuleti等人[¹³]将多智能体编排扩展到企业策略合规，引入了约束投影、自适应效用塑造和迭代协商，在企业场景中强制执行严格的SOX/HIPAA/GDPR约束且达到零违规——这一设计关注点通过CSM和零信任网关在AINTMA的安全层中得到了解决。

我们的设计借鉴了所有这些，但有意保持狭窄。缺陷评分和测试优先级排序这类定量任务不适合通用的LLM推理，我们在早期实验中发现LLM在数值工作上不可靠。经典ML处理这些任务。LLM保留用于语言生成，这是它们一贯做得好的事情。

### 用于软件工程的生成式AI

LLM代码生成从研究新奇事物迅速成为标准实践，这是在Codex[¹⁴]之后。测试生成是自然的下一步，并吸引了严肃的实证工作。Schafer等人[⁴]对此进行了仔细研究：LLM能生成语法正确的单元测试且质量可用，不过一旦离开基准条件进入真实世界代码库，幻觉问题和覆盖率缺口仍然存在。

测试运行之后发生的事情研究较少：使用生成模型帮助QA团队以外的人理解测试结果、沟通风险，并根据质量数据而非直觉做出发布决策。这正是GQIA专门做的事情，我们不知道此前有直接针对该问题的研究工作。

### 用于测试优先级排序的强化学习

我们最常参考的工作是Spieker等人[³]，他们证明了基于RL的CI优先级排序在工业数据上可靠地优于基于覆盖率的贪心启发式算法。该结果在我们的数据上得到了复现。Elsner等人[¹⁵]通过LSTM状态编码对其进行了扩展。Chen等人[¹⁶]探索了多目标公式。两者都在基线基础上有所改进。

我们的设置与Spieker的有两点不同，不过其中一个被证明远比另一个重要。我们使用512维状态空间，而他们的是128维。但更大的区别——当我们运行消融实验时真正让我们感到惊讶的区别——是缺陷风险注入步骤。在每个CI周期中，来自单独训练的XGBoost分类器的风险分数在RL智能体做出选择之前被写入MDP状态。这个步骤在我们审查的所有先前系统中都不存在。在消融实验中移除它导致APFD下降了4.3个百分点，超过了仅维度差异的影响。第5.6节有完整分析。

### 云原生测试基础设施中的安全

零信任[¹⁷]意味着对每个请求进行单独认证，无论其来自何处——即使是内部流量。JWT和OAuth2是微服务架构[¹⁸]中实现这一点的实际工具，也是我们所使用的。

测试管理平台有一个特定的安全问题，我们花了一段时间才完全意识到。质量信号具有商业敏感性。安全关键模块中的覆盖率差距揭示了架构弱点所在。在这种情况下，多租户隔离不能是尽力而为。我们最终在智能体通信层强制实施它，而不是仅仅依赖外围防御，因为系统内部智能体之间发生的事情与从外部进入的内容同样重要。

### AI增强的CI/CD流水线与自主DevOps

有几篇论文影响了我们设计评估的方式。Bertolino等人[⁵]在真实工业CI中比较了学习排序与排序学习用于回归测试选择；在他们的数据中，神经网络方法在大规模上胜过了覆盖率启发式算法，我们在自己的数据中也看到了同样的情况。Shi等人[⁶]围绕突变驱动的闭环反馈构建了Miwa，这在结构上与我们的RL智能体类似，尽管反馈机制不同。Tufano等人[⁷]使用Transformer从代码上下文生成测试；GQIA应用了相同的生成式方法，但用于质量叙述而非测试代码。Kim等人[⁸]专门指出了智能体协调中与安全相关的故障模式，这就是为什么CSM是一等架构组件而非可选附件。没有先前的系统将所有这些整合在一起。

## AINTMA多智能体架构

### 智能体设计哲学

花费最长时间解决的设计问题是智能体应共享多少状态。我们早期的设计使用一个公共数据存储，任何智能体都可以读写。这在测试中开始并行模型更新之前似乎没问题。第三次因两个智能体在重训练运行期间读取了不同版本的共享状态而导致的细微不一致性错误被追溯到后，我们施加了一条更严格的规则：每个智能体一种认知能力，背后是版本化接口，除了显式通过事件网格流动的内容外，不共享任何东西。更新一个智能体的模型不再成为其他人的问题，这在18个月的变化中证明非常重要。

所有六个智能体共享相同的内部结构。类型化感知接口精确列出每个智能体读取的信号。推理模块是训练的ML模型或LLM提示流水线，根据实际对该任务可靠工作的内容选择。输出经过模式验证，因此下游智能体不需要防御性解析代码。每个智能体还维护滚动本地内存：RL智能体30天，风险智能体90天，根据CI频率有所调整。

所有消息传递都通过基于Actor模型[¹⁹]的发布-订阅事件网格进行。在18个月内，RL模型经历了三次重大修订，GQIA提示库更改了十几次。没有一次更新需要触及另一个智能体。这就是严格边界规则的回报。

### 六个智能体系统概述

图1显示了架构。**测试发现智能体**处理索引：它每隔五分钟轮询仓库和CI事件流，通过webhook接收合并事件，并维护每个测试用例及其元数据、覆盖率贡献和历史的实时目录。

**风险评估智能体**接收代码变更信号，并使用XGBoost分类器（第3.5节）生成每个模块的缺陷风险分数。这些分数在每个周期直接馈送到RL智能体的状态中。**RL优先级排序智能体**使用马尔可夫决策过程运行调度决策，该过程在每次执行运行后更新（第3.3节）。**执行编排智能体**将排序后的调度转换为实际的CI/CD指令，并在每次运行后向上游报告结果。

**生成式质量智能体**（第3.4节）将分析数据转化为可读的报告。**云安全监控器**持续运行：对每个API网关请求进行令牌验证，监视异常的智能体间流量，并将事件写入SIEM。

编排器智能体：任务协调与调度  
分析器智能体：静态分析，依赖图  
规划器智能体：测试优先级排序，调度  
更新器智能体：测试脚本修改  
验证器智能体：覆盖率，质量保证  
报告器智能体：指标聚合与输出  
被测系统（SUT）：API / 应用程序代码库  
共享上下文内存 ↔ LLM提供者（GPT-4 / Claude）  

图1：AINTMA架构。六个智能体通过加密事件网格连接；外部流量通过零信任网关。

每个CI周期的数据流：
代码变更 → RAA → RPA → EOA → 测试结果 → GQIA → 质量洞察 → 工程/管理/高管。

CSM全程监控。

### RL优先级排序智能体

我们在测试了较小版本后确定了512维状态向量。它有三部分：256维来自提交差异的TF-IDF嵌入，128维来自PCA压缩的覆盖率位图，以及128维的每个测试历史（滚动通过/失败比率，平均执行时间）。