AI打比赛，连续三场第一名碾压所有人类选手——GrandCode做对了什么？

你有没有想过，Codeforces上那些rating 3000+的红名大神，有一天会被AI按在地上摩擦？

不是说AI做不了编程题——AlphaCode两年前就能排到中位数水平了。但竞赛编程和写业务代码不一样，它要求的是极短时间内的数学直觉、算法构造能力和精准的实现。2023年的AlphaCode 2（基于Gemini）能打败85%的选手，听着很厉害，但放到Div 1的顶尖赛场上还是不够看。

然后今年3月，一个叫GrandCode的系统在Codeforces连续参加了三场正式比赛——三场全部第一名，击败所有人类参赛者。

这不是离线评测、不是刷历史题，是实时比赛，跟tourist（传奇选手，Codeforces历史最高分保持者）这种级别的人正面对决。Round 1088那场，GrandCode的账号yokeko拿了15008分排第一，第二名turmax拿了13251，tourist排第三拿了13166。

这篇论文的核心问题其实是：怎么把一个"能做题"的大模型，升级成一个"能打比赛"的智能体系统？

核心摘要

GrandCode是一个多智能体竞赛编程系统，基于Qwen 3.5-397B构建。它把竞赛编程拆解为四个协作模块：主求解器、假设生成器、摘要压缩器和对抗测试用例生成器。训练上提出了Agentic GRPO——针对多阶段Agent rollout中"反馈延迟"和"off-policy漂移"的问题，将梯度更新拆为即时奖励和延迟修正两阶段。系统在2026年3月连续三场Codeforces正式比赛中全部获得第一名。在100题基准上，经过完整训练流程后接受率从64%提升到85%，Level-5难题（最难级别）解决数从4/20提升到15/20。这篇论文是工程整合的巅峰之作，但其方法论中也有值得深挖的细节和局限。

论文信息

  • 标题：GrandCode: Achieving Grandmaster Level in Competitive Programming via Agentic Reinforcement Learning
  • 作者：Xiaoya Li, Xiaofei Sun, Guoyin Wang, Songqiao Su, Chris Shum, Jiwei Li
  • 团队：DeepReinforce
  • 日期：2026年4月3日
  • 链接：https://arxiv.org/abs/2604.02721

为什么竞赛编程这么难？

竞赛编程和我们平时说的"AI写代码"是两码事。

平时的代码生成任务——给个函数签名，补全实现，跑通单测——大模型干这个已经很溜了。但竞赛编程的题目是这样的：给你一段文字描述一个数学/组合/图论问题，你要在2-3小时内理解题意、发现隐藏的数学性质、构造出正确且高效的算法、写出能通过所有测试点的代码。

难在哪？

  • 数学直觉：很多题的关键不是实现而是发现一个非显然的数学等式或贪心性质
  • 时间压力：比赛通常6-8道题，2小时。顶级选手平均每道题10分钟
  • 对抗性测试：出题者会刻意构造卡常、卡边界的测试数据
  • 全有或全无：代码要么通过所有测试用例，要么0分。没有"部分正确"

之前的AI系统，不管是AlphaCode还是后来Gemini 3 Deep Think（据论文提到，曾在评测中获得第8名），都面临一个共同的瓶颈：单次生成的可靠性不够。生成100份代码取最好的，离线评测看着还行，但实时比赛不允许你提交100次。

系统架构：四个模块的协奏曲

GrandCode的核心设计思路是：把"做竞赛题"这件事拆解成多个专精模块，让它们协作而非让一个大模型全包。

GrandCode系统架构总览

系统架构总览：左半部分是Post-Training训练流程，从继续预训练到SFT再到多组件RL联合训练；右半部分是Test-Time RL推理流程，根据题目难度选择直接生成或进入验证-反馈循环

整个系统分为两条腿——Post-Training（离线训练）和 Test-Time RL（比赛时在线优化）。

主求解器

核心策略模型，基于Qwen 3.5-397B。输入题目描述，输出推理过程和代码。这个没什么特别的，就是一个非常大的语言模型在做它擅长的事。

假设生成器

这个模块我觉得是GrandCode最有意思的设计。

竞赛题的难点经常不在实现，而在"看出来这道题其实是在问什么"。比如一道题表面在问图的遍历，但关键性质是"答案等于某个值的最大差值"。

假设生成器干的就是这个——针对题目提出结构性猜想，然后在小规模实例上暴力验证。

假设生成与小规模验证流程

假设生成流程：输入题目后提出数学猜想（如 \(k_{max} = \max_v(last(v) - first(v))\)），生成小规模随机实例（\(n \leq 8\)），用暴力枚举器对比猜想是否成立，不匹配则修正假设

