企业官网建设流程全解析

1. 项目概述：这不是“调用函数”，而是让AI真正听懂业务语言

Function Calling 这个词最近在Java后端圈子里火得有点突然——不是因为大家突然爱上了Python的OpenAI SDK，而是Spring AI 2.0正式把这套机制原生塞进了Spring Boot的血脉里。我第一次在IntelliJ IDEA里敲出@Bean FunctionCallingAgent时，手是抖的。不是因为紧张，是因为终于不用再写一堆if-else去解析LLM返回的JSON字符串了。过去半年，我带三个团队重构跨境商城的客服工单系统，核心痛点就一个：用户说“帮我查下订单号SH202405178892的物流”，后端要硬编码识别“查物流”意图、提取订单号、校验格式、调用WMS接口、再拼装成自然语言回复……整个链路像在走钢丝，改一个正则就崩一片。而Spring AI的Function Calling，本质是把“业务能力”注册成AI可理解的契约，让大模型不再瞎猜，而是精准调用——它不是API网关的替代品，而是语义层的智能路由中枢。

这个标题里的“从0到1吃透”，真不是营销话术。我见过太多人卡在第一步：以为只要加个spring-ai-spring-boot-starter依赖，再写个@Bean FunctionCallback就能跑通。结果连最基础的tool_choice="auto"都触发不了回调，日志里只有一堆{"role":"assistant","content":"我正在为您查询..."}的无效响应。问题不在代码，而在对Function Calling底层契约的理解断层——它要求你同时站在LLM提示工程、Spring Bean生命周期、MySQL事务边界、以及Java函数式编程四个维度上思考。比如，你定义的getOrderStatus(String orderNo)方法，Spring AI不仅要能序列化它的参数结构，还要确保在调用失败时，错误信息能以LLM可解析的格式回传，而不是抛出NullPointerException直接中断整个对话流。这背后涉及OpenAI Function Schema的Java映射规则、Spring AI的ToolProvider注册时机、以及MySQL连接池在异步调用链中的线程上下文传递——任何一个环节没对齐，就会出现“模型知道该调用，但永远调不到”的诡异现象。

适合谁来读？如果你正在用Spring Boot 3.x开发需要集成大模型能力的系统（比如多商户商城的智能导购、跨境支付的风险审核、SaaS平台的自然语言报表生成），并且已经踩过“手动解析JSON→硬编码调用→拼接回复”的坑；或者你刚接触Spring AI，被官方文档里FunctionCallback和ToolProvider绕得头晕，想知道为什么同样的代码在Alibaba Qwen3.7和本地Ollama模型上表现天差地别；又或者你正准备Java面试，发现“Spring AI Agent如何保证事务一致性”成了新晋高频题——那这篇就是为你写的。它不讲概念，只拆真实场景里的每一行代码、每一个配置项、每一次调试日志背后的逻辑。接下来的内容，全部来自我在生产环境落地7个Function Calling模块的实操记录，包括MySQL连接泄漏的定位过程、IntelliJ IDEA社区版调试Agent的隐藏技巧、以及Spring Boot 2.6.x与3.2.x在工具注册机制上的关键差异。

2. 核心设计思路：为什么必须放弃“封装一层API”的思维

2.1 Function Calling的本质不是远程调用，而是语义契约协商

很多人一上来就想把现有Service方法直接标上@FunctionCallback，结果发现模型根本不会触发调用。根源在于混淆了“函数调用”和“Function Calling”的本质区别。前者是Java进程内方法执行，后者是LLM与后端系统之间的一次双向语义协商。举个具体例子：当用户问“订单SH202405178892的物流到哪了”，LLM需要做三件事：第一，确认自己无法凭已有知识回答（即触发tool call）；第二，从预设的工具列表中精准匹配getOrderStatus；第三，将用户输入中的“SH202405178892”正确提取并填充到orderNo参数。这三个步骤缺一不可，而Spring AI的职责，就是确保Java端提供的工具描述（Schema）能被LLM无歧义解析。

