企业官网建设流程全解析

前一阵子我们团队做了一次 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 一个目标，让它自己决定路径。它会基于大语言模型的理解能力，把一句话任务拆解成具体的执行步骤，然后调用底层的浏览器操作工具、接口请求工具、断言工具去落地。更关键的一点是，它具备"反思"和"自适应"能力。比如某个用例第一步点击按钮失败了，它不是直接报红，而是会先分析失败原因——是元素没加载出来、还是页面跳转了、还是权限不够——然后选择重试、换一种定位策略或者跳过并在报告中标注原因。

我用一个表格来对比两者的差异，这样更直观：

1.2 Agent 是如何完成"计划-执行-验证"闭环的

在跑那 72 项测试之前，我先做了个小实验：让 Agent 去完成"登录系统并创建一个新的采购订单"这个任务。观察它的思考链路大致是这样的：

1. 解析任务目标，识别关键动作：登录、进入采购模块、新增订单、填写必填字段、保存、验证。
2. 检查当前页面状态，确定前置条件是否满足（是否已登录、菜单结构什么样）。
3. 逐步执行并持续收集页面反馈，每一步执行后都会对比预期结果。
4. 遇到异常时暂停，结合错误信息修正下一步动作。
5. 任务完成后整理执行日志，生成结论。

我当时就觉得这个思路很对路。传统的自动化测试让测试人员花大量时间在"把业务步骤翻译成代码"上，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 理解成了"进入采购申请页面"。修改方式很直接：在所有用例描述中把名词写完整，比如"新增采购订单（PO，Purchase 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 把执行层面的杂活接了过去，让我能把时间真正分配到设计更高质量的测试场景上。如果你也正在被大量重复性回归测试消耗精力，我的建议是找一个规模适中的模块先试起来，跑通一个完整闭环后，再逐步扩大范围。这套玩法，值得每个测试团队认真试一次。