ruflo 智能体负载均衡：工作窃取、自适应调度与 ruflo Swarm 负载均衡器实现全解析

本文以 ruflo 仓库中的 agent-load-balancer 技能文档为主体，系统讲解 Load Balancing Coordinator 智能体的四大核心机制——工作窃取（Work-Stealing）、动态负载均衡、多级优先队列与多目标资源分配——并对照仓库中 claims 模块的真实 LoadBalancer 服务实现与 MCP 协调工具，梳理从算法伪代码到生产代码的完整落地路径。读完后，你既能理解这套负载均衡方法论的每个关键参数（偷取阈值、老化提升、过载/欠载阈值、平衡分数），也能在仓库源码中定位到真实的调用链与默认配置，用于指导 Swarm 多智能体系统的性能调优。

技能定位：Load Balancing Coordinator 是什么

agent-load-balancer 是 ruflo 中一类"性能优化型智能体技能"，通过 $agent-load-balancer 调用。根据 SKILL.md 的元信息，其画像为：

• 名称：Load Balancing Coordinator
• 类型：Performance Optimization Agent（性能优化智能体）
• 专长：动态任务分配与资源调度
• 性能焦点：工作窃取算法与自适应负载均衡

它解决的核心问题是：当一个 Swarm 中多个 Agent 并行执行任务时，如何让"忙死的 Agent"把任务让给"空闲的 Agent"，避免局部过载拖垮整体吞吐。文档给出了四层能力：工作窃取、动态负载均衡、队列管理与优先级控制、资源分配优化，外加 MCP 集成钩子、高级调度算法（EDF/CFS）和熔断器等配套机制。

核心机制一：工作窃取算法（Work-Stealing）

工作窃取是这套技能的第一核心：空闲的 Agent（thief）主动向任务队列较长的其他 Agent（victim）"偷取"任务，而不是被动等待全局队列分配。文档中给出的实现骨架如下：

// Advanced work-stealing implementation
const workStealingScheduler = {
  // Distributed queue system
  globalQueue: new PriorityQueue(),
  localQueues: new Map(), // agent-id -> local queue

  // Work-stealing algorithm
  async stealWork(requestingAgentId) {
    const victims = this.getVictimCandidates(requestingAgentId);

    for (const victim of victims) {
      const stolenTasks = await this.attemptSteal(victim, requestingAgentId);
      if (stolenTasks.length > 0) {
        return stolenTasks;
      }
    }

    // Fallback to global queue
    return await this.getFromGlobalQueue(requestingAgentId);
  },

  // Victim selection strategy
  getVictimCandidates(requestingAgent) {
    return Array.from(this.localQueues.entries())
      .filter(([agentId, queue]) =>
        agentId !== requestingAgent &&
        queue.size() > this.stealThreshold
      )
      .sort((a, b) => b[1].size() - a[1].size()) // Heaviest first
      .map(([agentId]) => agentId);
  }
};

这段代码体现了工作窃取系统的三个经典设计决策：

1. 双队列体系：每个 Agent 持有 localQueues 中的本地队列（自己优先消费，避免锁竞争），同时存在一个 globalQueue 作为兜底。窃取失败时回退到全局队列，保证任务不会"卡死"。
2. 偷取阈值（stealThreshold）：只有当目标队列长度超过阈值时才被视为合法 victim，避免对只有一两个任务的 Agent 发起无谓的窃取开销。这个参数后续可通过 config-manage 命令在线调整（见"运维命令"一节）。
3. victim 选择策略：按队列长度降序排序（"Heaviest first"），即优先向最繁忙的 Agent 下手。这在分布式调度理论中接近 Cilk 工作窃取调度器的随机化 victim 选择的确定性变体——牺牲一点随机性换取更强的负载均衡确定性。

核心机制二：动态负载均衡与加权公平队列

第二层能力是实时负载均衡：周期性扫描所有 Agent 的容量与实际负载，把过载者的任务迁移给欠载者。文档中的系统骨架：

