企业官网建设流程全解析

在软件测试这条路上干久了，你会慢慢发现一个特别磨人的活儿：写测试用例。业务逻辑稍微复杂一点，用例动辄几百条，还得分正向、反向、边界、异常，每次迭代需求一变，用例就得跟着改一版。所以当“测试用例生成智能体”这个概念出现时，我的第一反应不是“这玩意儿能有多聪明”，而是“它能不能把我从这堆苦力活里捞出来”。这几个月我实打实做了一个测试用例生成智能体，从技术选型到落地部署走了一遍，踩了不少坑，也把整套技术栈摸清楚了。这篇文就是把我自己这一路的思路、选型、实现细节和排错记录拆开来讲，不说虚的，全是能直接拿去用的东西。

我判断这类工具最适合三类人：一是被重复用例编写折磨的测试开发工程师，二是想用AI Agent切入实际业务场景的算法工程师，三是负责质量平台建设、需要快速做技术预研的技术负责人。这篇文章会沿着“需求拆解 → 架构设计 → 技术选型 → 核心实现 → 部署落地 → 复盘扩展”这条路走，看完你至少能搞清楚一个智能体项目从头到尾要碰哪些技术栈，遇到问题该怎么排。

1. 项目背景与整体设计思路

1.1 核心需求拆解：我们要解决什么问题

先把这个项目的源头说清楚。我在做的这个测试用例生成智能体，核心目标只有一个：让AI根据需求描述自动生成结构化的、可评审的、覆盖度合格的测试用例。听起来简单，但真上手做的时候发现需求本身是层层嵌套的。

你光说“帮我生成测试用例”是不够的，得先搞清楚用户到底在什么场景下用这个工具。我梳理下来主要有三类高频场景：

• 场景一：迭代需求快速出用例。产品经理把需求文档丢过来，测试同学要在半天内出第一版用例，以前是开会讨论、翻原型、对着流程图慢慢磨，现在希望AI能先把初稿跑出来，人工只做增量评审。
• 场景二：接口字段级用例兜底。后端接口改动频繁，字段校验、必填项、长度限制这类用例最容易漏，团队希望AI能根据接口定义自动补全边界用例。
• 场景三：老系统回归用例重建。有些系统文档严重缺失，只有线上代码和数据库能看，测试同学希望AI帮忙从代码逻辑里反推核心用例，降低漏测风险。

这个智能体的核心能力就三块：理解需求、拆解场景、生成结构化用例。至于“怎么理解需求”，原理想起来很直观：把需求文本交给大模型，让它先做实体识别和动作抽取，再结合我们设计的测试模型（后面会详细讲）去映射边界条件和异常路径。但落地的时候你会发现，光靠提示词很难稳定输出高质量结果，必须搭配流程编排和数据约束，这就是为什么不能只写一个Prompt就完事，而是要做成一个Agent。

1.2 整体架构：四层模型加一条主链路

这个项目的整体架构我划分成四层：接入层、编排层、生成层、数据层。

• 接入层：负责对接用户输入，可能是自然语言描述、接口文档（OpenAPI/Swagger）、前端页面操作流，甚至是一段Excel用例模板。这一层最关键的是格式归一化，不然大模型会被各种输入格式带偏。
• 编排层：这是Agent的核心调度区，负责管理整个用例生成的流程状态，包括意图识别、需求拆分、生成任务分发、结果校验和反馈迭代。我用的是Dify来搭这个编排层，因为它自带完整的工作流设计器，还支持多智能体模式的节点编排。
• 生成层：真正调用大模型去产出用例内容的层，同时也是插件的宿主区。我们会让一个“主写手”Agent负责生成用例主流程，再让几个“检查官”Agent分别做需求覆盖度检查、边界值补全、用例格式校验。
• 数据层：存三样东西：项目元数据（比如用例模板、历史用例）、测试知识库（比如业务规则、常见错误模型）、向量化后的历史需求与用例片段，用来做RAG检索。

