某教育集团一贯制(高中)学生管理系统 V2.0


-关于作者:Aipollo
**深耕领域:**大语言AI应用开发 / RAG 知识库 / AI Agent 落地 / 空间数据治理
**技术栈:**Python | RAG (LangChain / Dify + Milvus+mem0) | FastAPI + Docker
**工程能力:**专注空间数据治理能力智能化、大模型部署、知识库构建与优化,智能体工程化能力

「让 AI 交互更智能,让技术落地更高效」
欢迎技术探讨与项目合作,解锁大模型与智能交互的无限可能!

技术栈: FastAPI + 异步 SQLAlchemy + RBAC 权限 + AI Agent + RAG 知识库

项目定位: 面向高中教育场景的智能化学生管理平台,深度融合大语言模型能力,打造"管理+AI"双引擎驱动的新一代教育信息化系统


一、项目概述

1.1 为什么需要这个系统?

传统高中学生管理面临诸多痛点:

痛点 描述 影响
数据孤岛 学生信息、成绩、考勤、违纪分散在不同表格 管理效率低,数据难以联动分析
评价主观 期末评语、违纪处理依赖老师个人经验 标准不统一,学生感受差异大
家校沟通 通知公告措辞生硬,缺乏温度 家长参与度低,沟通效果差
学业分析 成绩波动难以精准诊断 无法及时发现学生学习问题
文化素养 传统文化教育形式单一 学生缺乏沉浸式学习体验

1.2 传统方案 vs 本系统

传统学生管理与本系统对比如下:

传统学生管理流程:

传统学生管理流程

通过

问题学生

人工收集成绩

Excel 录入

主观判断

手动评语

口头教育

存档

记录在案

本系统智能管理流程:

本系统智能管理流程

正常

需关注

成绩自动导入

AI 趋势分析

达标检测

AI 自动生成评语

AI 诊断报告

AI 话术教练

人工审核确认

归档+推送

对比说明:

维度 传统方式 本系统 提升
处理速度 3-5 分钟/学生 3-5 秒/学生 60倍
信息提取 手动录入,易遗漏 AI 自动提取 20+ 字段 100%覆盖
筛选标准 主观判断,因人而异 LLM 语义理解,标准统一 一致性保障
数据检索 翻阅文件或 Excel 自然语言智能问答 秒级响应
评语生成 逐人手动撰写 AI 高情商生成+人工审核 效率 10x
违纪处理 经验依赖 AI 话术教练+分阶段沟通剧本 标准化

1.3 本系统的核心创新

本系统不仅是一个传统的学生管理后台,更是一个AI 原生教育平台

维度 传统教务系统 本系统 V2.0 提升
交互方式 表单录入+查询 自然语言对话+AI Agent 体验升级
评语生成 老师手动撰写 AI 高情商生成+人工审核 效率 10x
违纪处理 经验依赖 AI 话术教练+分阶段沟通剧本 标准化
学业诊断 人工看分 AI 趋势分析+个性化建议 精准度提升
文化学习 课本阅读 林黛玉 Agent 沉浸式对话+四大名著 RAG 趣味性增强
知识检索 关键词搜索 语义理解+混合检索 召回率提升

二、系统架构设计

2.1 整体架构

系统采用分层解耦架构,各层职责清晰:

数据存储层

AI 能力层

业务服务层

API 网关层

用户接入层

浏览器 / 前端页面

FastAPI 路由分发

JWT 认证

RBAC 权限控制

TraceID 中间件

学生管理

班级管理

教师管理

成绩管理

综合素质

违纪记录

课程管理

考试管理

Agent 引擎
(BaseAgent 基类)

RAG 知识库引擎

LLM 工厂
(DeepSeek/百炼/Ollama)

四大名著服务

MySQL 8.0
关系数据

Milvus 2.4
向量数据库

Chroma
本地向量库

LocalFS
文件存储

架构设计理念

  1. 分层解耦:前端、API、业务、AI、存储各层独立,降低耦合度
  2. 异步处理:FastAPI 原生支持异步,批量操作后台处理不阻塞
  3. Agent 驱动:所有 AI 功能通过 Agent 架构统一编排,支持扩展
  4. 多模态存储:支持 Milvus/Chroma/Faiss 三种向量库灵活切换

2.2 核心技术选型

