AI Agents + 微调 LLM + RAG + YOLO：端到端测试的实际架构详解

真正可落地的 AI 测试，不是让模型“写一段脚本”，而是让它在受控流程中读取真实知识、感知真实界面、执行真实验证，并把每一次失败沉淀为下一次决策的依据。

写在前面：这不是“一键生成测试”的故事

最近看到一套颇有代表性的 AI 驱动 E2E（端到端）测试思路：它把 AI Agents、微调 LLM、RAG、YOLO/OpenCV/OCR 和浏览器自动化放进同一条流水线。

它解决的并不是“如何让大模型写出 Playwright 脚本”这么小的问题，而是四个更难的问题：

• 模型怎样理解本产品的业务规则，而不是复述通用测试模板？
• UI 改动、动态渲染或无障碍信息不完整时，元素如何被可靠定位？
• 测试生成、页面探索、执行、失败分析如何形成可追踪的闭环？
• 哪些判断可以自动化，哪些必须留给测试人员审核？

先给结论：这是一套“传统自动化为主、AI 能力按需叠加”的架构。 高频、稳定的回归测试仍应优先使用确定性的 Playwright 脚本；Agent 和视觉识别更适合新功能探索、复杂 UI、定位器失效后的辅助恢复，以及扩大测试设计覆盖面。

一、从需求到报告：全链路架构

整套系统可分为五层。数据和控制流不是直线，而是带有验证门的闭环。

这里最容易被忽略的是两点：

• LLM 不直接拥有最终执行权。 它产出计划、候选用例和建议，真正执行前要通过结构校验、策略校验和风险门。
• 视觉模型不应取代 DOM。 DOM、可访问性树（Accessibility Tree）通常更快、更便宜、更稳定；视觉感知是它们缺失、失效或需要交叉验证时的补强。

二、知识准备层：先让系统拥有“可用的上下文”

RAG 的价值不是“把所有文档塞进 Prompt”，而是让每一个生成和判断都有可追溯的证据来源。它是减少幻觉的基础，但前提是知识本身干净、可定位、持续更新。

1. 应进入知识库的四类资产

不要把过期用例、重复文档和未经脱敏的生产数据原样灌入向量库。RAG 会放大知识质量：错误、冲突或过期的信息被检索到后，模型只会更有信心地给出错误答案。

2. 文档入库的关键不是“切块”，而是元数据

每个 chunk 除正文外，应至少带有：产品模块、版本、来源类型、更新时间、适用环境、风险等级、权限级别 和 原文链接。这样检索时才能限定“当前版本的支付模块”“仅已审核用例”“测试环境可用的数据规则”。

一个适合测试场景的检索策略通常是混合检索：

• 向量检索召回语义相近的需求、缺陷和历史用例；
• 关键词/字段过滤锁定模块、版本、环境；
• 重排序模型优先提升验收标准、已审核用例和高严重度缺陷；
• 将最终片段连同出处、版本和时间一起交给模型。

3. RAG 只提供依据，不替代验证

即便检索到了“登录失败三次会锁定账户”的历史规则，也要标明该规则来自哪个版本，并在执行时通过 API、页面状态或测试环境数据验证。RAG 输出的角色是 evidence（证据），不是 truth（最终事实）。

三、微调 LLM：把通用表达能力变成团队的测试表达

通用模型已经会列正常、异常、边界场景，但常见问题是：测试点正确却过于泛化，忽略产品特有流程，也不符合团队的用例字段、优先级和风险语言。

微调的目标不应该是让模型“记住所有业务知识”——动态业务知识更适合 RAG；它更适合学习稳定的输出规范和推理习惯，例如：

• 用例必须包含前置条件、数据、步骤、预期结果、优先级和标签；
• 对金额、权限、库存等高风险域自动追问边界与一致性；
• 输出可被程序解析的 JSON，而不是散文式建议；
• 在证据不足时明确标记 needs_human_review，而不是补全猜测。

1. 数据如何准备

