企业官网建设流程全解析

上个月帮团队做接口测试提效，订单管理模块那条“分页查询订单列表”的接口，按老办法得先翻需求文档、对字段、设计正常异常场景，再手写断言和边界值，一个人磨下来差不多一个小时。后来我把同一个接口的Swagger定义和一段需求描述直接丢给一个测试用例生成智能体，十分钟左右就拿到20条可用用例，每条还自动生成了可执行的pytest脚本，跑完一看，行覆盖率比手工写的还高了几个点。

这个结果的关键，不是“用AI生成测试用例”这个想法有多新，而是把“测试用例生成”这件事从一次性的提示词问答，重构成一个完整的智能体工程问题。本文就用订单模块这一个案例，把测试用例生成智能体涉及的技术栈一条条拆开讲清楚：意图识别、RAG召回、工具调用、结构化输出、结果校验、覆盖率反馈，再到多智能体协作和代码结构建模。适合QA工程师、测试开发、后端开发，以及所有想从零搭一个能真正干活的智能体的人。我会把每个环节“为什么这么设计”也说清楚，不是只列一堆名词。

1. 一次真实的测试提效经历：为什么不能只靠“AI写用例”

先说结论：单次对话式的“帮我写测试用例”和智能体化的测试用例生成，差的不是模型能力，而是系统设计。如果你只是把接口文档复制进大模型对话框，让它生成用例，三五条简单场景没问题，一旦涉及几十个字段、十几条业务规则、还要执行和验证，大模型就开始编字段、编断言、编出根本不存在的接口行为。这不是模型不行，是你没有给它“确认事实”的机制。

我这次做订单模块，输入材料只有三样：

• 订单查询接口的Swagger/OpenAPI定义，约40个字段；
• 一页半的需求说明，包含分页、排序、时间范围过滤、状态过滤几条业务规则；
• 项目仓库里已有的订单相关历史测试用例，共23条，分布在两个文件里。

这些材料如果全部塞进一处对话上下文，模型很快就被大量字段冲昏头。所以我做的是把整个流程拆成“读定义—查历史—定场景—写代码—执行—看覆盖率—修正”七步，每一步都交给智能体里的一个明确组件去完成。这一步一个组件，就是智能体与传统“大模型对话”的分水岭。

再说提效数据。原有人工方式，从读文档到用例评审通过，单接口平均50分钟左右；这套智能体跑完一轮生成加上人工复核入库，大约25分钟，接近对半的提效。更关键的是，它能把每次跑出来的覆盖率数据沉淀下来，以后同类接口生成时会自动参考历史效果，越用越准。

很多人问，这种能力难道不能靠一个“写得很好的Prompt”实现吗？我的答案是不能。Prompt能约束输出格式，但约束不了模型对代码仓库真实结构的理解，也约束不了断言强度和覆盖率达标。这些需要工具调用、检索增强和执行反馈回路，也就是智能体真正值钱的地方。

2. 技术栈全景拆解：从一堆新名词到一张分层架构图

聊智能体技术栈，最容易被一堆名词绕晕：智能体框架、MCP、向量数据库、RAG、多智能体、GNN、AgentScope、Dify、Coze、Hermes……好像每个词都能炒一锅菜。我习惯把测试用例生成智能体的技术栈按“管道”而不是按“品牌”来分层，因为测试用例生成场景的核心流程非常固定：读代码和文档、推理场景、出用例、执行验证、反馈修正。

2.1 五层管道：感知、规划、执行、记忆、校验

这套分层，是我在实际跑通订单案例后倒推出来的，现在做测试用例生成智能体基本都能对上号：

2.2 热搜词在管道里的真实位置

把最近比较热的智能体相关词放进这个分层，你会发现它们不打架，各自有明确位置：

