AI 应用平台为什么要拆分 Java 后端和 Python AI 服务

AI 应用平台为什么要拆分 Java 后端和 Python AI 服务？

摘要：在 AI 应用工作平台中，Java 更适合负责用户、权限、应用管理、会话记录、部署等稳定业务能力；Python 更适合负责大模型调用、Prompt 组织、流式生成、Agent 工具调用和文档处理等 AI 能力。本文结合当前项目的第一阶段拆分实践，简单说明拆分逻辑、职责边界，以及后续应该如何继续演进。

一、为什么要做服务拆分？

最开始做 AI 应用平台时，很多能力都可以直接写在 Java 后端里。

比如：

用户登录
应用创建
对话记录
调用大模型
生成代码
保存文件
部署应用

这样做在项目早期是可以的，因为开发速度快，所有逻辑都在一个 Spring Boot 项目里，调试也比较方便。

但是随着功能越来越多，问题也会变明显。

AI 相关代码和业务代码混在一起，会导致项目边界不清晰。

比如当前项目中，Java 后端既要处理用户、权限、应用管理，又要处理：

大模型配置
Prompt 模板
流式输出
工具调用
代码生成
AI 对话记忆
模型路由

这些能力本质上属于 AI 服务能力，不应该长期和业务系统强耦合。

所以更合理的方式是：

text 复制代码

Java 负责业务系统
Python 负责 AI 服务

也就是：

text 复制代码

Java 管平台，Python 管 AI。

二、Java 和 Python 各自适合做什么？

1. Java 适合负责平台业务

Java 在企业级后端开发中非常成熟，适合做稳定、复杂、长期维护的业务系统。

在当前 AI 应用平台中，Java 应该主要负责：

用户注册登录
用户身份校验
权限控制
应用管理
会话记录
文件记录
调用次数统计
接口限流
数据库读写
Redis 缓存
应用部署
应用截图
对前端提供统一接口

这些能力和 AI 模型没有直接关系，但它们是平台能否真正落地的基础。

例如用户发起一次代码生成请求，Java 需要先判断：

text 复制代码

用户是否登录
应用是否存在
当前用户是否有权限访问这个应用
请求参数是否合法
是否触发限流
生成结果如何保存
会话记录如何落库

这些都应该由 Java 后端统一管理。

2. Python 适合负责 AI 能力

Python 在 AI 生态中更成熟，适合做大模型调用和 AI 工程能力。

在当前项目中，Python AI Service 更适合负责：

调用大模型 API
Prompt 组织
模型路由
流式生成
代码生成
AI 输出格式化
Agent 工具调用
文档解析
向量检索
多模态处理

这些能力用 Python 实现会更灵活。

后续如果要接入：

OpenAI
DeepSeek
通义千问
智谱
Claude
本地大模型
LangChain
LlamaIndex
向量数据库

Python 侧的生态会更丰富，迭代速度也更快。

三、当前项目原来的问题

在拆分前，当前项目的 AI 生成链路大致是：

text 复制代码

前端请求
  ↓
AppController
  ↓
AppServiceImpl
  ↓
AiCodeGeneratorFacade
  ↓
AiCodeGeneratorServiceFactory
  ↓
LangChain4j 调用大模型
  ↓
StreamHandlerExecutor 处理流式结果
  ↓
解析代码并保存文件
  ↓
保存会话记录
  ↓
返回前端

这条链路可以跑通，但是有一个问题：

text 复制代码

Java 同时承担了业务系统和 AI 推理服务两类职责。

四、第一阶段怎么拆？

第一阶段不建议一上来就把所有 AI 代码搬到 Python。

因为当前项目里，AI 部分不只是简单调用模型，还包含：

流式输出
会话保存
代码解析
文件保存
Vue 项目构建
Agent 文件工具

如果一次性全部迁移，风险会比较大。

所以第一阶段采用最小改造方案：

text 复制代码

只把 HTML / MULTI_FILE 的模型调用迁移到 Python
Java 继续保留权限、会话、流式转发、代码解析和文件保存
Vue 工程模式暂时保留 Java 原链路

当前第一阶段拆分后的链路是：

text 复制代码

前端
  ↓
Java AppController
  ↓
Java AppServiceImpl
  ↓
Java 校验用户和应用权限
  ↓
Java 查询最近会话历史
  ↓
Java 调用 Python AI Service
  ↓
Python 调用大模型并流式返回
  ↓
Java 接收流式内容
  ↓
Java 继续处理流式结果
  ↓
Java 保存 AI 回复
  ↓
Java 解析代码并保存文件
  ↓
前端展示生成结果

这样做的好处是：

