← 返回 2026-05-13

EVOCHAMBER:个体、团队、群体三尺度的多智能体测试时协同进化框架 EVOCHAMBER: Test-Time Co-evolution of Multi-Agent System at Individual, Team, and Population Scales

Yaolun Zhang, Tianyi Xu, Shengyu Dai, Zhenwen Shao, Qingyun Wu, Huazheng Wang 📅 2026-05-11 👍 11 2026-07-13 08:36
LLM Agent 多智能体系统 测试时进化 知识迁移 群体智能

训练免费框架,让多智能体在测试时三尺度协同进化。

前置知识

Test-Time Evolution(测试时进化)

指模型在不更新梯度参数的情况下,仅通过积累上下文、记忆与经验来提升任务表现的方法。代表性工作如 Reflexion 通过自我反思积累经验、ExpeL 从历史轨迹中提炼可复用经验。该范式的优势是无需训练、可与任意 LLM 兼容,但传统方法主要针对单智能体设计。

EVOCHAMBER 是测试时进化范式向多智能体场景的扩展,理解单智能体进化的局限是把握本文动机的关键。

Multi-Agent System(多智能体协作系统)

由多个 LLM 实例分别扮演不同角色、通过特定通信模式协作完成任务的系统。常见结构包括 AutoGen 的角色对话、MetaGPT 的 SOP 流水线、多智能体辩论(Multi-Agent Debate)、Generator-Critic 生成-评判、任务分解(Decompose)等。团队的结构选择对最终质量影响巨大。

本文的核心论点是多智能体进化≠单智能体进化的复制,需要新的设计维度(谁协作、怎么协作、知识如何流动)来描述。

EWMA(指数加权移动平均)

一种递归更新的统计量,形式为 $q_i(z) \leftarrow (1-\alpha) q_i(z) + \alpha r_t$,其中 $\alpha$ 决定新观测的权重。相比简单移动平均,EWMA 对非平稳序列更敏感,能更快反映分布变化。

EVOCHAMBER 用 EWMA 维护每个智能体在每个 niche(子领域)上的能力估计 $q_i(z)$,因为能力是随经验与协作者演化的非平稳量。

Specialization(专精化)

在多智能体语境下,指原本同质的智能体在长期任务流中逐渐分化、形成不同专长的过程。专精化通常带来更高效的协作,但也带来协调成本与冷启动问题。

专精化是 EVOCHAMBER 声称能产生的涌现现象(4-5 个稳定 niche 专家自发出现),是验证多智能体进化是否真实发生的核心证据。

Asymmetric Knowledge Transfer(非对称知识迁移)

与对称广播(所有智能体接收相同信息)相反,仅将知识从特定源智能体路由到特定目标智能体的机制。在多智能体中常用「差量定位」思路:只把洞察发给能力低于池中位数的智能体,避免淹没强项。

非对称迁移是 EVOCHAMBER 与 MemCollab(对称共享)的关键区别,是消融实验中下降最显著(-10.8%)的组件。

研究动机

在持续异构任务流上部署 LLM 多智能体系统时,理想情况是系统能随经验持续改进:早期突破应能启发后续任务,重复出现的任务类型应被路由给最合适的智能体。然而现有测试时进化方法存在两个根本缺陷:一是单智能体方法(如 Reflexion、ExpeL、EvoMem)只演化单个智能体的上下文与记忆,无法让一个智能体的学习迁移到另一个,错过了在低成功率场景下尤其关键的交叉学习机会;二是对称共享方法(如 MemCollab)把所有智能体的经验蒸馏后无差别地广播给所有成员,每个智能体都得到相同的记忆,抹杀了由个体专长形成的协作价值。以 Hard Math Stream 为例,单智能体 Qwen3-8B 仅 0.298 准确率,MemCollab 也只有 0.484,大量失败经验在智能体之间无法定向流动。

本文的目标是本文的目标是提出一个完全无需梯度更新的训练免费框架 EVOCHAMBER,让多智能体系统在测试时同时在三个尺度上协同进化:个体尺度(每个智能体积累私有经验与 niche 能力估计)、团队尺度(按 niche 条件化组队并在线选择协作结构)、群体尺度(任务间在智能体之间非对称迁移知识、并通过 fork/merge/prune/genesis 等生命周期算子编辑池组成),从而在异构任务流上显著超越现有测试时基线,并自发涌现出任何单智能体学习者无法表达的 niche 专精化结构。

