思考 AI 应用架构

前面几篇文章，我一直是从 Java 后端的角度去理解 AI 应用开发。

比如大模型接口怎么接、Prompt 到底算不算代码、RAG 是什么、知识库背后有哪些后端流程。写到这里，我发现一个问题：如果继续往下做，不能只停留在"怎么调用模型"这一层了。

因为真正做 AI 应用时，它不只是一个接口，也不只是一个问答页面。它背后会涉及模型调用、知识检索、工具调用、业务系统、权限、日志、缓存、任务调度等一整套东西。

所以这篇想先停下来，聊聊我目前对 AI 应用架构的一些思考。

不是所有东西都适合塞进 Java 后端

我做了几年 Java Web 后端，习惯了 Spring Boot 那套开发方式。

Controller 接请求，Service 处理业务，Mapper 查数据库，Redis 做缓存，MQ 做异步，最后对外提供稳定接口。这套东西做业务系统很舒服，也很成熟。

但当我开始看 Agent、RAG、Tool Calling 这些内容时，会发现有些东西用 Java 当然也能做，但不一定是最顺手的。

比如：

Agent 编排
Prompt 调试
工具调用链路
RAG 实验
模型效果评估
多轮对话流程
各种 AI 框架集成

这些方向里，Python 生态明显更活跃。很多 AI 框架、向量库客户端、模型调用 SDK、Agent 工具链，第一优先支持的往往也是 Python。

所以我现在不太想把自己限制在"必须用 Java 做完整 AI 应用"这个思路里。

更现实的路线可能是：Python 负责 AI 能力层，Java 继续负责业务系统和工程支撑。

我目前理解的分层

如果让我设计一个简单 AI 应用，我会先粗略分成三层。

第一层是前端入口。

它可能是一个网页聊天窗口，也可能是后台系统里的智能助手入口，或者是企业微信、钉钉这类 IM 入口。用户的问题从这里进来。

第二层是 AI 能力层。

这一层主要用 Python 来做，负责 Agent、RAG、Prompt、模型调用、工具选择等偏 AI 应用逻辑的部分。比如用户问一句话，Python Agent 判断是普通问答、知识库检索，还是需要调用某个业务接口。

第三层是业务系统层。

这一层还是 Java/Spring Boot 更适合。它负责用户、权限、订单、商品、工单、报表、数据库、缓存这些确定性业务能力。Agent 需要查订单，就调用 Java 提供的订单接口；需要查库存，就调用库存接口；需要创建工单，就调用工单接口。

简单画一下，大概是这样：

复制代码

用户
  -> 前端/聊天入口
  -> Python AI 服务
      -> 大模型
      -> 向量数据库
      -> Prompt 模板
      -> 工具调用
  -> Java 业务服务
      -> MySQL
      -> Redis
      -> MQ
      -> 第三方接口

这里不是说 Java 不重要了，而是它的位置更清楚了：Java 负责稳定的业务底座，Python 负责更灵活的智能编排。

Python Agent 更像"大脑"，Java 服务更像"手脚"

这个比喻不一定严谨，但挺好理解。

Python Agent 负责理解用户意图、选择下一步动作、决定是否调用工具。它更像大脑，负责判断和编排。

Java 业务服务负责执行确定性的操作，比如查订单、查库存、创建记录、更新状态。它更像手脚，负责把具体事情做好。

比如用户问：

复制代码

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

Agent 不应该自己猜订单状态。它应该识别出这是一个订单查询问题，然后调用 Java 后端提供的订单查询接口。

Java 接口返回结构化结果：

复制代码

{
  "orderId": 10086,
  "status": "待出库",
  "payStatus": "已支付",
  "warehouseStatus": "缺货",
  "estimatedShipTime": "2026-08-05"
}

然后 Agent 再把这些确定性数据组织成自然语言：

复制代码

这个订单目前已经支付，但仓库状态是缺货，所以还没有发货。预计 8 月 5 日可以出库。