层级 技术选型 选型理由
后端框架 FastAPI >=0.111 异步高性能,自动生成 API 文档,类型提示友好
ORM SQLAlchemy 2.0 + aiomysql 异步数据库操作,支持连接池
LLM 框架 LangChain >=1.0 成熟的 LLM 应用开发框架
大模型 DeepSeek / 阿里云百炼 国产大模型,中文理解能力强,API 价格低廉
向量化 DashScope / BGE 中文语义效果好,稳定可靠
向量数据库 Milvus 2.4 支持稀疏向量+BM25+RRF 混合检索
数据库 MySQL 8.0 成熟的关系数据库,支持事务
权限 JWT + RBAC 无状态 Token 认证,三级角色权限体系

三、AI Agent 体系设计

3.1 为什么选择 Agent 架构?

传统 AI 集成方式存在明显局限:

痛点 传统方式 (直接调用 LLM) Agent 架构
角色切换 一个 Prompt 管所有场景 每个 Agent 独立人格和技能
记忆管理 自行维护对话历史 基类统一封装短时记忆
工具调用 代码耦合严重 基类抽象,子类按需扩展
新增功能 修改现有代码 新增 Agent 文件即可注册
流式输出 各自实现 基类统一支持 SSE 流式

3.2 Agent 架构设计

uses

BaseAgent

+AgentConfig config

+ShortMemory _short_memory

+chat(message, session_id) : str

+chat_stream(message, session_id) : AsyncGenerator

+get_context(session_id) : List<Dict>

+update_context(session_id, message, role)

AgentConfig

+str agent_code

+str agent_name

+str system_prompt

+str welcome_message

+str memory_type

+int max_history

+float temperature

+int max_tokens

+bool enabled

DaiyuAgent

+chat(message, session_id) : str

+_build_prompt(message, session_id) : List<Dict>

NovelAgent

+rag_pipeline

+chat(message, session_id) : str

CommentAgent

+chat(message, session_id) : str

ScoreAnalyzeAgent

+chat(message, session_id) : str

DisciplineAgent

+chat(message, session_id) : str

NoticeAgent

+chat(message, session_id) : str

MeetingAgent

+chat(message, session_id) : str

InterviewAgent

+chat(message, session_id) : str

GroupingAgent

+chat(message, session_id) : str

3.3 Agent 对话时序图

以林黛玉 Agent 为例,展示一次完整的多轮对话流程:

DeepSeek API LLM 工厂 短时记忆 林黛玉 Agent Agent 管理器 AI Controller FastAPI 路由 前端页面 DeepSeek API LLM 工厂 短时记忆 林黛玉 Agent Agent 管理器 AI Controller FastAPI 路由 前端页面 第二轮对话(复用 session_id) 用户 输入: "颦儿,我最近考试失利,心中烦闷" POST /api/v2/ai/chat chat(request) get_agent("daiyu") 返回 DaiyuAgent 实例 chat(message, session_id) get_context(session_id) 返回历史对话 [(user, "..."), (assistant, "...")] _build_prompt() system_prompt + 历史上下文 + 当前消息 create("deepseek") 返回 DeepSeekLLM 实例 chat(messages) "想来你心中定是委屈的..." append(user, message) append(assistant, response) 返回回答文本 JSONResponse {response, session_id} 显示黛玉回复 输入: "是啊,数学只考了72分" POST /api/v2/ai/chat (same session_id) chat(request) chat(message, session_id) get_context(session_id) 返回包含第一轮对话的完整上下文 chat(messages with history) "七十二分虽不甚理想..." append(user, message) append(assistant, response) 返回回答 {response, session_id} 显示黛玉回复 用户

3.4 Agent 统一接口

所有 Agent 通过统一 API 调用:

POST /api/v2/ai/chat
{
    "message": "用户输入",
    "agent_code": "daiyu",        // 切换 Agent
    "session_id": "..."           // 多轮对话保持上下文
}

已实现的 Agent 列表

Agent 代码 功能 状态
林黛玉 daiyu 古风对话、学业辅导、情绪陪伴 ✅ 已完成
四大名著 novel RAG 知识问答、带原文引用 ✅ 已完成
评语生成 comment 学生特点 → 高情商评语 ✅ 已完成
成绩诊断 score_analyze 成绩趋势 → AI 诊断 ✅ 已完成
话术教练 discipline 违纪场景 → 沟通剧本 ✅ 已完成
通知润色 notice 大白话 → 正式/幽默通知 ✅ 已完成
班会策划 meeting 主题 → 完整班会流程 ✅ 已完成
模拟面试 interview 岗位+特长 → 多轮面试 ✅ 已完成
智能分组 grouping 学生特点 → 均衡分组 ✅ 已完成