与已有工作不同的是,现有工作要么停留在单智能体范式(EvoMem、Reflexion),要么用对称广播混淆专长(MemCollab),要么依赖 RL 微调(CoMAS、MAPoRL、MAE),要么冻结离线搜索的图结构(AFlow、EvoMAC)。EVOCHAMBER 抓住了被这些工作共同忽略的一个点:多智能体系统的可演化状态比单智能体严格更丰富——它包含「谁协作」「怎么协作」「知识如何在群体中流动」这三个无单智能体对应的维度,而现有方法没有同时激活这三个维度。本文通过 CODREAM 协议和 lifecycle 算子,把这三个维度的演化统一在一个无需训练的框架里,并观察到涌现专精化这一结构性现象。

核心方法

EVOCHAMBER 的直觉可以类比为「一个不断自我重组的专家组」:20 个初始完全相同的 LLM 智能体像新入职的同事一样,面对源源不断的新任务,先各自积累经验,再根据各自擅长的子领域(niche)自动分化成几个稳定的「专家」。每次来新任务时,系统挑选当前 niche 最强的「锚点」、与锚点互补的「补位」、以及负责探索未充分参与任务的「侦察」三个角色组成三人小组;小组组长(锚点)再根据自己的元经验,在投票、辩论、生成-评判、分解四种协作结构中选一种完成任务。如果小组整体失败,触发 CODREAM 后置协议,让成员共同反思、对比成功与失败轨迹、提出假设、互相质疑、最终结晶成结构化洞察,并把这些洞察「非对称地」注入 niche 能力低于池中位数的智能体。每 10 个任务,系统还会检查池的健康状况:对表现过载的智能体 fork 一个子分支(专精化)、对冗余的合并、对持续低迷的裁掉、对出现新 niche 但无人覆盖的则通过 genesis 重新播种。整套机制不更新任何模型权重,全部通过 prompt 与状态簿记实现。

EVOCHAMBER 的核心创新是把多智能体系统的可演化状态形式化分解为三部分:$\theta_{MAS}^t = \{(C_i^t, M_i)\}_{i \in P^t} \oplus (T^t, L^t) \oplus (\Sigma^t, \Omega^t, P^t)$,其中第一项是个体记忆、第二项是当前任务的团队组成与协作结构、第三项是跨任务的群体级簿记(成对协同度 $\sigma_{ij}(z)$、风格重叠 $\omega_{ij}$、智能体池 $P^t$ 本身)。与已有方法的本质区别有三:(1) 团队选择用「锚点 + 补位 + 侦察」三角色分解而非按总分排序,避免强智能体垄断任务、多样性退化;(2) 协作结构 $L^t$ 由锚点通过 LeadLearn 在线选择(维护一个 (团队画像, 任务画像, 结构, 结果, 反思) 的元经验库,按相似度检索后注入 prompt 决策),而非固定或离线搜索;(3) 知识流动是非对称且差量定位的——CODREAM 把成功者的洞察「结晶」为带 niche 标签与层级(任务局部 / 子领域 / 跨领域)的结构化洞察,只写入 niche 能力低于池中位数的智能体,既避免了对称广播抹杀专长,又让强项更强、弱项被定向补齐。这三点一起,产生了从同质初始池中自发涌现 4-5 个稳定 niche 专家的涌现专精化现象,作者在三个种子下都复现了这一模式(虽然具体哪个智能体成为专家是路径依赖的)。

方法步骤详情

