用Hermes Agent一句话驱动72项系统测试：AI智能体自动化测试实战

1. 为什么选 Hermes Agent 来做系统测试

1.1 传统测试与自动化测试的割裂，问题出在哪

做系统测试最痛苦的事，不是用例不够多，而是“业务用例”和“自动化脚本”永远是两套东西。业务同学在 Excel 里维护 72 条测试用例，开发和测试开发同学在 pytest、Selenium、Appium 里维护另一套自动化代码，两边经常对不上。每次版本一升级，页面加了个字段、接口改了个参数、数据库表结构动了，自动化脚本就得跟着改一遍。遇到紧急回归，人肉点界面一天都点不完，脚本又不敢直接跑，因为连测试开发自己都不确定脚本跟当前版本还对不对得上。

这种“传统测试与自动化测试融合”没做好的团队，自动化覆盖率再高，也只是多了一套要维护的代码，并没有真正缩短交付时间。我这次给自己定的目标很直接：让业务人员用一句自然语言触发回归测试，让机器自己把用例拆出来、跑完、出报告，而不是让测试开发手工去编排脚本。最终的效果也确实做到了，我用 Hermes Agent 加一个本地大模型接口，只发了一句话，就跑完了 72 项系统测试，自动生成了 10 份报告。整个过程没有写新的测试用例，所有执行逻辑都来自已有工具链的调度。

1.2 Hermes Agent 到底是个什么东西

简单说，Hermes Agent 是一个开源智能体框架，核心能力是“把自然语言指令拆成可执行步骤，再调用已经注册好的工具完成每一步”。它本身不替你做测试，它做的是调度和决策。你可以把 pytest、requests、MySQL 连接器、报告生成器都注册成它的工具，剩下的事情就交给模型：把用户的一句话变成行动计划，然后按计划调用工具、读取结果、决定下一步怎么做。

网上有人把这套东西叫作“万神殿”模式，我觉得挺形象。什么意思呢？就是不同职责的小工具，像不同神位一样挂在一个总控下面，各有各的职能，模型是那个负责发号施令的调度员。你可以在同一个 Hermes Agent 底下挂接口测试工具、UI 测试工具、数据校验工具、报告工具，它们之间互相隔离，但又被同一个大脑统一指挥。这个架构对我这种需要频繁跑回归测试的场景特别合适，因为工具可以复用，业务流程变了只改 Prompt 和用例清单，不用重写框架。

1.3 为什么不直接用 pytest，也不直接上全套测试平台

有人会问，既然已经有 pytest 和各类自动化框架，为什么还要引入一个 agent 层？我当时也犹豫过。直接写 pytest 脚本当然能做自动化，但问题是它解决不了“业务语言到代码语言”的翻译成本。业务同学说“采购模块入库单创建要回归一下”，测试开发得先理解这句话，再去翻用例库，再把相关脚本挑出来跑，最后再汇总报告。这个链条里，真正花时间的不是执行，而是“翻译”和“调度”。

全套测试平台也能解决一部分问题，比如用例管理、执行计划、报告展示，但搭平台本身是一项不小的工程，还要做权限、数据隔离、定时任务，对一个小团队来说太重了。Hermes Agent 这种方案的好处是轻，本地就能跑，工具自己注册，报告模板自己写，语义调度交给模型。它不是替代 pytest 和 Selenium，而是在这些工具上面加了一层“会自然语言的遥控器”。

选型时我的判断是：不是 pytest 不行，而是缺一个能把“人话”转成“工具调用”的调度层。Hermes Agent 正好补在这一点上，而且它不绑定语言，哪怕团队后面要接 Java 接口测试框架，也只多注册一个命令行工具的事。

2. 落地准备：本地部署 Hermes Agent 和环境接入

2.1 Windows 本地部署 Hermes Agent 安装教程

我这次是在 Windows 上做的本地部署，踩了一圈坑之后，整理出一套可以直接照抄的流程。

第一步，装 Python 3.11 以上版本。这一步的关键是在安装时勾选“Add Python to PATH”，否则后面在 PowerShell 里敲python命令根本找不到。装完可以用python --version验证一下，能输出版本号就说明环境没问题。

第二步，用 Git 把 Hermes Agent 的官方仓库拉到本地。官方仓库在项目主页能找到，直接git clone就行。如果没有装 Git，也可以在项目主页下载 ZIP 包解压。我建议用 Git，因为后面更新版本方便，拉代码时还能顺便看到更新日志。另外官方提供了便携版，解压就能跑，适合不想折腾环境的同学，但我个人还是推荐走标准安装，因为工具注册和配置目录都更清晰。

