比特严选智能体：从蓝图开始设计

作者：程序员马丁

note

Ragent AI —— 从 0 到 1 纯手工打造企业级 Agentic RAG，拒绝 Demo 玩具！AI 时代，助你拿个offer。

上一篇咱们给 Agent 拍了张全景图：LLM 大脑、工具手脚、记忆、规划，四个要素在循环里协作运转。最后还拿扫地机退货串了一遍完整的交互流程，四要素怎么配合已经清楚了。

但那张图里的工具叫 queryOrder、searchKnowledge，都是随手起的名字。大脑的提示词长什么样、工具怎么注册、循环怎么停——这些全是留白。从这一篇开始，咱们要把留白一块一块填上。

不过别急着写代码。你有没有过这种经历：需求没想清楚就开干，写到一半发现方向跑偏了？Agent 的代码一旦跑起来，循环里套着工具调用，改起来比普通代码更痛苦。所以这一篇先不敲 Java，把比特严选智能体的蓝图画清楚——它要解决哪些任务、需要哪些工具、第一版做成什么样。蓝图画完，从下一篇开始真刀真枪写 ReAct 循环时，你才知道往哪使劲。

比特严选客服的一天

1. 先看真实的用户消息

第一篇已经介绍过比特严选的基本面——自营智能硬件电商，约 300 到 500 个 SKU，6 大品类（手机、平板电脑、笔记本、智能穿戴、智能家居、影音配件）。场景不再重复，但第一篇只看了一个扫地机退货的例子，还不够全面。

咱们换个角度，看看客服一天下来实际会收到哪些消息：

查东西：

帮我看看订单 88231 到哪了。上周买的耳机发了吗？运单号多少？

要操作：

上周买的扫地机不回充了，修不好我想退。收到的平板屏幕有划痕，要换货。

问推荐：

3000 块左右给老人买个手机，屏幕大、声音大的。客厅想搞一套智能家居——音箱、扫地机、摄像头，预算 2000 以内。

搞诊断：

我的比特手表连不上手机蓝牙了。智能音箱昨天开始说话有回声。

问政策：

你们以旧换新怎么算价？ 618 满减和学生优惠能叠加吗？

看到没有——用户的问题不只是查个资料答一句，而是经常涉及多步操作、需要跨系统查数据、还带着模糊的约束条件（“3000 块”“给老人”“预算 2000 以内”）。第一篇说 RAG 接不住这些问题，原因就在这里：它们需要 Agent 循环那个想-做-看的能力。

2. 八大任务拆解

把上面这些用户消息整理一下，比特严选智能体要解决的任务可以归纳成八大类：

编号	任务	典型用户消息	Agent 需要做什么
T1	查订单状态	订单 88231 什么状态了	调订单系统，返回商品、时间、当前状态
T2	查物流轨迹	快递到哪了	先从订单取运单号，再查物流接口
T3	退款/换货	扫地机坏了想退	查订单 → 判退货条件 → 发起售后
T4	商品规格对比	A15 和 A18 有什么区别	分别查两个商品规格，整理成对比表
T5	促销政策咨询	618 怎么参加	检索促销知识库，组织回答
T6	按需求推荐	3000 块给老人买手机	解析约束 → 筛选商品 → 排序推荐
T7	IoT 搭配推荐	客厅智能家居套装	跨品类组合 → 兼容性校验 → 预算匹配
T8	故障诊断	手表连不上蓝牙	多轮问答走诊断树，逐步排查

八个任务覆盖了比特严选客服 80% 以上的日常。但它们的复杂度差异很大——有的一步就搞定，有的要在循环里转好几圈。接下来咱们按复杂度分个级。

任务分级：一步到位的 vs 必须循环的

1. 四个复杂度等级

把八大任务按 Agent 循环需要转几圈来分级，画面就清晰了。

一星：单步查询

T1（查订单）和 T5（促销政策）最简单。大脑一想就知道该调什么工具，工具一调就拿到结果，直接回复用户。循环只转一圈：

用户提问 → 大脑：该查订单 → 工具：调订单系统 → 大脑：够了，回复用户

二星：串联查询

T2（查物流）和 T4（商品对比）要稍复杂一些。查物流得先查订单拿运单号，再用运单号查物流——两次工具调用有先后依赖。商品对比得分别查两个商品的规格，再整理成对比表。循环至少转两圈：

用户提问 → 大脑：先查订单拿运单号 → 工具：查订单 → 大脑：拿到运单号了，查物流 → 工具：查物流 → 大脑：够了，回复用户

三星：带判断的操作

T3（退款/换货）和 T6（按需推荐）不仅要查数据，还得根据数据做判断。退货得先查订单确认收货时间，判断在不在七天退货窗口内、是不是非人为损坏，然后才决定能不能退。推荐得先解析“3000 块”“老人用”“屏幕大”这些约束条件，从商品库筛选，还可能根据用户反馈调整结果。循环转几圈不确定，取决于中间的判断结果。

四星：多轮诊断 / 跨品类编排