EVOCHAMBER 的单任务循环(solve-evolve loop)包含 5 步。第 1 步——团队组建:对当前任务 $t$ 及其 niche 标签 $z_t$,先选锚点 $a_t = \arg\max_i q_i(z_t)$,再按 $c_t = \arg\max_i [\lambda_q q_i(z_t) + \lambda_\sigma \sigma_{i,a_t}(z_t) + \lambda_\omega (1-\omega_{i,a_t})]$ 选补位(兼顾 niche 能力、与锚点协同度、与锚点风格差异),最后按 $s_t = \arg\max_k [\lambda_u u_k(z_t) + \lambda_d (1-\bar{\omega}_{k,\{a_t,c_t\}})]$ 选侦察(奖励参与不足的智能体以保证探索)。第 2 步——结构选择:锚点作为 leader,将当前 (niche 标签, 团队能力画像) 编码为查询向量 $\xi_t$,从共享元经验库中按余弦相似度检索 top-k 条历史,条件化 LLM 决策协作结构 $L_t \in \{\text{voting, debate, generator-critic, decompose}\}$。第 3 步——执行与奖励:团队按 $L_t$ 协作产生答案,得分 $r_t \in [0,1]$。第 4 步——簿记更新:所有成员用 EWMA 更新 $q_i(z_t)$ 与协同度 $\sigma_{ij}(z_t)$,重算风格重叠 $\omega_{ij}$,leader 把 (team 画像, task 画像, $L_t$, $r_t$, 反思) 追加到 LeadLearn 库;若 $r_t < \theta$ 或成员分歧大,触发 CODREAM。第 5 步——群体层操作:每 $\tau=10$ 任务执行 fork(top 10% 表现者克隆并突变 persona)/ merge(profile 余弦相似度 > 0.95 且都积累了 ≥10 任务则合并去重)/ prune(连续 ≥10 任务低于池均值 0.8 倍的裁掉)/ genesis(池 < 15 或出现 niche 亲和度 < 0.4 的新任务类型时播种新智能体)。CODREAM 本身是 5 阶段反思管线:Reflect(每个成员私下诊断自己哪里对哪里错)→ Contrast(把失败成员与成功者配对,提取 delta)→ Imagine(把 delta 转化为带 niche 标签的假设策略)→ Debate(成员互相批评,淘汰弱假设)→ Crystallize(把幸存假设固化为带层级(任务局部/子领域/跨领域)+ niche 范围的洞察),再通过「低于池中位数」的差量门控写入对应智能体的经验库。

技术新颖性

EVOCHAMBER 的技术新颖性体现在四个层面。第一个层面是「三尺度状态分解」本身:它把多智能体可演化状态从单智能体的 $(C, M)$ 严格扩展为个体 + 团队 + 群体三段式张量积,并证明任何只激活其中子集的方法都存在系统性盲区(单智能体方法错过跨智能体学习,对称广播抹杀专长,固定团队结构错过动态结构搜索)。第二个层面是「三角色组队」与协同度+多样性双重约束:与简单地按总分排序相比,侦察角色的 $u_k(z_t) = 1/(1+n_k(z_t))$ 设计确保每个智能体定期获得任务经验,避免池崩溃到少数几个 dominant 成员。第三个层面是 LeadLearn 的元经验库:把 (team 画像, task 画像, 结构, 结果, 反思) 作为元知识累积,让 leader 角色随锚点轮换而分布式学习,避开了单独的元控制器。第四个层面是 CODREAM 的非对称差量路由:用五阶段反思管线(Reflect→Contrast→Imagine→Debate→Crystallize)把成功轨迹与失败轨迹的 delta 固化为带 niche 标签与层级的结构化洞察,再只发给低于池中位数的智能体,这种「既保留强项又定向补弱」的设计既解决了 MemCollab 的对称广播问题,也解决了 EvoMem 的孤岛问题。

Overview of EVOCHAMBER. Starting from a pool of N identically initialized agents (individual level), a niche-conditioned selector assigns three functional roles, anchor, complement, and scout, and a leader-learned policy selects one of four collaboration structures. The team outcome is attributed as a shared reward (team level, intra-task). Between tasks, asymmetric transfer (CODREAM) routes insights from high-fitness to deficit agents, and lifecycle operators fork, merge, prune, and seed new agents to edit pool composition (population level, inter-task).
Figure 1: Overview of EVOCHAMBER. Starting from a pool of N identically initialized agents (individual level), a niche-conditioned selector assigns three functional roles, anchor, complement, and scout, and a leader-learned policy selects one of four collaboration structures. The team outcome is attributed as a shared reward (team level, intra-task). Between tasks, asymmetric transfer (CODREAM) routes insights from high-fitness to deficit agents, and lifecycle operators fork, merge, prune, and seed new agents to edit pool composition (population level, inter-task).

实验结果

