每天发布新版本：如何用 5 个 AI Agent 搭建全流程自动化测试？

在高频迭代的研发团队中，每天合并十几个甚至几十个功能改动是常态。当编码环节普遍引入 AI 提速后，测试往往成为交付链路中最容易积压的瓶颈：人工核对分支耗时、手写边界用例易漏、UI 回归测试重复枯燥。本文拆解 HiFox 团队如何用 5 个分工明确的 AI Agent，搭建覆盖白盒预检、版本核对、用例设计、客户端黑盒执行到人工验收的全流程自动化测试体系。

一、为什么“对话框式 AI 测试”撑不起每日发版？

很多团队尝试过用大模型写测试用例，但依然觉得慢。根本原因在于过程锁在对话框里，没有接入任务流转与真实执行环境：

每次提测都要人工把需求描述和代码提交复制给 AI；
AI 不清楚当前测试包是否包含对应 Commit，常出现“测了半天发现包不对”；
生成了用例还得靠人去客户端手点、截图，执行证据散落在本地。

HiFox 的核心思路是将需求、代码、用例和执行证据全部绑定在同一张任务卡上，通过任务状态流转自动唤醒不同职责的 Agent，实现 AI Native 的研发测试闭环。

二、 5 个测试 Agent 的角色分工矩阵

按测试阶段拆成 5 个专职角色，各司其职：

Agent 名称核心职责触发时机输入信息核心产出物白小浅白盒测试与代码预检任务进入「待测试」需求、关联 PR/Commit、代码库代码核对结论、需黑盒验证的风险项测小统测试版本预检与排期版本打包完推送飞书群版本构建信息、待测任务列表确认改动已进包、状态推至「测试中」测小案测试用例设计任务进入「测试中」验收标准、白盒指出的风险点覆盖主流程与边界场景的 16 条用例凤小九Web 端黑盒与 UI 测试用例就绪（Web 需求）用例清单、Web 环境与 Electron 技能执行结果、截图、录屏与测试报告端小九客户端黑盒与 UI 测试用例就绪（客户端需求）用例清单、桌面环境与 Stage 技能客户端报告、71 张截图与 8 段录屏等

普通 Web 功能直接走“白小浅 → 测小统 → 测小案 → 凤小九”；涉及客户端安装、升级或本地环境的任务则交给“端小九”。

图 1：HiFox 五名自动化测试 Agent 角色分工与任务状态流转链路

图 1：五名测试 Agent 围绕任务卡接力完成全流程测试

三、实战拆解：一个真实需求的 7 步自动化流转

以真实需求**「会话中可以切换 Runtime」**为例。在 HiFox 中，Agent 通过电脑上的 Runtime（如 Claude Code 或 Codex）执行工作。用户聊天时可能希望临时换工具或换电脑运行，同时保留 Agent 默认设置。

1. 需求定义与开发提测

聊天窗口需支持：默认“跟随 Agent 设置”、可为当前会话选其他 Runtime、清晰展示当前工具和电脑、不能切换时说明原因。开发 Agent 完成代码后关联 PR 并提交证据，将任务标记为**「待测试」**。

2. 白小浅：白盒测试与风险识别

任务进入「待测试」后，自动化规则立即唤醒白小浅。它先核对需求对应的提交、合并结果和测试包，确认目标改动已包含在内并执行白盒测试。同时指出需黑盒继续检查的 3 个风险点：切换电脑后的工作目录表现、弹层位置，以及失败重试是否仍落到指定电脑。

3. 测小统：版本打包预检

版本打包完成后通知到飞书群，触发测小统确认当前提测版本包含哪些需求，确认可测后把状态流转到**「测试中」**。

4. 测小案：从 7 条到 16 条用例演进

任务进入「测试中」触发测小案。它先围绕需求设计了 7 条基础用例（覆盖默认跟随、固定目录限制、切换后目录恢复、弹层展示和配置保持等）；在补充要求后，又增加了 9 条真实使用场景，扩展到 16 条用例。

5. 端小九：客户端实操与证据交付

该需求需在桌面客户端验证，由端小九实际操作并截图录屏。端小九执行完所有用例，一次性交付了 HTML 报告、产物清单、71 张截图和 8 段录屏。

图 2：端小九在 HiFox 任务中完成客户端黑盒测试并交付 71 张截图与录屏证据的界面

图 2：端小九执行 16 条用例并交付报告、71 张截图与录屏

6. 人工验收

测试人员只需做两件事：走一遍需求流程确认没有漏掉的问题；查验 Agent 留存的 71 张截图与 8 段录屏证据确认测试流程正确。通过后流转为「待发布」。

四、让 Agent 稳定跑通的配置与 7 项工程准备

在 HiFox 中配置好 Agent、自动化规则、共享 Skill（Electron 与 HiFox Stage 测试流程）、飞书与 Git 集成后，团队还需做好 7 项工程准备：

前后端代码同仓库：方便白小浅沿着页面入口、接口请求到数据存储追踪实现，在同一代码基线核对前后端逻辑。
按全栈方式交付功能：由专人对完整用户路径负责，前后端改动、部署条件和验收规则对齐后再提测。
使用 24 小时在线的共享测试机：预装浏览器、测试客户端、Runtime 和专用账号，避免个人电脑休眠中断。
把测试环境准备写成脚本：提供统一的依赖安装、数据库初始化、服务启动和测试命令，开测前自动检查环境：

npm run env:check && npm run db:migrate && npm run test:start

准备专用账号和数据：提前备好管理员、普通成员、只读成员及有无空间权限的账号，支持测试数据自动创建与清理。
给每个 Feature 写清验收标准：明确切换影响当前会话还是全局、运行中能否切换、换电脑后路径如何处理、失败重试用哪个 Runtime，减少把现状当预期。
测试产物及时上传：报告、截图和录屏执行后及时上传并关联任务、运行编号和用例编号，防止临时目录被回收导致重测。