可从 TestRail、Zephyr、Excel/CSV、缺陷系统、需求系统和稳定的自动化脚本中整理样本。每条训练记录最好是“输入上下文 → 已审核输出”的配对，而不是仅堆积原始文档。

{
  "input": {
    "requirement": "会员可使用优惠券抵扣订单金额，订单取消后优惠券应返还。",
    "constraints": ["仅测试环境", "金额以分为最小单位"],
    "retrieved_evidence": ["AC-12：取消成功后 5 分钟内返还", "BUG-481：重复取消导致重复返券"]
  },
  "output": {
    "cases": [
      {
        "title": "已使用优惠券的订单取消后返券",
        "priority": "P0",
        "steps": ["创建并支付使用优惠券的订单", "取消订单", "查询优惠券状态"],
        "expected": "订单取消成功；5 分钟内优惠券恢复可用；余额仅返还一次",
        "evidence_ids": ["AC-12", "BUG-481"],
        "needs_human_review": false
      }
    ]
  }
}

训练前应做脱敏、去重和人工抽检。特别是缺陷单里可能包含用户信息、内部地址或 Token，不能因为“数据在内部系统”就直接进入训练集。

2. 采用什么微调方式

对大多数团队，LoRA 或 QLoRA 指令微调就足够：成本低、迭代快，也便于针对不同产品保留独立适配器。可以从 Qwen、Llama、Mistral、Phi 等可用基础模型开始；真正决定效果的往往不是模型名字，而是样本质量、输出约束和离线评估集。

SFT（监督微调）适合先把格式与基本策略校正。若团队已经积累了“候选用例 A 与 B，哪个更有价值”的偏好数据，再考虑 DPO 等偏好优化。不要一开始就上复杂的强化学习：没有明确的质量标尺，优化只会把噪声放大。

3. 让输出可执行、可拒绝

Generator Agent 需要强制使用 JSON Schema 或 Pydantic 等结构校验。至少校验以下内容：

• 步骤、预期结果、优先级、风险标签是否齐全；
• 每个关键断言是否关联检索证据；
• 是否出现不在白名单内的环境、账号、工具或操作；
• 是否存在“删除数据”“修改生产环境”等越权指令；
• 置信度不足时是否正确转入人工审核。

模型的自然语言能力用于“提出假设”，程序化规则用于“决定能否执行”。这是整套系统可靠性的分界线。

四、UI 感知层：YOLO、OpenCV、OCR 与 DOM 如何协作

浏览器测试的首选定位方式仍然是语义稳定的 locator，例如 Playwright 的 getByRole、getByLabel、getByTestId。但真实产品常遇到 Canvas、第三方组件、无障碍属性缺失、动态布局、DOM 频繁变化等问题。此时，视觉层可以提供第二条观察通道。

1. 一条可靠的混合识别流水线

以“点击提交按钮”为例：

• 先从可访问性树寻找 button 且名称为“提交”的节点；
• 若找不到或有多个候选，YOLO 在截图中检测按钮区域；
• OCR 读取按钮框内文字，确认它确实写着“提交”；
• OpenCV 判断该按钮是否处于表单底部、是否被遮挡、是否与目标区域相邻；
• 用 DOM 命中、YOLO 类别、OCR 文本、可点击状态形成综合置信度；
• 达标时优先回写为语义定位器；仅当页面确实没有稳定语义信息时，才把坐标作为短期兜底。

2. YOLO 模型要训练什么

通用 UI 检测模型可以帮助起步，但若产品有强烈的设计系统、复杂业务控件或大量图标，最好使用自家截图标注的小数据集微调。类别不必贪多，先覆盖价值最高、最容易失效的组件：

• button、input、select、checkbox、tab；
• modal、toast、table_row、pagination；
• 业务关键控件，例如“下单按钮”“验证码区域”“支付确认框”。

