通用 SaaS 系统如何接入 AI Gateway：让你的业务系统拥有 AI 对话能力

用户说一句话 → 大模型理解意图 → 自动调用子系统 API 或执行运维命令 → 把结果用人话说回来。这是整个方案最核心的设计——用 YAML 配置文件代替代码开发。display_name: 查询订单description: "查询订单列表，支持按状态、时间范围、客户筛选"category: 订单管理executor: http # 业务 Toolstatus:description: "订单状

chenbo980

218人浏览 · 2026-03-01 10:18:38

chenbo980 · 2026-03-01 10:18:38 发布

一、痛点：为什么 SaaS 系统需要 AI 对话入口？

传统 B/S 系统的交互模式是"菜单 → 表单 → 按钮"。当系统功能越来越多，用户面临的问题也越来越明显：

操作路径深：查一个报表要点 5 层菜单
学习成本高：新员工需要培训才能上手
跨模块操作繁琐：一个业务流程涉及多个页面来回切换
运维排查低效：出了问题要登录服务器、翻日志、查指标，步骤多且门槛高

如果系统能像 ChatGPT 一样，用户输入一句话就能完成操作呢？

用户："帮我查一下今天所有异常订单"
AI：正在查询... 今天共有 3 笔异常订单：
    | 订单号 | 客户 | 异常原因 |
    | ORD-001 | 张三 | 支付超时 |
    | ORD-002 | 李四 | 库存不足 |
    | ORD-003 | 王五 | 地址无效 |
    建议：ORD-001 可自动重试支付，ORD-002 需要补货后重新发起。

这就是 AI Gateway 要解决的问题。

二、核心思路：AI 网关 + 配置驱动 + 零侵入

整体方案的核心是在现有系统和大模型之间架设一个通用 AI 网关，它不修改任何子系统代码，而是通过 YAML 配置文件将子系统的 API"翻译"成大模型能理解的 Tool。

设计原则

原则	说明
零侵入	子系统不改一行代码，网关侧通过配置适配
配置驱动	每个子系统一组 YAML，新系统接入只加配置
独立部署	网关作为独立微服务，技术栈不受子系统限制
双执行器	业务操作走 HTTP 代理，运维操作走 Agent/SSH
安全可控	危险操作二次确认、运维命令白名单、审批流程、审计日志

一句话总结

用户说一句话 → 大模型理解意图 → 自动调用子系统 API 或执行运维命令 → 把结果用人话说回来。

三、整体架构

3.1 系统架构图

3.2 网关内部结构

AI Gateway 网关内部分为四个核心模块：

关键设计点：

动态 Prompt：每个子系统有自己的领域知识（如业务术语、状态码含义），网关根据 system_id 动态拼装 Prompt，让大模型"懂"这个子系统
Tool 注册中心：启动时扫描 YAML 目录，自动构建 Tool 列表，支持热加载
双执行器：业务 Tool 走 HTTP 代理调用子系统 API，运维 Tool 走 Agent/SSH 在服务器上执行命令

四、配置驱动：YAML 定义一切

这是整个方案最核心的设计——用 YAML 配置文件代替代码开发。

4.1 配置目录结构

tools/
├── order-system/                 # 子系统：订单管理
│   ├── _system.yaml              # 子系统元信息 + 领域知识
│   ├── query_order.yaml          # 业务 Tool: 查询订单
│   ├── cancel_order.yaml         # 业务 Tool: 取消订单
│   ├── ops_check_disk.yaml       # 运维 Tool: 检查磁盘
│   └── ops_view_log.yaml         # 运维 Tool: 查看日志
├── inventory-system/             # 子系统：库存管理
│   ├── _system.yaml
│   └── ...
└── crm-system/                   # 子系统：客户管理
    ├── _system.yaml
    └── ...

4.2 子系统元信息（`_system.yaml`）

system_id: order-system
display_name: 订单管理系统
service_name: order-service           # 注册中心的服务名

domain_knowledge: |
  ## 业务知识
  - 订单状态：0=待支付, 1=已支付, 2=已发货, 3=已完成, 4=已取消, 5=异常
  - 支付方式：alipay=支付宝, wechat=微信, bank=银行卡
  - 异常订单指状态为 5 的订单，需要人工介入处理

assistant_role: |
  你是订单管理系统的 AI 助手，可以帮用户查询订单、处理异常、分析销售数据。

# 运维功能：服务器信息
servers:
  - id: order-app-01
    host: 192.168.1.101
    agent_port: 9090
    services:
      - name: order-service
        type: spring-boot
        log_path: /opt/order-service/logs/

4.3 业务 Tool 定义

name: query_order
display_name: 查询订单
description: "查询订单列表，支持按状态、时间范围、客户筛选"
category: 订单管理
risk_level: low
requires_confirmation: false
executor: http                        # 业务 Tool

parameters:
  type: object
  properties:
    status:
      type: integer
      description: "订单状态：0=待支付, 1=已支付, 2=已发货, 3=已完成, 4=已取消, 5=异常"
    start_date:
      type: string
      description: "开始日期，格式 yyyy-MM-dd"
    end_date:
      type: string
      description: "结束日期，格式 yyyy-MM-dd"

api:
  method: POST
  path: /order/list
  request_mapping:
    body:
      orderStatus: "${status}"
      startDate: "${start_date}"
      endDate: "${end_date}"
  response_mapping:
    data_path: "$.data.records"

4.4 运维 Tool 定义

