企业级 Data Agent 产品需求文档

文档版本: v1.0
创建日期: 2026 年 4 月 6 日
文档状态: 草案
目标系统: L2 条件自动化 Data Agent
理论基础: arXiv:2510.23587 “A Survey of Data Agents” [1]

目录

  1. 文档概述
  2. 理论基础
  3. 用户画像与使用场景
  4. 系统架构设计
  5. 功能需求
  6. 非功能需求
  7. 人机协作模型
  8. 技术选型建议
  9. 演进路线
  10. 风险与缓解
  11. 成功指标
  12. 竞品对比
  13. 参考文献

1. 文档概述

本产品需求文档（PRD）定义了企业级 L2 Data Agent 的功能边界与架构设计，旨在通过引入自然语言转 SQL（NL2SQL）与智能分析技术，将传统依赖 IT 部门的取数流程转变为业务人员自助式的“对话即分析”新范式，彻底消除数据流转过程中的效率瓶颈。

1.1 背景与目的

随着企业数据规模的爆炸式增长，传统数据分析流程面临着严峻挑战：业务人员需要等待 IT 部门编写 SQL 查询，数据分析师被大量重复性的取数请求淹没，管理层难以实时获取决策所需的洞察。另一方面，大多数中大型企业当前已经投入大量资源建设了成熟的大数据平台或数据仓库，并在内部沉淀了极其丰富的固定报表、数据 API、预计算的宽表以及标准的业务操作流程（SOP）。

然而，由于缺乏统一的自然语言交互入口，这些已有资产的复用率和业务自服务率依然低下。此外，LLM Token 成本不可预测性也是企业采用大模型技术的关键阻碍之一。根据 “A Survey of Data Agents” [1] 的研究，Data Agent 作为连接自然语言与数据系统的智能中介，正在成为解决这一痛点的关键技术。

本文档旨在定义一个企业级 L2 Data Agent 产品的完整需求规格，该系统将基于论文提出的理论框架，实现条件自动化级别的数据智能服务。系统不仅提供从零开始的自然语言转 SQL（NL2SQL）能力，更强调对企业既有数据资产的无缝集成——将已开发的 API 和固化的 SQL 逻辑封装为可被大模型调用的数据技能（Data Skill），从而在保障业务口径绝对准确的前提下，让业务人员能够通过自然语言与数据交互，自主完成取数、分析、可视化等任务，并在关键决策点保持人类监督，确保数据安全与结果可靠性。

产品定位为面向中大型企业的数据智能平台，支持私有化部署和混合云部署两种模式，以满足不同行业的合规和数据安全要求。典型目标客户为拥有 100 以上数据分析需求用户且已具备一定数仓建设基础的企业。

1.2 目标受众

受众群体 角色描述 关注重点
业务分析师 日常数据分析工作的执行者 查询效率、分析深度、报告质量
运营人员 负责业务监控与异常响应 实时性、易用性、告警准确性
管理层 战略决策制定者 数据可信度、洞察价值、决策支持
IT 管理员 系统运维与安全管理 稳定性、安全性、可维护性
产品经理 产品规划与迭代负责人 功能完整性、用户体验、竞争力

1.3 术语与缩写

术语/缩写 英文全称 定义/中文说明
Data Agent Data Agent 基于大语言模型的数据智能代理，能够理解和执行数据相关任务
L0-L5 Level 0 to Level 5 Data Agent 自主能力分级体系，参照 SAE J3016 [5] 自动驾驶分级
NL2SQL Natural Language to SQL 将自然语言查询转换为 SQL 语句的技术
NL2VIS Natural Language to Visualization 将自然语言描述转换为数据可视化的技术
TableQA Table Question Answering 基于表格数据的问答系统
语义模型 Semantic Model 业务概念与物理数据模型之间的映射层
PCS 原理 Precision, Consistency, Sufficiency 数据质量评估的三原则：精确性、一致性、充分性
人类在环 Human-in-the-loop 在自动化流程中保留人工审核与干预的机制
RLS Row-Level Security 行级安全策略，控制用户可访问的数据行
CLS Column-Level Security 列级安全策略，控制用户可访问的数据列
CTE Common Table Expression 公用表表达式，SQL 中的临时结果集
MCTS Monte Carlo Tree Search 蒙特卡洛树搜索，用于查询优化的算法
SLA Service Level Agreement 服务等级协议
KPI Key Performance Indicator 关键绩效指标
NLG Natural Language Generation 自然语言生成

2. 理论基础

本系统的核心认知架构及演进范式严格遵循 “A Survey of Data Agents” [1] 的学术定义。从系统的形式化表征、L0-L5 的自动化分级模型、以及在人类在环（Human-in-the-loop）条件下的能力责任矩阵，确保商业产品的设计具有坚实的可论证性与技术前瞻性。

2.1 Data Agent 形式化定义

根据 “A Survey of Data Agents” [1] 的研究，Data Agent 可以被形式化定义为以下函数映射：

# Data Agent 的形式化定义函数映射
A: (T, D, E, M) → O

其中：

  • A (Agent): 数据智能代理系统
  • T (Task): 用户输入的任务描述，通常以自然语言形式表达
  • D (Data): 可用的数据资源集合，包括结构化数据、非结构化数据、元数据等
  • E (Environment): 执行环境，包括数据库管理系统 (DBMS)、代码解释器、API 接口等
  • M (LLMs): 大语言模型，作为 Agent 的认知核心
  • O (Output): 系统输出，包括查询结果、可视化图表、分析报告等

2.2 L0-L5 分级体系

参照 SAE J3016 [5] 自动驾驶分级标准，Data Agent 的自主能力可分为六个等级：

等级 名称 自主程度 人类角色 典型特征
L0 无自动化 完全手动 完全控制 用户手动编写所有查询和分析代码
L1 辅助响应 无状态提示 完全控制 Copilot 风格，提供代码补全和建议，无上下文记忆
L2 条件自动化 工作流内自主 编排者 在预定义规则内自主执行，人类批准关键决策
L3 自主编排 全管道自主 监督者 Agent 自主规划和执行完整数据管道，人类监督
L4 高度自主 主动探索 协作者 Agent 主动发现问题，自主探索数据湖
L5 生成式数据科学家 完全自主 委托者 Agent 能够发明新算法和范式，完全替代数据科学家

2.3 本系统定位：L2 条件自动化

本系统选择 L2 条件自动化 作为目标等级，基于以下战略考量：

选择 L2 的原因：

  1. 技术成熟度: L2 是当前企业级部署最成熟的技术水平，所有主流商业产品（Databricks Genie、Snowflake Cortex、ThoughtSpot 等）均处于此阶段
  2. 风险可控: 在关键操作点引入人工审批，可有效控制数据安全风险和业务风险
  3. 用户接受度: 渐进式的自动化程度更容易被企业用户接受，有利于产品推广
  4. 合规要求: 金融、医疗等监管严格的行业要求关键决策必须有人工参与
  5. 成本效益: 相比 L3+ 需要更复杂的规划和推理能力，L2 在成本和性能之间取得最佳平衡

2.4 L2 能力边界与责任分配模型

# 描述 L2 级别下 Agent 与人类的责任分配矩阵
┌─────────────────────────────────────────────────────────────────┐
│                     L2 责任分配矩阵                               │
├─────────────────────────────────────────────────────────────────┤
│  Agent 自主处理 (无需审批)                                         │
│  ├── 预定义 Skill 调用（API / 数据集 SOP）                          │
│  ├── 语义模型内的元数据查询（如：帮我查一下‘GMV’指标定义）              │
│  ├── NL2SQL 查询生成与执行                                        │
│  ├── 数据可视化渲染                                               │
│  ├── 数据清洗与格式转换                                            │
│  ├── 多表 JOIN 查询                                              │
│  ├── 模板化报告生成                                               │
│  └── 基于规则的异常检测                                            │
├─────────────────────────────────────────────────────────────────┤
│  需要人工审批                                                     │
│  ├── 基础设施变更（新增数据源、修改连接配置）                          │
│  ├── 访问策略变更（权限调整、角色变更）                               │
│  ├── 跨工作流任务（涉及多个业务域的复杂分析）                          │
│  ├── 高风险操作（数据删除、批量更新）                                 │
│  └── 低置信度结果（模型置信度低于阈值的结果）                          │
├─────────────────────────────────────────────────────────────────┤
│  默认策略                                                        │
│  └── 当任务无法明确分类时，默认触发人工审批（安全优先原则）              │
└─────────────────────────────────────────────────────────────────┘

2.5 数据生命周期覆盖

根据论文框架，Data Agent 应覆盖完整的数据生命周期：

# Data Agent 覆盖的数据生命周期全景图
数据管理 (Data Management)
    ├── 配置调优
    ├── 查询优化
    └── 故障诊断
           ↓
数据准备 (Data Preparation)
    ├── 数据清洗
    ├── 数据集成
    └── 数据发现
           ↓
数据分析 (Data Analysis)
    ├── 结构化分析 (NL2SQL / TableQA / NL2VIS)
    ├── 非结构化分析
    └── 报告生成