标注规范比模型版本更重要。要统一边框是否包含阴影、禁用态是否单列、图标按钮如何标注，以及截图的分辨率、主题、语言和缩放比例。训练集还应覆盖深色模式、移动端断点、加载态、错误态与遮挡态。

3. 视觉识别的正确定位

视觉识别通常速度更慢、成本更高，也可能被文案、主题、缩放、广告遮挡影响。因此它应当承担这三类工作：

• 补位：DOM/A11y 信息缺失时提供候选元素；
• 交叉验证：确认页面实际呈现了预期状态，而不是只确认 DOM 存在；
• 诊断：测试失败时把“元素不存在”“元素被遮挡”“元素文字变化”变成可解释证据。

它不应成为每一步点击的默认实现，更不能把“检测到了一个看起来像按钮的框”直接等同于业务断言通过。

五、Agent 编排层：把一次模型调用变成可控工作流

Agent 的核心价值不是“自主感”，而是把职责拆开，让每一步都有输入、输出、工具权限和失败边界。

LangGraph、AutoGen、CrewAI、LlamaIndex 都可以承载这一层；对需要严格状态转换和审批的企业场景，自建状态机或 LangGraph 一类的图式工作流通常更容易审计。框架不是关键，关键是每个节点都要有可序列化状态、可回放证据与可拒绝的工具调用。

一个最小状态机

RECEIVED
  -> RETRIEVED
  -> PLANNED
  -> GENERATED
  -> VALIDATED
  -> EXECUTING
  -> ANALYZED
  -> PASSED | HUMAN_REVIEW | FAILED

例如：模型想“重试一次”时，Orchestrator 必须检查预算、最大重试数、测试环境是否干净；模型想“修复 locator”时，必须把原 locator、候选 locator、证据和影响范围提交给人工或策略引擎，而不是直接覆盖稳定测试。

六、端到端执行流程：以一个新需求为例

假设需求是“订单取消后，已使用的优惠券在 5 分钟内返还，且不可重复返还”。一条完整工作流可以这样运行：

• 接收变更。 Planner 读取 Jira 票、PR 描述、受影响服务和风险标签。
• 检索证据。 RAG 召回验收标准、优惠券规则、历史重复返券缺陷和现有订单测试资产。
• 生成候选用例。 微调 LLM 输出正常取消、超时返还、重复取消、并发取消、异常补偿等 JSON 用例，并给出证据引用。
• 策略筛选。 系统将“重复返券”和“金额一致性”标为 P0；缺乏测试数据的场景转人工或数据准备任务。
• 探索页面。 UI Perception Agent 打开订单页，优先用 A11y/DOM 寻找取消按钮；若语义缺失，再用 YOLO + OCR 识别“取消订单”。
• 执行断言。 Executor 用 Playwright 执行已审核步骤，保留 trace、网络请求、截图、视频与关键 DOM 快照。
• 分析失败。 如果取消按钮未找到，Analyzer 区分三种情况：页面功能缺失、locator 因 UI 改版失效、按钮被浮层遮挡；如果是候选 locator 变化，提出补丁但不自动合并。
• 回写学习。 人工确认后的新用例、有效 locator、真实根因和过期资料进入版本化知识库，供后续检索与评估使用。

注意这里的“自愈”应被理解为：提出可审查的修复候选。若 Agent 为了让测试通过而跳过关键断言、改了业务预期或换到了语义不同的按钮，它修复的不是测试，而是掩盖了风险。

七、质量护栏：让 AI 流水线可复现、可解释、可治理

AI 参与后，测试系统需要同时评估“产品是否正确”和“AI 的判断是否可信”。以下护栏建议从第一天就建立。

1. 结构与确定性

• 固定模型版本、Prompt 版本、RAG 索引版本和测试数据版本；
• 将生成温度调低，对关键决策使用结构化输出；
• 对相同输入建立回放机制：能重新拿到当时的证据、计划和执行 trace；
• 把“无证据的断言”“未知字段”“越权工具调用”视为失败，而非自动补全。

2. 置信度不是一个数字

