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 方案用例维护脚本即用例业务变则脚本变用例和脚本分离但平台搭建重用例清单与执行工具分离更新成本低触发方式命令行或 CI 触发平台界面触发自然语言一句话触发报告产出需要自己写逻辑平台自带模板自定义agent 自动调用对测试开发依赖高中中低业务人员也可参与落地周期短长短选型时我的判断是不是 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 的流程。它不会拿过指令就直接执行而是先生成一份执行计划然后按计划逐步调用工具。我这次实际生成的计划大概是这样的读取采购模块测试数据和历史用例清单准备测试账号和环境检查执行接口测试用例并收集结果执行页面测试用例并收集截图执行数据库数据校验汇总所有结果并生成 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, ftests/{module}, -m, mark, --json-report] result subprocess.run(cmd, capture_outputTrue, textTrue) 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 避坑清单速查表问题现象常见原因处理方式依赖装不上Python 版本不匹配统一用 Python 3.11换镜像源模型连不上base_url 配错先用 curl 验证本地接口任务拆解乱工具描述模糊补参数约束和适用场景说明结果不稳定测试数据污染每次执行前清理测试数据报告为空结果 JSON 太大被截断传文件路径而不是传内容页面失败多等待时间不足单独调整 UI 工具的超时参数还有人问过能不能让 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 先对比上次结果能省下大量核对差异的时间。这套玩法后续还能往性能测试、安全扫描、数据一致性校验方向扩展核心思路是不变的。