前言
前两天，我已经完成了 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 也可以写后端接口。
什么是 uvicorn
FastAPI 写好以后，需要一个工具把服务启动起来。
这个工具通常叫：
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 服务用 FastAPI
- FastAPI 和 Spring Boot 的区别
- uvicorn 是什么
- 什么是健康检查接口
/health - 为什么 AI 服务也要统一返回格式
- Spring Boot 和 FastAPI 以后怎么通信
- 为什么业务服务和 AI 服务要分开
这些概念是后续学习 RAG 和 Agent 的基础。
和面试的关系
如果后续这个项目做完整，面试时可以这样介绍：
我的项目采用 Spring Boot + FastAPI 的双服务架构。
Spring Boot 负责用户、知识库、文档、工单等业务数据。
FastAPI 负责大模型调用、Prompt、Embedding、RAG 和 Agent 工具调用。
两个服务之间通过 HTTP API 通信。
这样可以让业务系统和 AI 能力解耦，方便后续扩展。这比简单说"我会调用大模型接口"更有说服力。
因为它体现的是完整项目设计能力。