跨品类编排：对比、搭配与售后一起跑
作者：程序员马丁
Ragent AI —— 从 0 到 1 纯手工打造企业级 Agentic RAG，拒绝 Demo 玩具！AI 时代，助你拿个offer。
上一篇实现了 TinyAgent 的技能系统——activate_skill 加载 SKILL.md 指令到主上下文，技能专属工具动态注入，LLM 在指令引导下按步骤执行。结尾留了一个悬念：之前的例子一直在处理单品类的需求，退一台扫地机、查一个订单。如果用户的一句话横跨多个品类，涉及对比、搭配、售后多种任务类型，TinyAgent 现有的能力能接得住吗？
这一篇就来回答这个问题。用跨品类场景来验证 Tool、Skill 和 Plan-and-Execute 的组合编排能力——对比 + 搭配 + 售后一起跑。
本项目中具体代码已上传 GitHub TinyAgent，大家 Clone 项目后，将代码分支切换到 1.12.x，默认主分支是最新代码。运行前复制
.env.example为.env，把自己的 API Key 填进去，默认阿里云百炼平台；.env已加入.gitignore，切分支时不会丢。
单品类够了，跨品类才是真考验
1. 比特严选的跨品类特性
回顾一下比特严选的品类结构：手机、平板电脑、笔记本、智能穿戴（手表、手环、耳机）、智能家居（扫地机、智能音箱、摄像头等）、影音配件——6 大品类，300-500 个 SKU。
之前的 Demo 都在同一个品类内打转：退扫地机走退款技能，查订单走查询技能，推荐扫地机搜知识库。但比特严选的核心竞争力不在单品类——而在跨品类的 IoT 生态体验。用户的真实需求经常是这样的：
比特 AirX 耳机和 BandPro 耳机哪个好？我主要通勤用。另外我手机是比特 Phone S1，想配一套运动装备，预算 1000 以内。顺便帮我查一下订单 88231 到了没。
一句话包含了三个子任务：
- 商品对比：耳机品类内的规格对比（AirX vs BandPro）
- IoT 搭配推荐：基于已有手机，跨品类推荐智能穿戴设备组合
- 订单查询：查一个订单的物流状态
三个子任务涉及智能穿戴、手机、售后三个领域，调用的工具也不一样——对比要用 compareProducts，搭配推荐要用 recommendBundle，查订单要用 queryOrder。更关键的是，这三个子任务之间没有依赖关系，可以按任意顺序执行。
2. 现有能力够不够
TinyAgent 目前有三种执行能力：ReAct（单步推理）、Skill（指令驱动执行）、Plan-and-Execute（动态规划）。面对上面这个跨品类需求，每种能力各有擅长和短板：
| 能力 | 能不能做 | 怎么做 | 问题在哪 |
|---|---|---|---|
| ReAct | 能 | 一步一步推理，先对比、再推荐、再查订单 | 三个独立任务混在一条推理链里，容易遗漏后面的子任务 |
| ReAct + Skill | 能 | 激活对比技能完成对比，再激活搭配技能完成推荐，最后查订单 | 连续激活多个技能会导致指令堆叠，上下文膨胀 |
| Plan-and-Execute | 能 | Planner 一次性拆解三个子任务，Executor 逐步执行 | 最稳，总 LLM 调用反而更少（后文有详细对比） |
用一句话概括：单子任务用 ReAct + Skill 足够；跨品类复合任务用 Plan-and-Execute 更可靠。
这不是理论推导——下面用代码和实际执行轨迹来验证。但在跑 Demo 之前，先要给 TinyAgent 补两个跨品类才需要的工具。
新增两个跨品类工具
之前 TinyAgent 只有 5 个基础工具：queryOrder、queryLogistics、applyRefund、searchKnowledge、getCurrentTime。这些工具覆盖了订单和售后场景，但做不了商品规格对比和 IoT 搭配推荐。现在要补两个：
1. CompareProductsTool：商品规格对比
用户问比特 AirX 耳机和 BandPro 耳机哪个好时，Agent 需要拿到两个商品的详细规格参数才能做对比分析。searchKnowledge 返回的是粗粒度的产品简介 ，不够对比用——对比需要精确到续航时间、重量、降噪方式这些具体参数。
public class CompareProductsTool implements Tool {
private static final Map<String, String> PRODUCTS = new LinkedHashMap<>();
static {
PRODUCTS.put("比特 AirX 真无线耳机",
"{\"name\":\"比特 AirX 真无线耳机\",\"category\":\"智能穿戴\","
+ "\"price\":399,\"type\":\"真无线入耳式\","
+ "\"noiseCancelling\":\"主动降噪 ANC\","
+ "\"battery\":\"单次 8 小时，总续航 30 小时\","
+ "\"weight\":\"5.2g（单耳）\",\"waterproof\":\"IPX4\","
+ "\"features\":\"蓝牙 5.3，通话降噪，触控操作，支持快充\"}");
PRODUCTS.put("比特 BandPro 头戴式耳机",
"{\"name\":\"比特 BandPro 头戴式耳机\",\"category\":\"智能穿戴\","
+ "\"price\":699,\"type\":\"头戴式包耳\","
+ "\"noiseCancelling\":\"混合主动降噪 + 通透模式\","
+ "\"battery\":\"40 小时\","
+ "\"weight\":\"258g\",\"waterproof\":\"无\","
+ "\"features\":\"Hi-Res 认证，可折叠，3.5mm 有线模式，多设备连接\"}");
PRODUCTS.put("比特 Phone S1 手机",
"{\"name\":\"比特 Phone S1 手机\",\"category\":\"手机\","
+ "\"price\":1999,\"screenSize\":\"6.7 英寸 AMOLED\","
+ "\"processor\":\"骁龙 7 Gen3\","
+ "\"ram\":\"12GB\",\"storage\":\"256GB\","
+ "\"battery\":\"5000mAh\","
+ "\"features\":\"120Hz 刷新率，NFC，红外遥控\"}");
PRODUCTS.put("比特 WatchFit 智能手表",
"{\"name\":\"比特 WatchFit 智能手表\",\"category\":\"智能穿戴\","
+ "\"price\":599,\"screenSize\":\"1.82 英寸 AMOLED\","
+ "\"battery\":\"典型使用 14 天\",\"waterproof\":\"5ATM\","
+ "\"features\":\"心率血氧监测，100+ 运动模式，"
+ "NFC 公交支付，消息通知\"}");
// ...... 更多商品
}
@Override
public String name() { return "compareProducts"; }
@Override
public String description() {
return "对比两个比特严选商品的规格参数，"
+ "返回两者的详细规格信息供对比分析。";
}
@Override
public String parameters() {
return """
{
"type": "object",
"properties": {
"productA": {
"type": "string",
"description": "第一个商品名称，如 比特 AirX 真无线耳机"
},
"productB": {
"type": "string",
"description": "第二个商品名称，如 比特 BandPro 头戴式耳机"
}
},
"required": ["productA", "productB"]
}""";
}
@Override
public String invoke(String input) {
String nameA = ToolUtils.extractRequiredField(input, "productA");
if (nameA.isBlank()) {
return ToolUtils.missingRequiredField("productA");
}
String nameB = ToolUtils.extractRequiredField(input, "productB");
if (nameB.isBlank()) {
return ToolUtils.missingRequiredField("productB");
}
String specA = fuzzyMatch(nameA);
String specB = fuzzyMatch(nameB);
if (specA == null && specB == null) {
return "{\"error\":" + ToolUtils.toJsonString(
"未找到商品：" + nameA + " 和 " + nameB) + "}";
}
if (specA == null) {
return "{\"error\":" + ToolUtils.toJsonString(
"未找到商品：" + nameA) + ",\"productB\":" + specB + "}";
}
if (specB == null) {
return "{\"error\":" + ToolUtils.toJsonString(
"未找到商品：" + nameB) + ",\"productA\":" + specA + "}";
}
return "{\"productA\":" + specA + ",\"productB\":" + specB + "}";
}
// fuzzyMatch：模糊匹配商品名，兼容用户简写
// ......
}
PRODUCTS 是一个静态 Map，存放比特严选商品的规格 Mock 数据——实际项目中这部分应该对接商品数据库。关键设计点：
入参是两个商品名，返回两者的完整规格 JSON。Agent 拿到结构化的规格数据后，自己做对比分析和推荐——对比逻辑由 LLM 完成，工具只负责提供数据。这种职责分离和 RAG 系列里的检索增强生成是同一个思路：工具提供事实，LLM 做推理。
模糊匹配兼容简写。用户说 AirX 耳机而不是比特 AirX 真无线耳机，fuzzyMatch 方法用关键词拆分匹配来处理。
2. RecommendBundleTool：IoT 搭配推荐
用户说想给手机配一套运动装备时，Agent 需要知道有哪些搭配组合可选、每个组合包含什么、组合价多少。这个工具根据基础商品推荐跨品类搭配方案：
public class RecommendBundleTool implements Tool {
@Override
public String name() { return "recommendBundle"; }
@Override
public String description() {
return "根据用户已有或感兴趣的商品，推荐 IoT 生态搭配组合"
+ "（手机 + 手表 + 音箱等跨品类组合），"
+ "返回搭配方案和组合价。";
}
@Override
public String parameters() {
return """
{
"type": "object",
"properties": {
"baseProduct": {
"type": "string",
"description": "用户已有或感兴趣的基础商品名称"
},
"budget": {
"type": "number",
"description": "搭配总预算（元），可选"
},
"preferences": {
"type": "string",
"description": "用户偏好描述，如 运动健康监测、全屋智能控制"
}
},
"required": ["baseProduct"]
}""";
}
@Override
public String invoke(String input) {
String baseProduct =
ToolUtils.extractRequiredField(input, "baseProduct");
if (baseProduct.isBlank()) {
return ToolUtils.missingRequiredField("baseProduct");
}
// 根据基础商品匹配搭配方案
if (baseProduct.contains("Phone") || baseProduct.contains("手机")) {
return "{\"baseProduct\":\"比特 Phone S1 手机\","
+ "\"bundles\":["
+ "{\"name\":\"运动健康套装\","
+ "\"items\":[\"比特 Phone S1 手机（¥1999）\","
+ "\"比特 WatchFit 智能手表（¥599）\","
+ "\"比特 AirX 真无线耳机（¥399）\"],"
+ "\"totalPrice\":2997,\"bundlePrice\":2799,"
+ "\"saving\":198,"
+ "\"scenario\":\"手机接收手表的运动和健康数据，"
+ "耳机连接手机听歌跑步\"},"
+ "{\"name\":\"全屋智能套装\","
+ "\"items\":[\"比特 Phone S1 手机（¥1999）\","
+ "\"比特 SoundBox Mini 智能音箱（¥299）\","
+ "\"比特 WatchFit 智能手表（¥599）\"],"
+ "\"totalPrice\":2897,\"bundlePrice\":2699,"
+ "\"saving\":198,"
+ "\"scenario\":\"手机作为智能家居控制中心，"
+ "音箱做语音控制入口，手表随身提醒\"}"
+ "]}";
}
// ...... 其他商品的搭配方案
}
}
返回的 JSON 里每个搭配方案包含四个关键信息：包含商品（items）、原价（totalPrice）、组合价（bundlePrice）、适用场景（scenario）。这些结构化数据给了 LLM 足够的素材来做推荐——LLM 可以根据用户的预算和偏好从多个方案中筛选。
注意一个细节：
bundlePrice包含了基础商品（如手机）的价格，但用户可能已经拥有基础商品，不需要重复购买。LLM 需要结合对话上下文判断哪些商品用户已有，再做预算计算——这也是工具只提供数据、推理交给 LLM 的好处。
3. 工具全景
加上新增的两个工具，TinyAgent 现在有 7 个基础工具：
| 工具名 | 品类覆盖 | 职责 |
|---|---|---|
queryOrder | 订单/售后 | 查订单详情 |
queryLogistics | 订单/售后 | 查物流轨迹 |
applyRefund | 订单/售后 | 申请退款 |
searchKnowledge | 全品类 | 检索知识库（产品信息、政策） |
getCurrentTime | 通用 | 获取当前时间 |
compareProducts | 跨品类 | 对比两个商品的规格参数 |
recommendBundle | 跨品类 | 推荐 IoT 搭配组合 |
前 5 个是之前就有的，后 2 个是本篇新增的。searchKnowledge 是粗粒度的知识检索（返回产品简介和政策文档），compareProducts 是细粒度的规格对比（返回详细参数 JSON），两者不冲突——知识检索用于回答用户扫地机推荐这类开放问题，规格对比用于 A vs B 这类明确的对比需求。
新增两个跨品类技能
有了工具，还要给它们配上技能——这样 ReAct + Skill 模式下，LLM 可以按预定义的流程执行对比和搭配推荐，而不是自己临时决定步骤。
1. product-comparison：商品对比技能
<!-- resources/skills/product-comparison.md -->
---
name: product-comparison
description: >
商品对比技能：查询两个商品的详细规格参数并进行对比分析，
给出结构化的对比结论和购买建议。适用于用户要求对比两个商品、
不知道选哪个的场景。
tools:
- compareProducts
---
# 商品对比
## 概述
你是比特严选的选购顾问。当用户要求对比两个商品时，按照以下流程处理。
## 处理步骤
### Step 1: 对比商品规格
使用 compareProducts 查询两个商品的详细规格参数。
### Step 2: 给出对比结论
根据返回的规格数据，从以下维度进行对比分析：
- 价格差异
- 核心功能差异（针对品类特点选择关键维度）
- 各自适合的使用场景
## 输出要求
给出清晰的对比表格或分点说明，最后根据用户提到的需求偏好
给出购买建议。如果用户没有明确偏好，列出两者各自的优势场景
让用户自行选择。
这个技能只声明了一个专属工具 compareProducts——对比场景只需要这一个。技能指令要求 LLM 从价格、核心功能、使用场景三个维度做对比分析，这比让 LLM 自由发挥更有结构感，输出质量也更稳定。
2. iot-bundle：IoT 搭配推荐技能
<!-- resources/skills/iot-bundle.md -->
---
name: iot-bundle
description: >
IoT 搭配推荐技能：根据用户已有或感兴趣的商品，推荐跨品类 IoT 生态
搭配组合，包含组合价和使用场景说明。适用于用户提到搭配、套装、组合、
生态等需求的场景。
tools:
- recommendBundle
---
# IoT 搭配推荐
## 概述
你是比特严选的 IoT 生态顾问。当用户想了解商品搭配方案时，
按照以下流程处理。
## 处理步骤
### Step 1: 获取搭配方案
使用 recommendBundle 查询基于用户已有或感兴趣商品的搭配组合方案。
如果用户提到了预算，传入 budget 参数。
如果用户提到了使用偏好（如运动健康、全屋智能），传入 preferences 参数。
### Step 2: 给出搭配建议
根据返回的搭配方案，说明每个组合包含哪些商品、组合价省多少、
适合什么场景。
## 输出要求
列出推荐的搭配方案，每个 方案说清楚包含商品、原价、组合价、省多少钱、
适合什么场景。如果有多个方案，根据用户偏好排序推荐。
3. 技能全景
加上新增的两个，TinyAgent 现在有 4 个技能：
| 技能名 | 专属工具 | 适用场景 |
|---|---|---|
process-refund | queryOrder、applyRefund | 退款处理 |
order-inquiry | queryOrder、queryLogistics | 订单全流程查询 |
product-comparison | compareProducts | 商品对比 |
iot-bundle | recommendBundle | IoT 搭配推荐 |
4 个技能覆盖了比特严选客服的四大高频场景。注意 queryOrder 同时出现在 process-refund 和 order-inquiry 两个技能里——上一篇讲过，DynamicToolProvider 注入时会去重，不会在 LLM 可见列表里出现两次。
现在 LLM 初始可见的工具列表变成了 3 个：searchKnowledge、getCurrentTime、activate_skill——通用工具不变，activate_skill 的 description 里多了两个技能的说明。7 个基础工具中，除 searchKnowledge 和 getCurrentTime 外的 5 个都被至少一个技能声明为专属工具，激活前不可见。
下面这张图把工具和技能的可见性机制画清楚了——左边是 LLM 一开始就能看到的 3 个工具，右边是被 4 个技能封装起来的 5 个专属工具，中间的 activate_skill 是唯一的桥梁：
场景一：ReAct + Skill 跑单任务
先用最简单的方式验证新工具和新技能是否工作——ReAct + Skill 模式处理单个跨品类任务。
1. 耳机对比
// CrossCategoryDemo.java（简化）
ToolRegistry toolRegistry = new ToolRegistry();
toolRegistry.register(new QueryOrderTool());
toolRegistry.register(new QueryLogisticsTool());
toolRegistry.register(new ApplyRefundTool());
toolRegistry.register(new SearchKnowledgeTool());
toolRegistry.register(new GetCurrentTimeTool());
toolRegistry.register(new CompareProductsTool()); // 新增
toolRegistry.register(new RecommendBundleTool()); // 新增
SkillRegistry skillRegistry = new SkillRegistry();
skillRegistry.loadFromDirectory(Path.of("src/main/resources/skills"));
ToolRegistry agentTools = skillRegistry.buildAgentRegistry(toolRegistry);
ReActAgent reactAgent = new ReActAgent(llmClient, agentTools, 10, 8000);
// 耳机对比
String answer = reactAgent.run(
"比特 AirX 耳机和 BandPro 耳机哪个好？我主要通勤用");
预期执行轨迹：
[SkillRegistry] 加载技能：process-refund（process-refund.md）
[SkillRegistry] 加载技能：order-inquiry（order-inquiry.md）
[SkillRegistry] 加载技能：product-comparison（product-comparison.md）
[SkillRegistry] 加载技能：iot-bundle（iot-bundle.md）
[SkillRegistry] 技能专属工具（激活前不可见）：
[queryOrder, applyRefund, queryLogistics, compareProducts, recommendBundle]
========== 场景 1：耳机对比（ReAct + Skill） ==========
===== 第 1 圈 =====
[工具调用] activate_skill({"name":"product-comparison"})
[Skill] 激活技 能：product-comparison，解锁工具：[compareProducts]
[动态工具] 解锁 1 个技能专属工具：[compareProducts]
===== 第 2 圈 =====
[工具调用] compareProducts({"productA":"比特 AirX 真无线耳机",
"productB":"比特 BandPro 头戴式耳机"})
[工具结果] {"productA":{"name":"比特 AirX 真无线耳机","price":399,
"type":"真无线入耳式","battery":"单次 8 小时，总续航 30 小时",
"weight":"5.2g（单耳）","waterproof":"IPX4",...},
"productB":{"name":"比特 BandPro 头戴式耳机","price":699,
"type":"头戴式包耳","battery":"40 小时","weight":"258g",...}}
===== 第 3 圈 =====
[最终答复] 两款耳机各有优势，以下是对比分析：
| 维度 | AirX 真无线 | BandPro 头戴式 |
|------|-----------|-------------|
| 价格 | ¥399 | ¥699 |
| 佩戴方式 | 入耳式，轻便 | 包耳式，舒适但较重 |
| 续航 | 总续航 30 小时 | 40 小时 |
| 降噪 | 主动降噪 ANC | 混合降噪 + 通透模式 |
| 防水 | IPX4 | 无 |
通勤推荐：AirX 真无线耳机。理由是轻便便携、IPX4 防水防汗、
价格更友好，通勤场景下入耳式比头戴式方便很多。
LLM 的行为完全符合预期：识别到对比需求 → 激活 product-comparison 技能 → 调 compareProducts 拿到规格数据 → 按技能指令的三个维度做对比分析 → 结合用户的通勤偏好给出推荐。整个过程 3 圈搞定。
2. IoT 搭配推荐
String answer = reactAgent.run(
"我刚买了比特 Phone S1，想配一些智能设备，主要想运动时用");
预期执行轨迹：
===== 第 1 圈 =====
[工具调用] activate_skill({"name":"iot-bundle"})
[Skill] 激活技能：iot-bundle，解锁工具：[recommendBundle]
[动态工具] 解锁 1 个技能专属工具：[recommendBundle]
===== 第 2 圈 =====
[工具调用] recommendBundle({"baseProduct":"比特 Phone S1 手机",
"preferences":"运动"})
[工具结果] {"baseProduct":"比特 Phone S1 手机","bundles":[
{"name":"运动健康套装",
"items":["比特 Phone S1 手机（¥1999）","比特 WatchFit 智能手表（¥599）",
"比特 AirX 真无线耳机（¥399）"],
"totalPrice":2997,"bundlePrice":2799,"saving":198,
"scenario":"手机接收手表的运动和健康数据，耳机连接手机听歌跑步"},
{"name":"全屋 智能套装",...}]}
===== 第 3 圈 =====
[最终答复] 配合您的比特 Phone S1，推荐运动健康套装：
- 比特 WatchFit 智能手表（¥599）：记录运动数据，心率血氧监测
- 比特 AirX 真无线耳机（¥399）：运动时听歌，IPX4 防汗
- 套装组合价 ¥2799（省 ¥198）
三件设备互联：手表记录运动数据同步到手机，耳机连接手机听歌跑步。
LLM 准确地识别了搭配需求，激活了 iot-bundle 技能，还把用户的运动偏好传入了 preferences 参数，最终从两个方案中筛选了更匹配的运动健康套装。
两个单任务场景都跑通了。ReAct + Skill 在单品类和单跨品类任务上表现稳定——激活一个技能，按指令走完流程，3 圈搞定。
场景二：Plan-and-Execute 跑复合任务
现在来真正的考验——一句话包含三个跨品类子任务。
1. 为什么不用 ReAct + Skill
先想一下 ReAct + Skill 处理这个复合任务会怎么走。用户说：
帮我对比一下比特 AirX 耳机和 BandPro 耳机，另外我买的比特 Phone S1 手机想配一套运动装备，预算 1000 以内，顺便帮我查一下订单 88231 到了没。
LLM 初始可见 4 个工具：searchKnowledge、getCurrentTime、activate_skill。它需要：
- 激活
product-comparison，调compareProducts，完成对比 - 激活
iot-bundle，调recommendBundle，完成搭配推荐 - 激活
order-inquiry，调queryOrder，完成订单查询
这意味着 LLM 要在一次 run() 里连续激活三个技能。上一篇的进阶思考部分提过：连续激活多个技能会导致指令堆叠。三个技能的 Markdown 指令加起来约 1500-2000 Token，全部进入主上下文后，LLM 可能搞混不同技能的步骤——对比技能要求使用 compareProducts，搭配技能要求使用 recommendBundle，LLM 面对两份同时生效的指令，选择正确工具的难度显著上升。
更麻烦的是，上一篇提到 dynamicToolMap 是 run() 的局部变量，每次 run() 调用独立。所以在同一次 run() 内，三个技能的专属工具会逐步叠加到可见列表——第一个技能解锁 compareProducts，第二个再解锁 recommendBundle，第三个再解锁 queryOrder 和 queryLogistics。这在技术上是可行的，但 LLM 看到一堆工具和一堆指令，决策质量容易下降。
ReAct + Skill 更适合一次一技能的场景。多技能协作，还是交给 Plan-and-Execute。
2. Plan-and-Execute 的优势
Plan-and-Execute 处理这个场景的方式完全不同——它不走技能路径，而是直接用基础工具：
// 场景 3：跨品类复合任务
PlanAndExecuteAgent planAgent =
new PlanAndExecuteAgent(llmClient, toolRegistry, 2);
String answer = planAgent.run(
"帮我对比一下比特 AirX 耳机和 BandPro 耳机，"
+ "另外我买的比特 Phone S1 手机想配一套运动装备，预算 1000 以内，"
+ "顺便帮我查一下订单 88231 到了没");
注意这里传入的是 toolRegistry（全量注册表，7 个基础工具全部可见），而不是 agentTools（经过技能过滤的注册表）。Plan-and-Execute 不需要技能——Planner 自己拆步骤，Executor 直接调基础工具。
这一点很重要。Skill 的价值是把高频、稳定的编排沉淀下来，避免每次都临时规划；但 Plan-and-Execute 的 Planner 本身就能根据工具列表生成合理的步骤编排。对于跨品类复合任务这种低频、非标的需求，Planner 临时规划反而比套用预定义技能更灵活。
下面这张时序图展示了 Plan-and-Execute 处理跨品类复合任务的完整流程——从用户输入到三个子任务分步执行，再到最终综合回复：
3. 完整执行轨迹
预期控制台输出（最终回复的措辞和排版因模型而异，以下为示意）：
========== 场景 3：跨品类复合任务（Plan-and-Execute） ==========
[Plan] 正在规划...
[Plan] 计划生成完成：
○ Step 1: 对比比特 AirX 耳机和 BandPro 耳机的规格参数 → compareProducts
○ Step 2: 根据比特 Phone S1 查询运动装备搭配推荐 → recommendBundle
○ Step 3: 查询订单 88231 的状态 → queryOrder
○ Step 4: 综合对比结论、搭配推荐和订单状态，给出最终回复 → null
[Execute] ▶ Step 1: 对比比特 AirX 耳机和 BandPro 耳机的规格参数
[工具调用] compareProducts({"productA":"比特 AirX 真无线耳机",
"productB":"比特 BandPro 头戴式耳机"})
[工具结果] {"productA":{...},"productB":{...}}
[Execute] ✓ Step 1 完成
[Execute] ▶ Step 2: 根据比特 Phone S1 查询运动装备搭配推荐
[工具调用] recommendBundle({"baseProduct":"比特 Phone S1 手机",
"budget":1000,"preferences":"运动"})
[工具结果] {"baseProduct":"比特 Phone S1 手机","bundles":[...]}
[Execute] ✓ Step 2 完成
[Execute] ▶ Step 3: 查询订单 88231 的状态
[工具调用] queryOrder({"orderId":"88231"})
[工具结果] {"orderId":"88231","product":"比特 S10 Pro 扫地机",
"status":"已签收",...}
[Execute] ✓ Step 3 完成
[Execute] ▶ Step 4: 综合对比结论、搭配推荐和订单状态，给出最终回复
[Execute] ✓ Step 4 完成
[Plan] 执行完成：
✓ Step 1: 对比耳机规格 → AirX 399 元入耳式 vs BandPro 699 元头戴式...
✓ Step 2: 搭配推荐 → 运动健康套装（手表 ¥599 + 耳机 ¥399）...
✓ Step 3: 查订单 → 88231 已签收...
✓ Step 4: 综合回复 → 已处理...
========== 最终结果 ==========
为您汇总三个问题的处理结果：
【耳机对比】AirX vs BandPro
| 维度 | AirX 真无线（¥399） | BandPro 头戴式（¥699） |
|------|-------------------|---------------------|
| 佩戴 | 入耳式，5.2g 超轻 | 包耳式，258g |
| 续航 | 总续航 30 小时 | 40 小时 |
| 降噪 | 主动降噪 | 混合降噪 + 通透模式 |
| 防水 | IPX4 | 无 |
| 音质 | 蓝牙 5.3 | Hi-Res 认证 |
两款定位不同：AirX 轻便防水，适合运动通勤；BandPro 音质更强，
适合长时间音乐欣赏。
【运动装备搭配】
考虑到您 1000 元以内的预算，推荐单独搭配比特 WatchFit 智能手表
（¥599）：心率血氧监测 + 100 种运动模式，与 Phone S1 数据互通。
如果预算放宽，还可以加一副 AirX 耳机（¥399），凑成运动健康套装
组合价 ¥2799（省 ¥198）。
【订单 88231】
您购买的比特 S10 Pro 扫地机已于 6 月 22 日签收。
如需其他帮助，随时联系！
整个过程 4 步搞定，三个子任务一个不漏。来看几个关键细节：
Planner 自动识别了三个独立子任务。规划阶段一次性拆出 4 步，每步对应一个独立目标。因为三个子任务没有依赖关系（对比结果不影响搭配推荐，搭配推荐不影响订单查询），Planner 可以按任意顺序编排。
Executor 直接调基础工具，不走技能。Step 1 直接调 compareProducts，不需要先 activate_skill 再调工具。Plan-and-Execute 模式下，Planner 已经把步骤和工具对应关系写清楚了，不需要技能指令来引导。
Step 2 的 budget 参数被正确传入。Executor 看到步骤描述里有预算 1000 以内的信息，结合 recommendBundle 的参数 Schema 里有 budget 字段，自动组装了 {"baseProduct":"比特 Phone S1 手机","budget":1000,"preferences":"运动"}。这是 Executor 的 LLM 理解能力在起作用——步骤描述和工具参数 Schema 共同约束了参数组装。
综合步骤把三个结果组织得有条理。Step 4 不是简单拼凑三个工具的 JSON 返回值，而是用 LLM 重新组织成面向用户的自然语言回复。
Plan-and-Execute vs ReAct + Skill：跨品类场景的执行对比
用同一个复合任务，对比两种方式的执行过程：
1. 执行轨迹对比
Plan-and-Execute（上面已展示）：
[规划] Step 1: 对比耳机 → compareProducts
Step 2: 搭配推荐 → recommendBundle
Step 3: 查订单 → queryOrder
Step 4: 综合回复 → null
[执行] 4 步，前 3 步各调 1 次工具，第 4 步纯文本综合，共 5 次 LLM 调用（含 1 次规划）
ReAct + Skill（假设 LLM 表现理想）：
第 1 圈: activate_skill("product-comparison")
第 2 圈: compareProducts(AirX, BandPro)
第 3 圈: activate_skill("iot-bundle")
第 4 圈: recommendBundle(Phone S1)
第 5 圈: activate_skill("order-inquiry")
第 6 圈: queryOrder(88231)
第 7 圈: 综合回复
7 圈 ReAct 循环，其中 3 圈是激活技能（不产生业务结果），4 圈是实际的工具调用和综合。
2. 关键指标对比
| 维度 | Plan-and-Execute | ReAct + Skill |
|---|---|---|
| LLM 调用次数 | 5 次（1 规划 + 4 执行） | 7 次（7 圈主循环） |
| 实际工具调用 | 3 次 | 3 次 + 3 次 activate_skill |
| 指令堆叠风险 | 无（每步独立上下文） | 高（三份技能指令叠加） |
| 遗漏子任务风险 | 低（计划覆盖全部子任务） | 中（走到第 5 圈可能遗忘第三个任务） |
| 上下文消耗 | 中等（步骤结果逐步累积） | 高（技能指令 + 所有 Observation 线性累积） |
| 可观测性 | 好（计划清单 + 步骤状态） | 一般（只能看工具调用日志） |
3. 什么时候该用哪种
这个对比不是要否定 ReAct + Skill——它们各有最佳场景：
确定性高 ◀━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶ 灵活性高
Skill Plan-and-Execute
（单技能场景最优） （多子任务场景最优）
退掉订单 88231 对比耳机 + 配运动装备
查订单和物流 + 查订单
对比 AirX 和 BandPro
单子任务用 ReAct + Skill。退款、查单、对比、搭配推荐——每个场景独立处理时，Skill 的指令引导能保证流程稳定，3 圈搞定。不需要规划的额外开销。
跨品类复合任务用 Plan-and-Execute。一句话包含多个独立子任务，且横跨不同品类、调用不同工具时，Planner 的全局视角能确保不遗漏、不混淆。
两者可以组合。AgentRouter 先判断任务复杂度：单技能匹配就走 ReAct + Skill，多目标复合就走 Plan-and-Execute。第 15 篇的 AgentRouter 已经实现了 ReAct 和 Plan-and-Execute 的路由，现在加上 Skill 维度，决策逻辑变为：
用户输入
↓
[AgentRouter]
├── 知识问答？ → 固定 RAG Workflow
├── 匹配单个技能？ → ReAct + Skill
├── 简单工具任务？ → ReAct
└── 多目标复合？ → Plan-and-Execute
跨品类编排的三种典型模式
通过上面的分析和实战，可以归纳出比特严选场景下跨品类编排的三种典型模式。上面的 Demo 已经完整展示了并行编排（三个独立子任务），下面补充串行和混合两种模式——它们用同一套 Plan-and-Execute 架构，区别仅在 Planner 对步骤顺序的安排。
先用一张图把三种模式的执行拓扑画出来，看完图再逐个展开：
1. 串行编排：步骤有依赖
有些跨品类任务的子步骤之间存在依赖关系——后一步必须依赖前一步的结果。
举个例子：用户说“帮我查一下订单 88231 的扫地机还在不在保修期内，如果过保了就推荐一台新的”。这句话的两个子任务有明确的先后依赖：
Step 1: queryOrder(88231) → 拿到签收时间
Step 2: getCurrentTime() → 拿到当前时间
Step 3: 判断是否过保（签收时间 + 保修期 vs 当前时间）
Step 4: 如果过保 → searchKnowledge("扫地机推荐")
Step 5: 综合回复
Step 3 依赖 Step 1 和 Step 2 的结果，Step 4 依赖 Step 3 的判断。这种模式只能串行执行——Planner 按依赖关系排好顺序，Executor 逐步执行。
2. 并行编排：步骤无依赖
前面的复合任务（对比 + 搭配 + 查订单）就是典型的并行场景——三个子任务之间没有数据依赖，理论上可以同时执行。
当前 TinyAgent 的 PlanAndExecuteAgent 是串行执行的——Step 1 完成后才执行 Step 2。在生产环境中，如果要优化响应时间，可以让 Planner 在计划中标注步骤之间的依赖关系，Executor 对无依赖的步骤并行执行：
[规划]
Step 1: 对比耳机 → compareProducts （无依赖）
Step 2: 搭配推荐 → recommendBundle （无依赖）
Step 3: 查订单 → queryOrder （无依赖）
Step 4: 综合回复 → null （依赖 1, 2, 3）
[执行]
Step 1 ──┐
Step 2 ──┼── 并行执行 ── Step 4（串行）
Step 3 ──┘
并行执行需要在
PlanStep中新增dependsOn字段标注依赖，Executor 用线程池同时提交无依赖的步骤。这不在本篇实现范围内，但数据结构上只需要给PlanStep加一个List<Integer> dependsOn字段，Planner 的提示词增加依赖标注要求。
3. 混合编排：部分串行 + 部分并行
现实中更常见的是混合模式。举个例子：
帮我对比 AirX 和 BandPro 耳机，选好后推荐一个搭配手机的方案，另外查一下订单 88231。
这里对比（Step 1）和查订单（Step 3）可以并行，但搭配推荐（Step 2）依赖对比结论——用户说“选好后推荐搭配”，意味着推荐的基础商品取决于对比结果：
[执行]
Step 1（对比耳机）──┬── Step 2（根据选定的耳机推荐搭配）── Step 4（综合）
Step 3（查订单） ──┘
对于 TinyAgent 当前的串行 Executor 来说，这三种模式在执行上没有区别——都是逐步执行。区别在于 Planner 对步骤顺序的编排：串行模式按依赖排序，并行模式可以按任意顺序（反正结果互不影响），混合模式需要把有依赖的步骤排在后面。
| 编排模式 | 特征 | 典型场景 | Planner 要求 |
|---|---|---|---|
| 串行 | 后一步依赖前一步结果 | 查订单 → 判断保修 → 推荐新品 | 按依赖排序 |
| 并行 | 子任务之间无依赖 | 对比 + 搭配 + 查订单 | 顺序无关 |
| 混合 | 部分有依赖，部分无依赖 | 对比 → 根据对比结果推荐搭配，同时查订单 | 有依赖的排后面 |
跨品类编排的工程注意事项
1. 工具描述是编排质量的基础
Planner 根据工具描述来决定每步该用什么工具。如果 compareProducts 的描述写得模糊（比如只写“商品工具”），Planner 可能把对比和搜索混为一谈，步骤编排就会出错。
好的工具描述要回答三个问题：做什么（WHAT）、输入什么（INPUT）、返回什么（OUTPUT）。
| 写法 | 问题 |
|---|---|
| 商品工具 | 太模糊，Planner 无法区分对比和搜索 |
| 对比两个商品的规格参数，返回两者的详细规格信息供对比分析 | 做什么 + 返回什么都清楚 |
searchKnowledge 和 compareProducts 的描述要明确区分各自的职责：前者是粗粒度的知识检索（产品简介、政策文档），后者是细粒度的规格对比（详细参数 JSON）。Planner 看到这两段描述，就能判断对比 AirX 和 BandPro 用 compareProducts，而退货政策是什么用 searchKnowledge。
2. Mock 数据的品类覆盖
本篇的 CompareProductsTool 和 RecommendBundleTool 都用 Mock 数据——PRODUCTS 静态 Map 和硬编码的搭配方案。这在 Demo 里足够，但有两个隐含假设需要在生产环境解决：
商品数据的实时性。静态 Map 里的价格和库存不会变，但真实场景中商品可能下架、调价、缺货。生产环境应该对接商品数据库或商品微服务 API。
搭配推荐的个性化。当前的搭配方案是固定的——手机对应两个套装。生产环境的推荐应该结合用户画像（上一篇讲的长期记忆）、购买历史、当前促销活动来动态生成。
3. 工具数量与 Planner 质量的关系
TinyAgent 从 5 个工具扩展到了 7 个。当前体量下 Planner 的表现很稳——7 个工具的描述加起来约 400 Token，Planner 能准确地把工具和步骤对应起来。
但如果工具数量继续增长到 15-20 个，Planner 的规划质量可能下降——工具描述占据的上下文空间增加，两个功能相近的工具容易被混淆。应对方式有两个：
一是用 ToolFilter 做预筛选。第 14 篇的 ToolFilter 根据用户问题的语义相关性筛选工具，只把相关工具传给 Planner。
二是合并功能相近的工具。比如如果有 comparePhones、compareTablets、compareEarphones 三个对比工具，不如合并成一个 compareProducts，内部根据商品品类路由——减少 Planner 的选择空间。
| 工具数量 | Planner 表现 | 建议 |
|---|---|---|
| 5-10 个 | 稳定 | 直接传全量工具列表 |
| 10-15 个 | 基本稳定，偶尔混淆 | 用 ToolFilter 预筛选 |
| 15 个以上 | 容易混淆相近工具 | 合并同类工具 + ToolFilter |
Demo：完整代码串联
把所有组件串起来，跑三个场景验证：
public class CrossCategoryDemo {
public static void main(String[] args) {
// 注册全部 7 个基础工具
ToolRegistry toolRegistry = new ToolRegistry();
toolRegistry.register(new QueryOrderTool());
toolRegistry.register(new QueryLogisticsTool());
toolRegistry.register(new ApplyRefundTool());
toolRegistry.register(new SearchKnowledgeTool());
toolRegistry.register(new GetCurrentTimeTool());
toolRegistry.register(new CompareProductsTool());
toolRegistry.register(new RecommendBundleTool());
Properties dotEnv = loadDotEnv();
LlmClient llmClient = new LlmClient(
setting(dotEnv, "TINYAGENT_API_URL",
"https://dashscope.aliyuncs.com/compatible-mode"
+ "/v1/chat/completions"),
requiredSetting(dotEnv, "TINYAGENT_API_KEY"),
setting(dotEnv, "TINYAGENT_MODEL", "qwen-plus")
);
// 加载全部 4 个技能
SkillRegistry skillRegistry = new SkillRegistry();
skillRegistry.loadFromDirectory(
Path.of("src/main/resources/skills"));
ToolRegistry agentTools =
skillRegistry.buildAgentRegistry(toolRegistry);
// 场景 1：ReAct + Skill —— 耳机对比
System.out.println(
"========== 场景 1：耳机对比 ==========");
ReActAgent reactAgent =
new ReActAgent(llmClient, agentTools, 10, 8000);
String answer1 = reactAgent.run(
"比特 AirX 耳机和 BandPro 耳机哪个好？"
+ "我主要通勤用");
System.out.println("\n[最终结果] " + answer1);
// 场景 2：ReAct + Skill —— IoT 搭配推荐
System.out.println(
"\n\n========== 场景 2：IoT 搭配推荐 ==========");
String answer2 = reactAgent.run(
"我刚买了比特 Phone S1，"
+ "想配一些智能设备，主要想运动时用");
System.out.println("\n[最终结果] " + answer2);
// 场景 3：Plan-and-Execute —— 跨品类复合任务
System.out.println(
"\n\n========== 场景 3：跨品类复合任务 ==========");
PlanAndExecuteAgent planAgent =
new PlanAndExecuteAgent(llmClient, toolRegistry, 2);
String answer3 = planAgent.run(
"帮我对比一下比特 AirX 耳机和 BandPro 耳机，"
+ "另外我买的比特 Phone S1 手机想配一套运动装备，"
+ "预算 1000 以内，"
+ "顺便帮我查一下订单 88231 到了没");
System.out.println("\n[最终结果] " + answer3);
}
// loadDotEnv()、requiredSetting()、setting() ......
}
三个场景分别验证了：
- 场景 1：ReAct + Skill 处理单品类对比（
product-comparison技能 +compareProducts工具） - 场景 2：ReAct + Skill 处理跨品类搭配推荐（
iot-bundle技能 +recommendBundle工具） - 场景 3：Plan-and-Execute 处理跨品类复合任务（Planner 拆步骤 + Executor 调多个基础工具）
注意场景 3 传入 toolRegistry 而不是 agentTools——Plan-and-Execute 直接用全量工具，不走技能路径。
文末总结
这一篇用跨品类场景验证了 TinyAgent 三种能力的组合编排：
- 新增两个跨品类工具：
CompareProductsTool返回两个商品的详细规格 JSON，供 LLM 做对比分析；RecommendBundleTool根据基础商品返回 IoT 搭配组合方案，包含组合价和场景说明。TinyAgent 的工具从 5 个扩展到 7 个，覆盖了订单售后、知识检索和跨品类对比搭配三大场景。 - 新增两个跨品类技能：
product-comparison引导 LLM 从价格、功能、场景三个维度做对比分析；iot-bundle引导 LLM 根据用户偏好筛选搭配方案。技能从 2 个扩展到 4 个。 - 单任务用 ReAct + Skill，复合任务用 Plan-and-Execute。单品类对比、单次搭配推荐——Skill 指令引导，3 圈搞定。跨品类复合任务（对比 + 搭配 + 售后）——Planner 一次性拆解全部子任务，Executor 逐步执行，不遗漏、不混淆。
- 三种编排模式：串行（步骤有依赖）、并行（步骤无依赖）、混合（部分有依赖）。当前 Executor 统一串行执行，生产环境可扩展为依赖标注 + 并行执行。
用一句话概括：跨品类编排不是新机制，而是 Tool、Skill、Plan-and-Execute 三种已有能力在多品类场景下的组合验证——单任务用 Skill 保稳定，复合任务用 Plan-and-Execute 保完整。
到这里，TinyAgent 的执行能力——从单步 ReAct 到预定义 Skill 再到动态 Plan-and-Execute——已经能覆盖比特严选绝大多数客服场景。但有一个问题一直悬着没解决：如果 Agent 在执行过程中翻车了——工具返回错误、LLM 理解偏差、步骤执行结果不符合预期——怎么办？第 15 篇的 Re-plan 只是在步骤失败时重 新规划，还没有让 Agent 自己反思哪里做错了、为什么做错、下次怎么避免。下一篇，咱们给 TinyAgent 装上 Reflection（反思）机制——让 Agent 不只是执行，还能自我纠错。