三层智能体架构
在企业环境中,测试用例生成不是“写几条文本”的问题,而是:
如何精确读取数据库需求
如何稳定生成结构化用例
如何保证结果可控
如何嵌入现有系统
如何控制生产风险
目录
问题定义:企业真正要解决什么
为什么纯 RAG 不可持续
三层智能体架构设计
数据访问层:SQL Agent 实现(含代码)
规则生成层:Case Agent 实现(含代码 )
约束校验层:结果控制机制
与现有系统的集成方式
什么时候不适合使用智能体
生产环境风险控制
测试工程师能力演进趋势
一、问题定义:企业真正要解决什么
典型企业场景:
需求沉淀在关系型数据库
需求数量大、更新频繁
测试用例需结构化输出
需要自动入库
不希望重构现有系统
本质问题是:
构建一条自动读取 → 自动生成 → 自动校验 → 自动入库的稳定链路。
二、为什么纯 RAG 不可持续
常见做法:
文档向量化
RAG 召回
直接生成用例
现实问题:
文档是模糊数据
每次生成结果不同
难以保证覆盖率
无法精确字段过滤
数据库中的数据是精确数据。
所以架构必须围绕数据库设计,而不是围绕文档设计。
三、三层智能体架构设计
系统拆分为三层:
数据访问层(SQL Agent)
规则生成层(Case Agent)
约束校验层(Validator)
整体架构:

三层职责:
第一层保证数据精确
第二层负责生成逻辑
第三层控制风险
四、数据访问层:SQL Agent 实现
- 定义结构化返回模型
from pydantic import BaseModel
from typing import List, Any
class SQLResult(BaseModel):
sql: str
explanation: str
data: List[Any]
设计原则:
强制结构化输出
禁止自由文本
构建 SQL Agent
@agent(
model=deepseek_model,
result_type=SQLResult,
dependencies=[db_connection]
)
def sql_agent(user_query: str):return f"""
根据以下数据库结构生成查询SQL。数据库结构:
{schema_info}用户请求:
{user_query}返回:
- SQL语句
- SQL解释
- 查询结果
"""
SQL 校验机制
@result_validator(sql_agent)
def validate_sql(result: SQLResult):forbidden = ["delete", "update", "insert", "drop"]
for word in forbidden:
if word in result.sql.lower(): raise ValueError("禁止写操作")if result.data is None:
raise ValueError("查询结果为空")return result
执行流程:

五、规则生成层:Case Agent 实现
- 定义用例结构
class TestCase(BaseModel):
title: str
steps: List[str]
expected: str
class CaseResult(BaseModel):
cases: List[TestCase]
构建 Case Agent
@agent(
model=deepseek_model,
result_type=CaseResult
)
def case_agent(requirements: list):return f"""
根据以下需求生成测试用例。规则:
- 输出JSON
- 包含正常流程与边界场景
- 每条用例包含title, steps, expected
不生成无关内容
需求:
{requirements}
"""
- 用例生成图

这张图体现:
智能体协作
数据流向
可替换结构
六、约束校验层
@result_validator(case_agent)
def validate_case(result: CaseResult):
if len(result.cases) == 0:
raise ValueError("未生成测试用例")
for case in result.cases:
if not case.steps:
raise ValueError("步骤不能为空")
if not case.expected:
raise ValueError("预期不能为空")
return result
校验层作用:
防止格式错误
防止空输出
保证结构完整
七、与现有系统集成方式
推荐方式:
封装 REST API
输入需求ID
返回 JSON
原系统入库

无需重构数据库。
八、什么时候不适合使用智能体
不建议使用场景:
需求数量极少
业务逻辑简单
已有稳定自动化规则
智能体适合:
需求规模大
规则复杂
更新频繁
需要批量生成
九、生产环境风险控制
必须增加:
数据库只读权限
SQL 白名单
JSON Schema 校验
敏感数据脱敏
日志隔离
批量限流
智能体不是风险来源。 缺乏约束才是。
十、测试工程师能力演进趋势
未来测试工程师的核心能力:
数据结构理解
智能体设计能力
校验机制构建能力
架构思维
真正的竞争力不是写多少脚本。
而是:
是否能设计一个可控、可扩展、可验证的智能体系统。