3. 用户画像与使用场景

为了精准覆盖企业内不同层级的数据消费诉求，产品体验设计针对以下四类核心角色（业务分析师、运营人员、管理层、IT 管理员）的典型痛点进行了垂直打磨。无论是临时取数的低延迟响应，还是高级管理层的全局趋势洞察，系统都提供了量身定制的交互策略与能力支撑。

3.1 用户画像一：业务分析师

本节描绘了系统中作为核心数据使用者的业务分析师的典型特征与期望体验，他们是高频且深度的数据消费者。

角色描述:

张明，32 岁，某电商平台高级业务分析师，拥有 5 年数据分析经验。熟悉 SQL 和 Python，但日常工作中大量时间被重复性的取数请求占据，希望将精力集中在高价值的深度分析上。

核心痛点:

  1. 业务部门的临时取数需求频繁，占用大量时间
  2. 跨部门数据分散，需要手动整合多个数据源
  3. 周报月报制作重复性高，缺乏自动化工具
  4. 业务术语与数据库字段的映射关系难以记忆

典型场景:

场景 1：日常取数:

运营经理在群里询问：”上周各品类退货率是多少？” 张明无需编写 SQL，直接向 Data Agent 提问：”查询上周各商品品类的退货数量和退货率，按退货率降序排列”，系统在 3 秒内返回结果表格。

场景 2：Ad-hoc 分析:

大促期间，张明需要快速分析某品类销售异常。通过 Data Agent 连续追问：”3C 品类本周销售额环比下降原因” → “对比各品牌销量变化” → “查看退货率是否有异常”，系统保持上下文，自动完成多轮分析。

场景 3：周报自动化:

每周一早晨，Data Agent 自动生成包含核心指标（GMV、订单量、客单价、转化率）的周报，张明只需审核和补充业务洞察，节省 2 小时制作时间。

期望体验:

  • 自然语言查询准确率达到 90% 以上
  • 复杂查询响应时间不超过 10 秒
  • 支持多轮对话，保持上下文连贯
  • 能够自动识别业务术语（如“大促”对应特定日期范围）

3.2 用户画像二：运营人员

本节刻画了对实时数据指标高度敏感、缺乏技术背景的一线运营人员，他们更关注数据呈现的直观性与响应的及时性。

角色描述:

李婷，28 岁，某金融科技公司用户运营专员，负责用户增长和留存运营。不具备编程能力，但需要频繁查看各类运营指标来指导日常工作。

核心痛点:

  1. 无法自主获取数据，每次都需要找数据分析师提需求
  2. 等待时间长，经常错过最佳运营时机
  3. 看不懂复杂的数据报表，需要直观的可视化
  4. 无法实时监控关键指标，异常发现滞后

典型场景:

场景 1：实时监控指标:

李婷每天早上通过 Data Agent 询问：”昨日新增用户数和七日留存率”，系统不仅返回数字，还自动对比前日数据，标注异常波动（如”新增用户下降 15%，低于近 7 日均值”）。

场景 2：异常告警与诊断:

Data Agent 检测到支付成功率骤降，主动推送告警。李婷询问：”支付失败的主要原因是什么？” 系统自动分析错误码分布，定位到某银行通道故障，帮助李婷快速协调技术团队解决。

场景 3：快速诊断:

某活动页面转化率异常，李婷通过 Data Agent 进行漏斗分析：”查看活动页到支付完成的转化漏斗” → “对比不同渠道的转化差异” → “找出流失最严重的环节”，全程无需编写代码。

期望体验:

  • 界面简洁，无需学习成本
  • 查询结果以图表为主，支持一键导出到 PPT
  • 关键指标可设置自动监控和告警
  • 异常分析提供业务友好的解释

3.3 用户画像三：管理层

本节聚焦于需要全局视野与宏观决策支持的企业高管群体，他们的时间极度碎片化，强调数据洞察的直接性与移动端体验。

角色描述:

王强，45 岁，某零售企业副总裁，负责销售和市场部门。需要基于数据做出战略决策，但时间宝贵，需要高效获取关键洞察。

核心痛点:

  1. 数据分散在多个系统，难以形成统一视图
  2. 传统报表更新滞后，无法支持实时决策
  3. 数据分析报告专业术语过多，理解成本高
  4. 缺乏预测性洞察，多为事后分析

典型场景:

场景 1：高层仪表盘:

王强每天早晨通过手机查看 Data Agent 生成的执行摘要，包含昨日核心指标、本周趋势、异常预警和行动建议，5 分钟掌握业务全局。

场景 2：趋势分析:

季度规划会议上，王强询问：”过去一年各区域销售趋势如何？预测下季度表现”，Data Agent 生成趋势图表和预测分析，支持决策讨论。

场景 3：决策支持:

考虑是否进入新市场，王强要求：”分析过去两年新进入市场的 ROI 表现”，Data Agent 整合历史数据，生成包含风险评估的建议报告。

期望体验:

  • 移动端优先，随时随地访问
  • 数据呈现简洁，突出关键信息
  • 提供”so what”层面的业务洞察
  • 支持语音交互，解放双手

3.4 用户画像四：IT 管理员

角色描述:

赵工，35 岁，某制造企业数据平台负责人，负责数据基础设施的运维和安全管理。关注系统的稳定性、安全性和合规性。他所在的企业已经建设了成熟的 Hadoop/Spark 数据仓库，并开发了上百个数据 API 和复杂的跑批 SQL。

核心痛点:

  1. 业务部门自助取数需求激增，底层数据库并发负载压力大。
  2. 历史沉淀了大量成熟的数据 API 和固定报表 SQL，但业务人员找不到、不会用，导致重复开发。
  3. 数据安全风险增加，跨系统权限管理复杂，缺乏对数据使用的全面审计能力。
  4. 业务术语与底层物理数据模型的映射维护困难。

典型场景:

场景 1：已有资产的技能化注册:

赵工通过管理后台，将企业现有的“用户画像查询 API”和“月度营收结算 SQL”直接注册为 Data Agent 的预置 Skill。业务人员提问时，Agent 会优先调用这些高可靠的既有资产，而不再消耗算力去重新生成 SQL。

场景 2：语义模型维护:

业务需求变化，需要新增”VIP 客户”的定义。赵工在语义模型层更新定义，所有相关查询自动生效，无需修改底层 SQL。

场景 3：权限管理:

新员工入职，赵工配置其数据访问权限：可以查看销售数据但看不到成本数据，可以访问汇总表但不能查看明细。所有访问行为被完整记录。

场景 4：审计与合规:

审计部门要求提供某敏感数据的访问记录。赵工通过审计日志快速导出完整的访问链：谁在什么时间通过什么查询访问了哪些数据。

期望体验:

  • 细粒度的权限控制能力
  • 完整的操作审计日志
  • 系统监控和告警机制
  • 易于维护的语义模型配置

4. 系统架构设计

平台基于高内聚、低耦合的四层架构设计。由外及里，用户界面层负责多端交互意图捕获；L2 代理编排层充当“大脑”进行任务拆解与审批拦截；核心能力层提供 NL2SQL 与可视化生成引擎；底层基础设施层则通过统一语义模型和沙箱环境保障查询的准确与安全执行。

4.1 整体架构图

# 系统四层架构设计图（UI 层、代理编排层、核心能力模块层、基础设施层）
┌─────────────────────────────────────────────────────────────────────────────┐
│                           用户界面层 (UI Layer)                               │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐ │
│  │  Chat UI    │  │  REST API   │  │   Webhook   │  │  Mobile Dashboard   │ │
│  │  (Web/桌面)  │  │  (第三方集成)│  │  (事件推送)   │  │  (管理层视图)        │ │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘  └──────────┬──────────┘ │
└─────────┼────────────────┼────────────────┼────────────────────┼────────────┘
          │                │                │                    │
          └────────────────┴────────────────┴────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                       L2 代理编排层 (Agent Orchestration)                     │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                        记忆与状态管理 (Memory & State)                │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 短期记忆      │  │ 长期记忆      │  │ 上下文持久化                │   │    │
