乔木博客

全部

AI工具

AI教程

AI生成

AI资讯

健脑房

播客解读

论文学习

HeavySkill：AI 集体讨论竟超越单次推理上限，秘密藏在"独立思考"

论文学习

·

2026年5月12日

·

1711 次阅读

·

约 21 分钟

论文原文：HeavySkill: Heavy Thinking as the Inner Skill in Agentic HarnessarXiv：https://arxiv.org/abs/2605.02396发布日期：2026-05作者：Jianing Wang et al.（投稿至 ICML 2026）

一道难题，你自己反复想了半天，死活想不通。

但把思路讲给几个朋友听，他们从不同角度七嘴八舌一讨论，反而很快就找到了突破口？

这不是巧合。

人类解决复杂问题时，"集体讨论"确实比"闭门苦思"更有效。

诺贝尔奖得主理查德·费曼有个著名的学习法，核心之一就是把自己对一件事的理解讲给别人听，然后在解释的过程中发现自己哪里没真正想清楚。

解释本身，就是一种思维工具。

现在，有一篇来自 ICML 2026 的论文，把这套逻辑直接搬给了 AI。

这篇论文叫 HeavySkill，核心主张只有一句话：让 AI 先并行"各想各的"，生成多条独立推理轨迹，再用另一轮推理来综合所有思路，得出最终答案。

听起来很朴素？但实验数据会让你吃一惊。

更有意思的是，这篇论文还把整个推理流程编码成一份"技能文件"，纯文本，任何 AI Agent 框架读懂之后就能执行，不需要改一行代码。

这背后是一个更大的问题：我们升级 AI 能力，到底是要训练新模型，还是只需要更好地"告诉它怎么做"？

AI 推理的"天花板"：Pass@K

在谈 HeavySkill 之前，先要理解一个背景概念，这样后面的数字才有感觉。

Pass@K：对同一道题生成 K 条独立推理轨迹，只要有一条是对的，就算通过。这是理论上的"最高上限"，衡量模型的推理潜力上界。

Mean@K：K 条轨迹的平均准确率。这是你实际用到的性能，通常远低于 Pass@K。

Vote@K（多数投票）：从 K 条轨迹里，选出答案出现频率最高的那个。这是目前最常用的聚合策略，俗称"少数服从多数"。

Pass@K 是天花板，Mean@K 是地板，Vote@K 是你能拿到的"中间件"。

传统智慧认为：你永远无法超越 Pass@K，因为那代表了模型在 K 次尝试中能力的绝对上限。

Pass@K 的逻辑很简单：K 次独立尝试里，只要一次对了就算赢。

如果 K 次没有一次对，你就输了，没有什么策略可以凭空变出一个正确答案。

这个上限，从逻辑上看起来无懈可击。

HeavySkill 的实验数据打破了这个"常识"。

在某些测试场景下，经过"集体讨论"之后产出的最佳答案（HP@4），居然超过了原始 K 次采样的 Pass@K 上限。

也就是说，经过讨论，模型生成了 K 次独立尝试中根本没有出现过的正确解法。

举个具体例子：在 IMO（国际数学奥林匹克答案基准）上，GLM 4.6 的原始 Pass@8 是 75.1%，代表 8 次单独尝试里最高能达到的上限。

但经过 HeavySkill 的讨论处理后，HP@4（4 次讨论输出中最好的那个）达到了 86.0%，超过了原始天花板整整 10.9 个百分点。

讨论的过程中，模型可以把不同轨迹里各自正确的片段拼合在一起，推导出任何单一轨迹都没有得到的完整正确答案。

就像把几张不完整的地图拼起来，你能看到比任意一张单独都更清晰的全貌。

框架核心：两段式流水线

HeavySkill 的架构图看起来很简单。

左边是并行推理阶段（Parallel Reasoning）：给同一道题生成 K 条相互独立的推理轨迹，每条轨迹都不知道其他轨迹的存在，各自从零开始思考。

右边是序列讨论阶段（Sequential Deliberation）：把所有轨迹打包，交给另一个模型（或同一个模型）做"综合推理"，最终给出答案。

并行推理（Parallel Reasoning）：同时启动 K 个独立的推理过程，不共享信息，确保多样性。就像让 K 个人在隔音房间里各自解题。

序列讨论（Sequential Deliberation）：把所有独立思路聚合起来，交给一个"主持人"综合评判，得出最终结论。

这两个阶段分工明确：并行阶段负责"广度"，讨论阶段负责"深度"。

这就好像组织一场论文评审。

先让每个评审人独立打分（防止互相影响），然后开一个全体讨论会，把所有评审意见摆在桌上，综合出最终结论。

如果直接让评审人互相讨论再各自打分，反而容易受到第一个发言者的影响，陷入"锚定效应"。