主链路是：原始需求 → 归一化文本 → 需求拆分 → 场景识别 → 用例生成 → 规则校验 → 人工评审 → 导出。这条链路上每一步都可能出错，后面第三部分我会针对每一步详细写实现细节。

这个架构一开始看起来有点重，但对生产级工具来说，这套分层是必须的。如果只在单一Prompt里堆逻辑，你会发现生成结果的质量方差极大，偶尔一次惊艳、经常一次崩坏，根本没法交给测试团队用。编排层和数据层就是来把“AI偶尔聪明”变成“AI稳定可用”的。

1.3 立项时踩的第一个坑：目标收敛

这里必须先说一个很亏的经验。我第一版的时候野心很大，想让智能体支持“从需求文档自动生成接口测试代码”，还想着顺便把UI自动化脚本也生成了。结果开发到一半发现，这个目标太大了，范围控制不住，每天都有新的场景要适配。

后来我把目标收敛成一句话：“先做从需求文本到可评审的功能测试用例，接口和UI代码生成放到第二阶段”。这个收敛非常关键，它决定了整个项目技术栈的轻重：如果要做代码生成，你就得接编译器、AST解析、代码执行沙箱；如果只是生成用例文本，核心就是大模型输出控制、结构化校验和知识库检索。技术与组织复杂度完全不是一个量级。

所以如果你是第一次做这类智能体，我强烈建议目标越窄越好。宁可用一个准确的爽快的单点能力，也不要一个什么都能做但什么都做不稳的通用Agent。

2. 技术栈选型与关键组件对比

这应该是很多人最好奇的部分。测试用例生成智能体到底涉及哪些技术栈？最热搜的那些词——Dify、Hermes智能体、图神经网络、向量数据库、MCP——到底在项目里扮演什么角色，我一个个说。

2.1 智能体框架：为什么我最终选了Dify

现在智能体框架多到眼花缭乱，LangChain、AgentScope、Coze、Dify、Hermes、自研框架都有。我先把框架分个类：

• 代码优先框架：LangChain、LlamaIndex、AgentScope这类，灵活度最高，但开发量大，调试链路易碎，适合团队本身就强，想要最大限度控制细节。
• 平台化低代码平台：Dify、Coze这类，提供可视化画布、内置知识库、工具插件、日志追踪，适合快速搭建Agent应用，落地周期短。
• 垂直领域智能体套件：比如Hermes这类偏向于某个特定运行环境或行业场景的套件，部署起来更重，但对特定环境支持更好。

我的选型结论是用Dify作为编排层的核心，原因有四点：

第一，接入成本低。团队里不是所有人都是算法背景，用可视化工作流搭建可以让测试人员也参与到Agent调试中来，这种跨角色协作的价值在落地期特别关键。

第二，内置RAG和大模型接入。Dify自带知识库管理和检索逻辑，不用自己从头写向量召回和混排，对测试知识库这种有明确范围的内容特别合适。

第三，多智能体编排能力。Dify的工作流节点里可以同时挂多个LLM节点，天然支持“主写手Agent + 评审Agent + 修正Agent”这种协作模式。

第四，部署可控。Dify可以私有化部署，这对企业内部数据安全要求来说基本是必选项。测试用例往往涉及业务核心逻辑，不可能全丢给外部SaaS。

当然Dify也有坑，比如它对很复杂的循环迭代支持得不够优雅、部分自定义Python节点性能一般。但这些在测试用例生成场景里都是可以接受的，因为核心瓶颈不在框架，而在大模型指令遵循和业务规则沉淀。

2.2 Hermes智能体在项目里到底用在哪

很多朋友搜到“Hermes智能体”这个词，特别容易误以为是同一个东西。实际上Hermes在市面上至少有几类：有开源对话智能体项目，也有面向企业级服务集成环境的智能体中间件，还有的就是拿来做部署壳层的工具。

