Skip to content

README.md

Latest commit

 

History

History
831 lines (615 loc) · 32.3 KB

README.md

File metadata and controls

831 lines (615 loc) · 32.3 KB
Raw

AI Native ERP

用自然语言驱动企业运营的开源 AI-Native ERP

Talk to your ERP. Governed agents execute real business operations.

.NET React Semantic Kernel License: MIT

语言 / Language: 中文 · English

总介绍 · 为什么做 · 项目一览 · 适合谁 · 三分钟体验 · 如何运行 · 架构 · 文档

项目总介绍

AI Native ERP 是一套开源的、可完整运行的 AI-Native 企业资源规划（ERP）参考实现（MIT License）。
它不是「在传统 ERP 旁边挂一个聊天框」，而是从架构上把 自然语言 设计为企业系统的一等入口，同时用工程化的 AI 治理链路 保证业务可信、可测、可审计。

它解决什么问题？

在企业里，ERP 往往功能齐全，但使用成本高：记菜单、记字段、跨模块找数、制度与实时数据分属不同系统。大模型普及后，很多产品选择「加 Chatbot」，却常陷入幻觉、越权写库、知识与现实数据混淆、出事无法追溯等问题。

AI Native ERP 提供一条可落地的中间路线：

用户说人话 → 识别业务域与意图 → Agent 编排受控 Tool → Application Service 执行业务
→ 结构化结果 + 自然语言解释 → 写操作草稿确认 → 全程审计与 Trace

核心能力全景

层面 包含什么
ERP 业务 销售、采购、库存/仓储、财务、人力资源、生产、流程审批、审计日志
AI 对话 非流式 / SSE 流式对话、仪表盘分析、全局 AI 侧边栏与命令面板
Agent 编排 Coordinator + 7 个领域 Agent（Sales / Purchase / Inventory / Finance / HR / Production / General）
意图识别 28 个 Intent Schema；先 Domain 后 Intent；歧义时 Clarify，不猜测
业务 Tool 28+ 受控 Tool，覆盖查询、分析、创建草稿、审批；带风险等级与人工确认
知识库 RAG Qdrant 向量检索 + 约 2100 条制度/流程示例；正文与意图训练样本分池
安全治理 Guardrails（注入/敏感/内容安全）、权限校验、Human-in-the-Loop、Agent Trace
前端体验 React 18 + Ant Design：仪表盘、业务页、AI 助手、流式交互
工程配套 分层 .NET 解决方案、单元/集成测试、Swagger、Docker Compose、中英文文档

三条设计原则

  1. LLM 负责理解，后端负责定夺，人负责确认高风险动作
    模型只提出候选 Intent 与 Slots；最终参数、权限、规则与执行由后端 Application Service 决定。

  2. 知识归 RAG，数据归 Service
    「采购流程怎么操作」走知识库；「本月采购了多少」走采购业务 Tool——不混在一个检索里。

  3. 写操作必须可拒绝、可确认、可回放
    创建订单等动作先出草稿，用户确认后再落库；审批类操作叠加权限与审计。

技术底座

层级 技术选型
后端 .NET 10、ASP.NET Core Web API、EF Core 10
前端 React 18、Vite 5、Ant Design 5
AI / Agent DeepSeek、Microsoft Semantic Kernel / Agent Framework
向量与嵌入 Qdrant、Ollama（nomic-embed-text）
数据 SQL Server（业务数据）、Serilog（日志）
认证与测试 JWT Bearer、xUnit、Vitest、Playwright

项目定位
是什么 可 fork、可扩展的 Agentic ERP 开源样板工程
不是什么 万能 SQL 助手、纯 Prompt Demo、开箱 SaaS 云服务
适合 技术评估、学习 Agent+ERP 落地、Demo 演示、二次开发、学术参考
许可 MIT — 可自由使用、修改与商用（保留版权声明）

想快速建立直觉：读下方 真实场景 → 三分钟体验 → 如何运行。
想深入设计：见 ARCHITECTURE.md、产品理念、AI 治理。

先讲一个真实场景

周一早上，销售主管打开系统，没有先点十层菜单，而是直接问：

「本月华东区销售额怎么样？有没有明显下滑的客户？」

