1. 为什么 Web 测试需要 AI Agent如果你写过一段时间的 Web 自动化测试大概会遇到这些让人头疼的场景页面结构一变之前的 XPath、CSS 选择器全部失效测试代码跟着一起“重构”。登录、下单、权限校验这类跨页面流程每一步都要写大量样板代码。需求文档更新很快测试脚本永远落后于产品迭代。回归测试用例数量巨大真正执行的频率却很低。测试数据、环境状态、权限条件稍不一致用例就出现“随机失败”。传统自动化测试的核心问题是把人的操作步骤固化成代码。一旦被测系统变化测试代码就得同步改。本质上我们是在用代码“翻译”测试用例而没有赋予测试工具“理解”和“自主决策”的能力。最近几年随着大语言模型LLM能力的提升出现了一种新思路让 AI Agent 充当测试执行者。Agent 不只是执行预设步骤它可以根据当前页面状态、任务目标、工具返回结果决定下一步该点击哪里、输入什么、断言什么。本文要聊的开源项目 ArgusShow HN 上展示的开源项目走的就是这个方向用开源 AI agents 对 Web 应用做自动化测试。这篇文章不会停留在概念介绍上。我会从核心原理出发带你拆解 Agent 测试 Web 应用的工作方式并给出一个可以实际运行的极简示例。通过这个示例你可以理解 LLM 如何驱动浏览器、如何设计工具调用、如何收集页面状态并生成结论。读完之后你既能把类似思路落地到自己的测试项目中也能更好地评估应该选择哪种 AI 测试方案。如果你是刚开始接触 AI Agent 的开发者、测试工程师或者正在为项目选型 AI 测试方案这篇文章都很适合你。2. Argus 是什么开源 AI 测试 Agent 的核心思路2.1 Argus 的定位Argus 是一个开源项目定位很明确面向 Web 应用测试场景的 AI agents 工具集。简单说它想解决传统自动化测试中的两个老大难用例维护成本高页面改动、文案调整、交互逻辑变化都会让写死的测试脚本失效。回归覆盖面不足测试用例数量庞大人工维护跟不上导致回归测试总是做不完整。Argus 的思路是把“测试执行过程”交给 AI Agent。测试人员提供目标描述比如“打开首页完成登录验证用户中心入口存在”Agent 自己决定用什么方式实现这个目标并在执行过程中根据实际页面反馈不断调整。这种模式下测试脚本不再是一系列固定的操作指令而是一段“任务描述 工具能力 终止条件”。页面结构变化时只要语义没有大变Agent 就有可能自动适应新页面。2.2 Agent 测试的工作流程一个典型的 AI Agent 测试流程大致如下接收测试任务描述例如“验证登录失败时是否提示错误信息”。观察当前页面状态提取可点击元素、输入框、按钮等关键信息。根据任务目标和当前状态决定下一步动作。调用工具执行动作比如点击、输入、跳转、截图。观察动作结果判断是否达到目标。如果尚未完成回到第 3 步继续执行。达到目标后输出测试结论和必要证据。这个过程形成了一个闭环观察 → 决策 → 执行 → 再观察。只要 Agent 的决策能力足够强工具集足够完整它就能处理相当复杂的多步骤流程。2.3 什么时候适合用 AI Agent 测试AI Agent 测试并不是要完全取代传统自动化测试而是适用于特定的场景场景传统自动化AI Agent 测试页面结构频繁变化维护成本高适应能力较强多步骤业务链路登录、下单、支付脚本冗长自然语言描述即可回归测试全量执行成本可控需要关注成本和安全精确到像素级断言可以做到目前偏弱离线、无网络环境可以运行依赖 LLM 服务在快速迭代的 Web 业务中AI Agent 测试尤其适合做探索性测试和冒烟测试它能以较低成本快速覆盖关键路径并发现传统脚本难以预料的边界问题。3. 环境准备与项目结构接下来我们进入实操环节。我会基于 Argus 的设计理念实现一个极简的 AI 测试 Agent。注意这是用于理解原理的最小实现不是 Argus 官方代码。具体使用 Argus 项目时请以官方 README 和实际版本为准。3.1 运行环境本文示例使用以下环境Python 3.10 及以上版本Playwright for PythonOpenAI Python SDK或其他兼容 OpenAI 接口的 LLM 服务版本方面不必完全一致只要保持依赖之间兼容即可。示例代码在 Python 3.10 / 3.11 上测试通过。3.2 安装依赖创建项目目录后执行以下命令安装依赖mkdir ai-agent-test cd ai-agent-test pip install playwright openai安装完成后还需要安装 Playwright 的浏览器内核playwright install chromium如果你希望使用界面模式观察 Agent 操作安装 chromium 就够了如果要用 WebKit 或 Firefox可以对应安装其他内核。3.3 项目结构这个极简项目只需要两个文件ai-agent-test/ ├── agent_test.py # Agent 主脚本 └── .env # 环境变量可选其中.env文件用于保存 LLM API Key内容如下OPENAI_API_KEYsk-xxxxxxxxxxxxxxxx当然也可以不创建.env直接在系统环境变量中配置OPENAI_API_KEY。3.4 准备被测系统为了让 Agent 有东西可测你需要准备一个测试用的 Web 应用。如果你手头没有现成项目可以用任意一个公开的、允许自动化访问的演示站点或者本地启一个简单的 HTML 页面。这里我建议准备一个带登录功能的简单页面因为登录流程是 Web 测试中最典型的场景。示例站点不一定需要多复杂关键是要有输入框、按钮、页面跳转等要素。4. 核心原理拆解LLM 浏览器工具调用在写代码之前先把核心原理讲清楚。只有理解了原理你才能根据自己的业务场景扩展工具集和任务目标。4.1 Agent 循环AI 测试 Agent 本质上是一个循环把任务目标、历史操作、页面状态打包成消息。调用 LLM让模型决定下一步动作。LLM 返回一个工具调用指令比如click(selectorbutton.login)。Agent 执行工具把执行结果追加到消息历史。再次调用 LLM直到模型认为任务完成或者达到最大步数。这个循环和传统自动化“按步骤执行”有本质区别每一步都是基于当前真实页面状态动态决策的而不是阅读写死的步骤列表。4.2 工具集设计Agent 能执行什么动作取决于我们给它提供什么工具。一个最小可用的 Web 测试工具集至少需要工具作用open_url打开指定 URLclick点击元素支持文本或选择器fill在输入框中填入内容get_text获取页面文字内容用于断言screenshot截图保存证据page_info获取当前 URL 和标题更完整的工具集还可以包括切换 Tab、处理弹窗、等待元素、获取元素属性、上传文件、执行 JavaScript 等。设计工具集时有一个原则工具粒度要适合 LLM 调用。太细比如“移动鼠标 10 像素”会让模型难以决策太粗比如“执行整个登录流程”又让模型失去灵活性。推荐以“用户视角的可见操作”为粒度比如点击、输入、读取文字、截图。4.3 上下文与状态管理Agent 之所以能在多步骤流程中保持连续性是因为我们始终把“之前的操作和结果”放在消息历史里。每次调用 LLM 时都会携带系统提示词说明 Agent 的角色和任务用户的测试目标之前每一步的工具调用及结果当前页面状态摘要需要注意的是页面状态不能全量塞给模型。完整的 DOM 可能有几万 token既不经济又容易让模型“迷失”。更合理的做法是抽取关键信息比如可见文字、按钮文案、输入框占位符、当前 URL组成一段简洁的页面摘要。5. 完整实战仿 Argus 思路实现极简 AI 测试 Agent下面进入代码实现。这个示例会实现一个带“登录验证”任务的极简 AI 测试 Agent。代码结构清晰适合你在此基础上扩展。5.1 创建项目文件首先创建agent_test.py并在开头导入依赖# agent_test.py import json import os from openai import OpenAI from playwright.sync_api import sync_playwright client OpenAI(api_keyos.environ.get(OPENAI_API_KEY))这里从环境变量读取OPENAI_API_KEY。如果你在.env里配置了 Key需要先加载from dotenv import load_dotenv load_dotenv()如果没有安装python-dotenv可以先执行pip install python-dotenv。5.2 定义工具清单为了让 LLM 知道有哪些工具可用我们需要声明工具清单。OpenAI 的 Function Calling 支持结构化工具描述TOOLS [ { type: function, function: { name: open_url, description: 打开指定 URL参数url目标网址, parameters: { type: object, properties: { url: {type: string, description: 目标网址} }, required: [url] } } }, { type: function, function: { name: click, description: 点击页面元素可通过 text 指定可见文本或通过 selector 指定 CSS 选择器, parameters: { type: object, properties: { selector: {type: string, description: CSS 选择器}, text: {type: string, description: 要点击的按钮/链接文本} } } } }, { type: function, function: { name: fill, description: 在输入框中输入内容参数selectorCSS 选择器、value输入内容, parameters: { type: object, properties: { selector: {type: string, description: CSS 选择器}, value: {type: string, description: 输入值} }, required: [selector, value] } } }, { type: function, function: { name: get_text, description: 获取当前页面的文本内容用于检查页面是否包含特定文字, parameters: { type: object, properties: {} } } }, { type: function, function: { name: screenshot, description: 对当前页面截图并保存参数path保存路径, parameters: { type: object, properties: { path: {type: string, description: 截图保存路径} }, required: [path] } } } ]工具描述中每个参数的说明要尽量具体。LLM 靠描述来理解参数含义描述不清晰会严重影响工具调用的准确性。5.3 实现工具执行器工具清单是“声明”还需要一个函数负责实际执行。这个执行器接收工具名称和参数调用 Playwright 的 API 操作页面def execute_tool(page, tool_name, args): if tool_name open_url: page.goto(args[url], timeout15000) page.wait_for_load_state(networkidle) return {status: ok, url: page.url} if tool_name click: if args.get(text): page.click(ftext{args[text]}, timeout8000) elif args.get(selector): page.click(args[selector], timeout8000) else: return {status: error, message: click 需要 text 或 selector 参数} page.wait_for_timeout(800) return {status: ok, url: page.url} if tool_name fill: page.fill(args[selector], args[value]) page.wait_for_timeout(300) return {status: ok, selector: args[selector]} if tool_name get_text: content page.inner_text(body) return {status: ok, text_preview: content[:1200], url: page.url} if tool_name screenshot: page.screenshot(pathargs.get(path, screenshot.png), full_pageFalse) return {status: ok, path: args.get(path, screenshot.png)} return {status: error, message: f未知工具: {tool_name}}这里我对get_text返回的文本做了截断只保留前 1200 字符。原因前面说过页面文本太长会占用大量上下文截断后对模型来说已经足够获取关键信息。5.4 构建 Agent 循环现在实现核心的 Agent 循环。这个循环的思路是将任务目标、系统提示、历史操作记录统一放入消息列表。调用 OpenAIA 接口带上工具清单。如果返回结果包含工具调用就执行工具把结果加入消息历史然后继续。如果返回结果没有工具调用说明 Agent 认为任务已经结束输出最终结论。def run_test_agent(page, task: str, max_steps: int 8): messages [ { role: system, content: ( 你是一个 Web 应用测试 Agent。你的任务是通过调用工具完成给定的测试目标。 每次行动前先分析当前页面状态选择最合适的工具。 完成目标后直接输出测试结论不要再调用工具。 如果遇到错误尝试换一种方式处理。 ) }, {role: user, content: f测试目标{task}} ] for step in range(1, max_steps 1): print(f\n 第 {step} 步 ) response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, tool_choiceauto ) message response.choices[0].message messages.append(message) if not message.tool_calls: print(Agent 结论:, message.content) return message.content for tool_call in message.tool_calls: fn_name tool_call.function.name try: fn_args json.loads(tool_call.function.arguments) except json.JSONDecodeError: fn_args {} print(f调用工具: {fn_name}, 参数: {fn_args}) try: result execute_tool(page, fn_name, fn_args) except Exception as e: result {status: error, message: str(e)} messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) print(达到最大步数任务结束。) return 未能在限制步数内完成任务这里有几个关键点需要说明tool_choiceauto让模型自己决定是否调用工具、调用哪个工具。message.tool_calls为空时说明模型不再调用工具直接输出文字结论此时视为任务完成。异常捕获即使工具执行出错也把错误信息返回给模型让它修正策略。这比直接崩溃健壮得多。max_steps限制防止 Agent 陷入无限循环。实际项目中建议把这作为可配置项。5.5 编写主函数主函数负责启动浏览器、创建页面、调用 Agent 循环def main(): task ( 打开登录页面 http://localhost:8080/login 使用用户名 admin、密码 123456 登录 然后检查登录后的页面是否包含“登录成功”字样并截图保存。 ) with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() try: run_test_agent(page, task) finally: browser.close() if __name__ __main__: main()这里把任务描述写成了自然语言。实际项目中可以把任务通过命令行参数或测试用例文件传入实现“数据和逻辑分离”。5.6 运行与验证执行脚本python agent_test.py如果你用的 LLM 服务商、模型名或 API 地址与示例不同需要在代码中调整client的初始化参数。比如使用本地部署的兼容 OpenAI 接口模型时client OpenAI( api_keylocal, base_urlhttp://localhost:11434/v1 )5.7 预期输出说明一次典型运行可能产生类似输出 第 1 步 调用工具: open_url, 参数: {url: http://localhost:8080/login} 第 2 步 调用工具: fill, 参数: {selector: #username, value: admin} 第 3 步 调用工具: fill, 参数: {selector: #password, value: 123456} 第 4 步 调用工具: click, 参数: {text: 登录} 第 5 步 调用工具: get_text, 参数: {} 第 6 步 调用工具: screenshot, 参数: {path: login_result.png} Agent 结论: 登录成功页面包含“登录成功”字样截图已保存为 login_result.png。注意由于 LLM 不是确定性算法实际运行时的步骤顺序、选择器、文本都可能与上面不同。如果页面元素缺少稳定的id或name属性模型可能选择用文本定位这是正常的。如果 Agent 在某个步骤连续失败它会尝试换一种策略。比如第一次用 selector 定位失败第二次可能会改用文本定位。这正是 Agent 测试相比传统脚本的优势所在。6. 常见问题与排查思路AI Agent 测试属于较新的实践运行中遇到的问题也不少。下面整理高频问题及排查思路问题现象常见原因解决思路模型不调用任何工具直接输出臆想结果系统提示词不明确或工具描述不清晰强化提示词明确要求“必须通过工具获取页面信息后再下结论”Agent 反复执行同一个动作页面状态没有变化模型陷入循环限制最大步数要求每次工具调用前先输出“对页面状态的判断”定位元素失败页面结构复杂选择器不准确截取页面文本和 DOM 片段反馈给模型增加等待时间页面状态信息过大超 token 限制DOM 文本太长对页面文本做截断优先提取可见文本、按钮文案、输入框占位符LLM API 调用报错网络问题或 Key 失效检查 API Key、网络环境、服务商状态测试结果不稳定LLM 决策有随机性设置较低温度参数增加关键步骤的断言将“检查点”写进提示词6.1 关于测试用例的筛选问题传统自动化测试框架中例如 Google TestC 测试框架提供了::testing::flags_gtest_filter这样的机制可以通过--gtest_filterFoo.Bar精确筛选要执行的用例。这种“用例过滤”思路在传统测试中非常重要它让你只跑相关的用例。但在 AI Agent 测试中“筛选”发生了变化。你不需要通过复杂的命令参数过滤用例而是直接在任务描述中写清楚要测什么。比如“只验证登录失败的提示信息”“检查购物车为空时的页面展示”“走一遍从商品详情到提交订单的全流程”Agent 会自行决定需要执行哪些步骤、跳过哪些无关操作。用自然语言替代过滤参数是 AI 测试和传统测试在工作方式上的一个明显区别。不过这并不意味着传统测试框架的过滤概念没有价值。在实际工程中你仍然需要一套机制来决定“哪些任务要跑、哪些任务可以跳过”。比如在 CI 中冒烟测试任务、回归测试任务应该有自己固定的 Prompt 集合。6.2 排查 Checklist如果你遇到 Agent 表现不如预期建议按下面顺序排查任务描述是否足够具体有没有给出明确的验证点工具集是否覆盖了当前任务所需的动作工具描述是否清晰模型能否理解每个参数的含义页面状态反馈信息是否足够模型有没有看到关键文字最大步数设置是否合理太少的步数会让模型仓促结束。是否有稳定的页面元素标识没有的话模型只能依赖文本定位。LLM 版本和参数是否合适不同模型对 Function Calling 的支持度不同。7. 最佳实践与工程建议7.1 任务描述要写清楚“验证点”AI Agent 不是万能的它需要明确的目标。写任务时不仅要说清操作路径还要说清验证点不好的写法登录一下看看 好的写法打开 /login用 admin/123456 登录验证登录成功后页面出现“工作台”或“欢迎”并截图验证点越具体Agent 的判断越准确最终结论也越可靠。7.2 用“检查点”约束结论你可以要求 Agent 在输出结论前必须调用get_text获取页面文本再依据文本内容判断测试是否通过。这样可以有效避免模型“闭着眼睛得出结论”。示例系统提示词你必须在查看页面文本后给出结论禁止在未调用 get_text 的情况下断言页面内容。7.3 控制上下文长度每轮对话都会保留历史记录步骤越多 token 消耗越大。建议对get_text返回的页面文本做截断处理。丢弃早期的工具结果只保留最近几步的操作记录。设置合理的最大步数通常 8 到 15 步足够处理大部分 Web 测试任务。如果任务非常长考虑拆分为多个子任务串联执行。7.4 提升操作稳定性AI Agent 依赖真实浏览器环境运行稳定性不如传统脚本。可以从这些方面优化统一测试环境避免本机弹窗、网络波动影响结果。对关键操作增加兜底逻辑比如等待元素出现后再点击。当工具执行失败时把错误信息返回给模型给它一次“自我修正”的机会。建议在headlessTrue模式下跑回归在有界面模式下调试。7.5 保证测试数据隔离AI Agent 操作真实浏览器有可能产生真实数据。测试环境必须与生产环境隔离推荐使用独立的测试域名或本地环境。使用 mock 的外部接口。测试产生的数据要可清理、可重置。涉及删除、修改数据的操作必须加二次确认或只在专用环境执行。7.6 安全与权限边界使用 AI Agent 执行测试时本质上是在“放权”给模型操作浏览器。因此在生产环境之外需要额外注意几件事只授权模型访问测试环境的 URL不要给它访问生产系统的能力。工具的访问颗粒度要控制比如限制 Download 操作、文件写入目录等。API Key 和密钥存放在环境变量或密钥管理中不要提交到代码仓库。记录 Agent 的完整操作日志方便审计和追踪问题。7.7 结果证据留存测试不能只看结论还要能溯源。建议每次测试自动收集操作步骤日志。关键节点的截图。页面 URL 变化记录。最终结论及其依据。这些证据既方便排查问题也可以用于向团队展示测试覆盖率。7.8 成本控制LLM API 是按 token 计费的Agent 每一步都会产生对话费用。控制方法包括给可能超过步数的任务设置上限。精简系统提示词和工具描述。页面内容截断减少无效 token。优先使用成本更低的模型做常规冒烟测试再把复杂任务交给更强模型。7.9 与 CI 集成的思路AI Agent 测试要真正产生价值建议接入持续集成将测试任务定义成配置文件例如 JSON/YAML。在 CI Pipeline 中启动测试环境。执行 Agent 测试脚本。收集日志、截图、结论生成测试报告。失败时通过消息通知相关人。接入 CI 时尤其要注意环境稳定性建议先跑少量核心任务验证效果后再逐步扩大覆盖面。8. 总结与下一步学习路线本文围绕 Argus 这个开源项目切入完整梳理了 AI Agent 测试 Web 应用的核心思路和落地方式。我们讨论了传统自动化测试的痛点、Agent 测试的工作流程、工具集设计、上下文管理并用 Python Playwright OpenAI 实现了一个可以运行的极简 AI 测试 Agent。通过这个示例你应该已经掌握了几个关键点AI 测试 Agent 是一个“观察 → 决策 → 执行 → 再观察”的循环。工具集是 Agent 操作浏览器的接口设计粒度很关键。页面状态需要有效抽取和截断不能全量塞给模型。测试结论需要有依据不能依赖模型凭空输出。工程落地时数据隔离、成本控制、日志审计都是必须考虑的问题。下一步你可以从这几个方向继续深入扩展工具集为你的业务场景补充上传文件、处理弹窗、切换 Tab、读取 Cookies 等能力。接入本地模型尝试用 Ollama、vLLM 等本地部署模型替代云端 API解决数据隐私和成本问题。设计任务编排把复杂的端到端测试拆成多个子任务通过一个调度器串联。完善报告系统把截图、日志、结论组装成可读的测试报告接入飞书、钉钉或企业微信通知。跑一遍真实项目选择一个内部测试环境用 AI Agent 完成一条核心业务链路然后对比传统自动化的维护成本。在实际落地时有一点忠告AI Agent 测试目前更适合作为“补充手段”而非“唯一方案”。关键核心链路、数据一致性要求极高的场景传统自动化仍然更可靠。先把 AI Agent 放在探索性测试、冒烟测试、页面结构易变的功能测试上用最小成本验证效果再逐步扩大使用范围。最后回到 Argus 这个项目本身。如果你对开源 AI 测试 Agent 感兴趣可以关注 Argus 的实现方式和社区进展。类似项目各有侧重有的强调多 Agent 协作有的侧重报表能力有的深度集成某个测试框架。多对比、多实践才能找到最适合你自己团队的那套方案。