name: check_disk_space
display_name: 检查磁盘空间
description: "检查服务器磁盘使用情况"
category: 系统监控
risk_level: low
requires_confirmation: false
executor: ops                         # 运维 Tool

parameters:
  type: object
  properties:
    server_id:
      type: string
      description: "目标服务器 ID"

ops:
  command_template: "df -h"
  timeout_seconds: 10
  output_parser:
    type: table
    columns: ["filesystem", "size", "used", "avail", "use_percent", "mount"]

新子系统接入只需 3 步：建目录 → 写 _system.yaml → 为每个 API 写一个 Tool YAML。不改网关代码，不改子系统代码。

五、交互流程

5.1 业务操作时序

5.2 危险操作二次确认

对于写操作（如取消订单、重启服务），通过 YAML 中的 requires_confirmation: true 触发前端确认弹窗：

5.3 运维操作流程

运维 Tool 通过部署在服务器上的轻量 Agent 执行命令，高风险操作需要审批：

六、运维能力扩展

除了调用子系统 API，AI Gateway 还支持通过 Agent 在服务器上执行运维操作，覆盖完整的运维场景：

6.1 双执行器模型

6.2 运维能力矩阵

类别	能力	风险等级
系统监控	磁盘 / CPU / 内存 / 网络	low
日志分析	查看日志、搜索错误	low
性能定位	JVM 线程栈、慢查询分析	low
代码定位	根据异常栈搜索源码、查看上下文	low
服务管理	重启 / 停止服务	high（需审批）
数据库	执行 SQL、连接数查看	high（需审批）
部署	发布 / 回滚	high（需审批）

6.3 安全机制

运维操作的安全通过四层机制保障：

命令白名单 → 角色权限 → 二次确认/审批 → 审计日志

命令白名单：Agent 只允许执行预定义的命令模式，拒绝 rm -rf / 等危险操作
角色权限：普通用户只能查看监控，运维人员可重启服务，管理员可执行数据库操作
审批流程：高风险操作需管理员审批通过后才执行
审计日志：所有运维操作全量记录，包括执行人、命令、结果、耗时

七、部署架构

7.1 部署拓扑

7.2 两种大模型部署方案

方案	适用场景	大模型	优点	缺点
方案 A：云端 API	服务器可访问外网	DeepSeek / GPT-4 / Qwen-Max	效果最好，无需 GPU	需要外网，有 API 费用
方案 B：本地私有化	纯内网环境	Ollama + Qwen2.5 / DeepSeek	数据不出内网，无 API 费用	需要 GPU 服务器

7.3 环境隔离

AI Gateway 网关与现有子系统的运行环境完全隔离：

维度	AI Gateway 网关	现有子系统
JDK	21（独立安装）	8
MySQL	8（独立实例，端口 3307）	5.7（端口 3306）
Spring Boot	3.x	2.x

两套环境互不干扰，AI Gateway 的安装和升级不影响现有业务系统。

八、接入一个新子系统需要做什么？

整个接入过程不需要修改网关代码，不需要修改子系统代码：

Step 1  确定子系统在注册中心的服务名称
          ↓
Step 2  在 tools/ 下创建子系统目录
          ↓
Step 3  编写 _system.yaml（服务名、领域知识、角色描述）
          ↓
Step 4  为每个需要 AI 调用的 API 编写 Tool YAML
          ↓
Step 5  （可选）编写运维 Tool YAML + 配置服务器信息
          ↓
Step 6  重启网关（或触发热加载）
          ↓
Step 7  前端传入对应 system_id 即可使用

典型工时：一个有 10 个 API 的子系统，约 1-2 天即可完成接入。

九、效果展示

接入后，用户在系统页面的 AI 对话窗口中可以这样交互：

👤 用户：帮我查一下今天所有异常订单

🤖 AI：正在查询异常订单...

   ⚙️ 调用工具: 查询订单 (status=异常, date=今天)
   ✅ 查询成功，返回 3 条记录

   今天共有 3 笔异常订单：

   | 订单号 | 客户 | 金额 | 异常原因 |
   |--------|------|------|----------|
   | ORD-001 | 张三 | ¥299 | 支付超时 |
   | ORD-002 | 李四 | ¥1,580 | 库存不足 |
   | ORD-003 | 王五 | ¥89 | 地址无效 |

   建议处理：
   - ORD-001：可自动重试支付
   - ORD-002：需补货后重新发起
   - ORD-003：需联系客户确认地址

👤 用户：订单系统服务器磁盘快满了吗？

🤖 AI：正在检查服务器磁盘...

   🔧 执行运维命令: df -h (服务器: order-app-01)
   ✅ 执行完成

   订单系统服务器磁盘使用情况：

   | 分区 | 总容量 | 已用 | 可用 | 使用率 |
   |------|--------|------|------|--------|
   | /    | 100G   | 45G  | 55G  | 45%    |
   | /opt | 200G   | 178G | 22G  | 89% ⚠️ |

   ⚠️ /opt 分区使用率已达 89%，建议清理日志文件。
   需要我帮你查看哪些日志文件占用空间最大吗？

十、总结

维度	方案特点
通用性	一套网关对接任意子系统，YAML 配置驱动
零侵入	子系统不改一行代码
双模式	业务操作（HTTP 代理）+ 运维操作（Agent/SSH）
安全	二次确认 + 命令白名单 + 审批 + 审计
灵活部署	云端大模型 / 本地私有化，适配内外网
快速接入	新子系统 1-2 天完成接入