│  │  │ (对话上下文)   │  │ (用户偏好)    │  │ (Context Persist)        │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│                                    ▼                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                        意图识别模块 (Intent Recognition)              │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 查询分类器     │  │ 实体抽取      │  │ 意图消歧/澄清              │   │    │
│  │  │ (NLU Engine) │  │ (NER)        │  │ (Clarification)          │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│                                    ▼                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      执行计划生成 (Plan Generation)                   │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 任务分解      │  │ 工具/Skill 选择│  │ 依赖关系构建               │   │    │
│  │  │ (Decomposer) │  │ (Tool Select)│  │ (DAG Builder)            │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│                                    ▼                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      SOP 与技能编排 (Skill & SOP Orchestrator)        │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ Skill 匹配    │  │ API 参数提取  │  │ 多步 SOP 状态管理          │   │    │
│  │  │ (Matcher)    │  │ (Extraction) │  │ (State Tracker)          │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│                                    ▼                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      人类在环控制 (Human-in-the-loop)                 │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 审批工作流     │  │ 置信度评估    │  │ 反馈收集                   │   │    │
│  │  │ (Approval WF)│  │ (Confidence) │  │ (Feedback Loop)          │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                      核心能力模块 (Core Capability Modules)                   │
│                                                                             │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌────────────┐ │
│  │   NL2SQL 引擎    │ │  NL2VIS 引擎    │ │  数据准备引擎     │ │ 报告生成器   │ │
│  │  ┌───────────┐  │ │  ┌───────────┐  │ │  ┌───────────┐  │ │ ┌────────┐ │ │
│  │  │ 语义解析   │  │ │  │ 图表推荐    │  │ │  │ 数据发现   │  │ │ │ NLG    │ │ │
│  │  │ SQL 生成   │  │ │  │ 交互构建    │  │ │  │ 数据集成   │  │ │ │ 模板    │ │ │
│  │  │ 查询优化   │  │ │  │ 渲染引擎    │  │ │  │ 数据清洗   │  │ │ │ 调度    │ │ │
│  │  └───────────┘  │ │  └───────────┘  │ │  └───────────┘  │ │ └────────┘ │ │
│  └─────────────────┘ └─────────────────┘ └─────────────────┘ └────────────┘ │
│                                                                             │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐                │
│  │   TableQA 引擎   │ │  统计分析引擎     │ │  异常检测引擎     │                │
│  │  ┌───────────┐  │ │  ┌───────────┐  │ │  ┌───────────┐  │                │
│  │  │ 表格理解   │  │ │  │ 描述统计    │  │ │  │ 时序异常   │  │                │
│  │  │ 多表推理   │  │ │  │ 假设检验    │  │ │  │ 分布异常   │  │                │
│  │  │ 聚合计算   │  │ │  │ 相关分析    │  │ │  │ 关联异常   │  │                │
│  │  └───────────┘  │ │  └───────────┘  │ │  └───────────┘  │                │
│  └─────────────────┘ └─────────────────┘ └─────────────────┘                │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                      基础设施层 (Infrastructure Layer)                        │
│                                                                             │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      语义模型与知识库                                  │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 业务术语词典   │  │ 技能/API 注册表│  │ 表关系图谱                │   │    │
│  │  │ 字段语义映射   │  │ (Skill Reg)  │  │ 示例查询库                 │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      执行引擎                                         │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ SQL 执行器    │  │ DuckDB 沙箱   │  │ 缓存层 (Redis)            │   │    │
│  │  │ 查询优化器     │  │ (物化API结果) │  │ 结果缓存/查询缓存           │   │    │
│  │  └──────────────┘  └──────▲───────┘  └──────────────────────────┘   │    │
│  │                           ┊                                         │    │
│  │                           ┊ (FR-072 联邦查询：Skill 结果物化为临时表)   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                    │                                        │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                      权限与安全                                       │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐   │    │
│  │  │ 身份认证      │  │ 访问控制       │  │ 数据脱敏                  │   │    │
│  │  │ (SSO/OAuth)  │  │ (RBAC/ABAC)  │  │ (Masking)                │   │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                      数据源层 (Data Source Layer)                            │
│                                                                             │
│  ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌────────────┐ │
│  │  关系型数据库     │ │  数据仓库/湖      │ │  文件系统        │ │  API/SaaS  │ │
│  │  ┌───────────┐  │ │  ┌───────────┐  │ │  ┌───────────┐  │ │ ┌────────┐ │ │
│  │  │ MySQL     │  │ │  │ Snowflake │  │ │  │ CSV       │  │ │ │ REST   │ │ │
│  │  │ PostgreSQL│  │ │  │ Databricks│  │ │  │ Excel     │  │ │ │ GraphQL│ │ │
│  │  │ Oracle    │  │ │  │ BigQuery  │  │ │  │ Parquet   │  │ │ │ ERP    │ │ │
│  │  │ SQL Server│  │ │  │ ClickHouse│  │ │  │ JSON      │  │ │ │ CRM    │ │ │
│  │  └───────────┘  │ │  └───────────┘  │ │  └───────────┘  │ │ └────────┘ │ │
│  └─────────────────┘ └─────────────────┘ └─────────────────┘ └────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘

4.2 数据流描述

标准查询与 Skill 优先流程：

# 标准数据查询流转全过程
1. 用户输入 → 意图识别模块解析查询意图和实体
2. 意图拦截 → 检查是否匹配预定义的 Data Skill（已有 API 或 SOP）
3. 匹配 Skill → 提取参数直接调用底层数据服务 API（绕过 NL2SQL）
4. 未匹配 Skill → 语义模型层将业务术语映射为数据库对象，并走标准 NL2SQL 路线
5. 执行计划生成器构建操作 DAG
6. 人类在环控制评估是否需要审批
7. 核心能力模块执行具体任务（API 调用 / NL2SQL / NL2VIS 等）
8. 执行引擎在沙箱环境中运行查询
9. 权限安全层进行结果过滤和脱敏
10. 结果返回给用户，同时记录审计日志

缓存优化流程：

# 多级缓存优化机制的执行流程
1. 查询到达 → 检查查询缓存（相同查询）
2. 缓存命中 → 直接返回缓存结果
3. 缓存未命中 → 检查语义等价缓存（不同表述，相同意图）
4. 执行查询 → 结果存入多级缓存
5. 元数据变更 → 自动失效相关缓存

错误处理流程：

# 异常捕获与智能修复重试流程
1. 查询执行失败 → 错误分类（语法错误 / 超时 / 权限不足 / 数据源不可用）
2. 语法错误 → 自动重写 SQL 并重试（最多 3 次）
3. 超时 → 尝试查询简化或拆分，提示用户缩小查询范围
4. 权限不足 → 返回权限说明，引导用户申请权限
5. 数据源不可用 → 使用缓存结果（如有）或告知用户当前服务受限
6. 所有重试失败 → 记录详细错误信息，返回友好的错误描述和建议操作

审批中断与恢复流程：

# 审批流程中的上下文中断与恢复机制
1. 任务触发审批 → 任务状态设为“待审批”，持久化存储执行上下文
2. 通知审批人 → 用户收到“等待审批中”状态提示
3. 审批通过 → 恢复执行上下文，继续执行后续任务
4. 审批拒绝 → 终止任务，向用户返回拒绝原因和替代建议
5. 审批超时（默认 24 小时）→ 触发升级规则或自动取消，通知用户重新发起

4.3 各层模块职责说明

架构层 核心模块 职责描述
用户界面层 Chat UI、REST API、Webhook、Mobile Dashboard 提供多端接入能力，统一请求格式后转发至编排层
L2 代理编排层 意图识别、SOP 与技能编排、执行计划生成、人类在环控制 解析意图优先匹配 Skill，构建执行 DAG，在关键节点触发审批
核心能力模块层 NL2SQL、NL2VIS、TableQA、报告生成、异常检测 执行具体的数据查询、API 调用、分析、可视化和报告生成任务
基础设施层 语义模型、执行引擎、权限安全 管理业务语义映射、沙箱执行查询、强制执行访问控制
数据源层 关系型数据库、数据仓库/湖、文件、API 提供底层数据存储和访问接口

本节明确了系统在不同数据合规与成本要求下的物理部署拓扑，支持从完全隔离的私有化环境到弹性可扩展的混合云架构平滑切换。

4.4 部署架构

系统支持以下两种部署模式：

  • 私有化部署：所有组件部署在客户 VPC 内，数据不出域，适合金融、医疗等监管严格的行业
  • 混合云部署：控制平面和 LLM 推理可部署在公有云，数据平面保留在客户环境，适合成本敏感场景

关键部署约束：

  • 无状态服务设计，支持 Kubernetes 编排
  • LLM 推理层支持 GPU 节点独立扩缩
  • 数据平面与控制平面网络隔离
  • 支持蓝绿部署和灰度发布

本节划定了系统架构设计的前置边界条件，明确了诸如“只读访问原则”与“元数据依赖”等不可逾越的工程底线。

4.5 技术约束与假设

  • 所有数据源均通过只读连接访问，系统不对源数据库执行写操作
  • LLM 推理延迟不纳入系统 SLA 计算（受三方服务影响）
  • 单次查询返回结果集上限为 10,000 行，超出部分需通过导出任务处理
  • 系统假设底层数据源已完成基本的数据治理（表命名规范、字段注释等）

5. 功能需求

系统的核心能力版图由八大功能子模块构成，横跨从数据源接入（数据准备）、业务概念映射（语义层），到自然语言对话取数、可视化自动渲染，再到高级洞察报告生成以及已有 API 技能集成（SOP）的完整生命周期，并在全链路中嵌入了人机协同机制。

5.1 自然语言取数（NL2SQL）

本模块是实现“对话即分析”理念的基石，通过引入大模型与数据库词法的深度融合机制，将缺乏结构化特征的自然语言输入稳定转化为语法正确、性能高效的 SQL 方言。该模块深度解耦了语言理解与物理执行，确保生成链路的安全性。

5.1.1 语义模型管理

作为沟通业务层与数据基建的桥梁，本模块允许数据管理员建立一套与物理表隔离的逻辑语义层（Semantic Layer），通过同义词词典、KPI 参数化公式以及跨表关联图谱，彻底消除大模型在解析专有业务黑话时的“幻觉”。

