如何为指定项目搭建测试 Agent，选择什么技术栈？

核心回答

我会先确认项目的核心流程、技术栈、现有测试和验收标准，再搭建能设计用例、调用测试工具、根据证据分析失败的测试 Agent。模型负责理解需求和补充场景，测试框架负责真实执行，是否通过由明确断言判断。

以一个有登录、文件上传和异步任务的 Web 项目为参考方案：

• Python 编排 Agent：读取相关需求、接口文档和变更，生成带预期结果的测试计划；第一版用单 Agent 加受控工具即可。
• pytest 加 HTTP 客户端测接口，Playwright 测关键页面流程；已有 Java、前端单测等框架继续复用，由执行工具调用。
• 独立测试环境、账号和数据承接操作；运行结果保存到结构化记录，附上失败日志、截图或 trace。
• 按“计划—执行—判定—分析”迭代：环境问题可以有限重试，稳定复现的功能失败输出缺陷证据；报告说明测了什么、哪里失败和哪些没测。

技术栈服务于被测项目。只有需要复杂分支、暂停恢复时再引入 LangGraph 等编排框架，不必一开始就搭多 Agent 或知识库。

展开说明

1. 先让 Agent 了解项目的可测试边界

输入包括需求验收项、相关代码与接口契约、启动和测试命令、依赖服务、已有用例，以及这次要验证的改动。先跑通一条已有测试，确认环境和基础数据可用，再扩展正常、边界、异常和权限场景。

每个用例至少说明前置状态、操作、预期结果和清理方式。比如“上传后提示成功”还不够，应确认任务被创建、状态能按约定变化、输出文件可取得。预期应来自需求或业务契约，不能只照着当前代码生成，否则容易把已有缺陷写成正确答案。

2. 给模型可以组合的测试能力

工具可以包括读取指定资料、列出已有用例、运行指定测试集、发送测试接口请求、执行浏览器动作和收集产物。模型输出的是结构化调用请求，执行器校验参数、环境和允许范围后才运行，并返回退出码、断言结果及证据位置。

不要只暴露一个“执行任意命令”的工具，让模型临时猜完整测试流程。复用已经可靠的测试入口，再让 Agent 决定补哪些场景，通常更容易维护。报告服务或操作界面可以后续增加，不是测试能力成立的前提。

3. 用一个上传用例串起实际执行

假设验收要求是“合法文件能够生成任务，超过限制的文件被拒绝”。Agent 先根据契约生成两个候选用例，明确合法格式、大小限制和预期错误。

接口层由 pytest 准备测试账号及文件，HTTP 客户端提交请求，检查响应结构和任务记录；异步任务在有截止时间的轮询中检查终态及产物。页面层用 Playwright 定位上传控件，操作并断言界面状态，同时保留网络或服务端证据。浏览器上下文隔离登录态，后端测试数据仍需独立准备和清理。

若测试挂了，先区分服务未启动、定位符失效、测试数据冲突和真实业务缺陷。基础环境故障修复后可重跑；业务结果错误则保存预期与实际差异。不能通过删断言或不断重跑，把偶尔通过解释成问题已解决。

4. 自动化要留下可复现的结果

一次运行记录代码版本、需求版本、环境配置、用例与执行结果，失败时附复现步骤、日志和产物。模型可以归纳失败原因、提出补充用例或修复建议，但判断功能是否正确仍优先依赖状态、Schema、业务不变量等可执行检查。

对重复执行的稳定用例，可以放入已有 CI；探索生成的新用例经确认后沉淀为回归测试。衡量效果时看有效缺陷发现、误报、复现稳定性和人工分析成本，不能只看生成了多少条用例。

常见追问

如何把整个测试流程自动化？

从一条核心业务链开始，把环境准备、数据创建、测试执行、结果收集和清理串起来，再让 Agent 补场景、选相关测试和分析失败。固定步骤交给脚本与测试框架；需求有歧义或缺少判定依据时，先明确预期。已有自动化已经覆盖的固定流程，不必让模型每次重新规划。

被测项目本身也是 Agent，要增加什么？

除了接口与页面功能，还要检查任务是否完成、工具选择与参数、权限范围、失败恢复和外部状态。对模型输出可补语义评测，但退款是否发生、文件是否生成等结果仍查实际状态。固定版本和环境，同类任务多次运行，观察失败类型及波动，不能以一次回答顺畅代表通过。

一定要拆成规划、执行、验证三个 Agent 吗？

不一定。这是职责划分，可以先由一个 Agent 配合执行器和确定性断言实现。场景很多、专业知识不同或确有并行需求时再拆；拆分后也要共享同一份需求与运行标识，避免生成器和验证者各自理解一套标准。

参考资料