在我这个项目里，一套相对完整的部署方案是采用Hermes智能体作为企业环境的运行容器或通信中间层。具体说，当系统需要对接医院集成平台这类偏传统的枢纽系统时，测试用例生成智能体需要去拉取真实的接口调用链数据、查看历史报文样例，而这些数据往往被封在一个内网集成引擎里。这时候不能直接让Dify去对接，中间就需要一个能适配多种集成协议的智能体或适配器，Hermes这类组件就比较合适，它擅长将不同格式的接口协议转换成标准化的数据模型。

但如果你只是做一个内部小工具，不接这种老系统，Hermes完全可以不引入。它属于“锦上添花”或者“系统集成刚需”，不是测试用例生成Agent的必备组件。很多人被热搜带偏，以为做Agent必须来一套Hermes，其实不是。

2.3 前端技术栈：选React而不是别的，原因很实际

提到“前端技术栈”，做智能体的人第一反应往往是“Agent服务端不是核心吗，前端随便写个页面就行”。但实测下来，前端体验直接决定了这个工具能不能在团队里用起来。如果只是给个黑框对话框，测试人员根本不愿意用；如果有个结构化的用例评审页面、批量导出、覆盖度看板，那接受度会完全不同。

我这边前端技术栈选了React。原因挺实际的：

• 团队现有储备里React的生态最熟，组件库用Ant Design，表格、表单、树形控件都很齐全，适合做后台管理系统风格的产品；
• 用例展示场景需要大量可交互组件，比如树形场景树、标签式属性编辑器、批量勾选操作，React生态里对应的组件成熟度高；
• React对后端工程师也比较友好，心智模型简单，短期内能上手写出可维护的代码。

如果从头再选一次，我还是会选React，但对于更轻量的场景，直接用Dify自带的前端页面也未尝不可，完全可以等验证了业务价值之后再投入开发前端。

2.4 图神经网络和向量数据库：热搜词里的两把刀

先说图神经网络。很多人看到“图神经网络 测试用例生成”会觉得这是必用的AI技术，但实际项目里，图神经网络不是地基，而是针对特定场景的“增强武器”。

在什么场景需要？我举个例子：当被测系统的业务非常复杂，接口A会异步触发接口B和C，B又会根据条件触发D，这时我们想生成“订单流转类”用例，单纯靠大模型的上下文理解，很难100%准确抓住这棵调用链树。图神经网络可以基于历史调用日志学习到接口间的依赖关系和调用概率，输出一张接口依赖图，再把这张图作为外部知识灌给大模型做生成的约束。

但我们第一版没做图神经网络，因为数据积累不够，硬上一个模型效果反而不如直接把接口调用链文本拼进Prompt里。所以我的真实建议是：先整RAG和结构化检索，图神经网络只在你有足够日志数据和明确场景时再考虑。不要因为热搜词去加一个复杂模型，项目复杂度是会滚雪球的。

向量数据库则是另一回事。它在智能体里的定位很明确：存储非结构化知识，供RAG检索使用。测试场景里，历史用例片段、需求文档、Bug描述、业务规则，这些都无法用结构化表结构完美表达，必须做向量化。

常见的向量库选型有Milvus、Qdrant、Chroma、pgvector等。我最终用的是Milvus，因为它对高并发检索、过滤条件、混合检索的支持比较稳，而且可以和Dify的知识库做集成。不过如果你只是个人项目或者数据量极小，先用Chroma或pgvector存着完全够用，不用一上来就上分布式向量库。关键是先跑通链路，再考虑容量。

2.5 MCP：让智能体有手有脚的接口标准

MCP（Model Context Protocol，模型上下文协议）也是最近特别火的一个词。它的本质是给大模型和外部工具之间定一个标准化的接口协议。

在测试用例生成智能体里，MCP最典型的用法是：当Agent需要读取线上接口定义或查询历史缺陷库时，它可以通过MCP客户端去调用对应的工具服务，比如“查询缺陷管理系统”“获取接口Schema”“查询配置中心参数”。标准协议保证了大模型不用为每个服务写一套私有调用方式，就像给Agent接上了一个标准USB口，什么工具服务符合协议都能插上来用。