第三步，安装依赖。在项目根目录执行pip install -r requirements.txt。如果网络条件不好，可以把 pip 源切到国内镜像源，比如pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple，装依赖的速度会快很多。这一步如果报错，多半是 Python 版本不对，或者缺了某个编译工具，具体排查方法我放在后面常见问题章节里。

第四步，初始化配置目录。执行hermes init，它会自动创建一个配置文件目录，里面包含主配置文件和工具注册目录。这一步很重要，不要跳过去，因为后面接入大模型和注册工具都在这个目录里做。

第五步，启动交互模式。执行hermes run --interactive，看到提示符说明已经起来了。第一次启动会慢一点，因为要加载模型配置和工具列表。整个时长大概在几分钟到十几分钟之间，取决于机器配置。

2.2 把本地大模型接进来

Hermes Agent 本身没有内置模型，它需要一个“会推理的大脑”来解析指令和做决策。我用的是 Ollama 拉了一个支持工具调用的开源模型，然后让 Hermes Agent 通过 OpenAI 兼容接口访问它。

具体做法分两步。第一步，在 Ollama 中把模型拉下来，比如ollama pull qwen2.5:14b。第二步，在 Hermes Agent 的配置文件里填接口地址和模型名，大概是这样：

model: provider: openai_compatible base_url: http://localhost:11434/v1 api_key: local model_name: qwen2.5:14b

如果你没有 GPU，用 7B 参数的模型也能跑，但任务拆解能力会差一些，复杂流程容易漏步骤。我实测下来，做系统测试这种场景，模型参数太小容易出现“规划完不执行”或者“执行到一半忘记目标”的问题，所以建议至少 14B 起步。模型接口连不上时，先用curl http://localhost:11434/v1/models验证一下 Ollama 服务是否正常，这是最快的排查方法。

2.3 被测系统信息准备

这一步很多人会忽略，但它恰恰是整个方案能不能跑通的前提。你要被测的 ERP 测试环境信息准备成结构化配置，而不是随手写在 Prompt 里。我把接口地址、测试账号、数据库连接信息、测试数据构造规则全部放到了.env文件里，Hermes Agent 的工具函数会从这个文件读取环境变量。

举个例子，接口测试工具需要知道采购模块的登录地址，UI 测试工具需要知道测试账号和密码，数据校验工具需要知道测试库的连接串。这些信息如果散落在 Prompt 里，模型可能会记混，甚至会把它当成回答内容输出。放到.env文件里集中管理之后，工具函数自己在代码里取，模型不需要关心具体的值，只负责决定“什么时候调用哪个工具”。这一步做完，agent 才算真正“接上了地气”。

3. 一句话驱动 72 项测试的核心链路

3.1 一句话到底该怎么给

很多人的第一反应是：既然 AI 都能理解了，那就随便说呗。实际不是这样。我这次用的 Prompt 是经过设计的，并不是随口一句话。我当时给 Hermes Agent 的指令是：

“对 ERP 系统的采购模块做回归测试，覆盖入库单创建、审批流、库存扣减、采购报表四个子模块，接口和页面都要跑。执行失败时自动重试一次并截图，全部结束后生成 HTML 测试报告、失败原因分析、风险清单、接口耗时统计等 10 份报告。”

这句话有效，是因为它包含四个关键要素：范围、方式、失败策略、交付物。范围限定了采购模块四个子模块，方式限定了接口和页面都要跑，失败策略要求重试并截图，交付物明确是 10 份报告。模型拿到这样一句话，才知道怎么拆步骤。如果只说“帮我测一下采购模块”，模型会一头雾水，最后跑出来的东西大概率不是你要的。

3.2 Agent 的任务拆解机制

Hermes Agent 在拿到指令后，会先走一个 plan-then-execute 的流程。它不会拿过指令就直接执行，而是先生成一份执行计划，然后按计划逐步调用工具。我这次实际生成的计划大概是这样的：

1. 读取采购模块测试数据和历史用例清单
2. 准备测试账号和环境检查
3. 执行接口测试用例并收集结果
4. 执行页面测试用例并收集截图
5. 执行数据库数据校验
6. 汇总所有结果并生成 10 份报告