• Dify、Coze（扣子）：属于规划层的可视化智能体编排平台，适合快速搭建工作流、做产品验证。Dify搭RAG、知识库和工具调用比较方便，Coze在对话框交互和插件生态上有优势。
• Hermes智能体：相当于可本地部署的智能体运行时，适合对数据敏感、要求内网或私有化交付的测试团队。我本地搭过一个用来做代码仓库分析，部署上比想象中轻，资源占用可控。
• MCP（Model Context Protocol）：这是执行层与外部工具之间的“USB-C接口”标准。工具接入、读取文件、执行命令、调覆盖率接口，统统归一成MCP协议，模型侧不用为每个工具写定制调用。
• 向量数据库与RAG：属于记忆层。测试用例生成特别依赖历史用例和缺陷库，因为你希望模型“看到”以前这个模块踩过什么坑，而不是每次都从零发挥。
• 图神经网络（GNN）：属于感知层与规划层之间的增强。它把代码的调用关系、控制流建模成图，再通过神经网络学习到边界路径、高风险节点等特征，辅助智能体判断“哪些分支最值得生成用例”。
• AgentScope、LangGraph、多智能体：属于规划层的高级形态。生成用例的角色、代码分析的角色、覆盖率验证的角色分头干活，通过类似A2A（Agent-to-Agent）协议交换结果。AgentScope 2.0对A2A协作支持已经比较顺。

2.3 为什么我选“管道分层”而不是按平台选型

很多人一上来就问“选Dify还是Coze”“要不要自研框架”，我一般劝他们先别选，先把流程图画出来。流程图上“读取代码”这一步，如果团队内网没有现成工具，那你就需要一个文件读取MCP工具；流程图上“查历史用例”这一步，如果你们还没有向量知识库，那这就是一个RAG子项目。技术栈不是“选”出来的，是流程“逼”出来的。

在我这个订单案例里，真正跑起来需要的技术栈很少：一个支持工具调用的大模型、一个可视化编排层（我用的Dify）、一个能执行本地命令的工具层（pytest命令、grep命令）、以及一份历史用例的向量库（我用pgvector，因为直接跑在现有PostgreSQL里，少维护一个组件）。GNN和多智能体是这个案例的进阶版，后面第五章单独说。

3. 案例落地：给订单模块生成完整测试用例的六个步骤

技术栈讲完，进入实操。订单模块的“查询订单列表”接口，需求不算复杂但典型：支持分页、可按订单状态筛选、按创建时间范围筛选、按订单号精确查询，排序字段可选。我把实现过程拆成六个步骤，每个步骤都标注了“为什么这么做”。

3.1 步骤一：定义输入包，把“上下文”变成“数据资产”

智能体不是凭空生成用例，它需要结构化输入。我不会把所有文档一次性塞给它，而是做一个固定目录，称为“输入包”：

• openapi.yaml：接口定义，含字段类型、必填项、枚举值、参数约束；
• requirements.md：一段精炼的需求说明，控制在300字以内；
• code/：订单服务的核心源码目录，智能体按需读取，而不是全量读取；
• history_cases/：历史订单接口的测试用例，用于RAG召回。

这一步的设计理由：给智能体划定一个“工作区”，它只会在这个范围内做文件读取和信息检索，避免它在几十万行的代码仓库里迷路。对于企业级系统，这个做法的价值远大于“塞一个强大的模型进去”，因为你把边界切好了。

3.2 步骤二：搭好编排平台，配置模型和工具层

我这里用的是Dify搭建工作流，配置如下：

1. 在Dify中新建“Chatflow”应用，模型选择支持函数调用和结构化输出的模型，我用的是GLM-4-Plus和DeepSeek-V3各跑过一轮，都能完成任务，差异只在生成代码的细节风格上；
2. 配置工具：把“文件读取”和“命令执行”封装成两个MCP工具。文件读取工具接收文件路径参数，返回文件内容；命令执行工具接收shell命令，返回标准输出和退出码；
3. 配置知识库：把23条历史用例切成chunk，向量化后存入pgvector，Dify里挂一个知识检索节点；
4. 设置全局变量，用来保存“当前接口名”“当前覆盖率”“已完成场景列表”。

平台与自研框架的选择，我的做法是：先用可视化平台快速验证流程，验证到瓶颈再换代码型框架。可视化平台的价值，是让你肉眼看见“模型在这一步到底调用没调用工具”，这个调试体验对新手非常重要。

3.3 步骤三：写系统提示词，把角色和行为边界讲透

系统提示词是整个智能体的“岗位说明书”。我这份提示词经过几轮迭代，核心内容如下：