这个设计相当精巧。它用一个较小的Qwen-3.5-27B模型来做猜想生成，验证过程靠的是暴力枚举而非模型推理——这就避免了"用模型验证模型"的循环论证。

训练效果也很能打：

模型配置 pass@1 pass@5
Qwen-3.5-27B（基础） 34% 44%
+ SFT 45% 52%
+ SFT + RL 52% 57%

从34%到52%，pass@1翻了超过1.5倍。这说明假设生成这个能力确实可以通过SFT+RL来训练，不是纯靠模型规模堆出来的。

摘要压缩器

竞赛编程的推理链经常特别长——动辄几千个token。当需要多次迭代求解时，之前的推理历史塞在上下文里会爆炸。

摘要模型的作用是把冗长的推理trace压缩成关键信息摘要，让后续迭代能"站在前人肩膀上"而不被上下文长度拖累。同样用Qwen-3.5-27B训练。

对抗测试用例生成

这个模块负责"自己出测试来卡自己"。两种策略：

  • Difference-driven：生成能暴露不同候选解之间差异的测试输入
  • Solution attack：分析候选解和标准解的差异，针对性构造能让候选解失败的测试

在50个真实Codeforces题目上的效果：

测试策略 通过题数（/50）
基础测试集 42
+ difference-driven + solution attack 48
+ 提交反馈 + 在线生成 50

从42到50，全部搞定。这个增量改进看着不大，但在竞赛里每多过一道就是实打实的排名提升。

Agentic GRPO：怎么训一个多阶段Agent

这是论文的技术核心，也是我觉得最值得仔细看的部分。

问题在哪

标准的GRPO（Group Relative Policy Optimization，DeepSeek提出的无Critic强化学习算法）是针对单轮生成设计的：模型生成一组回答，按组内相对奖励计算优势函数更新策略。

但GrandCode是多阶段的——假设生成、主求解、测试验证、摘要压缩，这些模块串联执行。问题来了：

  1. 反馈延迟：前面模块执行完了，最终奖励（代码是否通过）要等所有阶段跑完才知道。你让假设生成器等几十秒才能拿到梯度信号，效率太低。

  2. Off-policy漂移：RL训练是异步的。当策略A生成的rollout数据终于收到反馈时，策略已经更新到B了。数据过期了。

Agentic GRPO的解法

核心思路：把梯度更新拆成两阶段。

阶段一：即时奖励

每个子阶段（假设生成、主求解等）执行完后，立刻用该阶段的中间奖励 \(r_t\) 做梯度更新：

\[A_t^{(i)} = \frac{r_t^{(i)} - \mu_t}{\sigma_t}\]

其中 \(\mu_t\) 和 \(\sigma_t\) 是组内均值和标准差。

阶段二：延迟修正

当最终奖励 \(r_N\) 到手后，回头修正前面阶段的估计偏差：

\[\delta_t^{(i)} = r_N^{(i)} - r_t^{(i)}\]

同样做组内归一化后作为修正梯度。

这个设计的巧妙之处在于：即时奖励保证了训练不会因为等待而空转，延迟修正又把最终的"真相"回传给了早期阶段。相当于先给个粗糙但及时的信号让模型动起来，等精确信号到了再做微调。

处理Off-policy：Staleness加权

针对数据过期问题，论文引入了基于"陈旧度"的token加权：

\[w(d_t) = \begin{cases} 1 & d_t \leq K_1 \\ e^{-\lambda(d_t - K_1)} & K_1 \lt d_t \leq K_2 \\ 0 & d_t > K_2 \end{cases}\]

\(d_t\) 衡量token生成时和当前策略之间的差距。新鲜数据全额使用，稍旧的指数衰减，太旧的直接丢弃。

坦率讲，这个设计在概念上不算新——off-policy校正在RL里是老话题了。但在大模型Agent的多阶段训练中把它工程化落地，还是有实际价值的。

训练流程：从预训练到比赛

整个训练pipeline分三步：

Step 1：继续预训练

在70K+竞赛编程题上做继续预训练，数据来源包括TACO、LeetCode、USACO、CodeContests、IOI等。这一步主要是让模型熟悉竞赛编程的题目格式和代码风格。

Step 2：SFT

用参考解做监督微调，数据格式是（题目，思维过程，代码）三元组。思维过程通过最优thinking trace筛选得到。

Step 3：Multi-Component RL

三个策略模型（主求解器、假设生成器、摘要模型）联合用RL训练，加上测试用例生成的对抗反馈。