每一步执行完，结果都会回填给模型，模型根据结果判断有没有偏差，有偏差就调整下一步。比如接口用例发现登录态失效，它会在下一步先调用重新登录的工具，再去跑后面的页面用例。这种“边执行边修正”的能力，是传统脚本很难做到的地方。

3.3 从自然语言到可执行用例的转换

这里要澄清一个误区：Hermes Agent 并不会凭空生成测试用例。我这次跑通的 72 项测试，底层是一个 JSON 用例清单，包含用例编号、模块、优先级、请求参数、预期结果。Agent 做的事情是“翻译和调度”，它从用例清单里挑出与采购模块回归相关的用例，再按优先级排列，调用对应的工具去执行。

这个设计是有意为之的。让 AI 从头生成接口用例，风险很大，因为模型对被测系统的业务规则理解有限，生成的用例很可能跑完也不代表系统真的没问题。正确的做法是：核心回归用例必须有基线，AI 负责的是把基线用例快速、自动地跑完，再把结果整理成人能看懂的报告。AI 生成的补充用例可以作为探索性测试的输入，但不能替代基线用例。

3.4 执行环节：接口、UI、数据校验的协同

72 项测试的分布是：接口用例 41 项、页面用例 26 项、数据校验用例 5 项。这个分布不是随便来的，而是根据采购模块的风险点定的，接口能覆盖的尽量用接口覆盖，页面只覆盖关键流程，数据校验放在最后，用来核对前后端操作是否真的写对了库。

执行顺序上，Agent 会按依赖关系排序：先跑接口用例，再跑页面用例，最后跑数据校验。为什么？因为页面用例很多时候依赖接口造数，如果先跑页面，可能面临测试数据不足的问题。数据校验放最后，是因为它要等接口和页面都操作完，数据库里才会有最终结果。这个依赖排序，如果靠人肉来排会很费劲，但交给 Agent 后，它只需要看工具描述里标注的依赖关系，就能自动排出合理顺序。

3.5 10 份报告是怎么生成的

报告不是一个大而全的文件，而是拆成了 10 个不同维度的独立文件。我这次产出的 10 份报告分别是：测试执行摘要、用例明细、失败截图集、风险清单、接口耗时统计、UI 断言统计、数据库校验结果、缺陷疑似原因、回归对比报告、原始日志归档。

这个拆分的思路是让不同角色各取所需。项目负责人看摘要和风险清单，测试开发看失败截图和日志，开发看疑似缺陷原因和回归对比。报告生成本身也是一个注册给 Agent 的工具，底层用 Jinja2 模板把执行结果渲染成 HTML，再用 weasyprint 导出 PDF。Agent 只需在最后调用这个工具，把结果文件路径传进去，报告就出来了。关键是模板固定、字段固定、路径固定，这样模型不需要理解报表逻辑，只需要知道“什么时候调用”就够了。

4. 实操细节：配置、参数与核心代码示例

4.1 把“测试执行器”注册成工具

Hermes Agent 的工具注册方式很直接，本质上就是写一个 Python 函数，再用装饰器把它暴露给模型。我这边最核心的工具是run_pytest，负责执行指定模块的 pytest 用例。代码大概是这样的：

from hermes_agent import tool @tool def run_pytest(module: str, mark: str = "regression") -> dict: """ 运行指定模块的 pytest 用例。 module: 被测模块的目录名，只能是 purchase、sales、inventory 之一。 mark: 用例标记，可选 smoke、regression、full，默认 regression。 返回执行结果，包含退出码、通过数、失败数和报告文件路径。 """ import subprocess cmd = ["pytest", f"tests/{module}", "-m", mark, "--json-report"] result = subprocess.run(cmd, capture_output=True, text=True) return { "exit_code": result.returncode, "stdout": result.stdout[-2000:], "report_path": "reports/latest_result.json" }

这里有个很重要的经验：工具描述一定要写清楚参数格式和约束条件。刚开始我没写“module 只能是 purchase、sales、inventory 之一”，结果模型会传中文名称，甚至传一个带空格的文件路径，导致命令执行失败。把约束条件写进 description，模型就不会乱来，因为它是靠描述来理解工具用法的。

4.2 Prompt 和工具描述怎么写才高效

我给 Hermes Agent 的 Prompt 里加了一句话：“先输出执行计划，确认后再执行。”这句话非常关键，它能防止模型拿到指令后直接乱跑。有了这个约束，它在执行前会先把计划列出来，我确认没问题后再放行。对于测试这种操作型任务，多一道确认，能省掉后面很多返工。

