MARS: 面向竞争性编程的多专家 LLM 接力系统

TL;DR MARS用检索增强的算法专题专家接力迭代生成和修复C++代码，在CodeContests上将解决率从直接提示提升14.4个百分点，逼近SOTA且成本低3.3倍。

问题

问题背景

多智能体 LLM 在代码生成与复杂推理任务中受到关注，但竞赛编程场景下现有系统的通用角色分工未能解决算法专业性不足的问题。

现有方法局限

现有流水线通常将任务分配给 planner、coder、debugger 等通用角色，算法技术选型完全依赖骨干模型自身能力。这使得模型在面对动态规划、图论、字符串等细分领域时容易出现知识覆盖不全或推理错误，且调试阶段缺乏针对主题的结构化修复策略，导致在 CodeContests 基准上直接提示的通过率偏低。此外，通用角色的迭代过程 token 消耗方差较大，成本不稳定。

为什么这个问题难/重要

竞赛编程要求结合算法理论洞察与题目特定约束，对长程推理、代码沙箱验证和知识检索能力要求极高。算法主题多样、题目新颖，模型需要快速定位正确技术路线并迭代修复错误。业界对多智能体系统在软件工程与数学推理中的落地持续关注，如何在有限预算内提升通过率并降低开销是核心挑战。MARS 的 专门化专家 + 检索增强生成(RAG) + 沙箱迭代 提供了一条可借鉴的路径。

行业类比

类似为不同编程语言构建专门的代码助手，而非依赖一个通用模型处理所有任务；这种“专家接力”模式可推广到复杂软件工程流水线中的多阶段代码生成与修复。

核心洞察

• MARS 用“算法领域专家”替代通用流程角色，将算法选择从单一主干模型解耦。现有多智能体系统通常分配 planner / coder / debugger 等通用角色，算法技术选择仍依赖模型自身预训练知识，导致在需要特定理论（如动态规划、图算法）时容易失败。MARS 让每个 agent 成为特定算法主题的专家，并通过 RAG 从算法理论语料库注入领域知识，使 LLM 不必仅凭记忆生成正确算法。这种将领域知识外部化到 agent 角色的设计，为需要深厚领域知识的任务提供了可复用的提示工程范式。
• 基于沙箱测试的接力式移交机制让专家动态决定保留、修复或移交草案，构建自适应流水线。传统多智能体流水线通常按固定顺序执行，难以适应问题难度和 agent 实际表现。MARS 在每轮将候选方案运行于公共测试用例，让活跃专家根据反馈采取行动：保留当前方案、修复错误或移交给下一个更合适的专家。这种“测试-反馈-决策”的闭环使流水线能够根据问题特性动态调整路径，避免在简单问题上浪费过多专家，或在困难问题上过早放弃。对工程实践而言，它展示了如何利用沙箱执行反馈作为多智能体协作的控制信号。
• 通过检索组队和末端基础设施修复，MARS 在接近 CodeSIM 性能的同时大幅降低计算成本与 token 消耗方差。CodeSIM 作为强基线，通过多次模拟和投票达到较高通过率，但墙钟成本高。MARS 只选择少量相关专家（平均 2.3 个流水线阶段）并仅做一次样板修复，以 3.3 倍更低的墙钟成本缩小差距，同时 token 消耗方差更小，意味着更稳定的资源需求。这在生产环境中具有实际意义：在预算受限或需要可预测延迟的场景下，这种轻量级但专业化的多智能体设计提供了性能与成本的平衡点。

方法

输入与问题定义

MARS 接收竞争编程题目文本与公开样例，并维护一个覆盖动态规划、图论、字符串、几何等主题的算法理论语料库。系统通过检索增强生成（RAG）将每个代理绑定到对应主题知识。

核心流程

1. 专家团队选择：基于题目嵌入检索相关主题，构建由若干主题专家组成的小团队。
2. 初始生成：一个 starter 专家生成首个 C++17 候选解。
3. 沙盒迭代接力：
   • 每轮将当前候选解在沙盒中运行于公开样例；
   • 当前专家根据测试结果执行保留 / 修复 / 移交三种动作之一；
   • 移交时生成结构化 packet，包含题目元信息、代码、测试输出与诊断，传递给下一位相关专家；
   • 每位专家都是 prompt-only 角色，不改变模型权重，仅通过角色提示与检索上下文区分。
4. 基础设施修复：接力结束后执行一次 boilerplate 规范化 pass，统一输入输出、宏定义等，输出最终可提交代码。

输出与差异点