系统不是甩一段空泛的 AI 总结，而是：

  1. 识别这是 Sales / 分析 意图
  2. 调用受控的销售报表与趋势 Tool
  3. 从 SQL Server 取出真实业务数据
  4. 用自然语言解释结果，并保留可追溯的 Agent Trace

旁边的 HR 同事问的是：

「销售部有多少员工？」

这句话里有「销售」两个字，但系统会把它路由到 HR，而不是销售业绩——因为「员工」属于组织人事问题。这种边界，正是企业里最容易被「聊天机器人 ERP」搞错的地方。

这就是 AI Native ERP 想证明的事：
自然语言可以成为企业系统的一等入口，但权限、规则、审计和确认，绝不能交给模型自由发挥。

为什么需要 AI-Native ERP？

过去十年，很多产品走的是这条路：

传统 ERP  +  右侧挂一个 Chatbot  =  「看起来很 AI」

问题在于：Chatbot 往往只能查 FAQ、复述文档，或者偷偷拼一段 SQL。企业真正需要的是：

痛点 传统做法 AI Native ERP 的做法
找数据慢 记菜单、记字段、导出 Excel 用自然语言提问，走受控 Tool
跨部门问法易混 靠人肉判断该点哪个模块 先 Domain 再 Intent，歧义就澄清
AI 不可控 模型直接「帮忙改数据」 草稿 → 确认 → 执行，高风险必须审批
知识与业务混在一起 一个向量库搜到底 制度/流程走 RAG，实时业务走 Application Service
出了问题说不清 聊天记录里翻 Agent Trace + 审计日志可回放

更完整的产品理念见：docs/zh/product-vision.md。

项目一览
定位 可运行、可扩展的 Agentic ERP 开源参考实现（MIT）
语言栈 .NET 10 后端 + React 18 前端
AI 栈 DeepSeek · Semantic Kernel / Agent Framework · Qdrant · Ollama
业务域 销售 · 采购 · 库存 · 财务 · HR · 生产 · 审批 · 知识库
Agent 7 个领域 Agent + Coordinator 双层编排
Tool 28+ 受控业务 Tool（查询 / 分析 / 创建 / 审批）
Intent 28 个 Schema，先 Domain 后 Intent
知识库 约 2100 条制度/流程示例，与训练样本分池
测试 域分类负样本、Tool 路由、自然语言集成测试
Demo 自动种子数据 + 多角色账号，开箱可演示

这不是「只有聊天框的 Demo」，而是一套能跑通完整链路的 ERP + AI 治理样板：从自然语言到真实数据库，从草稿确认到审计追溯，代码结构可直接 fork 做二次开发。

适合谁？

你是… 这个项目能帮你…
企业架构师 / 技术负责人 评估「AI + ERP」该怎么落地：不是贴 Chatbot，而是 Intent / Tool / Service 分层治理
.NET / 全栈开发者 学习 Agent 编排、Tool Calling、RAG 与业务服务如何解耦；直接 fork 扩展新 Tool
AI 应用工程师 参考 Domain 分类、负样本测试、Human-in-the-Loop 写操作等可复用模式
产品经理 / 业务顾问 用 Demo 数据与 场景剧本 演示「自然语言驱动 ERP」的真实体验
学生 / 研究者 获得一份可运行的 Agentic ERP 样本，而不是 PPT 或纯 Prompt 仓库
开源贡献者 在清晰边界下贡献 Intent、Tool、Guardrails、前端体验或文档

不太适合：如果你只想要「一句话改任意表」的万能 AI，或开箱即用的 SaaS 多租户云服务——本仓库刻意不做这些，见 产品理念。

仓库里有什么？

┌─────────────────────────────────────────────────────────────┐
│  完整 ERP 业务模块                                            │
│  销售 / 采购 / 仓储 / 财务 / HR / 生产 / 审批 / 审计            │
├─────────────────────────────────────────────────────────────┤
│  AI 能力层                                                    │
│  意图识别 · RAG 知识库 · Guardrails · 流式对话 · 仪表盘分析      │
├─────────────────────────────────────────────────────────────┤
│  Agent 编排层                                                 │
│  Coordinator + 7 领域 Agent + ToolGateway + 审批暂停          │
├─────────────────────────────────────────────────────────────┤
│  现代 Web 前端                                                │
│  仪表盘 · 业务页 · AI 助手 · 侧边栏 · SSE 流式                  │
├─────────────────────────────────────────────────────────────┤
│  工程化配套                                                   │
│  单元/集成测试 · Swagger · Docker Compose · 中英文文档           │
└─────────────────────────────────────────────────────────────┘

