调度 Agent 怎么知道该分给谁？「 —— 你要讲清能力声明 + 语义匹配 + LLM 兜底的路由策略

1️⃣ 考察意图

面试官想考察你对多 Agent 系统“路由”这一核心组件的设计能力，而非单纯背诵概念。刁钻点在于：调度 Agent 不是简单的“分类器”，它必须处理能力描述不精确、用户意图模糊、以及冷启动无匹配等真实工程问题。答好了能展示你对能力注册（Capability Registration）、语义匹配（Semantic Matching） 和异常兜底（Fallback） 三者协同的深度理解，以及如何平衡准确率与延迟的工程取舍。

2️⃣ 标准答

多 Agent 路由的核心是“谁有能力谁接活”，但能力描述和用户请求都是非结构化的，所以需要三层策略：能力声明做注册，语义匹配做初筛，LLM 兜底做保底。

1. 能力声明：结构化注册表

每个子 Agent 在启动时向调度中心注册，注册表不是简单写个名字，而是包含：

领域标签：如 weather, news, calculator，支持层级（finance/stock）。
工具列表：具体 API 或函数签名，如 get_weather(city: str, date: str) -> dict。
输入输出 Schema：用 JSON Schema 描述，例如 {"type": "object", "properties": {"city": {"type": "string"}}}。
示例 Query：人工标注 3-5 条典型请求，如 “北京明天天气如何？”。
置信度阈值：该 Agent 认为能处理的语义相似度下限（例如 0.7）。

为什么这么做？ 纯用自然语言描述能力（如“我能处理天气问题”）会导致语义歧义，结构化注册表让后续匹配有明确的向量化和规则化基础。

2. 语义匹配：向量化 + 多路召回

调度 Agent 收到用户请求后，执行两步：

Query 编码：用 Sentence-BERT（如 all-MiniLM-L6-v2）或 OpenAI text-embedding-3-small 将请求转为 384/1536 维向量。
多路召回：
向量相似度：与每个 Agent 的“示例 Query”向量做余弦相似度，取 Top-3。
关键词触发：若请求含“天气”、“股票”等高频词，直接匹配对应 Agent。
规则路由：如请求含“计算 2+3”，直接路由到计算器 Agent。

工程取舍：向量相似度召回率高但延迟高（一次请求需遍历所有 Agent 的示例向量），所以实际中会用 HNSW 索引（如 FAISS）将匹配时间从 O(n) 降到 O(log n)。关键词触发作为快速通道，牺牲召回率换延迟（<5ms）。

3. LLM 兜底：处理模糊与冷启动

语义匹配可能失败，例如：

置信度低：所有候选 Agent 的相似度都低于阈值（如 <0.6）。
无匹配：用户请求涉及未注册能力（如“帮我写首诗”）。
多意图：请求同时涉及天气和新闻（如“北京明天天气如何，顺便看看今天的热点新闻”）。

此时调度 Agent 将请求 + 所有 Agent 的能力声明（结构化摘要）拼成 prompt，调用 LLM（如 GPT-4o-mini）做动态分配。LLM 输出格式为：

{"agent": "weather", "reason": "用户明确询问天气", "confidence": 0.95} 若 LLM 也认为无法分配，则返回用户澄清：“您是想查天气还是看新闻？或者两者都要？”

实际落地的坑：LLM 兜底延迟高（1-3 秒），且可能产生幻觉（分配错误 Agent）。解法是：设置 LLM 调用超时（如 2 秒），超时后降级为“返回用户澄清”；同时记录 LLM 分配结果，用于后续微调语义匹配模型（反馈完整流程）。

4. 路由策略：动态负载均衡

路由不是一次性的，需考虑 Agent 当前负载：

健康检查：每个 Agent 定期上报 QPS、平均响应时间、错误率。
权重分配：若天气 Agent 当前 QPS 过高（如 >100），调度 Agent 将部分请求路由到备用天气 Agent（如果有）或降级为返回缓存结果。
优先级队列：付费用户请求优先路由到低延迟 Agent。

5. 反馈完整流程：持续优化

记录每次路由结果（成功/失败、用户反馈），定期：

