三层智能体架构
在企业环境中，测试用例生成不是"写几条文本"的问题，而是：
-
如何精确读取数据库需求
-
如何稳定生成结构化用例
-
如何保证结果可控
-
如何嵌入现有系统
-
如何控制生产风险
目录
-
问题定义：企业真正要解决什么
-
为什么纯 RAG 不可持续
-
三层智能体架构设计
-
数据访问层：SQL Agent 实现（含代码）
-
规则生成层：Case Agent 实现（含代码 ）
-
约束校验层：结果控制机制
-
与现有系统的集成方式
-
什么时候不适合使用智能体
-
生产环境风险控制
-
测试工程师能力演进趋势
一、问题定义：企业真正要解决什么
典型企业场景：
-
需求沉淀在关系型数据库
-
需求数量大、更新频繁
-
测试用例需结构化输出
-
需要自动入库
-
不希望重构现有系统
本质问题是：
构建一条自动读取 → 自动生成 → 自动校验 → 自动入库的稳定链路。
二、为什么纯 RAG 不可持续
常见做法：
-
文档向量化
-
RAG 召回
-
直接生成用例
现实问题：
-
文档是模糊数据
-
每次生成结果不同
-
难以保证覆盖率
-
无法精确字段过滤
数据库中的数据是精确数据。
所以架构必须围绕数据库设计，而不是围绕文档设计。
三、三层智能体架构设计
系统拆分为三层：
-
数据访问层（SQL Agent）
-
规则生成层（Case Agent）
-
约束校验层（Validator）
整体架构：
三层职责：
-
第一层保证数据精确
-
第二层负责生成逻辑
-
第三层控制风险
四、数据访问层：SQL Agent 实现
1. 定义结构化返回模型
from pydantic import BaseModel
from typing import List, Any
class SQLResult(BaseModel):
sql: str
explanation: str
data: List[Any]设计原则：
-
强制结构化输出
-
禁止自由文本
2. 构建 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解释
- 查询结果
"""3. 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 实现
1. 定义用例结构
class TestCase(BaseModel):
title: str
steps: List[str]
expected: str
class CaseResult(BaseModel):
cases: List[TestCase]2. 构建 Case Agent
@agent(
model=deepseek_model,
result_type=CaseResult
)
def case_agent(requirements: list):
return f"""
根据以下需求生成测试用例。
规则：
1. 输出JSON
2. 包含正常流程与边界场景
3. 每条用例包含title, steps, expected
4. 不生成无关内容
需求：
{requirements}
"""3. 用例生成图
这张图体现：
-
智能体协作
-
数据流向
-
可替换结构
六、约束校验层
@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 校验
-
敏感数据脱敏
-
日志隔离
-
批量限流
智能体不是风险来源。 缺乏约束才是。
十、测试工程师能力演进趋势
未来测试工程师的核心能力：
-
数据结构理解
-
智能体设计能力
-
校验机制构建能力
-
架构思维
真正的竞争力不是写多少脚本。
而是：
是否能设计一个可控、可扩展、可验证的智能体系统。