你是一名资深测试开发工程师，负责为订单管理模块生成高质量测试用例。 工作流程： 1. 先读取openapi.yaml，列出所有参数、边界、必填项； 2. 查询历史用例知识库，判断哪些历史场景需要继承或扩展； 3. 结合需求文档，设计正常流、异常流、边界流、权限流四类场景； 4. 每个场景输出一个pytest函数，断言必须覆盖响应状态码、关键业务字段、边界值校验； 5. 执行pytest并获取覆盖率；若覆盖率或关键场景缺失，自动修正并重跑。 硬性要求： - 不要生成接口定义中不存在的参数； - 不要忽略必填参数的缺省场景； - 每个测试函数必须有函数注释，说明它覆盖的业务规则； - 断言不得只写status_code==200； - 不得输出与测试用例无关的解释，所有输出按JSON格式返回。

这份提示词的几个关键“反幻觉”设计点：

• 显式要求“先读取”“再查询”，而不是“根据你的知识”。这从流程上强制模型依赖真实数据；
• 硬性要求“不要生成接口定义中不存在的参数”，针对的是模型最爱编字段的通病；
• 断言不得只写200，是针对“覆盖率虚高”的防御措施，后面第四章会细讲。

3.4 步骤四：用JSON Schema锁定输出格式，下游才能自动装配

大模型生成测试用例，如果输出是自由文本，下游自动化根本没法处理。我的做法是要求模型按固定JSON Schema输出，每个场景是一个结构化对象：

{ "schema_version": "1.0", "case_set_id": "order_query_001", "cases": [ { "case_id": "C001", "title": "正常分页查询-第一页返回10条", "category": "normal", "preconditions": "存在至少10条订单数据", "request": { "path": "/api/orders", "method": "GET", "params": { "page": 1, "size": 10, "status": "PAID" } }, "expected": { "http_code": 200, "body_assertions": [ "response.data.list.length <= 10", "response.data.total >= 10", "each item.status == 'PAID'" ] } } ] }

这个结构有几个好处：第一，模型被约束在字段级，不能随便发挥；第二，后续把JSON转成pytest脚本，只是写一个模板渲染函数的事，不需要解析自然语言；第三，每个用例的preconditions和body_assertions必须是显式字段，逼着模型把“为什么测”和“怎么断言”想清楚。