EVOCHAMBER 在三个异构任务流和两个模型族上系统性地刷新了所有基线。在 Hard Math Stream(Qwen3-8B,382 题)上,整体准确率达到 0.639,相对最强基线 MemCollab(0.484)提升 32% 相对值、相对单智能体(0.298)翻倍多;最难的 AIME'24 子集从 0.267 提升到 0.433,绝对提升 16.6 个百分点。在 Hard Code Stream(Qwen3-8B,422 题)上,整体 0.757;其中 MBPP+ 已在 0.85 左右饱和,但 CodeContests 子集从单智能体的 0.068 提升到 0.352,5× 提升,且比 SC (k=5) 的 0.198 高 1.8×。在 AFlow-Stream(六个领域 600 题顺序块)上,整体 0.871,超过 EvoMem (0.840) 和 MemCollab (0.832),在六个领域中 5 个取得最佳或并列最佳,MATH 与 MBPP 提升最大。跨 backbone 验证(GPT-4.1-mini)显示同一组超参在 Hard Math 上把单智能体从 0.675 提升到 0.796(+10.7pp),在 AFlow 上从 0.869 提升到 0.888(+1.9pp,相对提升较小是因为 GPT-4.1-mini 的 SA 基线已经很高,留给提升的空间有限)。消融实验(AFlow-Stream)把每个创新点逐个关掉:去掉 niche 条件化选择器掉 2.4pp,去掉 LeadLearn 强制 voting 掉 3.0pp,去掉 CODREAM 掉 10.8pp——后者是单点最大下降,证实非对称跨智能体迁移是集体学习的主要驱动力。任务流顺序鲁棒性方面,对 Hard Math Stream 跑两个不同种子的随机排列,EVOCHAMBER 不降反升(0.655 与 0.662 vs 默认顺序 0.639),排除了「有利的课程顺序」作为增益来源。池规模敏感性方面,N=3 与 N=20 的最终差距仅 1.1pp,因为生命周期算子会把池调到相近的有效规模(N=3 长到 8、N=20 收缩到 9)。最重要的是涌现现象:从 20 个相同初始化的智能体出发,4-5 个稳定的 niche 专家在不同随机种子下都自发出现,三个种子的平均特化指数 0.123 ± 0.008,唯一锚点使用数 38 ± 5,但具体哪个智能体成为哪个 niche 的专家是种子依赖的——这种「模式种子无关、身份种子依赖」是单智能体学习者根本无法产生的结构性签名。

Evolution levels activated by representative methods. EVOCHAMBER is the first to activate all three levels online without training.
Table 1: Evolution levels activated by representative methods. EVOCHAMBER is the first to activate all three levels online without training.
Hard Math Stream accuracy on Qwen3-8B. math_hard: 262 MATH Level 4/5; AIME'22–'25: 30 problems each; Overall: micro-average over 382 tasks.
Table 2: Hard Math Stream accuracy on Qwen3-8B. math_hard: 262 MATH Level 4/5; AIME'22–'25: 30 problems each; Overall: micro-average over 382 tasks.
Accuracy on Hard Code Stream and AFlow-Stream. The HumanEval column is omitted from Hard Code as all methods score 1.000; Overall is the micro-average over all 586 tasks including HumanEval.
Table 3: Accuracy on Hard Code Stream and AFlow-Stream. The HumanEval column is omitted from Hard Code as all methods score 1.000; Overall is the micro-average over all 586 tasks including HumanEval.
Cross-backbone validation on the Hard Math Stream (top) and AFlow-Stream (bottom) under GPT-4.1-mini. The same hyperparameter configuration is used across both backbones and both streams.
Table 4: Cross-backbone validation on the Hard Math Stream (top) and AFlow-Stream (bottom) under GPT-4.1-mini. The same hyperparameter configuration is used across both backbones and both streams.
(a) Ablation on AFlow-Stream: each row disables one of the method-level innovations EVOCHAMBER introduces, mapped to the Method subsection that describes it. (b) Hard Math Stream under two random task permutations.
Table 5: (a) Ablation on AFlow-Stream: each row disables one of the method-level innovations EVOCHAMBER introduces, mapped to the Method subsection that describes it. (b) Hard Math Stream under two random task permutations.
Positioning of EVOCHAMBER against representative prior methods. ✓= fully satisfied; × = not satisfied; ◦= partially satisfied; — = not applicable.
Table 8: Positioning of EVOCHAMBER against representative prior methods. ✓= fully satisfied; × = not satisfied; ◦= partially satisfied; — = not applicable.
Four signals of pool co-evolution on the Hard Math Stream with Qwen3-8B, 382 tasks, seed 42. (a) Expert × niche anchor counts, column-normalized. (b) Cumulative anchor count per expert across the stream. (c) CODREAM anchor → recipient flow matrix. (d) Rolling-window W=32 anchor share per expert (top) and pool-level specialization index $1 - H(A_{anchor}|t)/\log N$ (bottom).
Figure 3: Four signals of pool co-evolution on the Hard Math Stream with Qwen3-8B, 382 tasks, seed 42. (a) Expert × niche anchor counts, column-normalized. (b) Cumulative anchor count per expert across the stream. (c) CODREAM anchor → recipient flow matrix. (d) Rolling-window W=32 anchor share per expert (top) and pool-level specialization index $1 - H(A_{anchor}|t)/\log N$ (bottom).
查看结构化数据
任务指标本文基线提升
Hard Math Stream 整体(Qwen3-8B) 准确率(EM) 0.639 MemCollab 0.484 / SA 0.298 +32% 相对(vs MemCollab),+114% 相对(vs SA)
Hard Math Stream - math_hard 子集 准确率(EM) 0.763 MemCollab 0.603 / SA 0.374 +16.0pp / +38.9pp
Hard Math Stream - AIME'24 子集 准确率(EM) 0.433 MemCollab 0.267 / SA 0.133 +16.6pp / +30.0pp
Hard Code Stream - CodeContests 子集 pass@1 0.352 SC(k=5) 0.198 / SA 0.068 +15.4pp / +28.4pp(约 5× vs SA)
AFlow-Stream 整体(Qwen3-8B) F1/准确率 0.871 EvoMem 0.840 / MemCollab 0.832 / SA 0.819 +3.1pp / +3.9pp / +5.2pp
Hard Math Stream(GPT-4.1-mini 跨 backbone) 准确率(EM) 0.796 MemCollab 0.764 / SA 0.675 +3.2pp / +12.1pp
AFlow-Stream(GPT-4.1-mini) F1/准确率 0.888 MemCollab 0.866 / SA 0.869 +2.2pp / +1.9pp
消融 - 去掉 CODREAM(AFlow-Stream) F1/准确率 0.763(去除后) EVOCHAMBER 完整 0.871 -10.8pp(消融掉后)
消融 - 强制 voting(AFlow-Stream) F1/准确率 0.841(去除后) EVOCHAMBER 完整 0.871 -3.0pp
CODREAM 隔离实验(30 题 AFlow math 子序列) 准确率 0.700(完整) 无 CODREAM 0.633 = SA 0.633 +10.5% 相对,纯靠跨智能体迁移贡献

