构造 AI 驱动的多 Agent 测试智能体实战

如果你现在做自动化测试，脚本写得再熟，大概也遇到过这几个卡点：用例维护成本比写还高、UI 改版一次挂一片、接口断言靠人肉补、失败原因要一个个翻日志。这门课讲的不是"再学一个测试框架"，而是把大模型和多个 Agent 拼成一条能自己跑、自己判断、自己修的测试链路。适合已经会写自动化脚本、但对 Agent 怎么落地到测试场景没有具体概念的人。

先确认你缺的是哪一块

这门课的起点不是"什么是大模型"，而是三个更具体的能力缺口：

• 知道 Prompt 怎么写，但不知道测试任务怎么拆给多个 Agent 分工——谁生成用例、谁执行、谁判失败、谁写报告；
• 听过 Harness、Agent Loop 这些词，但说不清一次完整的 Agent 运行里，模型调用、工具调用、状态回传是怎么串起来的；
• 做过 AI 辅助生成用例的小工具，但它只能生成不能验证，产出质量靠人兜底，没法接进真实项目。

如果这三条里有两条对上，这门课的密度对你是合适的；如果连接口测试和断言都没写过，建议先把基础补上再来，否则多 Agent 的编排部分会变成看热闹。

课程围绕什么展开

主线是"从单个 Agent 到多 Agent 协作"的递进。前半段解决单个 Agent 的基本构造：怎么给模型定义角色和可用工具、怎么让它调用测试执行器拿到真实结果、怎么把结果回灌给模型做下一步决策。这一段的关键不是写 Prompt，而是理解 Agent 的循环结构——什么时候该继续、什么时候该停、失败信息怎么变成下一轮的输入。

后半段进入多 Agent：把测试流程拆成几个职责单一的 Agent，比如负责需求解析和用例设计的、负责执行和采集结果的、负责失败归因的、负责汇总报告的。拆开之后要解决的问题就变成了通信和状态管理：Agent 之间传什么格式的数据、中间结果放哪、某个 Agent 判断错了谁来纠正。这部分是课程的重点，也是大部分自学的人卡住的地方。

Harness 相关的内容穿插在其中，讲的是这套东西怎么被组织成一个可复用、可观测的运行骨架，而不是每次从零拼一个脚本。

练什么，练到什么程度

配套练习跟着主线走，大致是：先让一个 Agent 跑通"拿到需求描述 → 产出用例 → 调用执行 → 返回结论"的最小闭环；再把其中判失败、做归因的部分拆成独立 Agent，观察拆分前后输出质量的差异；最后接一个相对完整的场景，让多个 Agent 协作跑一轮，并检查每一跳的中间产物。

这些练习的价值在于让你亲眼看到失败案例：Agent 什么时候会编造不存在的接口、什么时候会把环境问题误判成代码缺陷、什么情况下多 Agent 反而比单 Agent 更不稳定。这些现象在文档里看不出来，只能自己跑出来。

看完应该能回答的问题

• 一个测试 Agent 的最小可用结构包含哪几部分，缺了哪部分会导致它只能"说"不能"验"？
• 把测试流程拆成多个 Agent 时，按什么维度拆比较合理，拆太细会带来什么问题？
• Agent 之间传递的状态怎么设计，才能让失败归因那一环拿到足够信息？
• Harness 在这套体系里承担什么职责，没有它会出现哪些重复劳动？
• 什么情况下不该用多 Agent，单 Agent 加固定脚本反而更稳？

如果这些问题你现在只能答个大概，课程结束后应该能给出带具体取舍理由的答案。带着其中一个问题去听，比从头顺一遍收获更实在。