FR-001: 业务概念映射:

  • 系统应支持将业务术语（如”活跃用户”、”GMV”）映射到数据库表和字段
  • 支持同义词配置（如”销售额”=”GMV”=”Revenue”）
  • 支持层级概念（如”北京”→”华北”→”全国”）

FR-002: KPI 定义管理：

  • 系统应支持预定义 KPI 的计算逻辑（如”留存率 = 次日登录用户数 / 当日新增用户数”）
  • KPI 定义应支持参数化（如时间窗口、过滤条件）
  • KPI 变更应自动同步到所有相关查询

FR-003: 跨表关联配置：

  • 系统应支持可视化配置表之间的关联关系（JOIN 条件）
  • 支持主外键自动识别和建议
  • 支持复杂关联路径（多跳 JOIN）的自动发现和优化

FR-004: 语义模型版本控制：

  • 语义模型变更应支持版本管理
  • 支持灰度发布和回滚
  • 变更影响分析（哪些查询会受影响）

5.1.2 上下文增强

本模块通过构建业务示例库与用户偏好记忆，使得自然语言解析能够充分结合历史语境与个人习惯，显著提升复杂查询的意图命中率。

FR-005: 示例查询库：

  • 系统应维护常见查询的示例库
  • 支持基于相似度的示例检索（参考 Databricks Genie Knowledge Store [3]）
  • 支持用户收藏个人常用查询

FR-006: 列级元数据：

  • 系统应存储列的详细元数据（数据类型、取值范围、业务含义、枚举值说明）
  • 支持自动元数据采集（基于数据采样和统计分析）
  • 支持敏感数据自动标记

FR-007: 对话上下文管理：

  • 系统应在多轮对话中保持上下文
  • 支持指代消解（如”刚才的结果”、”那个表”）
  • 支持查询条件的继承和修改

FR-008: 用户偏好学习：

  • 系统应学习用户的查询习惯和偏好
  • 支持个性化查询建议
  • 支持常用维度和指标的自动推荐

5.1.3 查询生成与执行

本模块涵盖从基础单表检索到多表复杂 JOIN 的全量 SQL 算子生成逻辑，并引入基于成本的优化器以确保执行效率。

FR-009: 单表查询生成：

  • 系统应支持简单的单表 SELECT 查询生成
  • 支持 WHERE 条件（等于、范围、模糊匹配、IN 列表）
  • 支持 ORDER BY 和 LIMIT

FR-010: 多表 JOIN 查询：

  • 系统应支持多表 JOIN 查询的自动生成
  • 支持 INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL JOIN
  • 自动选择最优 JOIN 顺序和类型

FR-011: 复杂查询支持：

  • 系统应支持子查询（Subquery）生成
  • 支持 CTE（公用表表达式）
  • 支持窗口函数（ROW_NUMBER、RANK、LAG、LEAD 等）
  • 支持聚合函数和 GROUP BY

FR-012: 查询优化：

  • 系统应对生成的 SQL 进行优化
  • 支持基于成本的执行计划分析
  • 参考 Alpha-SQL MCTS 方法 [2] 进行查询重写优化

FR-013: 查询执行沙箱：

  • 所有查询应在隔离的沙箱环境中执行
  • 支持查询超时控制（默认 30 秒，可配置）
  • 支持资源限制（CPU、内存、返回行数）

5.1.4 验证与修正

本模块在 SQL 执行前与执行后引入了双重校验机制，旨在前置拦截高危扫描操作并自动修正语法缺陷，确保系统整体可用性。

FR-014: 执行计划验证：

  • 系统应在执行前验证 SQL 的执行计划
  • 检测潜在的性能问题（全表扫描、笛卡尔积等）
  • 高风险查询自动触发人工审批

FR-015: 结果一致性检查：

  • 系统应对查询结果进行合理性验证
  • 检测异常值（与历史数据对比）
  • 检测空结果和异常大结果集

FR-016: 成本估算：

  • 系统应估算查询的执行成本
  • 对高成本查询进行预警
  • 支持成本配额管理（按用户/部门）

FR-017: 成本硬拦截与预算控制：

  • 支持设置用户级/部门级的单次查询最大扫描数据量及预估费用阈值
  • 当查询预估超出阈值时，必须强制人工审批或自动拒绝
  • 实时监控 Token 消耗及查询算力成本，触达预算上限后熔断服务

FR-018: 查询修正建议：

  • 当查询失败时，系统应提供修正建议
  • 支持语法错误的自动修复
  • 支持业务逻辑错误的澄清和引导

5.2 智能数据分析（TableQA + 统计分析）

脱离了纯粹的数据检索，本模块赋予了 Agent “初级数据分析师”的数值推理能力。通过内置在内存沙箱中的 Pandas/DuckDB 引擎，系统不仅能针对临时挂载的子表进行多跳关联提问，还能执行同比环比等复杂的分析论证。

5.2.1 表格问答

面对高频的 Ad-hoc 查询，本功能支持用户对已经抽取的“宽表”或“临时视图”直接发问，系统将利用结构化数据推理技术（Table-based Reasoning），在无需重写底层 SQL 的前提下完成跨行/列的数值提取。

FR-019: 单表问答：

  • 系统应支持基于单张表的问答
  • 支持事实查询（如”最高的销售额是多少”）
  • 支持比较查询（如”A 和 B 哪个更高”）

FR-020: 多表推理：

  • 系统应支持跨多张表的推理问答
  • 自动识别所需的表和关联关系
  • 支持多跳推理（如”购买过 A 商品的用户中，有多少人购买了 B 商品”）

FR-021: 聚合统计：

  • 系统应支持各类聚合计算（求和、平均、计数、最大最小值）
  • 支持分组统计（按时间、类别、地区等维度）
  • 支持占比和同比环比计算

5.2.2 高级分析

本模块突破了传统取数的局限，通过引入时序预测与归因分析算法，赋予系统深度的数据挖掘与根因诊断能力。

FR-022: 趋势分析：

  • 系统应自动识别数据趋势（上升、下降、平稳、周期性）
  • 支持趋势拟合和预测
  • 支持趋势变化的拐点检测

FR-023: 异常检测：

  • 系统应自动检测数据异常（离群值、突变、异常模式）
  • 支持时序数据的异常检测
  • 支持异常原因的初步分析

FR-024: 关联分析：

  • 系统应支持变量之间的相关性分析
  • 支持相关系数计算和显著性检验
  • 支持关联规则挖掘（适用于交易数据）

FR-025: 根因分析：

  • 系统应支持简单的根因分析
  • 支持维度下钻分析（如销售额下降 → 按地区分析 → 按品类分析）
  • 支持贡献度分析（各因素对变化的贡献）

5.3 可视化展现（NL2VIS + 交互式图表）

本模块打破了传统 BI 拖拽配图的高门槛，引入自然语言到可视化（NL2VIS）多模态代理架构。通过理解数据特征的统计学意义与用户提问的隐性意图，自动为底层数据挂载最优的视觉映射规则，同时保留丰富的交互式下钻接口。

5.3.1 自动图表推荐

本模块旨在消除“选择哪种图表最合适”的决策阻力。它根据返回结果的数据类型（如时间序列、地理坐标、分类变量），智能生成诸如折线图、热力图或南丁格尔玫瑰图等最佳渲染配置。

FR-026: 智能图表类型选择：

  • 系统应根据数据特征自动推荐最合适的图表类型
  • 支持折线图（趋势）、柱状图（对比）、饼图（占比）、散点图（相关性）等
  • 支持多维度数据的图表类型推荐

FR-027: 图表配置自动生成：

  • 系统应自动生成图表的标题、坐标轴标签、图例
  • 支持颜色和主题的自动配置
  • 支持数据标签和提示信息的自动生成

FR-028: 多图表组合：

  • 系统应支持一个查询返回多个相关图表
  • 支持图表之间的关联和联动
  • 支持仪表盘风格的布局

5.3.2 交互式功能

本模块强调图表生成的灵活性与二次编辑能力，支持用户通过自然语言追问或拖拽操作对现有视图进行深度下钻与联动分析。

FR-029: 数据钻取：

  • 用户应能够在图表上进行下钻操作（如从年 → 月 → 日）
  • 支持自定义钻取路径
  • 支持上卷（Roll-up）操作

FR-030: 数据过滤：

  • 用户应能够在图表上进行交互式过滤
  • 支持点击图例筛选
  • 支持范围选择过滤

FR-031: 图表联动：

  • 多个图表之间应支持联动交互
  • 在一个图表上的选择应同步过滤其他图表
  • 支持联动状态的保存和分享

FR-032: 图表导出：

  • 用户应能够导出图表为图片（PNG、SVG）
  • 支持导出为交互式 HTML
  • 支持嵌入代码生成

5.3.3 仪表盘构建

本模块支持将碎片化的单图表聚合为全局业务看板，并提供灵活的布局定制与权限分发机制，满足管理层的宏观监控需求。