工具描述本身也有讲究。不要只写“这个工具能做什么”，一定要写“什么情况下不能用”和“参数格式要求”。比如报告生成工具，我特意在描述里加了：“如果结果文件不存在，先用 run_pytest 生成结果，再调用本工具。”这样模型就不会在没有任何结果数据时强行生成一份空报告。

4.3 并发、超时和重试参数怎么选

测试执行天然有个矛盾：跑得太慢浪费时间，并发太高又会互相污染数据。我这次接口用例并发设 4，页面用例并发设 1。为什么页面用例不敢并发？因为多个页面同时操作同一个测试账号，很容易出现登录态互相踢掉的情况，一踢掉满屏都是失败，根本分不清是系统问题还是环境问题。

超时时间我分了两档：接口 10 秒，页面 20 秒。这个值是观察了几轮执行结果后调出来的，太短容易误杀慢接口，太长浪费整体时间。重试策略是失败重试 1 次，只在接口层做，页面层不重试，因为页面失败通常有截图，重试反而可能掩盖真实问题。这三个参数我放在配置文件里，没有写进 Prompt。原因很简单，参数是环境相关的，换了环境改配置就行，不用改 Prompt。如果写进 Prompt，一旦要调参，还要等待模型重新解析，不可控。

4.4 执行现场记录与结果核对

第一次完整跑的时候，72 项测试挂了 9 项。我让 Agent 自动重试后，还剩 2 项失败，它把截图和日志归档到了报告里。人工定位后发现，6 项失败是因为测试数据被上一次运行污染了，3 项失败是页面元素等待时间不够，2 项失败是真实的接口返回异常。整个过程耗时 40 分钟左右，放到以前人工点界面，同样的 72 项测试至少需要一天。

这里有个特别想提醒的经验：Agent 的日志级别一定要设置成 DEBUG，否则你根本不知道它中间经历了什么。第一次跑时我用的是 INFO，结果报告出来 9 项失败，我完全不知道是模型调错工具了，还是工具本身出错，还是测试数据有问题。后来改成 DEBUG，每一步工具调用的入参和返回值都写得清清楚楚，定位问题快了很多。

5. 常见问题与排查技巧实录

5.1 部署阶段最常见的三个坑

部署 Hermes Agent 时，大多数人会在三个地方卡住。

第一个是 Python 版本不对。有些依赖包在新版本 Python 上编译不过，有些在旧版本上不支持。我的建议是直接用 3.11，这个版本兼容性最好，踩坑最少。

第二个是 Windows 下某些依赖装不上，比如 lxml。解决办法是切镜像源，或者直接装预编译的 wheel 包。不要硬编译，浪费时间。

第三个是模型接口连不上。Hermes Agent 启动正常，但一问它就报连接错误。这时候先检查 Ollama 服务有没有启动，再检查base_url配的是不是http://localhost:11434/v1，端口不要写错。

5.2 Agent 任务拆解得不对怎么办

如果你发现 Agent 拿到一句话后拆出来的步骤完全不是你要的，不要急着换模型，先检查两件事。

第一，Prompt 里有没有限定步骤范围。比如“只做采购模块”“不要执行删除操作”，这类显式约束能大幅减少模型自由发挥的空间。第二，工具描述够不够具体。模型拆错步骤，很多时候是因为工具描述太模糊，它不知道该在什么场景下调哪个工具。

如果这两点都排除了还是拆不对，那才需要考虑换更大的模型。我在 7B 模型上遇到过它把“生成报告”理解成“打印报告到控制台”，换了 14B 之后就没这个问题了。这说明当前模型的能力确实有瓶颈，不是配置问题。

5.3 测试结果“时好时坏”怎么排查

很多人一看到测试结果不稳定，第一反应就是 Agent 有问题，其实绝大多数情况跟 Agent 没关系。我的排查顺序是：先看测试数据是否独立，再看执行日志里失败点的前后操作，最后才看模型指令有没有问题。

测试数据污染是最常见的原因。比如上一次运行创建了一个单据，下一次运行又用同一个单据号去创建，自然就冲突了。解决办法是每次执行前让 Agent 先调用一个“清理测试数据”的工具，保证每次都是干净环境。并发冲突也会造成结果不稳定，两个用例同时操作同一个数据，互相覆盖。等待时间不足更常见，页面元素还没加载出来，用例就断言失败了。这三类问题，通过看 DEBUG 日志基本都能定位。

