一个集成了 11 个企业级 AI Agent 项目的统一平台，基于阿里巴巴通义千问（Qwen）系列大模型构建，覆盖金融、运维、客服、合同、数据分析等多个垂直业务场景。
| 项目 | 名称 | 一句话介绍 |
|---|---|---|
| A | 企业级自动化研报系统 | LangGraph 多 Agent 协作，从搜索采集到报告撰写全自动化，支持人工审核断点 |
| B | 企业财务票据助手 | OCR 识别 + LLM 审核，支持7种票据类型，4维合规校验，风险自动评分 |
| C | SQL 智能数据分析师 | 自然语言转 SQL，内置自愈纠错循环，自动选择图表类型并生成分析结论 |
| D | 智能 DevOps 故障排查助手 | 手写 ReAct 引擎，5 类工具联动，自动定位根因并输出修复建议 |
| E | 全模态智能售后诊断 Agent | 语音+图片+视频三模态输入，跨模态推理，多模态知识库检索与诊断 |
| F | 设备租赁客服 AI 助手 | RAG/SQL/多模态三路工具路由，情绪感知自动转人工，覆盖全场景客服 |
| G | 智能合同识别助手 | PDF 合同 OCR 解析 23 个字段，4 维审核引擎，SSE 流式推送审核进度 |
| H | 文本智能分块系统 | 支持5种文档格式、9种分块策略，实时可视化对比分块效果，服务 RAG 建设 |
| I | 租赁知识库 RAG 检索服务 | 语义+关键词混合检索，Cross-Encoder 重排序，检索结果透明可解释 |
| J | AI 租赁助手 | 多轮对话+会话记忆，意图路由至 RAG/SQL/直接回复，SSE 流式输出 |
| K | 意图识别系统 | Few-shot 动态召回 + Slot 填槽 + 工具映射，配置驱动零代码扩展意图 |
- Agent框架: LangChain, LangGraph
- 大模型: 阿里云 DashScope（Qwen-Max / Qwen-Turbo / Qwen-VL / Qwen-Audio）
- 向量数据库: ChromaDB
- 后端: FastAPI + Uvicorn + SQLAlchemy
- 前端: Next.js 16 + React 19 + TypeScript + Tailwind CSS
- OCR: 阿里云 OCR + PyMuPDF
- 数据库: MySQL + SQLite
📄 查看详细设计文档
项目背景
企业分析师需要定期生成行业研究报告，传统方式需要手动收集数据、分析整理、撰写成文，耗时数天。本项目通过多 Agent 协作自动完成从数据采集到报告生成的全链路自动化，将生产周期压缩至分钟级。
系统架构
基于 LangGraph 构建有向无环图（DAG）+ 循环反馈的多 Agent 工作流：
用户指令
↓
Supervisor Agent（路由分发）
├── Research Agent → Tavily 搜索 + 网页抓取
├── Analyst Agent → 数据清洗、对比分析
├── Writer Agent → 生成 Markdown 格式报告
└── Reviewer Agent → 质量审核 → 不合格则回流重做（循环）
所有 Agent 共享同一个 State 对象（Shared State 通信模型），Reviewer 判定不合格时自动触发回流重做。
架构图
graph TB
User[用户指令] --> Supervisor[Supervisor Agent\n路由分发]
Supervisor --> Research[Research Agent\nTavily搜索+网页抓取]
Supervisor --> Analyst[Analyst Agent\n数据清洗+对比分析]
Supervisor --> Writer[Writer Agent\n生成Markdown报告]
Research --> State[(Shared State\n共享状态)]
Analyst --> State
Writer --> State
State --> Reviewer[Reviewer Agent\n质量审核]
Reviewer -->|不合格 回流| Supervisor
Reviewer -->|合格| Output[最终研报输出]
State --> Checkpoint[(SQLite\n检查点持久化)]
技术亮点
- 多 Agent 状态管理：LangGraph 管理复杂长程任务状态，支持节点级检查点持久化（SQLite）
- Human-in-the-loop：在 Reviewer 环节加入人工审核断点，支持人机协同审查
- 自我纠错机制：Reviewer 检测到数据不一致时自动触发二次检索与修正
- 流式输出：前端实时预览报告生成过程，Markdown 渐进式渲染
📄 查看详细设计文档
项目背景
企业财务人员每月需处理大量报销票据，人工录入效率低且易出错；同时审核流程复杂，合规风险难以把控。本项目通过 OCR + LLM 实现票据自动识别、结构化提取和合规审核一体化。
系统架构
票据上传（图片/PDF）
↓
OCR 识别层
├── 阿里云 OCR → 字段精准提取（准确率 >98%）
├── PyMuPDF → PDF 多页解析
└── Qwen-Max → 结构化纠错与补全
↓
审核引擎（4 大维度）
├── 真伪校验 → 税务局 API 核验发票真伪
├── 重复检测 → 数据库比对历史记录
├── 合规校验 → 规则引擎（金额/日期/抬头）
└── 逻辑推理 → LLM 分析差旅时间地点连贯性
↓
风险评分（0-100） → 低风险自动通过 / 高风险转人工
架构图
graph TB
Upload[票据上传\n图片/PDF] --> OCR_Ali[阿里云OCR\n字段精准提取]
Upload --> PDF[PyMuPDF\nPDF多页解析]
OCR_Ali --> LLM_Fix[Qwen-Max\n结构化纠错补全]
PDF --> LLM_Fix
LLM_Fix --> Engine[审核引擎]
Engine --> V1[真伪校验\n税务局API核验]
Engine --> V2[重复检测\n数据库历史比对]
Engine --> V3[合规校验\n规则引擎]
Engine --> V4[逻辑推理\nLLM差旅分析]
V1 --> Score[风险评分 0-100]
V2 --> Score
V3 --> Score
V4 --> Score
Score -->|低风险| Auto[自动通过]
Score -->|高风险| Human[转人工复核]
LLM_Fix --> MySQL[(MySQL\n票据数据库)]
技术亮点
- 多模态识别：支持增值税发票、火车票、出租车票等7种票据类型自动分类
- 并发处理：50 张图片批量识别，平均耗时 <30 秒
- 人机协同：高风险单据必须人工确认，风险评分动态计算
- 完整合同管理：在发票基础上扩展合同识别模块，支持合同全生命周期管理
📄 查看详细设计文档
项目背景
业务人员需要查询数据库获取经营数据，但不具备 SQL 编写能力，且数据库结构复杂（多表关联）。本项目基于工程设备租赁行业数据模型，实现自然语言到 SQL 的全自动转换与可视化分析。
系统架构
基于 Self-Correction Loop 的 Text-to-SQL 引擎：
自然语言输入
↓
Schema Retriever → 动态提取 DDL + 样本数据
↓
SQL Generator → 基于 Schema 生成 SQL（Qwen-Max）
↓
SQL Validator → 沙箱预执行，捕捉语法错误/空结果
↓ （出错则回流）
Refiner → 将错误信息反馈 Generator 重新生成（CoT 推理）
↓
Data Visualizer → 自动选择最优图表类型（ECharts/Recharts）
↓
分析结论 → LLM 生成文字洞察说明
架构图
graph TB
NL[自然语言输入] --> SchemaRet[Schema Retriever\n动态提取DDL+样本数据]
SchemaRet --> SQLGen[SQL Generator\nQwen-Max生成SQL]
SQLGen --> SQLVal[SQL Validator\n沙箱预执行]
SQLVal -->|执行成功| Viz[Data Visualizer\n自动选择图表类型]
SQLVal -->|执行报错| Refiner[Refiner\nCoT推理纠错]
Refiner --> SQLGen
Viz --> Chart[ECharts图表渲染]
Viz --> Insight[LLM生成\n业务洞察结论]
SchemaRet --> MySQL[(MySQL\n租赁业务数据库)]
技术亮点
- 零样本 Schema 适应：无需预训练，直接理解陌生数据库结构
- 自动纠错循环：复杂 Join 报错时通过 Trace 信息自我修复，无需人工干预
- 智能图表选择：根据数据特征自动决策柱状图/饼图/折线图等展示形式
- 数据洞察：查询结果附带 LLM 生成的业务分析结论，体现推理深度
📄 查看详细设计文档
项目背景
生产环境故障处理时间紧迫，SRE 工程师需要快速从海量日志、监控指标中定位根因。本项目模拟 SRE 处理线上告警的完整工作流，通过 ReAct 推理模式实现自动化故障根因分析。
系统架构
基于手写 ReAct（Reason + Act）推理引擎：
告警接入（OOM/DB连接池耗尽/CPU飙升等）
↓
ReAct 推理循环（最多10步）
├── Thought → LLM 分析当前观测，制定下一步策略
├── Action → 选择工具执行
│ ├── read_logs → 读取指定服务日志
│ ├── query_metrics → 查询 CPU/内存/DB连接数等指标
│ ├── search_kb → 检索 SRE 专家知识库
│ ├── analyze_network → 检查网络拓扑连通性
│ └── optimize_resources → 资源优化建议
└── Observation → 工具返回结果，继续推理
↓
自我反思机制（第5步触发）→ 防止推理死循环
↓
Final Answer → 根因 + 分析过程 + 修复建议
架构图
graph TB
Alert[告警接入\nOOM/CPU飙升/DB耗尽] --> ReactLoop[ReAct 推理循环\n最多10步]
ReactLoop --> Thought[Thought\nLLM分析制定策略]
Thought --> Action[Action\n选择工具]
Action --> T1[read_logs\n读取服务日志]
Action --> T2[query_metrics\nCPU/内存/DB指标]
Action --> T3[search_kb\nSRE专家知识库]
Action --> T4[analyze_network\n网络拓扑检查]
Action --> T5[optimize_resources\n资源优化建议]
T1 --> Obs[Observation\n工具返回结果]
T2 --> Obs
T3 --> Obs
T4 --> Obs
T5 --> Obs
Obs --> ReactLoop
ReactLoop -->|第5步触发| Reflect[自我反思\n防止推理死循环]
Reflect --> ReactLoop
ReactLoop -->|得出结论| Final[Final Answer\n根因+修复建议]
技术亮点
- 手写 ReAct 引擎：不依赖 LangGraph/AutoGen，完整展示 Agent 推理过程控制
- 自我反思机制：超过阈值步数自动触发反思提示，避免推理循环
- 故障模拟引擎：内置多种故障场景（OOM/DB连接池/网络抖动），真实再现线上告警数据
- 终端风格 UI：Thought/Action/Observation 流式展示，完整呈现 Agent 思考链路
📄 查看详细设计文档
项目背景
工业设备售后场景中，客户需要描述设备故障，传统客服需要人工处理多种媒介（文字、图片、视频、语音）。本项目实现"语音输入 → 视觉感知 → 跨模态推理 → 解决方案输出"的全链路闭环。
系统架构
基于 Cross-Modal Fusion Reasoning 的多模态 Agent：
多模态输入
├── 语音 → Qwen-Audio ASR 语音识别
├── 图片 → Qwen-VL-Max 产品型号/故障点识别
└── 视频 → OpenCV 关键帧提取 → Qwen-VL-Max 动态故障分析
↓
Cross-Modal Reasoning → 语音描述与视觉证据语义对齐
↓
ChromaDB 多模态知识库检索（图文索引）
↓
Action Planner → 生成解决方案 + 调用业务接口
↓
多模态输出 → TTS 语音回复 + 标注故障示意图
架构图
graph TB
AudioIn[语音输入] --> ASR[Qwen-Audio\nASR语音识别]
ImgIn[图片输入] --> VL1[Qwen-VL-Max\n型号/故障点识别]
VideoIn[视频输入] --> KeyFrame[OpenCV\n关键帧提取]
KeyFrame --> VL2[Qwen-VL-Max\n动态故障分析]
ASR --> Fusion[Cross-Modal Reasoning\n跨模态语义对齐]
VL1 --> Fusion
VL2 --> Fusion
Fusion --> RAG[ChromaDB\n多模态知识库检索]
RAG --> Planner[Action Planner\n生成解决方案]
Planner --> TTS[TTS语音回复]
Planner --> ImgOut[标注故障示意图]
Planner --> API[调用业务接口]
技术亮点
- 跨模态语义对齐：声画同步分析，解决语音描述与视觉证据的语义匹配难题
- 视频时序分析：从视频流关键帧中提取动态故障信息，而非单帧识别
- 低延迟流式交互：VAD 语音活动检测，边听边推理的流式处理能力
- 多模态 RAG：ChromaDB 同时支持图文混合索引，多模态知识检索
📄 查看详细设计文档
项目背景
工程设备租赁行业客服场景多样（政策咨询/账务查询/现场支持），单一对话模型无法覆盖所有诉求。本项目构建多工具路由的智能客服系统，按意图自动分派到不同的处理链路。
系统架构
用户输入
↓
意图路由（Qwen-Max 集成客服人格 Prompt）
├── 业务咨询类 → RAG 检索（ChromaDB 知识库）
│ └── 租赁政策/保险条款/设备选型/操作规程
├── 账务合同类 → SQL 查询（MySQL 业务数据库，Read-Only沙箱）
│ └── 账单对账/设备可用性/合同进度/违约金计算
└── 现场支持类 → 多模态处理（DashScope Vision/Audio）
└── 故障诊断/证件核验/语音报修/视频验收
↓
情绪监测 → 负面情绪/高额纠纷/敏感词触发 → 转人工
架构图
graph TB
Input[用户输入] --> Router[意图路由\nQwen-Max客服人格]
Router -->|业务咨询| RAG[RAG检索\nChromaDB知识库]
Router -->|账务合同| SQL[SQL查询\nMySQL只读沙箱]
Router -->|现场支持| Modal[多模态处理\nDashScope]
RAG --> KB[租赁政策\n保险条款\n设备选型]
SQL --> DB[(MySQL\n业务数据库)]
Modal --> Vision[图片故障诊断\n证件核验]
Modal --> Audio[语音报修\nASR]
RAG --> Reply[回复生成]
SQL --> Reply
Modal --> Reply
Reply --> Sentiment[情绪监测\nSentiment Analysis]
Sentiment -->|负面/敏感词| Human[转人工客服\n+事件摘要]
Sentiment -->|正常| Output[输出回复]
技术亮点
- 三类工具混合路由：RAG/SQL/多模态三条处理链路自动切换
- 情绪感知转接：Sentiment Analysis 检测负面情绪，自动生成摘要转人工客服
- 安全沙箱：数据库查询工具严格 Read-Only 权限控制，防止 SQL 注入
- 回路锁定检测：同一问题连续 3 轮未解决自动触发人工介入
📄 查看详细设计文档
项目背景
企业合同管理量大，人工审核耗时且易遗漏风险条款。本项目实现合同图片上传 → OCR 识别 → 关键字段提取 → 合规审核的全自动化流程。
系统架构
合同上传（图片/PDF）
↓
OCR 识别服务（ContractOCRService）
└── 提取：合同编号/双方主体/金额/日期/付款方式等23个字段
↓
审核规则引擎（4 大维度）
├── LegalityChecker → 合法性校验（主体资质/签章完整性）
├── RiskChecker → 风险检测（不平等条款/违约金异常）
├── DuplicateChecker → 重复合同检测
└── LogicChecker → 逻辑推理（金额/日期/条款一致性）
↓
SSE 流式推送审核进度
↓
合同全生命周期管理（草稿/待审批/执行中/已完成）
架构图
graph TB
Upload[合同上传\n图片/PDF] --> OCR[ContractOCRService\n23个字段提取]
OCR --> Fields[合同编号/双方主体\n金额/日期/付款方式]
Fields --> AuditEngine[审核规则引擎]
AuditEngine --> L[LegalityChecker\n合法性校验]
AuditEngine --> R[RiskChecker\n风险检测]
AuditEngine --> D[DuplicateChecker\n重复合同检测]
AuditEngine --> LC[LogicChecker\n逻辑一致性推理]
L --> Score[风险评分]
R --> Score
D --> Score
LC --> Score
Score --> SSE[SSE流式推送\n审核进度]
Score --> MySQL[(MySQL\n合同主表+审核日志\n附件+付款计划)]
SSE --> Frontend[前端实时展示]
技术亮点
- 多页合同解析：支持 PDF 多页图片切片识别，OCR 结果自动拼合
- 4 维审核引擎：合法性/风险/重复/逻辑四层独立审核，风险评分量化
- SSE 流式审核：前端实时展示审核进度，用户无需等待全量结果
- 完整数据模型：33个字段合同主表 + 审核日志 + 附件 + 付款计划四张核心表
📄 查看详细设计文档
项目背景
RAG 系统的检索质量高度依赖文档分块策略。不同文档类型和业务场景需要不同的分块方案，但现有工具缺乏可视化对比能力。本项目提供企业级文档分块策略效果可视化平台，支持多策略实时对比。
系统架构
文件上传（PDF/DOCX/PPTX/HTML/MD）
↓
格式解析层
├── PDF → PyMuPDF 提取文本
├── DOCX → python-docx
├── PPTX → python-pptx（分块即分页）
├── HTML → BeautifulSoup4
└── MD → markdown 解析
↓
分块策略引擎（9种策略）
├── 固定长度分块（chunk_size/overlap 可配）
├── 递归字符分块（多级分隔符）
├── 句子级语义分块（Qwen Embedding 相似度阈值）
├── Markdown 结构分块（Header 层级拆分）
├── Token-Aware 分块（tiktoken 精确计算）
├── 滑动窗口语义分块
├── HTML 结构分块
├── 混合语义+固定长度
└── 自适应分块
↓
分块效果可视化 → 块数/平均长度/重叠率对比展示
架构图
graph TB
Upload[文件上传\nPDF/DOCX/PPTX/HTML/MD] --> Parser[格式解析层]
Parser --> P1[PyMuPDF\nPDF解析]
Parser --> P2[python-docx\nDOCX解析]
Parser --> P3[python-pptx\nPPTX分页解析]
Parser --> P4[BeautifulSoup4\nHTML解析]
Parser --> P5[markdown\nMD解析]
P1 --> Engine[分块策略引擎\n9种策略]
P2 --> Engine
P3 --> Engine
P4 --> Engine
P5 --> Engine
Engine --> S1[固定长度分块]
Engine --> S2[递归字符分块]
Engine --> S3[语义分块\nQwen Embedding]
Engine --> S4[Token-Aware分块\ntiktoken]
Engine --> S5[Markdown结构分块]
S1 --> Viz[可视化对比\n块数/均长/重叠率]
S2 --> Viz
S3 --> Viz
S4 --> Viz
S5 --> Viz
技术亮点
- 5 种格式智能适配：每种文件格式独立解析器，PPTX 按页分块保留结构语义
- 语义分块：基于 Qwen Embedding 计算句子相似度，动态决定分块边界
- 实时参数调整：前端滑动调整 chunk_size/overlap/threshold，即时渲染分块结果
- 策略对比分析：多策略并行执行，可视化对比不同策略的分块质量指标
📄 查看详细设计文档
项目背景
工程设备租赁行业积累了大量政策文档、操作规范、计费规则等非结构化知识，传统关键词搜索无法满足语义理解需求。本项目构建基于 RAG 的租赁行业垂直知识问答服务。
系统架构
知识入库
├── 4 个租赁行业知识库 MD 文件（每个 ≥1000 行）
│ ├── 设备租赁政策与合同条款
│ ├── 设备操作规范与安全指南
│ ├── 租赁定价与计费规则
│ └── 设备维护与故障处理
└── Qwen Embedding → 向量化存储（ChromaDB）
↓
检索层（三种模式）
├── 语义检索 → 向量余弦相似度
├── 关键词检索 → BM25 倒排索引
└── 混合检索 → 语义 + 关键词加权融合
↓
重排序（Rerank）→ Cross-Encoder 精排
↓
LLM 问答（Qwen-Max）→ 基于检索上下文生成回答
架构图
graph TB
KB1[设备租赁政策\n与合同条款] --> Embed[Qwen Embedding\n文本向量化]
KB2[设备操作规范\n与安全指南] --> Embed
KB3[租赁定价\n与计费规则] --> Embed
KB4[设备维护\n与故障处理] --> Embed
Embed --> ChromaDB[(ChromaDB\n向量存储)]
Query[用户查询] --> Semantic[语义检索\n向量余弦相似度]
Query --> Keyword[关键词检索\nBM25倒排索引]
Semantic --> Merge[混合检索\n加权融合]
Keyword --> Merge
ChromaDB --> Semantic
Merge --> Rerank[Cross-Encoder\n重排序精排]
Rerank --> LLM[Qwen-Max\n基于上下文生成回答]
LLM --> Output[回答+来源文档+相似度分数]
技术亮点
- 混合检索：语义检索 + 关键词检索双路召回，解决纯向量检索的词频偏差问题
- 重排序算法对比：可视化展示不同 Rerank 策略对检索结果排序的影响
- 垂直领域知识库：4 个专业领域知识库，覆盖租赁行业核心知识图谱
- 检索透明化：前端展示检索来源文档片段和相似度分数，结果可解释
项目背景
在 Project I 知识库 RAG 的基础上，构建面向终端用户的对话式租赁助手，支持多轮对话上下文管理和业务意图识别。
系统架构
多轮对话管理
↓
意图预分类
├── 知识咨询 → Project I RAG 检索问答
├── 业务查询 → MySQL 数据库工具调用
└── 闲聊 → Qwen-Max 直接回复
↓
会话记忆（Session Memory）→ 多轮上下文连贯
↓
流式响应输出（SSE）
架构图
graph TB
Session[多轮对话\nSession Memory] --> Input[用户输入]
Input --> Classify[意图预分类\nQwen-Max]
Classify -->|知识咨询| RAG[Project I RAG\n知识库检索问答]
Classify -->|业务查询| DB[MySQL\n数据库工具调用]
Classify -->|闲聊| Direct[Qwen-Max\n直接回复]
RAG --> Memory[会话记忆更新]
DB --> Memory
Direct --> Memory
Memory --> SSE[SSE流式响应]
SSE --> Frontend[前端实时展示]
技术亮点
- 会话管理：独立 session_id 隔离多用户对话，支持历史上下文追溯
- 工具调用路由：根据意图自动路由至 RAG/SQL/直接回复三种处理模式
- 租赁领域人格：Prompt 工程注入专业客服人格，回复风格统一
📄 查看详细设计文档
项目背景
任务型对话系统的核心挑战是准确识别用户意图并完成信息提取（Slot 填槽）。传统规则方案扩展性差，纯 LLM 方案可控性弱。本项目构建 Few-shot + 配置驱动 + 工具映射的企业级意图识别引擎。
系统架构
用户输入（文本/语音转文本/多轮上下文）
↓
Few-shot 示例选择器
├── 动态选择相似示例（余弦相似度匹配）
├── 难度匹配（easy/medium/hard）
└── 成功率排序（高置信示例优先）
↓
LLM 意图识别（Qwen-Max）
├── 单意图/多意图识别
├── 置信度评分
└── 关键词提取
↓
Slot 填槽引擎
├── NER 命名实体识别
├── 正则匹配（patterns）
└── LLM 结构化抽取
↓
Slot 验证器
├── 必填校验（required_fields）
├── 格式校验（regex validation）
└── 业务规则校验
↓
缺失 Slot 追问（最多3轮，合并追问）
↓
工具映射 → 执行顺序规划（业务规则驱动）
↓
输出：意图 + 置信度 + 已填Slot + 执行计划
架构图
graph TB
Input[用户输入\n文本/语音转文本] --> FewShot[Few-shot 示例选择器\n动态召回相似示例]
FewShot --> IntentLLM[LLM意图识别\nQwen-Max]
IntentLLM --> Intent[意图+置信度\n单意图/多意图]
Intent --> SlotExtract[Slot 填槽引擎]
SlotExtract --> NER[NER命名实体识别]
SlotExtract --> Regex[正则匹配]
SlotExtract --> LLMExtract[LLM结构化抽取]
NER --> Validator[Slot 验证器]
Regex --> Validator
LLMExtract --> Validator
Validator -->|Slot缺失| Clarify[追问生成器\n最多3轮合并追问]
Clarify --> Input
Validator -->|Slot完整| ToolMap[工具映射\n执行顺序规划]
ToolMap --> Output[输出执行计划]
FewShot --> MySQL[(MySQL\n8张配置表)]
技术亮点
- 配置驱动扩展：意图/Slot/Few-shot示例/工具映射全部存储于数据库，无需修改代码即可扩展
- 动态Few-shot：根据输入语义动态召回最相关示例，识别准确率 >90%
- 智能追问合并：多个缺失Slot合并为一次追问，避免用户交互疲劳
- 完整配置管理界面：提供 Web 管理页面，运营人员可直接配置意图、Slot、示例数据（8张配置表）
- Python 3.10+
- Node.js 18+
- MySQL 8.0+
# Python 依赖
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
# 前端依赖
cd web && npm installcp .env.example .env
# 填入 DASHSCOPE_API_KEY 等配置# 后端（端口 8000）
source .venv/bin/activate
python -m uvicorn src.main:app --host 0.0.0.0 --port 8000 --reload
# 前端（端口 3000）
cd web && npm run dev- 前端界面：http://localhost:3000
- 后端 API：http://localhost:8000
- Swagger 文档：http://localhost:8000/docs
- 健康检查：
curl http://localhost:8000/health
.
├── src/
│ ├── apps/
│ │ ├── project_a_report/ # 研报系统
│ │ ├── project_b_invoice/ # 票据助手
│ │ ├── project_c_sql/ # SQL分析师
│ │ ├── project_d_devops/ # DevOps助手
│ │ ├── project_e_diagnosis/ # 售后诊断
│ │ ├── project_f_rental_support/ # 租赁客服
│ │ ├── project_g_contract/ # 合同识别
│ │ ├── project_h_text_chunking/ # 文本分块
│ │ ├── project_i_rent_rag/ # RAG检索
│ │ ├── project_j_rent_assistant/ # AI租赁助手
│ │ └── project_k_intent/ # 意图识别
│ ├── shared/ # 共享模块（LLM/向量库/数据库）
│ └── main.py # FastAPI 入口
├── web/ # Next.js 前端
├── scripts/ # 初始化脚本
├── data/ # 数据存储（ChromaDB/上传文件）
└── tests/ # 测试用例
本平台目前涵盖的 11 个 AI Agent 项目均为原型与演示版本，受限于开发周期，各项目在功能完整性、异常处理、性能优化等方面仍存在不足，距离真实生产级别的使用标准还有持续迭代的空间。
如果你有兴趣参与共建、提出改进建议，或希望在真实业务场景中落地部署，欢迎一起探讨和协作。
如需进一步交流或商业合作，可添加个人微信：yy520926926
也欢迎关注公众号获取更多 AI Agent 技术内容：
MIT License