我在项目里给Agent接了一个MCP工具集，包括：获取需求详情、查询历史用例、查询Bug分布、解析接口文档、读取配置项。这几个工具让Agent不只是“闭着眼睛写用例”，而是能真正“看到”项目上下文再下笔。MCP的唯一麻烦在于，企业内部系统不一定都实现了MCP服务端，很多老接口需要你自己封装一层Adapter，这块工作量得提前预估。

3. 测试用例生成核心实现：从需求文本到可执行用例

这一部分是整个项目里最花精力、也最体现技术含量的环节。我按照主链路拆成四个关键模块来讲。

3.1 提示词工程与需求解析：先让Agent听懂人话

AI生成测试用例的第一步不是“生成”，而是“理解”。如果第一步的理解是错的，后续所有内容都是空中楼阁。

我用的是“结构化解构 + 多轮填充”的方式，而不是一次性地把整个需求扔给大模型让它直接输出用例。具体流程是：

1. 先让Agent对需求文本做实体识别，提取出用户角色、操作动作、业务对象、核心流程、约束条件这五类关键要素。
2. 再让Agent根据这些要素生成一版“需求理解摘要”，并要求它标注出所有识别到的边界信息和潜在异常点。
3. 由“需求校验Agent”检查摘要是否遗漏关键要素，如果遗漏，触发补充提问流程，让用户或系统自动补全信息。
4. 确认摘要完整之后，才进入用例生成阶段。

这一步的效率提升主要来自Prompt模板的设计。我们设计了一套短模板嵌套机制，每一类要素单独用小模板让Agent输出，最后再拼接成整体。比如角色提取模板约束它只输出“用户、管理员、第三方系统”等标准化角色，动作提取模板约束它只输出“新增、修改、删除、查询、导入、导出、审批”等标准动作。标准化的输出约束非常重要，它决定了后面的场景识别能否自动化。

经验值在这里：我第一版直接让大模型“生成一份测试用例”，结果它经常把需求的系统名称想当然地写错，甚至自行脑补不存在的流程细节。加了结构化摘要和校验Agent之后，输出质量明显稳定了。

3.2 场景识别与用例生成算法：用测试设计方法做映射

需求理解完，接下来要做的是场景识别。如果把需求拆解成“角色 + 动作 + 对象 + 条件”，场景识别的本质是回答“这个动作在什么条件下会产生什么样的预期结果”。

我把测试设计方法做了一层映射规则：

这套映射规则不是硬编码到代码里，而是放到Prompt里作为生成约束，让大模型根据识别的场景自动选择合适的测试方法来生成用例。当然，为了让规则更可复用，我也用结构化JSON把规则定义放到了知识库里，方便后续迭代。

大模型生成用例时，我会给它一张统一的输出Schema，包括：用例编号、用例标题、前置条件、测试步骤、测试数据、预期结果、优先级、用例类型。这个Schema就是连接AI输出和后续人工评审、自动化执行的桥梁。如果输出不用固定Schema，后面做用例管理和统计就会非常痛苦，这一点务必提前想好。

3.3 向量检索与知识增强：让Agent带着历史经验干活

测试用例生成有个很反常识的地方：同一个需求，老手测试和AI新手生成出来的用例质量差异，很大程度上来自经验而非逻辑能力。老手知道这个模块之前出过什么样的线上Bug，知道某些字段虽然文档没写但实际是必填的。这种经验沉淀在历史用例和Bug库里，是我做知识增强的核心数据源。

我把项目中的历史用例、Bug单、常见异常清单、业务规则文档全部处理后存入向量知识库，在Agent写用例之前先做一轮检索，把最相关的历史知识作为上下文注入。这一步的效果非常直观：

• 历史缺陷会告诉Agent：“这个金额字段曾经允许输入负数导致对账异常，生成用例时请包含负数校验”。
• 历史用例会告诉Agent：“这个页面的新增功能和编辑功能共用一套校验逻辑，上次编辑漏了必填校验，这次要特别注意”。