T7（IoT 搭配推荐）和 T8（故障诊断）是最复杂的。IoT 搭配要跨手机、智能家居、影音配件等多个品类选品，还得在智能家居品类内部做设备兼容性校验（音箱和摄像头能不能联动、扫地机支不支持同一个 APP 控制），再核算总价。故障诊断更是典型的多轮——让用户检查蓝牙开关、重启手表、清除配对记录，每一步看结果再决定下一步问什么，循环可能要转五六圈甚至更多。

2. 复杂度一览

等级	任务	典型圈数	关键挑战
⭐	T1 查订单、T5 促销政策	1 圈	无，单次工具调用即可
⭐⭐	T2 查物流、T4 商品对比	2-3 圈	多次调用有先后依赖
⭐⭐⭐	T3 退款/换货、T6 按需推荐	2-5 圈	中间结果决定分支走向
⭐⭐⭐⭐	T7 IoT 搭配、T8 故障诊断	3-8+ 圈	跨品类编排或多轮用户交互

这张表有个重要的启示：一星任务一次工具调用就够了，严格来说用不着 Agent；但从二星开始，多步串联、条件分支、多轮交互——正是 Agent 循环的价值所在。

第一版做什么，不做什么

1. MVP（最小可行产品）范围

咱们的目标是手写 ReAct 循环，不是做一个完整的客服系统。所以第一版要遵循一个原则：选一组刚好能把循环核心能力跑通的任务，不多也不少。

第一版选这四个任务：

入选任务	等级	入选理由
T1 查订单状态	⭐	最简单的起点，验证单步循环能跑通
T2 查物流轨迹	⭐⭐	引入多步串联，验证循环能转多圈
T3 退款/换货	⭐⭐⭐	引入条件判断和有副作用的操作
T5 促销政策咨询	⭐	把 RAG 检索封装成工具，验证知识库能被 Agent 自主调用

这四个任务从一星覆盖到三星，恰好能演示 ReAct 循环的四个核心能力：

单步调用——大脑想一次，工具跑一次，直接给答案。
多步串联——上一步的输出是下一步的输入，循环要转多圈。
条件判断——根据中间结果走不同分支，大脑要会拐弯。
RAG 作为工具——把你在 RAG 系列写的检索链路封装成 Agent 的一个工具，大脑自己决定什么时候调。

2. 暂不做的部分

暂不做	推迟到哪里	原因
T4 商品对比	第四部分·多工具编排	依赖商品数据库的完整建模
T6 按需推荐	第四部分·多工具编排	需要商品筛选与排序的完整实现
T7 IoT 搭配	第五部分·多 Agent 协作	天然适合拆成商品 Agent + IoT 兼容性 Agent 协作
T8 故障诊断	第四部分·Plan-and-Execute	需要诊断树和多轮交互的精细设计

不是说这些任务不重要。恰恰相反，它们是后面几个部分的主角。但它们依赖的机制——多 Agent 调度、Plan-and-Execute、反思——要到后面的篇章才讲。先把 ReAct 循环的骨架立稳，再往上加肉。

第一版的工具清单

1. 五个工具

四个任务拆下来，第一版需要五个工具：

工具名	输入	输出	服务的任务
`queryOrder`	订单号	商品名、下单时间、状态、运单号	T1、T2、T3
`queryLogistics`	运单号	物流状态、最新位置、预计送达	T2
`applyRefund`	订单号、退款原因	申请结果（成功/失败及原因）	T3
`searchKnowledge`	问题文本	匹配的政策/FAQ 内容	T5
`getCurrentTime`	无	当前日期时间	T3（计算退货时限和保修期）

这里有两个工具值得多说一句。

第一个是 searchKnowledge——它就是你在 RAG 系列里写的那套检索链路，从 Embedding 到向量检索到重排序，一整套都在。只不过现在它被包了一层 Tool 接口，大脑自己决定要不要调、什么时候调。从 RAG 到 Agent 的那条线，就在这里接上了。

第二个是 getCurrentTime——看起来不起眼，但想想看：大脑判断能不能退货的时候得知道今天几号，才能算收货有没有超过七天。模型自己不知道当前日期（它的知识是训练时冻结的），所以必须给它一个工具来获取。这类看似平凡的工具，实际项目里经常被遗漏，然后你就会看到大脑在那编一个日期出来——典型的幻觉。

2. 工具接口的雏形

上一篇定义了 Tool 接口和 Action 记录类，咱们用那个接口来看看第一版的工具长什么样：

public class QueryOrderTool implements Tool {

    private final OrderService orderService; // 正式编码时通过构造器注入

    @Override
    public String name() { return "queryOrder"; }

    @Override
    public String invoke(String input) {
        // input: 订单号，如 "88231"
        // 调用订单系统 API，返回订单详情 JSON
        return orderService.queryByOrderId(input);
    }
}

public class SearchKnowledgeTool implements Tool {

    private final RagService ragService; // 正式编码时通过构造器注入

    @Override
    public String name() { return "searchKnowledge"; }

    @Override
    public String invoke(String input) {
        // input: 用户的问题文本
        // 走 RAG 检索链路：Embedding → 向量检索 → 重排序 → 返回匹配内容
        return ragService.search(input);
    }
}

