如果你让一个大模型去参加算法竞赛最常见的失败方式不是“完全不会做”而是“读懂了题、写出了代码、提交之后只过了几个测试点”。这种卡在临门一脚的情况几乎每个用 LLM 做过编程题的人都遇到过。更麻烦的是你很难定位问题出在哪个环节是题目理解偏差、算法选型失误、代码实现有隐藏 bug还是边界条件没覆盖单独的提示词工程很难同时解决所有环节因为一次对话里塞进去的约束越多模型输出的稳定性反而越差。MARS 多专家接力框架针对的正是这个问题。它不追求一个超长 prompt 让模型“一步到位”而是把算法竞赛题的解题流程拆成多个专家角色每个角色只负责一段明确任务再按顺序接力产出中间结果最后通过统一的评分与反馈模块决定是否继续修正。据项目介绍这套思路能在大语言模型算法竞赛场景下把正确率提升 14 个百分点。如果这个目标能够落地它改变的不只是竞赛成绩还重新定义了用 LLM 解决复杂任务时的任务分解与执行方式。这篇文章会围绕 MARS 框架展开先讲清楚大模型做算法竞赛题为什么难再拆解多专家接力的设计思路和工程流程然后给出一个可以本地复现的简化版 Python 示例帮你理解每个阶段该做什么、怎么验证效果最后整理实际接入和调优时最容易踩的坑。1. 大模型做算法竞赛题瓶颈到底在哪很多开发者第一次让 LLM 写算法题时得到的反馈是“惊艳且不完整”。模型能在几十秒内生成一段结构完整的代码但提交到判题系统后经常只通过部分测试点。于是我们开始怀疑模型智商不够其实问题更可能出在任务执行的“过程管理”上。算法竞赛题的标准解题路径包含几个连续环节理解题面、抽象数学模型、设计算法、处理边界、编写可运行代码、修正回归。对人类选手来说这些步骤是内化的但对大语言模型来说每一步都存在独立的误差来源。题目理解层竞赛题往往有冗长的输入输出描述模型容易忽略某些修饰语比如“非负整数”和“正整数”的区别。算法选型层模型可能记住了常见题型的套路但判断不出这题是否带有特殊约束比如数据范围大导致 O(n^2) 超时。代码实现层即使思路正确生成的代码也可能出现变量名覆盖、循环边界差一、递归栈溢出等细节问题。验证回归层单次生成通常不会主动构造边界用例来验证更不会根据失败用例反推修正逻辑。传统 prompt 工程的做法是尝试把以上所有要求写进一个很长的 system prompt 中比如“请仔细阅读题目、分析复杂度、写出代码、并考虑边界条件”。这种做法的问题是上下文太长、约束互相干扰模型很难在同一段生成过程中做到全局最优。你要求它越仔细它反而越容易在自己已经生成的中间结论上自我强化最终在同一个错误方向上越走越远。MARS 的切入点很简单与其让一个模型同时扮演所有角色不如让多个“单一职责”的专家角色依次接力每个环节只做一件事并把上一阶段的输出作为下一阶段的结构化输入。这样既降低单次 prompt 的认知复杂度又能在每一个环节的入口做人工或程序化校验。2. MARS 多专家接力框架的核心设计MARS 这个名字强调的是“多专家 接力”。在竞赛解题任务里它把一个完整的生成过程拆成多个阶段每个阶段由一个专门的角色负责。角色之间不是并行发言而是严格顺序接力上一棒的输出会成为下一棒的上下文基础。用流程表达大致是这样的题目原文 - 题目理解专家提炼约束、边界、样例说明 - 算法设计专家确定算法、复杂度分析 - 代码实现专家生成完整代码 - 测试验证专家构造用例并尝试运行 - 修正专家根据失败用例做针对性修改 - 提交结果这种设计有几个关键点。第一中间产物是显式的。传统单次 prompt 中模型的“思考过程”是隐式的你很难知道它是从哪里开始跑偏的。MARS 要求题目理解专家先输出一段结构化描述算法设计专家再基于这段描述去设计解法。一旦最终结果错误你可以回溯到具体的接力段观察是哪一段的产出不合理。第二每个专家的工作上下文是克制的。题目理解专家只需要面对原文不需要思考代码算法设计专家只面对理解结果不需要直接生成代码。这样每个阶段的 prompt 都很短、目标明确模型输出更可控。第三反馈循环是闭环的。如果最终代码没有通过测试用例系统会构造一个失败的输入样例让修正专家基于旧代码和新证据重新产出补丁。多轮直到满足通过率门限。从工程本质看MARS 解决的其实是复杂任务的“上下文治理”问题。它并不是发明了新的模型能力而是改变了使用模型的方式把一步大生成变成多步小生成把互相冲突的约束分散到不同阶段把失败归因从黑盒变成可定位的环节。这也解释了为什么它声称能在正确率上带来十几个点的提升——因为大部分错误是过程管理导致的而不是模型能力本身的硬上限。3. 与传统单次生成方案的区别为了让你更直观理解 MARS 的改进我把传统单 prompt 方案和 MARS 多专家接力方案做一个对比。对比维度传统单 PromptMARS 多专家接力任务拆分不拆分一条 prompt 完成按解题阶段拆成多个独立任务上下文长度单次很长约束互相干扰每阶段短小目标单一失败定位难以确定错误来源可定位到具体接力环节修正方式重新生成一遍成本高基于失败用例定向修正中间产物隐式不可检查显式可记录、可校验适用任务简单题、一次性生成复杂算法题、多条件约束题这个对比并不意味着传统方案一无是处。对于简单题比如“两数之和”单 prompt 一次性生成的效率更高。MARS 的价值主要体现在中等偏难的竞赛题上题目条件复杂、边界情况多、最终代码需要多轮调优。另一个容易被忽略的差异是可审计性。算法竞赛题通常有严格的输入输出要求一次错误的生成可能耗时半小时调 bug。MARS 的中间产物天然形成了一条可审计的链路你可以看到题目理解专家把哪些条件丢了算法设计专家选择了什么复杂度的方案。这种可审计性对于生产环境中的代码生成任务尤为重要因为人工审查只审查最终代码是不够的还得知道这段代码是怎么被推导出来的。4. 环境准备与前置条件要复现一个简化版 MARS 流程你不需要特殊硬件只要一个能调用大模型 API 的 Python 环境和对应的 API Key。本文的示例代码以 OpenAI 风格的接口为例模型层面使用通用 Chat Completion 接口即可。如果你用的是 DeepSeek、通义千问或者其他兼容接口只需要修改base_url和模型名称。为了避免版本锁定这里不写死某个模型版本相关参数以你实际使用的环境为准。建议环境如下Python 3.10 以上本文代码兼容 Python 3.8。openaiPython SDK如果你自己用 requests 封装也可以。一个具备代码生成能力的大模型 API建议使用支持 JSON 输出或高上下文窗口的模型。本机具备 Python 执行环境因为测试验证阶段需要运行模型生成的代码。安装依赖只需要一行命令pip install openai python-dotenv建议把 API Key 放在环境变量中而不是直接写进代码文件export LLM_API_KEYyour_api_key_here export LLM_BASE_URLhttps://api.openai.com/v1 export LLM_MODELgpt-4o-mini如果你使用的是国内大模型的开放平台对应的base_url和模型名以平台文档为准。这里的关键是只要接口能接收messages数组并返回文本内容就可以用同样的方式接入框架。5. 核心流程拆解与简化实现为了让思路更容易在天花板以内复现我实现一个简化版的多专家接力流水线。这个实现不是 MARS 框架的官方源码而是参考其设计思想写的最小可运行版本代码分成三个文件模型调用封装、流程编排、验证与修正。5.1 封装 LLM 调用# mars_demo/llm_client.py import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1) ) MODEL os.getenv(LLM_MODEL, gpt-4o-mini) def call_llm(system_prompt: str, user_prompt: str, max_tokens: int 2048) - str: resp client.chat.completions.create( modelMODEL, messages[ {role: system, content: system_prompt}, {role: user, content: user_prompt}, ], max_tokensmax_tokens, temperature0.2, ) return resp.choices[0].message.content.strip()这个封装保持最小必要功能。temperature0.2的原因是接力流程中我们希望模型输出更稳定少一点发散。如果某个阶段需要创造性方案比如算法设计也可以临时把温度调高到 0.6 左右。5.2 定义多专家接力流程下面的代码把解题过程拆成四个阶段题目理解、算法设计、代码实现、测试与修正。每个阶段只接收上一阶段的结构化输出。# mars_demo/pipeline.py from llm_client import call_llm PROBLEM 给定一个长度为 n 的整数数组 a以及一个整数 k。 请找出所有长度为 k 的连续子数组中的最大值并输出这些最大值的集合去重后按升序排列。 n 10^5a[i] 10^9。 PHASES [ { name: 题目理解, system: 你是一名算法竞赛题目理解专家。请从题目中提炼出输入格式、输出格式、数据范围、边界情况和可能的陷阱。只输出提炼结果不要编写代码。, template: 请理解下面的算法竞赛题并输出结构化理解结果\n{problem}, }, { name: 算法设计, system: 你是一名算法设计专家。请基于题目理解结果设计时间和空间复杂度合适的算法。只描述算法思路、数据结构和复杂度不要编写完整代码。, template: 题目理解结果\n{understanding}\n\n请设计算法。, }, { name: 代码实现, system: 你是一名 Python 算法实现专家。请根据算法设计编写完整可运行的 Python 代码包含标准输入输出处理。只输出代码不要额外解释。, template: 算法设计\n{algorithm}\n\n请输出 Python 代码。, }, ] def run_pipeline(): context {problem: PROBLEM} for phase in PHASES: user_prompt phase[template].format(**context) result call_llm(phase[system], user_prompt) context[phase[name].lower()] result print(f {phase[name]} ) print(result[:800]) print() return context if __name__ __main__: context run_pipeline()上面代码中的context就是接力棒的传递容器。每一阶段的结果都会按名称存进去比如understanding、algorithm后一个阶段通过template读取这些字段。使用str.format的好处是模板清晰但你需要注意字段名一旦拼错就会抛 KeyError实际工程里建议改用字典插值或直接拼接字符串。5.3 测试验证与修正循环单一轮的四阶段接力只做到了“生成一条龙”但没有形成闭环。MARS 真正有效的地方是加入验证和修正机制。下面这个模块会把生成的代码保存为临时脚本然后运行一组由本地构造的测试用例根据失败结果让修正专家产出新的代码。# mars_demo/evaluate.py import subprocess import tempfile from llm_client import call_llm from pipeline import PROBLEM def run_code(code: str, input_data: str) - str: with tempfile.NamedTemporaryFile(suffix.py, modew, deleteFalse, encodingutf-8) as f: f.write(code) fpath f.name try: proc subprocess.run( [python, fpath], inputinput_data, capture_outputTrue, textTrue, timeout5 ) return proc.stdout.strip() except Exception as e: return fERROR: {e} def evaluate(code: str, test_cases: list) - tuple[bool, dict]: passed 0 failed_cases [] for i, (inp, expected) in enumerate(test_cases): actual run_code(code, inp) if actual expected: passed 1 else: failed_cases.append({case: i 1, input: inp, expected: expected, actual: actual}) total len(test_cases) return passed total, {passed: passed, total: total, failed_cases: failed_cases[:3]} def fix_code(code: str, failure_report: str) - str: system_prompt 你是一名代码修正专家。根据失败的测试用例和实际输出分析 bug 原因并输出修正后的完整 Python 代码。只输出代码。 user_prompt f原始代码\n{code}\n\n失败报告\n{failure_report} return call_llm(system_prompt, user_prompt) if __name__ __main__: # 这里假设已经从前一阶段得到了代码 context run_pipeline() code context[代码实现] test_cases [ (5 2\n1 3 2 4 5\n, 3 4 5), (1 1\n42\n, 42), ] ok, report evaluate(code, test_cases) print(f首次通过率: {report[passed]}/{report[total]}) if not ok: new_code fix_code(code, str(report[failed_cases])) ok2, report2 evaluate(new_code, test_cases) print(f修正后通过率: {report2[passed]}/{report2[total]})这个模块里最关键的设计是run_code的隔离执行。LLM 生成的代码是不可信的直接在当前进程里 exec 存在风险所以这里用子进程执行并设置 timeout。它避免了某个死循环把所有用例全部拖死。生产环境中应当再加上资源限制和沙箱而不是仅仅使用超时保护。验证模块的用法是先用少量手工构造用例做快速回归通过后再用完整的官方测试集做最终评测。为什么先用少量手工用例因为 LLM 调用的 token 成本不低每一轮修正都要消耗请求次数。小用例能快速判断大方向是否对节省成本。6. 运行结果与效果验证运行完整流程的方法如下cd mars_demo python pipeline.py python evaluate.py第一次运行时你会看到四段输出题目理解的提炼结果、算法设计的方案、生成的代码以及最终通过率。预期正常的结果是首次通过率: 1/2或修正后通过率: 2/2。如果所有用例一次就通过说明算法思路和实现都正确如果首次未通过重点检查失败的测试用例。注意文章开头提到的“正确率提升 14 个百分点”是项目公开介绍中的效果指标。在你本地的简化实现中能否复现同样的提升幅度取决于题目难度、模型能力和测试集设计。更稳妥的判断是MARS 的价值主要体现在“从 60 分提升到 80 分”这类过程性改进上而不是把完全不会做的题目变成全对。验证阶段要重点关注三个信号首次通过率反映模型在单轮生成中的准确性。MARS 的目标之一就是提升首次提交通过的概率。修正后通过率反映回环修正机制的效果。如果修正后通过率没有提升说明失败报告的信息不够充分或者模型被旧代码带偏了。修正轮次正常情况应当控制在 1 到 3 轮。超过这个次数说明前一阶段的理解或设计已经错得太远继续修代码意义不大应该回溯到题目理解阶段重新接力。7. 常见问题与排查思路实际使用这类框架时常见问题并不是“模型能力不够”而是工程细节没有处理好。我整理了一张问题排查表。问题现象可能原因排查方式解决方案代码始终超时被终止LLM 生成的代码复杂度太高查看算法设计阶段的输出在算法设计 Prompt 中强制加入复杂度上限要求或在后续接力中重新设计算法上下文越来越长导致部分内容被截断多轮修正后上下文累积检查提交给模型的 token 数截断失败用例数量控制每轮修正只携带最近的 1 到 2 个失败用例修正轮次过多且每次修改方向漂移修正 Prompt 包含太多旧代码干扰观察修正前后的 diff让修正专家只关注失败用例涉及的函数片段而不是重写整个文件测试用例全部运行时间过长用完整测试集做快速回归统计单次执行耗时先用 3 到 5 个手工用例做回归通过后再跑完整测试集中间产物格式不稳定Prompt 太自由模型输出格式不统一检查题目理解阶段的输出格式在 Prompt 中明确要求使用固定标题比如“约束:”“陷阱:”或改用 JSON 输出生成的代码包含无法运行的语法错误某个阶段上下文传递丢字段打印 context 中的代码内容在run_pipeline里每个阶段结束后校验非空输出必要时直接中断这些问题的共同点是多专家接力的收益建立在“每个环节的输出质量可控”之上。如果某个环节的输出是不可靠的错误只会被接力放大。所以实际工程中每个角色阶段的 Prompt 设计和输出格式校验重要程度不亚于最终代码生成。8. 适用边界与最佳实践MARS 不是万能的它的收益是“过程管理”带来的不是模型能力本身的提升。如果一道题超出了模型的知识边界或者模型根本没有见过类似题型多几个专家接力也不会凭空创造出正确答案。因此使用这套思路之前先判断任务是否符合以下特征。适合的场景题目描述长需要先提炼约束再设计算法。边界条件多一次生成很难覆盖全。测试反馈可自动化有判题脚本或单元测试。解题过程需要审计比如你在做竞赛练习并想分析自己模型在哪一步犯错。不适合的场景简单题比如基础数据结构操作单次生成已经足够好多阶段反而增加延迟和成本。需要与外部环境强交互的编程任务比如动态网页自动化、数据库运维操作这些任务的安全风险远大于竞赛题生成。对延迟敏感的场景每次调用 API 至少增加几百毫秒到数秒完整接力可能需要超过一分钟。在最佳实践方面我建议关注以下五点。第一角色 Prompt 要“单一职责”。题目理解专家的 prompt 里不要出现“如果可能顺便给一段伪代码”一旦越界输出形态就难以控制。每个角色的目标必须是一个可验证的产物。第二中间产物要结构化。最简单的做法是让模型按固定标题输出比如“输入约束:”“边界条件:”“算法复杂度:”。如果条件允许可以要求模型输出 JSON然后在 Python 里解析校验。结构化中间产物能大幅降低后续阶段的解析难度。第三修正循环必须限制轮数。设置最大修正次数比如 3 轮。超过次数后强制回退到算法设计阶段重新设计。这比无限修正更稳定因为当模型连续两次针对同一个 bug 修改失败时说明错误已经被固化在代码结构里继续局部修补只会越改越乱。第四控制验证成本。不要在每一轮修正中都跑完整测试集。一个可行策略是第一轮只跑基本样例和边界样例等通过率到了 80% 以上再切换到完整测试集。这样既省成本又不会让模型在大量失败用例中迷失重点。第五注意合法授权与安全边界。如果这套流程用于生产环境必须确保你有权调用模型 API并且对模型生成的代码做安全审查。自动执行生成的代码时应当放在沙箱容器中限制文件系统、网络和时间而不是直接在本机或生产服务器上运行。LLM 生成的代码可能包含隐藏的恶意逻辑即使是竞赛题代码也应当先人工审查再接入正式项目。从团队协作角度看MARS 的中间产物可以作为协作文档保存。比如题目理解结果可以提交到代码仓库的 issue 中算法设计作为设计文档最终代码作为实现失败用例作为测试样例。这相当于把“人写题”留下的思考痕迹也变成了模型写题的可审计资产。9. 下一步可以怎么继续探索MARS 这样的多专家接力框架本质上是在做 Agent 化和流程化之间的过渡设计。它的思路在大模型应用领域并不算新奇核心就是 task decomposition任务分解但落地难点在于每个角色之间的“交接棒”格式怎么设计以及反馈循环怎么控制。你可以继续从三个方向深入。第一个方向是尝试使用结构化输入输出格式来规范中间产物。给每个专家角色加一个输出 JSON Schema让接力更稳定。第二个方向是把测试集接入回归体系。准备一份通用评测脚本让每一次修正都自动计算通过率并把历史通过率记录成曲线观察模型的修正是否真的单调提升。很多情况下修正会让一个用例通过的同时让另一个用例挂掉只有曲线才能暴露这种震荡。第三个方向是让“修正专家”拥有工具能力。目前简化版只是让模型读失败用例文本更强的方式是让修正专家直接运行代码、打印变量、构造新用例也就是菜鸟级“调试 Agent”。这一步对环境的隔离和权限管理要求更高但也是从竞赛题走向真实 Debug 场景的关键路径。回到开头的问题大模型做算法竞赛题“看懂了却写不对”单纯增加 Prompt 长度是解决不了的。MARS 给了一个更工程化的答案把解题过程拆开、让每个角色专注做一件事、把失败用例变成修正证据、把调试过程变成闭环。对于想在算法竞赛训练中使用 LLM 的开发者真正值得学习的不是某个魔法 Prompt而是这套“接力 回环”的流程治理思想。下一篇文章里可以进一步分析如何在 MARS 基础上接入外部评测判题环境把生成、运行、判分做成一个完整的自动化训练回路。