分层解决方案（src/）：

项目 你在这里找到什么
AiNativeERP.Domain 订单、库存、员工等领域实体
AiNativeERP.Application 唯一业务写库入口的应用服务
AiNativeERP.Infrastructure EF Core、DbContext、Demo 种子数据
AiNativeERP.AI LLM、DomainClassifier、IntentSchema、RAG、Guardrails
AiNativeERP.Agent MeAiAgentOrchestrator、领域 Agent、Tool 路由
AiNativeERP.WebApi REST API、JWT、Chat、Knowledge 导入
AiNativeERP.Tests 意图负样本、Tool、集成场景测试

它如何工作？

用户说一句话时，系统不会让大模型直接查库或改数据，而是走一条可测试、可审计的管道：

sequenceDiagram
    participant U as 用户
    participant UI as React 前端
    participant API as Web API
    participant G as Guardrails
    participant I as Domain / Intent
    participant A as Agent + Tool
    participant S as Application Service
    participant DB as SQL Server

    U->>UI: 自然语言提问
    UI->>API: POST /api/chat/send
    API->>G: 输入安全检查
    G->>I: 先 Domain，再 Intent
    alt 歧义或低置信度
        I-->>U: 返回 Clarify（澄清）
    else 明确意图
        I->>A: 选择 Tool / 委派领域 Agent
        A->>S: 权限 + 业务规则校验
        S->>DB: 查询或（写）草稿
        alt 写操作
            S-->>U: 草稿待确认 → 确认后执行
        else 查询 / 分析
            S-->>U: 结构化结果 + 自然语言解释
        end
    end
    Note over API,DB: 全程 Agent Trace + 审计日志
Loading

三条铁律（贯穿全仓库）：

  1. 先 Domain，后 Intent —— 「销售部员工」进 HR，不进 Sales
  2. 知识归 RAG，数据归 Service —— 制度问知识库，库存问业务 Tool
  3. 写操作必须可拒绝、可确认、可回放 —— 草稿 → 确认 → 执行

更细的治理规则：docs/zh/ai-governance.md · 架构分层：ARCHITECTURE.md

三分钟感受一下

启动后（见下方「如何运行」），用 admin / admin123 登录，打开 AI 助手 或右侧侧边栏，试这几句：

你说 系统应该怎么理解 你会看到什么
销售部有多少员工 HR 查询，不是销售 员工人数 / 名单类结果
本月销售额趋势怎么样 Sales 分析 趋势与结构化指标
有哪些库存预警 Inventory 查询 预警物料列表
采购流程怎么操作 Knowledge 检索 制度/流程正文说明
报销制度在哪里看 Knowledge 检索 报销制度说明
帮我建一张销售订单 Sales 创建（写） 先出草稿，确认后才落库

更多对话剧本与边界案例：docs/zh/user-scenarios.md。

你：销售部有多少员工？
系统：已识别为人力资源查询（而非销售业绩）…
      销售部当前在职员工 N 人，可按部门/岗位继续筛选。

你：采购流程怎么操作？
系统：已从知识库检索「采购流程说明」…
      步骤 1 … 步骤 2 …（制度正文，不是实时采购单数据）

核心亮点

维度 说明
AI-Native 架构 7 个领域 Agent + 双层编排（Coordinator → Domain Agent → Business Tool）
28+ 业务 Tool 销售、采购、库存、财务、HR、生产、知识库；带风险等级与审批约束
先 Domain 后 Intent 规则化域分类 + Schema 解析；HR/制度/流程等边界样本有单测防回归
RAG 知识库 Qdrant + 约 2100 条结构化知识示例；制度正文与意图训练样本分池
安全护栏 Prompt 注入、敏感数据、内容安全、工具风险评分
完整 ERP 模块 销售、采购、仓储、财务、HR、生产、审批流、审计日志
现代前端 React + Ant Design，AI 侧边栏、命令面板、SSE 流式对话
开箱 Demo 数据 自动种子 + 多年业务扩展数据，适合演示与分析

和「Chatbot 贴在 ERP 上」差在哪？

