协同强化学习优化测试Harness调度：从单智能体到QMIX实战

1. 从一次“下午四点半卡顿”说起：Harness为什么需要协同

1.1 先明确：这里说的Harness到底是什么

Harness 这个词在技术圈里指代比较杂。它可能是 CI 里的测试执行框架，也可能是模型评测里的“评测器具”，还可能是设备联调用的物理夹具。为了不产生歧义，本文先统一口径：我讲的 Harness 特指测试执行基础设施——一套把测试用例发现、任务编排、执行器调度、结果汇聚串起来的中间层。它不关心单个测试用例怎么写，只关心两个问题：现在该跑什么、让谁去跑。

很多团队早期把 Harness 当成一个“工具脚本”随手搭起来，等到执行节点上到几十个、用例上到几千个，瓶颈才会暴露出来。关键不在于单机执行能力，而在于调度协同：几十个执行器各看各的本地状态，没有一个共享的全局目标。我这次用协同强化学习（Cooperative RL，也就是多智能体强化学习中的合作设定）改造的就是这一层调度逻辑。

1.2 一次典型的“下午四点半卡顿”

模拟项目 X 里维护的 Harness 有 50 个执行节点，日均跑几万条测试。最典型的一天下午，流水线开始莫名其妙地卡顿：关键回归测试排队等了 40 多分钟，而监控面板显示至少有 6 个节点正在重复跑同一个参数变体用例。

翻日志发现三个扎心事实：

• 同一类用例被不同节点重复拉取，结果汇总阶段还要做去重，白耗资源。
• 几个高 CPU 消耗的用例恰好被分到同一台机器，互相拖慢，整个节点直接变成瓶颈。
• flaky 用例失败后反复重试，每次重试都重新排队，把关键路径上的用例越挤越靠后。

这种场景下，静态轮询调度器看起来“每个节点都没闲着”，但实际上整体吞吐在持续恶化。我事后分析，根因非常统一：每个执行器只根据自己局部的空闲状态做决定，没有人对全局目标负责。

1.3 为什么单智能体RL在这里使不上劲

顺手做技术选型时，我先试了单智能体 RL 思路：一个中央调度器，拿所有节点的状态拼接成一个超长向量，一口气输出全部节点的动作分配。仿真里跑了几个星期，效果不理想，原因也很直接：

1. 状态维度爆炸。50 个节点、每个节点十多个特征，拼起来就是 500+ 维输入，样本效率低得吓人。
2. 动作空间呈指数级。每个节点都要从待执行用例里选一个，联合动作空间大到没法枚举。
3. 决策延迟高。中央策略一次推理要处理全网状态，算完再分发到各节点，在线场景根本扛不住几十毫秒以上的延迟。
4. 鲁棒性差。某个节点宕机或者负载突变时，集中式策略的输入分布瞬间变化，策略表现立刻崩盘。

所以单智能体方案只在小规模仿真（节点数小于 5）里能看，放到真实生产环境就是玩具。

2. 把Harness调度翻译成多智能体协同任务

2.1 协同RL的“合作”设定

协同强化学习的关键是“共享目标”四个字。所有执行节点不再各跑各的 KPI，而是共同最大化同一个全局目标函数，这是多智能体强化学习里的合作博弈设定。每个智能体都有自己的局部观测和动作空间，但奖励是团队共享的。

相比单智能体，协同 RL 多出两个核心难点：

• 非平稳性：每个智能体的策略都在持续更新，对其中任意一个智能体来说，其他智能体的行为变化等同于“环境分布”在漂移。今天学到的 Q 值，明天可能因为队友策略变了而完全失真。
• 信用分配：团队奖励拿到了，但到底是哪个节点贡献最大？哪个节点其实在拖后腿？共享奖励本身不携带这个信息，必须靠算法层面去估算。

这两个难点后面会单独展开，这里先建立整体框架。

2.2 Harness组件与MARL元素的映射

我建议所有刚接触这个方向的团队，第一件事不是选算法，而是先画一张映射表，把领域问题老老实实翻译成 MARL 的要素：

这张表背后的核心问题是“哪些信息是全局的、哪些是局部的”。理想设计是：训练阶段允许智能体看到全局信息（完整队列长度、所有节点负载），部署阶段每个智能体只依赖自己手边的局部观测。这就是 CTDE（Centralized Training with Decentralized Execution）框架的出发点，后面章节会详细讲。

2.3 共享奖励与搭便车问题的第一课

