1. 为什么“套壳大模型”在招聘场景里活不过三轮面试2026 年开年到现在我前后参与了四家不同规模公司的 AI 招聘系统选型有做互联网中厂的有做制造业集团 HR 数字化的也有做猎头 SaaS 的。一个非常明显的感受是市面上挂着“AI 招聘”名头的产品十有七八底层就是调个通用大模型 API外面套一层简历解析的 Prompt再配个聊天窗口就敢叫“智能招聘大脑”。这种系统在 Demo 阶段看着挺唬人一旦进入真实招聘流程——尤其是中大型企业那种日均几千份简历、几十个在招岗位、多轮面试交叉并行的场景——基本撑不过三轮面试就会露馅。露馅的地方很集中。第一是幻觉候选人明明写的是“负责过支付网关的幂等设计”系统给你总结成“主导过支付系统架构”面试官拿着这份摘要去问候选人一脸懵。第二是知识割裂企业的岗位 JD、历史面试评价、内部职级体系、薪酬带宽这些核心资产散落在 HR SaaS、飞书文档、Excel 和邮件里通用大模型根本够不着只能靠人肉喂 Prompt喂一次管一次下次换个岗位又得重来。第三是不可追溯系统给出一个“推荐进入复试”的结论你问它为什么它给你一段听起来很有道理但无法对应到任何一条具体简历事实的话术HR 不敢信业务面试官更不敢信。所以这篇东西不打算写成又一篇“AI 招聘系统哪家强”的软文。我想干的事情更具体把企业级 AI 招聘系统的底层架构拆开给你一套可以拿去和供应商对线、也可以拿去和内部架构评审会交差的评估矩阵。核心围绕四个东西展开——MAS多智能体系统、RAG检索增强生成、消息队列Kafka / RabbitMQ / RocketMQ、以及 Agentic RAG 的工程化落地。这四个词不是赶时髦它们分别对应招聘系统里四个绕不开的硬骨头任务编排、知识 grounding、异步解耦、以及检索决策的自主性。如果你正在做 2026 年的招聘系统选型或者你是一个被老板要求“三个月内把 AI 招聘搞上线”的技术负责人这篇内容应该能帮你省掉至少两轮被供应商话术带偏的时间。我会尽量把每个架构决策背后的“为什么”讲清楚参数怎么算、坑在哪里、什么场景该选什么都摊开说。适合有基本后端和 LLM 应用经验的读者纯小白也能看懂大逻辑但具体到消息队列参数那块可能需要你有一点分布式系统的基础。2. 先搞清楚企业级 AI 招聘到底在解决哪几类问题2.1 招聘流程的本质是一个多阶段、多角色、强状态的决策流水线很多人把招聘系统想简单了觉得就是“简历进来、打分、排序、推给 HR”。真实的企业招聘是一条状态机非常复杂的流水线。一份简历从投递到入职中间要经过简历解析、硬性条件过滤学历、年限、证书、岗位匹配打分、招聘专员初筛、用人部门复筛、笔试/测评、多轮面试、offer 审批、背调、入职。每一步都有不同的角色参与每一步都会产生新的结构化或非结构化数据每一步的结论都可能因为上游信息变化而需要重算。这就决定了 AI 招聘系统不能是一个“请求-响应”式的无状态服务。它必须维护每个候选人、每个岗位、每一轮面试的上下文状态。通用大模型 API 是无状态的你每次调用都得把全部上下文重新塞进去token 成本先不说上下文窗口再大也扛不住一个候选人跨三周、跨五个面试官的完整轨迹。这就是为什么MAS多智能体系统会成为企业级招聘架构的必然选择——你需要一组各有分工、能共享状态、能互相调用的智能体而不是一个什么都干的“全能大模型”。2.2 招聘场景对“知识 grounding”的要求远高于通用问答招聘里最要命的知识不是公开的行业常识而是企业私有的、动态变化的、强上下文依赖的那一部分。比如某个岗位的 JD 里写着“熟悉分布式事务”但你们团队实际用的是 Saga 模式而不是 XA面试官期望候选人聊的是 Saga 的补偿设计这个隐含期望通用模型不可能知道。你们公司 P7 和 P8 的职级差异在面试评价里体现为“能否独立负责一个跨团队项目”还是“能否定义一个新的技术方向”这种细微差别只存在于历史评价数据里。某个业务线去年裁过一轮今年 HC 卡得很死招聘专员在筛选时对“期望薪资偏高”的候选人会格外谨慎这种策略性知识也不会写在任何公开文档里。这些知识如果不能让模型在生成结论时“看到”那 AI 招聘就永远停留在玩具阶段。RAG检索增强生成解决的就是这个问题——把企业私有知识切片、向量化、存进知识库在模型生成之前先检索出最相关的片段作为 grounding 塞进上下文。但普通 RAG 在招聘场景里也不够用因为招聘的检索需求往往是多跳的、需要推理的你要先找到“这个岗位的历史成功候选人画像”再根据画像去检索“当前候选人里谁最接近”再根据接近程度去检索“面试官对该类候选人的历史评价偏好”。这就是Agentic RAG要解决的问题——让检索本身变成一个由智能体自主决策的过程而不是一次性的向量相似度查询。2.3 异步解耦不是可选项是招聘系统能不能扛住高峰的生死线招聘有非常明显的潮汐特征。校招季一天几万份简历涌进来社招旺季一个岗位开放两小时收到上千份投递而平时可能一天就几十份。如果简历解析、打分、检索这些重活儿都做成同步调用系统在高峰必挂。更麻烦的是招聘流程里很多步骤是长耗时的一个候选人要等面试官三天内给评价一个 offer 要等三级审批这些都不能用同步请求去等。消息队列在这里的角色就是削峰填谷 异步编排。简历进来先扔进队列解析服务按自己的消费能力慢慢处理面试评价提交后发个事件触发后续的流程推进和通知。Kafka、RabbitMQ、RocketMQ 这三个是绕不开的选项但它们在招聘场景下的表现差异很大后面我会专门用一节来对比包括我实际踩过的坑。3. 底层架构评估矩阵六个维度把“套壳”和“真架构”分开3.1 维度一状态管理与任务编排能力这是区分“套壳”和“真架构”的第一道分水岭。套壳系统的状态基本存在数据库的一张宽表里每次请求现查现拼真架构会有一个显式的状态机或工作流引擎来管理候选人生命周期。评估时你可以直接问供应商三个问题候选人从“初筛通过”到“面试完成”这个过程中如果面试官中途修改了评价系统如何保证后续的 offer 审批看到的是最新版本如果一个候选人在 A 岗位被拒两周后投了 B 岗位系统如何复用之前的解析结果和评价数据同时避免“先入为主”的偏见多智能体之间如何共享上下文是每个 Agent 独立维护自己的记忆还是有一个共享的 BlackboardMAS 架构下我比较推荐的是共享状态 角色化 Agent的模式。具体来说有一个中央的 Candidate Context Store可以用 Redis 持久化 DB 做两级存储所有 Agent 读写同一份上下文但每个 Agent 只负责自己那一段逻辑。比如 Resume Parser Agent 只负责把简历变成结构化字段Matching Agent 只负责打分Interview Scheduler Agent 只负责协调时间。它们之间通过消息队列通信而不是直接函数调用这样任何一个 Agent 挂掉都不会阻塞整条流水线。3.2 维度二RAG 的检索质量与可追溯性RAG 在招聘系统里的评估不能只看“检索命中率”这种笼统指标。我一般会拆成四个子指标子指标含义招聘场景下的及格线召回率相关文档是否被检索出来岗位 JD 相关片段召回 ≥ 90%精确率检索结果里有多少是真正相关的Top-5 片段精确率 ≥ 70%可追溯性生成结论能否对应到具体检索片段每条结论必须能点开看到来源时效性知识更新后多久能被检索到新 JD 发布后 5 分钟内可检索普通 RAG 用向量相似度做检索在招聘场景里最大的问题是语义漂移。比如候选人写“负责过日活百万的推荐系统”向量检索可能给你召回一堆“推荐系统”相关的文档但真正相关的是“日活百万”这个规模量级对应的岗位要求。这时候就需要GraphRAG 或 Ontology RAG的介入——把岗位、技能、职级、业务线建成一个本体图谱检索时先在图谱上做推理再去向量库取具体片段。Agentic RAG 的落地方式我实测下来比较稳的是用一个 Router Agent 先判断当前查询需要走哪条检索路径向量检索 / 图谱检索 / 混合检索再用一个 Rerank Agent 对召回结果做二次排序最后用一个 Grounding Agent 把检索片段和生成结论做对齐校验。这套流程比单次向量检索慢 200-400ms但在招聘这种对准确性要求极高的场景里这点延迟完全值得。3.3 维度三消息队列的选型与招聘场景的匹配度Kafka、RabbitMQ、RocketMQ 这三个我在招聘系统里都用过说几个真实的体感差异。Kafka的优势是吞吐量极大校招季一天几十万份简历的解析任务Kafka 扛起来毫无压力。但它的弱项是延迟敏感型的小消息——比如面试官提交评价后要立刻触发通知Kafka 的批量机制可能导致几秒的延迟。另外 Kafka 的 topic 管理比较重如果你有几十个不同的事件类型简历投递、解析完成、打分完成、面试安排、评价提交、offer 审批……每个都开 topic 会让运维很头疼。RabbitMQ的优势是路由灵活exchange queue 的模型非常适合招聘这种“一个事件触发多个下游动作”的场景。比如“面试完成”这个事件需要同时触发更新候选人状态、通知 HR、触发下一轮安排、写入评价知识库。RabbitMQ 的 fanout exchange 可以很优雅地做这件事。但 RabbitMQ 在消息堆积时的性能下降比较明显校招季如果消费者跟不上队列积压到百万级管理界面基本卡死。RocketMQ是我在招聘场景里比较推荐的折中方案。它的延迟比 Kafka 低吞吐比 RabbitMQ 高而且支持事务消息——这在招聘里很有用比如“offer 审批通过”这个动作需要同时更新数据库和发送通知事务消息能保证两者要么都成功要么都失败。另外 RocketMQ 的延时消息功能可以很方便地做“面试前 24 小时提醒”这种定时任务不用额外引入调度系统。我实际用下来的组合是简历解析这种大批量、可容忍延迟的任务走 Kafka面试流程推进这种低延迟、多下游的任务走 RocketMQ内部管理通知这种小规模、路由复杂的走 RabbitMQ。当然如果团队运维能力有限统一用 RocketMQ 也能覆盖 90% 的场景。3.4 维度四Agentic RAG 的自主决策边界Agentic RAG 听起来很美好但在招聘系统里必须给它划清楚决策边界。我的原则是Agent 可以自主决定“检索什么”和“怎么检索”但不能自主决定“录用谁”和“拒绝谁”。前者是信息获取后者是价值判断必须有人类在环。具体落地时我会把 Agentic RAG 的自主性限制在三个动作上查询改写把 HR 的自然语言查询“帮我找几个做过高并发后端的”改写成多条检索 query分别去向量库和图谱里查。检索路径选择根据查询类型决定走向量检索、图谱检索还是混合检索。结果重排与去重对多路召回的结果做合并、去重、按相关性重排。超出这三个动作的比如“根据检索结果直接生成录用建议”必须经过一个显式的 Human-in-the-loop 确认节点。这不是技术做不到而是招聘的合规和公平性要求决定的。3.5 维度五可观测性与评估闭环一个 AI 招聘系统上线后你怎么知道它到底好不好套壳系统基本没有这个能力因为它的输出不可追溯。真架构必须内置评估闭环每次 AI 给出一个结论比如“推荐进入复试”系统要记录这个结论对应的检索片段、模型版本、Prompt 版本、以及最终人类的决策面试官是否真的让他进复试了。这些数据积累起来才能做持续的离线评估和在线 A/B 测试。我一般会要求系统至少能产出这几张表结论溯源表每条 AI 结论对应哪些检索片段和模型调用。人类反馈表HR 和面试官对 AI 结论的采纳/修改/拒绝记录。检索质量表每次检索的召回片段、相关性打分、最终是否被采用。延迟分布表各环节 P50 / P95 / P99 延迟。没有这四张表所谓的“持续优化”就是空话。3.6 维度六成本结构与规模化能力最后但同样重要的是钱。套壳系统的成本模型很简单token 消耗 × 单价。但企业级招聘系统的成本要复杂得多向量库成本存储 检索随简历量线性增长。消息队列成本吞吐量 存储随事件量增长。Agent 编排成本每个 Agent 的调用次数 × 单次成本多智能体架构下这个数字可能比单模型高 3-5 倍。人工审核成本Human-in-the-loop 节点的人力投入。我见过一个团队用 MAS Agentic RAG 做招聘效果确实好但单份简历的处理成本到了 0.8 元校招季一天十万份就是八万块。后来他们把 Agent 数量从 7 个砍到 4 个检索路径从三路混合改成两路成本降到 0.3 元效果只掉了 5%。这个取舍在选型阶段就要想清楚。4. 实操落地从零搭一套可评估的 AI 招聘架构原型4.1 环境准备与核心组件选型假设你现在要从零搭一个原型来验证架构可行性我建议的最小可行组合是消息队列RocketMQ 5.x单机 Docker 部署即可生产再上集群向量库Milvus 或 QdrantMilvus 生态更全Qdrant 更轻量图数据库Neo4j Community做 Ontology RAG 的本体存储Agent 框架LangChain4j 或 Spring AI如果团队是 Java 栈Python 栈可以用 LangGraphLLM先用一个中等规模的模型做原型比如 Qwen 或 GLM 的 API验证流程跑通后再换更大模型状态存储Redis热状态 PostgreSQL冷状态和审计日志这套组合在一台 16C32G 的机器上就能跑起来Docker Compose 一把梭。关键是先把数据流跑通而不是一上来就追求模型效果。4.2 消息队列的 Topic 设计与参数计算招聘系统的事件类型我一般会设计成这几个 TopicTopic生产者消费者消息量级日延迟要求resume.raw投递入口解析服务1万-10万分钟级resume.parsed解析服务打分服务、检索服务同上秒级match.scored打分服务初筛服务、通知服务同上秒级interview.event面试系统状态服务、通知服务、知识库1千-1万秒级offer.event审批系统状态服务、通知服务百级秒级参数计算上以校招季峰值 10 万份简历/天、集中在 8 小时内投递为例平均 TPS 100000 / (8 × 3600) ≈ 3.5峰值 TPS 按 5 倍算 ≈ 17.5每份简历解析后产生约 5 条下游消息峰值消息 TPS ≈ 87.5这个量级对 RocketMQ 来说非常轻松单机就能扛。但如果你要做延时消息比如面试前 24 小时提醒RocketMQ 的延时级别默认只支持固定的 18 个级别需要自己扩展或者用时间轮实现。我踩过的坑是直接用delayTimeLevel做 24 小时延时结果发现最大级别只到 2 小时后来改成用定时任务扫表 普通消息触发才解决。4.3 RAG 知识库的切片与索引策略招聘知识库的切片不能像通用文档那样按固定 token 数切。我的做法是按语义单元切岗位 JD按“职责”“要求”“加分项”三个段落切每段一个 chunk。历史面试评价按“候选人-面试官-轮次”三元组切每条评价一个 chunk附带岗位、职级、时间元数据。职级体系文档按职级切每个职级一个 chunk附带能力维度标签。薪酬带宽按“岗位序列-职级”切每个组合一个 chunk。切片后做 embedding 时我建议同时存两份向量一份是原始文本的 embedding一份是加了元数据岗位、职级、时间的 embedding。检索时先用元数据做过滤再做向量相似度这样能大幅提升精确率。实测下来加了元数据过滤后Top-5 精确率从 52% 提升到 78%。Ontology RAG 的部分我会建一个简单的图谱节点岗位、技能、职级、业务线、候选人边岗位-要求-技能、职级-要求-技能、候选人-具备-技能、候选人-投递-岗位检索时先用图谱做一跳或两跳推理找出“这个岗位最核心的三个技能”再去向量库检索“具备这三个技能的候选人”。这比纯向量检索的召回质量高很多尤其是在岗位要求比较抽象的时候。4.4 Agentic RAG 的 Router 与 Rerank 实现Router Agent 的核心是一个分类器输入是 HR 的查询输出是检索路径。我一般用一个小模型比如 1.5B 级别的做这个分类因为它的判断逻辑相对固定# 伪代码示意 def route_query(query): intent classify_intent(query) # 岗位匹配 / 候选人检索 / 评价查询 / 流程状态 if intent 岗位匹配: return [vector_search, graph_search] elif intent 候选人检索: return [graph_search, vector_search] elif intent 评价查询: return [vector_search] else: return [vector_search]Rerank Agent 我推荐用Cross-Encoder模型而不是简单的余弦相似度。Cross-Encoder 会把 query 和每个候选片段拼在一起过一遍模型精度高很多代价是慢。实测下来对 Top-20 候选做 rerank延迟增加约 150ms但精确率提升 20 个百分点以上。Grounding Agent 的职责是校验生成结论和检索片段的一致性。简单做法是用一个 NLI自然语言推理模型判断“结论是否被片段蕴含”。如果某个结论找不到任何片段支撑就打回去让生成 Agent 重写或者标记为“低置信度”让人工复核。4.5 状态管理与 Human-in-the-loop 的接入点状态管理我用的是Redis Hash PostgreSQL 事件表的组合。Redis 存当前热状态候选人当前阶段、最近一次评价、待办事项PostgreSQL 存完整的事件流每次状态变更都追加一条记录。这样既能快速读取当前状态又能追溯完整历史。Human-in-the-loop 的接入点我建议至少设三个初筛结论确认AI 给出“推荐/不推荐”后HR 必须点确认才能进入下一轮。面试评价生成AI 根据面试记录生成评价草稿面试官必须编辑或确认后才能提交。offer 审批AI 可以给出薪酬建议但最终审批必须由人完成。这三个点不是技术限制而是合规和信任建设的需要。我见过一个团队为了追求“全自动”把这三个点都去掉了结果上线两周就被业务部门投诉到 CTO 那里原因是“AI 把一个大专学历的候选人推到了要求硕士的岗位面试官白跑一趟”。5. 常见问题与排查技巧实录5.1 检索结果不相关但向量相似度很高这是 RAG 在招聘场景里最常见的问题。原因通常是 embedding 模型对“招聘领域术语”不敏感。比如“高并发”和“大流量”在通用 embedding 里可能距离很远但在招聘语境里是近义词。解决办法有两个一是用招聘领域数据做 embedding 模型的微调需要标注数据成本高二是在检索前做 query 改写把 HR 的口语化查询改写成多条标准术语查询分别检索后合并。我实测下来第二种方法成本低、见效快query 改写后召回率能提升 30% 以上。5.2 消息队列消息堆积消费者跟不上校招季最容易出这个问题。排查思路先看是生产太快还是消费太慢。如果是生产太快考虑加消费者实例如果是消费太慢看消费者里有没有同步阻塞操作比如调用 LLM API 没设超时。检查消费者的批量消费配置。RocketMQ 默认是批量消费但如果你的处理逻辑是逐条调 LLM批量反而会拖慢。这时候应该改成单条消费 多线程。如果消息已经堆积到百万级不要急着扩消费者先降级把非核心消息比如通知类先丢弃或延迟处理保证核心流程解析、打分的消息优先消费。我踩过的一个坑是消费者里调 LLM API 没设超时结果一个请求卡住整个消费者线程池被占满消息堆积到 50 万。后来加了 3 秒超时 重试机制才解决。5.3 Agent 之间上下文不一致MAS 架构下如果每个 Agent 独立维护上下文很容易出现“A Agent 认为候选人已通过初筛B Agent 还在等初筛结果”的情况。解决办法是强制所有 Agent 读写同一个 Context Store并且 Context Store 的更新要走乐观锁或版本号机制。具体实现上我会给每个候选人上下文加一个version字段Agent 更新时先读 version写入时校验 version 是否变化如果变了就重试。这样能避免并发写覆盖。5.4 成本失控单份简历处理成本过高前面提过MAS Agentic RAG 的成本可能是单模型的 3-5 倍。控制成本的手段Agent 合并把功能相近的 Agent 合并比如“简历解析”和“字段抽取”可以合成一个。检索路径降级非核心查询只走向量检索不走图谱。模型分级简单任务用小模型复杂任务才用大模型。缓存相同岗位的 JD 检索结果可以缓存不用每次重新检索。我一般会设一个成本红线单份简历处理成本不超过 0.5 元。超过这个线就要做优化否则规模化之后财务会来找你。5.5 常见问题速查表问题现象可能原因排查动作解决方向检索结果不相关embedding 领域不匹配检查 query 和召回片段的语义距离query 改写 元数据过滤消息堆积消费者阻塞或不足看消费延迟、线程池状态加消费者、设超时、降级非核心消息Agent 上下文不一致各自维护状态检查 Context Store 读写日志统一 Context Store 版本号成本过高Agent 过多、检索路径过重统计各 Agent 调用次数和成本合并 Agent、降级检索、模型分级生成结论不可追溯没有记录检索片段检查日志表加结论溯源表强制记录来源面试评价生成偏差历史评价数据有偏见分析评价数据的分布去偏处理 人工确认节点6. 选型决策清单拿去和供应商对线的问题列表6.1 架构层面的必问问题如果你在选型阶段下面这些问题可以直接拿去问供应商。能答上来且答得具体的基本是真架构支支吾吾或者用“我们的 AI 很智能”糊弄的大概率是套壳。你们的 MAS 里有多少个 Agent各自职责是什么Agent 之间怎么通信上下文状态存在哪里Redis 还是数据库有没有版本控制RAG 的检索路径有几条向量检索、图谱检索、混合检索分别用在什么场景有没有 Agentic RAG 的 RouterRouter 用什么模型决策逻辑是什么消息队列用的什么Topic 怎么设计的峰值 TPS 多少有没有结论溯源表每条 AI 结论能不能点开看到来源片段Human-in-the-loop 的接入点有几个分别在哪一步单份简历的处理成本是多少怎么算出来的6.2 不同规模企业的选型建议中小型企业日简历量 1000不建议上全套 MAS Agentic RAG成本太高。可以用“单模型 普通 RAG RabbitMQ”的轻量组合重点解决简历解析和岗位匹配两个场景。等量级上来了再逐步加 Agent。中大型企业日简历量 1000-10000建议上 MAS 混合 RAG消息队列用 RocketMQ。重点建设知识库和评估闭环把历史面试评价和岗位 JD 的检索质量做上去。大型集团日简历量 10000全套架构Kafka RocketMQ 混用Agentic RAG 全量落地。重点做成本控制和可观测性没有评估闭环的系统在这个量级下就是黑盒出了问题没法排查。6.3 一个真实的选型翻车案例去年我参与的一个选型供应商在 Demo 时展示了非常漂亮的“AI 面试官”功能能根据简历自动生成面试问题还能实时分析候选人回答。技术团队很兴奋差点就签了。后来我们要求做 POC用真实数据跑了一遍发现两个致命问题一是面试问题生成严重依赖简历里的关键词候选人如果简历写得比较概括生成的问题就很空泛二是实时分析候选人回答的功能底层是把语音转文字后调通用大模型做情感分析准确率在真实面试场景下不到 60%。后来我们复盘发现供应商的架构里根本没有 RAG所有“智能”都来自 Prompt 工程。这就是典型的套壳。如果当时 POC 阶段没有坚持用真实数据上线后就是灾难。所以我的建议是任何 AI 招聘系统POC 必须用你自己的真实简历、真实 JD、真实面试评价跑一遍。Demo 数据都是精心挑选的看不出问题。7. 我个人在实际落地中的几个体会第一个体会是不要追求“全自动”。招聘本质上是一个涉及人的决策过程AI 能做的是信息聚合、初步筛选、辅助决策而不是替代决策。把 Human-in-the-loop 做好比把模型调优到 99% 准确率更重要。我见过太多团队在模型效果上死磕结果忽略了流程设计上线后 HR 根本不用。第二个体会是知识库的质量决定 RAG 的上限。很多团队花大力气调检索算法但知识库里的文档本身就不全、不准、不及时。我的做法是先把知识库建设当成一个独立的工程来做指定专人负责 JD 更新、评价归档、职级文档维护保证检索源的质量。检索算法用最基础的向量相似度 元数据过滤效果就已经很好了。第三个体会是消息队列的选型不要过度设计。我见过一个团队日简历量才 500非要上 Kafka 集群运维成本比开发成本还高。量级没到之前RocketMQ 单机甚至 RabbitMQ 都够用。等真的到了校招季扛不住的时候再换迁移成本远小于提前过度设计的成本。第四个体会是成本要一开始就监控。我一般会在系统里埋一个成本计数器每处理一份简历就累加 token 消耗和检索调用次数实时展示在监控面板上。这样一旦成本异常能立刻发现是哪个 Agent 或哪条检索路径出了问题。没有这个监控等到月底账单出来才发现就晚了。最后分享一个小的工程技巧在 Agentic RAG 的 Router 里加一个缓存层把最近 5 分钟内相同的查询路由结果缓存起来。招聘场景里 HR 的查询重复率其实很高比如多个 HR 同时在看同一个岗位的候选人查询语句可能一模一样。加了这个缓存后Router 的调用量能降 40% 左右延迟也明显下降。这个优化很小但实测很管用。