AI 友好型应用开发实践：环境管理升级

Mr.Sun2026年3月27日...大约 6 分钟

AI 友好型应用开发实践：环境管理升级

TL;DR 通过将传统 10+ 张表的多表级联架构升级为 2 张表 + JSON 存储，环境管理系统的 AI 交互效率大幅提升。这套"AI 原生设计"思路适用于所有需要 AI 深度参与的平台。
关键词： AI 友好性 | JSON 存储 | 扁平化架构 | 测试自动化

🔑 核心要点速览

改进项	传统方案	新方案	提升
表数量	10+ 张	2 张	↓ 80%
环境创建	5+ 步操作	1 步完成	效率 ↑
配置生成	分钟级	秒级	速度 ↑
AI 错误率	频繁出错	降低 80%	质量 ↑

一、背景：传统架构遇上 AI Agent

在自动化测试领域，环境管理一直是个复杂问题。传统的测试环境管理系统通常采用多表级联设计：

┌─────────────┐     ┌─────────────┐     ┌─────────────────┐
│   环境主表   │────▶│   配置表    │────▶│  仪表关联表      │
└─────────────┘     └─────────────┘     └─────────────────┘
        │                                      │
        ▼                                      ▼
┌─────────────┐                         ┌─────────────┐
│  历史记录表  │                         │   仪表表     │
└─────────────┘                         └─────────────┘
        │
        ▼
┌─────────────┐
│  变更日志表  │
└─────────────┘

这种设计在人工操作时代尚可接受，但当引入 AI Agent（如 TSE Agent）来辅助环境管理时，问题暴露了。

二、痛点分析：为什么不 AI 友好？

2.1 AI 需要理解复杂的外键关系

-- AI 需要生成的复杂 SQL
SELECT e.*, c.*, i.*, h.*
FROM environment e
JOIN config c ON e.id = c.env_id
JOIN instrument_relation ir ON e.id = ir.env_id
JOIN instrument i ON ir.instrument_id = i.id
LEFT JOIN history h ON e.id = h.env_id
WHERE e.status = 'active'
AND e.test_type = '5G_NR';

问题：

AI 需要理解多张表的外键关系
生成 SQL 容易出错
查询性能随数据量下降

2.2 配置生成需要多步操作

传统方式：AI 需要分步生成
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ 第1步   │───▶│ 第2步   │───▶│ 第3步   │───▶│ 第4步   │
│ 生成环境 │    │ 生成配置 │    │ 生成仪表 │    │ 维护外键 │
└─────────┘    └─────────┘    └─────────┘    └─────────┘
     ↑              ↑              ↑              ↑
   易出错         易出错         易出错         易出错

2.3 扩展困难，删除有风险

新增环境类型 → 需要增加表或字段
删除环境 → 需要级联清理多张表，易产生脏数据
恢复环境 → 几乎不可能

三、新方案：扁平化 JSON + 少量核心表

3.1 架构对比

传统方案                          新方案
┌──────────────────┐             ┌──────────────────┐
│  10+ 张表        │             │  2 张表 + JSON    │
│  外键层层嵌套    │    ───▶     │  数据自包含      │
│  关系复杂        │             │  结构扁平        │
└──────────────────┘             └──────────────────┘

3.2 表结构设计

-- 环境配置表（存储环境定义）
CREATE TABLE environment_config (
    id BIGINT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    config_json JSON NOT NULL,  -- 完整的环境配置
    schema_version VARCHAR(50),
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);

-- 环境实例表（存储运行时状态）
CREATE TABLE environment_instance (
    id BIGINT PRIMARY KEY,
    config_id BIGINT,
    status VARCHAR(50),  -- active/inactive/deleted
    runtime_json JSON,   -- 运行时状态
    created_at TIMESTAMP,
    last_used_at TIMESTAMP
);

3.3 JSON 结构示例

{
  "environmentName": "5G NR 测试环境",
  "testType": "射频性能测试",
  "description": "用于 5G NR 射频性能验证",
  
  "instruments": [
    {
      "type": "频谱仪",
      "model": "FSW43",
      "ip": "192.168.1.100",
      "port": 5025,
      "calibrationDate": "2026-03-01"
    },
    {
      "type": "信号源",
      "model": "SMW200A",
      "ip": "192.168.1.101",
      "port": 5025,
      "powerRange": "-130 to 20 dBm"
    }
  ],
  
  "signalParams": {
    "frequency": 3.5e9,
    "bandwidth": 100e6,
    "modulation": "256QAM",
    "subcarrierSpacing": 30e3
  },
  
  "limits": {
    "evm": 0.03,
    "aclr": -45,
    "sem": -25
  },
  
  "metadata": {
    "createdBy": "TSE Agent",
    "createdAt": "2026-03-27T10:30:00Z",
    "version": "1.0"
  }
}

四、如何支撑 AI "直接生成和管理"