更新示例 Query：将成功路由的请求加入对应 Agent 的示例库。
调整阈值：若某 Agent 频繁被误分配，提高其置信度阈值。
微调 Embedding 模型：用路由日志做对比学习，优化语义匹配准确率。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，能力声明，每个子 Agent 注册结构化描述（领域、工具、示例 Query），存入注册表；第二，语义匹配，调度 Agent 用 Sentence-BERT 将请求向量化，通过 FAISS 索引做 Top-K 召回，结合关键词触发做快速路由；第三，LLM 兜底，当匹配置信度低或请求模糊时，调用 LLM 动态分配，并设置超时和降级策略。总结一句：路由是注册表 + 向量匹配 + LLM 兜底的三层漏斗，兼顾准确率和延迟。”

4️⃣ 高频追问 & 应对

追问 1：如果子 Agent 的能力描述经常变化（如新增工具），怎么保证路由不失效？

应对策略：能力声明支持热更新。调度中心维护一个版本号，子 Agent 变更后推送新注册表，调度 Agent 在下一轮请求时重新构建 FAISS 索引。但频繁重建索引有性能开销（百万级向量重建需 1-2 秒），所以实际中采用增量更新：新向量插入 HNSW 图时，只影响局部节点，无需全量重建。同时设置冷却期：同一 Agent 在 5 分钟内最多更新 3 次，防止抖动。

追问 2：LLM 兜底时，如果多个 Agent 都能处理同一个请求（如“查一下苹果公司的股价”），怎么避免冲突？

应对策略：LLM 输出中必须包含 confidence 字段，调度 Agent 取置信度最高的 Agent。但若两个 Agent 置信度接近（如 0.92 vs 0.90），则触发并行执行：同时路由到两个 Agent，取最先返回的结果，另一个结果丢弃。代价是资源浪费，所以只在付费用户或高价值请求上启用。另一种方案是优先级规则：在注册表中定义 Agent 优先级（如金融 Agent > 通用新闻 Agent），LLM 输出相同时按优先级分配。

追问 3：如何评估路由系统的效果？给几个具体指标。

应对策略：核心指标三个：路由准确率（正确 Agent 被选中 / 总请求数，目标 >95%）、平均路由延迟（从请求到分配完成，目标 <50ms，含 LLM 兜底时 <2s）、兜底触发率（LLM 兜底次数 / 总请求数，目标 <10%，过高说明语义匹配能力不足）。辅助指标：用户反馈满意度（路由后用户是否继续追问或投诉）、Agent 负载均衡度（各 Agent QPS 标准差，越小越好）。

5️⃣ 避坑 · 常见错误答法

❌ 只说“用 LLM 判断分给谁”，不提能力注册和语义匹配。 → ✅ 必须强调 LLM 兜底是最后手段，前置的语义匹配和规则路由才是性能保障，否则延迟和成本都不可控。
❌ 认为路由是一次性决策，不考虑负载和健康状态。 → ✅ 必须加入动态负载均衡，否则高并发时单 Agent 过载会导致整体系统雪崩。
❌ 忽略反馈完整流程，认为路由策略固定不变。 → ✅ 必须说明如何用路由日志优化匹配模型和调整阈值，否则系统无法适应新场景。

6️⃣ 简历呼应

如果你有 RAG 项目：从“检索路由”角度切入，类比 RAG 中 Query 到文档的检索，强调多 Agent 路由本质是“能力检索”，可以复用 FAISS 索引和 BM25 混合检索经验。
如果你只做过传统 NLP：用“意图分类 + 实体抽取”类比，强调语义匹配就是多分类任务，但需要处理动态类别（Agent 增减），所以用向量检索而非固定分类器。
如果你是校招无项目：聚焦论文复现，提到“RouteLLM”（2024）或“Agent Routing”相关论文，说明自己理解能力注册和 LLM 兜底的协同，并可以快速实现一个基于 LangChain 的 demo。
《RouteLLM: Learning to Route LLMs with Preference Data》（2024）
《Agent Routing: A Survey of Multi-Agent Systems》（2024）
FAISS 官方文档：HNSW 索引构建与增量更新
LangChain 多 Agent 路由示例：langchain.agents.agent_toolkits 中的 create_agent_executor
《Semantic Search with Sentence-BERT》博客（SBERT 官方）

—— 本场面试完 ——