前言前两天我已经完成了 KnowFlow Agent 的基础工作。Day 1 主要完成了项目初始化包括项目目录、README、开发文档、Git 仓库和 GitHub 推送。Day 2 主要完成了 Spring Boot 后端基础工程让backend-spring可以启动并且能够访问http://localhost:8080/api/health返回统一格式的 JSON。到了 Day 3项目要开始搭建第二个核心服务FastAPI AI 服务。KnowFlow Agent 的整体架构是Spring Boot FastAPI RAG Agent其中Spring Boot 负责业务FastAPI 负责 AI 能力。Day 3 的目标Day 3 不急着做复杂的大模型调用也不急着实现 RAG 和 Agent。今天的目标很简单让 ai-service 从一个空目录变成一个可以启动、可以访问接口的 FastAPI 服务。最终希望访问http://localhost:8000/health可以返回{ code: 0, message: ok, data: { service: ai-service, status: UP } }这个接口和 Day 2 的 Spring Boot 健康检查接口对应Spring Boot 后端GET /api/health FastAPI AI 服务GET /health这样项目就从单个后端服务开始变成真正的多服务架构。FastAPI 是什么FastAPI 是 Python 里的一个后端框架。它和 Spring Boot 有点像都是用来写后端接口的。区别是Spring Boot 用 Java FastAPI 用 Python在 KnowFlow Agent 这个项目里Spring Boot 主要负责业务系统FastAPI 主要负责 AI 能力。比如以后用户在前端提问某个产品出现故障怎么办Spring Boot 会负责接收请求、记录用户问题、保存问答记录。然后 Spring Boot 会调用 FastAPI。FastAPI 负责检索知识库 组织 Prompt 调用大模型 生成回答 返回 AI 结果所以可以简单理解为FastAPI 是 KnowFlow Agent 的 AI 服务层。为什么 AI 服务要用 FastAPI一开始我会有一个疑问既然 Spring Boot 也可以调用接口为什么不直接用 Spring Boot 调大模型原因主要有三个。1. Python 更适合 AI 开发很多 AI 相关工具和库都优先支持 Python比如文档解析 Embedding 向量数据库 RAG Agent 大模型调用所以把 AI 能力放到 Python 服务里会更方便后续开发。2. 业务和 AI 分开更清楚Spring Boot 负责用户、权限、知识库、文档、工单、数据库、缓存FastAPI 负责LLM、Prompt、Embedding、RAG、Agent这样每个服务职责更清晰。3. 后续扩展更方便如果以后要换大模型、换 RAG 方案、换向量数据库只需要主要修改 FastAPI 服务。Spring Boot 只需要继续负责业务数据和接口流转。这种拆分方式更接近真实工程项目。Day 3 要创建的目录结构Day 3 计划把ai-service整理成下面这样的结构ai-service/ app/ main.py FastAPI 启动入口 core/ config.py 配置管理 api/ health.py 健康检查接口 schemas/ response.py 统一响应格式 services/ llm_service.py 大模型服务占位 rag_service.py RAG 服务占位 agents/ ticket_agent.py 工单 Agent 占位 prompts/ ticket_prompt.py Prompt 占位 requirements.txt Python 依赖 README.md AI 服务说明Day 3 只搭骨架不写复杂业务逻辑。这样做的目的是先让服务能跑再慢慢往里面加能力。FastAPI 最简单的接口一个最简单的 FastAPI 接口大概是这样from fastapi import FastAPI app FastAPI() app.get(/health) def health(): return { service: ai-service, status: UP }这段代码的意思是当用户访问 /health 时执行 health() 函数并返回 JSON。和 Spring Boot 的 Controller 类似。Spring Boot 中可能是GetMapping(/health) public ApiResponse health() { return ApiResponse.success(data); }FastAPI 中就是app.get(/health) def health(): return data所以 Day 3 其实是在学习Python 也可以写后端接口。什么是 uvicornFastAPI 写好以后需要一个工具把服务启动起来。这个工具通常叫uvicorn启动命令类似uvicorn app.main:app --reload --port 8000可以拆开理解uvicorn启动 FastAPI 服务的工具 app.main找到 app/main.py 文件 app找到 main.py 里的 FastAPI 对象 --reload代码修改后自动重启 --port 8000服务运行在 8000 端口Day 2 的 Spring Boot 后端运行在8080 端口Day 3 的 FastAPI AI 服务运行在8000 端口这样两个服务就不会冲突。为什么也要统一返回格式Day 2 的 Spring Boot 后端已经用了统一返回格式{ code: 0, message: ok, data: {} }Day 3 的 FastAPI 服务也应该保持类似格式。原因是以后 Spring Boot 会调用 FastAPI。如果 FastAPI 返回格式稳定Spring Boot 就能更容易处理结果。比如{ code: 0, message: ok, data: { answer: 这是 AI 生成的回答 } }Spring Boot 可以判断code 是否等于 0如果是 0就读取data。如果不是 0就读取message保存错误信息或返回给前端。统一格式能让两个服务之间的协作更清楚。Spring Boot 和 FastAPI 怎么配合后续智能问答流程大概是用户在前端输入问题 ↓ Spring Boot 接收请求 ↓ Spring Boot 保存问答记录 ↓ Spring Boot 调用 FastAPI ↓ FastAPI 执行 RAG 检索和大模型回答 ↓ FastAPI 返回 AI 结果 ↓ Spring Boot 保存回答和引用来源 ↓ 前端展示给用户所以两个服务的分工是Spring Boot 是业务入口 FastAPI 是 AI 能力提供者Spring Boot 不负责复杂 AI 算法。FastAPI 不负责完整业务数据管理。这样项目结构会更加清楚。Day 3 暂时不做什么Day 3 不做这些复杂功能不接真实大模型 不做 Embedding 不接向量数据库 不做 RAG 不做 Agent 工具调用 不做文档解析这些内容会放到后面的阶段。Day 3 只做一个目标让 ai-service 活起来。也就是让 AI 服务能启动、能访问、能返回统一 JSON。Day 3 需要掌握的概念今天主要需要理解这些内容FastAPI 是什么为什么 AI 服务用 FastAPIFastAPI 和 Spring Boot 的区别uvicorn 是什么什么是健康检查接口/health为什么 AI 服务也要统一返回格式Spring Boot 和 FastAPI 以后怎么通信为什么业务服务和 AI 服务要分开这些概念是后续学习 RAG 和 Agent 的基础。和面试的关系如果后续这个项目做完整面试时可以这样介绍我的项目采用 Spring Boot FastAPI 的双服务架构。 Spring Boot 负责用户、知识库、文档、工单等业务数据。 FastAPI 负责大模型调用、Prompt、Embedding、RAG 和 Agent 工具调用。 两个服务之间通过 HTTP API 通信。 这样可以让业务系统和 AI 能力解耦方便后续扩展。这比简单说“我会调用大模型接口”更有说服力。因为它体现的是完整项目设计能力。