今天继续推进 KnowFlow Agent 项目。本次一次完成了 Day08 和 Day09 两部分内容主要围绕“文档进入知识库”展开。前面已经完成了知识库模块知识库可以创建、查询、修改、删除也可以接入 MySQL 保存数据。但只有知识库还不够真正的企业知识库系统还需要能够管理文档。因为后续 RAG 问答、文档切片、Embedding 向量化都是基于文档内容来做的。所以 Day08 和 Day09 的重点就是先让文档进入系统再让后端可以调用 AI 服务发起文档解析。一、今日目标本次主要完成两个目标。Day08完成文档模块基础接口。Day09完成 Spring Boot 和 FastAPI 的文档解析接口联调。简单来说就是先让后端可以保存文档信息再让 Spring Boot 调用 FastAPI得到一个模拟的文档解析结果。二、Day08文档模块基础接口Day08 新增了文档模块主要实现文档元数据管理。这里的“文档元数据”指的是文档的基本信息例如文档 ID 所属知识库 ID 文件名 文件类型 文件路径 文件大小 解析状态 向量化状态 分块数量 上传人 创建时间 更新时间当前阶段还没有真正做文件上传而是先保存文档的基础信息。这样做是为了先把业务流程跑通后面再逐步接入真实文件上传和解析。三、文档模块接口Day08 实现了以下接口GET /api/documents POST /api/documents GET /api/documents/{id} DELETE /api/documents/{id}分别对应查询文档列表 创建文档元数据 查询文档详情 删除文档创建文档时需要绑定知识库 ID例如{ knowledgeBaseId: 1, fileName: 售后政策.txt, fileType: txt, fileSize: 128, uploadedBy: 1 }这样就表示这个文档属于 ID 为 1 的知识库。四、为什么文档要绑定知识库这个项目的目标是做企业智能客服和售后支持系统。一个企业可能有多个知识库例如售后服务知识库 安装维修知识库 产品说明知识库 退换货政策知识库每个知识库下面又会有很多文档。所以文档必须绑定到某一个知识库否则后续用户提问时系统就不知道应该从哪个知识库中检索内容。比如用户问产品坏了可以退吗系统后续需要从“售后服务知识库”或“退换货政策知识库”中检索而不是从所有无关文档中乱找。五、文档状态设计文档模块里设计了两个比较重要的状态parseStatus embeddingStatusparseStatus表示文档解析状态。例如PENDING等待解析 SUCCESS解析成功 FAILED解析失败embeddingStatus表示向量化状态。例如PENDING等待向量化 SUCCESS向量化成功 FAILED向量化失败当前新增文档后这两个状态默认都是PENDING。这是因为文档刚进入系统时还没有经过解析也还没有做向量化。六、Day09文档解析接口联调Day09 的重点是让 Spring Boot 后端可以调用 FastAPI AI 服务。新增了两个接口POST /api/documents/{id}/parse POST /ai/documents/parse其中/api/documents/{id}/parse是 Spring Boot 后端接口。/ai/documents/parse是 FastAPI AI 服务接口。调用流程大致是用户请求 Spring Boot 解析某个文档 Spring Boot 查询文档信息 Spring Boot 调用 FastAPI 文档解析接口 FastAPI 返回解析结果 Spring Boot 更新文档解析状态和分块数量 Spring Boot 返回统一 JSON七、当前解析还是模拟版本目前 FastAPI 的文档解析接口还不是真正解析 PDF、Word 或 TXT 文件而是一个模拟版本。请求示例{ document_id: 1, file_name: 售后政策.txt, content: 七天内质量问题可申请退换货。 }返回结果大概包括document_id file_name parse_status text_length chunk_count preview其中text_length表示文本长度。chunk_count表示预计分块数量。preview表示文本预览。虽然现在是模拟解析但接口结构已经确定了。后面只需要把 FastAPI 内部逻辑替换成真实文件解析即可。八、为什么要分成 Spring Boot 和 FastAPI这个项目采用的是双服务架构Spring Boot负责业务系统 FastAPI负责 AI 能力Spring Boot 更适合做用户管理 知识库管理 文档管理 工单管理 数据库操作 权限控制FastAPI 更适合做文档解析 Prompt 构建 Embedding RAG 检索 Agent 工具调用 大模型调用所以文档解析这类 AI 相关能力放在 FastAPI 中更合适。Spring Boot 只负责发起调用和保存结果。九、本次新增的后端结构这次后端新增了文档模块结构依然保持之前的分层方式Controller Service Repository Domain DTO Client其中Controller负责接收接口请求。Service负责业务逻辑。Repository负责保存和查询文档数据。Domain表示文档对象。DTO用于请求和响应数据传输。Client用于调用 FastAPI AI 服务。相比前几天今天多了一个Client层。它的作用就是专门负责服务之间的 HTTP 调用。十、测试结果本次完成后分别运行了 Spring Boot 和 FastAPI 的测试。测试结果Spring Boot14 个测试全部通过 FastAPI2 个测试全部通过说明文档基础接口正常 文档解析联调流程正常 知识库模块没有被影响 健康检查接口正常 AI 服务文档解析接口正常