阶段总结：UI-Tars + 检索增强生成（RAG）= 端到端探索性人工智能测试代理（第三部分）

这是本系列的最后一篇文章。

我将展示一个示例，用以说明：

如何将 UI-Tars 的系统 2推理与本地搭建的 RAG（基于 Ollama 和 LangChain）结合，从而创建一个能够理解用户高级指令，并基于每个阶段的浏览器截图实现自动化执行的系统。
验证 UI-Tars 和本地 RAG 结合后系统 2 推理的能力。
端到端演示
本次演示以 Miro 为例，展示处理非 B2C且复杂系统的能力。AI智能体根据用户的单条指令执行任务：

“创建一个新画板，添加 2 个便签，并用连线将这两个便签连接起来。”

⚠️非常重要⚠️：本次演示使用的是 Miro 的免费计划，对所有可以使用免费计划的人开放。为了验证稳定性，测试执行次数不超过 10 次。身份验证部分使用的是我个人的 Miro 免费账户（已硬编码，以避免任何其他风险）。我强烈建议任何想要针对面向客户的产品复现此测试的读者，不要影响产品的正常使用，并且必须分别遵循相关产品的政策。

https://youtu.be/L-_vJ23O118（视频链接）

（👀 除了身份验证之外，其余操作均由人工智能体根据单条高级用户指令自主规划和执行）
2. 说明
在测试之前，我们需要部署 UI-Tars-7B-SFT：

步骤 1：将 UI-Tars-7B-SFT 部署到 Hugging Face，部署到 L40S 1 * GPU 上，你可以按照此处的步骤进行操作。
步骤 2：为 Midscene 配置.env 文件

OPENAI_API_KEY="hf_"  // 这可以是Hugging Face的访问密钥
OPENAI_BASE_URL="https://something/v1"  // 这可以是Hugging Face的端点URL
MIDSCENE_MODEL_NAME="ui-tars-7b-sft" 
MIDSCENE_USE_VLM_UI_TARS=1  // 必须告知Midscene切换到UI-Tars
MIDSCENE_LANGSMITH_DEBUG=1  // 启用向Langsmith发送跟踪信息，帮助我们调试和测试这个人工智能代理
LANGSMITH_API_KEY= 
LANGSMITH_ENDPOINT="https://api.smith.langchain.com"
LANGSMITH_TRACING_V2=true
LANGSMITH_PROJECT=
DEBUG=true  // 这将启用OpenAI SDK在控制台打印调试日志

步骤 3：在本地构建自己的 Ollama + Langchain 环境，拉取 nomic-embed-text 作为嵌入，并在本地构建一个包含 “非常结构化” 文档的 RAG（ollama）。

测试进行了三个步骤：

步骤 1：进行身份验证，将身份验证状态保存到本地文件，这是通过按照 Playwright 身份验证指南编写 Playwright 代码来实现的。
步骤 2：仅向 ai () 函数传递一条高级用户指令，让 ai () 函数处理指令的规划和执行。这个函数由字节跳动创建的工具 Midscene 提供。

# Passing only ONE user instruction to UI-Tars, UI-Tars only use this single instruction to do reasoning. 

        await ai(`**ID: ${ uuidv4() }, 这是一个新指令，完全忽略之前的记忆，严格按照指令和规则执行，禁止幻想**
Given A free plan user creates a new board without upgrade,
And the user creates 2 sticky notes in 2 different side of the grid, 
Then the user adds a line from 1st sticky note to the 2nd sticky note`)

步骤 3：使用AI通过 aiAssert () 函数来断言最终状态。
阶段结论

3.1 系统 2 推理能力
参考论文中提到，系统 1 推理是指模型在没有思维链的情况下直接产生动作，而系统 2 推理则涉及一个更审慎的思考过程，即模型在选择动作之前生成推理步骤。

在第一部分中，使用 Vinted 展示了一个示例。通过将人类语言转换为单一的浏览器动作且无需思维链，它展示了系统 1 推理的良好效果。

上述视频通过具有思维链（包括我们自己的本地 RAG）展示了 UI-Tars 在系统 2 推理方面的能力。

要点：

与 GPT-4o 相比，UI-Tars 具有更好的系统 2 推理能力。（数据来自第二部分）
然而，要让 UI-Tars 针对特定领域或产品进行恰当的推理，需要一个结构化的 RAG，或者使用我们自己的输入数据对 UI-Tars 进行微调。（数据来自（UI-Tars 的 RAG）[https://github.com/web-infra-dev/midscene/issues/426]）
对于一个B2C网站，结合一个小型 RAG 和 UI-Tars-7B-SFT，我们可以实现非常高级的指令，例如：我想在 Vinted 上买一个包。（已经在Vinted.com上进行了测试，但我不能分享演示，因为该测试被视为机器人操作，并且该动作违反了 Vinted 的政策。）

3.2 适用的产品和场景

即使不构建 RAG，这个解决方案也已经能够作为B2C网站现有回归端到端自动化测试的补充，但它需要一些系统 2 推理。
这个解决方案能够作为B2C应用程序自动化探索性测试的一部分，而其他情况则需要构建 RAG，或者使用他们自己的结构化业务数据对 UI-Tars-SFT 进行微调。
这个解决方案能够进行图形用户界面（GUI）和光学字符识别（OCR）检查，以取代你现有 Playwright 或 Puppeteer 测试中的截图断言。（前提是你截图断言的目的不是将用户界面样式与给定图片进行比较）

3.3 问题与风险

你可能会很兴奋！它已经能够解决质量保证工程中的实际挑战，但它需要谨慎使用并持续开发。

质量保证工程中的一个问题可能会从 “自动化测试不稳定 / 过时” 转变为 “人工智能决定的自动化测试结果不可信”。
对于将 RAG 与 UI-Tars 结合使用的情况，它在 7B-SFT 下运行稳定，但在 7B-DPO 下运行不佳（或者根本无法运行），所以需要更多努力来使该解决方案更具扩展性。
如何将这个AI智能体作为虚拟质量保证工程师应用到现有的软件开发生命周期（SDLC）中，在应用的时间和方式以及结果的稳定性方面都面临挑战，尽管它在系统 1 推理方面已经相当稳定，并且在部分系统 2 推理方面也较为稳定。
如果你的目标之一是实现测试执行的高速度，那么对于复杂的 Web 应用程序（例如一些软件即服务（SaaS）应用程序），当过多使用系统 2 推理时，这个方案可能效果不佳，因为 UI-Tars 有其自身的短期和长期记忆，跳转到 “错误的” 缓存会导致结果偏差极大……

‍