不过向量检索不是完美的，它可能召回一些噪声内容，反而干扰生成。我在实践里加了两个控制：一是检索结果只取TopK相关片段并限定时长，二是单独设置一个“知识引用”字段，让Agent在引用历史经验时注明依据，方便评审人员追溯。

很多文章会强调RAG的召回率、准确率，但在这个场景，我更看重召回内容对生成用例的增益度。如果检索回来的知识和大模型已有能力差不多，那说明检索链路并没有真正发挥作用，需要重新检查分块策略和查询改写逻辑。

3.4 数据集设计与评测方法：怎么衡量智能体好不好

聊到“AI生成测试用例的数据集怎么设计”，这是很多想复现这个项目的人会卡住的地方。数据集不是拿来看的，是拿来验证和迭代的。

我设计了三层数据集：

• 评估集（Eval Set）：包含50-100个标注好的“需求-理想用例集”对。标注时由两名高级测试工程师独立编写用例，再合并去重，作为Ground Truth。评估指标包括：用例覆盖率（生成的用例覆盖了多少个Ground Truth场景）、精确率（生成的用例中有多少条是合理可执行的）、无效率（完全无法执行的用例占比）。
• 回归集（Regression Set）：覆盖典型业务模块的题目，每次Prompt或知识库改动后跑一遍，确保不出现“改好一个地方、弄坏一片场景”的回退问题。
• 对抗集（Adversarial Set）：专门放一些容易让大模型犯错的题目，比如需求描述极其模糊、包含多种逻辑嵌套、或者输入文本里带有大量无关信息的情况。对抗集用来检验Agent的稳定性，看看它会不会被带偏。

数据集在开发过程中要持续扩充，尤其是把线上评审时人工修正过的用例逐步回流到数据集中。这其实就是把智能体当成一个持续学习的产品来运营，而不是交作业式地写一次代码就行。

在评测工具上，我直接用了一套轻量脚本，调用LLM API批量跑Eval Set，输出通过率、覆盖率维度，再人工抽检10-20条低分案例定位问题。评估一次完整数据集大约需要20到40分钟，整个过程可以自动跑，唯一需要人工的是分析失败样本并调整Prompt或知识库。

3.5 多智能体协作：评审Agent如何让用例质量跃升

很多人做AI生成测试用例，只做一个“生成”Agent，然后发现生成结果就像过山车，时好时坏。我后来引入了多智能体协作模式，才算把质量稳住。

我的实现是三个角色协同：

• 执行Agent（Executor）：负责主流程的用例生成，按前面说的流程输出初稿用例。
• 评审Agent（Reviewer）：负责审初稿，重点检查遗漏场景、前后置条件不完整、预期结果模糊、边界条件缺失。它会把问题逐条列出来，并标注严重级别。
• 修正Agent（Refiner）：接收评审意见，对初稿进行增删改，输出终稿用例。修正Agent必须逐条响应评审意见，不能直接跳过。

这三个角色的协作方式在Dify里就是三个LLM节点串联，非常简单。但有几个细节要特别注意：

• 三个角色如果都用同一个大模型（比如同一个GPT-4或同一个Qwen），会有“自己审自己”的倾向，修正效果会打折扣。建议至少让评审Agent的模型和生成Agent的模型有差异，比如一个用大参数模型、一个用较小但速度快的模型。
• 评审Agent的输出要结构化，比如输出“问题编号、问题描述、涉及用例编号、严重级别、修改建议”，这样修正Agent才能准确对应处理。
• 协作轮次建议控制在两轮以内。我曾试过让它们无限循环迭代，结果成本飙升且收益迅速衰减，第二轮之后的修改基本是在给句子斟字酌句，测试用例内容已经没有实质变化了。

引入多智能体后，我的Eval Set覆盖率从68%提升到了82%，精确率也提高了约10个百分点。这个增益的核心其实不在“多个Agent”本身，而在“把评审这个动作拆分成了一个不会漏掉单一环节的独立步骤”。人工作业时我们也是这么做的，只不过AI让它跑得更快、更稳定。

