前面我写到自己做 AI 应用开发时不太想纠结“到底用 Java 还是 Python”。因为越往后看越发现这不是一个非黑即白的问题。AI 应用不是单纯写一个接口也不是只调一次大模型 API。它里面既有 Agent、RAG、Prompt、Tool Calling 这些偏 AI 应用层的东西也有用户、权限、数据库、缓存、日志、接口稳定性这些传统后端绕不开的问题。所以我现在更倾向于一种分工Python 做 Agent 和 RAGSpring 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 应用开发能力。下一篇我准备继续拆得更细一点一个 AI 助手的请求链路用户提问后Agent 和后端分别做了什么