一个有趣的trick是长度惩罚：

\[Penalty(l, d) = \max\left(0, \frac{l - B \cdot \alpha^{(d-1)}}{B \cdot \alpha^{(d-1)}}\right)\]

其中 \(d\) 是题目难度（1-5），\(l\) 是生成长度，\(B\) 和 \(\alpha\) 是超参。难度越高允许的生成长度越长。这避免了模型对简单题也生成冗长推理。

还有一个rank-based reward smoothing：

\[w_j(\lambda) = \frac{e^{-\lambda j}}{\sum e^{-\lambda m}}\]

\(\lambda\) 在训练过程中逐渐增大，让模型从"向所有好的解学习"逐渐过渡到"只向最好的解学习"。这个思路类似于课程学习中的逐步收紧标准。

比赛实战：三场全第一

Codeforces三场比赛排行榜

三场Codeforces正式比赛排名截图：Round 1087（Div 2）账号averyjones1拿下8334分第一；Round 1088（Div 1+2）账号yokeko拿下15008分第一，击败tourist（13166分，第三名）；Round 1089（Div 2）账号Vortex1拿下9506分第一

这张排行榜截图是整篇论文最炸的部分。具体数据：

比赛 日期 组别 账号 得分 用时 排名
Round 1087 3月21日 Div 2 averyjones1 8334 00:51:11 1st
Round 1088 3月28日 Div 1+2 yokeko 15008 01:40:35 1st
Round 1089 3月29日 Div 2 Vortex1 9506 00:56:43 1st

Round 1088是含金量最高的——Div 1+2意味着所有段位的选手都在，包括tourist这种传奇。GrandCode不仅赢了，而且领先第二名接近1800分。

但有个地方需要留意：论文用了"separate"和"joint"两种分数。separate分数更高（分别是9269、16511、11596），这可能是系统内部多个方案分开计算的得分，joint才是最终提交得分。论文在这里的区分不太清晰。

Test-Time RL：比赛中的在线优化

GrandCode在比赛时不是简单地生成代码提交。它有一套Test-Time RL流程：

  1. 判断题目难度——简单题（A、B、C级）直接生成提交
  2. 难题进入验证循环：生成候选解 -> 用测试用例生成器构造对抗测试 -> 验证 -> 如果通过则提交，否则反馈给LoRA更新
  3. 全局trial summary记录历史尝试，避免重复犯错

这个设计意味着系统在比赛过程中还在"学习"——每次错误提交都会通过LoRA微调来修正策略。

实验结果：数据说话

训练阶段消融

阶段 接受率 Level-5解决数 加权得分
Qwen 3.5-397B（基础） 64% 4/20 52.2
+ 继续预训练 71% 6/20 61.0
+ SFT 73% 7/20 62.5
+ Summary模块 72% 7/20 61.7

继续预训练带来了最大的增益（+7%接受率），SFT再加2个点。Summary模块加入后接受率反而微降1%，但在更长推理链的场景应该有优势（这个baseline可能没完全体现）。

RL训练效果

阶段 接受率 Level-5解决数 加权得分
Post-training 72% 7/20 61.7
Full RL 81% 13/20 72.3
+ Test-Time RL 85% 15/20 73.5

RL阶段的提升是跳跃式的——接受率从72%到81%，Level-5从7/20直接翻到13/20。这6道难题的突破才是GrandCode能在比赛中获胜的关键。Test-Time RL又多解了2道Level-5，从13到15。

与前沿模型对比

模型 接受率 Level-5解决数 加权得分
Gemini 3.1 Pro 75% 7/20 64.3
Claude Opus 4.6 73% 8/20 63.7
GPT-5.4 72% 7/20 63.0
Qwen 3.5-397B（基础） 64% 4/20 52.3
GrandCode（完整） 85% 15/20 73.5

GrandCode完整系统（85%接受率）远超所有通用大模型。差距主要在Level-5难题——通用模型能解7-8道，GrandCode解了15道，接近翻倍。

基础设施创新：DeltaNet混合架构与流水线并行

论文在工程侧也花了不少篇幅，这部分对做大规模RL训练的同学很有参考价值。

DeltaNet + Softmax混合架构

GrandCode的base model不是纯Transformer，而是DeltaNet（线性注意力）+ Softmax Attention的混合体。DeltaNet层处理大部分计算，Softmax层负责需要精确长程依赖的部分。

好处是推理效率更高（线性注意力复杂度低），但训练时有个麻烦：DeltaNet层需要context parallelism（CP）来处理长序列，而Softmax层不需要。

流水线Context Parallelism

流水线Context Parallelism示意图

