前一阵子我们团队做了一次 ERP 系统的大版本回归用例量不算夸张——72 项核心业务流程覆盖从登录鉴权到工单审批再到库存盘点。放在以前这种量级的回归我至少要腾出两个整天自己手动点界面、记结果、截日志、截图最后还要对着 Excel 模板一张张填报告填到晚上十点脑子基本是糊的。这次我换了个思路——把整套活儿交给 Hermes Agent 去跑。我用一句话描述了任务目标Agent 自己完成了用例拆解、脚本执行、结果校验、日志采集和报告生成72 项测试全部跑完10 份可交付的测试报告自动产出整个耗时从人工的两天压缩到 40 分钟左右。这篇文章就围绕这套实战过程展开把我踩过的坑、想明白的原理、以及最终沉淀下来的可复用方法都写清楚。无论你是刚接触 AI 自动化测试还是已经在用传统框架想引入 Agent 能力这篇应该都能给你一些参考。1. Hermes Agent 不是又一个录制脚本工具而是拆解任务的执行大脑最开始我听到 Hermes Agent 这个名字第一反应是这又是一款类似 Selenium 或者 Playwright 的自动化测试框架。实际用下来发现完全不是一回事。传统自动化测试框架解决的是脚本怎么跑Hermes Agent 解决的是任务怎么拆、决策怎么做、异常怎么处理。1.1 它和传统自动化测试框架的本质区别传统框架的工作方式是测试人员把所有步骤写成确定性脚本框架按脚本一行一行执行遇到断言失败就报错终止。这套模式的问题在于一旦被测系统的页面结构、业务流程、数据环境发生变化脚本就得跟着改维护成本非常高。Hermes Agent 的工作方式则像是给 Agent 一个目标让它自己决定路径。它会基于大语言模型的理解能力把一句话任务拆解成具体的执行步骤然后调用底层的浏览器操作工具、接口请求工具、断言工具去落地。更关键的一点是它具备反思和自适应能力。比如某个用例第一步点击按钮失败了它不是直接报红而是会先分析失败原因——是元素没加载出来、还是页面跳转了、还是权限不够——然后选择重试、换一种定位策略或者跳过并在报告中标注原因。我用一个表格来对比两者的差异这样更直观维度传统自动化框架Hermes Agent任务来源人工编写脚本代码自然语言描述目标执行逻辑固定步骤顺序执行动态拆解与决策异常处理遇错即停或简单重试分析失败原因后自适应调整用例维护页面变动需改代码描述任务时可容忍一定变化报告生成需要另外开发报告模块自动汇总执行过程并生成结构化报告适用场景稳定系统的批量回归复杂业务链路、快速迭代、跨模块回归1.2 Agent 是如何完成计划-执行-验证闭环的在跑那 72 项测试之前我先做了个小实验让 Agent 去完成登录系统并创建一个新的采购订单这个任务。观察它的思考链路大致是这样的解析任务目标识别关键动作登录、进入采购模块、新增订单、填写必填字段、保存、验证。检查当前页面状态确定前置条件是否满足是否已登录、菜单结构什么样。逐步执行并持续收集页面反馈每一步执行后都会对比预期结果。遇到异常时暂停结合错误信息修正下一步动作。任务完成后整理执行日志生成结论。我当时就觉得这个思路很对路。传统的自动化测试让测试人员花大量时间在把业务步骤翻译成代码上Agent 则是让测试人员把精力放在把测试意图表达清楚上——后者明显更接近测试的本质。当然Agent 也不是万能的它依赖底层模型的理解能力和工具的稳定性。所以后续的所有经验都建立在一个前提上先把 Hermes Agent 的部署和运行环境调稳再谈大规模用例的自动化执行。2. 本地部署一台 16G 内存的机器足够跑完全部任务Hermes Agent 部署本身不复杂但从我自己的经历以及周边朋友的反馈来看大部分人栽在环境依赖和配置细节上。如果你打算在 Windows 上部署或是用一台配置不太高的笔记本跑下面这些实测经验可以直接抄。2.1 部署方式和环境准备Hermes Agent 官方提供了两种主流部署路径一种是 Docker 容器化部署一种是 Python 源码方式运行。我最终选择的是 Python 虚拟环境方式原因是调试方便能看到完整日志而且后续要接入自定义测试脚本也更灵活。硬件方面我用的是一台 i5 处理器、16G 内存的 Windows 笔记本。实际跑 72 项测试的过程中CPU 占用率控制在 60% 左右内存占用约 6G没有出现卡死或 OOM 的情况。如果你的机器只有 8G 内存建议把浏览器并发数限制在 3 个以内。部署步骤大致如下# 1. 克隆仓库并创建虚拟环境 git clone https://github.com/hermes-agent/hermes-agent.git cd hermes-agent python -m venv venv source venv/bin/activate # Windows 下用 venv\Scripts\activate # 2. 安装依赖 pip install -r requirements.txt # 3. 配置环境变量 cp .env.example .env # 编辑 .env配置模型 API Key 等相关参数依赖安装过程中有几个特别注意的点。Python 版本必须大于等于 3.10否则部分异步库会报错。浏览器驱动方面Agent 底层通常通过 Playwright 来操作浏览器所以playwright install chromium这一步不能省。Windows 下安装完成后需要确保把 Chromium 的路径写进配置否则 Agent 会找不到浏览器实例。2.2 模型接入配置Agent 的推理能力来自大语言模型这里需要配置模型服务的接入信息。我在实际使用中同时测过云端 API 和本地模型两种方式。云端 API 的响应速度更快推理质量也更稳定处理复杂任务时的准确率明显更高但会有 token 消耗费用。本地模型完全离线数据隐私最好但对显存要求高而且推理速度慢处理 72 项这样的任务量会明显拉长总时长。我的建议是如果你的测试环境允许访问公网 API优先用云端服务跑日常回归费用其实可控后面我会单独聊成本估算。如果你的测试数据极度敏感再考虑本地模型方案。模型选择上通用对话能力强的模型在任务拆解和异常推理中表现更好。配置文件中主要就几个关键参数llm: provider: openai # 或 local model: gpt-4o-mini temperature: 0.2 # 测试场景下建议用低 temperature max_tokens: 4096这里有个细节值得强调执行测试类任务时temperature 尽量不要高于 0.3。temperature 值越高模型输出的随机性越强在测试断言场景下会导致同一用例多次执行结果不一致这是自动化测试的大忌。2.3 验证安装先跑一个小任务部署完成后我强烈建议你先跑一个最简任务验证链路而不是直接把 72 项用例灌进去。比如让 Agent 打开一个公开网页截个图保存下来。只要这个小任务能顺利跑通说明浏览器控制、模型调用、文件输出这条链路没问题。验证脚本方式# 交互式模式直接输入指令 hermes-agent --interactive # 然后输入 打开 https://example.com 并截图保存到 ./screenshots/demo.png大约十几秒后如果截图文件正常生成部署就算成功了。从这里开始才能进入正式的项目任务编排阶段。3. 用一句话驱动 72 项测试任务描述和用例映射才是关键标题里说一句话搞定系统测试很多人觉得这就是对着 Agent 喊一嗓子给我跑完全部测试就完事。真实情况不是这样的。这一句话背后需要你先把任务边界、用例映射、执行策略都设计好Agent 才能在收到指令后自主工作。3.1 先把 72 项测试的组织方式设计好我负责的那套 ERP 系统业务模块分成 9 个功能域登录与权限、组织架构、物料管理、采购管理、库存管理、生产工单、财务凭证、系统配置、报表查询。每个功能域下又细分了若干个业务用例72 项就是这么来的。为了让 Agent 能够有条不紊地执行我把每一类用例都整理成了结构化的描述文件格式类似于用例 ID: TC-PO-003 所属模块: 采购管理 前置条件: 用户已登录且具备采购员角色 操作步骤: 1. 进入采购订单列表页面 2. 点击新增按钮 3. 选择供应商 4. 添加至少一种物料并填写数量、单价 5. 保存并提交审批 预期结果: 订单状态变为待审批列表中能看到新订单记录72 个用例全部按这个格式整理完毕后我并没有把它们一股脑丢给 Agent而是按照模块维度拆成 9 个子任务组。这样做的原因有两个一是 Agent 在执行过程中的上下文窗口有限任务范围越小指令跟随的准确率越高二是按模块分组后即使某一组任务失败不会影响其他模块的测试执行避免一挂全挂的连锁反应。3.2 任务指令怎么写Agent 才能准确执行指令质量直接决定了执行质量。我在实际写指令时遵循了以下几个原则明确任务范围避免歧义。我用的主指令是执行采购管理模块的全部 8 条测试用例用例定义文件路径是 ./testcases/purchase.md执行完成后输出测试报告。明确输出要求。例如报告需要包含每条用例的执行状态、失败原因、截图路径、操作日志。明确异常策略。我加了遇到环境类异常时自动重试最多 2 次重试后仍失败则标记为 Blocked 并继续执行下一条用例。批量任务采用分组指令下发方式。我通过配置文件定义了 9 组任务Agent 会自动按顺序拉取并执行。下面是一段我实际使用的任务配置文件示例tasks: - name: 登录与权限模块测试 testcase_file: ./testcases/auth.md output_report: ./reports/auth_report.md - name: 采购管理模块测试 testcase_file: ./testcases/purchase.md output_report: ./reports/purchase_report.md - name: 库存管理模块测试 testcase_file: ./testcases/inventory.md output_report: ./reports/inventory_report.md配置完成后启动指令只需要一行hermes-agent --task-file ./test_plan.yaml就是这一句话启动了整轮 72 项测试的自动执行。Agent 拿到任务清单后会先读取每个模块的用例定义文件理解测试目标然后逐个执行并记录结果。3.3 测试数据的准备与隔离这是自动化测试里最容易被忽略但又最要命的一环。如果多个用例共用同一份测试数据前一个用例改掉的数据状态可能直接导致后一个用例失败。我在跑采购流程测试时就遇到过这类问题TC-PO-003 创建了一个采购订单并提交审批结果 TC-PO-004 去查询待审批订单列表时恰好又查到 TC-PO-003 创建的订单导致预期结果与实际数量对不上。解决方案是在任务指令中明确要求 Agent 在每个用例执行前检查并准备独立的数据快照。比如要求 Agent在执行前通过系统接口重置当前模块的测试数据确保每条用例使用独立的单据编号。Agent 会调用系统后端的测试数据管理 API 来完成数据准备。通过这种前置检查数据互相污染的问题基本被消除了。4. 10 份报告自动产出从原始日志到可交付文档的组装流水线如果说自动跑测试已经不算新鲜事那么自动生成 10 份报告才是这次实战里真正让人省心的部分。人工方式下跑完测试只是完成了一半工作整理报告通常还要花费一晚上。Agent 能在执行过程中顺手完成证据采集和报告生成彻底把我从报告堆里解放了出来。4.1 Agent 在执行过程中自动采集了哪些证据报告不是凭空生成的。Agent 在每执行一个操作步骤时都会同步记录三类数据操作日志包括每一步操作的描述、时间戳、操作前后页面 URL、操作结果。截图证据在关键步骤如提交、保存、跳转自动截图失败步骤还会额外多截一张现场图。接口响应数据对于后端调用Agent 会捕获 HTTP 状态码、响应体关键字段、耗时等指标。这些原始证据统一存放在指定的工作目录下按用例 ID 分类归档。这样每一条用例都拥有一个完整的黑匣子无论后续要追溯问题还是做缺陷复现都能找到原始依据。4.2 10 份报告是怎么拆出来的我配置的报告体系是9 份模块报告 1 份总体汇总报告的结构。9 份模块报告分别对应 9 个功能域每份报告包含模块内所有用例的执行状态统计、失败用例的详细分析、关键截图和日志链接。第 10 份报告是整个测试轮次的总报告内容涵盖测试范围与执行环境各模块通过率、失败率、阻塞率缺陷列表及严重程度分布遗留风险提示测试结论与上线建议生成报告时我还在指令里要求 Agent 使用统一的模板模板我一开始就定义好了里面包含了公司测试交付物所要求的标题层级和字段。这样产出的报告不只给自己看也完全可以直接同步给业务方或管理层不需要额外转换格式。4.3 报告质量的验证与兜底自动化生成的报告存在一个天然风险就是看着很完整实则数据有误。我在正式交付报告前额外加了一道校验步骤让 Agent 对汇总报告中的关键数字进行交叉核对确保报告里写的通过用例数 实际执行的通过用例数每个失败用例都能对应到具体的失败日志。有一次 72 项用例实际通过了 68 项但汇总报告里却写成了 69 项。排查后发现是个别用例在重复执行时被计数了两次。加了这道交叉校验逻辑后报告数据的可靠性基本达到了可直接交付的水准。这一步特别重要宁可多花 1 分钟校验也不要交出一份让业务方追溯时发现对不上的报告。5. 实测中的四个意外和对应的处理思路任何自动化测试方案理论上说得再漂亮跑起来总会有意外。Hermes Agent 也一样。下面几个坑是我在真实执行过程中遇到过的写出来供大家参考。5.1 Agent 对业务术语的理解偏差第一轮跑采购模块用例时Agent 把采购申请单和采购订单这两个概念搞混了。它打开了采购申请列表页面去执行新增采购订单的操作结果自然是找不到对应按钮用例执行失败。我看了日志Agent 在反思环节已经发现操作结果与预期不符但它的第一次修正路径又走回了采购申请页面等于连续错了两步。这个问题的根因在于用例描述文件里的术语不够绝对明确。我当时的用例里写的是进入采购模块新增一笔订单Agent 理解成了进入采购申请页面。修改方式很直接在所有用例描述中把名词写完整比如新增采购订单POPurchase Order并明确标注具体菜单位置。调整后这类歧义基本没有再出现。这个案例说明了一个重要的经验Agent 的理解能力再强也需要测试人员在用例定义阶段尽可能消除歧义。把 Agent 当成一个很聪明但缺乏业务背景的新人你就会知道哪些上下文需要提前交代清楚。5.2 用例之间的数据依赖导致状态串扰这就是前面提到过的数据隔离问题我在这里再展开讲讲完整的排查链路。第二轮测试中TC-INV-005库存盘点差异审核失败率高得异常Agent 标记的失败原因是预期库存盘点差异状态为已审核但实际状态为待审核。通过排查日志链路发现TC-INV-004库存盘点创建与提交在上一轮执行时生成的盘点单没有被清理当 TC-INV-005 执行时系统默认加载了最新一张盘点单而那张单据的状态还是审核中自然和预期不匹配。解决思路分了两步走第一步在用例前置条件里增加清理历史盘点单数据的指令第二步在 Agent 执行完 TC-INV-004 后立即通过接口归档该单据避免影响后续用例。这个问题解决之后库存模块的用例通过率从 75% 提升到了 100%。5.3 非确定性 UI 元素导致偶发失败ERP 系统里有些页面元素带有动态 ID比如每次刷新都会变化的按钮 ID 或输入框 ID。Agent 首次运行时通过语义定位抓到了元素但第二次跑时动态 ID 变了它按照记忆中的 ID 去找就找不到用例偶发失败。这个问题在传统自动化框架里也很常见通常的解法是使用更稳定的定位策略比如 XPath 结合文本内容定位。Agent 的优势在于它能在失败后自动切换定位策略从依赖 ID 转为依赖按钮文本或相对位置。我在指令里加了一条优先使用语义化定位方式如果动态元素导致定位失败尝试使用文本定位或 XPath 兜底。这之后动态 ID 引发的偶发失败率明显下降。5.4 外部依赖不稳定引起的超时误报我们的 ERP 系统依赖一个第三方短信网关发送审批通知。有几条用例涉及审批流转会触发短信发送但第三方网关偶尔响应缓慢Agent 认为系统卡死直接判定失败。其实被测系统本身是正常的只是外部依赖超时。我把超时阈值从 5 秒调整到了 15 秒并在用例设计中增加了一个环节遇到第三方服务超时先检查被测系统后端日志如果业务数据已经正常写入数据库则判定为通过并记录外部依赖延迟。这个思路本质上就是 Agent 在智能判断方面比传统框架强的地方——它能结合多方证据来综合判断用例是否真正失败而不是仅盯着一处超时信息就下结论。6. 用了一个月之后我给后来者的几点实在建议从第一次跑通 72 项测试到现在这套 Hermes Agent 测试方案已经在我们的日常回归中稳定运行了一个多月。这期间迭代了若干版本也沉淀出了一些基于个人经验的判断。如果你正准备做类似的事情这几条建议可以直接拿去参考。6.1 先挑一个模块做试点别急着全套上线我第一周只做了采购管理这一个模块的 8 条用例。目的是把指令写法、用例描述格式、报告模板、异常策略都验证一遍。等这一条链路跑顺了再横向扩展到其他模块。一上来就想直接跑完全部 72 项如果指令设计不合理排查问题会很耗时。6.2 任务描述要给足上下文但别把动作写死这是 Agent 和传统脚本的一个重要区别。给足上下文的意思是模块范围、业务名词、预期结果要明确。别把动作写死的意思是不要告诉 Agent点击左上角第三个按钮这种没有语义且容易失效的指令而是说在采购订单列表页面点击新增按钮。这样 Agent 才能发挥它自适应定位的优势在页面细节发生微小变化时仍然完成任务。6.3 关注成本但别因为成本放弃这个方案token 消耗是很多人关心的问题。按照我目前的用量跑完整轮 72 项测试调用云端模型的 token 花费折合约几块钱人民币。相比耗费人工两天时间这个成本在效率和投入产出比上优势明显。如果你希望进一步压缩成本可以把用例描述文件做得更精简、减少 Agent 在步骤间的冗余思考或者改用轻量模型处理那些逻辑简单的操作型用例。6.4 长期运行要建立反馈循环Agent 方案不是一次配置永久生效。系统在迭代用例描述需要跟着更新Agent 的失败模式也需要定期复盘。我现在每个迭代周期都会做一次复盘把上次执行中的失败用例和失败原因拉出来逐条更新用例描述和任务策略。持续优化一段时间后整轮的通过率已经稳定在 95% 以上。我个人在整套方案落地中最大的感受是测试自动化的瓶颈已经不在能不能自动执行而在怎么把业务知识清晰地传递给 Agent。Hermes Agent 把执行层面的杂活接了过去让我能把时间真正分配到设计更高质量的测试场景上。如果你也正在被大量重复性回归测试消耗精力我的建议是找一个规模适中的模块先试起来跑通一个完整闭环后再逐步扩大范围。这套玩法值得每个测试团队认真试一次。