FR-033: 可视化仪表盘：

  • 系统应支持用户创建个人仪表盘
  • 支持拖拽式布局调整
  • 支持实时数据刷新

FR-034: 外部工具集成：

  • 系统应支持导出到 Tableau、Power BI 等外部工具
  • 支持生成兼容的数据文件和连接配置
  • 参考 nvAgent 框架 [6]（processing agent → construction agent → validation agent）

5.4 分析报告自动生成

本模块致力于解决周报、月报及大型专题分析报告等重度图文混排场景的人力消耗。系统不仅聚合查询结果，更通过大模型引入多维度洞察（Insights），一键输出可供直接向管理层汇报的企业级幻灯片与文档。

5.4.1 NLG 数据洞察

作为“看图说话”的数字助理，该功能能够基于阈值警报或显著波动，使用自然语言（Natural Language Generation）智能撰写数据背后的业务事实，免去人工归因解读的脑力成本。

FR-035: 自动洞察生成：

  • 系统应使用 NLG 技术将数据发现转换为文本叙述
  • 支持关键指标的自然语言描述
  • 支持异常和趋势的自动解读

FR-036: 数据故事讲述：

  • 系统应能够构建数据故事（Data Storytelling）
  • 支持时间线叙事（过去 → 现在 → 预测）
  • 支持问题-分析-结论的结构化叙述

FR-037: 多语言支持：

  • 系统应支持中文和英文的洞察生成
  • 支持业务术语的本地化表达
  • 支持语气和风格的配置（正式/轻松）

5.4.2 报告模板

本模块预置了覆盖主流业务场景的标准化报告框架，同时支持企业级视觉规范的深度定制，确保输出产物的专业度与品牌一致性。

FR-038: 预定义报告模板：

  • 系统应提供多种报告模板：
    • 执行摘要（Executive Summary）：关键指标、主要发现、行动建议
    • 详细分析报告：数据背景、分析方法、详细结果、局限性说明
    • 定期报告：日报、周报、月报模板

FR-039: 自定义报告模板：

  • 用户应能够创建自定义报告模板
  • 支持模板变量的定义
  • 支持条件内容（根据数据动态显示/隐藏）

FR-040: 报告格式导出：

  • 系统应支持导出为 PDF、Word、PPT 格式
  • 支持邮件正文格式的报告
  • 支持 Markdown 格式导出

5.4.3 定期调度

本模块通过引入 CRON 表达式与事件驱动机制，实现了分析报告的无人值守生成与多渠道自动化分发。

FR-041: 报告调度配置：

  • 用户应能够配置报告的定期生成和分发
  • 支持按日、周、月、季度调度
  • 支持条件触发（如异常发生时自动发送）

FR-042: 分发渠道：

  • 系统应支持多种分发渠道：
    • 邮件发送
    • 企业微信/钉钉/飞书机器人
    • Webhook 回调
    • 系统内消息通知

5.5 数据准备能力（P2 需求：第三方元数据集成）

Data Agent 的核心价值在于“读与析”，而非“写与洗”。为了避免陷入自研庞大 ETL 引擎的泥潭，本模块聚焦于与企业既有数据治理资产的集成，通过获取高质量的元数据上下文，为 Agent 提供充足的分析背景。

5.5.1 元数据平台集成

本模块提供标准化的适配器，实现与主流开源及商业数据目录系统的打通，以只读方式获取企业全局数据地图。

FR-043: 第三方 DataHub/OpenMetadata 集成：

  • 系统应支持一键接入 DataHub、OpenMetadata 等主流元数据管理平台
  • 支持定时同步表结构、字段注释及业务术语定义
  • 支持读取上游系统沉淀的数据血缘关系

FR-044: 元数据语义搜索：

  • 用户能够通过自然语言搜索已集成的元数据资产
  • 自动将元数据平台的 Tag 和 Glossary 转化为 Agent 的上下文
  • 支持基于业务描述的相似度数据集推荐

FR-045: 数据质量状态读取：

  • 系统应能够读取第三方数据质量平台（如 Great Expectations）的监控状态
  • 在 Agent 执行分析前，若检测到源表处于“质量告警”状态，需向用户发出风险提示

5.6 多数据源连接

为了满足中大型企业的复杂网络架构需求，系统通过插件化的连接器设计，实现了对关系型数据库、大数据仓库生态及三方 API 的全方位覆盖，彻底打破数据孤岛。

5.6.1 关系型数据库

作为大多数企业 ERP/CRM 系统的底层承载，本模块提供了针对主流 RDBMS 的高性能、加密只读连接适配。系统支持特定数据库方言的直接翻译与执行。

FR-046: MySQL 支持：

  • 系统应支持 MySQL 5.7+ 版本的连接
  • 支持标准 SQL 方言
  • 支持 SSL/TLS 加密连接

FR-047: PostgreSQL 支持：

  • 系统应支持 PostgreSQL 10+ 版本的连接
  • 支持 PostgreSQL 特有特性（JSONB、数组类型等）
  • 支持 SSL 连接和证书认证

FR-048: Oracle 支持：

  • 系统应支持 Oracle 11g+ 版本的连接
  • 支持 Oracle PL/SQL 存储过程调用
  • 支持 Oracle 特有的数据类型

FR-049: SQL Server 支持：

  • 系统应支持 SQL Server 2016+ 版本的连接
  • 支持 T-SQL 方言
  • 支持 Windows 认证和 SQL Server 认证

5.6.2 数据仓库/湖

本模块规范了系统与主流大数据分析平台（如 Hive、Spark、Snowflake）的深度对接标准与下推执行策略。

FR-050: Snowflake 支持：

  • 系统应支持 Snowflake 连接
  • 支持 Snowflake 特有的语法（如 SEMI JOIN）
  • 支持 Snowflake Semantic Views 集成

FR-051: Databricks 支持：

  • 系统应支持 Databricks SQL Warehouse 连接
  • 支持 Unity Catalog 集成
  • 支持 Delta Lake 特性

FR-052: BigQuery 支持：

  • 系统应支持 Google BigQuery 连接
  • 支持 BigQuery 标准 SQL 方言
  • 支持分区表和嵌套字段

FR-053: ClickHouse 支持：

  • 系统应支持 ClickHouse 连接
  • 支持 ClickHouse 特有的数据类型和函数
  • 支持分布式表查询

FR-054: Hive 支持：

  • 系统应支持 Apache Hive 连接
  • 支持 HiveQL 方言
  • 支持分区表和桶表

5.6.3 文件数据源

本模块支持对非结构化或半结构化文件（CSV、Excel、JSON）的快速解析与临时表挂载分析。

FR-055: CSV 支持：

  • 系统应支持 CSV 文件的上传和查询
  • 自动检测编码和分隔符
  • 支持大文件分块处理

FR-056: Excel 支持：

  • 系统应支持 Excel (.xlsx, .xls) 文件
  • 支持多 Sheet 选择和合并
  • 支持公式计算结果的读取

FR-057: Parquet 支持：

  • 系统应支持 Parquet 格式文件
  • 支持列式存储优化查询
  • 支持嵌套数据结构

FR-058: JSON 支持：

  • 系统应支持 JSON 和 JSONL 文件
  • 支持嵌套结构的展平和查询
  • 支持 JSON Schema 推断

5.6.4 API 数据源

本模块允许系统通过 REST/GraphQL 接口实时抓取外部动态数据，打破企业内部数据孤岛。

FR-059: REST API 支持：

  • 系统应支持 REST API 作为数据源
  • 支持多种认证方式（API Key、OAuth、Basic Auth）
  • 支持分页和速率限制处理

FR-060: GraphQL 支持：

  • 系统应支持 GraphQL API 连接
  • 支持查询生成和变量传递
  • 支持嵌套数据的自动展平

FR-061: ERP/CRM 连接器：

  • 系统应提供常见 ERP/CRM 系统的预置连接器
  • 包括 Salesforce、SAP、Oracle ERP 等
  • 支持标准对象和自定义对象

5.7 人机协作功能

本系统拒绝盲目追求“完全自动驾驶”，而是通过设计闭环的反馈链路与渐进式的授权体系，让大模型在与人类的协同中不断进化，从而构筑稳固的业务信任度。

5.7.1 用户反馈

作为数据飞轮（Data Flywheel）的核心驱动力，本模块允许用户通过显式的点赞、踩及打标操作，为系统沉淀宝贵的对齐样本（Alignment Data），从而反哺微调大模型。

FR-062: 即时反馈：

  • 用户应能够对每次查询结果提供反馈（正确/错误/部分正确）
  • 支持错误类型的标注（理解错误、SQL 错误、数据错误）
  • 支持修正输入，用于模型学习

FR-063: 查询收藏：

  • 用户应能够收藏常用查询
  • 收藏时可添加标签和备注
  • 支持从收藏生成示例查询库

FR-064: 反馈分析：

  • 系统应定期分析用户反馈
  • 识别高频问题和改进点
  • 生成模型优化建议报告

5.7.2 信任建立

本模块通过提供可解释的执行计划与详尽的数据血缘追踪，帮助业务人员透视“黑盒”，建立对 AI 生成结果的长期信任。

