AI 助手架构设计：Python Agent 和 Spring Boot 如何分工？

前面我写到，自己做 AI 应用开发时，不太想纠结"到底用 Java 还是 Python"。

因为越往后看越发现，这不是一个非黑即白的问题。AI 应用不是单纯写一个接口，也不是只调一次大模型 API。它里面既有 Agent、RAG、Prompt、Tool Calling 这些偏 AI 应用层的东西，也有用户、权限、数据库、缓存、日志、接口稳定性这些传统后端绕不开的问题。

所以我现在更倾向于一种分工：Python 做 Agent 和 RAG，Spring Boot 做业务系统和工程支撑。

这篇就从一个后端开发者的角度，聊聊如果让我设计一个 AI 助手，我会怎么拆 Python Agent 和 Spring Boot 的职责。

AI 助手不是一个简单聊天框

刚开始看 AI 助手时，很容易把它理解成一个聊天页面。

用户输入一句话，后端调用大模型，然后返回一段回答。这个流程当然能跑，但它更像一个简单问答 Demo。

如果真的想让 AI 助手和业务系统结合起来，它就不能只会聊天。它至少应该能做几类事情：

回答普通问题
查询知识库内容
理解用户意图
调用后端业务接口
根据业务数据生成解释
保存会话和操作记录
处理权限、异常和日志

比如用户问：

复制代码

帮我查一下订单 10086 为什么还没发货

这个问题不能直接丢给模型猜。AI 助手需要识别出这是一个订单查询问题，然后调用订单系统接口，拿到准确数据后再组织回答。

所以 AI 助手背后其实是一条链路，而不是一个简单的聊天框。

Python Agent 负责"理解和编排"

我理解的 Python Agent，主要负责偏智能层的事情。

比如用户输入一句话后，Agent 要先判断用户想做什么。是普通闲聊？是查知识库？是查询订单？还是需要创建工单？

这部分逻辑比较适合放在 Python 里。

原因也比较现实：Python 的 AI 生态更丰富，做模型调用、Prompt 调试、Agent 编排、RAG 实验都更方便。很多框架和示例也是 Python 优先，对学习和快速试错更友好。

Python Agent 可以负责这些事情：

接收用户问题
判断用户意图
选择是否调用工具
执行 RAG 检索
组装 Prompt
调用大模型
整理最终回答
记录模型调用过程

它更像一个"调度层"。不是所有事情都自己做，而是根据用户问题决定下一步该找谁做。

Spring Boot 负责"业务和稳定性"

Spring Boot 这边，我不会让它去承担太多 Agent 编排逻辑。

它更适合继续做自己擅长的事：业务接口、权限控制、数据读写、缓存、日志、异常处理。

比如订单系统、用户系统、库存系统、工单系统，这些核心业务能力，还是应该由 Java 后端负责。

Java 服务可以提供这些接口：

查询订单详情
查询用户信息
查询库存状态
创建工单
获取报表数据
查询知识库权限
保存会话记录
保存工具调用日志

这些接口本质上和以前给前端调用的接口差不多，只是现在调用方多了一个 Python Agent。

以前是页面按钮触发接口，现在可能是用户一句自然语言触发接口。

但不管调用方是谁，权限校验、参数校验、业务规则都不能省。

一个简单的分层大概是这样

如果先不考虑特别复杂的微服务架构，我会先设计成这样：

复制代码

用户
  -> 前端聊天入口
  -> Python Agent 服务
      -> 大模型 API
      -> RAG 检索
      -> Tool Calling
  -> Spring Boot 业务服务
      -> MySQL
      -> Redis
      -> MQ
      -> 业务接口

用户的问题先进入 Python Agent 服务。

Agent 判断问题类型。如果是知识类问题，就走 RAG；如果是业务类问题，就调用 Spring Boot 提供的接口；如果只是普通问答，就直接调用大模型。