锚定效应（Anchoring Bias）：人在做判断时，容易过度依赖最先看到的信息，后续的判断往往围绕这个"锚"来调整。独立先判断，再集体讨论，是打破锚定效应的标准方法。

这也解释了为什么并行推理阶段要强调"独立性"。

如果 K 个 Agent 能互相看到彼此的推理过程，它们很可能会很快收敛到同一个错误答案，多样性就失去了意义。

独立推理才能保证：这 K 条轨迹真的在探索不同的解题路径，而不是一群人跟着第一个人的思路一起走进死胡同。

从 2024 年 o1 发布以来，测试时计算的重要性越来越被业界认可。

o1 的核心进步之一，就是在推理阶段让模型"多想一会儿"。

但 o1 的多想是单线程的，是在一条轨迹上往深处走；

HeavySkill 的多想是多线程加综合，是在宽度和深度上同时扩展。

记忆缓存：解决"太长了装不下"的问题

K 条推理轨迹，每条都可能有几千个 token 的内部思维过程，全部拼在一起？

模型的上下文窗口早就撑爆了。

序列化记忆缓存（Serialized Memory Cache）：一种把多条轨迹压缩、整合后送入讨论阶段的机制。会裁剪掉冗余内容，并对轨迹顺序做随机打乱，防止模型对特定位置的答案产生偏见。

这里有个细节值得注意：打乱顺序是为了防止位置偏见。

如果轨迹永远按固定顺序排列，讨论模型可能会系统性地偏向"第一条"或"最后一条"，而不是真正做内容评判。

这就像把多份报告的顺序随机打乱再给分析师看，防止他们因为"先入为主"而影响判断。

记忆缓存还有另一个设计细节：剪枝。

每条推理轨迹里，模型的内部思考过程（Thinking Chain）往往比最终答案长很多，有时候是好几倍。

如果把所有轨迹的完整内容都拼起来，上下文长度会爆炸。

所以缓存只保留关键的推理片段和最终答案，裁掉冗余的中间过程。

这里有个微妙的工程权衡：裁掉的内容越多，上下文越短，但可能丢失讨论阶段需要的关键信息。

保留的内容越多，越完整，但超出上下文窗口就会直接截断。

如何在这两者之间找平衡，是实际部署中需要仔细调试的问题。

论文的解决方式是：保留推理结论和关键步骤，丢弃内部自我质疑和重复尝试的内容。

这和人类开会时记录"会议纪要"的逻辑一样，不是逐字逐句记录所有发言，而是提炼关键决策和结论。

"可读技能"：给 AI 看的说明书

HeavySkill 最有意思的一个设计，是它不只是一个 Python 程序，还可以被编码成一份人类可读、AI 可执行的文本文档。

Skill 文件（Skill File）：一种结构化的自然语言文档，描述 AI Agent 何时触发、如何执行、输出什么。不需要修改底层代码，只需加载到上下文窗口即可。

这份 Skill 文档包含四个部分：

激活条件：什么时候该启动重型思考？（复杂推理任务时是，闲聊时否）

并行推理协议：如何启动 K 个独立 Agent，鼓励多样化的解题路径

讨论提示词：核心环节，指导讨论模型如何综合所有轨迹

输出约束：只输出答案，不输出元分析过程

这份文档可以被 Claude Code、OpenAI Codex 等任何支持技能加载的 Agent 框架直接使用，不需要改一行代码。

这和今天的编程实践高度相关：你不是在部署一个新模型，你只是给现有的模型读了一份"操作手册"，它就知道该怎么做了。

In-Context Learning（上下文学习）：模型通过在提示词里看到任务描述和示例，就能执行新任务，无需微调参数。HeavySkill 的 Skill 文件正是利用了这一能力。

这个设计有个很吸引人的特性：可移植性。

同一份 HeavySkill 文件，在 Claude Code、OpenAI Codex 和自定义 Agent 框架里都能工作，不需要任何修改。它和底层的推理基础设施解耦了。

想象背后的含义：未来也许存在一个"技能市场"，AI 研究者把他们发现的有效推理策略打包成 Skill 文件，工程师直接下载部署，就像安装一个插件。

不用等到下一个版本的模型，不用做大规模微调，推理能力的迭代可以更快速、更模块化地进行。

数据说话：集体讨论，到底赢在哪里？

论文做了非常系统的实验，横跨 STEM、编程、通用推理三大类任务，测了十多个模型。

STEM 推理任务

在 AIME25、BeyondAIME、HMMT25-Feb、GPQA-Diamond 四个高难度数学和科学基准上：

评估指标

含义

典型表现

Mean@K（基线）

K 条轨迹平均准确率

底部

Vote@K（多数投票）

频率最高的答案

中等

HM@4（重型平均）

4 次讨论的平均准确率

通常超过 Vote@K

HP@4（重型潜力）