这个流程里，订单状态来自 Java 后端，不来自模型编造。模型只负责理解和表达。

我觉得这个边界很重要。

确定性的东西，不要交给模型猜

做传统后端时，我们很在意数据准确性。

订单状态是什么，就查订单表；用户有没有权限，就查权限关系；库存还剩多少，就查库存系统。不能因为用户问得自然一点，就让模型自己发挥。

AI 应用里也一样。

模型适合做这些事：

理解自然语言
总结文本
生成解释
判断用户意图
在多个工具之间做选择
把结构化结果转成用户能看懂的话

但模型不适合直接决定这些事：

用户是否有权限
订单是否存在
余额是否足够
库存是否扣减成功
业务状态是否允许流转
数据库是否应该更新

这些必须交给后端系统。

所以我目前的原则是：确定性业务逻辑留在 Java，非确定性的理解和生成交给 Python Agent。

这样做的好处是，AI 应用看起来更智能，但核心业务仍然可控。

RAG 是 AI 能力层的一部分

前面聊过 RAG。放到整体架构里看，RAG 更适合放在 Python AI 服务这一层。

用户提问时，Agent 可以判断是否需要查知识库。如果需要，就调用检索流程：

复制代码

用户问题
  -> 生成向量
  -> 检索相关文档片段
  -> 拼接 Prompt
  -> 调用大模型回答

但知识库的元数据、用户权限、文档归属关系，仍然可以由 Java 或业务系统维护。

比如：

文档属于哪个用户
属于哪个租户
哪些角色可以访问
文档上传记录
文档处理状态
问答日志

这些结构化数据用 MySQL 管起来更清楚。

向量数据库负责语义检索，Python 负责 RAG 流程，Java 负责业务权限和管理接口。这样分工会比较自然。

Tool Calling 是连接 Agent 和业务系统的桥

Agent 如果只会聊天，价值有限。

真正有用的 AI 助手，应该能调用工具。对后端系统来说，这里的工具很多时候就是一个个业务接口。

比如：

查询订单
查询用户信息
创建工单
生成报表
查询库存
获取项目进度
检索知识库

Java 后端可以把这些能力包装成稳定的 HTTP API。Python Agent 通过 Tool Calling 来决定什么时候调用哪个接口。

这样一来，原本一个个普通业务接口，就变成了 Agent 可以使用的工具。

这也是我觉得 Java 后端经验很有价值的地方。因为 Agent 想真正做事，最后还是要落到具体业务接口上。而这些接口的稳定性、安全性、权限控制、幂等处理，依然是后端的基本功。

怎么实践

如果后面自己动手做一个小型 AI 助手，我大概会按这个顺序来。

第一步，先用 Spring Boot 提供几个简单业务接口，比如查询订单、查询用户、查询知识库文档列表。这些接口先不复杂，重点是返回结构清晰。

第二步，用 Python 写一个 AI 服务，先接入大模型，实现普通问答。

第三步，在 Python 服务里接入一个简单 Agent，让它能根据用户问题判断是否需要调用工具。

第四步，把 Java 接口注册成 Agent 可用工具。比如用户问订单问题时，Agent 能调用订单查询接口。

第五步，加上 RAG 能力，让 Agent 在回答文档类问题时，先查知识库再回答。

第六步，再补日志、会话、权限、异常处理和调用链追踪。

这个过程不追求一步到位。先做一个能跑通的小闭环，再慢慢加能力。

最后

现在我对 AI 应用架构的理解还在变化，但有一点越来越清楚：AI 应用不是单纯调用一个大模型接口，也不是把所有业务都交给 Agent。

更合理的方式，是把智能能力和业务系统分开看。

Python 适合做 Agent、RAG、模型调用和灵活编排；Java/Spring Boot 适合做业务接口、权限、数据、缓存、日志和稳定性支撑。

对一个 Java 后端来说，这条路线不是放弃过去的经验，而是把过去的后端能力放到新的 AI 应用架构里继续使用。