// Real-time load balancing system
const loadBalancer = {
  // Agent capacity tracking
  agentCapacities: new Map(),
  currentLoads: new Map(),
  performanceMetrics: new Map(),

  // Dynamic load balancing
  async balanceLoad() {
    const agents = await this.getActiveAgents();
    const loadDistribution = this.calculateLoadDistribution(agents);

    // Identify overloaded and underloaded agents
    const { overloaded, underloaded } = this.categorizeAgents(loadDistribution);

    // Migrate tasks from overloaded to underloaded agents
    for (const overloadedAgent of overloaded) {
      const candidateTasks = await this.getMovableTasks(overloadedAgent.id);
      const targetAgent = this.selectTargetAgent(underloaded, candidateTasks);

      if (targetAgent) {
        await this.migrateTasks(candidateTasks, overloadedAgent.id, targetAgent.id);
      }
    }
  },

  // Weighted Fair Queuing implementation
  async scheduleWithWFQ(tasks) {
    const weights = await this.calculateAgentWeights();
    const virtualTimes = new Map();

    return tasks.sort((a, b) => {
      const aFinishTime = this.calculateFinishTime(a, weights, virtualTimes);
      const bFinishTime = this.calculateFinishTime(b, weights, virtualTimes);
      return aFinishTime - bFinishTime;
    });
  }
};

流程可以拆解为"度量 → 分类 → 迁移"三步：calculateLoadDistribution 生成负载分布快照，categorizeAgents 将 Agent 分为过载/欠载两桶，再对每个过载者挑选可迁移任务与目标 Agent 执行 migrateTasks。

其中 scheduleWithWFQ 实现的是加权公平队列（Weighted Fair Queuing）：先按 Agent 能力计算权重，再为每个任务估算"虚拟完成时间"，按虚拟时间升序出队。这与网络领域的 WFQ 思想同源——用虚拟时间轴把不同权重的流映射到同一条公平的时间刻度上，高权重（高能力）Agent 分到的任务会呈现更短的虚拟完成间隔。

值得注意的是，这套"过载/欠载 + 迁移"的抽象在仓库的真实实现中得到了印证。claims 模块中的 LoadBalancer 服务 头部注释明确写出了与文档一一对应的重平衡算法：

1. Calculate average load across swarm
2. Identify overloaded agents (>1.5x average utilization)
3. Identify underloaded agents (<0.5x average utilization)
4. Move low-progress (<25%) work from overloaded to underloaded
5. Prefer same agent type for transfers
6. Use handoff mechanism (not direct reassignment)

也就是说，文档伪代码中的 categorizeAgents / migrateTasks，在生产实现里对应着 detectImbalance() 与基于 handoff 机制的 rebalance()（详见后文"从技能伪代码到生产实现"一节）。

核心机制三：多级队列管理与老化策略

任务并非同等重要——紧急任务不能被低优先级任务长时间阻塞，但低优先级任务也不能永远饿死。文档给出的 PriorityTaskQueue 同时解决这两个矛盾：

// Advanced queue management system
class PriorityTaskQueue {
  constructor() {
    this.queues = {
      critical: new PriorityQueue((a, b) => a.deadline - b.deadline),
      high: new PriorityQueue((a, b) => a.priority - b.priority),
      normal: new WeightedRoundRobinQueue(),
      low: new FairShareQueue()
    };

    this.schedulingWeights = {
      critical: 0.4,
      high: 0.3,
      normal: 0.2,
      low: 0.1
    };
  }

  // Multi-level feedback queue scheduling
  async scheduleNext() {
    // Critical tasks always first
    if (!this.queues.critical.isEmpty()) {
      return this.queues.critical.dequeue();
    }

    // Use weighted scheduling for other levels
    const random = Math.random();
    let cumulative = 0;

    for (const [level, weight] of Object.entries(this.schedulingWeights)) {
      cumulative += weight;
      if (random <= cumulative && !this.queues[level].isEmpty()) {
        return this.queues[level].dequeue();
      }
    }

    return null;
  }

  // Adaptive priority adjustment
  adjustPriorities() {
    const now = Date.now();

    // Age-based priority boosting
    for (const queue of Object.values(this.queues)) {
      queue.forEach(task => {
        const age = now - task.submissionTime;
        if (age > this.agingThreshold) {
          task.priority += this.agingBoost;
        }
      });
    }
  }
}

三个值得注意的设计点：

• 分层队列结构：critical 按截止时间（EDF 语义）排序，high 按优先级数值排序，normal 走加权轮询，low 走公平共享队列——不同等级用不同的公平性定义。
• 硬优先 + 软权重混合调度：critical 非空时绝对优先出队（硬实时语义）；其余等级按 0.3/0.2/0.1 的累计权重做加权随机选择（统计公平语义）。
• 老化机制（Aging）：agingThreshold 与 agingBoost 两个参数控制"排队超过阈值的任务获得优先级加成"，这是防止低优先级任务饿死的经典手段。文档末尾的运维命令示例中 --config '{"stealThreshold": 5, "agingBoost": 10}' 说明这两个参数支持运行时热调。