传统 ERP：     菜单 → 表单 → 保存
Chatbot 插件： 聊天 → 偶尔查数 → 经常幻觉
AI Native ERP：自然语言 → Domain/Intent → Tool 编排 → 业务服务 → 结构化结果 / 审批确认
Chatbot 插件 AI Native ERP
数据访问 常直连库或拼 SQL 只经 Application Service
写操作 容易「一句话就改了」 草稿 → 确认 → 执行
知识 vs 业务 混在一个检索里 RAG 管制度，Tool 管实时数据
可测试性 难 域分类负样本 + Tool 路由单测
出事 trace 弱 Agent Trace + 审计

关键原则：LLM 只生成候选 Intent 和 Slots，不直接访问数据库，不直接执行写操作。

系统架构

flowchart TB
    subgraph UI["用户入口"]
        Web["React Web"]
        Sidebar["AI Sidebar / Command Palette"]
    end

    subgraph Agent["Agent 编排层"]
        Orch["MeAiAgentOrchestrator"]
        Coord["Coordinator Agent"]
        Domains["Sales / Purchase / Inventory / Finance / HR / Production / General"]
        Tools["Tool Gateway + 28+ Tools"]
    end

    subgraph AI["AI 能力中台"]
        LLM["DeepSeek LLM"]
        Intent["DomainClassifier + IntentSchema"]
        RAG["RAG / Qdrant"]
        Guard["Guardrails"]
    end

    subgraph Biz["ERP 业务层"]
        App["Application Services"]
        WF["Approval Workflow"]
    end

    subgraph Data["数据底座"]
        SQL["SQL Server"]
        Vec["Qdrant"]
        Embed["Ollama Embedding"]
    end

    Web --> Sidebar --> Orch
    Orch --> Coord --> Domains --> Tools
    Orch --> Intent
    Intent --> RAG
    Orch --> Guard
    Tools --> App --> SQL
    RAG --> Vec
    RAG --> Embed
    App --> WF
Loading

更完整的分层说明见 ARCHITECTURE.md（英文版：ARCHITECTURE.en.md）。

功能模块

从业务视角看，这是一套能独立演示的迷你 ERP；从 AI 视角看，每个模块都对应一组受控 Tool 与 Intent Schema，而不是让模型「自由发挥」。

ERP 业务域

模块 能力示例 典型自然语言问法
销售 销售订单、客户、报价单、趋势分析、订单审批 「最近销售订单」「本月趋势怎么样」
采购 供应商、采购订单、采购审批 「待审批采购单」「供应商列表」
库存 / 仓储 现存量、出入库、盘点、库存预警 「有哪些库存预警」「查某物料库存」
财务 发票、付款、费用、应收应付 「本月应收账款」「查看费用」
人力资源 员工、部门、考勤、请假、薪资 「销售部有多少员工」「考勤统计」
生产 BOM、生产订单、工单、领料 「生产订单进度」「查看 BOM」
流程审批 待审批、通过、驳回 「有哪些待审批」
知识库 制度/流程问答 「采购流程怎么操作」「报销制度在哪看」

AI 能力

  • 意图识别：28 个 Intent Schema，覆盖 Query / Analyze / Create / Approve
  • 知识检索：query_knowledge 仅检索 knowledge_article 正文，意图训练样本独立维护
  • 流式对话：POST /api/chat/stream（SSE）
  • 仪表盘分析：POST /api/chat/analyze-dashboard
  • 可观测性：Agent Trace、事件总线、会话历史、审计日志

技术栈

层级 技术
后端 .NET 10、ASP.NET Core Web API、EF Core 10
前端 React 18、Vite 5、Ant Design 5
AI / Agent DeepSeek API、Microsoft Semantic Kernel、Microsoft.Extensions.AI
向量检索 Qdrant（gRPC）、Ollama Embedding（nomic-embed-text）
数据库 SQL Server
认证 JWT Bearer
日志 Serilog
测试 xUnit、Moq、FluentAssertions、Vitest、Playwright

如何运行

下面是从零把项目跑起来的完整步骤。建议按顺序执行：基础设施 → 配置 → 后端 → 知识库 → 前端 → 验证。

一键演示（Docker）： 配置 DEEPSEEK_API_KEY 后执行 pwsh scripts/demo-setup.ps1，会拉起 SQL / Qdrant / Ollama / WebApi / MCP / Frontend，并尝试导入知识库。前端默认 http://localhost:8080，MCP 端点 http://localhost:3001/mcp。