4.1 AI 直接生成完整配置

传统方式：5步操作
┌────┐  ┌────┐  ┌────┐  ┌────┐  ┌────┐
│步1 │─▶│步2 │─▶│步3 │─▶│步4 │─▶│步5 │
└────┘  └────┘  └────┘  └────┘  └────┘

新方式：1步完成
┌─────────────────────┐
│  AI 一次性生成完整   │
│  JSON，直接存入     │
└─────────────────────┘

代码对比：

# 传统方式：AI 需要分步生成
env_id = create_environment("5G NR 测试环境")
config_id = create_config(env_id, {...})
instrument_ids = create_instruments(env_id, [...])

# 新方式：AI 一次性生成完整配置
config = {
    "environmentName": "5G NR 测试环境",
    "testType": "射频性能测试",
    "instruments": [...],
    "signalParams": {...}
}
save_environment(config)  # 直接存入 JSON 字段

4.2 AI 直接查询与理解

-- 简单查询：AI 只需单表操作
SELECT runtime_json FROM environment_instance 
WHERE status = 'active';

-- 搜索特定仪表的环境
SELECT * FROM environment_instance 
WHERE runtime_json->'instruments' @> '[{"model": "FSW43"}]';

4.3 环境恢复与克隆

-- 删除（软删除）
UPDATE environment_instance SET status = 'deleted' WHERE id = 123;

-- 恢复（一键恢复）
UPDATE environment_instance SET status = 'active' WHERE id = 123;

-- 克隆（复制环境）
INSERT INTO environment_instance (config_id, status, runtime_json)
SELECT config_id, 'active', runtime_json 
FROM environment_instance WHERE id = 123;

五、量化收益

5.1 详细对比

维度	传统方案	新方案	提升
表数量	10+ 张	2 张	↓ 80%
环境创建	5+ 步	1 步	↑ 5x
配置生成	分钟级	秒级	↑ 60x
AI 错误率	频繁	降低 80%	↑ 质量
环境恢复	困难/不可逆	一键恢复	↑ 可靠性
代码量	数据访问层复杂	简化 60%	↑ 可维护性

5.2 收益总结

┌─────────────────────────────────────────┐
│  开发效率提升                             │
│  • 环境创建：5+ 步 → 1 步               │
│  • 代码量减少 60%                        │
│  • SQL 调试时间减少 70%                  │
├─────────────────────────────────────────┤
│  AI 交互效率提升                          │
│  • 配置生成：分钟级 → 秒级               │
│  • 外键错误降低 80%                      │
│  • AI 无需学习复杂表结构                 │
├─────────────────────────────────────────┤
│  系统可维护性提升                         │
│  • 表数量：10+ → 2                       │
│  • 无需数据库迁移                         │
│  • 支持一键恢复已删除环境                │
└─────────────────────────────────────────┘

六、启发与推广

这套设计思路适用于所有需要 AI 深度参与的平台：

项目类型	借鉴点	预期收益
配置管理平台	用 JSON 替代多表存储	AI 直接生成/优化配置
设备资产管理	统一 JSON Schema	AI 可跨设备类型分析
测试任务管理	参数、步骤、结果用 JSON	AI 一键生成复杂任务
运维工单系统	工单详情用 JSON 存储	AI 自动生成处理方案

七、设计原则总结

核心原则

1️⃣  AI 原生优先
    └── 让 AI 能够直接读、写、理解数据
    
2️⃣  数据结构扁平化
    └── 用 JSON 替代复杂关系模型
    
3️⃣  状态驱动而非操作驱动
    └── 记录状态变化，支持回滚和恢复

实施建议

渐进式迁移
- 新功能采用新方案
- 老功能逐步迁移
- 保持双向兼容
JSON Schema 管理
- 定义清晰的 Schema 规范
- 提供 Schema 验证工具
- 支持版本升级
查询优化
- 合理使用 JSON 索引（GIN）
- 避免过度嵌套
- 定期清理历史数据

八、技术栈推荐

组件	推荐技术	说明
数据库	PostgreSQL	JSONB 支持完善
查询语言	SQL + JSON 路径	强大而灵活
索引策略	GIN 索引	加速 JSON 查询
验证工具	JSON Schema	规范验证

结语

当系统需要 AI 深度参与时，数据结构的 AI 友好性应该成为首要考虑因素。

传统的关系型数据库设计虽然严谨，但在 AI 交互场景下反而成为障碍。通过采用扁平化 JSON 存储，我们不仅简化了系统架构，更重要的是让 AI 能够更自然、更高效地与系统交互。

💡 核心洞察： AI 友好的架构不是让 AI 适应系统，而是让系统适应 AI。

欢迎交流讨论！

如果你也在学习 AI Agent，欢迎交流讨论，我的 blog：https://sunrong.site

贡献者

Sun RongSunRong sunrong1 sunrong