上个月团队在推测试智能体的落地，遇到一个很典型的问题：同一个页面元素定位任务，Agent第一天跑了12次才找对，第二天跑了8次，第三天只跑了3次。

我没改任何提示词，也没重新训练模型。

它自己学会的。

这件事让我认真研究了一下AgentLoop的经验自进化机制，以及它跟测试场景结合后的实际效果。今天把完整的链路和实操过程写出来。

先搞清楚一个事实：Agent的不确定性不是靠调参解决的

传统软件追求确定性——相同输入、相同环境下，系统给出稳定可预测的结果。AI Agent不是这样。

模型采样有随机性，上下文每次都不一样，任务规划路径可能完全不同。同一个问题连续跑五次，Agent可能选不同的工具、走不同的路径、给出不同的答案。一次评测通过，不代表下一次还能过。

这就是测试同学最头疼的地方。你不可能拿一个“今天能用明天不能用”的工具去跑CI。

AgentLoop的思路是：不确定性无法被彻底消除，但可以被持续约束。

约束的方式就是经验。Agent每次执行任务都会留下完整的执行轨迹，成功路径里有有效的方法，失败路径里有反复踩的坑。这些轨迹被清洗、提炼、挖掘之后，变成可复用的经验，在下一次任务执行时注入到上下文里。

Trace到Trajectory：数据清洗比模型调优更重要

原始Trace的数据量非常大。里面包含大量基础设施Span、重复消息、跟决策无关的日志。如果直接拿原始Trace做长期存储和分析，成本高不说，真正有价值的信号会被噪音淹没。

AgentLoop的做法是先清洗再组装：把原始Trace去噪，只保留任务目标、行动步骤、工具调用、观察结果、错误信息、恢复过程和最终结果，形成标准化的Trajectory。

内部复杂样本里，清洗后的Trajectory可以降到原始Trace的4%到6%的数据量级。

这个清洗环节对测试场景特别关键。 测试执行的Trace里充斥着大量重复的页面快照、网络请求日志、截图。但真正有价值的信号是：Agent在哪个步骤选错了定位策略、哪个断言写得太脆弱、哪次工具调用超时后选择了错误的恢复路径。

清洗后的Trajectory让挖掘算法能直接分析Agent的决策过程，而不是在日志片段里大海捞针。

经验怎么进入下一次执行：Skill + CLI

经验生成之后，不需要重新训练模型，也不需要重建Agent。

在客户端安装Recall Skill，通过CLI配置经验库和访问凭证。安装完成后，Agent在任务开始、调用关键工具、遇到错误或准备交付时，会自动检索相关经验，把召回结果作为参考上下文注入当前任务。

这种方式有三个好处：

• 接入快，不改模型权重
• 经验更新后立刻生效
• 经验出问题可以快速下线或限制范围

而且经验是跨模型、跨Agent框架共享的。换模型或换框架之后，业务经验不用从零积累。一个Agent验证过的有效路径，其他Agent也能召回；一个团队踩过的坑，其他团队可以提前避开。

测试场景实操：Playwright MCP+ 自愈执行

说了这么多理论，落到测试场景里到底怎么跑？

我拿一个Web登录功能试了一套组合方案：用Playwright MCP驱动浏览器，配合自愈引擎处理定位失败。

第一步：配置Playwright MCP

Playwright MCP的核心是把浏览器的操作封装成AI可以调用的工具，同时把页面状态（DOM树、网络请求、Console日志）转化为模型能理解的文本快照。

快照不是简单截取HTML，而是基于可访问性树精简过的，优先保留有ARIA角色、标签和交互属性的元素。

npm init -y
npm i @playwright/test
npx playwright install

第二步：写一个用例生成脚本

from rag_playwright import RAGCodeGen

rag = RAGCodeGen(index_path="./api_docs/swagger.json")
prompt = "测试登录功能：输入admin/123456，点击登录，应跳转到/dashboard"
code = rag.generate(prompt, framework="playwright")

with open("tests/login.spec.ts", "w") as f:
    f.write(code)

生成的代码大概长这样：

test('login test', async ({ page }) => {
  await page.goto('/login');
  await page.fill('#username', 'admin');
  await page.fill('#password', '123456');
  await page.click('button:has-text("登录")');
  await expect(page).toHaveURL('/dashboard');
});

第三步：注册自愈插件

import { healPlugin } from 'playwright-auto-healing';

