客服机器人拆开看就三层：程序层管对话流程，接口层管和业务系统打交道，知识库层管答案从哪来。市面产品再花哨，架构都绕不开这三层。这篇按三层拆自建思路，末尾给“自建还是买”的判断，写给有技术背景的读者。

程序层：会话与路由。核心是一个对话状态机：会话怎么开始、多轮上下文怎么存（建议会话 ID 加消息队列，保留最近若干轮）、意图怎么路由（先关键词规则，再模型分类，规则做兜底）。别小看路由——线上多数答非所问不是模型不行，是路由把问题送错了地方。

接口层三件事。1、消息进出：对接各电商开放平台的消息推送与回调，注意 ack 超时和重试设计——漏一条消息就是一条考核扣分；2、业务查询：查订单状态、物流单号、库存的内部 API，机器人答“发到哪了”必须实时查接口，不能靠知识库里的静态文本；3、转人工接口：把会话连同上下文转给人工坐席系统，触发条件做成配置项，别写死在代码里。

知识库层两条路线。先说 FAQ 对：问题和答案成对入库，用户问句先做相似度匹配（向量检索粗筛加精排），过了阈值直接返回。FAQ 见效快、答案可控，适合起步。再说 RAG：把商品详情、售后政策、活动规则切成片段向量化入库，用户问题检索出候选片段，拼进提示词让大模型生成回答。RAG 适合长尾问题，但要管住两点：检索不中就别硬生成；答案涉及时效和金额的必须以接口实查为准——生成模型对数字过于自信，是售后纠纷的常见来源。

人机切换。三个触发器：置信度低于阈值，先答“帮您转人工”再转；用户明确要求，关键词命中即转、不挽留；高敏意图，投诉、退款纠纷直接标给人工。切换时带上完整上下文，让买家不用重讲一遍。

落地顺序三条。1、先只读后写：机器人只答查询类问题，退款、改地址这类写操作留给人工；2、先 FAQ 后 RAG：高频二十题先覆盖，长尾再上检索增强；3、先灰度后全量：夜间时段先跑，看独立解决率和转人工率，再放开全天。每一步都要有回退开关。

自建还是买？自建自由度高，但要长期养三件事：接口维护、知识库更新、坏例回收——知识库不更新，机器人三个月就变笨。没有全职研发的团队，用现成的电商客服机器人更经济：像叮当小宝CS这类产品，平台消息接口、订单查询、知识库配置和转人工都是现成的，商家把自家商品问答灌进去就能跑。有研发团队的，自建一套薄路由加 RAG 也很常见，两条路不冲突。

架构总结：程序层管流程，接口层管真实数据，知识库层管答案，人机切换管兜底。四件事都配上，机器人才算能上线；四件事都持续维护，它才能一直好用。