局限与改进

作者在附录 A 中坦承了几个局限。第一,只验证了两个模型族(Qwen3-8B 与 GPT-4.1-mini),更多架构(Claude、Llama、DeepSeek)的迁移性有待检验;不过由于方法完全在 prompt 层面运作,没有架构特定组件,作者认为应可迁移。第二,推理成本约为单智能体的 3.6×,对延迟敏感场景可能过于昂贵;但需要指出 EVOCHAMBER 比 SC (k=5) 用 72% 的 token 预算却更高准。第三,生命周期算子依赖在所有任务流上未经调优的固定阈值(merge cosine 0.95、prune 0.8× 池均值 10 任务、genesis 池规模 < 15),理想情况应通过元学习自动适配。我的独立观察还包括:(a) 自一致性基线在 AIME 上崩溃到 0.067,是因为 5 个独立智能体 20% 准确率下多数投票的正确率只有约 5.8%,EVOCHAMBER 通过结构选择规避了这个问题,但反过来也说明「在低基线准确率下多数投票本身有害」这一发现比 EVOCHAMBER 本身的相对提升更值得反思;(b) 作者在 Case Study 中观察到 AIME 阶段的 CODREAM 触发 7 次但贡献边缘——4 次在 AIME'22、3 次在 AIME'23、零次在 AIME'24 与 AIME'25,原因是 AIME 阶段基线准确率过低,团队无成功轨迹可蒸馏,结晶出来的是「从文本提取数值」这类元建议而非数学技巧,这是 CODREAM 内在的「需要至少一个成功成员」机制的设计代价;(c) N=20 是个相当大的池,多数时候只有 9 个智能体被频繁调用,意味着大部分算力浪费在被动维护上。

独立分析的弱点