FR-065: 透明度展示：

  • 系统应展示查询的转换过程（自然语言 → SQL）
  • 展示数据来源和计算逻辑
  • 展示置信度评分和依据

FR-066: 渐进式授权：

  • 新用户初始权限受限，随着使用历史和信任积累逐步放开
  • 高风险操作需要额外的信任验证（如 MFA）
  • 支持临时权限提升（带时限）

FR-067: 信任度评分：

  • 系统应维护用户的信任度评分
  • 基于历史行为（准确率、违规记录等）计算
  • 信任度影响审批流程和权限边界

FR-068: 审批中断恢复机制：

  • 支持任务状态的持久化存储，当触发人工审批时，Agent 自动保存当前执行上下文
  • 审批通过后，系统能够从断点恢复执行计划，避免因等待过久导致会话超时或让用户重试
  • 支持设置审批超时自动取消及通知机制

5.8 数据技能与 SOP 编排

本模块旨在集成企业已有大数据平台和成熟数据仓库积累的 API、数据资产与标准操作程序（SOP），通过“预定义技能（Skill）”机制实现 NL2API 的直接调用。

5.8.1 API 与技能注册

FR-069: 数据 API 接入：

  • 支持无缝注册企业已有的大数据平台对外提供的查询 API
  • 支持 OpenAPI/Swagger 规范自动解析与导入 API 端点
  • 统一管理各内部系统的认证鉴权机制（如 JWT、OAuth）

FR-070: 技能（Skill）元数据定义：

  • 将具体的 API 封装为 Data Skill，并为其配置自然语言描述、触发关键词与意图
  • 支持定义 Skill 的入参/出参 Schema，以及参数的枚举映射关系
  • 支持在模型无法通过 NL2SQL 直接查询到底层宽表时，优先建议用户调用相关 Skill

5.8.2 SOP 编排执行

FR-071: 多步 SOP 编排：

  • 支持将多个独立的 Data Skill 串联编排为一个复杂数据分析 SOP
  • 支持 SOP 中的上下文变量传递（如上一步 API 返回的部门 ID 作为下一步 API 的入参）
  • 支持带有条件判断分支（If-Else）的技能调用流

FR-072: 混合查询执行：

  • 允许同一个用户会话中，既包含对已有数据 API 的 Skill 调用，也包含实时生成的 NL2SQL 查询
  • 支持将 API 返回的结构化数据直接作为临时表，与数仓中已有表进行联邦查询（Federated Query）与关联分析

FR-073: 技能结果缓存（TTL）：

  • 支持对 Data Skill 的返回结果设置 TTL（Time-To-Live）缓存策略
  • 针对低频变更数据（如部门列表）设置长缓存（如 1 小时），针对高频数据（如实时库存）设置短缓存或不缓存（0 秒）
  • 降低后端 API 的并发压力，提高 Agent 响应速度

6. 非功能需求

作为面向中大型企业的商业系统，除了实现基础的业务功能，系统在性能指标（响应延迟、高并发）、安全基线（行列级权限、脱敏）、高可用架构以及合规审计方面必须达到极其严苛的生产级 SRE（站点可靠性工程）标准。

本节量化了系统在极端并发场景下的吞吐与延迟基准，确保在全公司范围内推广时核心业务的丝滑体验。

6.1 性能需求

为了保障良好的用户体验，系统对各类核心操作设定了严格的响应时间基准。

NFR-001: 查询响应时间 SLA：

查询类型 P50 目标 P99 目标 说明
简单查询（单表、少量数据） < 2 秒 < 5 秒 命中缓存的场景
复杂查询（多表 JOIN、聚合） < 10 秒 < 30 秒 需要实际执行的查询
报告生成 < 30 秒 < 2 分钟 包含 NLG 的完整报告

NFR-002: 系统可用性：

  • 系统可用性目标：99.5%（月度）
  • 计划内维护窗口：每月不超过 4 小时，需提前 72 小时通知
  • 故障恢复时间目标（RTO）：< 30 分钟
  • 数据恢复点目标（RPO）：< 5 分钟

NFR-003: 并发处理能力：

  • 系统应支持 100-1000 并发用户（根据部署规模）
  • 查询队列管理：当并发超过限制时，请求进入队列等待
  • 支持查询优先级的动态调整

NFR-004: 缓存性能：

  • 查询缓存命中率目标：> 60%
  • 缓存更新延迟：< 5 秒（元数据变更后）
  • 支持多级缓存（内存缓存 + 分布式缓存）

6.2 安全需求

本节明确了系统的安全基线，包括行列级权限控制与敏感数据脱敏策略，保障企业数据资产绝对安全。

NFR-005: 行级安全（RLS）：

  • 系统应支持基于用户属性的行级数据过滤
  • 支持动态 RLS 策略（根据查询上下文调整）
  • RLS 策略应作用于所有查询路径（包括导出和 API）

NFR-006: 列级安全（CLS）：

  • 系统应支持列级数据访问控制
  • 支持敏感列的自动识别和标记
  • 支持基于角色的列级权限配置

NFR-007: 数据脱敏：

  • 系统应支持敏感数据的动态脱敏
  • 脱敏规则包括：掩码（如手机号 138****8888）、哈希、截断、替换
  • 支持基于用户权限的差异化脱敏策略

NFR-008: Agent 级权限执行：

  • Data Agent 应在执行层强制执行权限控制
  • 防止通过提示注入等方式绕过权限
  • 所有权限检查应记录审计日志

NFR-009: 数据传输加密：

  • 所有数据传输应使用 TLS 1.3 加密
  • 支持证书固定（Certificate Pinning）
  • 敏感数据在日志中应脱敏存储

NFR-010: 密钥管理：

  • 数据库凭证和 API 密钥应使用专用密钥管理系统
  • 支持密钥的定期轮换
  • 支持硬件安全模块（HSM）集成

6.3 审计与合规

本节规定了系统的审计日志及合规要求，确保系统的所有操作均可追溯。

NFR-011: 完整审计日志：

  • 系统应记录所有数据访问和操作行为
  • 审计日志包括：用户 ID、时间戳、操作类型、查询内容、访问数据范围、执行结果
  • 审计日志应防篡改，保留期限不少于 1 年

NFR-012: 数据血缘追踪：

  • 系统应维护数据血缘关系
  • 支持从报表追溯到原始数据源
  • 支持血缘影响分析（变更影响范围）

NFR-013: GDPR 合规：

  • 支持用户数据导出（数据可携带权）
  • 支持用户数据删除（被遗忘权）
  • 支持数据处理活动的记录和报告

NFR-014: SOC2 合规：

  • 满足 SOC2 Type II 控制要求
  • 支持控制证据的自动收集
  • 支持审计员的只读访问

6.4 可扩展性

本节明确了系统的扩展机制和多租户能力，为未来业务的快速增长提供技术保障。

NFR-015: 水平扩展能力：

  • 系统应支持水平扩展以应对负载增长
  • 无状态服务设计，支持负载均衡
  • 数据库层支持读写分离和分片

NFR-016: 多租户架构：

  • 系统应支持多租户部署
  • 租户之间的数据隔离粒度不低于 Schema 级别
  • 支持租户级别的资源配额和计费

NFR-017: 插件扩展机制：

  • 系统应提供插件机制支持自定义功能
  • 支持自定义数据源连接器
  • 支持自定义分析算法和可视化组件

6.5 可靠性

本节定义了系统在面对故障时的韧性设计与恢复策略。

NFR-018: 故障转移：

  • 系统应支持高可用部署
  • 关键组件应有主备或集群部署
  • 支持自动故障检测和切换

NFR-019: 健康检查：

  • 系统应提供健康检查端点
  • 支持组件级别的健康状态报告
  • 支持依赖服务（数据库、缓存、LLM）的健康监控

NFR-020: 优雅降级：

  • 当部分服务不可用时，系统应优雅降级
  • 核心查询功能在依赖服务故障时仍可工作（使用缓存或简化逻辑）
  • 向用户明确提示当前的服务限制

NFR-021: 数据备份：

  • 系统配置和元数据应定期备份
  • 支持增量备份和全量备份
  • 支持跨区域备份容灾

6.6 数据源连接可靠性

本节规定了对底层数据源的连接池管理及异常熔断机制，避免拖垮业务数据库。

NFR-022: 连接池管理：

  • 系统应为每个数据源维护独立的连接池
  • 连接池大小、空闲超时、最大生命周期均可配置
  • 支持连接池监控和告警（耗尽、泄漏）

NFR-023: 连接故障恢复：

  • 数据源连接失败时应自动重试，采用指数退避策略（最大重试 3 次）
  • 支持连接健康检测（定期心跳检查）
  • 引入熔断机制：当某个数据源连续失败达到设定阈值（如 5 分钟内失败 10 次），应自动熔断该数据源连接池，避免雪崩效应拖垮 Agent 服务
  • 连接不可用时应自动触发降级策略并通知用户

NFR-024: 连接超时控制：

  • 连接建立超时：默认 10 秒，可配置
  • 查询执行超时：默认 30 秒，可配置
  • 超时后应自动释放连接资源并返回友好提示