4 次讨论中最佳答案

某些情况下超过 P@K

重点发现：在 GPQA-Diamond（博士级科学题）上，用 K=8 并行轨迹时，某些模型的 Vote@K 只有 32.1%，而 HM@4 达到了 48.8%，高了将近 17 个百分点。

多数投票在这里为什么失效？

因为这类难题，正确答案往往是"少数派"，正确轨迹可能只有 1-2 条，被多数错误轨迹淹没。

而讨论阶段的模型会做批判性分析，不会盲目跟风。

多数投票（Majority Voting / Vote@K）：从 K 条轨迹中选出出现频率最高的答案。这个方法在简单题上很有效，但在难题上容易被"多数错误"压制少数正确。

这个现象在人类的集体决策里也很常见。

经典案例是阿波罗 13 号的故障排查：NASA 工程师团队当时面对一个很多人都判断错误的技术假设，但少数几个人通过系统性分析找到了真正的原因。如果用投票，真相会被淹没。

论文给出了一个更细致的分析图：

对于并行推理通过率低于 50% 的难题（正确轨迹是少数派），在 1 万条样本里，有超过 500 条经过讨论后被纠正成功。

这不是小数字，这是在"看起来大多数人都答错了"的情况下，讨论机制依然能找回正确答案。

编程和通用推理任务

在 LiveCodeBench 上，GPT-OSS-20B 的 Mean@K 是 69.7%，经过讨论后 HM@4 提升到 85.5%，涨了将近 16 个点。

在 IFEval（指令遵循）上，R1-Distill-Qwen-32B 从 35.7% 跳到 69.3%，翻了快一倍。

但在 Arena-Hard（开放对话偏好）上，效果就不明显了。

这说明讨论机制对"有标准答案"的任务帮助最大，对"口味偏好"类任务效果有限。

反直觉发现：讨论者不需要很会解题

这是论文里最反直觉的发现。

把并行推理阶段固定为 R1-Distill-Qwen-7B，然后换不同的模型来做"讨论"：

R1-Distill-Qwen-7B（自己讨论）：效果好

R1-Distill-Qwen3-8B：效果好

Qwen2.5-32B-Instruct：效果也好

问题来了：Qwen2.5-32B-Instruct 自己解 AIME25 只有 12.8% 的准确率，连弱小很多的 R1-Distill-Qwen-7B 都比不上。

但它作为"讨论主持人"，却能显著提升最终结果。

这说明什么？

讨论阶段需要的不是强大的解题能力，而是强大的分析、综合、总结能力。

把一堆解题过程摆在面前，问"哪个对、为什么、怎么整合"，和自己从零解题是完全不同的能力。

Qwen2.5-32B-Instruct 作为大参数通用模型，在这种综合分析上很有优势，即便它解题能力相对弱。

这就像公司里的 PM 和工程师：好的 PM 不一定能写出最好的代码，但他很善于综合多个工程师的输入，给出清晰的决策。

这个发现对实际部署有很大的成本含义。

如果讨论阶段不需要顶级推理模型，你可以：

并行推理阶段：用多个较小的专业推理模型（成本低、速度快）

讨论阶段：用一个大参数的通用模型（善于分析综合）

这种分工方式可能比"全程用最强推理模型"更经济，同时效果还更好。

论文没有显式计算成本，但这个思路已经有了。

推理成本（Inference Cost）：运行一次模型推理所消耗的算力资源。参数量越大、输出越长，成本越高。HeavySkill 的"分工模式"理论上可以在固定预算下榨出更多性能。

迭代讨论：越讨论越好？

除了一次性讨论，论文还试了迭代讨论：把第一次讨论的输出塞回记忆缓存，再做第二次讨论，如此循环。

结果：HM@K（平均性能）随迭代次数持续上升，但 HP@K（最佳潜力）反而下降。

这说明迭代会帮助提升平均水平，但也会引入"累积噪声"，把原本某些正确的思路逐渐带偏。

更多的讨论不一定带来更高的上限，有时候过度讨论会把好答案淹没在越来越多的中间结论里。

开会开多了的人，对这个现象一定不陌生。

工具调用场景：重型思考扩展到 Agent

论文还做了一个让我觉得特别有价值的实验：在 Tool-Interleave Reasoning 场景下测试 HeavySkill。

Tool-Interleave Reasoning（工具交织推理）：推理过程中可以调用外部工具（比如 Python 解释器）获取执行结果，然后根据结果继续推理。这比纯文本推理更接近真实的 Agent 使用场景。

实验设置：并行推理阶段，每个 Agent 都能调用 Python 解释器，最多交互 50 轮。

然后把所有轨迹和执行结果一起送给讨论阶段综合。

模型

AIME25 Vote@4

AIME25 HM@4

HMMT25 Vote@4

HMMT25 HM@4