核心机制四：资源分配的多目标优化

第四层能力处理"给定一组 Agent、一组任务、一组约束，求最优分配"这一组合优化问题。文档给出两条互补路线——启发式与精确约束求解：

// Intelligent resource allocation
const resourceAllocator = {
  // Multi-objective optimization
  async optimizeAllocation(agents, tasks, constraints) {
    const objectives = [
      this.minimizeLatency,
      this.maximizeUtilization,
      this.balanceLoad,
      this.minimizeCost
    ];

    // Genetic algorithm for multi-objective optimization
    const population = this.generateInitialPopulation(agents, tasks);

    for (let generation = 0; generation < this.maxGenerations; generation++) {
      const fitness = population.map(individual =>
        this.evaluateMultiObjectiveFitness(individual, objectives)
      );

      const selected = this.selectParents(population, fitness);
      const offspring = this.crossoverAndMutate(selected);
      population.splice(0, population.length, ...offspring);
    }

    return this.getBestSolution(population, objectives);
  },

  // Constraint-based allocation
  async allocateWithConstraints(resources, demands, constraints) {
    const solver = new ConstraintSolver();

    // Define variables
    const allocation = new Map();
    for (const [agentId, capacity] of resources) {
      allocation.set(agentId, solver.createVariable(0, capacity));
    }

    // Add constraints
    constraints.forEach(constraint => solver.addConstraint(constraint));

    // Objective: maximize utilization while respecting constraints
    const objective = this.createUtilizationObjective(allocation);
    solver.setObjective(objective, 'maximize');

    return await solver.solve();
  }
};

• optimizeAllocation 是多目标遗传算法：以"最小化延迟、最大化利用率、负载均衡、最小化成本"四个目标为适应度，通过种群初始化 → 适应度评估 → 选择 → 交叉变异 → 种群替换的迭代求近似最优解。适合目标冲突、解空间大的场景。
• allocateWithConstraints 是约束规划：把每个 Agent 的分配量建模为 [0, capacity] 区间变量，叠加业务约束后以"最大化利用率"为目标做精确求解。适合约束清晰、需要可证明最优的场景。

从源码结构看，仓库当前把这条路线落地为"基于事件与 handoff 的在线重平衡"（见下文），而非离线批量求解——这符合 Swarm 场景下负载状态持续变化的特点：在线增量调整比周期性全局重排更稳定。

高级调度算法：EDF 与 CFS

文档还收录了两个操作系统级别的经典调度器，用于不同负载形态：

最早截止时间优先（EDF）——面向实时任务的抢占式调度，配套 Liu & Layland 利用率上界的准入控制：

class EDFScheduler {
  schedule(tasks) {
    return tasks.sort((a, b) => a.deadline - b.deadline);
  }

  // Admission control for real-time tasks
  admissionControl(newTask, existingTasks) {
    const totalUtilization = [...existingTasks, newTask]
      .reduce((sum, task) => sum + (task.executionTime / task.period), 0);

    return totalUtilization <= 1.0; // Liu & Layland bound
  }
}

admissionControl 的要点：新任务进入前检查"执行时间/周期"的总利用率是否超过理论可调度上界（严格来说是 n 个任务时的 n(2^{1/n}-1)，趋近 1.0），超界则拒绝准入，从源头避免不可调度状态。

完全公平调度（CFS）——面向通用任务的权重公平调度，用红黑树组织虚拟运行时间：

class CFSScheduler {
  constructor() {
    this.virtualRuntime = new Map();
    this.weights = new Map();
    this.rbtree = new RedBlackTree();
  }

  schedule() {
    const nextTask = this.rbtree.minimum();
    if (nextTask) {
      this.updateVirtualRuntime(nextTask);
      return nextTask;
    }
    return null;
  }

  updateVirtualRuntime(task) {
    const weight = this.weights.get(task.id) || 1;
    const runtime = this.virtualRuntime.get(task.id) || 0;
    this.virtualRuntime.set(task.id, runtime + (1000 / weight)); // Nice value scaling
  }
}

CFS 的精髓在 updateVirtualRuntime：每次调度后虚拟运行时间按 1000 / weight 增量增长——权重越高的任务虚拟时间增长越慢，从而在红黑树中最小值（虚拟时间最小者）持续优先被选中的同时，整体实现按权重比例的 CPU 时间分配。这正是 Linux 内核 CFS 的 nice 值缩放机制的简化映射。