从工程和研究两个角度看,EVOCHAMBER 至少有以下几点可以改进。第一,池规模与算力浪费:当 N=20 实际只激活 9 个时,超过一半的 prompt 路由与元经验簿记是无用功;可以引入「冷热池」分级,让未激活智能体进入低频更新模式,将推理成本压缩到接近 k=3 单次调用的水平。第二,CODREAM 的失败模式处理:在 AIME 阶段基线准确率过低时,团队整体失败导致无成功轨迹可蒸馏,当前实现仍会触发并产生无意义的元建议;可以加一个「团队是否至少产生过一个部分正确轨迹」的预检,若无则跳过 CODREAM 直接转 genesis 探索新 persona。第三,LeadLearn 的元经验库共享设计:所有智能体共享一个 LeadLearn 库,但每个智能体作为 leader 时检索的是同样的元经验,可能让 leader 决策高度同质化;可以让每个智能体维护一个自己的元经验子集,按 niche 或风格聚类,提高 leader 决策的多样性。第四,niche 标签依赖外部元数据:当前 Hard Math、Hard Code、AFlow-Stream 都需要预先给任务打 niche 标签,这在实际部署中不现实;可以用任务嵌入的在线聚类自动发现 niche,或用 few-shot 任务描述让 LLM 自报 niche。第五,差距在 GPT-4.1-mini AFlow 上只有 1.9pp,提示当基线本身就很强时,三尺度进化的边际收益急剧衰减——这一点应在论文中更明确地讨论,以避免读者高估方法在强模型上的普适性。

未来方向

作者在附录 A 提到三个方向:(1) 验证更强 backbone 与超过 1000 任务的长任务流,研究规模上限、长时专精化稳定性与洞察陈旧化问题;(2) 把当前共享的团队奖励 $r_t$ 形式化为更细粒度的角色条件化 credit attribution,让每个角色(anchor/complement/scout)有独立的回报信号;(3) 通过元学习自动适配生命周期阈值。基于成果还可以延伸的方向包括:(a) 把 niche 标签与 persona 设计的协同机制扩展到跨语言、跨模态任务流,验证非对称迁移在异质模态间的有效性;(b) 把 EVOCHAMBER 的涌现专精化模式与 mixture-of-experts、参数高效微调结合,看是否能用群体进化替代部分 fine-tuning;(c) 研究「专精化」与「多样性」之间的 Pareto 边界——当前 4-5 个专家是不是最优,过多专家是否会导致 routing 不稳定、过硬专精化是否会让 niche 漂移失活;(d) 探索把 CODREAM 的非对称差量迁移机制推广到单智能体内部,让同一智能体的不同 persona / 不同历史窗口间也能定向迁移。

复现评估

EVOCHAMBER 的复现门槛属于「中等偏高」。代码已在 GitHub 开源(https://github.com/Mercury7353/EvoChamber),主实验使用 Qwen3-8B 通过 vLLM 部署在 1 张 H100 上、两个实例做 round-robin 负载均衡,max model length 32768、GPU memory utilization 0.90、bfloat16;GPT-4.1-mini 实验通过 API 调用。数据方面,Hard Math Stream 包含 262 道 MATH Level 4/5 加 AIME 2022-2025 各 30 道共 382 题,Hard Code Stream 包含 257 道 MBPP+ 与 165 道 CodeContests 共 422 题,AFlow-Stream 包含六个领域各 100 任务共 600 题——这些数据集都来自公开来源(MATH、AIME、MBPP+、CodeContests、GSM8K、HotpotQA、HumanEval、DROP),复现无需额外标注。超参方面,论文强调「同一组超参在所有任务流和所有 backbone 上不经调整直接使用」并把全部超参列在 Table 9(EWMA $\alpha=0.3$、$N=20$、$k=3$、$\tau=10$、$\theta=0.6$、$\lambda_q=1.0, \lambda_\sigma=0.3, \lambda_\omega=0.5$、$\lambda_u=0.3, \lambda_d=0.5$ 等),降低了 tuning 成本。最大的复现挑战是:(i) vLLM 的随机解码与 LLM API 的非确定性会让单次运行结果有小幅波动,需要多次种子取平均;(ii) LeadLearn 库、CODREAM 五阶段反思管线、lifecycle 算子都需要在工程上精细实现,每个阶段的 prompt 模板、insight 分类、差量门控都有一定实现细节,建议直接复用作者开源代码而不是从零搭建;(iii) Qwen3-8B 的「thinking mode」开关对结果有显著影响,附录 E.2 明确说明三个任务流都使用了 thinking mode,忘记开启会导致准确率明显下降。总体而言,拿到代码与超参表后,在 1 张 H100 上几小时内可以完整复现主要结果,但要把涌现专精化现象跑清楚需要跑完 600+ 任务流,单次实验可能需要数小时到一天。