测试Web应用是一件看起来简单、做起来却极其繁琐的事情。业务测试用例成百上千界面元素改个 class 就让回归脚本全线标红真实的用户操作路径又远比脚本里的线性步骤复杂。传统自动化测试框架擅长稳定执行脚本但很难处理“计划之外的状况”。而直接用大模型提问又无法让模型真实点击页面、读取网络请求、判断弹窗有没有出现。Argus 这类开源 AI Agent 的出现切中的正是这个矛盾它把大模型的自然语言理解和 AI Agent 的行动能力封装起来接上浏览器自动化环境让“一句测试目标”逐渐变成“自主执行测试动作并返回验证结果”的完整流程。它真正降低的不是“写脚本”的成本而是“探索、定位、判断、处理异常”的成本。这篇文章会把 Argus 放到一个真实可落地的方法论里来写。我们先理清 AI Agent 做 Web 测试的核心思路再给出环境准备、任务定义、代码示例和验证流程。你不需要立刻把现有自动化测试全部替换掉但可以拿一个小型业务页面跑通 Agent 测试闭环再判断它适合放在你的回归流程、冒烟测试还是探索性测试阶段。1. 这篇文章真正要解决的问题很多人看到“AI agents for testing web apps”的第一反应是这不就是自动生成测试脚本吗已经有很多工具在做类似的事输入页面地址AI 返回几条 Playwright 代码。如果 Argus 只是这样那它并不值得专门讨论。真正值得关注的差异是生成脚本和自主测试是两条路线。传统工具生成的是“静态产物”代码生成完毕执行人还是测试框架而 AI Agent 生成的是“动态行为”它会根据页面状态决定下一步点击哪里、输入什么、等待多久、是否需要重新尝试。对端到端测试来说后者的价值在于它能处理不确定性和页面变化。所以这篇文章要解决三个层面的问题理解层面AI Agent 测试 Web 应用和传统自动化测试框架、普通大模型问答的本质区别是什么。操作层面如何用 Argus 或同类开源 AI Agent 工具搭建一个最小可运行的测试环境并完成一条真实业务任务。决策层面它适合替代哪部分测试工作不适合替代哪部分以及真正接入项目时有哪些坑。如果你正在为以下问题困扰这篇文章正好适合你测试脚本维护成本太高页面元素变化频繁导致回归用例脆弱团队的探索性测试依赖人工但能投入的时间越来越少又或者你已经接触了 Claude、GPT 等大模型想知道它们到底怎么被用来“操作”浏览器而不是只“聊”页面代码。2. 开源AI Agent测试Web应用的核心思路2.1 从“脚本执行”到“目标驱动”传统端到端测试的写法是一条线性脚本打开 URL等待选择器输入内容点击按钮断言结果。每一步都写死了操作顺序。问题在于 Web 页面不是稳定状态机可能有加载动画、接口延迟、按钮 disabled、弹窗遮挡、A/B 实验变化。任何一步出现预期之外的 DOM 变化脚本就会中断。AI Agent 的思路完全不同。你给它一个目标比如“登录后验证个人中心显示当前用户名”它会把目标拆成多个子任务并根据当前页面反馈决定下一步动作。它不需要你预先指定每一步的选择器只要求你提供可操作的能力接口比如点击、输入、选择、滚动、截图和判断依据。核心循环可以概括为感知通过 DOM 快照、可访问性树或截图获取当前页面状态决策根据任务目标和历史信息选择下一个动作行动通过浏览器自动化接口执行点击、输入、跳转等操作验证读取新的页面状态判断任务是否达成或是否需要修正路径这个循环就是 AI Agent 的基本范式不管底层用的是大模型 API 还是本地模型结构都一样。2.2 Agent测试和传统测试的对比维度传统自动化测试AI Agent 测试任务输入具体脚本步骤自然语言目标或验收标准元素定位选择器固定变化即失败动态解析支持语义化定位异常处理依赖开发者预先编写等待和重试Agent 根据状态自行调整策略维护成本页面结构变化需要改脚本任务描述通常不变页面适配由 Agent 完成可解释性每步都有明确代码可读性强需要日志和思维链记录辅助查看稳定性高适合大规模线性回归中模型输出有概率因素需要加重试和断言适用场景大量重复、稳定、关键路径回归探索性测试、冒烟测试、复杂场景验证这个对比不是说 AI Agent 要完全替代现有测试框架。更准确的关系是传统框架负责稳定执行高频回归AI Agent 负责那些“脚本写起来太费劲、维护成本太高、但又必须有人/有东西去点一遍”的场景。2.3 开源的意义在哪里如果是一个闭源 SaaS 服务来做 AI 测试你要把被测系统的一些页面数据发送到第三方服务器。对很多企业内部应用来说这一步直接就是合规风险。开源项目最大优势是你可以把整个 Agent 运行在自己的环境里数据不出内网模型也可以选择调用内部 API 或者部署本地模型。定制能力也很关键Agent 的动作集合、提示词模板、断言逻辑都可以自己改。此外开源项目能让你看到底层到底发生了什么。测试 Agent 出问题时你能检查它使用了哪些工具、输出了什么中间决策、为什么选择了某个按钮。这种可观测性对生产环境接入非常重要。3. Argus的项目定位与适用场景3.1 Argus是一个什么样的Agent从项目名称和定位来看Argus 是一个开源的 AI Agent 工具目标是把 AI 智能体应用到 Web 应用测试场景中。它把浏览器自动化能力与语言模型决策能力组合在一起让测试人员可以通过自然语言描述任务由 Agent 自主完成操作和验证。这里需要说明如果你搜索到的仓库已经出现了更具体的功能列表、版本号或配置项请以项目官方 README 为准。本文后续的配置思路基于通用开源 AI Agent 测试工具的实现方式进行演示目的是帮你跑通“任务描述到执行结果”的闭环。通常一个 Web 测试 Agent 至少需要四层能力界面感知层读取 DOM、可访问性树、截图、当前 URL。动作执行层封装浏览器操作如点击、填写、选择、键盘、等待。任务规划层把自然语言目标拆成具体动作序列并在失败后调整。验收报告层记录操作步骤、截图、断言结果输出可读报告。开发者在接入 Argus 时实际是在配置这四层能力。3.2 哪些场景最适合从工程角度看以下几类 Web 应用测试任务最适合先用 AI Agent 跑通冒烟测试新版本发布后只需要确认主流程可用。Agent 比人跑得快比固化的冒烟脚本更抗页面元素变化。探索性测试给定一个业务目标让 Agent 自己尝试多条路径记录过程中遇到的页面异常或阻断。理论上它能覆盖比人工更广的点击路径。复杂业务流程的片段验证比如订单创建、支付回调、权限控制这类跨页面任务用 Agent 描述目标比维护一长串脚本更简洁。页面频繁改版时的回归辅助当 UI 结构频繁变化传统脚本一直修选择器时Agent 的语义理解方式可能减少这类维护工作。3.3 哪些场景不要盲目使用AI Agent 不是银弹。如果你的测试场景要求毫秒级稳定、断言非常精确、每一条路径都要绝对复现那传统自动化框架仍然更合适。Agent 的决策带概率性容易在复杂页面上选择错误元素或者因为多模态模型对截图的误判而执行无效操作。此外Agent 执行速度通常比直接脚本慢每步决策都需要模型推理不适合并发跑几千条用例。合规和权限也很关键。Agent 在测试环境里“自主操作”没问题但如果没有做好权限隔离和账号隔离它可能会访问到不该访问的数据。更稳妥的判断是先让 Agent 在测试环境跑非敏感场景确认识别和决策稳定后再逐步扩大范围。4. 环境准备与安装4.1 运行环境要求安装和配置 Argus 之前先确认基础环境。以下是一般开源 AI Agent 测试工具最常见的依赖操作系统Linux 或 macOS 优先Windows 也可以但浏览器自动化的无头模式在 Linux 服务器上更省资源。Python 版本通常要求 Python 3.9 以上。具体以项目文档为准。Node.js很多浏览器自动化底层依赖 Playwright 或 Puppeteer需要 Node 运行时。浏览器Chromium 或 Chrome。Playwright 通常可以在安装时下载对应浏览器内核。大模型 API可以配置 OpenAI 兼容接口、Anthropic 接口或本地模型服务不同项目支持范围不一样。如果你是在公司内网环境部署还需要确认可以访问模型服务或者已经搭建了内网模型网关。4.2 使用 Python 虚拟环境安装建议把所有依赖安装在独立的虚拟环境里避免污染系统 Python。下面是一个基于通用流程的示例# 创建项目目录 mkdir argus-demo cd argus-demo # 创建虚拟环境 python3 -m venv .venv source .venv/bin/activate # 安装项目包具体包名以项目 README 为准 pip install argus-ai-testing如果你是从源码安装git clone https://github.com/your-org/argus.git cd argus pip install -r requirements.txt这里容易踩的一个坑是Playwright 的浏览器内核不会随 pip install 自动安装。你需要额外执行playwright install chromium在安装过程中如果遇到网络下载失败优先检查是否有内网 npm/pip 镜像以及是否允许访问 Playwright 的 CDN。4.3 配置浏览器与模型服务安装完成后通常需要一个配置文件。这个文件负责告诉 Agent 使用哪个浏览器、哪个模型、模型 API 地址、API Key 放在哪里、超时时间等。一个典型的 YAML 配置长这样# 文件路径argus-demo/argus_config.yaml browser: headless: true viewport: width: 1280 height: 720 timeout: 15000 model: provider: openai model: gpt-4o-mini api_base: https://api.openai.com/v1 api_key_env: OPENAI_API_KEY temperature: 0.2 agent: max_steps: 10 retry_times: 3 save_trace: true screenshot_dir: ./screenshots配置项并不复杂但有几个细节需要留意api_key_env表示从环境变量读取 API Key避免把密钥写进配置文件。headless: false会比较适合第一次调试你可以看清楚 Agent 到底点了哪里。max_steps是单次任务的行动上限防止 Agent 在一个任务里无限循环白烧模型额度。temperature建议调低一点测试场景更需要确定性。设置环境变量export OPENAI_API_KEYyour-key-here如果你用的是本地模型服务只需要把api_base改成内网服务地址。比如使用 vLLM 或者 Ollama 时可以配置成model: provider: openai model: local-model api_base: http://localhost:8000/v1很多本地模型服务会提供 OpenAI 兼容接口所以配置逻辑是一致的。5. 用Argus编写和执行第一个测试任务5.1 任务定义的基本原则第一次使用 AI Agent 测试时不需要一上来就写复杂的多页面流程。建议从一个真实但简单的业务冒烟任务开始。任务描述越具体Agent 的执行成功率越高。比如下面这个任务“打开登录页面使用账号 demo 和密码 123456 登录登录成功后在页面右上角看到用户昵称 demo_user。”这段描述已经包含了起始状态打开登录页操作输入账号密码并登录验收标准右上角显示昵称你还可以补充类似“如果登录失败输出页面上的错误信息”这样的异常分支。好的任务描述通常包括目标、行动边界、验收标准、失败处理方式。5.2 命令行方式假设 Argus 支持命令行工具运行方式通常是argus run --task 打开登录页面... --config argus_config.yaml如果你希望把任务写入文件可以用 Markdown 或 YAML 定义任务# 文件路径tasks/login_test.yaml name: login_smoke_test description: 验证登录主流程 steps: - 打开登录页面 http://localhost:8080/login - 在用户名输入框中输入 demo - 在密码输入框中输入 123456 - 点击登录按钮 - 等待页面跳转 - 验证页面右上角显示 demo_user然后执行argus run --task-file tasks/login_test.yaml --config argus_config.yaml5.3 Python SDK 方式如果项目提供了 Python SDK你可以更灵活地控制 Agent 的执行流程。下面是一个示例脚本# 文件路径run_login_test.py from argus import AgentTestRunner, Task task Task( namelogin_smoke_test, description验证登录主流程, instructions 1. 打开 http://localhost:8080/login 2. 在用户名输入框中输入 demo 3. 在密码输入框中输入 123456 4. 点击登录按钮 5. 等待页面跳转 6. 验证页面右上角显示 demo_user , tags[smoke, login], ) runner AgentTestRunner(config_fileargus_config.yaml) result runner.run(task) print(result.status) # passed / failed / blocked print(result.summary) # 任务总结 print(result.steps) # 每一步操作记录这个示例用Task对象封装了一次测试目标AgentTestRunner负责加载配置并执行完整闭环。result对象里既包含最后的通过状态也包含每一步的决策记录。不同版本的项目 API 可能有差异最核心的调用模式是“创建任务、运行任务、获取结果”。你只需要把自己的任务描述替换进去先跑通最小闭环再研究更多参数。5.4 使用自然语言直接驱动如果你不想写代码很多 AI Agent 测试工具也允许在交互式终端里直接输入argus chat启动后你会进入交互会话输入任务描述后Agent 会逐步执行并把中间状态打印出来。这种方式适合快速验证 Agent 是否理解业务页面也适合探索性测试时随时追加要求。6. 运行与结果验证6.1 预期输出运行第一个任务时建议先用headless: false模式让浏览器窗口显示出来。你会看到 Agent 自动控制浏览器执行以下动作打开登录页定位输入框输入账号定位密码框输入密码点击登录按钮等待页面跳转读取页面内容查找目标昵称如果执行成功命令行会打印类似这样的摘要[argus] 任务完成状态passed [argus] 执行步骤数8 [argus] 截图已保存到./screenshots/step_8.png [argus] 追踪日志已保存到./trace/output_0.json判断成功的标准不只是状态字段是passed还要确认执行步骤的合理性。例如打开的是不是预期地址填写的输入框是不是正确的用户名输入框点击的按钮是不是真正的登录按钮验证方式是不是真的从页面读取到了用户昵称如果状态是passed但 Agent 只是“看到页面出现了 demo_user 字符串”而这个字符串一直出现在页面静态内容里那这个测试其实没有真正验证登录状态。这也是 AI Agent 测试中常见的问题表面通过实际验证无效。6.2 如何提升验证可信度要让 Agent 测试结果可信任务描述里应该尽量写“验证什么状态”而不是“看到什么文字”。比如把“验证页面右上角显示 demo_user”改成“验证页面右上角出现 demo_user 且此时 URL 不再是 /login”。更复杂一点可以在登录前后分别读取当前用户信息再判断变化。如果你使用的 Agent 工具支持自定义断言函数可以用 Python 写一个更确定的验证def assert_login_success(page): url page.url nickname page.locator(.user-nickname).inner_text() assert /login not in url, f仍然停留在登录页: {url} assert nickname demo_user, f用户昵称不匹配: {nickname}把这类函数注入执行流程后即便 Agent 的导航判断失误最终断言也能兜底。这是在 AI Agent 测试里非常值得投入的部分让模型负责“怎么操作”让代码负责“怎么验收”。6.3 从日志和截图排查问题AI Agent 测试和传统脚本测试有个区别传统脚本失败你定位的是选择器或等待条件Agent 失败你需要看的往往是决策链路也就是它为什么选择点击了某个元素为什么在那个步骤停了下来。所以运行后第一件事不是看最终状态而是打开追踪日志。里面通常会记录每一步执行前的页面摘要Agent 决定执行某个动作的原因动作执行后的页面响应如果出现异常模型如何重新规划截图也非常关键。很多页面动态内容一闪而过回看截图才能确认是 Agent 操作错误还是业务系统本身出了 Bug。7. 常见问题与排查思路问题现象可能原因排查方式解决方案启动时报浏览器内核错误Playwright 浏览器未安装或版本不匹配检查playwright install是否执行成功重新执行playwright install chromium或更新 Playwright 版本一直无法定位输入框页面结构复杂模型从 DOM 快照中无法准确识别查看步骤日志看模型找到了哪些候选元素在任务描述中补充页面特征或给元素添加>button> 开源AI Agent如何重塑Web应用测试：以Argus为例的实战指南
测试Web应用是一件看起来简单、做起来却极其繁琐的事情。业务测试用例成百上千界面元素改个 class 就让回归脚本全线标红真实的用户操作路径又远比脚本里的线性步骤复杂。传统自动化测试框架擅长稳定执行脚本但很难处理“计划之外的状况”。而直接用大模型提问又无法让模型真实点击页面、读取网络请求、判断弹窗有没有出现。Argus 这类开源 AI Agent 的出现切中的正是这个矛盾它把大模型的自然语言理解和 AI Agent 的行动能力封装起来接上浏览器自动化环境让“一句测试目标”逐渐变成“自主执行测试动作并返回验证结果”的完整流程。它真正降低的不是“写脚本”的成本而是“探索、定位、判断、处理异常”的成本。这篇文章会把 Argus 放到一个真实可落地的方法论里来写。我们先理清 AI Agent 做 Web 测试的核心思路再给出环境准备、任务定义、代码示例和验证流程。你不需要立刻把现有自动化测试全部替换掉但可以拿一个小型业务页面跑通 Agent 测试闭环再判断它适合放在你的回归流程、冒烟测试还是探索性测试阶段。1. 这篇文章真正要解决的问题很多人看到“AI agents for testing web apps”的第一反应是这不就是自动生成测试脚本吗已经有很多工具在做类似的事输入页面地址AI 返回几条 Playwright 代码。如果 Argus 只是这样那它并不值得专门讨论。真正值得关注的差异是生成脚本和自主测试是两条路线。传统工具生成的是“静态产物”代码生成完毕执行人还是测试框架而 AI Agent 生成的是“动态行为”它会根据页面状态决定下一步点击哪里、输入什么、等待多久、是否需要重新尝试。对端到端测试来说后者的价值在于它能处理不确定性和页面变化。所以这篇文章要解决三个层面的问题理解层面AI Agent 测试 Web 应用和传统自动化测试框架、普通大模型问答的本质区别是什么。操作层面如何用 Argus 或同类开源 AI Agent 工具搭建一个最小可运行的测试环境并完成一条真实业务任务。决策层面它适合替代哪部分测试工作不适合替代哪部分以及真正接入项目时有哪些坑。如果你正在为以下问题困扰这篇文章正好适合你测试脚本维护成本太高页面元素变化频繁导致回归用例脆弱团队的探索性测试依赖人工但能投入的时间越来越少又或者你已经接触了 Claude、GPT 等大模型想知道它们到底怎么被用来“操作”浏览器而不是只“聊”页面代码。2. 开源AI Agent测试Web应用的核心思路2.1 从“脚本执行”到“目标驱动”传统端到端测试的写法是一条线性脚本打开 URL等待选择器输入内容点击按钮断言结果。每一步都写死了操作顺序。问题在于 Web 页面不是稳定状态机可能有加载动画、接口延迟、按钮 disabled、弹窗遮挡、A/B 实验变化。任何一步出现预期之外的 DOM 变化脚本就会中断。AI Agent 的思路完全不同。你给它一个目标比如“登录后验证个人中心显示当前用户名”它会把目标拆成多个子任务并根据当前页面反馈决定下一步动作。它不需要你预先指定每一步的选择器只要求你提供可操作的能力接口比如点击、输入、选择、滚动、截图和判断依据。核心循环可以概括为感知通过 DOM 快照、可访问性树或截图获取当前页面状态决策根据任务目标和历史信息选择下一个动作行动通过浏览器自动化接口执行点击、输入、跳转等操作验证读取新的页面状态判断任务是否达成或是否需要修正路径这个循环就是 AI Agent 的基本范式不管底层用的是大模型 API 还是本地模型结构都一样。2.2 Agent测试和传统测试的对比维度传统自动化测试AI Agent 测试任务输入具体脚本步骤自然语言目标或验收标准元素定位选择器固定变化即失败动态解析支持语义化定位异常处理依赖开发者预先编写等待和重试Agent 根据状态自行调整策略维护成本页面结构变化需要改脚本任务描述通常不变页面适配由 Agent 完成可解释性每步都有明确代码可读性强需要日志和思维链记录辅助查看稳定性高适合大规模线性回归中模型输出有概率因素需要加重试和断言适用场景大量重复、稳定、关键路径回归探索性测试、冒烟测试、复杂场景验证这个对比不是说 AI Agent 要完全替代现有测试框架。更准确的关系是传统框架负责稳定执行高频回归AI Agent 负责那些“脚本写起来太费劲、维护成本太高、但又必须有人/有东西去点一遍”的场景。2.3 开源的意义在哪里如果是一个闭源 SaaS 服务来做 AI 测试你要把被测系统的一些页面数据发送到第三方服务器。对很多企业内部应用来说这一步直接就是合规风险。开源项目最大优势是你可以把整个 Agent 运行在自己的环境里数据不出内网模型也可以选择调用内部 API 或者部署本地模型。定制能力也很关键Agent 的动作集合、提示词模板、断言逻辑都可以自己改。此外开源项目能让你看到底层到底发生了什么。测试 Agent 出问题时你能检查它使用了哪些工具、输出了什么中间决策、为什么选择了某个按钮。这种可观测性对生产环境接入非常重要。3. Argus的项目定位与适用场景3.1 Argus是一个什么样的Agent从项目名称和定位来看Argus 是一个开源的 AI Agent 工具目标是把 AI 智能体应用到 Web 应用测试场景中。它把浏览器自动化能力与语言模型决策能力组合在一起让测试人员可以通过自然语言描述任务由 Agent 自主完成操作和验证。这里需要说明如果你搜索到的仓库已经出现了更具体的功能列表、版本号或配置项请以项目官方 README 为准。本文后续的配置思路基于通用开源 AI Agent 测试工具的实现方式进行演示目的是帮你跑通“任务描述到执行结果”的闭环。通常一个 Web 测试 Agent 至少需要四层能力界面感知层读取 DOM、可访问性树、截图、当前 URL。动作执行层封装浏览器操作如点击、填写、选择、键盘、等待。任务规划层把自然语言目标拆成具体动作序列并在失败后调整。验收报告层记录操作步骤、截图、断言结果输出可读报告。开发者在接入 Argus 时实际是在配置这四层能力。3.2 哪些场景最适合从工程角度看以下几类 Web 应用测试任务最适合先用 AI Agent 跑通冒烟测试新版本发布后只需要确认主流程可用。Agent 比人跑得快比固化的冒烟脚本更抗页面元素变化。探索性测试给定一个业务目标让 Agent 自己尝试多条路径记录过程中遇到的页面异常或阻断。理论上它能覆盖比人工更广的点击路径。复杂业务流程的片段验证比如订单创建、支付回调、权限控制这类跨页面任务用 Agent 描述目标比维护一长串脚本更简洁。页面频繁改版时的回归辅助当 UI 结构频繁变化传统脚本一直修选择器时Agent 的语义理解方式可能减少这类维护工作。3.3 哪些场景不要盲目使用AI Agent 不是银弹。如果你的测试场景要求毫秒级稳定、断言非常精确、每一条路径都要绝对复现那传统自动化框架仍然更合适。Agent 的决策带概率性容易在复杂页面上选择错误元素或者因为多模态模型对截图的误判而执行无效操作。此外Agent 执行速度通常比直接脚本慢每步决策都需要模型推理不适合并发跑几千条用例。合规和权限也很关键。Agent 在测试环境里“自主操作”没问题但如果没有做好权限隔离和账号隔离它可能会访问到不该访问的数据。更稳妥的判断是先让 Agent 在测试环境跑非敏感场景确认识别和决策稳定后再逐步扩大范围。4. 环境准备与安装4.1 运行环境要求安装和配置 Argus 之前先确认基础环境。以下是一般开源 AI Agent 测试工具最常见的依赖操作系统Linux 或 macOS 优先Windows 也可以但浏览器自动化的无头模式在 Linux 服务器上更省资源。Python 版本通常要求 Python 3.9 以上。具体以项目文档为准。Node.js很多浏览器自动化底层依赖 Playwright 或 Puppeteer需要 Node 运行时。浏览器Chromium 或 Chrome。Playwright 通常可以在安装时下载对应浏览器内核。大模型 API可以配置 OpenAI 兼容接口、Anthropic 接口或本地模型服务不同项目支持范围不一样。如果你是在公司内网环境部署还需要确认可以访问模型服务或者已经搭建了内网模型网关。4.2 使用 Python 虚拟环境安装建议把所有依赖安装在独立的虚拟环境里避免污染系统 Python。下面是一个基于通用流程的示例# 创建项目目录 mkdir argus-demo cd argus-demo # 创建虚拟环境 python3 -m venv .venv source .venv/bin/activate # 安装项目包具体包名以项目 README 为准 pip install argus-ai-testing如果你是从源码安装git clone https://github.com/your-org/argus.git cd argus pip install -r requirements.txt这里容易踩的一个坑是Playwright 的浏览器内核不会随 pip install 自动安装。你需要额外执行playwright install chromium在安装过程中如果遇到网络下载失败优先检查是否有内网 npm/pip 镜像以及是否允许访问 Playwright 的 CDN。4.3 配置浏览器与模型服务安装完成后通常需要一个配置文件。这个文件负责告诉 Agent 使用哪个浏览器、哪个模型、模型 API 地址、API Key 放在哪里、超时时间等。一个典型的 YAML 配置长这样# 文件路径argus-demo/argus_config.yaml browser: headless: true viewport: width: 1280 height: 720 timeout: 15000 model: provider: openai model: gpt-4o-mini api_base: https://api.openai.com/v1 api_key_env: OPENAI_API_KEY temperature: 0.2 agent: max_steps: 10 retry_times: 3 save_trace: true screenshot_dir: ./screenshots配置项并不复杂但有几个细节需要留意api_key_env表示从环境变量读取 API Key避免把密钥写进配置文件。headless: false会比较适合第一次调试你可以看清楚 Agent 到底点了哪里。max_steps是单次任务的行动上限防止 Agent 在一个任务里无限循环白烧模型额度。temperature建议调低一点测试场景更需要确定性。设置环境变量export OPENAI_API_KEYyour-key-here如果你用的是本地模型服务只需要把api_base改成内网服务地址。比如使用 vLLM 或者 Ollama 时可以配置成model: provider: openai model: local-model api_base: http://localhost:8000/v1很多本地模型服务会提供 OpenAI 兼容接口所以配置逻辑是一致的。5. 用Argus编写和执行第一个测试任务5.1 任务定义的基本原则第一次使用 AI Agent 测试时不需要一上来就写复杂的多页面流程。建议从一个真实但简单的业务冒烟任务开始。任务描述越具体Agent 的执行成功率越高。比如下面这个任务“打开登录页面使用账号 demo 和密码 123456 登录登录成功后在页面右上角看到用户昵称 demo_user。”这段描述已经包含了起始状态打开登录页操作输入账号密码并登录验收标准右上角显示昵称你还可以补充类似“如果登录失败输出页面上的错误信息”这样的异常分支。好的任务描述通常包括目标、行动边界、验收标准、失败处理方式。5.2 命令行方式假设 Argus 支持命令行工具运行方式通常是argus run --task 打开登录页面... --config argus_config.yaml如果你希望把任务写入文件可以用 Markdown 或 YAML 定义任务# 文件路径tasks/login_test.yaml name: login_smoke_test description: 验证登录主流程 steps: - 打开登录页面 http://localhost:8080/login - 在用户名输入框中输入 demo - 在密码输入框中输入 123456 - 点击登录按钮 - 等待页面跳转 - 验证页面右上角显示 demo_user然后执行argus run --task-file tasks/login_test.yaml --config argus_config.yaml5.3 Python SDK 方式如果项目提供了 Python SDK你可以更灵活地控制 Agent 的执行流程。下面是一个示例脚本# 文件路径run_login_test.py from argus import AgentTestRunner, Task task Task( namelogin_smoke_test, description验证登录主流程, instructions 1. 打开 http://localhost:8080/login 2. 在用户名输入框中输入 demo 3. 在密码输入框中输入 123456 4. 点击登录按钮 5. 等待页面跳转 6. 验证页面右上角显示 demo_user , tags[smoke, login], ) runner AgentTestRunner(config_fileargus_config.yaml) result runner.run(task) print(result.status) # passed / failed / blocked print(result.summary) # 任务总结 print(result.steps) # 每一步操作记录这个示例用Task对象封装了一次测试目标AgentTestRunner负责加载配置并执行完整闭环。result对象里既包含最后的通过状态也包含每一步的决策记录。不同版本的项目 API 可能有差异最核心的调用模式是“创建任务、运行任务、获取结果”。你只需要把自己的任务描述替换进去先跑通最小闭环再研究更多参数。5.4 使用自然语言直接驱动如果你不想写代码很多 AI Agent 测试工具也允许在交互式终端里直接输入argus chat启动后你会进入交互会话输入任务描述后Agent 会逐步执行并把中间状态打印出来。这种方式适合快速验证 Agent 是否理解业务页面也适合探索性测试时随时追加要求。6. 运行与结果验证6.1 预期输出运行第一个任务时建议先用headless: false模式让浏览器窗口显示出来。你会看到 Agent 自动控制浏览器执行以下动作打开登录页定位输入框输入账号定位密码框输入密码点击登录按钮等待页面跳转读取页面内容查找目标昵称如果执行成功命令行会打印类似这样的摘要[argus] 任务完成状态passed [argus] 执行步骤数8 [argus] 截图已保存到./screenshots/step_8.png [argus] 追踪日志已保存到./trace/output_0.json判断成功的标准不只是状态字段是passed还要确认执行步骤的合理性。例如打开的是不是预期地址填写的输入框是不是正确的用户名输入框点击的按钮是不是真正的登录按钮验证方式是不是真的从页面读取到了用户昵称如果状态是passed但 Agent 只是“看到页面出现了 demo_user 字符串”而这个字符串一直出现在页面静态内容里那这个测试其实没有真正验证登录状态。这也是 AI Agent 测试中常见的问题表面通过实际验证无效。6.2 如何提升验证可信度要让 Agent 测试结果可信任务描述里应该尽量写“验证什么状态”而不是“看到什么文字”。比如把“验证页面右上角显示 demo_user”改成“验证页面右上角出现 demo_user 且此时 URL 不再是 /login”。更复杂一点可以在登录前后分别读取当前用户信息再判断变化。如果你使用的 Agent 工具支持自定义断言函数可以用 Python 写一个更确定的验证def assert_login_success(page): url page.url nickname page.locator(.user-nickname).inner_text() assert /login not in url, f仍然停留在登录页: {url} assert nickname demo_user, f用户昵称不匹配: {nickname}把这类函数注入执行流程后即便 Agent 的导航判断失误最终断言也能兜底。这是在 AI Agent 测试里非常值得投入的部分让模型负责“怎么操作”让代码负责“怎么验收”。6.3 从日志和截图排查问题AI Agent 测试和传统脚本测试有个区别传统脚本失败你定位的是选择器或等待条件Agent 失败你需要看的往往是决策链路也就是它为什么选择点击了某个元素为什么在那个步骤停了下来。所以运行后第一件事不是看最终状态而是打开追踪日志。里面通常会记录每一步执行前的页面摘要Agent 决定执行某个动作的原因动作执行后的页面响应如果出现异常模型如何重新规划截图也非常关键。很多页面动态内容一闪而过回看截图才能确认是 Agent 操作错误还是业务系统本身出了 Bug。7. 常见问题与排查思路问题现象可能原因排查方式解决方案启动时报浏览器内核错误Playwright 浏览器未安装或版本不匹配检查playwright install是否执行成功重新执行playwright install chromium或更新 Playwright 版本一直无法定位输入框页面结构复杂模型从 DOM 快照中无法准确识别查看步骤日志看模型找到了哪些候选元素在任务描述中补充页面特征或给元素添加>button>