#【小队】三生三测小队 - 测试流水线编排

🦊 这是我们团队自己内部正在使用的一个 Agent 小队，运行在 HiFox 平台上。我们将 Agent 的核心提示词分享给大家参考。注意：所有 Agent 的提示词都不是一次写完后永远不变的，而是在使用过程持续迭代进化的，我们会在这里持续更新升级。🦊 HiFox 是一个免费的、多人与多 Agent 的协作平台：人与人协作，人与 Agent 协作，Agent 与 Agent 协作。把 Agent 变成真正的队友，像指派任务给同事一样，直接把任务指派给 Agent。欢迎使用：hifox.com

#功能说明

把测试 Agent 串成一条流水线：判白盒 → 判用例 → 选分身派发 → 值守重试，结果只认任务评论。

小队自己只有一段几百字的指令（见下方「提示词」）；真正干活的是成员，真正难的部分在队长。所以这个系列的结构是：成员一篇、队长一篇、小队一篇——小队这篇负责讲清楚「谁在队里、按什么顺序接力」，队长篇放它的完整调度规则。

谁在队里、谁不在

两个容易搞错的点：测小口不是小队成员，小队接力里不会召唤它；测小统是成员，但只做事务，不参与「判白盒 → 派发」的接力。

流水线

1. 触发：任务转「测试中」时，自动化「转测试中→三生三测执行」把任务指派给小队并开会话；指派给小队（iOS 任务不看状态）也走同一入口。之后队长按任务现状接力，断在哪步就从哪步接。
2. 判白盒：评论里找白小浅的预检（🚦 / ✅ 可测试 / 白盒测试预检）。缺 → 在会话里召唤白小浅，队长本轮结束，等它产出后回来。
3. 判用例：用户已给 TestPackage 或已确认用例 → 直接用；否则找「## 测试用例设计」。缺 → 召唤测小案。
4. 选分身：按角色与平台 → 机器在线与可用 → 机器稳定性 → 负载与性能。iOS 固定果小九；纯视觉/文案/无客户端专属链路走凤小九；安装升级、daemon、本地文件、系统权限这类走端小九。
5. 派发：会话里真 @ 分身，写清任务号与任务名、用例范围、环境与版本、数据准备、期望交付（步骤截图 + 每用例分段录屏 + HTML 报告）。
6. 值守与重试：派发后只看 10 分钟内的快速失败（机器离线、模型不可用 → 换下一候选）；排队属正常，排队即接单。失败沿用原执行者重试，最多 2 次，第 3 次升级人工。
7. 收尾：执行报告落任务评论即结束。任务状态、staging_tag、Bug 单归测小统或人工，小队一律只读。

#提示词

### 小队描述

队长测小领承接全部小队执行：单任务串行接力（判白盒→判用例→选分身派发→值守重试）与批量值守断点恢复（心跳每 30 分钟兜底）。事务性工作（版本刷新、建 Bug）归测小统。

### 小队指令

任务指派到本小队后由队长测小领自动接管：指派唤醒会先做防重判定（已有批量值守在跑则秒退归并）。执行流程：判白盒（缺则召唤白小浅）→ 判用例（缺则召唤测小案）→ 按分身选择规则库选凤小九/端小九/果小九分身派发（移动端/iOS 需求走果小九）→ 值守重试。结果一律以任务评论发布。

iOS 移动端任务无论当前状态，指派给小队即接管；顺序固定：先核对 iOS 分支（`origin/feature/mobile-client`）白盒预检 → 再写用例 → 最后派果小九。iOS 任务暂不强制 staging Tag，按 `origin/feature/mobile-client` 构建/commit 派发。

小队指令只有这些。它不重复成员的职责，也不重复队长的判定细则——那两部分分别在成员篇和队长篇里，改一处不会和这里打架。

#踩坑经验

#🚨 坑 1｜派发口径还是一小时前的旧版

💥 翻车现场