4. 部署落地与问题排查实录

智能体开发完，真正的考验才开始：部署上线。尤其是要跑在Windows服务器上、或者要对接企业既有的集成平台时，那真是问题一个接一个。

4.1 部署架构与Windows环境适配

我们最终采用Docker Compose来部署智能体后端，包括Dify服务、向量数据库、目标大模型的网关。不过有不少企业内部环境是Windows Server，Docker支持相对较弱，这时候就需要单独考虑Hermes这类组件的部署方式。

如果你要在Windows系统上部署Hermes智能体，我建议区分两种情况：

• 如果Hermes只承担轻量通信Agent角色，可以直接以服务方式运行，用NSSM这类工具把启动命令注册成Windows服务，故障时能自动拉起。
• 如果Hermes需要承担较重的AI推理或大规模消息处理，建议还是用WSL2或Docker Desktop来跑Linux容器，性能损耗可控且生态环境更接近生产环境。

另外，Windows环境部署还有两个容易踩的坑。一个是路径分隔符和中文编码，配置文件里路径写成反斜杠有时能跑、有时又出问题，解决方案是全部统一用正斜杠并在启动脚本里强制UTF-8编码。另一个是防火墙和端口映射，Agent要回调内部接口时，经常因为出网白名单限制导致调用超时，这个必须在部署前就和网络管理员确认好。

4.2 常见问题速查与排查案例

我把实际运行中遇到的典型问题整理成一张速查表，方便后面的人直接对号入座：

一个印象最深的排查过程是“OPC连接失败”问题。当时Agent需要从集成平台上拉取接口调用日志，但中间通过OPC连接时总是超时。我一开始以为是代码问题，后来用抓包工具一看，才发现是OPC服务器侧的连接空闲超时设置太短，长任务还没执行完连接就被断掉了。解决方式是在OPC连接参数里把KeepAlive间隔调小，同时把Agent端的超时时间从10秒放宽到30秒。这个问题如果不看报文，纯查代码真的查不出来，所以遇到集成类问题，一定要先看链路层和后端日志，别先在业务代码里大海捞针。

还有一个我在IDEA和命令行里反复踩过的坑：JDK版本不一致导致代码里用的某些语法编译不通过，但IDE和服务器却表现不同。最后我强制在构建脚本里指定JDK路径和版本参数，并写了统一的Java环境初始化脚本，问题才彻底解决。这也是为什么我特别强调在Windows部署时要先把基础运行时环境统一好，不然后续排查成本会成倍增加。

4.3 面对业务方：怎么把“技术栈有哪些”说清楚

有段时间“医院集成平台涉及技术栈有哪些”这类搜索特别多，其实背后是一类普遍需求：业务方或刚接手的新人要快速搞清楚一个老系统整条技术栈全貌，才好评估改造或接入成本。

就拿医院集成平台举例，一套典型的平台技术栈通常包含四层：

• 集成引擎层：核心是类似OPC、连接适配器、消息路由、报文转换服务，它的作用是把分布在不同科室系统中的数据统一汇聚和转发。
• 数据层：包括主数据管理、共享文档库（类似CDA）、数据仓库，还有近年引入的向量化知识库，用于支持检索和AI应用。
• 接口协议层：涵盖HL7、FHIR、REST/JSON、WebService等。很多老系统还是WebService，新系统则普遍支持FHIR。
• 管理运维层：包括监控平台、日志中心、API网关、统一调度管理。

你去看这类平台的智能体改造，其实也就是在原有技术栈上增加一层「智能体编排层 + 大模型网关 + 知识库」的旁路结构，不太需要重写底层引擎。“能说清楚技术栈”的关键不是背出一堆技术名词，而是能沿着一条“数据怎么从源头流到终端应用”的链路，把每一层用到什么技术说清。

这点对做测试用例生成智能体的人尤其重要。我后来给团队做培训时就总结出一个方法：拿一个业务单据（比如一次门诊请求）从头走到尾，画出一张包含“系统、接口、协议、数据格式、中间件”的最小链路图。只要能把这条链路讲通，技术栈的80%就算说明白了，剩下的就是各层再往深里展开。

