文章：腾讯面试官：你的多 Agent 协作，调度 Agent 怎么知道该分给谁？子 Agent 挂了整个任务就废了

P2 · multi_agent · 🏢 腾讯

1️⃣ 考察意图

这道题考察的是多 Agent 系统的工程落地能力，而非单纯背诵概念。面试官想看：你是否能设计一个可调度、可容错、可扩展的协作框架。刁钻点在于：调度 Agent 不是“万能路由器”，它需要动态感知子 Agent 的能力、负载和状态；子 Agent 挂了不是简单重试，而是任务级容错，涉及状态回滚、降级和人工兜底。答好了能展示你对分布式系统 + LLM 编排的交叉理解，以及从 Demo 到生产的坑位意识。

2️⃣ 标准答

核心设计：调度 Agent = 任务分解器 + 能力路由器 + 状态监控器

1. 调度 Agent 如何知道“分给谁”？

能力注册与描述：每个子 Agent 启动时向调度 Agent 注册，提供 function calling schema（如 {name: "order_query", description: "查询订单状态", parameters: {...}}）和负载指标（当前队列长度、平均响应时间）。调度 Agent 维护一个能力索引表，类似 API 网关的路由表。
动态路由策略：不只用 LLM 硬选。采用两阶段决策：
阶段一（规则过滤）：基于任务类型（如 type: "售后"）和子 Agent 的 description 做 BM25 + 语义相似度 匹配，筛出候选集（Top-3）。
阶段二（LLM 精排）：将候选子 Agent 的当前负载、历史成功率、任务复杂度输入 LLM，让 LLM 做最终决策。Trade-off：纯 LLM 路由延迟高（~2s），但准确率高；规则过滤快（~50ms），但泛化差。两阶段结合，90% 任务走规则，10% 模糊任务走 LLM，平均延迟控制在 300ms 内。
负载感知：子 Agent 每 5 秒上报心跳和队列深度。调度 Agent 用加权轮询，优先分配给队列最短、成功率最高的 Agent。坑：子 Agent 上报延迟导致调度到已满的 Agent，解法是主动探测——调度 Agent 在分配前发一个 ping 确认可用性，超时 1s 则跳过。

2. 子 Agent 挂了怎么办？——任务级容错

超时与重试：每个子任务设置 TTL（如 30s）。超时后调度 Agent 先重试 2 次到同一 Agent（可能是网络抖动），失败后切换备用 Agent（相同能力的 Agent 列表）。坑：重试可能导致重复执行（如扣款），解法是幂等性设计——每个子任务带唯一 task_id，子 Agent 执行前检查是否已处理过（用 Redis 存状态）。
状态回滚与补偿：如果子 Agent 失败且无备用，调度 Agent 触发补偿事务。例如：订单 Agent 挂了，已创建的订单需要回滚。调度 Agent 调用补偿 Agent（专门处理回滚），发送 rollback(task_id) 指令。Trade-off：补偿机制增加复杂度，但保证了最终一致性。对于非关键任务（如日志记录），直接降级——跳过该子任务，记录错误，继续执行主流程。
降级与人工兜底：关键子 Agent（如支付）连续失败 3 次，调度 Agent 切换为简化流程（如改为“先下单，后支付”），并通知人工坐席（通过 Webhook 或消息队列）。落地坑：人工兜底需要定义“什么算关键”，建议按任务类型 + 失败次数动态判定，例如：支付类任务失败 2 次即触发人工，日志类失败 5 次才触发。

3. 状态同步与任务分解

共享状态存储：使用 Redis 存储任务状态（pending/running/success/failed），调度 Agent 和子 Agent 都读写同一 key。坑：Redis 单点故障，解法是Redis Cluster + 本地缓存（子 Agent 缓存最近 10 个任务状态，减少读 Redis 频率）。
任务分解：调度 Agent 将复杂任务（如“处理退货”）分解为子任务（查询订单 → 检查库存 → 生成退款单），每个子任务独立调度。分解策略：用 LLM + 模板，例如“退货”任务固定分解为 3 步，但参数（订单号）由 LLM 从用户输入提取。

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

