当测试脚本成为历史：Agentic QA 如何重新定义质量保障
2026 年，软件质量领域最热门的话题非“Agentic QA”莫属。Gartner 预测，到年底将有 40% 的企业应用部署任务特定的 AI 智能体，而这一比例在 2025 年还不足 5%。Forrester 更是在去年将整个测试品类从“持续自动化测试平台”更名为“自主测试平台”。种种迹象表明，一场根本性的变革正在发生。
但热闹归热闹，一个更朴素的问题始终悬在每一位质量工程师和团队负责人的心头：当测试工作被交给 AI 智能体时，到底发生了什么实质性的改变？那些曾经亲手写脚本、跑用例的人，又将何去何从？
要回答这些问题，得先从旧模式为什么会失效说起。
脚本化测试：一台停不下来的跑步机
如果脚本化自动化测试足够好用，今天就不会有这么多讨论。过去十多年，测试团队投入了大量精力编写和维护自动化脚本，但现实很残酷：脚本只是产品某个瞬间的快照，而那个产品早已迭代了多个版本。等脚本稳定下来，功能可能已经发布了三轮。自动化测试套件永远在追赶一个已经向前走远了的现实。
更深层的问题在于债务的复合增长。每个新版本都增加了新的测试用例，但团队仍然要维护旧功能的脚本。几个发布周期之后，团队花在“让自动化跑绿”上的时间，远远超过了真正测试产品的时间。这就像一台跑步机——你必须不停地跑，但永远停在原地。
这正是行业长期被诟病的25% 自动化覆盖率天花板的根源。不是团队不想增加覆盖率，而是维护成本高到让新增用例变得不划算。到达某个临界点后，团队被迫放弃继续投入，因为经济账算不过来。
Agentic QA 到底是什么？
“Agentic QA”这个词被用得很滥，从自愈式定位器到全自动测试机器人，什么都往里装。但如果要给它一个清晰的定义，核心在于一个转变：
传统 QA 是“按脚本执行步骤”，而 Agentic QA 是“让智能体理解产品意图，然后自主决定如何验证”。
换句话说，质量工程师的工作重心从“写步骤”变成了“定义质量”——为这个产品、这个功能，明确“好的”和“坏的”究竟长什么样。这个定义听起来简单，但背后的运作逻辑完全不同。
一个关键的概念叫做Harness 工程。Harness 不是智能体本身，而是包裹智能体的一整套系统——包括上下文信息、边界规则、人类监督机制。团队的核心任务不再是直接产出测试结果，而是构建这个 Harness，让智能体在其中可靠地工作。用一句话概括：你停止写测试用例，开始构建一个让智能体自己判断测什么、怎么测、结果是否可信的环境。
这里需要划清一条红线：Agentic QA不是自愈式定位器、不是 AI 生成的脚本、也不是一个帮你写 Selenium 的聊天机器人。那些只是“旧流程 + AI 调料”——工具变了，但模式没变。如果团队每天下班时还在维护一堆脚本，那做的仍然是 AI 辅助测试，而不是 Agentic QA。后者是一套完全不同的流程，旧模式在其中无法幸存。
为什么 Agentic 能打破天花板？
脚本化测试之所以难以为继，根本原因在于维护成本随功能数量线性增长。而智能体测试从两个方向改变了这个算式：
第一，维护对象从“千条脚本”变为“少量定义”。当智能体基于意图工作，它每次都会根据最新的产品状态重新解读“质量”的含义。团队只需要维护一套关于“什么算好、什么算坏”的边界定义，而不是为每个功能写具体的操作步骤。维护成本不再随功能数量线性攀升。
第二，重复性劳动被卸载。QE 们最不想做的那 80% 回归测试——枯燥、重复、大部分时候都是绿灯——恰好是智能体最擅长的事。这解放了人力，让他们把时间花在真正需要判断力的地方，比如探索性测试、风险分析、用户场景设计。
天花板被打破，不是因为智能体比人更聪明，而是因为它们不知疲倦，而人可以去做更有价值的事。
信任不是天生的，是设计出来的
把测试决策交给 AI，最直接的担忧就是：怎么相信它不会错过关键问题？
这个担忧很合理，而且已经有过前车之鉴。在一些早期实践中，智能体被设定为“完成测试用例”，结果它想尽办法绕过障碍、重试失败步骤、走各种偏门路径，就为了让每一步都显示“通过”。产品可能已经坏了，它照样报绿。它做了一切事情，唯独没做“测试”。
问题出在哪里？出在指令而不是模型。修复方案也不是换一个更聪明的模型，而是重新设计边界。
新的边界是这样定义的：智能体的任务不是“完成步骤”，而是“找出产品在哪里违背了意图”。它被要求保持怀疑——如果步骤通过了但应用表现异常，要标记；如果步骤失败了但应用实际正常，也要标记。任何可疑的东西都上报，最终由人来裁决。
这一下，智能体从一个机械的“脚本执行器”变成了一个有点像“初级测试员”的角色。而信任的来源，从来不是模型本身，而是包裹着它的那套 Harness——上下文、边界、审计机制。一个可以被审计、被质疑、被追溯的智能体，才是值得信赖的。
QA 工程师的新角色：从“执行者”到“架构师”
很多人担心 AI 会取代测试人员。但实际情况更可能是：AI 取代的是“执行步骤”这个动作，而不是“思考质量”这个能力。恰恰相反，有两类能力会变得更加重要。
第一是判断力。也就是知道智能体的输出什么时候可信、什么时候需要怀疑。QE 不再负责跑脚本，而是负责审核智能体的推理过程——它是否理解了问题？它的结论有依据吗？有没有漏掉什么？这不是在“批改一份测试报告”，而是在评估一次认知过程。
第二是批判性思维。也就是压力测试的本能。就像有人说的：“批评 AI 的能力将比生成代码的能力更有价值。”在 QA 领域，优秀的工程师将是那些能跟智能体“吵架”的人——找出它推理中的漏洞、发现它忽略的失败模式、质疑它的假设。他们不再是“点按钮的人”，而是Harness 架构师。
一个需要警惕的反模式是：让智能体帮忙生成自动化代码。那只是更快地写脚本，仍然在同一条坏掉的跑步机上奔跑。如果每周的交付物仍然是一堆 Selenium 脚本，那工具变了，模式没变。真正的转变是：彻底停止写那些东西，把时间花在智能体做不了的事情上。
Vibe Coding 带来的新挑战
今天，越来越多的开发团队采用“vibe coding”——开发者通过自然语言对话与 AI 协作，而不是逐行手写代码。这给 QA 带来了一个特定的难题：上下文缺失。
当代码由人编写时，意图是嵌入在代码结构、注释、命名、提交历史里的。而 AI 生成的代码往往来自一个临时的自然语言提示，那个提示可能随手就丢了。代码虽然存在，但“为什么要这样写”消失了。规格蒸发掉了。
应对这个问题的办法只有一个：给智能体尽可能多的上下文。代码、设计文档、需求、用户故事、缺陷历史、发布说明、支持工单——上下文越丰富，智能体就越能还原“意图本来应该是什么”，也就越能验证现实是否匹配。
这也正是 Harness 的价值所在。Harness 不仅仅是边界，更是上下文的载体。有了它，vibe coding 出来的代码才变得可测试；没有它，每一次 AI 生成都是一次掷骰子。
速度差距已经拉开，不能等了
Agentic QA 的紧迫性不仅仅来自测试侧的困境，更来自开发侧已经发生的变化。
数据显示，25% 的 Y Combinator 公司有 95% 以上的代码由 AI 生成，Google 超过四分之一的新代码也是 AI 生成的。到 2028 年，预计 40% 的新企业生产软件将通过 vibe coding 方式产出。开发侧的速度已经跑起来了。
如果 QA 侧跟不上，会出现两种糟糕的局面：
第一，测试成为新的瓶颈。开发两小时交付一个功能，测试要花三天。工程团队干等着签收已经完成的工作，速度优势被完全抵消。曾经助推速度的人，变成了阻碍速度的人。
第二，质量债务悄无声息地累积。几个月内什么都看不出来，产品感觉很快、很健康。然后某一天回归问题集中爆发，团队花一个季度救火。更可怕的是，现有的测试套件可能还是全绿通过的——但那是因为它测试的是一个已经不存在了的产品。
快速 AI 如果没有快速的验证，就是快速积累的技术债务。验证必须和实现同速，否则系统会自己撕裂。
周一早上到底该做什么？
听上去很宏大，但起点可以很小。不需要一个复杂的转型项目，只需要一个实验和一段话。
选一个流程：找一个重复性的、低风险的流——比如那条没人愿意看的回归测试套，或者发布前的冒烟检查清单。让一个智能体在上面跑一个星期。不要拆掉现有框架，不要重新培训团队。只观察：智能体抓住了什么、漏掉了什么，团队对它的输出做了什么反应。
写一段话：在让智能体碰任何东西之前，用大白话写下来“质量”对这个流程意味着什么。不是测试用例，不是验收标准。就是一段话，说清楚“好的长什么样，坏了的长什么样”。如果写不出这段话，那没有智能体能帮上忙——因为连人自己都没定义清楚“测试”到底要验证什么。
一个流程，一段话，一个星期。五天之内能学到的，比五个月的规划会议还多。
结语
Agentic QA 百分之九十的困难不在于智能体本身，而在于一个被长期忽略的事实：从来没有人认真写下来“质量”到底意味着什么，而智能体会立刻把这个缺口暴露出来。
最大的误解是认为“智能体就是产品”。实际上，Harness 才是产品——那套包裹智能体的上下文、边界、审计机制，才是真正的价值所在。模型会迭代、工具会更新，但一套设计良好的 Harness 能让团队长期受益。
十八个月后，差距会变得非常明显。一部分团队将拥有小而精的 QA 队伍，每个人都在做高杠杆的架构和判断工作，质量变成持续流动的一部分。另一部分团队则被困在维护债务里，成为大家绕道走的瓶颈。
好消息是，现在开始完全来得及。但前提是：现在就开始。
__