第一章 问题的本质：企业数据的结构性困境

1.1 一个真实的业务场景

让我们从一个具体场景开始。

某药企的省区经理，想要了解："我这个月在广东省的科莫非，进去了哪些医院？哪些科室在用？流向和去年同期相比是什么情况？"

这个问题对于一个熟悉 ERP 的业务人员来说，意味着：

1. 打开 ERP 系统，找到流向查询模块
2. 选择省份、时间范围、品种
3. 手工导出 Excel
4. 打开 Excel，手工筛选、加总、比对去年同期
5. 整理成一份汇报材料

这个过程可能需要 数小时。

现在，把这个场景换成："帮我生成这个月广东省的科莫非医院进院分析报告，包括竞争格局、药剂科攻关路径、重点科室 KOL 分析"。

这就是我们正在试图解决的问题。

1.2 问题的三个层面

这个问题并不是一个单纯的技术问题。它涉及三个相互关联的层面：

1.2.1 数据层面：数据在系统里，但 AI 读不懂

ERP 和数据库存储了业务数据，但数据的业务语义隐含在代码里，而不是表名和字段名里。

一个具体的例子：

ERP 数据库的真实表名：
 t_drug_sale_2024
 t_hospital_info
 t_ida_patient

ERP 数据库的真实字段名：
 DRUG_ID, SALE_AMT, REGION_ID, FLOW_STATUS
 HOSP_ID, HOSP_LEVEL, HOSP_TYPE
 IDA_PATIENT_CNT, FLOW_QTY

问题的根源：ERP 系统的数据模型是给开发人员设计的，不是给 AI 设计的。业务逻辑存在于开发人员的代码注释里，而不是机器可读的元数据里。

1.2.2 逻辑层面：业务逻辑在表单里，变化需要改代码

在传统 ERP 架构中，业务逻辑以表单/流程/报表的形式硬编码在系统中：

业务需求 → ERP 顾问提出 → 开发排期 → 设计 → 开发 → 测试 → 上线
 ↑
 一个"简单"的需求变更，需要数周甚至数月

1.2.3 交互层面：人机交互是表单式的，而不是对话式的

传统 ERP 的交互模式是表单驱动的：

• 用户在预设的表单里选择筛选条件
• 系统返回预设格式的结果
• 结果以固定的报表形式呈现

1.3 为什么这个问题现在才凸显

这三个层面的问题在 ERP 系统存在了二十多年，但为什么现在才成为焦点？

1.3.1 LLM 第一次让机器能够理解业务语义

在 LLM 出现之前，AI 处理结构化业务数据的能力非常有限。GPT-4、Claude 等 LLM 的出现，第一次让机器能够：

• 理解"流向数量"、"IDA 患者"、"达成率"这样的业务术语
• 将业务术语映射到数据库字段
• 在多个数据源之间进行关联推理
• 生成符合业务规范的文字报告

1.3.2 Agent 架构让多步骤复杂任务成为可能

生成一份医院调研报告，需要：
1. 查询 ERP 数据（流向、患者数、进院状态）
2. 检索知识库（竞品信息、学术文献）
3. 搜索网络（医院信息、KOL 资料）
4. 汇总生成报告
5. 质量审核
6. 推送通知

单个 AI 模型无法完成这样的任务链。Multi-Agent 协作架构让这成为可能。

1.3.3 Skill 体系让业务逻辑可以文档化

在 AI Native 架构中，业务逻辑可以以文档化的 Skill 形式存在——一份包含业务定义、API 规范、调用脚本的技能包。

这意味着：业务人员（通过 AI）可以修改业务逻辑，而不需要经过开发流程。

1.4 问题的边界与约束

核心约束

1.5 问题定义

企业智能业务平台的核心问题是：在不改变现有 ERP 系统的前提下，如何让 AI Agent 能够理解 ERP 数据的业务语义，并以自然语言为接口，向业务人员提供智能化的数据分析和报告生成服务。

这个问题包含三个子问题：

1. 语义映射问题：如何将 ERP 的表字段映射为 AI 能理解业务概念？
2. 交互范式问题：如何以"报告模板"替代"表单/报表"，作为业务逻辑的载体？
3. 协作架构问题：如何通过 Multi-Agent 协作完成复杂的数据分析和报告生成任务？

第二章 领域专家的认知与行业解决方案

2.1 领域专家如何定义这个问题

2.1.1 Text-to-SQL / Natural Language to SQL（NL2SQL）

核心问题：用户用自然语言提问，AI 自动生成 SQL 查询语句，从数据库提取数据。

代表项目：Vanna.ai、Dataherald、Wren AI、Awesome-Text2SQL

关键不是让 AI 更好地猜 SQL，而是先让 AI 理解业务语义。

2.1.2 Semantic Layer（语义层）

核心问题：在数据库和 AI 之间建立一层"业务语义映射"，让 AI 理解"流向数量"而不是 FLOW_QTY 字段。