改动范围小
原来的前端接口不用改
Java 的权限和会话逻辑不用重写
原来的代码解析和保存逻辑还能继续复用
Python 服务先独立跑起来
后续可以继续逐步迁移

五、第一阶段 Java 具体负责什么？

第一阶段完成后，Java 仍然是主后端。

Java 主要负责：

text 复制代码

1. 接收前端请求
2. 校验 appId 和 message 参数
3. 获取当前登录用户
4. 校验应用是否存在
5. 校验用户是否有权限访问应用
6. 判断代码生成类型
7. 查询最近会话历史
8. 保存用户消息
9. 调用 Python AI Service
10. 接收 Python 返回的流式内容
11. 转发 SSE 给前端
12. 保存 AI 回复
13. 解析生成代码
14. 保存代码文件
15. 后续部署和截图

也就是说，Java 仍然掌握业务主流程。

前端不直接访问 Python 服务，而是始终访问 Java。

推荐结构是：

text 复制代码

前端  →  Java 后端  →  Python AI Service

不推荐：

text 复制代码

前端  →  Python AI Service

原因是用户身份、权限、额度、会话记录都应该由 Java 统一控制。

六、第一阶段 Python 具体负责什么？

第一阶段中，Python AI Service 先只负责 AI 生成能力。

Python 主要负责：

text 复制代码

1. 接收 Java 传来的生成请求
2. 根据 codeGenType 选择 Prompt
3. 组织历史消息
4. 调用 OpenAI 兼容大模型接口
5. 以流式方式返回生成内容
6. 在未配置模型 Key 时返回本地兜底内容，方便联调

Python 服务提供的核心接口是：

text 复制代码

POST /api/ai/code/generate/stream

请求大致包含：

json 复制代码

{
  "requestId": "请求ID",
  "appId": 123,
  "userId": 456,
  "message": "帮我生成一个登录页面",
  "codeGenType": "html",
  "model": "gpt-4o-mini",
  "history": [
    {
      "role": "user",
      "content": "我是个ikun"
    },
    {
      "role": "assistant",
      "content": "之前的 AI 回复"
    }
  ]
}

流式返回大致是：

text 复制代码

data: {"type":"chunk","content":"生成内容片段"}

data: {"type":"done"}

Java 收到 chunk 后继续交给原有的流式处理器处理。

七、为什么 Vue 工程模式暂时没迁？

当前项目中，Vue 工程模式比 HTML 和 MULTI_FILE 更复杂。

它不仅是调用模型返回代码，还涉及：

Agent 工具调用
文件读取
文件写入
文件修改
目录读取
Vue 项目构建
构建状态查询

这些能力目前还在 Java 里。

如果第一阶段就把 Vue 工程模式也迁到 Python，需要同时处理文件系统、工具调用、构建产物、目录共享等问题，改动会比较大。

所以第一阶段先保留：

text 复制代码

VUE_PROJECT 继续走 Java 原链路
HTML / MULTI_FILE 先走 Python AI Service

这样可以先验证服务拆分是否可行。

等第一阶段稳定后，再迁移 Vue 工程模式和 Agent 工具。

八、拆分后的项目结构

当前项目可以理解为：

text 复制代码

zero_code/
├── src/main/java/ai/zerocode/       # Java 主后端
│   ├── controller/                  # 对前端接口
│   ├── service/                     # 业务逻辑
│   ├── client/                      # 调用外部服务
│   ├── model/                       # DTO / VO / Entity
│   ├── core/                        # 代码解析、保存、构建等
│   └── config/                      # Java 配置
│
├── ai-service/                      # Python AI 服务
│   ├── app/
│   │   ├── main.py                  # FastAPI 入口
│   │   ├── api/                     # AI 接口
│   │   ├── services/                # AI 业务逻辑
│   │   ├── clients/                 # 大模型客户端
│   │   ├── schemas/                 # 请求响应结构
│   │   └── core/                    # 配置等基础能力
│   ├── requirements.txt
│   ├── Dockerfile
│   └── README.md
│
└── src/main/resources/application.yml

Java 中新增了一个专门调用 Python 的客户端：

text 复制代码

PythonAiClient

它只负责和 Python AI Service 通信。

业务层不应该直接拼 HTTP 请求。

推荐调用方式是：

text 复制代码

Controller
  ↓
Service
  ↓
PythonAiClient
  ↓
Python AI Service

九、后续应该怎么继续改？

第一阶段只是完成了服务拆分的起点。

后面可以分几个阶段继续演进。

十、第二阶段：迁移 Agent 工具调用

当前 Java 中还有一批工具类：

text 复制代码

FileReadTool
FileWriteTool
FileModifyTool
FileDeleteTool
FileDirReadTool
ExitTool
ToolManager