切换 LLM： 在 appsettings.json 设置 Chat:Provider 为 DeepSeek / OpenAI / AzureOpenAI / Ollama（兼容旧 DeepSeek:* 配置节）。

启动顺序一览

1. SQL Server          （业务数据）
2. Qdrant + Ollama     （向量检索 + Embedding，AI 知识库必需）
3. 配置 DeepSeek Key   （对话 / 推理）
4. dotnet run          （后端 API :5195）
5. 导入知识库           （首次或 Qdrant 为空时）
6. npm run dev         （前端 :3000）

环境要求

依赖 用途 是否必需
.NET 10 SDK 后端 ✅ 必需
Node.js 18+ 前端 ✅ 必需
SQL Server 2022+ 业务数据库 ✅ 必需（本地实例或 Docker）
DeepSeek API Key LLM 对话与推理 ✅ 必需
Ollama + nomic-embed-text 文本向量化 ✅ AI 功能必需
Qdrant 向量数据库 ✅ AI 知识库必需
Docker Desktop 可选，用于跑 SQL Server / Qdrant 推荐

说明： 只看 ERP 页面可以只启 SQL Server + 后端 + 前端；自然语言问答、知识库检索、意图增强 依赖 DeepSeek + Ollama + Qdrant 三者同时可用。

第一步：克隆代码

git clone https://github.com/<your-org>/ai-native-erp.git
cd ai-native-erp

第二步：启动基础设施

方式 A — Docker（推荐）

终端 1 — SQL Server：

docker compose up -d sqlserver

默认连接串（Docker）：

Server=localhost,1433;Database=AiNativeERP;User Id=sa;Password=YourStrong@Passw0rd;TrustServerCertificate=True;

终端 2 — Qdrant：

docker run --name qdrant -p 6333:6333 -p 6334:6334 qdrant/qdrant

验证：浏览器打开 http://localhost:6333/dashboard

终端 3 — Ollama：

ollama pull nomic-embed-text
ollama serve

验证：

curl http://localhost:11434/api/tags

方式 B — 本机已有 SQL Server

使用 Windows 身份验证时，默认连接串在 appsettings.json 中已配置：

Server=localhost;Database=AiNativeERP;Trusted_Connection=True;TrustServerCertificate=True;

确保本机 SQL Server 服务已启动，且当前 Windows 用户有建库权限。

第三步：配置 API Key

推荐创建本地覆盖文件（不要提交到 Git）：

src/AiNativeERP.WebApi/appsettings.Local.json

{
  "DeepSeek": {
    "ApiKey": "sk-your-deepseek-api-key"
  },
  "ConnectionStrings": {
    "DefaultConnection": "Server=localhost;Database=AiNativeERP;Trusted_Connection=True;TrustServerCertificate=True;"
  }
}

若使用 Docker SQL Server，把 DefaultConnection 换成上面的 SA 连接串。

第四步：启动后端

cd src/AiNativeERP.WebApi
dotnet run --launch-profile http

看到日志中出现 Now listening on: http://localhost:5195 即表示启动成功。

端点 地址
API 根地址 http://localhost:5195
Swagger 文档 http://localhost:5195/swagger
健康检查（无需登录） http://localhost:5195/api/chat/health

首次启动会自动完成：

  • 创建数据库表（EnsureCreated）
  • 导入 Demo 业务数据（客户、订单、库存、员工等）
  • 检查 Qdrant 知识库是否已有数据

Qdrant 为空时不会自动灌入约 2100 条示例知识，需要执行下面的「导入知识库」步骤。

第五步：导入知识库（首次必做）

AI 问答和制度/流程检索依赖 Qdrant 中的向量数据。第一次运行或清空向量库后，需要手动导入。

PowerShell（Windows）：

# 1. 登录拿 Token
$login = Invoke-RestMethod -Uri "http://localhost:5195/api/auth/login" `
  -Method Post -ContentType "application/json; charset=utf-8" `
  -Body ([System.Text.Encoding]::UTF8.GetBytes('{"username":"admin","password":"admin123"}'))
$token = $login.data.token