代表产品：Cube.dev、dbt Semantic Layer、AtScale、Prometheus

用户问题：「广东省科莫非流向最高的 10 家医院」
     ↓ 语义层翻译
AI 理解：「流向数量按省=广东、品种=科莫非、降序取 Top10」
     ↓ 映射到指标
指标定义：flow_qty（原生指标）× 品种维度 × 组织维度
     ↓ SQL 生成
SELECT hospital_name, flow_qty FROM fact_flow
WHERE province = '广东省' AND drug = '科莫非'
ORDER BY flow_qty DESC LIMIT 10

语义层不是技术基础设施，而是数据治理工具。建设语义层的本质是建立一套业务人员能够理解的指标定义体系。

2.1.3 Enterprise Knowledge Graph + RAG

核心问题：将企业的业务知识（流程、规则、术语）建立为知识图谱，AI 在回答问题时首先检索相关知识，再结合数据库查询。

仅有 schema 描述不够，需要领域知识库 + 历史查询模式来补充上下文。这正是我们的"BP 数字指标体系"和"检索指南"的价值所在。

2.1.4 AI-Native ERP（AI 原生 ERP）

代表动向：

• SAP Joule：SAP 的 AI 助手，嵌入 SAP ERP 的每个模块
• Microsoft Dynamics 365 Copilot：在 ERP/CRM 中内置自然语言数据查询
• 用友 BIP：国产 ERP 的 AI 助手，用自然语言查询财务/供应链数据

SAP 在 2025 年底的 Cloud ERP Private 版本中，核心升级就是 Semantic Data Foundation（语义数据基础层）——明确承认了语义层是 AI 和 ERP 数据之间的关键桥接。

2.2 主要玩家及其解决方案

2.3 开源解决方案

Vanna.ai

定位：Text-to-SQL RAG 框架，专门针对企业私有数据库。

用户问题 → RAG（检索相似 SQL + schema 上下文）→ LLM → SQL → 执行 → 答案
 ↑
 训练数据：历史 SQL 查询对（用户自己提供）

优势：开源（MIT License），支持自定义训练，支持 PostgreSQL、MySQL、SQL Server、Snowflake 等主流数据库

局限：主要解决 Text-to-SQL 问题，不解决"生成完整报告"的问题

Cube.dev

定位：开源语义层平台，专为 LLM & AI 应用设计。

业务人员 → 定义指标（Revenue, Flow_Qty）+ 维度（Province, Drug）
     ↓
Cube 自动生成 REST/GraphQL/SQL API
     ↓
AI 应用调用 API，AI 不知道底层数据库结构

优势：开源（Apache 2.0），支持 dbt 集成，自动生成 API，缓存层减少数据库压力

dbt Semantic Layer

定位：在 dbt（数据转换工具）生态内建的语义层。

优势：与 dbt 生态无缝集成，指标定义版本化管理，支持复杂指标

Model Context Protocol（MCP）

定位：Anthropic 提出的开放协议，标准化 LLM 与外部数据源/工具的连接。

AI 应用 ←→ MCP Server（标准化接口）←→ 外部工具/数据源
 ↑
 一次连接，处处使用

优势：开放标准（2024 年底），多厂商支持，已有 10000+ MCP Server（截至 2025 年底），安全性高

2.4 各方案的对比分析

2.5 我们的方案定位

以 Semantic Layer 为数据基础，以 Multi-Agent 协作为执行架构，以"报告模板"为业务逻辑载体，构建一套 AI Native 的企业智能业务平台。

四个关键特征：

1. 不改造 ERP：通过 PostgREST 中间层，以只读方式访问 ERP 数据
2. 自建语义层：以 BP 数字指标体系为蓝本，建立语义层（指标 + 维度 + 口径）
3. 模板即系统：以 Markdown 模板作为业务逻辑的载体，业务人员可修改模板来调整业务规则
4. Multi-Agent 协作：用 Agent Platform 的 5 种协作模式处理完整链路

一、核心范式：报告模板即系统

1.1 传统 ERP 的局限

传统 ERP 系统以表单和流程为核心：

定义表单/流程 → 开发 ERP 模块 → 用户填表单 → 流程审批 → 生成报告
 ↑
 变化时需要改代码、排期，开发、测试、上线

• 业务逻辑硬编码在代码里：每当业务规则变化，必须走完整的开发流程
• 表单有边界：用户只能填写表单里预设的字段，无法容纳业务现场的真实信息
• 数据是孤岛：ERP 里的数据和其他系统割裂，跨系统分析困难
• 变化成本高：一个看似简单的需求变更，往往需要数周甚至数月的开发周期

1.2 新范式：报告模板即系统

业务逻辑不再以代码形式存在，而是以文档化的"报告模板"存在。

业务讨论（对话）→ 输出报告模板（= 业务定义）
     ↓