性能优化配套：熔断器模式

在负载均衡的迁移、握手等操作可能因目标 Agent 故障而失败的场景下，文档给出了熔断器实现，避免持续对故障节点发起调用：

class CircuitBreaker {
  constructor(threshold = 5, timeout = 60000) {
    this.failureThreshold = threshold;
    this.timeout = timeout;
    this.failureCount = 0;
    this.lastFailureTime = null;
    this.state = 'CLOSED'; // CLOSED, OPEN, HALF_OPEN
  }

  async execute(operation) {
    if (this.state === 'OPEN') {
      if (Date.now() - this.lastFailureTime > this.timeout) {
        this.state = 'HALF_OPEN';
      } else {
        throw new Error('Circuit breaker is OPEN');
      }
    }

    try {
      const result = await operation();
      this.onSuccess();
      return result;
    } catch (error) {
      this.onFailure();
      throw error;
    }
  }

  onSuccess() {
    this.failureCount = 0;
    this.state = 'CLOSED';
  }

  onFailure() {
    this.failureCount++;
    this.lastFailureTime = Date.now();

    if (this.failureCount >= this.failureThreshold) {
      this.state = 'OPEN';
    }
  }
}

三态机语义清晰：CLOSED 正常放行；连续失败达到 threshold（默认 5 次）切到 OPEN，直接快速失败；timeout（默认 60 秒）后进入 HALF_OPEN，放行一次探测请求，成功则恢复、失败则重新熔断。把它套在 handoffService.requestHandoff 或 attemptSteal 这类跨 Agent 调用上，可以把"某个 Agent 挂了"从隐性长尾延迟变成显性快速失败，让负载均衡器及时把它从候选名单中剔除。

MCP 集成钩子：把负载均衡接入 MCP 工具面

文档定义了负载均衡器与 MCP 工具层的三个集成点：指标采集、重平衡协调、拓扑优化：

// MCP performance tools integration
const mcpIntegration = {
  // Real-time metrics collection
  async collectMetrics() {
    const metrics = await mcp.performance_report({ format: 'json' });
    const bottlenecks = await mcp.bottleneck_analyze({});
    const tokenUsage = await mcp.token_usage({});

    return {
      performance: metrics,
      bottlenecks: bottlenecks,
      tokenConsumption: tokenUsage,
      timestamp: Date.now()
    };
  },

  // Load balancing coordination
  async coordinateLoadBalancing(swarmId) {
    const agents = await mcp.agent_list({ swarmId });
    const metrics = await mcp.agent_metrics({});

    // Implement load balancing based on agent metrics
    const rebalancing = this.calculateRebalancing(agents, metrics);

    if (rebalancing.required) {
      await mcp.load_balance({
        swarmId,
        tasks: rebalancing.taskMigrations
      });
    }

    return rebalancing;
  },

  // Topology optimization
  async optimizeTopology(swarmId) {
    const currentTopology = await mcp.swarm_status({ swarmId });
    const optimizedTopology = await this.calculateOptimalTopology(currentTopology);

    if (optimizedTopology.improvement > 0.1) { // 10% improvement threshold
      await mcp.topology_optimize({ swarmId });
      return optimizedTopology;
    }

    return null;
  }
};

其中 optimizeTopology 的"10% 改进阈值"是一个务实的防抖设计：只有预期改进超过 10% 才真正执行拓扑变更，避免在近似最优的拓扑上空转。

这部分集成在仓库的 MCP 协调工具中确有对应实体。coordination-tools.ts 定义了名为 coordination_load_balance 的 MCP 工具，其 inputSchema 支持 action（get / set / distribute）、algorithm（round-robin / least-connections / weighted / adaptive 四种）与 weights（节点权重表）参数。从 handler 实现看：

• get 返回当前负载均衡配置与节点负载统计（avgLoad / maxLoad / minLoad）；
• set 把算法与权重持久化到协调状态存储（coord store）；
• distribute 按当前算法选节点：least-connections 与 adaptive 选负载最小节点，weighted 按权重选节点，默认 round-robin 取首个活跃节点，选中后递增该节点 load 计数并落盘。

这意味着文档中 scheduleWithWFQ 的"权重 + 完成时间"思路，在工具层以"权重 + 当前连接数"的形式落地为可运维的配置项：你可以先用 get 观察负载分布，再用 set 切换算法与权重，最后用 distribute 验证分发行为。

