前面聊 AI 助手请求链路时我提到一个点Agent 不能只是聊天真正有价值的地方是它能调用业务系统里的能力。比如用户问帮我查一下订单 10086 为什么还没发货这个问题如果只丢给大模型它其实不知道真实订单状态。它最多只能给一个看起来合理的回答但这个回答未必可信。更合理的方式是Python Agent 先理解用户意图发现这是一个订单查询问题然后调用 Java 后端提供的订单接口拿到真实数据后再让模型组织成自然语言回答。这里就引出了一个很重要的问题后端已有的业务接口怎么变成 Agent 可以调用的工具这篇就从后端开发的角度聊聊我的理解。工具不是新东西只是换了调用方做 Java 后端时我们平时写了很多接口。比如GET /api/orders/{orderId} GET /api/users/{userId} POST /api/tickets GET /api/inventory/{sku}以前这些接口主要是给前端页面调用。用户点按钮前端传参数后端处理业务最后返回结果。到了 Agent 场景里调用方变了。不再一定是前端按钮触发而可能是用户的一句话触发。比如用户说帮我查一下订单 10086Python Agent 识别出用户想查订单于是调用GET /api/orders/10086从 Java 后端角度看这个接口还是原来的接口只是调用方从前端变成了 Agent。所以我现在理解的“工具”其实就是把后端已有业务能力用一种 Agent 能理解的方式描述出来。一个接口要变成工具需要多一层描述普通接口文档一般会写 URL、请求方式、参数、返回值。但 Agent 调工具时除了这些还需要知道这个工具适合什么时候用。比如订单查询工具可以描述成工具名称query_order 工具作用根据订单号查询订单状态、支付状态、发货状态 输入参数orderId订单号 适用场景当用户询问订单状态、发货情况、物流前状态时使用这层描述很重要。因为 Agent 面对的是自然语言不是固定按钮。它要根据用户问题判断要不要调用工具、调用哪个工具、参数从哪里提取。如果工具描述太模糊Agent 可能会选错工具。比如用户问库存它却去查订单用户问订单它又去查用户信息。所以后端接口变成工具不只是把 URL 暴露出去还要把能力边界描述清楚。Java 接口还是要保持确定性虽然调用方变成了 Agent但 Java 后端的职责没有变。订单能不能查用户有没有权限参数是否合法数据是否存在这些都必须由 Java 后端判断。比如 Agent 调用订单接口时不能只传一个订单号就完事。后端还要知道当前用户是谁是否有权限查看这个订单。否则就会出现一个很危险的问题用户通过自然语言绕过前端页面限制让 Agent 去调用本不该调用的接口。所以工具调用里权限不能只靠 Agent 判断。Agent 可以负责识别意图但真正的鉴权、数据范围、业务规则必须留在 Spring Boot 后端。这和我们平时做接口一样。不能因为前端隐藏了按钮后端就不做权限校验。到了 AI 应用里也一样不能因为 Agent 看起来“懂业务”就把安全边界交给它。工具返回值最好结构化如果 Java 接口返回一大段文本Agent 当然也能处理。但我更倾向于让后端返回结构化数据。比如订单查询接口返回{ orderId: 10086, orderStatus: 待出库, payStatus: 已支付, warehouseStatus: 部分商品缺货, estimatedShipTime: 2026-08-15 }这样 Agent 拿到数据后再组织成用户能理解的话这个订单已经支付目前处于待出库状态。仓库显示部分商品缺货预计 8 月 15 日可以发货。结构化数据的好处是清晰、稳定、可追踪。如果后面回答不准确我们可以看日志Java 后端返回了什么Agent 又是怎么解释的。这样排查问题会简单很多。不是什么接口都适合直接变成工具这个点我觉得也要注意。不是所有 Java 接口都应该直接暴露给 Agent 调用。比如查询类接口风险相对低一些适合作为第一批工具查询订单查询库存查询用户基础信息查询知识库文档查询工单状态但涉及写操作的接口要谨慎很多取消订单修改地址创建工单修改用户信息发起退款删除数据这些操作最好增加确认机制。比如用户说帮我取消订单 10086Agent 可以先调用订单查询接口确认订单状态是否允许取消然后回复用户这个订单目前还未发货可以取消。是否确认取消只有用户确认后再调用取消订单接口。这种设计会更稳一点。AI 应用里读操作和写操作最好分开对待。工具调用日志一定要留传统接口开发里日志很重要。到了 Agent 调工具这里日志更重要。因为一次用户请求可能不只是一次接口调用。它可能是用户提问 - Agent 判断意图 - 调用订单查询工具 - 调用库存查询工具 - 调用大模型组织回答 - 返回用户如果中间任何一步出问题都需要能追踪。我觉得至少要记录这些信息用户原始问题Agent 判断的意图调用了哪个工具工具入参是什么Java 后端返回了什么模型最终回答是什么整体耗时是否异常这些日志可以先落 MySQL后面量大了再考虑日志系统或链路追踪。没有这些记录AI 应用上线后很容易变成黑盒。用户说“它回答错了”我们却不知道错在 Agent 判断、工具调用还是模型表达。怎么实践如果后面做一个最小 Demo我会先从一个简单订单查询工具开始。第一步用 Spring Boot 写一个订单查询接口返回固定的结构化 JSON。第二步在 Python Agent 里定义一个query_order工具描述清楚它的用途和参数。第三步让 Agent 从用户问题里提取订单号。第四步调用 Java 接口拿到订单数据。第五步把订单数据交给大模型让它生成自然语言回答。第六步把整个过程记录下来包括用户问题、工具名称、入参、返回值和最终回答。这个 Demo 不需要一开始做得很复杂。只要能跑通“自然语言 - 工具调用 - 业务接口 - 自然语言回答”这条链路就已经能说明很多问题。后面再逐步加库存查询、工单创建、知识库检索、权限校验和确认机制。最后Python Agent 调 Java 接口本质上不是把后端系统推倒重来而是把原来给前端调用的业务能力换一种方式提供给 Agent 使用。Java 后端继续负责准确的数据、稳定的接口、权限和业务规则Python Agent 负责理解用户问题、选择工具、组织回答。这样分工以后AI 助手就不只是一个会聊天的入口而是可以逐步连接真实业务系统。对 Java 后端来说这个方向其实挺自然。我们过去写过的很多接口未来都可能变成 Agent 可以调用的工具。下一篇我准备继续把 Tool Calling 单独拿出来聊聊Tool Calling 是什么用后端接口的思路讲清楚。