NFR-025: LLM 幻觉监控：

  • 系统应建立指标监控用户的“点踩率（Thumbs Down Rate）”
  • 当针对某个知识库或表结构的 NL2SQL 准确率突然下降或点踩率飙升时（如因底层模型更新导致的数据漂移），能够自动触发告警通知管理员介入

NFR-026: 多模型 Fallback 自动降级：

  • 系统需支持大模型 API 超时、限流或宕机时的自动降级切换
  • 当主力模型（如 GPT-4o）不可用时，请求必须能无缝 Fallback 至备选模型（如 GPT-4o-mini 或本地部署模型），以保障核心对话取数链路的连续性

7. 人机协作模型

系统拒绝采用黑盒化的完全自主范式，而是创新性地引入了基于置信度的“人类在环（Human-in-the-loop）”审批干预机制，既保证了自动化执行的高效性，又通过渐进式授权与反馈回路构建了牢固的业务信任基石。

本节详细定义了触发人工介入的具体风险阈值与上下文挂起/恢复流程，是 L2 级别“条件自动化”在工程上的具象体现。

7.1 审批机制设计

为平衡效率与安全，系统制定了明确的审批触发阈值，确保关键操作始终有人工介入。

审批触发条件：

触发条件 审批级别 审批人 说明
基础设施变更 高 IT 管理员 新增数据源、修改连接配置
访问策略变更 高 数据 Owner + 安全团队 权限调整、角色变更
跨工作流任务 中 数据 Owner 涉及多个业务域的分析
高风险操作 高 IT 管理员 + 业务负责人 数据删除、批量更新
低置信度结果 中 终端用户 模型置信度 < 阈值
高成本查询 低 系统自动 超出配额时提示确认

审批流程：

# 任务审批路由流转示意图
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ 任务提交 │ → │ 风险评估 │ → │ 审批路由 │ → │ 人工审批 │ → │ 执行/拒绝│
└─────────┘    └─────────┘    └─────────┘    └─────────┘    └─────────┘
                    │               │               │
                    ▼               ▼               ▼
               ┌─────────┐    ┌─────────┐    ┌─────────┐
               │ 自动通过 │    │ 升级规则 │    │ 审批委托 │
               │ (低风险) │    │ (超时)   │    │ (缺席)   │
               └─────────┘    └─────────┘    └─────────┘

7.2 置信度分级

本节定义了系统基于不同执行置信度所采取的分级干预策略，确保回答的准确度。

置信度评估维度：

  1. 语义理解置信度：NLU 对查询意图的理解程度
  2. 映射置信度：业务术语到数据模型的映射确定性
  3. 结果置信度：查询结果的统计合理性
  4. 安全置信度：权限边界和敏感数据处理的确定性

分级处理流程：

# 基于模型置信度的分级处理策略矩阵
┌─────────────────────────────────────────────────────────────────┐
│                        置信度分级处理                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  高置信度 (> 90%)                                               │
│  ├── 直接执行，无需确认                                          │
│  └── 记录日志，用于持续学习                                      │
│                                                                 │
│  中置信度 (70% - 90%)                                           │
│  ├── 展示执行计划，请求用户确认                                  │
│  ├── 提供备选方案（如果有）                                      │
│  └── 用户确认后执行                                              │
│                                                                 │
│  低置信度 (< 70%)                                               │
│  ├── 停止自动执行                                                │
│  ├── 向用户请求澄清                                              │
│  ├── 提供可能的意图选项                                          │
│  └── 转人工处理（可选）                                          │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

7.3 反馈回路

本节描述了系统基于用户反馈进行持续自我演进的模型训练链路。

持续学习机制：

# 闭环持续学习与反馈机制数据流
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ 用户反馈 │  →  │ 质量评估 │ → │ 样本筛选  │  → │ 模型微调 │
└─────────┘    └─────────┘    └─────────┘    └─────────┘
                                              │
                                              ▼
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ 效果监控 │  ← │ A/B 测试 │  ← │ 灰度发布 │  ← │ 模型验证  │
└─────────┘    └─────────┘    └─────────┘    └─────────┘

本节探讨了如何通过“透明化推导过程”避免用户对大模型产生过度依赖或盲目不信任，建立健康的人机协同边界。

7.4 信任校准

人机协作模型中的信任建立机制通过 FR-065: 透明度展示、FR-066: 渐进式授权 和 FR-067: 信任度评分 实现，详见第 5.7.2 节。

8. 技术选型建议

在核心组件的实现路径上，产品倾向于解耦性高、不绑定单一公有云厂商的开放生态组件。通过整合高性能的本地沙箱引擎（如 DuckDB）、标准化的语义层工具（如 dbt/Cube），搭配可插拔的异构大语言模型（闭源高精度/开源低成本），构筑兼顾成本与性能的最佳实践组合。

8.1 大语言模型

本节评估并推荐了适用于不同场景和安全要求的基础大模型。

以下模型推荐基于当前的技术评估，实际选型时应根据当时最新的基准测试结果和成本效益重新评估。

使用场景 推荐模型 备选方案 选型理由
高精度 NL2SQL GPT-4o / Claude 3.5 Sonnet Qwen-72B / DeepSeek-V2 复杂推理能力强，SQL 准确性高
成本敏感场景 GPT-4o-mini / Claude 3 Haiku Qwen-7B / GLM-4-9B 性价比高，适合高频查询
私有化部署 Llama 3.1 70B / Qwen-72B Baichuan2-13B 支持本地部署，数据不出域
领域特化 Fine-tuned CodeLlama Fine-tuned StarCoder 针对企业 Schema 微调

多模型 Fallback 策略（高可用保障）： 系统在架构上必须支持多模型级联降级。当主力模型（如 GPT-4o）遭遇 API 超时、限流（Rate Limit）或宕机时，系统应自动且无感地将请求 Fallback 至备选模型（如 GPT-4o-mini 或本地私有化部署模型），确保核心对话取数链路的连续性，而非直接向用户抛出异常报错。

8.2 Agent 框架

本节对比了当前主流的 Agent 开发框架及其在企业级应用中的适配度。

框架 适用场景 优势 劣势
LangChain 通用场景 生态丰富，集成度高 学习曲线较陡
LlamaIndex 知识密集型 检索增强能力强 复杂工作流支持有限
AutoGen 多 Agent 协作 对话式编程，灵活 生产化程度待验证
Semantic Kernel 微软生态 与 Azure 集成好 跨平台支持有限

8.3 语义层

本节列举了负责业务逻辑转换与指标统一的核心组件候选。

技术 用途 推荐场景
dbt 数据转换和建模 已有 dbt 生态的企业
Apache Iceberg 表格式管理 数据湖场景
Cube.js 语义层和 API 层 需要统一指标服务
LookML (Looker) 语义建模 已有 Looker 投资

8.4 执行引擎

本节根据数据处理的规模与场景，推荐了相应的高性能查询引擎。

引擎 适用场景 特点
DuckDB 中小规模分析，本地执行 轻量，高性能，易嵌入
Apache Spark 大规模数据处理 分布式，生态丰富
Presto/Trino 联邦查询 跨源查询，低延迟
Apache Arrow 内存计算 列式存储，向量化执行

8.5 身份认证与授权

本节给出了系统接入企业统一身份认证体系的标准方案推荐。

组件 推荐方案 说明
身份提供商 Okta / Azure AD / Keycloak SSO 集成
授权框架 Casbin / Open Policy Agent 细粒度权限控制
数据库 RBAC 原生 RBAC + 代理层检查 双重保险

8.6 数据治理

本节梳理了可与 Data Agent 深度整合的数据质量与元数据管理平台。

组件 推荐方案 用途
元数据管理 OpenMetadata / DataHub 数据目录和血缘
数据质量 Great Expectations / Soda 质量规则和执行
主数据管理 Collibra / Informatica 企业级治理

8.7 监控与可观测性

本节定义了保障系统可用性及快速排障的监控运维工具栈。

组件 推荐方案 用途
APM DataDog / New Relic 应用性能监控
日志 ELK Stack / Loki 日志收集和分析
指标 Prometheus + Grafana 指标监控和告警
链路追踪 Jaeger / Zipkin 分布式追踪

9. 演进路线

产品的生命周期管理采取了“敏捷验证 -> 企业就绪 -> 自主升维”的务实演进策略。从最初三个月内打通 NL2SQL 单表取数 MVP 闭环，再到一年内铺开多租户与全局安全基建，最终实现基于因果推理和主动洞察的 L3 级数据科学家委托代理模式。

9.1 MVP 阶段（3-6 个月）

本阶段的核心是快速验证系统能力并在受限场景下建立初步闭环。为降低初期“模型幻觉”与数据口径失控风险，本阶段将优先落地“存量数据资产的 AI 智能化盘活”策略（详见配套文档《企业级 Data Agent 敏捷落地规划：存量数据资产的 AI 智能化盘活》）。

目标：通过技能挂载（Skill Integration）优先盘活已有 API，快速闭环并建立业务信任，同时验证基础 NL2SQL 能力。