这就决定了设计起点必须是Schema先行。我见过最典型的反模式，是先写好OrderService.getOrderStatus()方法，再用@FunctionCallback注解强行包装。问题在于：Java方法签名（如String getOrderStatus(String orderNo)）和OpenAI Function Schema（要求明确type: "string",description: "12位字母数字组合的订单号"）存在天然鸿沟。Spring AI 2.0虽然提供了自动推导，但实际生产中，我们发现自动推导的Schema缺少关键约束——比如orderNo字段在MySQL里是VARCHAR(16) NOT NULL，但自动生成的Schema默认允许null，导致LLM可能传入空值，进而引发后续NPE。解决方案是彻底放弃自动推导，手动编写FunctionCallback的FunctionDescription：

@Bean public FunctionCallback getOrderStatusCallback() { return FunctionCallback.builder("getOrderStatus") .description("根据订单号查询物流状态，仅支持已支付订单") .parameter("orderNo", String.class, p -> p.description("12-16位大写字母与数字组合，例如SH202405178892") .required(true) .pattern("[A-Z0-9]{12,16}")) // 关键！显式声明正则约束 .handle((Map<String, Object> arguments) -> { String orderNo = (String) arguments.get("orderNo"); // 此处必须包含完整的业务校验，不能依赖数据库唯一索引兜底 if (!orderNo.matches("[A-Z0-9]{12,16}")) { throw new IllegalArgumentException("订单号格式非法"); } return orderService.getStatus(orderNo); }) .build(); }

这段代码里藏着三个必须死磕的细节：第一，pattern参数不是可选的，它直接决定LLM能否生成合法参数；第二，handle方法里的校验必须冗余——即使MySQL有CHECK约束，Java层也要拦截，因为LLM传参错误属于语义层问题，不该让数据库报错污染对话流；第三，description必须包含业务语境（“仅支持已支付订单”），这是引导LLM在用户问“未支付订单能查吗”时主动拒绝的关键依据。这些都不是框架能替你做的，而是需要你以“LLM产品经理”的视角重新设计每个函数的契约。

2.2 Spring AI Agent不是黑盒，而是可插拔的编排引擎

另一个常见误区，是把FunctionCallingAgent当成开箱即用的“AI代理”。实际上，Spring AI 2.0的Agent设计极度模块化，核心由四部分组成：PromptTemplate（提示词模板）、ChatModel（大模型客户端）、ToolProvider（工具提供者）、OutputParser（输出解析器）。它们之间的协作关系，直接决定了Function Calling的健壮性。比如，我们曾遇到一个诡异问题：在Qwen3.7模型上，getOrderStatus能稳定触发，但在本地Ollama运行的Llama3模型上，始终返回content而非tool_calls。排查发现，Ollama的Llama3默认不启用function calling能力，需要在启动参数中添加--enable-tool-calling，而Spring AI的ChatModel配置里，必须显式指定modelOptions：

@Bean public ChatModel chatModel() { return OllamaChatModel.builder() .baseUrl("http://localhost:11434") .modelName("llama3") .modelOptions(opts -> opts .temperature(0.3) .numPredict(512) .toolChoice("auto") // 关键！必须显式设置 ) .build(); }

这里toolChoice("auto")是生死线。如果省略，Ollama会按普通文本生成模式响应，即使你注册了工具，LLM也不会尝试调用。而Qwen3.7在百炼平台部署时，默认启用了工具调用，所以容易让人误以为这是模型特性而非配置项。这种差异暴露了一个核心原则：Agent的可靠性取决于所有组件的显式协同，而非某个组件的“智能”。我们最终在生产环境强制要求：所有ChatModel配置必须包含toolChoice，所有FunctionCallback必须包含pattern和description，所有PromptTemplate必须预留{tools}占位符——这三者构成铁三角，缺一不可。

2.3 MySQL不是数据源，而是语义执行的最终仲裁者

Function Calling的终点不是Java方法返回值，而是MySQL事务的提交结果。这点常被忽略。比如refundOrder(String orderNo, BigDecimal amount)函数，如果只关注Java层返回"退款成功"，而忽略MySQL里refund_log表的插入是否成功，就会出现LLM告诉用户“已退款”，但实际资金未划转的灾难。我们的解决方案是将MySQL操作封装进@Transactional方法，并在FunctionCallback.handle()中捕获所有异常：

@Bean public FunctionCallback refundOrderCallback() { return FunctionCallback.builder("refundOrder") .description("为指定订单执行全额退款，需校验订单状态和余额") .parameter("orderNo", String.class, p -> p.required(true)) .parameter("amount", BigDecimal.class, p -> p.required(true).description("退款金额，单位：元")) .handle((Map<String, Object> args) -> { try { String orderNo = (String) args.get("orderNo"); BigDecimal amount = (BigDecimal) args.get("amount"); // 关键：所有数据库操作必须在此方法内完成，且事务由Spring管理 RefundResult result = paymentService.refund(orderNo, amount); // 返回给LLM的必须是结构化数据，而非原始对象 return Map.of( "status", result.isSuccess() ? "success" : "failed", "message", result.getMessage(), "refundId", result.getRefundId() ); } catch (InsufficientBalanceException e) { // 特殊异常必须转换为LLM可理解的错误格式 return Map.of("error", "余额不足，无法退款"); } catch (Exception e) { // 通用异常兜底，避免栈信息泄露 return Map.of("error", "退款服务暂时不可用，请稍后重试"); } }) .build(); }

这里有两个硬性规范：第一，handle()方法内必须完成所有数据库操作，不能异步委托；第二，返回值必须是Map<String, Object>，且error字段名要与LLM的错误处理逻辑对齐（我们约定所有工具返回error表示失败，status表示成功）。这样做的好处是，当LLM收到{"error": "余额不足"}时，能自动生成“您的账户余额不足，当前可用余额为XXX元”的人性化回复，而不是冷冰冰的“调用失败”。

3. 实操细节拆解：从依赖配置到生产级容错

3.1 依赖版本矩阵：Spring Boot 3.2.x + Spring AI 2.0.1 + MySQL 8.0.33

版本兼容性是Function Calling落地的第一道坎。我们踩过的最大坑，是Spring Boot 2.6.x与Spring AI 1.x的组合——当时FunctionCallback的注册机制依赖ApplicationContextInitializer，但在Spring Boot 3.x的ApplicationContext刷新流程中，工具注册时机发生了变化，导致Agent初始化时找不到已注册的工具。最终锁定的黄金组合是：

pom.xml关键依赖如下：

<dependencies> <!-- Spring Boot Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>3.2.5</version> </dependency> <!-- Spring AI Core --> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-spring-boot-starter</artifactId> <version>2.0.1</version> </dependency> <!-- MySQL Driver --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-j</artifactId> <version>8.2.0</version> </dependency> <!-- MyBatis-Plus --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-spring-boot3-starter</artifactId> <version>3.5.5</version> </dependency> </dependencies>

特别注意：spring-ai-spring-boot-starter必须使用2.0.1，低版本在FunctionCallback参数类型推导时存在ClassCastException（当参数为BigDecimal时会转成Double）。这个Bug在2.0.1中通过引入ParameterTypeResolver类修复，原理是在FunctionCallbackBuilder中显式调用TypeDescriptor进行安全转换。

3.2 IntelliJ IDEA社区版调试技巧：绕过商业版的AI Assistant限制

很多开发者卡在调试环节——IntelliJ IDEA社区版不内置AI Assistant，无法直接查看LLM的tool_calls原始请求。我们的土办法是利用Spring Boot的LoggingChatClient，在application.yml中开启详细日志：

logging: level: org.springframework.ai: DEBUG org.springframework.ai.chat.ChatClient: DEBUG org.springframework.ai.chat.prompt.PromptTemplate: DEBUG spring: ai: chat: model: ollama:llama3 options: temperature: 0.3 tool-choice: auto

然后在FunctionCallback.handle()方法开头添加断点，并在Debug模式下观察arguments变量的实时内容。更高效的方式是自定义ChatResponse拦截器：

@Component public class DebugChatResponseInterceptor implements ChatResponseInterceptor { private static final Logger log = LoggerFactory.getLogger(DebugChatResponseInterceptor.class); @Override public void intercept(ChatResponse response) { // 拦截LLM返回的原始响应，打印tool_calls详情 if (response.getResults() != null && !response.getResults().isEmpty()) { ChatResponse.Choice choice = response.getResults().get(0); if (choice.getDelta() != null && choice.getDelta().getToolCalls() != null) { log.info("【Function Calling触发】工具调用: {}", choice.getDelta().getToolCalls()); } } } }

这个拦截器能实时捕获LLM返回的tool_calls数组，包括id、function.name、function.arguments等字段。我们在生产环境也保留此拦截器，但只在logback-spring.xml中配置<filter class="ch.qos.logback.core.filter.LevelFilter">，将日志级别设为WARN，避免DEBUG日志刷爆磁盘。

3.3 MySQL连接池的线程安全陷阱：HikariCP的allowPoolSuspension必须关闭

Function Calling的调用链是：User Request → Spring MVC → ChatClient → LLM → Tool Callback → MySQL。其中Tool Callback的handle()方法默认在ChatClient的IO线程中执行，而MyBatis的SqlSession依赖于Spring的TransactionSynchronizationManager，该管理器基于ThreadLocal存储事务上下文。如果handle()方法在非主线程执行，@Transactional注解会失效，导致数据库操作不在事务中。

解决方案是强制FunctionCallback在Spring管理的线程中执行。我们在application.yml中配置：

spring: ai: chat: client: thread-pool: core-size: 4 max-size: 8 queue-capacity: 100

同时，在FunctionCallback的handle()方法中，显式使用TaskExecutor：

@Autowired private TaskExecutor taskExecutor; @Bean public FunctionCallback getOrderStatusCallback() { return FunctionCallback.builder("getOrderStatus") .handle((Map<String, Object> args) -> { CompletableFuture<Map<String, Object>> future = new CompletableFuture<>(); taskExecutor.execute(() -> { try { String orderNo = (String) args.get("orderNo"); Map<String, Object> result = orderService.getStatus(orderNo); future.complete(result); } catch (Exception e) { future.completeExceptionally(e); } }); return future.join(); // 阻塞等待，确保同步返回 }) .build(); }

这里taskExecutor使用的是Spring Boot自动配置的ThreadPoolTaskExecutor，其线程池与TransactionSynchronizationManager兼容。关键点在于future.join()——必须阻塞等待结果，否则handle()会立即返回null，导致LLM收到空响应。我们测试过CompletableFuture.thenApply()的异步方式，结果LLM永远收不到工具调用结果，因为ChatClient的响应处理器在handle()返回后就结束了生命周期。

3.4 生产级容错设计：超时熔断与降级策略

Function Calling最大的风险是LLM调用链的雪崩。比如getOrderStatus依赖的WMS接口超时，会导致整个对话流卡死。我们的容错体系分三层：

第一层：工具级超时
在FunctionCallback.handle()中使用Timeout装饰器：

@Bean public FunctionCallback getOrderStatusCallback() { return FunctionCallback.builder("getOrderStatus") .handle((Map<String, Object> args) -> { return Timeout.decorateFuture( () -> CompletableFuture.supplyAsync(() -> { String orderNo = (String) args.get("orderNo"); return orderService.getStatus(orderNo); }, taskExecutor), Duration.ofSeconds(3) // 工具调用超时3秒 ).join(); }) .build(); }

第二层：Agent级熔断
使用Resilience4j配置CircuitBreaker：

@Bean public CircuitBreaker circuitBreaker() { return CircuitBreaker.ofDefaults("function-calling"); } @Bean public FunctionCallback getOrderStatusCallback(CircuitBreaker circuitBreaker) { return FunctionCallback.builder("getOrderStatus") .handle((Map<String, Object> args) -> { return circuitBreaker.executeSupplier(() -> { String orderNo = (String) args.get("orderNo"); return orderService.getStatus(orderNo); }); }) .build(); }

第三层：LLM级降级
当所有工具调用失败时，触发备用提示词：

@Bean public PromptTemplate fallbackPromptTemplate() { return PromptTemplate.from( """ 你是一个智能客服助手。当前系统功能暂时不可用，无法查询订单状态。 请向用户说明情况，并提供人工客服联系方式：400-123-4567。 用户原始问题：{userMessage} """ ); }

这三层容错在跨境商城大促期间经受住了考验：当WMS接口因流量激增超时，getOrderStatus自动熔断，LLM切换到备用提示词，用户收到“系统繁忙，稍后重试”的友好提示，而非“内部服务器错误”的技术报错。

4. 完整实战流程：从零搭建跨境商城订单查询Agent

4.1 第一步：定义领域工具契约（Schema设计）

以跨境商城的核心场景“订单查询”为例，我们定义三个工具：

注意countryCode参数的设计意图：跨境商城的物流系统按国家分库，getOrderStatus必须将countryCode作为路由键，否则会查错库。这个参数在Schema中必须显式声明，因为LLM需要据此生成正确的调用参数。

4.2 第二步：实现工具回调（Java代码落地）

@Service public class OrderToolService { @Autowired private WmsClient wmsClient; // 跨境WMS微服务客户端 @Autowired private OrderMapper orderMapper; // MyBatis-Plus Mapper @Transactional public Map<String, Object> getOrderStatus(String orderNo, String countryCode) { // 1. 校验订单号格式 if (!orderNo.matches("[A-Z0-9]{12,16}")) { throw new IllegalArgumentException("订单号格式非法"); } // 2. 校验国家码 if (!Arrays.asList("US", "CA", "UK", "DE", "FR").contains(countryCode)) { throw new IllegalArgumentException("不支持的国家代码"); } // 3. 查询主订单信息（MySQL） OrderEntity order = orderMapper.selectById(orderNo); if (order == null) { throw new IllegalArgumentException("订单不存在"); } // 4. 调用WMS获取物流（HTTP Client） WmsResponse wmsResp = wmsClient.getStatus(orderNo, countryCode); // 5. 合并结果 return Map.of( "orderNo", orderNo, "status", order.getStatus(), "wmsStatus", wmsResp.getStatus(), "trackingNumber", wmsResp.getTrackingNumber(), "estimatedDelivery", wmsResp.getEstimatedDelivery() ); } @Transactional public List<Map<String, Object>> listOrderItems(String orderNo, boolean includePrice) { // 实现逻辑类似，此处省略 return Collections.emptyList(); } @Transactional public Map<String, Object> cancelOrder(String orderNo, String reason) { // 实现逻辑类似，此处省略 return Collections.emptyMap(); } }

关键点：所有方法都标注@Transactional，确保MySQL操作与WMS调用在同一个事务中（通过Saga模式补偿）。getOrderStatus方法内，我们做了三层校验：格式校验（正则）、业务校验（国家码白名单）、存在性校验（数据库查询），这比单纯依赖数据库约束更可靠。

4.3 第三步：注册工具到Agent（Spring Bean配置）

@Configuration public class FunctionCallingConfig { @Autowired private OrderToolService orderToolService; @Bean public FunctionCallback getOrderStatusCallback() { return FunctionCallback.builder("getOrderStatus") .description("查询跨境订单的物流状态，需指定国家代码以路由到对应WMS系统") .parameter("orderNo", String.class, p -> p.description("12-16位大写字母与数字组合的订单号") .required(true) .pattern("[A-Z0-9]{12,16}")) .parameter("countryCode", String.class, p -> p.description("收货国家代码，支持US/CA/UK/DE/FR") .required(true) .enumValues("US", "CA", "UK", "DE", "FR")) .handle((Map<String, Object> args) -> { String orderNo = (String) args.get("orderNo"); String countryCode = (String) args.get("countryCode"); return orderToolService.getOrderStatus(orderNo, countryCode); }) .build(); } @Bean public FunctionCallback listOrderItemsCallback() { // 类似实现，省略 return null; } @Bean public FunctionCallback cancelOrderCallback() { // 类似实现，省略 return null; } @Bean public FunctionCallingAgent functionCallingAgent(ChatModel chatModel, ToolProvider toolProvider) { return FunctionCallingAgent.builder() .chatModel(chatModel) .toolProvider(toolProvider) .promptTemplate(PromptTemplate.from( """ 你是一个专业的跨境商城客服助手，严格遵循以下规则： 1. 所有订单查询必须调用getOrderStatus工具，并传入countryCode参数 2. 当用户未提供countryCode时，必须追问用户收货国家 3. 禁止猜测订单号或国家代码，必须严格按工具参数要求执行 4. 如果工具调用失败，用中文向用户说明原因，不要暴露技术细节 用户问题：{userMessage} """ )) .build(); } }

这里promptTemplate的第四条规则至关重要——它教会LLM在countryCode缺失时主动追问，而不是自行猜测。我们测试过，没有这条规则时，LLM会随机填入US，导致查到错误国家的物流信息。

4.4 第四步：暴露REST API（Controller层）

@RestController @RequestMapping("/api/v1/chat") public class ChatController { @Autowired private FunctionCallingAgent agent; @PostMapping("/query") public ResponseEntity<Map<String, Object>> chat(@RequestBody ChatRequest request) { try { // 构建ChatClient的Message列表 List<ChatMessage> messages = new ArrayList<>(); messages.add(SystemMessage.of("你是一个跨境商城智能客服")); messages.add(UserMessage.of(request.getUserMessage())); // 调用Agent ChatResponse response = agent.call(messages); // 解析响应 String content = ""; if (response.getResults() != null && !response.getResults().isEmpty()) { content = response.getResults().get(0).getMessage().getContent(); } return ResponseEntity.ok(Map.of("reply", content)); } catch (Exception e) { // 全局异常处理，避免500暴露堆栈 return ResponseEntity.status(500).body(Map.of("reply", "服务暂时不可用，请稍后重试")); } } } @Data public class ChatRequest { private String userMessage; }

注意：ChatController不直接暴露FunctionCallback，而是通过FunctionCallingAgent统一入口。这样做的好处是，所有对话状态、工具调用历史、错误日志都集中在Agent层，便于监控和审计。

4.5 第五步：验证与压测（Postman + JMeter）

使用Postman发送测试请求：

POST /api/v1/chat/query { "userMessage": "帮我查下订单号SH202405178892的物流，收货地是德国" }

预期响应：

{ "reply": "订单SH202405178892当前物流状态为'已发货'，运单号DE123456789DE，预计送达时间2024-06-15。" }

压测时重点关注三个指标：

• 工具调用成功率：应≥99.9%（低于此值说明Schema或校验逻辑有问题）
• 平均响应延迟：≤1.2秒（LLM生成+工具调用+MySQL查询）
• MySQL连接池活跃数：峰值≤50（避免连接耗尽）

我们用JMeter模拟100并发，发现当getOrderStatus的countryCode参数缺失时，LLM会持续追问，导致对话轮次增加，延迟上升。解决方案是在PromptTemplate中加入超时机制：“如果用户三次未提供countryCode，则返回‘请提供收货国家代码，例如US或DE’”。

5. 常见问题与独家排查技巧

5.1 问题速查表：Function Calling不触发的7种原因

5.2 独家避坑技巧：来自生产环境的血泪经验

技巧1：用@Valid替代手动校验，但必须配合BindingResult
我们曾尝试在FunctionCallback.handle()中使用@Valid注解，结果发现Spring的Validator不生效。原因是FunctionCallback的参数是Map<String, Object>，而非POJO。最终方案是创建专用DTO：

public class GetOrderStatusRequest { @NotBlank(message = "订单号不能为空") @Pattern(regexp = "[A-Z0-9]{12,16}", message = "订单号格式错误") private String orderNo; @NotBlank(message = "国家代码不能为空") @Pattern(regexp = "US|CA|UK|DE|FR", message = "不支持的国家代码") private String countryCode; // getter/setter } // 在handle中 .handle((Map<String, Object> args) -> { GetOrderStatusRequest req = new GetOrderStatusRequest(); req.setOrderNo((String) args.get("orderNo")); req.setCountryCode((String) args.get("countryCode")); BindingResult result = new BeanPropertyBindingResult(req, "req"); validator.validate(req, result); if (result.hasErrors()) { throw new IllegalArgumentException(result.getFieldError().getDefaultMessage()); } return orderToolService.getOrderStatus(req.getOrderNo(), req.getCountryCode()); })

技巧2：MySQL时区问题导致LocalDateTime解析失败
在Linux服务器上，MySQL的serverTimezone默认为SYSTEM，而JVM时区为Asia/Shanghai，导致LocalDateTime字段存入数据库时偏移8小时。解决方案是在application.yml中强制统一：

spring: datasource: url: jdbc:mysql://localhost:3306/shop?serverTimezone=UTC&useUnicode=true&characterEncoding=utf8

同时在MySQL配置文件my.cnf中添加：

[mysqld] default-time-zone='+00:00'

技巧3：IntelliJ IDEA社区版快速定位FunctionCallback注册点
在IDEA中按Ctrl+Shift+N，搜索FunctionCallbackRegistry，打开其register()方法，在第1行打断点。运行应用后，断点会停在所有@Bean FunctionCallback的注册位置，直观看到哪些工具被加载、哪些被跳过。

技巧4：用ChatResponseInterceptor实现调用链追踪
在拦截器中添加唯一traceId：

@Override public void intercept(ChatResponse response) { String traceId = MDC.get("traceId"); if (traceId == null) { traceId = UUID.randomUUID().toString(); MDC.put("traceId", traceId); } log.info("TraceID: {} | Tool Calls: {}", traceId, response.getResults().get(0).getDelta().getToolCalls()); }

这样在ELK中可以关联一次用户请求的所有日志，快速定位是LLM问题还是工具实现问题。

5.3 Java面试高频题实战解析

Q：Spring AI Function Calling如何保证事务一致性？
A：核心是两点：第一，FunctionCallback.handle()必须在@Transactional方法内执行，且该方法由Spring代理管理；第二，所有数据库操作必须在handle()方法体内完成，不能异步委托。我们曾用@Async尝试优化，结果发现事务上下文丢失，导致MySQL操作不回滚。正确做法是用TaskExecutor同步执行，如前文3.3节所示。

Q：对比Dify工作流转成Spring AI Java代码，优势在哪？
A：Dify是低代码平台，适合快速原型，但生产环境有三大硬伤：第一，工具调用日志分散在Dify后台，无法与Spring Boot的TransactionSynchronizationManager集成；第二，Dify的错误处理是全局的，无法为getOrderStatus和cancelOrder定义差异化降级策略；第三，Dify生成的Java代码缺乏pattern和enumValues等Schema约束，导致LLM参数生成错误率高。Spring AI的优势在于深度融入Spring生态，能复用@Transactional、CircuitBreaker、HikariCP等成熟组件。

Q：MySQL安装教程里常说的rpm安装mysql和docker安装mysql，哪个更适合Function Calling场景？
A：Docker。理由有三：第一，`docker run -e MYSQL_ROOT_PASSWORD=xxx -p 3306:3306