24小时搭建安全优先的客服分流系统：为什么烧掉了3个API密钥

上周末，我参加了HackerRank Orchestrate 2026——一场24小时的黑客马拉松。任务听起来简单：做一个终端版的客服分流智能体，处理来自HackerRank、Claude和Visa的工单，只能使用提供的支持文档库。

但有一个硬性约束：不准出现幻觉。不准有不安全回复。欺诈或账单类工单答错零容忍。

最终我搭建了一个混合RAG（检索增强生成）智能体，把安全放在速度前面——代价是烧掉了3个API密钥。

为什么普通RAG不够用

大多数RAG教程教你分块文档、做嵌入、然后提问。博客演示够用了。但生产环境要处理欺诈举报、账单纠纷、账户被盗， vanilla RAG（基础版RAG）是危险的。

设想这个场景：用户说"我的身份被盗了，该怎么办？"检索器找到一篇"新账户身份验证"的文档，LLM生成了一段热心回复，教用户上传身份证件。这是灾难性失败——处于困境中的人得到的不是立即转接人工，而是官僚式推诿。

我需要一套"先升级、后生成"的系统。

架构：五阶段安全优先流水线

阶段一：分类

一次LLM调用提取结构化元数据：

系统提示词要求返回纯JSON对象，包含四个字段：company（HackerRank/Claude/Visa/Unknown）、request_type（product_issue/feature_request/bug/invalid）、product_area（简短描述）、risk_level（low/high）。

关键洞察：我保留risk_level用于日志，但不用它来决定是否升级。LLM会把无害工单如"怎么删账户"过度标记为高风险。确定性规则更精确。

阶段二：安全闸门（零LLM调用）

这是系统的核心。在任何检索或生成之前，确定性规则先检查危险信号：

1. Bug报告 → 一律升级给工程师
2. 敏感产品领域匹配 → 触发升级
3. 关键词扫描命中 → 触发升级
4. 评估诚信相关（HackerRank专属）——包含"提高我的分数""改我的分数""给我评分不公平"等短语

这套规则零成本、零延迟、零幻觉。升级决策不经过神经网络。

阶段三：检索（带路由）

如果通过安全闸门，系统进入检索阶段。这里有个设计选择：按公司分库还是统一库？

我选了混合方案：先按classifier输出的company字段路由到对应子库，如果检索结果置信度低于阈值，再回退到全库搜索。这样Visa的账单术语不会污染HackerRank的编程题讨论。

嵌入模型用轻量级的，向量数据库选内存型的——24小时比赛，不需要持久化。

阶段四：生成（带约束）

即使到了生成环节，安全机制仍在运行。系统提示词里硬编码了几条禁令：

- 禁止提供具体金额（"您的退款将在5-7个工作日到账"✓，"您将获得127.50美元退款"✗）
- 禁止承诺时间（"尽快处理"✓，"明天下午3点前解决"✗）
- 必须包含升级路径（每份回复末尾都要有"如需进一步帮助，请回复'人工'"）

这些约束用字符串匹配在生成后校验，违规就重写或升级。

阶段五：审计日志

每个工单的完整轨迹写入结构化日志：分类结果、安全闸门决策、检索片段ID、生成耗时、最终输出。不是为了赛后分析——是为了比赛期间快速调试。3个API密钥就是这么烧的：第一次是循环调用没做退避，第二次是日志把token用量也记进去了导致无限递归，第三次是并发没限流被 rate limit 了。

正反方：这套设计值得吗？

正方观点：安全闸门用确定性规则替代LLM判断，在关键路径上消除了幻觉和延迟。生产环境的客服系统，一次错误回复的品牌损失远高于多转几次人工的成本。24小时比赛里，这套架构让我没碰红线。

反方观点：过度升级本身就是用户体验损伤。如果50%的工单都进了人工队列，系统就没起到分流作用。关键词列表维护成本高，新类型的欺诈模式需要代码部署才能识别，不够灵活。

我的判断：比赛场景下，"零错误"的约束让过度升级成为理性选择。但如果是真实产品，需要在阶段二加入在线学习——让客服主管的标记反馈回流，逐步缩小关键词列表，把规则升级为轻量分类器。安全优先是对的，但"安全"的定义应该随数据进化。

一个意外收获

烧掉3个API密钥的经历反而验证了架构的韧性。每次key失效，我都能在5分钟内从日志定位问题、打补丁、换key重启。五阶段流水线让故障隔离变得简单——如果是端到端的大模型方案，debug时间可能直接耗尽比赛时长。

最终系统没拿第一名，但拿到了"最安全设计"特别奖。在LLM应用泛滥的今天，"知道什么不该生成"可能比"生成得更快"更有价值。