这些工具本质上是 Agent 能力的一部分。

后续更适合迁移到 Python。

第二阶段目标可以定为：

text 复制代码

Python 负责 Agent 工具调用
Java 不再直接处理模型工具调用

迁移后，Python 可以返回更丰富的流式事件：

text 复制代码

data: {"type":"tool_request","toolName":"file_write","arguments":{...}}

data: {"type":"tool_executed","toolName":"file_write","result":"写入成功"}

data: {"type":"chunk","content":"页面已生成完成"}

Java 只负责接收事件、转发前端、保存必要记录。

十一、第三阶段：迁移 Vue 工程生成

第二阶段稳定后，可以继续迁移 Vue 工程模式。

目标是让 Python 负责：

生成 Vue 项目文件
修改 Vue 项目文件
管理 Agent 文件操作
输出项目结构

Java 继续负责：

应用权限
构建状态
部署
截图
数据落库

迁移后的链路可以变成：

text 复制代码

Java 校验用户和应用权限
  ↓
Java 调用 Python
  ↓
Python 生成 Vue 项目文件
  ↓
Python 返回 artifactId 或项目路径
  ↓
Java 保存记录
  ↓
Java 执行构建、部署、截图

十二、第四阶段：去掉 Java 中的 LangChain4j 模型依赖

当 HTML、MULTI_FILE、VUE_PROJECT 都迁到 Python 后，Java 中很多 AI 模型相关代码就可以逐步删除。

例如：

text 复制代码

AiCodeGeneratorService
AiCodeGeneratorServiceFactory
AiCodeGenTypeRoutingService
AiCodeGenTypeRoutingServiceFactory
PromptSafetyInputGuardrail
RetryOutputGuardrail
ReasoningStreamingChatModel
RoutingAiModelConfig
RedisChatMemoryStoreConfig

同时，pom.xml 里和模型调用强相关的依赖也可以减少。

Java 后端会变得更轻：

text 复制代码

Java 不再直接关心模型怎么调用
Java 只关心业务流程和服务编排

这才是比较清晰的职责边界。

十三、第五阶段：完善工程化能力

服务拆分以后，还需要补齐一些工程化能力。

例如：

Python AI Service 健康检查
Java 调 Python 的超时控制
请求 requestId 链路追踪
AI 服务错误码规范
模型调用日志
token 消耗统计
AI 服务限流
失败重试
服务熔断
Docker 部署
CI/CD 构建
OpenAPI 接口文档

这些能力会让服务更接近真实企业项目。

特别是 requestId 很重要。

Java 调 Python 时应该带上 requestId。

Java 日志和 Python 日志都记录同一个 requestId，这样后面排查问题会方便很多。

十四、最终目标架构

最终比较理想的架构是：

text 复制代码

前端
  ↓
Java Spring Boot 主后端
  ↓
Python FastAPI AI Service
  ↓
大模型 API / 向量数据库 / 文档解析工具 / Agent 工具

Java 负责：

text 复制代码

用户
权限
应用
会话
数据库
缓存
限流
部署
截图
对前端接口

Python 负责：

text 复制代码

模型调用
Prompt
代码生成
Agent
工具调用
文档解析
向量检索
多模型适配

这样拆分以后，两个服务可以独立演进。

Java 后端继续保持企业级业务系统的稳定性。

Python AI Service 负责快速接入新的模型和 AI 能力。

十五、总结

这次拆分的核心思路不是为了拆而拆，而是让系统职责更清楚。

AI 应用平台本质上既是业务系统，也是 AI 能力平台。

所以它不适合把所有逻辑都堆在一个服务里。

更合理的方式是：

text 复制代码

Java 做稳定的业务主后端
Python 做灵活的 AI 服务

当前第一阶段已经完成了最小闭环：

text 复制代码

HTML / MULTI_FILE 生成走 Python
Java 保留权限、会话、SSE、解析、保存
Vue 工程模式暂时保留 Java 原链路

后续可以继续按阶段推进：

text 复制代码

第二阶段：迁移 Agent 工具调用
第三阶段：迁移 Vue 工程生成
第四阶段：删除 Java 中的模型依赖
第五阶段：补齐监控、日志、限流、部署等工程化能力

这样改造风险更低，也更符合真实项目的演进方式。

对于 AI 应用工作平台来说，最重要的不是一开始就把架构设计得很复杂，而是先把边界拆清楚：

text 复制代码

Java 负责业务可靠性
Python 负责 AI 扩展性

这个边界清楚以后，后续无论接入新模型、增加知识库、扩展 Agent，还是做企业级部署，都会更容易推进。