核心要点
能说清匹配维度：渠道/群组、@提及、关键词、正则、再到 LLM 意图分类，形成从廉价到昂贵的分层匹配漏斗
能讲优先级与短路：显式 @提及 > 精确关键词/正则 > 意图分类 > 默认兜底，命中高优先级即短路，不再下探
能处理冲突与去重：多个 Agent 同时命中时用优先级排序或抢占锁，避免重复响应同一条消息
能设计可配置路由表和默认兜底 Agent：路由规则数据化、可热更新，未命中时由兜底 Agent 接管而非静默丢弃
标准回答
消息路由的目标是把一条进来的消息分发到最合适的一个（或少数几个）Agent/处理器，核心是匹配维度、优先级短路、冲突去重和兜底四件事。
匹配维度从廉价到昂贵分层
先用最便宜的规则过滤：渠道与群组（这条消息来自哪个群、哪个频道，限定候选 Agent 范围）；再看显式信号 @提及（用户明确点名某个 Agent）；然后是关键词与正则（命中预设触发词或模式）；最后才落到意图分类（用一个轻量分类模型或 LLM 判断用户意图）。把昂贵的 LLM 分类放在漏斗末端，能显著降本降延迟。
优先级与短路
匹配维度天然有强弱：显式 @提及 > 精确关键词/正则匹配 > 模糊意图分类 > 默认兜底。命中高优先级规则就短路返回，不再继续往下匹配，既快又可预测。规则内部也要排序，例如更具体的正则排在更宽泛的关键词前。
冲突解决与去重
当多条规则、多个 Agent 同时命中同一消息时，要避免重复响应：给每个路由规则赋优先级权重取最高者；或对一条消息加处理锁/抢占机制，谁先抢到谁处理；并发场景用消息 ID 做幂等去重，保证同一消息只被消费一次。
默认兜底与可配置路由表
任何规则都没命中时，不能让消息石沉大海，要有一个默认兜底 Agent接管（比如通用助手或转人工）。整张路由表应数据化、可配置（规则、优先级、目标 Agent 以配置形式存储并支持热更新），便于运营在不改代码的情况下调整路由策略，也方便灰度和回滚。
常见误区
⚠️ 常见踩坑
把路由直接交给一个 LLM「全凭意图判断」——既慢又贵还不稳定，正确做法是先用渠道/@提及/关键词等廉价规则短路，意图分类只兜复杂情况；另一个误区是不做去重与优先级，导致一条消息触发多个 Agent 同时抢答、刷屏甚至互相循环触发；还有人忘了设默认兜底，未命中的消息被静默丢弃，用户以为没人理。
追问
追问 1：路由规则之间冲突、多个 Agent 都命中时怎么决定谁来响应？
给每条规则赋优先级权重，按权重取最高者；权重相同再按规则具体程度（精确正则 > 宽泛关键词）排序。运行时对一条消息加处理锁或抢占标记，第一个命中的 Agent 锁定后其余跳过；并发消费时用消息 ID 做幂等去重，保证一条消息只被处理一次。
追问 2：什么时候该用 LLM 意图分类做路由，而不是关键词/正则？
当用户表达方式多样、同一意图有大量同义说法、关键词覆盖不全或维护成本高时，用 LLM/轻量分类模型识别意图更鲁棒。但它延迟和成本更高，所以放在漏斗末端——先让渠道、@提及、关键词短路掉大部分明确情况，只把剩余模糊消息交给意图分类，必要时缓存分类结果。
追问 3：怎么防止 Agent 之间因为路由形成循环触发、互相刷屏？
给消息打来源标记并区分「人类发起」与「Agent 发起」，默认 Agent 产生的消息不再触发其他 Agent，或需显式白名单才允许；维护一条消息的处理链路深度并设上限，超过即停止；对相同内容做去重，并限制单位时间内的触发频率，必要时加熔断。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习