从技能伪代码到生产实现：claims 模块的 LoadBalancer

前面四节是技能文档中的算法骨架。仓库中还有一处把这些抽象真正落成了带类型、带事件、带默认参数的生产代码——v3/@claude-flow/claims/src/application/load-balancer.ts。对照文档逐项印证，可以看清"技能文档的伪代码 → 工程实现"之间补上了哪些工程细节。

默认参数表

实现中的 DEFAULT_REBALANCE_OPTIONS（L325-L332）给出了每个可调参数的默认值，正好对应文档中"Adjust balancing parameters"一节要调的那些量：

参数	默认值	含义
maxProgressToMove	25	仅迁移进度低于 25% 的 claim，避免迁移快做完的任务
preferSameType	true	优先在同类型 Agent 之间转移（能力匹配）
overloadThreshold	1.5	利用率超过平均值 1.5 倍判定为过载
underloadThreshold	0.5	利用率低于平均值 0.5 倍判定为欠载
maxMovesPerRebalance	10	单次重平衡最多迁移 10 个任务，防止雪崩式抖动
useHandoff	true	走 handoff 机制而非直接改派，保留生命周期与审计轨迹

优先级加权的利用率与平衡分数

文档的 agentCapacities / currentLoads 两本账，在实现里被合并为一次加权计算 calculateUtilization（L712-L734）：claim 按优先级加权（critical: 2.0, high: 1.5, medium: 1.0, low: 0.5），且 blocked 状态的 claim 只按 0.5 系数计入（阻塞中的任务不占满有效算力），最终归一化到 0–1。这比"任务数 / 容量上限"的朴素比值更贴近真实负载——同样 5 个任务，全是 low 优先级和全是 critical 的占用完全不同。

整体平衡度则用变异系数量化：calculateBalanceScore（L742-L761）计算各 Agent 利用率的 1 - (stdDev / mean)，完全均衡时为 1。这恰好对应文档"Performance Metrics"一节中的 Load Distribution Variance KPI——文档用方差描述失衡，实现把方差进一步归一成了可比较的分数。

Handoff 而非直接改派

文档的 migrateTasks 在实现中被刻意替换为 handoffService.requestHandoff(issueId, from, to, reason)（L525-L533），reason 字段自动带上利用率变化（如 redistributing work across swarm (0.92 -> 0.21 utilization)）。源码注释解释了动机："Load balancer uses handoffs (not direct reassignment) to maintain proper claim lifecycle and audit trail"。这是一个典型的工程权衡：直接改派更快，但丢失了任务的接管确认与审计记录；handoff 多一次往返，换来状态机完整性。此外 previewRebalance 通过强制 useHandoff: false 实现"只建议、不执行"的预览模式，方便在真正迁移前先人工审视建议列表。

事件驱动的联动

LoadBalancer 继承自 Node.js 的 EventEmitter，发出三类事件：swarm:rebalanced（重平衡完成，携带迁移结果与新平衡分数）、agent:overloaded / agent:underloaded（越过阈值时触发）。这意味着文档"Integration Points"一节描述的联动（Performance Monitor 消费指标、Memory System 记录历史模式）可以通过订阅这些事件实现。同模块的 domain/events.ts 定义了与之对应的领域事件，tests/events.test.ts 验证事件流转。集成层的 worker-pool.ts 在按负载均衡策略分配工作后也会发出 load-balanced 事件，说明该模式贯穿了协调层到执行层的多个组件。

行为验证

测试文件 load-balancer.test.ts 按 London School TDD 风格对负载计算、重平衡、预览、失衡检测做了行为验证。其配置常量与主实现呼应且略有扩展：imbalanceThreshold: 30（30% 差异触发重平衡）、maxActionsPerRebalance: 10（与默认值一致）、minUtilizationForRebalance: 20（利用率低于 20% 不值得重平衡）、cooldownPeriodMs: 60000（重平衡冷却期，防止高频抖动），以及 priorityWeights: { claimCount: 0.4, utilization: 0.4, queueDepth: 0.2 } 的三维综合评分权重。冷却期（cooldown）这一点在技能文档中未展开，从测试结构看是生产实现对文档方法论的补充——任何自动重平衡机制都需要防抖窗口，否则两个平衡器互相"纠正"会形成震荡。

运维命令

文档给出了完整的 CLI 操作面，围绕 claude-flow 命令族展开。负载均衡相关：

# Initialize load balancer
npx claude-flow agent spawn load-balancer --type coordinator

