Agent 的负载均衡策略有哪些？如何选择
1️⃣ 考察意图
面试官想看你对负载均衡算法的系统性理解。刁钻点在于：很多人只答"轮询"和"最少连接"，但说不清"能力匹配"和"预测调度"的实现细节。答好了能展示你的分布式系统 + 机器学习的交叉能力。
2️⃣ 标准答
五种负载均衡策略，从简单到复杂：
1. 轮询（Round Robin）
- 机制：维护 Agent 列表，按顺序轮流分配
- 复杂度：O(1)
- 适用：Agent 能力同构、任务难度均匀
- 局限：不考虑负载差异——某个 Agent 正在处理大任务，新任务还是会分配给它
2. 加权轮询（Weighted Round Robin）
- 机制：按 Agent 的
max_tasks（容量）做加权。容量大的 Agent 分配更多任务 - 复杂度：O(N)（需遍历计算权重）
- 适用：Agent 能力同构但容量不同（如 GPT-4 Agent max 3 并发，GPT-4o-mini max 10 并发）
- 实现：用平滑加权轮询算法（Nginx 用的算法），避免集中分配
3. 最少连接（Least Connections）
- 机制：选择当前
active_tasks最少的 Agent - 复杂度：O(N)
- 适用：Agent 处理速度不同——快的 Agent 自动获得更多任务
- 实现：用 Redis Sorted Set（score=active_tasks）实时排序，取 score 最小的
- 局限：不考察能力匹配——可能把代码任务分配给文档 Agent
4. 能力匹配（Capability-Based）
- 机制：根据任务的
required_capabilities匹配最擅长的 Agent，在匹配的 Agent 中选负载最低的 - 复杂度：O(N×M)（N 个 Agent × M 个能力维度）
- 适用：Agent 能力异构
- 实现：三级匹配——精确匹配（capabilities 集合包含）→ embedding 相似度 → LLM 决策。匹配后用最少连接做负载均衡
- 局限：匹配计算开销大。优化：缓存最近匹配结果 + 预计算 embedding
5. 预测调度（Predictive Scheduling）
- 机制：基于历史数据预测每个 Agent 完成任务的时间，选择预计最快的
- 复杂度：O(N)（预测计算）+ 模型推理开销
- 适用：任务类型重复、有历史数据
- 实现：用线性回归/梯度提升树预测
estimated_time = f(task_type, agent_id, current_load, time_of_day)。特征包括任务类型、Agent ID、当前负载、历史平均完成时间、时间段 - 局限：冷启动问题——新 Agent 没有历史数据。解法：新 Agent 用能力匹配策略，积累 10+ 次任务后切换预测调度
策略选择决策树：
Agent 能力是否同构？**├─ 是 → Agent 处理速度是否不同？ │ ├─ 是 → 最少连接 │ └─ 否 → 轮询 └─ 否 → 有历史数据吗？ ├─ 是 → 预测调度 └─ 否 → 能力匹配 + 最少连接
3️⃣ 答题模板（30 秒电梯版）
"五种负载均衡策略：轮询（O(1)，同构Agent）、加权轮询（按容量加权，异构容量）、最少连接（选active最少的，速度不同时用）、能力匹配（三级匹配+最少连接，异构能力时用）、预测调度（历史数据预测完成时间，有数据时最优）。选择决策树：同构→速度不同→最少连接；同构→速度相同→轮询；异构→有历史→预测调度；异构→无历史→能力匹配。核心：先匹配能力再做负载均衡。"
4️⃣ 高频追问 & 应对
追问 1**：预测调度的模型怎么训练？特征工程怎么做？
特征：(1) 任务特征——task_type（编码/测试/审查）、task_complexity（简单/中等/困难）、input_size（输入长度）；(2) Agent 特征——agent_id、agent_model（GPT-4/mini）、agent_load（当前并发数）；(3) 环境特征——time_of_day（高峰期慢）、api_latency（当前API延迟）。模型：用 LightGBM（特征重要性可解释、训练快、推理 <1ms）。训练数据：收集过去 1000+ 次任务的
{features, actual_time}。评估：MAE（平均绝对误差），目标 < 实际时间的 20%。冷启动：新 Agent 用同类 Agent 的平均时间做初始预测。
追问 2：负载信息怎么实时维护？Agent 处理完任务后怎么通知调度器？
两种方式：(1) 推送——Agent 完成任务后主动调用
scheduler.update_load(agent_id, delta=-1)。实时性好但依赖 Agent 的可靠性（Agent 崩溃则不通知）；(2) 拉取——调度器每 5 秒轮询所有 Agent 的状态。可靠性好但延迟高（最多 5 秒延迟）。生产建议：推送为主 + 拉取为辅——Agent 推送实时状态，调度器每 30 秒做一次全量同步（修正推送遗漏）。用 Redis Sorted Set 存储active_tasks，INCR/DECR 是原子操作。
追问 3：如果所有 Agent 都过载了怎么办？
三级降级策略：(1) 请求排队——新任务进入优先级队列等待，不拒绝但告知用户"预计等待 X 分钟"；(2) 模型降级——过载时切换到更快的模型（如 GPT-4→GPT-4o-mini），牺牲质量保证可用性。用户可见"当前使用快速模式"提示；(3) 拒绝请求——队列超过阈值（如 100 个等待任务）时拒绝新请求，返回"系统繁忙请稍后"。关键设计：降级策略应该是渐进的——先排队→再降级→最后拒绝，而非直接拒绝。
5️⃣ 避坑 · 常见错误答法
- ❌ "负载均衡就是 Nginx 那套" → ✅ "Agent 负载均衡比 Web 负载均衡复杂——需要考虑能力匹配（不同 Agent 擅长不同任务）和任务依赖（DAG 调度），而非简单的流量分发。"
- ❌ "用最少连接就够了" → ✅ "最少连接不考察能力匹配，可能把代码任务分给文档 Agent。应该先做能力匹配筛选，再在匹配的 Agent 中用最少连接。"
- ❌ "预测调度太复杂，不值得" → ✅ "预测调度的收益在于减少任务完成时间 15-25%（选择最快的 Agent 而非最空闲的）。对于高频任务场景（如客服），这个收益显著。"
6️⃣ 简历呼应
- 如果你有负载均衡经验：从"策略对比和效果量化"切入，描述你实现的负载均衡系统和不同策略的效果数据
- 如果你只做过单 Agent：用"单 Agent 无负载问题 vs 多 Agent 的负载均衡需求"切入
- 如果你是校招无项目：实现一个 5-Agent 的负载均衡器，对比 5 种策略的 Makespan 和利用率，写一篇博客
- "Load Balancing in Distributed Systems" (Cardellini et al., 1999)
- "Predictive Scheduling for Multi-Agent Systems" (Ji et al., 2024)
- "Nginx Smooth Weighted Round Robin Algorithm" (Nginx, 2018)