Qwen3-8B

55.7%

70.7%

38.0%

—

Qwen3-32B

63.0%

81.7%

40.3%

—

GPT-OSS-20B

69.8%

95.0%

55.3%

93.3%

GPT-OSS-20B 在 AIME25 上，投票只有 69.8%，加上讨论直接跳到 95.0%，接近完美。

这个实验的意义在于：HeavySkill 不是一个纯文本推理的技巧，它在更复杂的工具使用场景下同样有效。

未来的 AI Agent 任务越来越复杂，往往需要调用多种工具、处理代码执行反馈、跨步骤维护状态。

在这些场景下，并行思考加集体讨论的框架有更大的施展空间。

用 RL 进一步提升：训练 AI 更会"讨论"

论文最后的部分，试了把强化学习（RLVR）应用到 HeavySkill 的讨论阶段。

RLVR（可验证奖励的强化学习）：用可自动验证的奖励信号（比如数学答案是否正确）来训练模型，不需要人工标注。

选了并行通过率在 0~62.5% 之间的难题（正确轨迹本来就很稀少的那些），用 VeRL 框架做 RL 训练：

前 100 步，HM@4 持续上升，最终提升了约 10 个百分点。

但 K=16 的配置出现了训练不稳定的问题（熵崩溃），K=8 表现更稳定。

作者推测原因是上下文长度限制：16 条轨迹的记忆缓存太长，超出了模型处理能力。

轨迹选哪些？策略很重要

论文还做了一个有趣的消融实验：在 256 条轨迹里，怎么选 K 条送给讨论阶段？

随机选：不错

最大多样性：和随机差不多，主动选多样性没有明显增益

最长轨迹：最差！长不代表好，冗长往往意味着更多噪声

最多数答案（Max-Answer-Num）：最好！先用多数投票筛出高质量轨迹，再送讨论

这个发现很实用：先用多数投票做初筛，再讨论，比直接随机送讨论效果好。

不是把投票和讨论当成竞争者，而是让它们配合工作。

Max-Length（选最长轨迹）为什么最差？这也反直觉。

我们通常觉得"想得越详细越好"，但实验数据说：冗长的推理轨迹里往往混杂了更多无效甚至有害的内容，反而干扰讨论阶段做出正确判断。

短而准的答案，比长篇大论更有价值。

这和写作里的道理是一样的：冗余不是深度，精炼才是。

写在后面

这篇论文投稿于 2026 年 5 月，刚刚出来。

它所研究的问题，是最近两三年 AI 圈里争论最激烈的那类问题之一：测试时扩展（Test-Time Scaling）。

过去，我们提升 AI 能力的方式主要靠训练：更多数据、更大模型、更长时间。

但 o1 和 DeepSeek R1 之后，大家意识到"推理时多花算力"也是一条有效的路。

Gemini、Kimi K2 Thinking 都已经在自己的产品里用上了类似的"重型思考"机制。

HeavySkill 做的事，是把这件事从"各家黑盒实现"变成一个可以被系统研究的框架。

它把"并行推理加讨论"这套模式拆解清楚，把每个组件的贡献量化，还提供了一份可以直接被 AI Agent 读懂执行的技能文件。

这件事本身值得停下来想一想。未来的 AI 能力提升，会越来越多地通过这种"写说明书"而不是"重新训练"的方式实现吗？

如果一个足够聪明的 AI 能读懂一份足够好的技能文档，并且按照文档执行，那能力迭代的速度会发生什么变化？

这篇论文里最出乎意料的那个发现，让我反复想：一个自己只能解出 12.8% AIME 题的模型，作为讨论主持人，却能帮助整体表现超越强模型的单独发挥。

解题能力和综合判断能力，是两种可以独立存在的东西。

如果你身边有个不擅长做题但特别擅长听懂别人思路、找到关键问题、综合出最佳方案的人，你知道他在团队里有多宝贵。

AI 里也有这样的角色分工，而且这是从实验数据里自然浮现的，不是设计出来的。

我们花了这么多年时间研究如何让 AI 更聪明，或许忽视了另一件事：如何让多个 AI 更好地配合。一个弱模型作为协调者，加上几个中等模型作为思考者，整体效果可以超过一个强模型单独工作。

这是组织的力量，不只是个体的力量。

下次你在用 AI 工具遇到它答错的时候，不妨多问一次："你能不能重新想想，从另一个角度看看之前的思路有没有问题？"

某种程度上，你在手动触发 HeavySkill 里的那个"讨论阶段"，而且它确实会有效。

论文原文：HeavySkill: Heavy Thinking as the Inner Skill in Agentic HarnessarXiv：https://arxiv.org/abs/2605.02396发布日期：2026-05作者：Jianing Wang et al.（投稿至 ICML 2026）

© 2026

·

向阳乔木