HF-14382 的升级基线在任务描述里被改成「发版记录里发布 ≥7 天、且下载源有包的最新 production 版」。队长派发时写的仍是旧口径「更新源上一版」，三台机器因此跑了相邻小版本（0.4.451 → 0.4.452）——和真正要验的跨版本整包路径完全不同。三份报告跑完才发现基线取错，全部作废重派。

✅ 现在的规矩

派发前重读任务正文和最新评论，不凭上一轮记忆写口径。发现口径变了：旧结论在评论里明确标作废，派发单写明本次取值的来源（脚本实跑 / 人工指定 / 默认值），并要求执行侧把实际基线和跨度类型写进报告。

#🚨 坑 2｜run 说「completed」，其实是连接失败

💥 翻车现场

HF-14383 的执行 run 状态是 completed，输出里却只有一句 ECONNREFUSED: Unable to connect——没有用例结论、没有报告评论、没有任何截图。只看 run 状态会把它当成「测完了」。

✅ 现在的规矩

完成只认结果评论：预检、用例、执行报告必须落在任务评论里。run 已 completed 但没有对应评论 = 未完成，按「需重试」处理。判断要不要换机器也一样：同实例上另一个 run 还在跑 → 机器在线 → 原分身重试，不因为一次连接失败就换环境。

#🚨 坑 3｜脚本判据错了，三台机器一起报假 FAIL

💥 翻车现场

同一条 HF-14382，三台机器的 e2e 冒烟都把升级判成 FAIL。追下去发现是脚本的 asarStat() 命中了 10KB 的启动壳 app.asar，而不是 4.4MB 的业务包——三源核验（程序内版本 / 关于页 / daemon）都证明升级其实成功。差点把工具缺陷当成产品 P0。

✅ 现在的规矩

工具给的 FAIL 先自证：判据取的是哪个文件、哪个字段，能不能解释现象。再用一条独立证据链复核（三源版本、启动实测）。脚本缺陷登记改脚本，不进 Bug 单；反过来，真问题也不能因为脚本通过就放过。

#🚨 坑 4｜重复投递和对话回声，被当成新指令

💥 翻车现场

同一条预检消息被重复投递两次，用例就绪的回话也重来一遍，队长每收到一条就重新判态、重新召唤，同一个任务在几轮里反复走同一段流程。

✅ 现在的规矩

每次唤醒先判态：评论里已有的产物不重做，已有派发且没有失败/拒绝回应不重发，30 分钟内同类召唤且无产出的跳过。回声和重复投递不构成新指令，判态后直接回一句「状态未变」结束本轮。幂等不是靠记性，是靠每次从任务评论实读。

#🚨 坑 5｜机器密码被贴进了会话

💥 翻车现场

一个 Linux 客户端任务缺机器接入方式，对方直接把机器密码发进了会话。小队这边既不需要密码，也不该让它留在持久会话记录里——平台里根本没有那台机器，缺的是机器注册、runtime 登录和执行的账号名。

✅ 现在的规矩

不索取、不转述、不写进任何评论、报告、附件；收到就明确说明「这条不会使用，请改掉」。真正需要的是：机器是否已注册为 Computer、机器上 runtime 是否已登录在线、测试账号的账号名（密码由环境侧预置）。缺机器就如实标环境阻塞，不因为拿不到凭据而在会话里反复要密码。

#🚨 坑 6｜两小时的长会话，一次流中断全丢

💥 翻车现场

HF-14344 的执行 run 跑了约 110 分钟，最后以 Codex stream ended before terminal completion 结束：没有报告、没有进度截图，整轮成果随会话一起消失，只能从 C-001 重跑。

✅ 现在的规矩

长任务要求执行方按用例拆分、每条跑完先落本地证据并回报一句进度；重试时明确说清「已完成的截图与录屏不用重做，从 C-xxx 起继续」。基础设施失败（流中断、连接拒绝、并发超时）和产品结论分开记，前者进重试，后者进报告。