问题场景；，人工智能如何应对混合需求？
单一 vs 多样化需求
在上一章节中。我们展示了以下简洁流程:
text
使用者询问天气 ➜ 判断需否触发 API ➜ 调用 getWear ➜ 返回结果
这是一种“一刀切”的单体方案，只需要判断是否需要外部数据即可。只是在实际电商网站中，一句简短的话往往蕴含数条请求:
-
检查历史购买 – 找到账单或产品记录
-
追踪快递状态 – 查询配送进度
-
主动催促发货 – 若延迟则启动内部流程
例如的观点是。text
至于使用者说，「我上周买那款手机怎么还没收到？」
此时 AI 必须自行解析优先级，并按正确顺序执行多步操作才能给出完整答复。怎么说呢，
战前准备 – 三大主要 Tool 集合
1️⃣ BussinesTools
下面是我们定义的一组 Java Tool。每个 Tool 对应一种常见业务动作:
java
package com.yunxi.ai.tools;老实说，import org.springframework.ai.tool.annotation.Tool;其实，import org.springframework.ai.tool.annotation.ToolParam;import org.springframework.stereotype.Component;import java.util.List;import java.util.Map;import java.util.stream.Collectors;@Component
public class BussinesTools {
@Tool(description =
"根据关键词 查询所有相关记录")
public String queryOrders(
@ToolParam(description =
"关键词，如『手机』、『ORD001』") String keyword){
return queryOrdersMock;}
@Tool(description =
"通过 OrderID 获取详细信息")
public String getOrderById(
@ToolParam(description =
"OrderID 格式如 ORD123")String orderId){
return getOrderByIdMock;}
// ---------- 库存 ----------
@Tool
public String checkStock(
@ToolParam(
description ="产品名，如『iPhone』")String productName){
return checkStockMock;}
// ---------- 物流 ----------
@Tool
public String queryTracking(
@ToolParam(
description ="OrderID 如 ORD123")String orderId){
return queryTrackingMock;}
/* ，mock 数据与实现略 …*/
}
### 2️⃣ BusinessService
该层把 ChatClient 与 Tool 集成，使得前端仅需发送一句话即可触发完整流程:
java
package com.yunxi.ai.service;import com.yunxi.ai.tools.BussinesTools;import lombok.extern.slf4j.Slf4j;import org.springframework.ai.chat.client.ChatClient;怎么说呢，import org.springframework.stereotype.Service;按理说，@Slf4j
@Service
public class BusinessService {
private final ChatClient chatClient;private final BussinesTools tools;public BusinessService(ChatClient.Builder builder,BussinesTools tools){
this.chatClient=builder.build;其实，this.tools=tools;其实，}
public String businessChat{
return chatClient.prompt
.system
.user
.tools
.call
.content;
}
}
## 实战演示 – 多 Tool 协同工作
### 场景 A – 单一意图
| 使用者 | 调用链 | 回复 |
|------|--------|------|
| 「帮我查 AirPods Pro 是否有现货」 | `` | 商品「AirPods Pro」当前缺貨，預計下週補貨。不过，請考慮其他型號或設定到貨通知。|
从*关键点*来看，单一任务，只触发一次对应 Tool，无冗余操作。### 场景 B – 模糊搜索 + 精准定位
| 步骤 | 调用 | 返回 |
|------|------|------|
| 步骤① | `` | 未找到包含「耳机」之訂單 |
| 步骤② | `` | 找到了 ORDER ID 为 ORD002 的 AirPods Pro |
| 步骤③ | `` | 暂无运輸資訊 |
说到回复示例。「您购买的 AirPods Pro目前尚未发貨，请确认后我们将协助催單。」
### 场景 C – 多意图组合请求
#### 使用者请求
「帮我检查 iPhone 是否有貨，还有我的訂單现在在哪？」
#### 自动拆解与执行
| 序号 | 工具 | 参数 |
|-|-|-|
|①| `checkStock` | 当前庫存128件 |
|②| `queryOrders` | 找到了 ORDER ID ORD001 |
|③| `queryTracking` | 到達北京朝阳分拨中心 |
从最终回复来看，「好消息！iPhone 当前有貨，您的 ORDER ORD001 已经抵达北京朝阳分拨中心，将于今日派送。」
---
### 场景 D – 闲聊无需外部接口
若输入仅为问候或非操作性语句：
* **输入**：「你好呀！话说回来，」
* **输出**：「您好！我是您的智能客服助手，可帮助您查询订購、庫存與運輸狀態。请告訴我想了解哪些内容，」
此类情况下模型直接生成自然语言答案，无需触發任何 Tool。## 常见陷阱与常用方法
### 坑一 — 无限循环重试
#### 症状
当请求的数据不存在时为寻找更好答案模型会反复尝试同一 Tool：
查找 ORDER ORD999 的物流状态
-> “ORDER 不存在”
-> “未找到訂單”
... 循环不停 …#### 防御策略
* **设置最大呼叫次数**，超过限制即停止进一步重试。至于配置示例，yaml
再看spring，ai:
openai这方面。chat:
options:
max-tool-calls: 5 # 最多五次尝试后终止
### 坑二 — 幻觉产生不存在的 Tool
#### 症状
模型误以为程序拥有某些接口，例如尝试 `sendSms` 而实际缺失。话说回来，#### 防御策略
在 System Prompt 中明确限定可使用之 Tool。仅允许已注册之方法：
.system
### 坑三 — 参数匹配失误
#### 症状
输入词汇与数据库字段不完全一致导致错误响应。#### 防御策略
1️⃣ 在每个 `<@ToolParam>` 注释中提供更细致说明并列举典型实例；2️⃣ 后端 Service 内实现模糊搜索逻辑；3️⃣ 在较复杂情境下让模型先使用通用搜索 再以精准值 完成验证。## 小结 — 从单工艺到并行协作
| 功能点 | 单工艺版
| 并行/串行版
|
| # 主要思路 # 简洁描述 vs 自动推理生成 # 完整交互封装 # 可视化报告等 ... 示例省略 ... |
-
# 客户痛点回归 # 继续关注交付时间和准确率，以提高满意度。
-
# 技术维护成本 # 将每个 Tool 写成标准化模块。即使换模型也能保持一致接口，从而降低维护成本。
END
。
