上一篇聊了 AI 助手架构设计主要讲 Python Agent 和 Spring Boot 怎么分工。写完以后我发现如果只讲分层还是有点偏架构图。真正理解一个系统最好还是回到后端开发最熟悉的方式看一次请求是怎么流转的。以前做业务接口时我们经常会从请求链路看问题。用户点了一个按钮请求到了哪个 ControllerService 做了什么查了哪些表Redis 有没有命中最后返回了什么。AI 助手其实也可以这样理解。用户输入一句自然语言后背后不是简单“丢给大模型回答”这么直接。一个稍微真实一点的 AI 助手中间可能会经过 Agent 判断、RAG 检索、工具调用、后端接口、数据库查询、结果整理等多个环节。这篇就从一次请求的角度拆一下用户提问后Python Agent 和 Java 后端分别做了什么。先从一个例子开始假设用户在 AI 助手里问了一句帮我看一下订单 10086 为什么还没发货如果只是普通聊天机器人可能会直接把这句话发给大模型让模型生成回答。但这显然不靠谱。模型不知道真实订单状态也不知道库存、支付、仓库这些业务数据。它如果直接回答很可能是在猜。更合理的流程应该是用户提问 - Python Agent 接收问题 - Agent 判断这是订单查询类问题 - Agent 调用 Spring Boot 订单接口 - Java 后端校验权限并查询数据库 - Java 返回订单结构化数据 - Agent 把数据整理成自然语言 - 返回给用户这样回答就不是模型编出来的而是基于后端真实数据生成的。这也是我现在理解 AI 助手的一个关键点模型负责理解和表达业务事实必须来自后端系统。第一步Agent 先理解用户意图用户的问题通常不是接口参数。他不会直接说{ intent: query_order, orderId: 10086 }他只会自然地说我的订单 10086 怎么还没发货所以 Python Agent 第一件事就是理解这句话大概想做什么。它需要判断用户是不是在查订单订单号是多少是否需要调用后端工具是否需要补充追问是否只是普通问答这部分比较适合放在 Agent 层因为它和自然语言理解、Prompt、工具选择关系比较近。从后端角度看这一步有点像以前做参数解析和路由分发只不过输入从固定字段变成了自然语言。第二步Agent 决定要不要调用工具不是所有问题都要调用后端接口。比如用户问Redis 缓存穿透是什么这种问题可能直接让模型回答就行。如果用户问公司报销流程是什么那可能要走 RAG先查知识库资料。如果用户问帮我查一下订单 10086这就需要调用订单接口。所以 Agent 要做一个选择当前问题到底走哪条链路。简单看大概有几类普通问答 - 直接调用大模型 知识库问题 - RAG 检索后调用大模型 业务查询 - 调用 Java 后端接口 业务操作 - 调用 Java 后端接口并让后端校验这里的 Tool Calling 就是关键。它让 Agent 不只是聊天而是可以调用外部业务能力。第三步Java 后端负责查准数据当 Agent 决定要查询订单后它会调用 Spring Boot 提供的接口。比如GET /api/orders/10086这个接口对 Agent 来说是一个工具对 Java 后端来说还是普通业务接口。Java 后端要做的事情和以前一样校验用户身份判断用户有没有权限看这个订单校验订单号是否合法查询 MySQL必要时读取 Redis 缓存处理订单状态和业务规则记录接口调用日志返回结构化结果比如返回{ orderId: 10086, payStatus: 已支付, orderStatus: 待出库, warehouseStatus: 缺货, estimatedShipTime: 2026-08-15 }这些数据必须由后端系统提供不能让模型自己猜。尤其是涉及订单、库存、金额、权限、状态流转这类业务Java 后端仍然是核心。第四步Agent 负责组织回答拿到后端返回的数据后Agent 再把结构化结果组织成用户能看懂的话。比如最终回答可以是这个订单目前已经支付但仓库状态显示部分商品缺货所以还没有发货。系统预计 8 月 15 日可以出库。这一步就是大模型比较擅长的地方。如果直接把 JSON 返回给普通用户用户可能还要自己理解每个字段。让模型把结果解释成人话体验会好很多。但这里也要注意边界。Agent 只能基于后端返回的数据解释不能自己补业务结论。比如后端只返回“待出库”Agent 就不应该自己说“仓库缺货”后端没有预计时间Agent 就不应该编一个时间。Prompt 里最好明确告诉模型只能根据工具返回结果回答不要补充没有依据的信息。如果是知识库问题请求链路会不一样再看另一种问题公司报销流程是怎样的这类问题不一定要查订单系统而是要查知识库。链路可能变成用户提问 - Python Agent 判断是知识库问题 - 根据用户权限确定可检索范围 - RAG 检索相关文档片段 - 组装 Prompt - 调用大模型生成回答 - 返回答案和引用来源这里 Spring Boot 也可能参与。比如文档权限、知识库归属、用户角色关系这些可以由 Java 后端提供。Python Agent 拿到用户可访问的知识库范围后再去做向量检索。所以 RAG 不是完全脱离后端它也需要业务系统提供权限和元数据支撑。会话和日志也很重要一个 AI 助手如果只看单次请求很快就会遇到问题。用户可能连续问查一下订单 10086接着又问那它大概什么时候能发第二句话里的“它”指的是上一轮订单。这时候就需要会话上下文。这部分可以这样设计Redis 保存短期会话上下文MySQL 保存长期问答记录Agent 使用会话 ID 读取历史消息Java 后端记录工具调用日志和业务操作日志日志也不能省。因为 AI 应用上线后问题不一定是接口报错也可能是回答不准、调用错工具、没有命中知识库、模型输出不符合预期。如果没有记录用户问题、Agent 判断、调用了哪个工具、后端返回了什么、模型最终回答了什么后面很难排查。我目前会这样拆职责站在当前学习阶段我会先把职责拆得清楚一点。Python Agent 负责理解用户问题判断意图选择工具执行 RAG组装 Prompt调用大模型生成最终回答Spring Boot 负责提供业务接口校验权限查询 MySQL使用 Redis执行业务规则记录操作日志保证接口稳定性这样分工以后系统边界会清楚很多。Agent 不直接碰核心数据库也不自己决定业务状态。它通过后端接口获取数据、执行操作。Java 后端不负责复杂 Agent 编排只提供稳定可靠的业务能力。怎么实践如果接下来做 Demo我会先从最小链路开始。第一步用 Spring Boot 写一个订单查询接口模拟返回订单状态。第二步用 Python 写一个简单 Agent让它能识别用户是在查订单。第三步把订单查询接口包装成工具Agent 根据用户问题调用它。第四步让 Agent 根据工具返回结果组织自然语言回答。第五步把每次请求链路记录下来包括用户问题、工具调用、后端返回、最终回答。第六步再加 RAG让 Agent 同时支持知识库类问题。这样一来一个 AI 助手的基本请求链路就能跑起来。最后从一次请求链路看AI 助手并不是简单调用大模型。用户提问后Agent 要理解意图、选择工具、组织上下文Java 后端要提供准确数据、校验权限、执行确定性业务逻辑大模型则负责理解自然语言和生成最终表达。对后端开发者来说这个拆法会更容易接受。因为它本质上还是请求、接口、服务、数据、日志这些东西只是中间多了一层 Agent 编排和模型生成。我现在越来越觉得AI 应用开发真正有意思的地方不是把所有东西都交给模型而是让模型和现有业务系统配合起来。下一篇我准备继续聊Python Agent 调 Java 接口业务能力怎么变成工具