2021年，谷歌DeepMind的AlphaCode团队做了一件疯狂的事：为了在编程竞赛里达到人类中等水平的成绩，他们让模型对同一道题生成上百万份候选答案，再用层层过滤挑出最靠谱的几份提交。
这句话你读完是不是觉得哪里不对劲。
一道题目，人类高手可能花二十分钟就想清楚了用什么算法、怎么写代码，AI却要靠"广撒网"生成一百万次尝试才能勉强够到及格线。这不是AI比人聪明的故事，这是AI比人"能扛"的故事，用算力堆出来的蛮力，而不是真正理解了问题。
这就是竞赛编程留给大语言模型的一道坎。今天要讲的这篇论文，MARS（Multi-Agent Relay of Specialized LLMs，多专家智能体接力系统），想解决的正是这道坎背后更深层的问题：AI写代码时，到底知不知道自己该用什么算法。
竞赛编程为什么这么难啃
你可能觉得，现在的大模型写代码已经很强了，日常的函数、脚本、小工具，随手就能生成。但竞赛编程是另一个物种。
一道竞赛题往往会同时揉进好几个算法领域：可能一半是图论，一半是动态规划，中间还夹杂着一点数论技巧。而且这些题目故意设计得让人猜不出该用哪个套路，你得先"诊断"出题目的本质，才能对症下药。这种诊断能力，恰恰是大模型最容易露怯的地方。
已有的解决方案思路是这样的：搭一个多智能体（multi-agent）系统，让不同的AI角色分工合作。
> 多智能体系统：让多个AI程序（智能体）各自承担不同任务，通过互相协作完成一件复杂事情的技术架构，类似公司里不同部门配合完成一个项目。
比如MapCoder、CodeSIM这些框架，会设置"规划者""编码者""调试者"这样的角色，规划者负责想思路，编码者负责写代码，调试者负责挑错。这个分工听起来很合理，但论文作者精准地指出了一个盲点：这些角色的分工是按照"工作流程阶段"划分的，不是按照"算法领域"划分的。
换句话说，不管题目是图论题还是几何题，负责规划的都是同一个"规划者"角色，它是不是真的懂图论、懂几何，全靠底层大模型自己的预训练知识兜底，系统本身没有为它注入任何针对性的专业背景。
这就好比一家医院，接诊、开药方、做手术分别由三个人负责，听起来分工明确，但不管病人得的是心脏病还是骨折，接诊的永远是同一个全科医生，他懂不懂心脏，全看他自己平时读了多少书，医院没有专门配一个心脏科医生给他撑腰。如果病人真得了心脏病，这套流程照样走一遍，但正确率就得看运气了。
MARS这篇论文的核心想法就是：既然题目本身有明确的算法领域，那就应该有对应领域的"专家"来负责，而不是让一个万金油角色硬撑。
MARS怎么组建它的专家团队
MARS准备了十一个"专科医生"，每一个都对应一个算法领域，比如动态规划、图论、字符串处理、几何、构造性算法等等。每个专家不只是名字不同，更关键的是，他们各自"读过"不同的专业书。
具体来说，MARS给每个专家配了一个检索增强生成（RAG）系统，让它能去查阅一个叫cp-algorithms的算法理论语料库里和自己领域相关的那部分内容。
> 检索增强生成（RAG，Retrieval-Augmented Generation）：让AI在回答问题前先去一个知识库里检索相关资料，再结合检索到的内容生成答案的技术，好比考试时允许翻书查资料，而不是全靠死记硬背。
这就解决了一个根本问题：不再是让大模型凭记忆去猜"动态规划该怎么做"，而是让动态规划专家实实在在地带着动态规划的参考资料上场。
拿到一道题之后，系统不会一上来就指定谁来做，而是让全部十一个专家都自我评估一遍：这题跟我的专业相关吗？我有把握处理这部分吗？每个专家会给出一个置信度分数，系统根据这些分数挑出最多三个最匹配的专家组成一支小队，再单独问一遍谁适合当"首发"，由这个首发专家先写出第一版代码。
这个自我举手的机制其实挺有意思。它不是由某个中心化的"调度员"来分配任务，而是让每个专家自己判断"这活儿我能不能接"，有点像一个项目群里发了个需求，谁觉得自己擅长就主动认领，最后系统按认领意愿和专业匹配度挑人组队。
如果不这样做会怎样？论文里做了对比实验：如果换成一个更宽松、不那么挑剔的团队筛选机制（论文里的"并行集成"方案），团队规模确实更大了，连"暴力枚举""图论"这种边缘匹配的专家都被拉了进来，但最终的正确率反而没有提升，因为专家多不等于专业对口，团队里塞满了打酱油的人，账面上热闹，干活上添乱。
接力棒式协作：写代码、跑测试、自查、交棒
团队组好之后，真正的干活环节开始了。MARS采用的是一种"接力"模式，这也是它名字里"Relay"的来源。
首发专家先写出一版C++代码，这份代码会立刻被丢进一个叫ExecEval的沙箱环境里，跑一遍题目自带的公开测试样例。
> 沙箱环境（sandbox）：一个隔离的、安全的代码运行空间，代码在里面执行不会影响到外部系统，通常用来测试不确定是否可靠的程序。
跑完测试之后，同一个专家会拿到一份执行报告，上面写着哪些测试通过了、哪些失败了、失败的具体原因是什么。这时候专家要做三选一的决定：保留这份代码（觉得没问题）、修复这份代码（发现了具体的错误并且自己能改）、或者把代码原封不动地交给下一个专家（觉得已经超出自己的专业范围）。
这里有一个特别值得注意的设计细节：如果专家选择修复代码，修复后的新版本必须重新跑一遍公开测试，而且必须确保通过的测试数量不能比修复前更少，才会被采纳，否则系统会自动把代码打回原来那个版本，拒绝这次修复。
这个机制的意义在于，它把"要不要采纳这次修改"的决定权，从AI自己的主观判断转移到了客观的测试结果上。AI很容易觉得"我这次改得挺好"，但事实是不是这样，得靠跑分说话。
这就像一个团队里做代码审查（code review），如果只凭作者自己一句"我测过了，没问题"就直接合并代码，出问题的概率会很高，因为人对自己的判断天然存在盲区。但如果强制要求"你这次改动必须让自动化测试的通过数不减少，否则不能合并"，就相当于加了一道硬性的质量闸门。如果没有这道闸门会怎样？论文的统计数据显示，在697次自我检查决策里，有4.4%的修复提议被这道闸门拦下并撤销，这些本该被拦下的错误修复，如果没有测试验证机制，就会被悄悄接受，进而污染后续的代码。
专家做完自己这一轮，会打包一份"交接文档"给下一个专家：我完成了哪部分工作、还剩下什么没做、有什么潜在风险需要注意。这个交接文档不是把原始的测试报告一股脑甩给下一个人，而是经过提炼的关键信息摘要，让接手的专家能快速进入状态，而不用从头理解一遍所有细节。
整个接力过程有严格的边界：最多轮换三个专家、最多走八个步骤，如果连续两轮都没有实质进展就会重新路由，连续三轮没进展就直接停止。这种"止损"设计避免了系统在无效尝试里反复空转，浪费时间和算力。
收尾还得靠"基础设施修理工"
代码接力结束之后，MARS还留了一道保险：一个专门负责查漏补缺的"基础设施修复"环节。
这个环节不负责修改算法逻辑，它只处理那些和算法本身无关，但会导致代码直接跑不通的低级问题，比如输入输出格式不对、少了某个头文件、整数类型宽度不够导致溢出。这些问题往往和"这道题该用什么算法"没有半点关系，纯粹是工程细节上的疏忽，但只要出现一处，代码就直接判为失败，非常冤枉。
这个修复环节只有在检测到这类底层错误时才会被触发，论文的统计显示，在完整版MARS的运行中，这个环节实际发挥作用、真正改动了代码的情况只占了0.2%，也就是165道测试题目里大概只帮上了一次忙。这说明底层的Gemma 4模型本身已经能把输入输出这些基础环节写得比较靠谱，这道保险大部分时候是备而不用，但一旦用上，往往就是那种"辛辛苦苦算对了，却因为一个格式错误满盘皆输"的冤案得到平反的时刻。
成绩单：分数、时间、成本的三方权衡
说了这么多设计思路，最终效果到底怎么样。
论文在CodeContests测试集上选取了165道题目，用谷歌的Gemma 4模型作为底层引擎，做了一系列对比实验。
| 方法 | 通过率 | 每题耗时（秒） | 每题Token消耗（千） |
|---|---|---|---|
| 直接提问（Direct） | 0.48 ± 0.02 | 34.9 ± 49.6 | 1.8 ± 1.2 |
| 单一RAG专家（Single-RAG） | 0.53 ± 0.01 | 59.8 ± 21.2 | 25.0 ± 3.2 |
| 并行集成（Parallel ens.） | 0.56 ± 0.00 | 360.9 ± 172.9 | 29.8 ± 5.1 |
| 基础接力（Base relay） | 0.55 ± 0.00 | 191.6 ± 91.5 | 34.1 ± 10.2 |
| **MARS** | **0.62 ± 0.01** | 244.3 ± 154.4 | 40.3 ± 8.1 |
| CodeSIM（对照组） | 0.73 ± 0.01 | 817.5 ± 1358.5 | 32.2 ± 54.8 |
先看最直观的数字：直接把题目丢给模型，什么都不做，通过率是48%。加上MARS的完整设计后，通过率提升到62.4%，多了整整14.4个百分点。这意味着什么？意味着原本每两道题里模型就要错过一道，现在这个比例改善到了接近每三道题只错一道多一点。
但真正让人眼前一亮的不是这个数字本身，而是MARS和CodeSIM的对比。CodeSIM是目前这个赛道里表现最强的框架之一，通过率高达73%，比MARS还高出十个百分点。可是它的代价也非常惊人：每道题平均要花817秒，也就是十三分钟以上，而且波动极大，标准差高达1358秒，意味着有些题目它会疯狂地反复调试。相比之下，MARS每道题只需要244秒，大约四分钟，是CodeSIM耗时的三分之一都不到。
这个权衡背后藏着一个更深的道理：CodeSIM靠的是"死磕"，在困难题目上它甚至会尝试多达45次调试迭代，硬生生靠数量堆出正确率。MARS靠的是"找对人"，用专业分工去减少无效尝试的次数。这两条路径谁更好，取决于你更在意什么。如果你是打比赛，时间不是问题，正确率才是唯一标准，CodeSIM更合适。但如果你是要把这套系统部署到实际的开发场景里，每次调用的成本和响应时间同样重要，MARS这种"花小钱办大事"的思路显然更实用。
论文里还专门统计了一个细节：MARS在token消耗上的标准差比CodeSIM小了大概七倍。这说明MARS的行为模式更加稳定和可预期，不会出现某道题突然消耗海量资源的极端情况，这对于需要控制预算的实际应用来说是个相当重要的优点。
再看难度分层的表现。论文把题目按Codeforces的难度分成简单、中等、困难三档。在简单题上，各种方法的表现都逼近满分，差距不明显。真正拉开差距的是中等和困难题：中等难度上，MARS的通过率是72%，而直接提问只有59%；困难题上，MARS达到40%，直接提问只有18%，相当于MARS把困难题的通过率翻了一倍还多。这个现象也印证了论文的核心论点：题目越难，越依赖精准的算法领域判断，专业分工的价值就体现得越明显。简单题目怎么写都能对，难题才是真正考验"知不知道用什么方法"的地方。
换个大脑、换种语言，结论还成立吗
一个方法好不好，不能只在一个模型上测。论文额外做了跨模型和跨语言的验证，这一步其实很关键，因为很多论文里的方法只在特定条件下管用，换个环境就失灵了。
论文还测试了把目标编程语言从C++17换成Python的情况。结果显示，MARS在Python上达到62.2%的通过率，直接提问只有48.5%，差距同样接近14个百分点，和C++17上的表现基本一致，只是Python版本运行速度慢了一些（307.6秒 vs 244.3秒），这大概和Python本身的解释执行特性有关。
值得一提的是，论文里还拿MARS和另一个叫PairCoder的框架做了对比。PairCoder在Python上达到70.5%的通过率，比MARS高出8.3个百分点，但耗时是MARS的1.4倍。更重要的是，PairCoder依赖一个商业化的文本嵌入模型来做方案聚类，而MARS全程用的都是开源组件。这个细节说明了一件事：MARS的优势不仅在效果，还在于它是一套完全开放、可以自由部署和二次开发的方案，不依赖任何闭源的关键组件。
拆掉零件看看哪个部分真的管用
任何一个复杂系统，最怕的就是说不清楚到底是哪个设计在起作用。论文做了细致的消融实验（ablation study），也就是每次拿掉一个组件，看看性能下降多少，以此判断这个组件到底有没有用。
> 消融实验：通过逐一移除系统中的某个组成部分，观察整体表现的变化，从而判断该部分对整体效果贡献大小的实验方法，类似于拆解一台机器，一个零件一个零件地卸下来看少了它还转不转得动。
结果显示，去掉RAG检索增强这个环节，通过率从62.4%下降到60.4%，掉了2个百分点。如果连专家的"专科"身份设定都取消，让所有专家变成通用型的全科选手（同时也去掉RAG），通过率是61.5%，仅比完整版低0.9个百分点，但这个版本反而更慢，每题多花31%的时间，调用次数也更多。
这组数据揭示了一个很微妙的现象：单独拿掉"专业分工"这个身份标签，对最终正确率的冲击其实不算大，但代价是效率明显变差，模型需要更多的试错和调用才能达到差不多的效果。这就像一个团队，即便不给每个人贴上明确的职责标签，靠着足够多的沟通和试错，最终结果也许差别不大，但过程会拖沓得多，开会更多，返工更多。MARS真正的价值，某种程度上不完全在于"能不能做对"，而在于"能不能更高效地做对"。
而如果去掉的是接力过程中的执行反馈机制（也就是论文里的"基础接力"版本，不做公开测试的自我检查），通过率直接掉到55.2%，跌幅达到7.2个百分点，这是所有消融实验里最大的一次下滑。这个结果说明，让专家在写代码之后能立刻看到跑测试的真实反馈，并据此决定是保留、修复还是交棒，这个环节才是MARS整个体系里最核心的支柱，比"专家分工"这件事本身更重要。
接力棒交到了谁手里
论文还统计了实际运行中，团队的组成规模和专家的活跃程度。数据显示，82.4%的题目最终动用了三个专家组成的满员团队，只有1.8%的题目一个专家就搞定了。平均下来，一个题目里真正动手改过代码的专家有1.35个，剩下没动手的专家可能只是在交接过程中确认了一下代码没问题就直接放行。
从专家的出场频率来看，数学、构造性算法、数据结构和动态规划这几个领域的专家被选中的次数最多，说明这几类知识在竞赛编程里是最通用、覆盖面最广的基础技能，而像博弈论、几何这种更细分的领域专家，只有在题目明确涉及相关标签时才会登场，属于"专科门诊"，平时不常开门，但一旦需要，作用不可替代。
论文里还给出了一个具体的运行案例，题目是Codeforces上一道叫"矩形上的三角形"的题目，涉及几何和数学知识。整个流程是这样展开的：数学专家先推导出面积公式和四条边的枚举方法，写出第一版代码，结果在公开测试里翻车了，因为矩形的宽和高在两条边上被算反了。同一个数学专家看到测试报告后，立刻定位问题并修复，重新提交的版本通过了测试。接着几何专家接手，把每条边的计算简化成端点相减，进一步优化了逻辑的清晰度。最后构造性算法专家完成了多组测试数据的读写框架、加速输入输出以及防止整数溢出的处理。三个专家各自完成了自己最擅长的那一部分，最终这份代码顺利通过了所有隐藏测试。
这个案例其实很好地展示了MARS的设计初衷：数学专家负责"想清楚公式对不对"，几何专家负责"把逻辑写得更优雅
宝盈优配提示：文章来自网络，不代表本站观点。
