绝代小李最近把一个电商客服+导购智能体从零到一搭完上线了。这个项目的核心不是做一个聊天机器人，而是把售前导购、售中订单管理、售后处理揉进同一个 Agent 工作流里，让用户能在一段自然对话里完成从了解商品、比较参数、下单咨询到查询售后的完整闭环。标题里“客服+导购”这两个词看着简单，实际落地时牵扯到意图识别、多轮状态管理、知识库检索、订单 API 对接、人工转接这些链路，属于典型的企业级智能体开发场景。
这篇文章会从整体架构、技术选型、核心功能实现到排查实录完整过一遍。里面有我的设计取舍，也有上线后踩过的坑。如果你正在做智能体开发，或者想用 Dify、Coze 这类平台搭业务机器人，建议重点看第 3、4 部分，可以直接抄作业的地方我都标出来了。
1. 项目定位与整体架构设计
1.1 客服和导购为什么要合并成一个智能体
最初业务方提的需求是“做个客服机器人”，把常见问答和售后流程接进去就行。但真看到用户进线记录后我发现，大量咨询发生在下单之前。用户会问“给家里老人买手机，预算 2000，屏幕大一点，续航好，有推荐吗”，或者“这件卫衣我 175cm、75kg 应该买什么码”。这些问题如果只靠一个被动回答的客服机器人，大概率会变成“亲，您可以参考商品详情页呢”这种没有任何帮助的回复。
把导购能力塞进来的价值在于，用户不需要自己先去搜一堆商品再回来问客服。智能体可以在同一轮对话里完成需求采集、商品筛选、参数解释和下单引导。对商家来说，这也不只是省人工，而是把“高意向但还没下单”的用户拦在咨询环节里尽量转化掉。
我当时的判断是：不要做两个独立的机器人，而是做成一个 Agent，让它同时具备客服和导购能力。原因很简单，用户在对话过程中不会提前告诉你“我现在是来购物还是来咨询”，上一句在问商品材质，下一句可能就问发货时间。如果分成两个系统，上下文切换会非常生硬，体验会差很多。
1.2 整体架构：主从 Agent 模式
架构上我选了主从模式：一个主 Agent 负责理解用户意图、维护对话状态、决定调用哪个子能力；售前导购、售中订单、售后处理分别做成可被调用的子 Agent 或者工具。
很多刚接触智能体开发的人会纠结到底该用单 Agent 还是多 Agent。我的经验是：如果业务工具少于 5 个，单 Agent 就够；一旦涉及多个业务系统（商品库、订单库、售后系统、优惠券系统），并且每个系统都有复杂的参数，就必须拆成子 Agent 或独立工具。不然 system prompt 会写成一个几百行的庞然大物，模型很容易犯糊涂，今天调用错工具，明天漏参数。
从实现上看，主从模式本质上就是把子 Agent 当作一种特殊的 tool 来调用。主 Agent 先判断“这个用户需要查询订单”，然后通过 tool call 触发订单子 Agent，子 Agent 返回结构化结果，主 Agent 再组织成自然语言回复。这样做的好处是每个子 Agent 的 prompt 可以保持精简，上下文窗口也不会被无关系统撑爆。
1.3 功能模块拆解
我把整个智能