5.4 报告生成后没有数据

报告生成工具调用成功，但打开 HTML 报告是空的，这个问题我遇到过两次。原因基本出在两个地方：一是执行结果 JSON 太大，被模型上下文截断了，二是报告模板字段跟实际数据对不上。

我的解决办法是：让报告工具直接从结果文件读数据，不依赖模型转述。也就是模型只需要传给工具一个report_path，工具自己去读 JSON 文件，再把对应字段填进模板。这样哪怕模型上下文不够，也不影响报告内容。模板字段对不上的问题，检查一下渲染日志，看是哪个字段缺失，改模板或者改结果文件的输出格式就行。

5.5 避坑清单速查表

还有人问过能不能让 Hermes Agent 接 draw.io 画图。这个是可以的，把绘图工具的导出接口封装成一个 Python 函数，注册成工具，让模型生成绘图脚本再交给 draw.io 渲染就行。核心思路都一样：模型不直接操作外部软件，它只负责决定“调哪个工具、传什么参数”。

6. 扩展：从 ERP 系统测试到更多场景

6.1 小程序如何利用 AI 做自动化测试

小程序 UI 自动化和传统 Web 页面不太一样，驱动方式不同，但思路是一样的。把小程序自动化驱动库封装成工具，注册给 Hermes Agent，比如“打开页面”“点击元素”“获取页面数据”“截图”这几个操作，都能做成独立工具。模型只需要根据自然语言用例，决定先调哪个、再调哪个。

小程序我建议先用冒烟测试跑通主路径，比如登录、首页加载、核心业务下单，确认没有明显问题后再扩大范围。因为小程序的页面结构经常变，自动化用例维护成本比 Web 高，让 Agent 来做调度的价值反而更大，因为页面元素变了只要改工具函数，不用改业务流程描述。

6.2 和 Java 接口自动化测试框架结合

很多团队主栈是 Java，测试框架用的是 RestAssured 或者 HttpClient。这种情况不用把 Hermes Agent 限定在 Python 里。Agent 的本质是调度器，它可以直接调用命令行工具。你只需要写一个 Java 程序的命令行入口，支持传入测试模块和参数，然后在 Hermes Agent 里注册一个工具，调用这个命令行程序就行。

我试过把接口用例执行封装成 Maven 命令，注册给 Agent 之后，它完全可以正常调度。唯一的额外工作是解析 Java 程序的输出结果，格式化成 JSON 给模型读。这意味着 Hermes Agent 是一个语言无关的调度层，底层用什么技术栈都能接，价值在于调度能力，而不是语言绑定。

6.3 传统测试与自动化测试融合的团队协作建议

如果你想把这套模式带到团队里，我的建议是分工上做一些调整。业务测试同学不再需要写代码，他们的工作是把用例按“前置条件、操作步骤、预期结果”写清楚，这本来就是他们的强项。测试开发同学负责把操作步骤对应的工具封装好，也就是把业务操作变成可复用的工具函数。Agent 负责调度和报告生成。

这个分工最大的变化是，业务测试从“写用例”变成了“写 Prompt”，或者说“写更结构化的用例描述”。对团队来说并不增加太多学习成本。我在实际推进中的体会是：先把少量高价值模块跑通，比如 ERP 的采购、销售、库存这类核心链路，再逐步扩大范围。不要一开始就想着把所有模块都接进来，那样工具维护量会很大，反而推不动。

7. 写在最后：一点实战体会

跑完这 72 项测试，我最深的一个感受是：Agent 不是用来替代测试人员的，它用来替代的是重复劳动和“翻译”工作。业务人员描述需求，测试开发封装工具，Agent 负责把两边连接起来并自动执行，这个模式比“每个人都去学写自动化脚本”要现实得多。如果你现在刚开始学自动化测试，我的建议还是先把 pytest 和 Requests 这类基础框架跑熟，再回来玩 Agent。基础不牢，AI 也救不了你，因为 Agent 再聪明，也得有人告诉它工具怎么用、数据怎么造、结果怎么判断。把环境准备好、工具描述写清楚，比选什么模型更重要。另外一个小技巧：每次跑完把结果文件和报告一起归档，下次回归时让 Agent 先对比上次结果，能省下大量核对差异的时间。这套玩法后续还能往性能测试、安全扫描、数据一致性校验方向扩展，核心思路是不变的。