export default {
  use: { ... },
  plugins: [healPlugin({
    maxHealingAttempts: 3,
    llmModel: 'gpt-4',
    healSelectors: ['css', 'text', 'aria', 'xpath']
  })]
};

跑测试的时候加上自愈参数：

npx playwright test --heal=auto --trace=on

当定位失败时，控制台会输出类似这样的信息：

[Healing] Failed to find '#submit-btn', trying AI locator...
→ new selector: 'button[aria-label="提交"]'
✓ healed in 2.1s

这才是经验自进化在测试场景里最直观的体现。 第一次定位失败，自愈引擎尝试了CSS、文本、ARIA等多个维度，最后用aria-label定位成功。这次成功的修复路径被记录为Trajectory，经过挖掘后变成经验。下次遇到类似的定位失败，Agent会优先尝试aria-label方案，而不是从头遍历所有选择器。

接口测试场景：Swagger + Skills拆解

Web端跑通了，接口端能不能复用同一套思路？

能，但需要换一种拆法。

Swagger文档写得很规范，路径、参数类型、必填属性、响应结构都清清楚楚。但直接在CI里跑通的测试用例，需要的上下文远不止这些。

• 合法的业务数据示例（userId必须是数据库里真实存在的）
• 边界值规则（age范围1-120，超过400报错）
• 调用链路依赖（先调登录拿token，再调业务接口）
• 断言规则（响应里code=0时data不能为空）

Swagger里一个都没有。测试人员写用例时，脑子里调用了两类知识：技术规范来自Swagger，业务经验来自规则库、历史缺陷、领域知识。AI生成用例失败的根本原因就是：模型只看到了前半部分。

实际可行的工程路径是：用RAG把业务规则注入，用Skills把用例生成拆成可编排的原子能力。

我把用例生成拆成了三个独立Skill：

参数构造Skill：输入参数名、类型、约束，输出一组合法的测试数据值。对于依赖外部数据的参数，自动插入获取逻辑。比如userId不能是0，它自动从数据库里拉一个有效值。

依赖链处理Skill：分析接口的前置条件，生成setup代码。需要登录态就自动生成调用登录接口并提取token的代码块。

断言生成Skill：根据响应schema和业务规则，生成状态码断言、字段存在性断言、值范围断言。

每个Skill有独立的prompt模板，调用时只关注自己的职责。不让LLM一次生成整个测试文件，任务太复杂容易出错。

完整的经验闭环长什么样

把Web端和接口端的链路串起来，整个飞轮是这样的：

观测 → Agent执行测试任务，产生Trace → 轨迹 → 清洗组装为Trajectory → 挖掘 → 从多个轨迹中发现有效路径和失败模式 → 经验 → 生成结构化经验 → 召回 → 下次执行时注入上下文 → 运行 → 产生新的Trace

AgentLoop在内部复杂样本里验证过效果。StarOps实验中平均工具调用次数下降25.1%，有害事件下降27.8%。SWE-bench Verified通过率从67.2%提升到74.4%。

但真正值得关注的不是单次成功率，而是同类任务多次执行的稳定性。如果平均准确率提高的同时质量下限被抬高、运行波动逐步缩小，Agent才算从“偶尔做对”走向“可以稳定上线”。

企业衡量经验库的有效性，应该同时看这几个指标：平均任务成功率、首次完成率、同类任务多次执行的波动范围、失败模式的集中度、人工接管率和返工率。

落地时踩过的坑

第一，Trace接入方式要提前规划。 AgentLoop支持多种接入方式——探针、OpenTelemetry、Pilot、eBPF。如果你的Agent不方便改代码，可以用eBPF从系统层面采集。但不同接入方式采集到的数据粒度不一样，影响后续经验挖掘的质量。建议先跑通一条链路再扩展。

第二，不是所有任务都适合做经验挖掘。 一次性的、低频的测试任务，积累的经验样本太少，挖掘出来的规律没有统计意义。高频回归、多版本迭代的测试场景才值得投入。

第三，经验注入不是Token一定下降。 有些任务为了获得更高成功率，可能需要使用更多上下文。合理的目标是在质量护栏下持续优化单位成功成本，而不是单独追求最低Token消耗。

第四，经验库需要版本管理和权限控制。 不同业务线的经验应该隔离，通用经验可以跨Agent共享。AgentLoop支持按AgentSpace和经验库做权限边界。别把所有经验塞进一个池子里，召回的时候噪音太大。

关于我们

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。