5. 复盘与进阶：从Demo到产品级能力

做完了这轮项目，我最大的感触是：测试用例生成智能体在技术实现上并没有想象中那么高不可攀，真正的壁垒在于业务知识的沉淀和质量闭环的构建。最后分享几个我在复盘时梳理的关键点。

5.1 效果数据与调优经验：不是调一次就完事

上线运行两周后，我统计了一下智能体生成用例的数据：整体覆盖率达到91%，用例可执行率88%，平均生成时间从人工的2小时降到了5分钟，人工评审成本大约只需要原来的30%。这个结果确实称得上“实战可用”，但并不是白来的。

调优过程实际上经历了三个阶段：

第一阶段是Prompt调优。把一轮生成的Prompt改成“结构化摘要 + 多轮生成”，覆盖率提升最明显。第二阶段是知识库调优。把历史Bug和业务规则以更合适的粒度进行分块处理，边界用例的生成质量显著提升。第三阶段是多智能体协作调优。加入评审Agent和修正Agent后，无效用例比例下降了一半。

每个阶段结束都要重新评估，评估又反过来指导下一轮调优。这套闭环不能断，一旦断了，Agent质量会随模型版本或需求变化慢慢退化。

5.2 可复用的扩展方向：销售智能体、HR智能体、企业知识库

虽然我做的是测试用例生成智能体，但底层这套“编排层 + 大模型 + RAG + 多智能体协作”的架构，换一个行业场景就能复用到其他地方。

比如销售智能体，核心逻辑就是“从客户对话意图识别 → 匹配产品知识库 → 生成话术和跟进策略”。HR智能体则是“从岗位JD解析 → 匹配简历库和历史录用数据 → 生成面试题和评估维度”。它们和测试用例生成的共同点在于：都是基于特定领域知识库的生成任务，都需要结构化输出，也都需要人工评审闭环。

这时候你会明白，为什么那么多企业着急做“企业知识库”，并且会问到“AI智能体的企业知识库是存放在向量数据库中的吗”。答案是：通常是的，但不完全。企业知识库一般分成两类：一类是结构化数据（存在关系型数据库），另一类是非结构化文档（先切块、embedding，然后存入向量数据库）。智能体在回答问题时，首先从向量库检索相关片段，再结合结构化数据补齐上下文，最终综合给大模型参考。

所以做智能体项目，不要只盯着一个向量库，要提前规划好结构化数据和非结构化数据的双通道设计。否则等你把知识库接入到业务系统里，会发现大量查询逻辑要改写，那时候再来重构，成本已经很高了。

5.3 从React Client到Agent全家桶：前端和协议还要继续演进

最后再说一个容易被忽略的点。部署Agent之后，你会发现团队不可能人人用命令行或API去调用，还是需要一个前端操作界面，也就是前面提到的React Client。它不只是展示用例列表，还要能做评审勾选、标注修正原因、管理知识库版本、看各个模块的生成质量报表。这就和测试平台本身的功能越来越重合了。

我在设计前端时，直接把智能体输出和旧的测试管理平台对接了，让它生成完就自动导入到用例库中、打上“AI生成”的标签，人工评审后自动流转为正常用例。这一步节省了很大的人力，也提升了团队使用的接受度。

至于未来的协议演进，多Agent协作标准的成熟会让我们把生成、评审、修正这三件事进一步拆成独立服务，用标准协议互相通信。这样从测试用例生成出发，慢慢就能长出完整的企业智能体基础设施。

实测下来，我的真实感受是：这类智能体项目的门槛不在模型多强、框架多新，而在于你是否真的理解业务问题、能否设计出稳定的生产链路。把一个清晰的小场景（生成测试用例）做好，看起来只是解决一个点，但它迫使你把需求解析、知识增强、多智能体协作、部署运维这一整条链路都跑通一遍。这个过程沉淀下来的方法和经验，远比那几个“热搜词”值钱。