核心功能：

  • NL2SQL 基础能力（单表查询、简单 JOIN）
  • 基础可视化（自动图表推荐）
  • 基础身份认证和审计
  • 支持 2-3 种主流数据源（MySQL、PostgreSQL、Snowflake）
  • 明确排除：MVP 阶段不包含第 5.5 节“数据准备能力”及复杂的第三方元数据集成

技术重点：

  • 语义模型基础框架
  • 查询缓存机制
  • 基础审批工作流

成功标准：

  • NL2SQL 准确率：在封闭的 10 张核心宽表测试集上 > 85%，在全量表上 > 60%
  • 查询响应时间 P50 < 5s
  • 早期用户满意度 > 4.0/5.0

9.2 企业就绪阶段（6-12 个月）

本阶段旨在完善多租户、审计与安全特性，为全面推广铺平道路。

目标：满足企业级部署要求

核心功能：

  • 多租户架构
  • 完整审计和数据血缘
  • 高级安全特性（RLS/CLS/脱敏）
  • 扩展数据源支持（覆盖主流数据仓库和文件）
  • 报告自动生成和调度

技术重点：

  • 性能优化（查询优化、缓存策略）
  • 高可用架构
  • 企业集成（SSO、ERP 连接器）

成功标准：

  • 系统可用性 > 99.5%
  • 支持 500+ 并发用户
  • 通过 SOC2 Type II 审计

9.3 高级能力与 L3 过渡（12+ 个月）

本阶段将系统自主性推向新高度，实现从被动响应到主动洞察的跨越。

目标：实现高级分析能力，向 L3 演进

核心功能：

  • 工作流编排（多步骤分析自动化）
  • 自动数据准备（智能清洗、集成）
  • 预测性分析
  • 主动式洞察（异常自动发现）
  • 自然语言数据探索

技术重点：

  • Agent 协作框架
  • 因果推理能力
  • 持续学习系统

成功标准：

  • 复杂分析任务自动化率 > 50%
  • 用户自助率 > 80%
  • 数据准备时间减少 70%

10. 风险与缓解

作为前沿的 AI 数据基础设施项目，不仅要面对 LLM 幻觉（Hallucination）与自然语言理解的固有多义性难题，还需要应对诸如企业数据安全合规、系统级联雪崩失效等重大工程和治理风险。本节为核心威胁矩阵设立了详尽的干预熔断手段。

10.1 技术风险

本节列举了在架构设计与模型应用层面的技术障碍及应对手段。

风险 影响 概率 缓解措施
NL2SQL 准确性不足 高 中 查询验证和人工确认机制 / 白名单 SQL 模式 / 持续微调优化
权限绕过 高 低 Agent 层独立权限检查 / 多重验证机制 / 渗透测试
级联错误 中 中 PCS 原理验证 / 中间结果检查点 / 错误隔离机制
LLM 幻觉 中 中 结果可验证性设计 / 置信度评分 / 人工审核机制
性能瓶颈 中 中 查询优化和缓存 / 资源隔离和限流 / 水平扩展能力

10.2 治理风险

本节针对数据安全及合规领域的潜在风险提出了前置规避策略。

风险 影响 概率 缓解措施
数据泄露 高 低 端到端加密 / VPC 隔离 / 数据脱敏 / 最小权限原则
合规违规 高 低 合规检查清单 / 定期审计 / 法务团队审核
模型偏见 中 中 多样化测试数据 / 偏见检测机制 / 公平性评估
数据质量问题 中 高 数据质量监控 / 质量门禁 / 数据血缘追踪

10.3 运营风险

本节着眼于系统上线后的持续运营挑战，包括用户接纳与外部依赖。

风险 影响 概率 缓解措施
LLM 模型漂移 中 中 定期基准测试 / 模型版本管理 / A/B 测试验证
供应商锁定 中 中 抽象层设计 / 多供应商策略 / 自研能力储备
人才短缺 中 中 培训计划 / 文档和知识库 / 外部专家支持
用户接受度低 高 中 渐进式推广 / 用户培训 / 反馈闭环优化

11. 成功指标

通过对工程系统的 APM 时延约束（如 P50 延迟要求、多级缓存命中率）与业务团队的使用深度（如每日单兵调用量、工单缩减率）进行北极星指标（North Star Metric）对齐，确保该数据中台建设最终能够转化为实打实的企业人效杠杆。

11.1 技术指标

本节量化了系统底层的性能、稳定性和准确性预期，作为技术团队的北极星指标。

指标 Phase 1 目标 Phase 2 目标 Phase 3 目标 测量方法
NL2SQL 准确率 核心宽表 > 85% ； 全量表 > 60% > 90% > 95% 人工标注测试集
查询延迟 P50 < 5s < 3s < 2s APM 监控
查询延迟 P99 < 30s < 20s < 10s APM 监控
系统可用性 > 99% > 99.5% > 99.9% 监控告警
缓存命中率 > 40% > 60% > 70% 缓存监控
用户反馈满意度 > 4.0/5 > 4.2/5 > 4.5/5 用户调研

11.2 业务指标

本节以最终商业价值为导向，定义了产品成功推行的业务表现评估维度。

指标 定义 目标
用户采用率 月活跃用户数 / 目标用户总数 > 60% (Year 1)
日均查询量 平均每用户每天发起的查询数 > 5 次/人/天
语义模型覆盖率 企业 80% 的常见查询涉及的字段已被映射为业务术语 > 80%
模型 Token 消耗周环比 每周 Token 消耗量较上周的增长/下降比例（成本控制指标） 稳定在预期预算内
数据请求工单减少率 (原工单数 - 现工单数) / 原工单数 > 50%
洞察获取时间 从提出问题到获得洞察的平均时间 从 2 天 → 5 分钟
自助服务率 无需人工介入完成的查询占比 > 80%
报告自动化率 自动生成的报告占比 > 60%

11.3 安全与数据质量指标

本节强调了系统在红线合规与数据置信度方面的强制性达成标准。

指标 定义 目标 测量方法
权限绕过事件数 经审计确认的权限绕过成功事件数 0 次/年 安全审计
数据泄露事件数 未授权数据访问或外泄事件数 0 次/年 安全监控
审计日志完整率 审计日志覆盖的操作占比 100% 日志分析
数据准确性评分 查询结果与人工验证结果的一致率 > 95% 抽样人工验证
敏感数据脱敏覆盖率 已配置脱敏规则的敏感字段占比 100% 元数据扫描

12. 竞品对比

立足于目前 Snowflake Cortex Analyst 强绑云原生的封闭生态，以及 Databricks Genie 等数据仓库衍生插件工具的市场格局，我们的方案通过提供独立解耦的语义层映射与中立的数据接入探针，实现真正的跨云异构环境联邦分析。

12.1 竞品对比分析

本节横向比对了业界领先的同类产品，分析了它们的优势与局限。

产品 厂商 定位 核心优势 局限性 本系统差异化
Databricks Genie Databricks 数据仓库原生 AI 助手 与 Unity Catalog 深度集成，Knowledge Store 强大 强绑定 Databricks 生态 多数据源中立性，开放架构
Snowflake Cortex Analyst Snowflake 云数仓 AI 分析 Semantic Views，企业级安全 仅支持 Snowflake 跨平台支持，混合数据源
BigQuery Data Canvas Google 云数仓可视化分析 与 GCP 生态集成，可视化能力强 仅限 BigQuery 私有化部署支持，企业安全
Microsoft Fabric Copilot Microsoft 统一数据分析平台 与 Office 365 集成，生态完整 强绑定 Azure 开放 API，第三方集成友好
ThoughtSpot Spotter ThoughtSpot 搜索式 BI 领导者 搜索体验成熟，性能优化好 成本较高，学习曲线 更强的 NL2SQL 能力，L2 人机协作

12.2 关键差异化策略

本节归纳了基于竞品分析提炼出的系统核心竞争壁垒与护城河。

  1. 开放架构：不绑定特定数据平台，支持混合数据源
  2. L2 人机协作：更精细的人类在环控制，适合监管严格行业
  3. 语义模型优先：强调语义层建设，降低维护成本
  4. 企业级安全：原生支持 RLS/CLS/脱敏等企业安全需求
  5. 渐进式智能化：从 L2 向 L3 演进，而非一步到位

13. 参考文献

[1] Yizhang Zhu et al., “A Survey of Data Agents: Emerging Paradigm or Overstated Hype?,” arXiv preprint arXiv:2510.23587, 2025. [2] Boyan Li et al., “Alpha-SQL: Zero-Shot Text-to-SQL using Monte Carlo Tree Search,” arXiv preprint arXiv:2502.17248, 2025. [3] Databricks. Databricks Genie Technical Documentation[EB/OL]. [2026-04-07]. https://docs.databricks.com/. [4] Snowflake. Snowflake Cortex Analyst Documentation[EB/OL]. [2026-04-07]. https://docs.snowflake.com/. [5] SAE International. (2021). SAE J3016 - Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles. [6] Geliang Ouyang et al., “nvAgent: Automated Data Visualization from Natural Language via Collaborative Agent Workflow,” arXiv preprint arXiv:2502.05036, 2025.