其余三个工具结构完全一致，只是 name() 和 invoke() 的实现不同。这里先看个样子，正式编码放到第二部分。

3. 工具与任务的映射

把任务和工具的调用关系整理成一张图，后面写代码时可以直接对号入座：

任务	第 1 步	第 2 步	第 3 步
T1 查订单	`queryOrder`	—	—
T2 查物流	`queryOrder`（取运单号）	`queryLogistics`	—
T3 退款/换货	`queryOrder`（取订单信息）	`getCurrentTime`（算时限）	`applyRefund`（发起退款）
T5 促销政策	`searchKnowledge`	—	—

最值得注意的是 T3 那一行——退款/换货要调三个工具，而且中间有判断逻辑：如果 getCurrentTime 算出来超过了七天，第 3 步的 applyRefund 就不会被调用，大脑会走另一条分支告诉用户不符合退货条件。这正是三星任务的典型特征：工具调用之间不是简单的串联，而是带分支的。

用退款场景串一遍完整流程

光看表格还是有点抽象。咱们拿 T3（退款/换货）这个三星任务，完整走一遍 Agent 循环，看看大脑、工具、记忆是怎么配合的。

用户消息：「我上周买的扫地机不回充了，修不好我想退。订单号 88231。」

顺着这张图数一下，循环总共转了三圈：

第一圈：大脑想到先得知道是哪个订单，调了 queryOrder，拿回订单详情。
第二圈：有了订单信息后，大脑需要知道今天几号来算退货时限，调了 getCurrentTime。
第三圈：算出来 6 月 22 日签收到 6 月 29 日刚好七天，还在窗口内，大脑决定发起退款，调了 applyRefund。退款成功，大脑认为任务完成，给用户最终答复。

三圈里每一圈都是一次完整的想-做-看：大脑想出下一步该干嘛（Thought），工具执行并返回结果（Observation），结果被记忆收下、喂给大脑的下一轮思考。这就是上一篇架构全景图里那个循环的真实运作。

退货政策的边界：比特严选的七天无理由退货以签收次日起算，签收后第 7 个自然日 24:00 前均可申请。6 月 22 日签收，退货截止日就是 6 月 29 日，所以这笔订单刚好赶上末班车。

如果算出来超过了七天怎么办？大脑会走另一条分支——告诉用户不符合退货条件，但可以走保修维修流程。同样的三个工具，根据中间结果走不同的路，这就是条件判断的价值，也是为什么这个任务是三星而不是一星。

从蓝图到代码，还差什么

蓝图画到这里，任务、工具、流程都定好了。但要把这张蓝图变成能跑的代码，还有几个关键问题没回答：

问题	对应的篇章
ReAct 这个范式到底是什么，为什么管用？	第 04 篇·ReAct 到底是什么
循环的主体代码怎么写？	第 05 篇·手写 ReAct 循环
工具的入参出参怎么描述给大脑听？	第 06 篇·Tool 的定义与注册
提示词怎么设计，才能让大脑按格式输出？	第 07 篇·ReAct 提示词设计
怎么不再手动解析文本，让模型直接返回结构化调用？	第 08 篇·Function Calling
循环什么时候该停？	第 09 篇·终止条件与最大步数

这六个问题，就是整个第二部分《ReAct 核心》要逐篇解答的。每一篇解决一个问题，六篇写完，比特严选智能体的第一版就能跑起来了。

文末总结

这一篇没写一行能跑的代码，但画完了整张蓝图：

八大任务：查订单、查物流、退款/换货、商品对比、促销咨询、按需推荐、IoT 搭配、故障诊断——覆盖了比特严选客服的日常。
四个复杂度等级：从一星的单步查询到四星的多轮诊断，任务越复杂，Agent 循环的价值越大。
第一版 MVP：选了 T1、T2、T3、T5 四个任务，从一星到三星，恰好跑通 ReAct 循环的核心能力。
五个工具：queryOrder、queryLogistics、applyRefund、searchKnowledge、getCurrentTime，其中 searchKnowledge 直接复用 RAG 系列的检索链路。

一句话收尾：蓝图画好了——八大任务、四个复杂度等级，第一版选出四个任务、五个工具，后面写代码每一行都有据可循。

下一篇正式进入第二部分——ReAct 核心。我们先把 ReAct（Reasoning + Acting，推理 + 行动）这个范式的来龙去脉讲透：它从哪来、为什么管用、跟纯思维链有什么区别。概念理清楚了，紧接着就是全系列的重头戏——手写 ReAct 循环。

我们下一篇见。

比特严选客服的一天​

1. 先看真实的用户消息​

2. 八大任务拆解​

任务分级：一步到位的 vs 必须循环的​

1. 四个复杂度等级​

2. 复杂度一览​

第一版做什么，不做什么​

1. MVP（最小可行产品）范围​

2. 暂不做的部分​

第一版的工具清单​

1. 五个工具​

2. 工具接口的雏形​

3. 工具与任务的映射​

用退款场景串一遍完整流程​

从蓝图到代码，还差什么​

文末总结​

Table of Contents