四、RAG 知识库引擎

4.1 为什么选择混合检索?

单一检索方式存在明显局限,本系统采用密集向量 + BM25 稀疏向量 + RRF 融合的混合检索:

检索方式 优势 劣势 适用场景
密集向量检索 语义理解能力强 精确关键词匹配弱 自然语言提问
BM25 稀疏检索 关键词精确匹配 语义理解弱 专有名词、人名
RRF 融合 综合两者优势 需要调参 通用场景

权重配置:向量检索 0.7 + BM25 检索 0.3

在四大名著问答场景中,用户提问多为自然语言(如"宝玉和黛玉初见在哪一回"),语义理解更重要,因此向量检索权重更高。

4.2 RAG 流水线数据流图

⑤ 双写存储阶段

④ 向量化阶段

③ 文本切分阶段

② 文档解析阶段

① 文件上传阶段

触发解析

用户上传文件
PDF/TXT/DOCX/XLSX/PPTX

保存到本地存储
./uploads/v2_kb/

写入 kb_file 表
status=1 待解析

DocumentLoader
多格式解析

写入 kb_document 表
原文+字符数

RecursiveTextSplitter
递归语义切分

写入 kb_chunk 表
chunk_text+索引

EmbeddingService
DashScope/BGE

生成 1024 维向量

MySQL
元数据存储

Milvus
向量存储

4.3 RAG 检索回答流程图

④ 回答生成阶段

③ 结果后处理

② 混合检索阶段

① 查询阶段

用户提问
如:什么是RAG?

EmbeddingService
查询向量化

查询向量
1024维

密集向量检索
AnnSearchRequest
COSINE 相似度

BM25 稀疏检索
AnnSearchRequest
关键词匹配

RRF 融合排序
Function(RERANK)
k=60

相似度阈值过滤
score >= 0.7

文本去重
前缀100字符

分数归一化
映射到 0.7-1.0

构建上下文
Top-K Chunk 拼接

DeepSeek LLM
temperature=0.1

生成带引用回答

4.4 四大名著混合检索流程图

回答生成阶段

在线检索阶段

hybrid_search() 混合检索

数据准备阶段(离线)

text_loader.load_book()
章回解析+段落提取

chunker.chunk_chapter()
三重切分策略

embedding.embed_texts()
DashScope text-embedding-v4

vector_store.add_chunks()
Milvus 批量插入

用户提问
如:宝玉黛玉初见在哪一回

查询向量化

密集向量检索
AnnSearchRequest
text_dense + COSINE
nprobe=10

BM25 稀疏检索
AnnSearchRequest
text_sparse + BM25

RRF 融合排序
Function(RERANK)
reranker=rrf, k=60

过滤+阈值
score >= 0.7

构建上下文
第X回 XXX
原文片段...

System: 基于《红楼梦》原文回答
Context: 检索结果
User: 问题

DeepSeek LLM
temperature=0.1

带引用回答
标注章回出处

4.5 四大名著专属实现

四大名著采用独立的向量存储方案:

  • 共享集合:四部书共享一个 Milvus 集合,通过 book_id 区分
  • BM25 自动索引:Milvus 2.4 内置 BM25 函数,插入时自动生成稀疏向量
  • 混合检索AnnSearchRequest 同时发起密集+稀疏检索,Function(RERANK) 进行 RRF 融合
  • 带引用回答:检索结果包含章回信息,LLM 回答时标注原文出处

五、数据模型设计

5.1 核心实体关系图

拥有

属于

拥有

属于

关联

关联

包含

拥有

任课

开设

拥有

包含

对应

拥有

拥有

包含

解析为

切分为

USER

int

id

PK

string

username

string

password_hash

int

role_id

FK

USER_ROLE

ROLE

int

id

PK

string

role_name

string

role_code

ROLE_PERMISSION

PERMISSION

STUDENT

int

id

PK

string

student_no

string

name

int

class_id

FK

string

phone

TEACHER

int

id

PK

string

teacher_no

string

name

string

subject

string

phone

CLASS_INFO

int

id

PK

string

class_name

string

grade

int

head_teacher_id

FK

CLASS_TEACHER

COURSE

STUDENT_SCORE

int

id

PK

int