输出为经过多轮迭代的 C++17 提交代码。与常见 generic planner/coder/debugger 多代理管线相比，MARS 将算法技术选择从单一 backbone 中显式解耦，通过主题专业化与检索驱动接力，以更低的 wall-clock 成本与更小的 token 方差缩小与 CodeSIM 的性能差距。

实验

实验设计

• 数据集：CodeContests test split，主要评估 backbone 为 Gemma 4。
• 对比基线：直接提示（direct prompting）与 CodeSIM（多智能体系统）。
• 协议：检索增强多专业智能体接力，沙盒测试公开样例，末尾 infrastructure-fixer 规范化。

关键发现

• MARS 达到 0.624 ± 0.006 pass rate，比直接提示高 +14.4 个百分点。
• 平均 pipeline stages 仅 2.3，说明接力精简高效。
• 与 CodeSIM 对比：pass rate 差距 0.107，但 wall-clock cost 降低 3.3 倍，且 per-task token 消耗方差更小。
• 消融与协议变体验证了专业化角色和交接机制的必要性。

基线对比解读

• 直接提示依赖单一 backbone 选择算法，MARS 通过检索多专家与结构化交接，弥补算法选择与实现之间的断层，提升明显。
• 相比 CodeSIM 的通用规划员/编码员/调试员流水线，MARS 以更低成本和更稳定的 token 开销逼近其性能，适合资源敏感或需要可预测成本的场景。

行业影响

落地场景

多专家 relay 架构 可直接用于需要算法代码生成的业务场景：

• 在线编程教育平台：自动解答竞赛题、生成可执行 C++17 代码并沙箱验证，提升题库维护与答疑效率。
• 企业算法研发：电商供应链优化、金融风控建模中的动态规划、图算法等模块，可作为内部代码生成助手。
• 自动化软件工程：嵌入 CI/CD 流水线，自动修复算法类缺陷。

商业价值

• 降本：相比 CodeSIM 高 3.3× wall-clock cost，MARS 用 prompt-only + 小模型 Gemma 4 达到 0.624 pass rate，token 消耗方差更小，推理成本显著降低。
• 增效：专业分工使问题定位更准，减少无效重试；+14.4 pp 的提升意味着更多任务一次通过，缩短开发周期。
• 体验：对开发者或学员，输出结果更稳定可复现。

与现有工作流集成

MARS 不依赖微调，可作为 prompt-only 模块 接入现有 LLM 应用栈：

• 替换通用 planner/coder/debugger 角色为 topic specialists，通过 retrieval 连接算法理论库（如 competitive programming 题解库）。
• 利用 sandbox（如 Docker）执行公共测试用例，集成到 LangGraph、AutoGen 等框架。
• 结构化 packet（问题描述、当前代码、测试反馈）便于在各 agent 间传递，与现有 API 网关兼容。

具体 use case

1. 电商平台：动态定价或库存分配问题涉及动态规划，MARS 可接收自然语言需求，产出经测试的 C++ 微服务核心算法。
2. 在线教育：编程练习平台自动生成题解并验证正确性，降低人工出题成本。

局限

• - 对公开测试用例的潜在过拟合：MARS 在迭代过程中将候选代码运行在公开示例上，并依据结果决定是否保留、修复或移交，这可能导致代理过度针对公开用例进行调整，从而降低对隐藏测试集的泛化能力。竞争性编程的最终评测通常依赖私有测试数据，而该方法缺少明确的防过拟合机制（如交叉验证或正则化），因此在实际竞赛中可能面临性能衰减的风险。
• - 依赖预定义的专家类型与算法理论语料库：专家主题（动态规划、图、字符串、几何等）需要预先设定，并且检索增强依赖一个精心维护的算法理论语料库。这限制了系统的可扩展性和对新问题类型的适应性——若问题不属于预定义类别或需要跨领域知识，系统可能无法有效处理。此外，语料库的质量和覆盖范围至关重要，构建和维护成本较高，且泛化到其他编程任务或领域的可行性尚未验证。
• - 准确率仍低于 CodeSIM，且主要结果仅基于单一骨干模型：MARS 在 CodeContests 测试集上达到 0.624 的通过率，而 CodeSIM 为 0.731，差距约 10 个百分点。虽然成本显著降低，但在要求高精度的场景中仍显不足。摘要仅报告了 Gemma 4 的结果，其他骨干模型（第 4.2 节）的表现未在摘要中呈现，可能效果不佳或需要额外调优，方法的跨模型通用性有待进一步验证。