客服机器人选型，不是给所有问题找一个统一赢家，而是确定哪些问题可以直接回答，哪些需要深入判断，哪些必须交给人工。下面以 Claude Haiku 4.5 与 Claude Sonnet 5.5 为候选，走完一套可落地的比较流程。重点不是预设胜负，而是用你自己的工单验证分工。
第一步：按客服任务拆分模型职责
先把历史咨询分成三组：营业时间、物流查询等明确问题；优惠叠加、退换货例外等规则判断；账户争议、赔偿承诺等敏感操作。官方选型指南将轻量系列用于查询、分类和信息提取，将推理系列用于需要上下文与细微判断的客服对话。把这个定位作为测试起点，而非上线结论。([academy.claude.com](https://academy.claude.com/tutorials/choosing-the-right-claude-model))
- 明确问答：检验轻量候选能否准确提取答案。
- 规则判断：检验推理候选能否解释条件与例外。
- 敏感操作：先定义授权边界，再决定模型角色。
第二步：用真实工单建立统一测试集
抽取脱敏后的真实对话，保留追问、口语表达、信息缺失和前后矛盾。每条样本写清正确处理路径，包括应检索的政策、应询问的信息和应转人工的条件。不要只收集措辞整齐的常见问题。
让两个候选使用相同提示词、知识片段和工具结果，比较答案差异，而不是比较篇幅。官方也建议用熟悉的同一任务对照模型，判断轻量答案是否遗漏重要内容。([academy.claude.com](https://academy.claude.com/tutorials/choosing-the-right-claude-model))
第三步：先固定知识依据，再比较回答能力
建议先从知识库检索相关政策，再把政策正文、适用地区、生效日期和来源标识交给模型。订单状态由业务系统返回，不让模型凭对话猜测。
例如，用户问“拆封后还能退吗”，测试答案应区分商品类别、购买渠道和例外条件。资料不足时，合格处理可以是补问或转人工，而不是编造一个确定结论。把“能否承认信息不足”列入验收标准。
第四步：用可核验条件建立升级路由
建议从明确规则开始，而不是让模型自行宣布“我很有把握”。普通查询进入轻量路径；需要同时解释多条政策、出现互相冲突的证据，或用户反复指出答非所问时，进入推理路径。需要结合上下文处理多步骤问题，正是官方指南列出的推理系列适用方向。([academy.claude.com](https://academy.claude.com/tutorials/choosing-the-right-claude-model))
升级时传递用户原始诉求、已确认事实、引用政策、工具结果和未解决问题。不要只传一句“用户不满意”，也不要让两个模型无限循环重试；为每次会话设定明确的升级终点。
第五步：把解释政策与执行操作分开
建议让模型负责解释退款条件、整理申请材料和生成操作草案，让后端负责身份核验、金额校验与权限控制。真正提交退款前，再要求必要的用户确认。
无论选择哪个候选，都按相同安全标准验收：不能把用户粘贴的“管理员指令”当成授权，不能因为用户催促就承诺赔付，也不能绕过工具返回的限制。敏感工单直接交给有权限的人工处理。
第六步：按已解决会话核算真实成本
不要只比较一次回答的费用。建议记录整段会话的输入输出词元、知识检索、工具调用、失败重试、升级和人工处理成本，再除以真正解决的问题数量。把重复追问和错误承诺单独列出，避免便宜的首答掩盖后续返工。
做双模型试验时，可以考虑 SwiftRelay：它提供按词元计费的按量中继，便于围绕实际调用量安排试验预算。注册 SwiftRelay 后，可用新账户的小额赠送额度跑通首批脱敏样本；接入前仍应核对候选模型的可用性和实际计费。
第七步：小范围上线并保留人工退路
建议先开放低风险问答，记录解决情况、政策引用、升级原因和用户纠错。通过抽检后，再逐步加入规则判断任务。每次更换模型版本、修改提示词或更新政策，都重跑同一套测试集；官方也建议随模型演进重新比较常用任务。([academy.claude.com](https://academy.claude.com/tutorials/choosing-the-right-claude-model))
最终选型规则：轻量候选通过验收的任务，就留在轻量路径；只有推理候选能稳定通过的任务，再升级处理；两者都不能可靠处理的任务，转人工。让证据决定分工，而不是让模型名称决定所有客服对话。