DeltaNet层（上半）采用流水线context parallelism：4个GPU按micro-batch交错处理不同层，减少idle时间；Softmax Attention层（下半）所有GPU同步处理同一micro-batch

这张图展示了如何让DeltaNet层和Softmax层的并行策略无缝衔接。DeltaNet层用流水线方式在4个GPU上交错执行不同层的micro-batch，Softmax层则所有GPU同步处理。

效率数据：

Micro-batch数 DeltaNet效率 整体效率 Bubble开销
2 67% 87% 13%
4 80% 90.3% 9.7%
8 89% 94% ~6%
16 94% 97% ~3%

16个micro-batch时整体效率达到97%，bubble开销只有3%。这个数字相当不错。

另外一个细节：RL训练中MoE（混合专家）模型的expert routing是frozen的——不参与RL梯度更新。论文的解释是路由层在RL训练中容易不稳定，不如固定住。这个经验挺实用。

我的判断：亮点与问题

值得学习的地方

假设生成器的设计是我觉得这篇论文最有价值的贡献。它不是简单地让模型"想更多"，而是引入了一个显式的"猜想-验证"循环。用暴力枚举在小实例上验证数学假设，这个思路在竞赛编程之外也能迁移——比如数学证明、科学推理。

Agentic GRPO的两阶段设计在工程上很实用。多模块Agent系统的训练一直是个痛点，这篇论文给出了一个可操作的方案。

三场实战连胜的说服力毋庸置疑。不管方法论上有什么可争议的，结果摆在那里。

需要思考的问题

1. 基座模型的贡献有多大？

Qwen 3.5-397B本身就是一个397B参数的超大模型。从消融表看，基础模型已经能做到64%接受率。整个训练pipeline把它提到85%——提升了21个百分点。但如果换个小模型，比如70B级别的，这套方法还能work到什么程度？论文没有回答这个问题。

2. 比赛环境的公平性

GrandCode在比赛时使用了Test-Time RL——实时微调模型。人类选手没有这个条件。当然，AI也没有人类的直觉和创造力，但Test-Time RL某种程度上让AI获得了"比赛中学习"的能力，这是一种人类不具备的优势。

3. 三场比赛的样本量

三场都赢了，很了不起。但从统计角度说，N=3的样本量不足以得出"AI系统性地优于顶尖人类"的结论。如果连续参加30场比赛，表现如何？有没有题型盲区？

4. 账号使用和可重复性

论文中三场比赛用了三个不同账号（averyjones1、yokeko、Vortex1）。没有解释为什么换账号。Codeforces的规则是一人一号——这在伦理上有些微妙。虽然后续论文公开了，但比赛当时其他参赛者并不知道自己在跟AI比赛。

5. 与Gemini Deep Think的对比不够充分

论文提到之前最好的AI系统（Gemini 3 Deep Think）"曾获得第8名"，但没有给出详细的头对头对比。Gemini的评估是在什么条件下做的？题目集一样吗？这个对比过于粗略。

6. Summary模块的消融结果有点尴尬

加了Summary模块后接受率从73%掉到72%。论文的解释是在100题基准上效果不明显，但在更长推理链的场景有帮助。可能是这样，但这种"在我们的benchmark上效果不好但在实际中有效"的说法，需要更多证据支撑。

放到更大的图景里看

AI在竞赛编程领域的发展轨迹很清晰：

  • 2022：AlphaCode达到Codeforces中位数水平（Elo ~1238），约打败46%的选手
  • 2023：AlphaCode 2（基于Gemini Pro）打败85%的选手
  • 2025：Gemini Deep Think在部分评测中获得Top 10
  • 2026：GrandCode连续三场正式比赛第一名

从"能参加比赛"到"能赢比赛"，中间隔了一套完整的多模块Agent系统 + 定制化的RL训练方法。这个跳跃不是模型规模变大带来的——Gemini的参数量不比Qwen 3.5-397B小——而是系统级架构和训练方法的突破。

我的判断是：GrandCode代表的不仅仅是AI在竞赛编程上的里程碑，它更像是一个证明——复杂推理任务需要的不是更大的模型，而是更聪明的系统设计。假设生成器、对抗测试、Test-Time RL这些组件，每一个单独拿出来不算新，但组合在一起产生了质变。

这个思路对其他领域也有启发：如果你在做数学证明、科学发现、甚至复杂的工程设计，"猜想-验证-迭代"的Agent架构可能比单纯扩大模型规模更有效。

当然，竞赛编程毕竟是一个有明确评判标准的closed-world问题。在open-ended的创造性任务上，这套方法的迁移性还需要验证。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我