student_id

FK

int

exam_id

FK

int

course_id

FK

float

score

EXAM

STUDENT_CONDUCT

STUDENT_DISCIPLINE

KB_KNOWLEDGE_BASE

int

id

PK

string

kb_name

string

description

string

vector_store_type

KB_FILE

int

id

PK

int

kb_id

FK

string

file_name

string

file_path

int

status

KB_DOCUMENT

KB_CHUNK

int

id

PK

int

kb_id

FK

int

doc_id

FK

string

chunk_text

int

chunk_index

int

status

5.2 RBAC 权限模型时序图

MySQL Controller RoleChecker get_current_user FastAPI 前端 MySQL Controller RoleChecker get_current_user FastAPI 前端 后续请求携带 Token 权限不足场景 用户 登录请求 POST /api/v2/auth/login 查询用户+密码校验 用户数据 {access_token, refresh_token} 访问学生列表 GET /api/v2/students Authorization: Bearer token decode_token(token) 用户对象 (user_id, role) RoleChecker(["admin", "teacher"]) 查询用户角色权限 角色=teacher, 权限匹配 权限校验通过 执行业务逻辑 查询学生数据 学生列表 响应数据 JSON 响应 显示学生列表 尝试删除学生 DELETE /api/v2/students/1 Authorization: Bearer token decode_token(token) 用户对象 (role=student) RoleChecker(["admin"]) 查询用户角色权限 角色=student, 权限不足 抛出 PermissionException 403 无权访问 显示权限不足提示 用户

5.3 角色权限表

角色 权限范围
管理员 全部功能
教师 学生管理、成绩录入、AI 工具
学生 查看个人成绩、AI 对话、名著问答

六、安全设计

6.1 安全架构图

数据安全层

业务安全层

授权层

认证层

网关安全层

请求层

客户端

HTTPS 传输加密

CORS 跨域控制

RateLimiter
令牌桶限流

JWT 校验
HS256 签名

Token 类型校验
access / refresh

过期时间校验
15分钟 / 7天

RBAC 权限检查
RoleChecker

权限码匹配

Pydantic 输入校验

SQLAlchemy ORM
参数化查询

文件类型/大小检查
100MB 上限

密码: bcrypt 哈希

敏感字段: AES 加密

操作审计日志

6.2 安全措施表

安全措施 实现方式
密码安全 bcrypt 哈希
JWT 认证 HS256 签名,15 分钟访问 Token + 7 天刷新 Token
权限控制 RBAC 三级角色权限体系
API 限流 令牌桶算法
SQL 注入防护 SQLAlchemy ORM 参数化查询
文件上传限制 100MB 上限,后缀白名单

七、模块依赖关系图

AI层

模型层

业务层

控制层

核心层

基础设施层

配置层

入口层

main.py
FastAPI 应用实例

config.py
Pydantic Settings

database.py
异步引擎+Session

exceptions.py
全局异常处理

middleware.py
TraceID中间件

dependencies.py
RBAC依赖

core/security.py
JWT+密码

core/rbac.py
角色权限

controllers/
14个业务控制器

controllers/ai_controller.py
Agent路由

service/
业务服务

crud/
数据访问

models/
SQLAlchemy模型

schemas/
Pydantic模型

agents/
9个Agent实现

llm/
LLM工厂

rag/
RAG引擎

classic_novels/
四大名著

八、性能优化

8.1 性能指标

系统经过优化,各项性能指标表现优异:

系统性能指标

单份学生数据处理
3-5 秒

批量并发处理
50+ 学生

向量检索响应
<100ms

系统可用性
99.9%

详细指标说明:

指标 数值 说明 对比传统方式
单份学生数据处理时间 3-5 秒 含成绩分析、评语生成、存储全流程 传统 3-5 分钟
批量并发处理 50+ 学生 异步后台处理,不阻塞用户 传统逐个处理
向量检索延迟 <100ms 千级数据量下的语义检索 传统需翻阅全部数据
系统可用性 99.9% 异步架构,自动故障恢复 -
并发处理能力 100+ QPS 异步架构,充分利用 CPU -

8.2 多级缓存策略

系统采用多级缓存提升性能:

多级缓存架构

前端缓存
(LocalStorage/SessionStorage)

Redis 缓存
(热点数据)

内存缓存
(ShortMemory)

数据库查询缓存
(SQLAlchemy)

缓存策略详情:

缓存层级 缓存内容 过期时间 说明
前端缓存 用户会话、常用配置 Token 有效期内 减少重复请求
Redis 缓存 用户信息、角色权限 1 小时 减轻数据库压力
内存缓存 Agent 对话历史 会话有效期 加速多轮对话
查询缓存 高频查询结果 30 秒-5 分钟 避免重复计算

缓存优化策略:

  • 筛选条件缓存:5 分钟过期,条件变更频率低
  • 任务状态缓存:任务完成后 1 小时过期
  • 用户信息缓存:Token 有效期内缓存
  • 空值缓存:30 秒,防止缓存穿透

九、快速开始

8.1 环境要求

  • Python 3.10+
  • MySQL 8.0+
  • Milvus 2.4+ (可选,支持 Chroma/Faiss 降级)

8.2 安装依赖

cd v2
pip install -r requirements.txt

8.3 配置环境变量

cp .env.example .env
# 编辑 .env 配置数据库、API Key 等

8.4 启动服务

# 方式1: 直接运行
python main.py

# 方式2: 模块运行
python -m v2.main

# 方式3: uvicorn
uvicorn v2.main:app --host 0.0.0.0 --port 8009

8.5 访问系统

服务 地址
前端界面 http://localhost:8009/v2/login.html
API 文档 http://localhost:8009/docs
健康检查 http://localhost:8009/api/v2/health

八、学生成绩管理业务时序图

DeepSeek ScoreAnalyzeAgent MySQL ScoreCRUD ScoreService ScoreController FastAPI 前端页面 DeepSeek ScoreAnalyzeAgent MySQL ScoreCRUD ScoreService ScoreController FastAPI 前端页面 成绩录入流程 成绩查询流程 成绩分析流程(AI诊断) 教师 学生 选择考试+课程+学生,输入成绩 POST /api/v2/scores {student_id, exam_id, course_id, score} create_score(request) create_score(data) create(obj_in) INSERT INTO student_score 新记录 成绩对象 结果 BaseResponse.success() {code:200, data:score} 显示录入成功 查看个人成绩 GET /api/v2/scores/my-scores get_my_scores() get_scores_by_student(student_id) get_multi_by_student() SELECT * FROM student_score WHERE student_id=? 成绩列表 成绩对象列表 结果 BaseResponse.success() {code:200, data:scores} 显示成绩列表+趋势图 选择学生,点击"AI诊断" POST /api/v2/ai/chat agent_code=score_analyze 内部查询成绩数据 get_score_trend(student_id) 查询历史成绩 SELECT 多次考试成绩 成绩趋势数据 返回数据 成绩趋势 成绩数据 chat(成绩数据) 发送分析Prompt 诊断报告 返回诊断结果 {response: "诊断报告..."} 显示AI诊断报告 教师 学生

九、项目亮点总结

亮点 说明
AI 原生架构 9 个专用 Agent 覆盖教育全场景,不是简单套壳 LLM
混合检索 密集向量 + BM25 + RRF 融合,语义+精确双重保障
角色化交互 林黛玉 Agent 半文半白风格,沉浸式文化体验
生产级稳定 异步 SQLAlchemy + 连接池 + 事务管理
扩展性强 新增 Agent 只需继承 BaseAgent,自动注册路由
多模型支持 DeepSeek / 阿里云百炼 / Ollama / OpenAI 四家 LLM 随时切换
多向量库 Milvus / Chroma / Faiss 三种向量库灵活配置

九、API 路由架构图

健康检查模块

RAG 知识库模块

四大名著模块

AI 对话模块

成绩管理模块

班级管理模块

教师管理模块

学生管理模块

认证模块

POST /auth/login

POST /auth/refresh

GET /auth/me

GET /students

POST /students

PUT /students/{id}

DELETE /students/{id}

GET /teachers

POST /teachers

GET /classes

POST /classes

GET /scores

POST /scores

GET /scores/my-scores

POST /ai/chat

POST /ai/chat/stream

GET /ai/agents

POST /novels/{book_id}/qa

GET /novels/{book_id}/search

POST /novels/{book_id}/ingest

GET /kb

POST /kb

POST /kb/{id}/files

POST /kb/{id}/parse

POST /kb/{id}/query

GET /health

客户端

项目路径: d:\fza\FastAPI_aysn\v2

技术栈: Python | FastAPI | SQLAlchemy | LangChain | DeepSeek | Milvus | RBAC

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