在Dify里，实现方式是在工作流最后加一个“结构化输出”节点，提示模型“严格按用户指定的JSON Schema输出，禁止附加markdown代码块”。实测这一步非常关键，不加这句话，模型经常把JSON包在```json代码块里，下游解析要多写不少容错逻辑。

3.5 步骤五：执行与反馈闭环，覆盖率是硬指标

生成用例不等于任务结束，我设计的智能体有一个“验证循环”：

1. 模型输出JSON用例集；
2. 工具层把JSON渲染成pytest文件，写入临时目录；
3. 执行pytest --cov=order_service --cov-report=term-missing，拿到行覆盖率和未覆盖行号；
4. 把覆盖率结果和未覆盖行号回填给模型，模型针对未覆盖分支补充用例；
5. 循环最多3次，超过次数就停止，把“未能覆盖的行”作为风险项输出给人工。

这个反馈闭环，是整个智能体最核心的技术栈设计。没有这一步，智能体只是一个“生成器”；有了这一步，它才变成“生成+验证+修正”的工程系统。

订单接口这一轮的实际数据：第一次生成16条用例，行覆盖率62%；回填未覆盖行后补了4条用例，覆盖率到81%；第三次补了3条，覆盖率达到88%。剩下12%主要是异常分支和数据库连接异常等难以稳定复现的场景，标记为人工作为可接受风险。

pytest执行过程会偶发不稳定，比如测试库数据被清理导致前置条件失败。我的工具层专门做一个“数据准备”脚本，在每次执行前插入两条标准订单数据，保证可重复性。这个细节很琐碎，但对“让智能体稳定循环跑”非常重要。

3.6 步骤六：人机协同收尾，给“确认”和“兜底”留出口

智能体给出最终用例集后，我不会让它直接提交代码仓库，而是加一个“评审人”环节。这个环节做了两件事：

• 展示给测试负责人的人工复核视图：每个用例的场景分类、前置条件、断言列表、覆盖率分布一目了然；
• 保留“人工修正”入口：测试负责人可修改断言、删掉无效用例、补充特殊业务规则，确认后合并到真正的测试仓库。

个人经验：智能体自动化程度可以高，但最后一道“删用例”的权限必须给人。因为测试用例不是越多越好，滥用例会显著增加维护成本。我见过一些激进自动化团队，让智能体无限制补充用例，结果用例数量一周翻了两倍，CI时间从10分钟涨到40分钟，最后又不得不做用例瘦身。所以我在设计阶段就规定：单个接口单轮生成用例数上限30条，超出部分必须人工确认。

4. 实测中的三类翻车现场：流程跑通后真正的坑在哪

流程跑通只是开始，真正折磨人的是细节。订单案例里我踩了三个典型坑，每个都值得单独说。

4.1 幻觉出“不存在的接口字段”：根因不是模型，是没给它“确认机制”

第一次跑通流程后，我检查生成的用例，发现有一条用例断言response.data.orderType == "NORMAL"。乍一看没啥问题，但我翻了OpenAPI定义，orderType这个字段根本不存在，模型是在命名上“顺着感觉”编了一个字段，然后基于这个字段写了断言。这种用例如果进了仓库，要么在运行时直接报KeyError，要么因为断言永远不会真正校验到值而成为“假用例”。

根因分析：大模型在做代码补全式推理时，会基于训练先验“订单一般有orderType字段”生成内容，而对本次接口的真实定义没有强约束。解决办法不是换更聪明的模型，而是在提示词和工作流里同时加约束：

• 提示词里强调“所有字段必须能在openapi.yaml或源码中找到，否则不要出现在断言中”；
• 工作流中增加一个“字段校验”工具，把模型输出的JSON里的所有字段名自动与接口定义的字段集合做比对，出现不明字段直接打回重新生成。

这个“字段校验工具”本质上是给智能体装了一个安全网，它不依赖模型自觉，而是机械地阻止幻觉进入下游。把它做成MCP工具后，所有接口生成任务都能复用，性价比很高。

4.2 断言弱到形同虚设：覆盖率虚高但缺陷漏检

第二个坑是模型生成的断言往往偏弱。比如查询订单列表接口，模型经常只断言status_code == 200和len(data) >= 0，这类断言看着覆盖了一大堆执行行，覆盖率数字很好看，但实际什么都不验证，业务缺陷照样漏出去。这属于“覆盖率虚高”问题。

我的修正方案是定义“断言强度”规则，在提示词和校验工具里双管齐下：

• 显式禁止只写状态码断言；
• 要求每个GET类接口至少断言响应体中的一个业务字段；
• 对分页接口，必须断言page、size、total三个分页参数的关系；
• 对筛选接口，断言返回数据中的所有元素都满足筛选条件，而不是只断言HTTP状态。

我写了一个简单的断言强度检查工具，解析生成的pytest代码，统计每个测试函数里assert关键字的数量和断言面向的对象。如果发现存在“只有状态码断言”的测试函数，就标记为“弱断言”，让模型补充后再进入执行环节。经过这个修正，用例的缺陷检出能力提升明显，在订单接口的历史缺陷集合上做了回归，检出率从55%提升到83%。

4.3 循环失控：覆盖率上不去，模型就开始“凑用例”

验证循环里另一个经典问题：模型发现覆盖率指标不够，不是去分析未覆盖的代码行逻辑，而是机械地生成“换参数组合”的重复用例，比如page=1、2、3各来一条，分页参数从0到100逐个测一遍。这些用例对覆盖率提升毫无贡献，却把执行时间拉得很长，也增加了后续维护成本。

我的应对是三层机制：

1. 对生成用例做相似度去重：每个用例JSON渲染成一段文本，计算sha256哈希，哈希相同直接跳过；再做一次简单的字段级指纹比对，字段名、参数值、断言表达式完全相同但顺序不同的用例也算重复；
2. 限制循环次数：最大3次，第三次结束后无论覆盖率多少都停止，把未覆盖行输出为风险清单，而不是无限循环；
3. 在提示词中加入“覆盖率未提升时，分析未覆盖行的业务逻辑，优先补异常分支和边界分支，而不是枚举参数组合”。

这几个机制加完后，智能体的行为模式明显变化：第二轮补充的用例开始主动跑到“订单状态为CANCELLED时返回空列表”“时间范围跨月时分页正常”这类边界逻辑上，而不是继续刷分页参数。这说明模型不是不能做好，而是需要一个强制的分析路径。

5. 进阶联动：图神经网络、多智能体协作与覆盖率优化的想象空间

订单案例的基础版跑通之后，我开始琢磨两个进阶方向，一个是代码结构感知，一个是多智能体协作。这两个方向对测试用例生成的技术栈完整性很重要，虽然落地成本更高，但确实能解决前面的方案解决不了的问题。

5.1 用图神经网络做代码结构感知，让智能体“看懂”调用链

订单接口不算复杂，但很多企业系统接口背后是一长串调用链：Controller调Service，Service调Mapper，Mapper查数据库，中间还有缓存、消息队列、外部RPC。如果智能体只看接口定义，它生成的是“黑盒用例”，覆盖的是入口的参数校验，很难触达深处的分支。

GNN在这里的作用是：把代码的函数调用关系、控制流依赖建模成图，通过图神经网络学习到“哪些代码节点是关键路径”“哪些节点是缺陷高发区”等结构化特征，然后把这些特征作为模型生成用例时的上下文提示。

具体步骤我梳理了一下，分成四步：

1. 用tree-sitter或JavaParser解析Java工程，提取每个函数的调用关系和控制流分支；
2. 构建函数调用图（Call Graph）和每个函数的控制流图（CFG），节点是函数或基本块，边是调用关系或跳转关系；
3. 用networkx做基础特征计算，比如节点度数、环路复杂度、出入度，再用GCN或GraphSAGE生成节点Embedding；
4. 将关键节点的Embedding和对应的源代码片段一起，作为上下文注入智能体生成用例时的提示词。

我自己的实践是在一个内部小项目里试了前三步，CLOC约3万行的订单服务，构建调用图大约耗时1分钟，识别出18个高复杂度函数，其中6个被智能体优先补充了用例，把这三个文件的行覆盖率从71%提升到92%。这个收益比“无差别补充用例”高很多。

对大多数团队，我的建议是：不需要一上来就自己训练GNN模型，现阶段的工具链路里，用静态分析工具（比如SpotBugs、SonarQube）先算出“高复杂度、高变更频率、多调用者”这些可解释特征，就已经能给智能体提供有用的代码结构感知了。GNN更像是一个增强特征表达的可选项，先能把“调用链”信息线性的提供给模型，就已经超过很多团队了。

5.2 多智能体协作：用例生成Agent、代码分析Agent、覆盖率验证Agent

单智能体做测试用例生成，瓶颈在于所有任务都挤在一个上下文里：既要做代码分析，又要做用例生成，还要分析覆盖率结果和修正代码。上下文一长，模型的注意力就分散，前面分析的“陷入参数组合”等问题，很大程度上都是上下文杂乱导致的。

多智能体思路，就是让每个Agent只干一件事，通过协议交换结果。我设计的角色划分如下：

三个Agent通过类似A2A的协议协作：代码分析Agent产出结构洞察后，作为任务上下文传给用例生成Agent；用例生成Agent产出用例后，发给覆盖率验证Agent执行；覆盖率验证Agent把不达标信息和原因回传给生成Agent，形成第二轮循环。

这个结构的好处是每个Agent的上下文都很短，用例生成Agent不需要理解整个代码仓库，只需要吃“代码分析Agent”已经提取好的摘要。我用AgentScope 2.0的A2A模式试过这个协作流程，虽然多了一层通信开销，但生成用例的针对性明显更好，上下文也更干净。

不过我还是想提醒一句：多智能体不是银弹。如果单智能体还没把工具调用、RAG、反馈闭环跑通，直接上多智能体会把问题放大三倍——每个Agent都要调试，Agent之间的通信也变成新的不稳因素。我的建议是先用单智能体跑通基线，等明确感受到上下文拥挤的瓶颈时，再考虑拆Agent。

5.3 记忆层：为什么历史用例和缺陷库值得做成向量检索

不管是单智能体还是多智能体，RAG记忆层都是容易被低估的一环。第一次跑订单案例时，我没有挂知识库，智能体生成的用例风格很“通用”，每个场景都是“正常分页、边界值、异常参数”三板斧，跟这个模块历史踩过的坑完全无关。我的23条历史用例里明明有一条“订单金额为0时不允许提交”的回归用例，智能体完全不知道，也没有生成。

把历史用例和缺陷记录做进向量库之后，效果变化很大。做法是把每条历史用例的结构化部分转成一段自然语言摘要，比如“历史缺陷：当订单状态为REFUNDING时，分页查询偶发返回重复数据；回归用例：按状态REFUNDING查询，断言结果集中订单ID无重复”，然后用Embedding模型转成向量存入pgvector。智能体在执行生成前，先按“当前接口名+业务关键词（分页、状态过滤、金额边界）”做一次相似度检索，取Top 5最相似的历史用例作为上下文。

这个机制的价值不在于让模型“抄作业”，而在于把已有的团队经验沉淀成模型可检索的结构化资产。很多测试团队的历史用例其实很值钱，但都躺在仓库里没人用，RAG是把这部分资产激活的最直接方式。

6. 平台、框架、自研怎么选：适合不同团队的落地建议

最后聊选型。测试用例生成智能体的技术栈选型，市面上有可视化平台、开源框架、自研方案三条路，很多人纠结，我直接给一套判断标准。

6.1 三类方案的优劣势对比

我的建议是：第一次做智能体，不要直接选“最强”的，而是选“最快能看到完整闭环”的。Dify这类平台能把模型编排、工具调用、知识检索、可视化调试一把梭，非常适合先验证你的流程设计是否成立。我当时就是从Dify起步的，整个闭环跑通只花了一天半，如果直接上代码型框架，这个时间至少翻一倍。

等闭环跑通，并且明确了“平台限制了我的发挥”的具体点，再迁移到代码型框架。比如你发现平台自带的工具节点不够灵活，无法自定义覆盖率解析逻辑；或者你发现多智能体协作在平台上只能按固定工作流走，没法动态路由——这些就是迁移代码型框架的信号。

6.2 我踩过的选型教训：先问“数据在哪里”，再问“模型用哪个”

确定选型时有一个很容易被忽略的因素：你的代码仓库和测试数据到底在哪里。如果是内网部署的GitLab，代码不能出内网，那么Dify在线版或云端大模型API就要谨慎，这时候要么用本地部署的Dify社区版，要么用Hermes这类本地运行时再接私有化模型。

我建议把所有智能体涉及的数据流都画出来，包括接口定义、源码摘要、历史用例、覆盖率报告，然后挨个问：这份数据能不能出当前网络？什么环节必须内网完成？把这个边界画清楚之后，选型范围一下就缩小了。

模型选择上，jq测试代码生成任务，我对GLM-4-Plus、DeepSeek-V3、GPT-4o、Claude都试过，一个直觉：生成函数级测试代码时各家差异不大，差异大的是“是否严格遵守JSON Schema输出”和“多轮反馈时能否不乱改已有用例”。你可以拿一个自定义的“结构化输出符合率”指标去快速评测，针对你的具体接口跑20轮，统计JSON解析失败率，哪个模型低就用哪个。

6.3 落地节奏建议：先窄后宽，先单接口后全模块

最后给一个落地的节奏参考。不要一上来就规划“全公司所有接口自动生成用例”，而是选一个核心模块的3到5个接口做试点，跑通完整链路，定好用例质量标准、覆盖率门槛、人工评审流程，再逐步扩大。我在订单模块的试点中总结了一个“三个一”：

• 第一周：只做一个接口，跑通从“输入定义”到“用例入库”的完整闭环，哪怕只覆盖最核心的5个正常场景；
• 第二周：扩到一个模块的10个接口，重点验证反馈循环和覆盖率门槛是否稳定；
• 第三周：把历史用例和缺陷库接进RAG，验证召回质量，同时把用例评审流程固化到团队日常协作里。

每增加一层能力，都要回看“是否解决了实际痛点”。比如我做完RAG接入后，明显感受到“模型开始记得历史缺陷”，就值得固定下来；而GNN虽然听起来酷，但现阶段对大多数团队并不是第一优先级，我更建议先把RAG和覆盖率反馈做扎实，再做结构感知的增强。

这个项目的最终成果，不是那20条订单接口用例，而是把“测试用例生成”从一个拍脑袋的灵感，变成一套有输入、有工具、有验证、有记忆的系统工程。如果让我总结一条最值得分享的经验，那就是：智能体最重要的是闭环，生成得再漂亮，不执行、不验证、不修正，就只是花架子。先把闭环跑通，再谈技术栈的“豪华程度”。