AI 从多源提取数据 → 填充报告模板
     ↓
人工复核 → 完成
     ↓
模板变了？→ 改模板，不改系统

1.3 为什么现在可以做到

1. LLM 能处理结构化 + 非结构化数据：ERP 数据（结构化）和工作协同文档/语音（非结构化）可以被同一个 AI Agent 整合处理
2. Agent Platform 提供多 Agent 协作引擎：多个专业 Agent 可以并行工作
3. Skill 体系让业务逻辑快速迭代：Skill 是一份文档化的业务知识，可以通过与 AI 对话快速修改和更新

二、整体架构

2.1 三层架构

┌─────────────────────────────────────────────┐
│ 用户交互层                                   │
│ 入口：玄关 IM · 钉钉 · Discord · Web        │
│ 自然语言对话 ───────────────────▶ 分析报告/通知推送 │
└─────────────────────────────────────────────┘
                      │
                      ▼
┌─────────────────────────────────────────────┐
│ AI 协作层（Agent Platform）                   │
│  Orchestrator Agent · Gen-Verifier Agent    │
│  Team Workers · Event Bus · Shared State   │
│  Approval Flow                              │
└─────────────────────────────────────────────┘
                      │
                      ▼
┌─────────────────────────────────────────────┐
│ 数据层                                       │
│  报告模板体系  ·  ERP 数据语义层             │
│  工作协同系统  ·  业务系统 Skill             │
└─────────────────────────────────────────────┘
                      │
                      ▼
┌─────────────────────────────────────────────┐
│ ★★★ 数据连接层（需与 ERP 团队共建）★★★        │
│  ERP 数据库（只读）──▶ PostgREST ──▶ REST API│
└─────────────────────────────────────────────┘

2.2 Agent 角色设计

三、报告模板体系

3.1 模板是业务逻辑的载体

报告模板不是"填写表单"，而是一份完整业务定义的文档：

# 医院品种调研报告

## 一、基本信息
- 医院名称：[ERP自动填充]
- 药品名称：[ERP自动填充]
- 调研日期：{date}

## 二、该医院相关数据（ERP自动填充）
- 该品种近6个月销售数据：{flow_data}
- 相关科室医生名单：{doctor_list}

## 三、实地调研（业务人员填写）
### 3.1 科室情况
{自由文本，业务人员填写}

## 四、综合分析（AI自动生成）
{AI根据以上信息生成分析结论}

3.3 模板类型

四、ERP 数据语义层

4.1 核心问题：AI 如何理解 ERP 数据

4.2 数字字典：指标 Metadata 标准（17 个字段）

4.3 三层指标体系

4.4 九大指标分类

五、数据连接层

5.1 推荐路径：PostgREST 中间层

5.4 物理取数路径标准

格式：系统.库.表.字段

示例：
FSS.NC_GL.GL_VOUCHER.ExpenseAmount
FR.销售跟踪表.FlowQty

六、典型工作流

6.1 工作流 1：医院品种调研（完整链路）

用户：「帮我们评估一下 XXX 药品进入北京协和医院的可行性」

1. 对话 Agent → 解析意图 → 创建 Goal（mode: orchestrator）

2. Query Planner → 拆解任务：
   ├── Task A: ERP Data Agent → 查该药品近6个月流向数据
   ├── Task B: ERP Data Agent → 查该医院相关科室医生名单
   ├── Task C: ERP Data Agent → 查该品种历史销售数据
   ├── Task D: 工作协同 Agent → 检查是否有该医院的既往调研记录
   └── Task E: 知识库 Agent → 检索相关市场策略文档

3. Team 模式 → 并行执行 Task A/B/C/D/E

4. Shared State → 汇总中间结果

5. 报告组装 Agent → 生成「医院品种调研报告」初稿

6. Gen-Verifier → 质量审核 Agent 审核报告

7. Approval Flow → 推送给业务负责人复核

8. Event Bus → 发布「调研完成」事件 → 更新看板、通知相关人员

6.3 工作流 3：大规模并行调研（万级医院）

场景：某新药上市 → 对全国 10,000 家医院同步发起调研

1. 用户定义调研模板（与 AI 对话生成）
2. 用户导入医院列表 + 品种列表
3. Orchestrator → 创建 Goal（mode: team，maxConcurrency: 100）
4. Team → 100 个 Worker 并行执行
5. Aggregator → 汇总 10,000 份报告
6. 生成「全国市场调研总报告」
7. 推送结果 → 钉钉/看板

七、Skill 体系

7.1 已有 Skill（dev-guide 规范）

九、阶段规划

Phase 0：基础能力 ✅ 已完成

Phase 1：ERP 数据连接层（共创核心）

阶段总览

十、与 ERP 团队共创的关键议题

10.1 数据连接路径选择

10.2 数据语义梳理

10.3 初期切入模块

十一、下一步

附录 B：核心概念对照