# Start load balancing
npx claude-flow load-balance --swarm-id <id> --strategy adaptive

# Monitor load distribution
npx claude-flow agent-metrics --type load-balancer

# Adjust balancing parameters
npx claude-flow config-manage --action update --config '{"stealThreshold": 5, "agingBoost": 10}'

性能监控相关：

# Real-time load monitoring
npx claude-flow performance-report --format detailed

# Bottleneck analysis
npx claude-flow bottleneck-analyze --component swarm-coordination

# Resource utilization tracking
npx claude-flow metrics-collect --components ["load-balancer", "task-queue"]

典型操作顺序是：agent spawn 拉起协调者 → load-balance 以 adaptive 策略启动 → agent-metrics 观察分布 → 用 config-manage 热调 stealThreshold / agingBoost → performance-report / bottleneck-analyze 验证效果。其中 --strategy adaptive 与 MCP 工具 coordination_load_balance 的 adaptive 算法枚举相呼应，说明 CLI 与 MCP 工具面共享同一套策略命名。

集成点与可观测性

文档明确了两组集成关系：

与其他优化智能体：Performance Monitor（为均衡决策提供实时指标）、Topology Optimizer（基于负载模式协调拓扑变更）、Resource Allocator（优化 Swarm 内的资源分布）。

与 Swarm 基础设施：Task Orchestrator（接收均衡后的任务分配）、Agent Coordinator（提供 Agent 容量与可用性信息）、Memory System（存储负载均衡历史与模式）。

对应的 KPI 体系包括五项：Load Distribution Variance（跨 Agent 负载均衡度，即实现中的 balance score 的原始度量）、Task Migration Rate（工作窃取频率）、Queue Latency（任务在队列中的平均等待）、Utilization Efficiency（资源利用率相对最优值的比例）、Fairness Index（资源分配公平性）。文档还附带了对应的基准测试骨架：

// Load balancer benchmarking suite
const benchmarks = {
  async throughputTest(taskCount, agentCount) {
    const startTime = performance.now();
    await this.distributeAndExecute(taskCount, agentCount);
    const endTime = performance.now();

    return {
      throughput: taskCount / ((endTime - startTime) / 1000),
      averageLatency: (endTime - startTime) / taskCount
    };
  },

  async loadBalanceEfficiency(tasks, agents) {
    const distribution = await this.distributeLoad(tasks, agents);
    const idealLoad = tasks.length / agents.length;

    const variance = distribution.reduce((sum, load) =>
      sum + Math.pow(load - idealLoad, 2), 0) / agents.length;

    return {
      efficiency: 1 / (1 + variance),
      loadVariance: variance
    };
  }
};

loadBalanceEfficiency 的 efficiency = 1 / (1 + variance) 是一个归一化到 (0, 1] 的实用度量：理想均匀分配时方差为 0、效率为 1，方差越大效率越低。与主实现中"变异系数"思路相比，这里用的是绝对方差，对负载量纲敏感——跨 Swarm 对比时宜优先使用相对度量。

总结：从算法骨架到 Swarm 协调的生产闭环

回到 SKILL.md 的整体脉络，这套负载均衡方法论的分层逻辑可以概括为：

1. 微观层（单 Agent 决策）：工作窃取 + stealThreshold 控制窃取成本，EDF/CFS 决定本地出队顺序，熔断器隔离故障对端；
2. 中观层（队列语义）：多级优先队列 + 老化机制，在"紧急任务硬优先"与"低优任务不饿死"之间取得平衡，WFQ 提供跨 Agent 的公平性；
3. 宏观层（Swarm 级）：周期性 detect → categorize → migrate 重平衡，多目标遗传算法处理批量分配，MCP 钩子把决策暴露给外部工具面。

而仓库中 claims 模块的 LoadBalancer 展示了这一方法论被工程化后的关键取舍：用优先级加权利用率替代朴素任务计数，用 handoff 替代直接改派，用变异系数平衡分数量化目标，用默认参数表（1.5x / 0.5x / 25% / 10 次上限）和冷却期抑制震荡。技能文档提供算法直觉与调参抓手，源码提供可验证的默认值与事件契约，两者结合构成了 ruflo 多智能体 Swarm 中"让正确的 Agent 在正确的时间做正确量的任务"的完整方案。

深入阅读建议从四个入口开始：技能定义 SKILL.md、核心实现 load-balancer.ts、MCP 协调工具 coordination-tools.ts、行为测试 load-balancer.test.ts。