元素定位的置信度可以由多个信号组合，例如：

locator_score =
  0.45 * DOM/A11y 语义命中
  + 0.25 * YOLO 组件类别置信度
  + 0.20 * OCR 文本一致度
  + 0.10 * 布局与可点击状态

这不是通用公式，而是提醒我们：置信度必须能拆解。报告应说明“为什么认为这就是提交按钮”，而不是只给出 0.91。对于支付、删除、权限变更等高风险动作，即使置信度很高，也应要求额外确认或使用专门的测试账号。

3. 把审核门放在高风险处

建议至少在以下场景强制人工审核：

• 新增 P0/P1 用例、修改业务预期或删除既有断言；
• 需要变更稳定 locator、访问敏感环境或写入测试数据；
• 视觉定位与 DOM 语义发生冲突；
• Analyzer 无法区分产品缺陷、环境故障和测试脚本问题；
• 模型引用的资料过期、冲突或证据不足。

八、成本、速度与适用范围：不要让 AI 回归膨胀

这类架构最常见的误区，是把每一条回归都交给多 Agent + 视觉循环。结果往往是执行更慢、成本更高、结果反而更不稳定。

衡量价值时，不只看“AI 生成了多少条 case”，而应跟踪：人工审核通过率、有效缺陷发现率、误报率、定位器维护时间、平均反馈时长、单次运行成本，以及被人工否决的自愈建议比例。

九、一个务实的落地顺序

不要一次性训练模型、搭向量库、接视觉识别、再上多 Agent。更稳妥的路线是逐层建立可测量的能力：

第 1 阶段：先把基础自动化做稳

• 用 Playwright 建立关键业务链路；
• 补全 role、label、data-testid 等可测试语义；
• 统一 trace、截图、视频、日志和测试数据隔离；
• 建立可被 CI 调用的确定性基线。

第 2 阶段：接入 RAG + 用例生成

• 选择一个业务模块整理小而高质量的资料集；
• 让 LLM 只生成候选用例，不直接执行；
• 建立人工审核结果集，测量通过率与遗漏类型；
• 先优化检索质量和输出 Schema，再考虑微调。

第 3 阶段：引入 Agent 编排与失败分析

• 将“检索—规划—生成—执行—报告”做成可回放状态机；
• 让 Analyzer 先做归因摘要和证据聚合；
• 明确重试、预算、权限与人工审批规则。

第 4 阶段：仅在确有痛点时加入视觉层

• 统计 locator 失败发生在哪类页面；
• 针对这些页面采集、脱敏并标注截图；
• 以 DOM/A11y 为基线评估 YOLO + OCR 的增益与误判；
• 将视觉定位限制为候选生成或二次验证，而不是全量替换。

第 5 阶段：用评估驱动迭代

准备一组永不参与训练的“黄金需求—已审核用例—已知缺陷”评估集。每次更新模型、Prompt、索引或工作流都回归这组数据，观察覆盖、幻觉、格式错误、误报和成本变化。没有评估集的持续优化，本质上只是凭感觉调 Prompt。

十、技术栈参考

写在最后：把“聪明”放进边界里

AI Agents、微调 LLM、RAG 和视觉识别组合后，能让测试系统多出三种传统脚本不擅长的能力：从历史中提取风险、从界面中获得冗余证据、把失败组织成可行动的解释。

但它们不会自动带来可信度。可信度来自清晰的数据边界、结构化输出、确定性执行、证据留存、评估集和人工审核门。

所以这套架构真正的价值，不是“让 AI 代替测试人员”，而是把测试人员从重复生成、机械定位和碎片化排查中解放出来，把时间留给测试策略、业务风险与质量判断。AI 负责扩大第一稿与覆盖面；人负责定义什么值得相信、什么必须拦下。

本文基于一套 AI 驱动 E2E 测试架构的讨论整理，侧重工程化拆解与落地边界；其中的模型、框架和工具应结合团队的数据安全、现有自动化基线与实际验证结果选择。