原创 白右 2025-07-09 08:31 浙江
这是2025年的第76篇文章
（ 本文阅读时间：15分钟 ）
01
当下的挑战
在电商行业高速发展的当下，高并发场景的快速交付需求与传统劳动密集型研发模式之间的矛盾日益突出。尤其在大促节点，突发性业务洪峰与资源调度能力不足的结构性矛盾尤为显著——这如同双十一期间传统物流体系因缺乏智能分拣系统导致订单积压，直接暴露出传统架构在系统弹性扩展能力与自动化处理效率方面的显著短板。
研发环节中，测试团队常陷入“打地鼠”式的低效循环：一面需反复手动验证功能上线，一面又需加速构建自动化测试与运维工具，如同杂技演员在多重压力中艰难平衡，随时面临失控风险。
1.1 当测试遇见智能体
一个需求从变更到安全上线的传统测试流程通常遵循以下模式：
业务需求评审
开发编码改动
执行人工用例
缺陷反馈修复
测试回归验证
人工报告评审
上线发布放量
这一流程存在三大显著痛点：
效率低下：单次流程周期常以“天”甚至“周”计，难以匹配高频业务迭代节奏；
人力依赖：测试环节高度依赖人工操作，复杂场景链路变更时易出现覆盖盲区；
风险累积：微小改动可能引发“蝴蝶效应”，导致线上故障频发，甚至需凌晨紧急修复。
尤其在业务高峰期，此类模式的脆弱性被进一步放大——开发与测试的“接力赛”常演变为“救火队”式被动响应，技术债与人力成本持续攀升。而基于Agentic AI的新测试范式可以更好地应对这些挑战，新范式对比传统测试范式有如下特点：
在淘工厂研发实践过程中，在Agentic AI驱动的新测试范式中，多智能体系统实现从需求分析 → 用例编写 → 测试执行 → 结果记录与报告生成的全流程自动化闭环。这一范式的核心突破在于：
协同模式升级：通过智能体间的分布式协同，将传统“人肉串联”的线性流程升级为智能体自动并发协作，测试时效提升82%，并具备7x24小时分钟级响应能力；
质量防御体系重构：构建自主生成-智能执行-闭环优化的智能化质量保障体系，覆盖需求变更全生命周期，显著降低人工干预风险；
生产关系革新：实现1人管理N个智能体（1:N）的弹性配置模式，打破传统“1人1任务”限制，单个测试工程师可同时驱动多个智能体并行执行不同测试场景。
新范式不仅释放了人力资源，更通过AI自适应学习能力持续优化测试策略，使复杂链路变更的缺陷发现率明显提升，真正实现“测试即服务”智能化跃迁。
1.2 我们眼中的智能体
目前，市面上许多大厂、独角兽、高校及研究所，都尝试给Agent下过定义，最经典的之一是OpenAI的研究主管Lilian Weng给出的定义：Agent = 大模型（LLM）+ 规划（Planning）+ 记忆（Memory）+ 工具使用（Tool Use）。另外的一个定义是复旦大学NLP团队给出来的，他们认为Agent的概念框架包括三个组件：大脑、感知、行动。
这些定义，其实都在勾勒一个人在做事时所需要的最基本元素。因此，换个角度思考，相比大模型的纯网聊回复，智能体会记住你的喜好、倾听你的需求、收到要求后拆分去执行且有反馈，更全面、更有血有肉、也更拟人。
我们在设计开发过程中，也拟人化地思考智能体，把智能体当成一个刚入职的应届生 小A君。我们需要让他在这个流程中承担什么任务/解决哪类问题（角色定位），在原有基础上具备哪些专业知识（知识库）、如何解释手头任务并布置给他（提示词）、如何正确的思考并接受反馈改进（提示词）、可以使用的工具及资源（工具调用），随着时间推移，他经历的多了、收录过往的case多（补充沉淀知识库），这位应届生也会变得越来越专业，能力越来越强。
02
基于智能体的自适应测试解决方案
2.1 多智能体测试框架介绍
从“单兵作战”到“智能体工作室”：我们把一个智能体拟人类比为一个应届生，那么一个多智能体在垂类领域的系统，更像多个应届生协作在这个垂类领域的知识共享工作室，且全天开店营业。同样，这个多智能体系统，具备三大基本环节，知识共享&表达，知识生产和知识存储，三者形成循环。新模式测试框架中，对应到三项：
知识共享与表达能力（智能体间实时信息互通，模拟团队协作）
知识生产能力（自主生成测试策略与用例，实现“经验沉淀”）
知识存储能力（动态更新知识库，构建领域专属“记忆库”）
智能体A2A协作全自动完需求研发变更-测试生成执行的全流程：多智能体系统收到用户传入的需求变更文档+代码变更id，通过多智能体协作实现需求分析+测试分析+用例生成+测试执行，最终产出测试报告。
分析执行阶段（知识共享与表达）：
解析需求文档，识别关键测试场景与风险点；
基于代码变更ID定位影响范围，生成初步测试策略。
测试知识生产与沉淀（知识生产）：
自动化生成测试用例，覆盖正向/边界/异常场景；
执行测试并实时记录过程数据（日志、截图、性能指标）。
知识库迭代（知识存储）：
将输入文档、过程日志、测试报告三类数据经标注与评估后，回流至知识库；
通过机器学习持续优化用例生成逻辑与风险识别模型。
从单次任务到持续进化的领域知识循环机制：如下列架构图展示的流程，在分析执行过程中的输入、过程数据日志及结果报告都将重新被分析标注、评定后整理回收到各智能体依赖的知识库中。
数据闭环：每次测试执行后，系统自动将过程数据标注为训练样本（如缺陷类型、修复路径），反哺智能体的知识网络。
弹性扩展：新增智能体可快速调用知识库中的历史案例，实现“经验复用”，避免重复劳动。
领域深化：知识库随业务迭代动态更新，使系统对垂类领域的理解深度呈指数级增长（如电商场景下的促销规则、物流异常处理等）。
2.2 需求分析
首先，我们对需求文档会通过需求分析智能体分析，主要关注以下方面，实现问题早发现：
文档完整性检查：需求描述是否存在遗漏、模糊或矛盾的部分，评估文档结构的完整性。
业务逻辑可行性：需求在业务产品层面的潜在的风险点、冲突点和依赖关系。
此外，还会基于历史项目经验，对类似需求中曾经出现的问题进行预警，并提供相应的规避建议。
2.3 代码及配置分析
需求分析外，在代码仓库分析上，我们通过智能体自动分析代码仓生成高质量的分析文档，作为知识库支持技术方案设计和接口自动化测试等多个应用场景。在diff代码分析方面，我们构建了一个全面的AI代码审查智能体，分析维度涵盖了需求匹配度、架构设计、功能缺陷、安全漏洞和配置集成风险等多个方面。代码分析智能体能够自动提取变更接口的详细信息（包括完整类名、接口名和参数定义），支持接口自动化测试。为确保分析结果的可追踪性，所有分析输出都会记录在钉钉文档中，自动创建TB任务跟踪管理发现的风险。
例：代码分析发现的问题
2.4 配置变更分析
在配置变更分析方面，我们的方案主要通过接入changeFree订阅变更来获取变更前后内容，并结合AI技术分析其对相关代码的影响。
具体实现上，对于switch变更，我们直接通过配置名查询关联代码，再用AI分析变更内容的影响面；而对于diamond变更，由于其通常采用json结构，需要先由AI分析出变更关键词，再据此查询关联代码并分析影响面。AI还会对变更进行数据类型、值域范围、格式规范等基础合规性检查，以防止因配置格式错误导致整个配置失效。
2.5 测试用例生成
各类分析后，来到了生成测试用例环节。在智能体生成测试用例上，单智能体在挂载对应域的知识库后，可以很轻松地分析需求、生成用例。可是，往往产出结果不如预期、过于宽泛、步骤或预期不清，和严格执行所需的质量仍有距离。针对这点，如下图结构关系中，我们在这个环节使用三个Agent，用例生成Agent、对抗助手Agent和对抗结果融合Agent协作解决。
步骤如下：
用例生成Agent优先生成初版用例
对抗助手Agent检查初版用例、所用知识库及提示词是否存在问题。
对抗结果融合Agent综合初版用例和优化建议产出终版用例。
这三个Agent详细介绍如下：
2.6 AI测试数据构造&AI脚本生成&用例执行
在整个多智能体并行执行环节，我们根据日常手工测试会涉及的不同场景划分为：功能UI测试、接口测试、数据测试、消息测试、监控创建、核对生成等，拆分后便于AI进行更详细的分析执行，也避免了输出内容太多会受到模型的输出token的限制。针对上述指定的场景，分别并行地进行差异化分析，结合历史经验知识库经过初步分析->对抗分析->分析融合，最终得到每个指定测试场景下的详细用例，每种场景的用例均通过表格形式规范输出，表格内容包括用例编号、前置准备、操作步骤、测试预期等，便于后续人工进行标注。
测试数据方面，我们的方案是提前离线准备测试数据。为了提高整个执行效率，我们收集了大家日常测试过程中会频繁使用的测试数据的类型，通过一个离线数据构造的编排，结合知识库整合目前已有的大波浪数据构造工具，准备常用的测试数据品池。在实际AI测试过程的使用中，首先通过需求分析得到本次需求可能需要用到哪些条件的数据，然后去我们维护的测试数据品池中去找到满足条件的测试数据，用于后续的测试用例执行。
此外，执行方面，离线数据测试可通过直接读取线上数据并执行开发环境表的SQL用例完成验证，需结合数据一致性检查等核心测试点保障质量。功能UI测试依赖存量页面操作知识库与前端分析，通过浏览器插件录制操作步骤生成测试脚本，最终以YAML格式实现自动化执行；核对生成与监控创建需基于需求分析制定规则并调用工具实现自动化，其中核对SQL生成需对接数据质量平台，而监控创建需规范参数并避免重复配置。
2.7 测试知识生产&沉淀
为了实现多智能体在整个执行过程中越来越好用，我们搭建了反思回流闭环。从执行结果、过程日志分析提炼，结合部分人工标注结果，评估分析、并实现经验回流和用例沉淀，回补到各域以及对抗助手的正负向向知识库，同时，不断沉淀该域的用例，自我完善。
整个回流的工作流程可以分为几个主要阶段：
过程日志及结果报告通过三类AI Expert Agent，“常识性误解审核”、“经验陷阱审核”和“系统性偏差审核”作为AI Agent专家评定输入，这些Agent负责从不同角度对内容进行初步评估。这些评估结果会汇总到"多专家评估决策融合"环节，同时可以选择性地结合人工标注(Optional)来增强决策的准确性。
2.8 知识库
作为专业知识存储的角色，当前链路方案中，各智能体所用知识库主要分为域知识库、域对抗助手知识库、对应的应用代码知识库和历史经验知识库，并引入正负向知识库机制辅助。
正负向知识库模式
核心机制：通过构建双轨制知识库体系，分别沉淀有效经验与缺陷案例，形成正向引导与反向约束的双向反馈机制。
通俗说法：正向需应用、负向需剔除。
各域核心知识库
2.9 智能体增强模式
在整个多智能体测试系统中，我们也应用了多种智能体增强模式。在原有提示词中给定角色、任务、场景描述、工具、资源、能力、限制之外，通过应用各种增强模式让智能体有更强的表现。
03
具体场景使用
3.1 需求交付场景
具体场景方案
当前方案已经在淘工厂商品运营各域开展使用，并将在全域扩量推广。每个域有对应的需求测试分析多智能体，使用中根据不同测试分析执行的场景划分为：功能UI测试、接口测试、数据测试、消息测试、监控创建、核对生成等。并行分析执行以提高效率。以各域来说，输入、中间处理、输出如下表：
下图为我们在“竞价域”的编排流程示例：
整体编排流程
输入文档等内容处理
知识库获取&并行分析+执行
实际执行效果
以本周为例（截止20250623），需求变更触发测试覆盖商品运营的4个域和商家、价格、营销等3个域，智能测试三天内处理8个需求测试，用例生成平均准确率约71%，平均漏测率约14%， 平均执行成功率81%，并发现了4个缺陷/改进建议。
基于代码变更问题识别上，针对各域跑测的9个变更，共发现了21个风险/可优化点。
例：智能体代码分析Bug举例
例：智能体生成的测试报告（部分）
例：智能体测试结论
新的衡量体系
为了避免单一指标带来的偏执，在需求交付场景下的多智能体应用表现衡量体系，综合借鉴了效能评估的周期内三个核心维度——需求交付吞吐、研发成本效率和研发质量安全等维度，全面反映多智能体范式带来的效率提升。换句话说，我们希望“应届生”们可以更快更好更全面地处理更多的任务量。具体而言：
需求交付吞吐维度：单位时间内完成的需求数量，如每周及月度需求吞吐量，来量化多智能体新范式的生产产能。高需求吞吐量意味着多智能体具备高效处理需求，快速实现迭代验证的能力。
研发成本效率维度：除监控需求测试与开发人日比例（测开比）的逐步提升外，重点全自动化任务的比例量化系统中无人介入执行的占比，以评估资源节约程度。随着对领域知识不断沉淀和多智能体系统优化，逐步提升系统的自适应效果，指标不断优化，实现研发效率的持续精进。
研发质量安全维度：统计各阶段发现的问题总数、任务准确率及召回率（漏测）发生率。这些指标能帮助我们更好地在过程中跟踪当前多智能体系统自身的“完善度”和使用者的“置信度”。我们通过跟踪这些指标精细化分析多智能体在不同体量、复杂度分类场景中的表现，不断定位具体问题及优化方向。
最终，该体系实现从需求响应交付、质量保障到研发效率的全链路效能可视化，形成一个全面客观的评估框架，指引优化方向、突破在原有传统经典范式下的人工瓶颈。
04
未来展望
4.1 更完善的知识库智能运维体系
作为测试领域的多智能体应用，我们从原传统人工测试的范式转向了基于多智能体的“知识能力同享”体系，而测试同学的主要工作，也将从人工测试转向了“测试专业知识”运维。
接下来，我们会着重思考围绕测试专业的知识库智能运维，如何构建关系层次结构更清晰、信息密度更高的结构化数据、可进化且受控的知识管理体系。
比如：
知识结构化处理：通过模型将测试用例、缺陷报告等非结构化数据分层，并生成知识图谱，实现语义化检索与精准关联，形成层级清晰的关系结构。
变更闭环管理：建立知识版本控制与审核流程，结合工单系统追踪知识修改记录，确保变更可追溯且符合合规要求。
动态知识进化：通过对需求文档、执行记录等自动提取测试过程中产生的新数据（如性能优化策略、复现步骤），生成结构化知识条目并实时更新原知识库，保障时效性。
智能驱动迭代：通过Query增强技术分析用户检索行为与反馈，识别知识盲区或高频问题，驱动针对性智能搜索可信任来源知识补充；同时利用聚类分析挖掘知识关联性，优化分类体系与推荐逻辑。
最终，以结构化存储为基础，通过自动化采集与闭环变更管理实现知识持续进化，最终提升测试运维的准确性与响应效率。
4.2 从生产力跃迁到生产关系重构
多智能体范式必将带来生产力跃迁爆发：
以数据知识库、大模型算法与算力，实现测试任务并行化与流程智能化。快速迭代与工具链标准化，进一步降低了技术应用门槛。也将推动测试智能体不断在更复杂的任务上体现更高的自主决策能力和执行精度。
未来，我们在测试多智能体能力升级上，仍需在以下两点不断深挖：
不断强化其在复杂长链路测试任务容错性与稳定性，同时兼顾新扩量的领域、链路的快速适配性。例如，快速覆盖到新项目，新业务链路，如何使多智能体系统快速发现自身异常后，自动多来源收集所需数据。
结果归因层面需建立透明化因果分析框架。随着测试多智能体协同多源数据搜集共享、智能知识库运维和分析自愈能力的提升，测试多智能体将不断重塑在复杂任务上的边界。
多智能体范式正在重塑组织形态与协作逻辑：
一方面，测试工程师从“执行者”转型为“策略制定者”，通过智能体调度中心统一管理任务队列；新人或跨域人员可通过预设模板快速上手，降低协作摩擦成本；智能体间实时共享测试策略与缺陷模式，形成“群体智慧”驱动的协作去中心化协作网络。
另一方面，人机生产关系从工具使用转向共生共创模式——人类聚焦策略制定，多智能体承担能力更强大的执行优化，推动生产关系向开放协作演进。这也催生新型任务价值分配，每个测试同学都拥有一堆专业的"虚拟应届生"时，应该更高维度、全面思考质量保障策略和风险防范的课题。With great power comes great responsibility.
05
FQA
1. 多智能体的测试到底是代替，还是加重了人工测试及维护的负担？
答：当前，无论是基于领域知识微调大模型，还是现在叠加上RAG/KAG等buff的方案，均没法做到在复杂任务上的结果完全脱离人工的绝对置信。如AI业界现在吸引众多目光的RL思想，我们相信随着不断地使用，更多使用过程中的知识总结沉淀，更精细的知识运维手段加入。多智能体测试将在更多复杂场景下，取得精度和置信度，让测试同学放开双手。
2. 到底该如何判断某个测试场景是否适合多智能体？
答：根据实验经验，场景领域知识要求越多、流程SOP越模糊、结果要求越精确或责任越大，一般不是直接应用多智能体测试的理想场景，调优及数据工作量普遍不小，且需要配合人工或规则兜底策略进行。
反之人工高频重复但操作范围、所需领域知识相对固定的场景会是多智能体测试快速应用的沃土，比如，测试同学日常面对的各种数据查询答疑、日志排查问题定位等。
3. 底层大模型能力不断攀升，如OpenAI、谷歌亚马逊等也陆续推出能力强大的Agent，自己开发 or 等待行业发展？
答：模型能力和通用智能体能力在不断迭代与提升，但垂类行业与细分领域中的独特的场景SOP和私有化数据也会逐步成为应用智能体的壁垒。因此，除了集成和应用与日俱增的通用模型能力外，未来智能体在企业内侧重点会围绕在“私有化数据清洗与处理”，“可信数据源接入”与“细分场景知识增强能力”上。
4. 在推广覆盖到更多域的过程中遇到了哪些问题？
答：在推广到各域过程中，可以发现还是存在对多智能体的新范式有“内心抗拒”的情况存在。这更多源自对于“被代替”的焦虑。其实，我们一直有个思想，也是上文所提到的，“当每个测试同学都拥有一堆专业的"虚拟应届生"时，应该更高维度、全面思考质量保障策略和风险防范的课题。With great power comes great responsibility.”有时候，正在代替我们的，会推动我们不断进化，可以站在更高的维度，解决更大更复杂的问题，创造价值更高的事。我们大家一样，都在进化中。
另外，智能体的效果也在不断迭代优化中，在推广的过程中需要测试同学一起反馈“badcase”，我们对智能体进行持续调优，提升准确率。
欢迎留言一起参与讨论~