Spring Boot 不直接决定模型怎么回答，它只负责提供准确、稳定、可控的业务能力。

这个边界我觉得很重要。

Tool Calling 是两边配合的关键

Python Agent 和 Spring Boot 之间怎么配合？我目前觉得核心就是 Tool Calling。

从后端角度看，Tool Calling 可以先理解成：把后端接口包装成 Agent 可以调用的工具。

比如有一个订单查询接口：

复制代码

GET /api/orders/{orderId}

对前端来说，这是一个普通 HTTP 接口。

对 Agent 来说，它可以被描述成一个工具：

复制代码

工具名称：query_order
工具作用：根据订单号查询订单状态
输入参数：orderId
返回结果：订单状态、支付状态、发货状态、预计发货时间

当用户问"订单 10086 为什么还没发货"时，Agent 可以判断需要调用 query_order，然后把订单号传给 Java 后端。

Java 返回结构化数据后，Agent 再把结果组织成自然语言。

这样 AI 助手就不只是"回答问题"，而是能真正连接业务系统。

数据边界要想清楚

做 AI 应用时，我觉得最容易模糊的地方就是数据边界。

哪些数据可以交给 Agent？哪些必须留在后端？

我的理解是，确定性业务数据应该留在 Java 后端。

比如：

用户是否有权限
订单是否存在
库存是否充足
工单是否创建成功
某个状态能不能流转
数据库是否需要更新

这些不能交给大模型判断，也不应该让 Agent 自己猜。

Agent 可以负责理解用户表达，但最终业务判断必须由后端接口完成。

比如用户说：

复制代码

帮我把这个订单取消掉

Agent 可以识别用户想取消订单，但真正能不能取消，要由 Java 后端根据订单状态、支付状态、发货状态来判断。

这样系统才是可控的。

RAG 放在 Agent 层更自然

知识库问答这块，我更倾向于放在 Python Agent 服务里。

原因是 RAG 本身和模型调用、Prompt 拼接、检索策略关系比较近，用 Python 做会更灵活。

但知识库的管理数据，不一定全放 Python。

比如文档基本信息、用户权限、租户关系、上传记录、处理状态，可以放在 Spring Boot 业务系统里，用 MySQL 管。

向量数据可以放向量数据库，Python Agent 查询时结合权限范围进行检索。

大概可以这样分：

复制代码

Spring Boot：
管理文档、用户、权限、上传记录

Python Agent：
执行文本检索、Prompt 组装、模型回答

向量数据库：
保存文本片段向量，提供语义检索

这样不会把所有东西都堆到一个服务里。

怎么实践

如果现在让我开始实践，我不会一上来做完整平台。

我会先做一个最小可跑的版本。

第一步，用 Spring Boot 写几个模拟业务接口，比如查询订单、查询库存、创建工单。

第二步，用 Python 写一个 Agent 服务，先能接收用户问题并调用大模型。

第三步，把 Java 接口包装成工具，让 Agent 能根据用户问题调用对应接口。

第四步，加一个简单知识库，支持上传 Markdown 或 TXT，先跑通 RAG。

第五步，保存会话记录、工具调用记录和模型调用日志。

第六步，再慢慢补权限、限流、异常处理、流式输出和前端页面。

这样做的好处是，每一步都能看到效果，不会一开始就陷进复杂架构里。

最后

现在我对 AI 助手架构的理解是：不要把它看成一个单独的 AI 功能，而是看成一套"智能层 + 业务层"的组合。

Python Agent 负责理解、编排、RAG、Tool Calling 和模型调用；Spring Boot 负责业务接口、权限、数据、缓存、日志和系统稳定性。

这不是放弃 Java，也不是完全转 Python，而是让两边各自做更适合的事情。

对我这种 Java 后端背景的人来说，这条路线比较自然。过去积累的后端经验不会浪费，同时也能慢慢切入 Agent、RAG 这些 AI 应用开发能力。