给整个团队设一个共享奖励，理论上很美好，实践里的第一个坑就是“搭便车效应”。我见过最典型的表现：某个节点看到其他节点都在跑任务，自己挂机几分钟也不影响团队奖励，梯度一计算，它学到的策略就是“摸鱼”。等到团队奖励下降，它又会发现队友已经干了大部分活，自己继续摸鱼也没有额外惩罚。

为了避免搭便车，奖励设计上必须引入个体贡献项。最直接的办法是给“成功完成重试用例”“主动承接关键用例”等行为额外的个体奖励。更精细的做法是用反事实基线（COMA 算法里的思路）估算“如果这个节点刚才没动作，团队奖励会差多少”，把这个差值作为该节点的优势值。前期我吃过亏，所以这里专门提醒一句：早期版本不要只给一个单纯共享奖励，否则收敛出来的策略大概率是“一群人摸鱼”。

3. 状态空间、动作空间与奖励塑形的实战设计

3.1 局部观测向量怎么构造

观测设计直接决定训练能不能收敛。我最终采用的局部观测是固定长度向量，避免变长结构带来的维度对齐问题：

obs_i = [ queue_len, # 该节点待执行队列长度 cpu_util, # 当前 CPU 负载（0~1） mem_util, # 当前内存负载（0~1） running_count, # 正在跑的用例数 wait_avg, # 队列平均等待时长 flaky_rate, # 最近一小时 flaky 比例 critical_weight, # 队列里关键用例的权重和 last_reward, # 上一时刻团队奖励 dt, # 距离上次决策的时间间隔 ]

这些特征都需要做归一化。队列长度、等待时长的数值范围差异很大，直接用原始值会让神经网络训练震荡。我用的是 min-max 归一化，把每个特征的上下界先固定下来，比如队列长度归一到 0~1，等待时长按最大容忍值 300 秒归一。

有一个容易被忽略的点：不要把全局队列整个塞进局部观测。训练的时候塞了全局信息，上线时执行器拿不到，维度对不上只能回炉重造。正确的做法是训练阶段通过中心化 Critic 补全局信息，执行阶段 Actor 只用局部观测，这一点在算法落地章节会再强调。

3.2 动作空间：离散版先行

动作空间我做过两个版本，差别很大：

• 版本 A（离散）：每个节点从待执行队列里选一个用例 ID，或者选择“等待”“重试最近一次失败用例”。动作数量小，训练稳定，可解释性强。
• 版本 B（连续）：每个节点输出一个资源分配权重向量（0~1），由下游规则翻译成具体操作。表达能力更强，但训练难度显著上升，容易出现探索不足或动作抖动。

对 Harness 这种场景，我的建议是先做离散版本，等基线跑通、影子模式验证没问题，再升级到连续版本。理由很简单：多智能体训练里每增加一个无关维度，收敛时间可能翻倍。不要一上来就追求表达能力的上限。

离散动作里要特别处理“重试”这个动作。flaky 用例反复失败会占用队列位置，我选择把“重试最近一次失败用例”单独设计成一个动作，并且加上次数限制（同一用例最多重试 3 次）。这个限制不在 RL 里做，而在环境层面做硬约束，避免智能体学到无限重试拖时间的策略。

3.3 奖励塑形：权重标定与势函数技巧

团队奖励我设置成以下四项相加：

R = α * throughput_reward # 单位时间完成用例数 - β * avg_wait_penalty # 平均排队等待惩罚 - γ * idle_penalty # 节点空闲惩罚，防止占着资源不干活 + δ * critical_bonus # 及时完成关键用例的额外奖励

这四个权重需要在仿真里反复标定。我的起始经验值是 α=1.0、β=0.5、γ=0.2、δ=2.0，后来因为关键用例过度优先的问题把 δ 降到了 1.0。标定方法是固定住其中三个，只扫描剩下的一个，观察训练后的调度行为是否符合直觉。比如只调 γ 时，如果节点开始频繁申请资源又快速释放，说明 γ 太大，节点在用“假动作”规避空闲惩罚。

这里值得多说一个实用技巧：用势函数塑形（potential-based shaping）而不是直接在奖励里加任务项。直接加奖励容易引入 reward hacking，比如节点学会故意把等待队列预测得很长来骗惩罚项的差分收益。势函数塑形的好处是理论上不改变最优策略，只改变探索过程中的奖励信号，实施起来就是给状态转移加一项 γ(Φ(s') - Φ(s))，Φ 可以是资源利用率这类平滑指标。

4. 算法选型：CTDE框架下的QMIX落地

4.1 为什么必须走CTDE

CTDE 的设计思路和 Harness 的需求几乎一一对应：训练阶段允许集中式 Critic 看到全局信息，也就是队列状态、各节点负载；执行阶段每个 Actor 只依赖自己的局部观测做决策。打个比方：团队训练时教练（全局 Critic）能看到全场跑位，给出价值判断；正式比赛时球员（Actor）只能靠自己视野里的信息临场决定。

这个框架同时解决了非平稳性的一部分问题——训练时 Critic 有全局视角，对全局价值的估计更准，不用盲猜队友策略；部署时又保住了分布式执行的实时性，每个节点本地推理毫秒级完成。

技术路线上有两大分支：

• 价值分解：QMIX、QTRAN 这类算法，把团队 Q 值分解成各个智能体的 Q 值组合。训练时学习混合网络，执行时每个智能体只看自己的 Q 值选动作。
• 策略梯度：MADDPG、MAPPO 这类算法，中心化 Critic + 分布式 Actor，Actor 直接输出策略分布。

4.2 QMIX、QTRAN、MAPPO 怎么选

我实际对比过三个算法，直接给结论表：

Harness 的“选哪个用例”本质是离散决策，所以我最终选了 QMIX 做离散调度。QMIX 的核心思想是：虽然团队 Q 值由混合网络计算，但它约束混合网络对每个智能体的 Q 值做单调映射，这样每个智能体只要最大化自己的局部 Q 值，就能间接最大化团队 Q 值。这个约束在不少场景下过于严格，但对调度类问题通常够用，而且训练稳定很多。

如果要做连续版本（版本 B 的资源分配），再切到 MAPPO，前后两套模型不要混在一个网络里硬套。我在实验里尝试过让 QMIX 输出连续权重，效果很差，最后还是老老实实拆开。

4.3 仿真环境与训练循环搭建

仿真环境我写成了一个事件驱动的简易模拟器，核心结构如下：

class HarnessSimEnv: def __init__(self, n_agents, workload_gen): self.agents = [ExecutorState() for _ in range(n_agents)] self.queue = PriorityQueue() # 全局任务队列 self.workload_gen = workload_gen # 测试到达生成器 self.reward = 0.0 def step(self, actions): for aid, action in actions.items(): if action == "wait": continue test = self.queue.pop(action) self.agents[aid].assign(test) self._tick_time() # 推进时间，回收完成的执行器 reward = self._compute_team_reward() # 按第三节公式计算 obs = self._collect_local_obsets() # 收集每个智能体的局部观测 return obs, reward, done, info def reset(self): self.queue.clear() self.agents = [ExecutorState() for _ in range(len(self.agents))] return self._collect_local_obsets()

训练循环用标准的 PPO 式更新，每批采样 2048 步、16 个并行环境在跑 rollouts。这里有个工程细节不能省：并行环境数量一定要够。单进程仿真太慢，而且样本之间相关性太强，价值分解类算法很容易在局部最优里出不来。我用 16 个并行环境之后，训练曲线明显平滑，稳定性提升了一个档次。

超参经验值可以参考：学习率 3e-4、replay buffer 容量 500K、熵正则系数 0.01、GAE lambda 0.95。训练规模方面，4 个智能体、200 个测试用例、到达率 5/min 的仿真，跑到 1M 时间步大概需要 4~5 小时，普通 CPU 多核就能搞定，不需要 GPU。

5. 训练稳定性与仿真到生产的安全迁移

5.1 域随机化：别让策略背下测试负载

仿真环境做得越真实，训练效果越好——这句话只对一半。完全仿真的成本会爆炸：要模拟网络延迟、物理机差异、测试之间的资源互斥，这些细节对调度策略训练帮助并不大。真正要保真的是三类分布的随机性：测试到达时间的分布、测试运行时长的分布、flaky 失败率的分布。

我把这三个参数都做成了可配置项，并且加了域随机化：每次 reset 时从参数范围随机采样。比如到达率从 3/min 到 7/min 之间随机，用例时长从 20 秒到 50 秒之间随机，flaky 率从 2% 到 10% 之间随机。这样做的原因是防止策略“死记硬背”住某一组固定负载。如果不做域随机化，训练出来的策略换个负载分布就明显退步，这在灰度阶段会非常痛苦。

5.2 非平稳性三板斧：参数共享、冻结锚点、熵正则

训练过程中最典型的现象是：前 100K 步曲线一切正常，到 300K 步开始振荡，损失函数像锯齿。根因就是多个智能体的策略同步变化，Q 值互相追逐，环境分布持续漂移。我处理这个问题用了三个招：

1. 参数共享：所有执行器共享同一套网络参数，只是输入观测不同。这等于把“多个智能体各自学策略”降级成“一组智能体学同一个策略”，非平稳性被大幅削弱。
2. 冻结锚点：训练时固定 10% 的智能体采用上一版已冻结策略，其余 90% 继续更新。对正在学的智能体来说，队友里至少有一部分行为是稳定的锚点，不会全员乱动。
3. 熵正则：在 PPO/QMIX 的 loss 上都加一个小的熵正则项，防止策略过早锁死成某种“互相配合”的退化解。退化解虽然也能拿高奖励，但往往不具备泛化能力。

这三板斧加下来，训练稳定性肉眼可见地改善。如果你发现训练曲线一直在锯齿状抖动，先检查这三条，大概率能救回来。

5.3 影子模式：安全上线的三条路径

真实 Harness 不可能一上来就允许 RL 全量接管调度。我建议的迁移路径分三步走：

1. 影子模式：RL 策略在旁路跑，输出动作但不执行，只记录“如果当时采取了 RL 动作，结果会怎样”。积累一周到两周的对比日志，重点看 RL 建议的动作是否安全、是否符合业务规则。
2. 混合模式：RL 策略的动作经过安全规则过滤后才执行。比如“不得选择预估时长超过 5 分钟的用例进入关键队列”“同一用例不得连续重试超过 3 次”“任何动作的资源申请不得超过节点剩余容量的 70%”。违反规则的动作直接丢弃，回退到传统调度器。
3. 完全接管：只有前两个阶段都验证通过，才让 RL 负责全部决策，同时保留一键回滚开关。

这一步看起来保守，实际上非常值。影子模式阶段能暴露大量观测维度缺失、奖励定义偏差的问题，而且完全不需要冒生产风险。我见过太多团队的失败案例都是跳过了影子模式，直接把 RL 策略上线，结果某个冷门用例触发策略幻觉，整条流水线被带崩。

6. 实测数据、踩坑清单与后续扩展

6.1 仿真与灰度对比数据

在模拟项目 X 的负载下，我把三种方案放在同一批测试负载上做 20 轮对比，取中位数作为结果：

需要特别说明：不同负载分布下收益不完全一样，但从整体趋势看，协同 RL 相对静态调度提升了约 18% 的吞吐，平均等待时间下降约 33%。单智能体 RL 虽然也有提升，但它的训练成本高、鲁棒性差，负载分布一变化就明显退步，这一点在我测试的多个负载场景里反复得到验证。

6.2 我踩过的几个坑

坑一：奖励黑客。前期为了让节点不摸鱼，把 idle_penalty 设得很大，结果节点学会了一种很猥琐的操作：不停申请资源、马上释放，用高频“假动作”规避空闲惩罚，实际吞吐反而下降了。后来我把动作频率也纳入成本，并把空闲惩罚改成“连续空闲时间超过阈值才算”，才算纠正过来。

坑二：QMIX 过估计。价值分解类算法在共享奖励下容易高估全局 Q 值，表现是训练后期吞吐曲线还在往上飘，但真实环境奖励没有同步提升。我在训练里做了两个调整才缓解：降低学习率（从 1e-3 降到 3e-4），扩大 replay buffer（从 100K 扩到 500K）。这两个参数对 QMIX 的过估计问题非常敏感，建议优先排查。

坑三：关键用例过度优先。灰度阶段发现 RL 策略对 critical_bonus 特别敏感，为了追逐关键用例的额外奖励，非关键测试长时间积压。这不是算法 bug，是奖励权重失衡。把 δ 从 2.0 降到 1.0 之后，积压问题恢复正常。

坑四：影子模式数据污染。影子模式下，RL 策略虽然不执行动作，但它的“模拟执行结果”用了真实环境的时间线推进。后来发现真实执行器之间的资源竞争会影响模拟结果，导致影子数据偏乐观。解决方法是把资源竞争项单独建模，避免影子数据失真。

6.3 后续可以怎么扩展

这套协同 RL 思路不只适用于测试 Harness。任何“多个执行器共享队列、共享资源”的基础设施都有迁移的可能：构建集群的任务分发、容器平台的资源调度、数据管线的任务编排等，本质上都是同一套“多智能体共享全局目标”的框架。

如果再往下做，我会优先尝试两个方向。一是把决策频率从固定时间片改成事件驱动——智能体只在有新任务到达时才决策，进一步降低推理开销。二是引入分层结构：上层一个协调者负责目标优先级排序，下层执行器各自跑 QMIX，把调度和执行的粒度解耦。

从整个踩坑过程来看，最关键的教训不是算法选得多高级，而是把领域问题老老实实翻译成 MARL 设定，再用影子模式在真实环境里反复校准观测设计和奖励权重。协同 RL 不是银弹，但当你手头的 Harness 规模大到静态规则已经搭不动的时候，它确实是一条值得认真尝试的路。