“这个问题我从调度、容错、状态同步三个层面回答。调度层面，我用两阶段路由——规则过滤 + LLM 精排，结合负载感知，避免全量 LLM 决策的延迟。容错层面，我设计了重试、切换备用 Agent、补偿事务和降级四层兜底，关键任务失败触发人工。状态同步用 Redis 加本地缓存，保证一致性。总结一句：多 Agent 协作的核心不是让调度 Agent 全知全能，而是通过分层设计，让系统在部分 Agent 挂掉时仍能优雅降级。”

4️⃣ 高频追问 & 应对

追问 1：如果子 Agent 返回了错误结果（不是挂了，而是答非所问），调度 Agent 怎么发现？

这是语义错误，比挂掉更难检测。解法：调度 Agent 对子 Agent 的输出做结果校验——用 LLM 判断输出是否符合预期 schema（如“订单查询”应返回 order_id 和 status）。如果不符合，标记为“疑似错误”，触发重试（换一个 Agent）。Trade-off：校验增加一次 LLM 调用，延迟 +1s，但避免了错误传播。对于非关键任务，可以跳过校验，直接信任。

追问 2：子 Agent 数量很多（100+），调度 Agent 怎么维护能力索引表？

不能全量加载到 LLM 上下文。解法：分层索引——第一层按领域分（如订单、售后、物流），每个领域一个子索引；第二层用 FAISS 向量库，将子 Agent 的 description 转为 embedding，调度时先做 ANN 检索（Top-10），再交给 LLM 精排。坑：子 Agent 能力描述更新后，embedding 需要增量更新，避免全量重建。建议用 Milvus 或 Qdrant 支持动态插入。

追问 3：如果调度 Agent 自己挂了怎么办？

调度 Agent 是单点，必须高可用。解法：部署主备调度 Agent，共享状态存储（Redis）。主调度 Agent 每隔 5s 写心跳到 Redis，备用 Agent 检测到心跳超时（15s）后接管。坑：主备切换时，正在调度的任务可能丢失。解法：任务状态存储在 Redis，备用 Agent 启动时扫描所有 running 状态的任务，重新分配（幂等性保证不重复执行）。

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

❌ “调度 Agent 直接用 LLM 选子 Agent，简单粗暴。” → ✅ “LLM 选 Agent 延迟高且不可控，应该用规则过滤 + LLM 精排的两阶段策略，90% 任务走规则，10% 模糊任务走 LLM，平衡准确率和延迟。”
❌ “子 Agent 挂了就重试，重试 3 次还不行就报错。” → ✅ “重试要考虑幂等性（避免重复执行），失败后切换备用 Agent，关键任务触发补偿事务或降级，最后才报错。报错也要通知人工兜底，不是直接抛异常。”
❌ “状态同步用数据库就行，简单可靠。” → ✅ “数据库延迟高，不适合高频状态更新。应该用 Redis 做状态存储，配合本地缓存减少读压力。同时要考虑 Redis 单点故障，用 Cluster 或主备模式。”

6️⃣ 简历呼应

如果你有 RAG 项目：从“多 Agent 协作”切入，类比 RAG 中的检索 Agent 和生成 Agent 的调度。强调你如何用两阶段路由（BM25 + 语义检索）分配任务，以及如何用重试和降级处理检索失败。
如果你只做过传统 NLP：用“微服务架构”类比——调度 Agent 像 API 网关，子 Agent 像微服务，容错机制类似断路器模式。强调你理解分布式系统的状态管理和幂等性设计。
如果你是校招无项目：聚焦论文复现——引用 AutoGPT 或 MetaGPT 的调度设计，指出它们的缺陷（无容错、无负载感知），然后给出你的改进方案（两阶段路由 + 补偿事务）。展示你对前沿工作的批判性思考。
《AutoGPT: A Multi-Agent Framework for Task Automation》——了解基础调度逻辑
《MetaGPT: Meta Programming for Multi-Agent Collaboration》——学习任务分解和角色分配
《Building Resilient Multi-Agent Systems with Circuit Breaker Pattern》——容错设计模式
《FAISS: A Library for Efficient Similarity Search》——子 Agent 能力索引的向量检索方案
《Redis Sentinel and Cluster for High Availability》——调度 Agent 高可用实践

—— 本场面试完 ——