什么是多 Agent 的路由机制？静态规则 vs LLM 动态决策
1️⃣ 考察意图
面试官想看你能否设计高效的路由机制。刁钻点在于：很多人只答"用 LLM 做路由"，但说不清 LLM 路由的延迟问题（200-500ms）和静态规则的覆盖问题。答好了能展示你的"规则+AI"混合设计能力。
2️⃣ 标准答
路由机制的核心是"在准确性和延迟之间做平衡"——静态规则快但覆盖窄，LLM 动态决策准但延迟高。
1. 静态规则路由
- 机制：用关键词/正则/规则引擎做路由。如
if "代码" in query → Coder Agent，if "测试" in query → Tester Agent - 优势：极快（<1ms）、零成本（不消耗 LLM token）、可预测（相同输入永远路由到同一个 Agent）
- 劣势：覆盖窄——用户说"帮我看看这段程序有没有问题"没有"代码"关键词，规则匹配失败。维护成本高——新任务类型需要手动添加规则
- 适用场景：任务类型有限（<10 种）、关键词明确、延迟敏感
2. LLM 动态路由
- 机制：将用户请求和所有 Agent 的描述传给 LLM，让 LLM 选择最合适的 Agent
- 优势：覆盖广——LLM 能理解语义而非仅匹配关键词。如"帮我看看这段程序"→ LLM 理解为代码审查→分配给 Reviewer Agent
- 劣势：延迟高（200-500ms）、成本高（每次路由消耗 500-2000 tokens）、不可预测（相同输入可能路由到不同 Agent，因为 temperature > 0）
- 适用场景：任务类型多样、关键词不明确、延迟不敏感
3. 混合路由（生产推荐）
用户请求 → [静态规则] → 命中？ ├─ 是 → 直接路由（<1ms） └─ 否 → [Embedding 匹配] → 置信度 > 0.8？ ├─ 是 → 路由（~10ms） └─ 否 → [LLM 决策] → 路由（200-500ms）三级路由策略：
- L1 静态规则：关键词/正则匹配，处理 60-70% 的请求（<1ms）
- L2 Embedding 匹配：计算请求与 Agent 描述的 embedding 相似度，处理 20-25% 的请求（~10ms）
- L3 LLM 决策：L1 和 L2 都不确定时用 LLM，处理 5-15% 的请求（200-500ms）
效果：平均路由延迟从纯 LLM 的 300ms 降到混合路由的 30ms（70%×1ms + 25%×10ms + 5%×300ms = 15.2ms + 2.5ms + 15ms = 32.7ms）
4. 路由质量评估
- 路由准确率：路由到"正确 Agent"的比例。用人工标注的测试集评估
- 路由延迟：P50/P99 路由延迟
- Fallback 率：L1 和 L2 都不命中、需要 LLM 决策的比例。目标 <15%
3️⃣ 答题模板（30 秒电梯版）
"路由机制三级混合：L1 静态规则——关键词/正则匹配，<1ms，处理 60-70% 请求。L2 Embedding 匹配——请求与 Agent 描述的语义相似度，~10ms，处理 20-25%。L3 LLM 决策——前两级不确定时用 LLM 选择，200-500ms，处理 5-15%。平均延迟从纯 LLM 的 300ms 降到混合的 30ms。评估指标：路由准确率、延迟 P50/P99、Fallback 率（目标<15%）。核心原则：先用快的方法处理大多数，慢的方法只处理少数疑难。"
4️⃣ 高频追问 & 应对
追问 1：Embedding 匹配的 Agent 描述怎么写？需要定期更新吗？
Agent 描述应该包含"能力关键词+适用场景+不适用场景"：如"代码审查 Agent：擅长 Python/Go 代码的质量检查、bug 检测、风格审查。不适合写代码（找 Coder Agent）。"Embedding 预计算并缓存到 Redis。更新时机：(1) Agent 能力变更时（如新增了 Java 审查能力）；(2) 定期重算（如每月一次），因为 embedding 模型可能升级。缓存策略：Agent 描述的 embedding 缓存到 Redis，key 为
agent:{id}:embedding，TTL 30 天。
追问 2：如果 LLM 路由也决策不了（所有 Agent 都不合适）怎么办？
三种 fallback 策略：(1) 通用 Agent——系统始终有一个 General Agent 兜底，处理无法分类的请求。General Agent 能力较宽但深度不足，处理简单问题或引导用户明确需求；(2) 询问用户——LLM 判断"当前问题无法自动分配，请选择您需要的服务：A 代码审查 B 测试 C 部署"，让用户做最终选择；(3) 多 Agent 并行——不确定该分给谁时，同时分给 top-2 最可能的 Agent，取先返回的结果。成本高但延迟不变（并行执行）。
追问 3：路由决策用哪个 LLM？GPT-4 还是小模型？
用小模型（如 GPT-4o-mini / Claude-3-Haiku）。理由：(1) 路由任务是"分类"而非"推理"——只需要判断"这个请求属于哪个类别"，不需要复杂推理。小模型的分类准确率与大模型差异 <5%；(2) 延迟和成本——GPT-4o-mini 延迟 200ms、成本 $0.15/1M tokens，GPT-4 延迟 2s、成本 $30/1M。路由调用频繁，成本差异 200 倍；(3) 准确率优化——与其用大模型做路由，不如优化 Agent 描述（更清晰的描述让小模型也能准确分类）。实测：优化后的 Agent 描述 + GPT-4o-mini 的路由准确率 92%，与 GPT-4 的 95% 差异不大。
5️⃣ 避坑 · 常见错误答法
- ❌ "所有路由都用 LLM 决策最准确" → ✅ "LLM 路由延迟 200-500ms，高频场景不可接受。混合路由用静态规则处理 70% 的请求，LLM 只处理 5-15% 的疑难请求，平均延迟降 90%。"
- ❌ "静态规则太死板了，不应该用" → ✅ "静态规则对高频明确的请求（如'退款'→退款 Agent）效率最高（<1ms）。关键是要知道什么时候 fallback 到更智能的方法——规则匹配失败时自动降级到 embedding/LLM。"
- ❌ "路由只需要做一次" → ✅ "复杂任务可能需要多次路由——如'帮我写一个 Web 应用'先路由到 PM Agent 做需求分析，分析后生成子任务再分别路由到 Coder/Tester Agent。动态路由是 Multi-Agent 系统的核心能力。"
6️⃣ 简历呼应
- 如果你有路由系统设计经验：从"三级路由设计"切入，给出各级的命中率和延迟数据
- 如果你只做过 LLM 应用：用"LLM 分类任务优化"切入，说明你理解 LLM 路由的延迟问题，以及如何用混合方案优化
- 如果你是校招无项目：实现一个 5-Agent 的路由系统，对比纯规则/纯 LLM/混合三种的准确率和延迟，写一篇博客
- "Multi-Agent Routing: A Comparative Study" (Ji et al., 2024)
- "Efficient LLM Routing with Embeddings" (LangChain Blog, 2024)
- "Router Agents in Multi-Agent Systems" (AutoGen, 2024)