# 2. 导入知识库（约 5~7 分钟，会清空后重建）
Invoke-RestMethod -Uri "http://localhost:5195/api/knowledge/import?clearFirst=true" `
  -Method Post -ContentType "application/json; charset=utf-8" `
  -Headers @{ Authorization = "Bearer $token" } `
  -Body ([System.Text.Encoding]::UTF8.GetBytes("{}"))

curl（Linux / macOS）：

TOKEN=$(curl -s -X POST http://localhost:5195/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin123"}' | jq -r '.data.token')

curl -X POST "http://localhost:5195/api/knowledge/import?clearFirst=true" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}'

成功后会返回 imported: ~2100、failed: 0。

查看知识库状态：

curl http://localhost:5195/api/knowledge/status \
  -H "Authorization: Bearer <token>"

第六步：启动前端

新开一个终端：

cd frontend
npm install        # 仅首次需要
npm run dev
页面 地址
首页 http://localhost:3000
登录 http://localhost:3000/login
仪表盘 http://localhost:3000/dashboard
AI 助手 http://localhost:3000/ai-assistant

前端通过 Vite 代理把 /api 转发到 http://localhost:5195，无需额外配置 CORS。

第七步：登录并验证

演示账号：

用户名 密码 角色
admin admin123 管理员
sales sales123 销售主管
purchase purchase123 采购主管
warehouse warehouse123 仓库主管
finance finance123 财务主管
hr hr123 HR 主管
production production123 生产主管

验证清单：

  1. 打开 http://localhost:3000/login ，用 admin / admin123 登录
  2. 进入 AI 助手 或右侧 AI 侧边栏，输入：采购流程怎么操作
  3. 应返回「采购流程说明」等结构化知识正文
  4. 输入：销售部有多少员工 → 应走 HR 查询，返回员工数据

用 API 快速验证（PowerShell）：

$login = Invoke-RestMethod -Uri "http://localhost:5195/api/auth/login" -Method Post `
  -ContentType "application/json; charset=utf-8" `
  -Body ([System.Text.Encoding]::UTF8.GetBytes('{"username":"admin","password":"admin123"}'))
$headers = @{ Authorization = "Bearer $($login.data.token)" }
$body = '{"message":"采购流程怎么操作","userId":"admin","tenantId":"demo-tenant"}'
Invoke-RestMethod -Uri "http://localhost:5195/api/chat/send" -Method Post `
  -ContentType "application/json; charset=utf-8" -Headers $headers `
  -Body ([System.Text.Encoding]::UTF8.GetBytes($body))

试试这些问法

销售部有多少员工          → HR 查询（不是销售）
采购流程怎么操作          → 知识库：采购流程说明
报销制度在哪里看          → 知识库：报销制度说明
本月销售额趋势怎么样      → 销售分析
有哪些库存预警            → 库存预警

常见问题

现象 可能原因 处理方式
后端启动报数据库连接失败 SQL Server 未启动或连接串错误 检查服务状态；核对 appsettings.Local.json
AI 回复很慢或超时 DeepSeek Key 无效或网络问题 检查 DeepSeek:ApiKey；查看 logs/ 目录日志
知识问答返回「未找到相关知识」 Qdrant 为空或未导入 执行第五步知识库导入
中文问法返回乱码或 Unknown 请求未使用 UTF-8 PowerShell 请用上面示例的字节编码方式
dotnet build 报 DLL 被锁定 后端进程仍在运行 先停掉占用 5195 端口的进程再编译
前端页面空白 / 接口 401 未登录或 Token 过期 先访问 /login；检查后端是否在 5195 端口
Ollama 连接失败 模型未拉取或服务未启动 执行 ollama pull nomic-embed-text && ollama serve
Qdrant 连接失败 容器未启动 确认 6333/6334 端口可访问

停止服务：

# 后端 / 前端：在对应终端按 Ctrl+C

# Docker
docker stop qdrant
docker compose down

生产构建（可选）

# 后端发布
cd src/AiNativeERP.WebApi
dotnet publish -c Release -o ./publish

# 前端构建
cd frontend
npm run build
# 静态文件输出在 frontend/dist/

项目结构

ai-native-erp/
├── frontend/                 # React 前端（仪表盘、业务页、AI 助手）
├── src/
│   ├── AiNativeERP.Domain/         # 领域实体
│   ├── AiNativeERP.Application/    # 业务服务（销售/采购/库存/财务/HR/生产）
│   ├── AiNativeERP.Infrastructure/ # EF Core、迁移、种子数据
│   ├── AiNativeERP.AI/             # LLM、意图识别、RAG、Guardrails
│   ├── AiNativeERP.Agent/          # Agent 编排、Tool 路由与执行
│   ├── AiNativeERP.WebApi/         # API 入口
│   └── AiNativeERP.Tests/          # 单元测试 + 集成测试
├── docs/                     # 中英文文档、模块实施报告、数据表规划
├── ARCHITECTURE.md           # 架构设计（中文）
├── ARCHITECTURE.en.md        # Architecture (English)
├── README.en.md              # English README
├── scripts/demo-setup.ps1    # 一键演示：compose + Ollama pull + 知识导入
└── docker-compose.yml        # SQL / Redis / RabbitMQ / Qdrant / Ollama / WebApi / MCP / Frontend

API 示例

登录

curl -X POST http://localhost:5195/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin123"}'

对话（非流式）

curl -X POST http://localhost:5195/api/chat/send \
  -H "Content-Type: application/json; charset=utf-8" \
  -H "Authorization: Bearer <token>" \
  -d '{"message":"采购流程怎么操作","userId":"admin","tenantId":"demo-tenant"}'

流式对话（SSE）

curl -N -X POST http://localhost:5195/api/chat/stream \
  -H "Content-Type: application/json; charset=utf-8" \
  -H "Authorization: Bearer <token>" \
  -d '{"message":"本月销售情况怎么样","userId":"admin","tenantId":"demo-tenant"}'

测试

# 后端
dotnet test src/AiNativeERP.Tests/AiNativeERP.Tests.csproj

# 前端
cd frontend
npm test
npm run test:e2e

重点测试覆盖：域分类负样本、知识检索分池、Tool 路由、审批流、自然语言集成场景。

路线图

  • 分层架构与 ERP 核心业务模块
  • Semantic Kernel 双层 Agent 编排
  • 28+ 业务 Tool + 审批流
  • RAG 知识库（Qdrant + 结构化制度/流程正文）
  • React 前端 + AI 侧边栏 + 流式对话
  • 中英文文档与社区贡献指南
  • 官方 Docker 一键启动（含 Qdrant / Ollama / Frontend / MCP）
  • 多模型适配（DeepSeek / OpenAI / Azure / Ollama，Chat:Provider）
  • MCP Server 标准化对外暴露（转发 ToolGateway，无直连 DB）
  • 可选 Redis 缓存 / RabbitMQ EventBus（默认内存）
  • 截图 / 演示视频 / 在线 Demo

文档

想先理解「为什么这样设计」→ 从产品与场景读起；要落地开发 → 看架构与治理。

文档 说明
docs/README.md 中文文档索引（推荐入口）
docs/zh/product-vision.md 产品理念：为什么是 AI-Native
docs/zh/user-scenarios.md 用户场景与对话剧本
ARCHITECTURE.md 分层架构与数据流
docs/zh/ai-governance.md AI 治理硬约束
docs/zh/intent-domain-rules.md Domain → Intent 规则
docs/zh/tools.md 业务 Tool 清单
docs/zh/api-overview.md API 概览
README.en.md / docs/README.en.md English docs
CONTRIBUTING.md 贡献指南
frontend/README.md 前端说明
docs/GITHUB_SETUP.md GitHub 发布清单
docs/erp-database-schema-plan.md 数据表规划
docs/phase1-purchase-module-report.md · phase2 模块实施报告

参与贡献

欢迎 Star、Fork、提 Issue 和 PR。详见 CONTRIBUTING.md。

我们特别欢迎的方向

  • 意图识别负样本与边界 case 测试
  • 新业务 Tool（走 Application Service，遵守治理约束）
  • RAG 检索质量、Guardrails 规则
  • 前端体验（AI 侧边栏、可访问性、移动端）
  • 文档、截图、演示脚本（中英文）
  • Docker 一键启动（Qdrant / Ollama 等）

如果你准备贡献代码，建议先阅读 ARCHITECTURE.md 与 AI 治理：

  1. LLM 不能直接访问数据库
  2. 写操作必须草稿 → 确认 → 执行
  3. 高风险 Tool 必须审批 + 审计
  4. 域分类歧义必须澄清，不允许猜测
  5. 核心流程需有单元测试（含负样本）

许可证

本项目采用 MIT License 开源。

如果这个项目对你有帮助，欢迎点个 Star 支持一下