大杀器！多Agent系统进入自动化编程领域，程序员会失业吗？

关注

原创最新推荐文章于 2026-07-11 18:37:52 发布 1.5k 阅读 AI 写同款· GEO 优化 ›

多Agent系统定义、概念、特点及概念模型 1. 多Agent系统（MAS） 1) 定义由分布在网络上的多个问题求解器松散耦合而成的大型复杂系统，这些问题求解器相互作用以解决由单一个体的能力知识所不能处理的复杂问题。 2) 特点每一主体具有有限信息资源和问题求解能力，缺乏实现协作的全局观点。系统不存在全局控制，即控制分布知识与数据都是分散的。计算是异步执行的。 3) 分类 1. 根据主体的自主性进行分类 1) 由控制主体和被控主体... 阅读详情

多Agent应用` `开源代码

MapCoder: Multi-Agent Code Generation for Competitive Problem Solving

代码合成是一项艰巨的任务，它要求深入理解复杂的自然语言描述，生成复杂算法和数据结构的代码指令，并通过全面的单元测试。尽管大型语言模型（LLMs）在自然语言处理上表现出色，但在代码生成方面仍有局限。本文提出了一种新颖的多代理提示方法，模拟人类开发者的程序合成全周期，包括回忆示例、规划、代码生成和调试。我们的 MapCoder 框架通过四个 LLM 代理实现这一过程，并在多个基准测试中展示了其卓越的代码生成能力，刷新了 HumanEval、MBPP、APPS、CodeContests 和 xCodeEval 的记录。此外，该方法在不同编程语言和问题难度上均表现出色。我们已在 GitHub 上开源 MapCoder 框架。

https://arxiv.org/abs/2405.11403

背景

大语言模型写代码已经不足为奇了，但是大语言模型直接写的代码往往不尽如人意，尤其是一些复杂问题编程的时候。

早期的大语言模型编程，采取的是直接输入提示词的方法，直接根据问题描述、样本示例输入输出来生成代码。这样的效果往往不是最好的，近期，大家通过一些新的提示工程方法，比如思维链，进行代码模块化、伪代码生成等方法来增强代码生成时的规划能力和减少错误。

同样，基于检索的方法，即利用相关问题和解决方案来指导LLM生成代码也可以提高代码生成的准确性和效果。

但是这些方法在复杂任务上还是进步有限，生成的代码往往无法通过测试用例，并且缺乏错误修复机制。

自我反思（Reflexion）是一种有希望的解决方案，通过迭代评估生成的代码与测试用例的匹配度，反思错误并进行相应修改。

为了突破以上方法的局限性，提升LLM写代码的能力，作者提出和开发了MapCoder，项目地址：https://github.com/Md-Ashraful-Pramanik/MapCoder。

在这里插入图片描述

简而言之，MapCoder是一个模仿人类程序员编程习惯，使用LLMs进行检索、规划、编码、调试的一个多Agent智能体系统。

MapCoder的架构？

MapCoder的灵感来自人类程序员编程习惯，通过多个LLM智能体（Agent）：检索、规划、编码、调试来实现。为此，创建了一个智能体Pipeline，将四个Agent进行串联，借助管道上游Agent的上下文学习信号来增强下游Agent的能力。

但并非所有Agent的反馈都同样有价值。因此，MapCoder还引入了一个自适应的Agent遍历机制（上图下部分），允许Agent之间动态交互，通过迭代改进，比如修复缺陷，来优化代码生成，同时最大化利用大语言模型的潜力。

检索Agent

作为首个登场的检索Agent，它像人类的记忆力一样，回顾并找出与当前问题相似的过往问题解决案例。

与其他检索不同的是，检索Agent的并不需要人工介入或者外部检索模型，而是直接利用大语言模型来生成这些相似的问题。

基于提示词（如上图），同时产生示例及其解决方案，并附带问题描述、代码和计划等附加元数据，为后续Agent提供辅助信息。

• 首先指导LLM生成相似而又有区别的问题及其解决方案，以促进问题规划的逆向工程。
• 接着引导LLM逐步生成解决方案代码，便于后续处理形成相应计划。
• 最后指导LLM生成相关算法并提供教学指导，使Agent能够深入理解底层算法，并生成算法上相似的示例。

规划Agent

第二个登场的规划Agent，其目标是为原始问题制定一个分步计划。规划Agent利用检索Agent提供的示例及其计划，来生成针对原始问题的计划。

最直接的方法是将所有示例汇总，共同生成一个目标计划。但是，并非所有检索到的示例得作用都是等同的。随意串联示例可能会影响LLM生成准确计划的能力。所以，为每个检索到的示例生成一个独特的目标计划。此外，多个计划能够提供多样化的成功路径。

为了帮助后续Agent在生成步骤中了解每个计划的效用信息，为规划Agent设计的提示要求LLM同时生成计划和置信度评分。上图展示了规划Agent的提示词。

编码Agent

紧随其后的是编码Agent。它接收问题描述和规划Agent提供的计划作为输入，将这些计划转化为解决该问题的代码。在Agent的序列执行过程中，编码Agent拿到原始问题和规划Agent提出的特定计划，生成代码，并在一些样本输入输出上进行测试。如果初始代码未能通过测试，Agent会将其传递给下一个Agent进行调试。如果代码通过测试，则假定其为最终解决方案。

调试Agent

作为流程的最后一环，调试Agent利用问题描述中的样本输入输出来修正代码中的错误。就像人类在修复错误时会反复核对计划一样，系统通过规划Agent提供的计划来辅助调试Agent。这种基于计划的调试方法显著提升了MapCoder在错误修复方面的能力，凸显了调试Agent和规划Agent在整个代码生成过程中扮演的核心角色。对于每个计划，这个过程会重复执行多次（提示词见上图）。与Reflexion（Shinn等人，2023年）和AlphaCodium（Ridnik等人，2024年）不同，调试Agent在流程中无需生成任何额外的测试用例。

动态Agent遍历

MapCoder的动态遍历从规划Agent开始，它为原始问题生成带有置信度评分的计划。这些计划会根据得分进行排序，得分最高的计划将被发送给编码Agent。编码Agent将计划转化为代码，并用样本输入输出进行测试。如果测试全部通过，则代码会被返回；如果未通过，则代码会被传递给调试Agent。调试Agent会尝试迭代地修正代码，最多尝试多次。如果调试成功，代码会被返回；如果失败，则会转回规划Agent，以获取下一个置信度最高的计划。

这个迭代过程会持续进行多次，反映了程序员解决问题的方法。上图展示了MapCoder解决问题的方法与直接方法、思维链方法和反射方法的对比。

如何评估MapCoder的效果？

数据集

为了进行广泛的评估，采用了八个标准的基准数据集：五个涵盖基础编程，三个涉及复杂的竞技编程。

在基础编程方面，选用了 HumanEval、HumanEval-ET、EvalPlus、MBPP 以及 MBPP-ET 这五个数据集。

在竞技编程方面，选用了三个数据集：自动化编程进度标准 (APPS)、xCodeEval 和 CodeContest。

对比模型

将 MapCoder 与多种基线和尖端方法进行了比较。

• 直接提示是让语言模型在没有明确指引的情况下生成代码，这依赖于大语言模型Agent应用的内在能力。
• 思维链提示则是将问题拆解为一步步的解决方案，有效应对复杂任务。
• 自我规划提示将代码生成任务分为规划和实施两个阶段。
• 类比推理提示则是指导模型回想训练数据中的相关问题。
• 反思通过单元测试结果提供反馈，以提升解决方案的质量。
• 自我协作提出了一个框架，让不同的LLMs分别扮演分析师、编码员和测试员的角色，共同协作生成复杂任务的代码，展现出比单一Agent应用更优的性能。
• AlphaCodium 则是基于 AI 生成的输入输出测试来迭代优化代码。

MapCoder效果均优于其他方法

从上表看，MapCoder在代码生成上显著超越了所有基线方法，并在所有基准测试中创造了新的最先进成果。通常来说，与ChatGPT相比，GPT-4的规模表现更佳。

使用不同模型的性能

在这里插入图片描述

为了展示MapCoder在不同大语言模型上的稳健性，使用Gemini Pro这一不同的最先进大语言模型家族，如上表所示。

还使用开源大语言模型Mistral-7B instruct（见上表）。

不同编程语言上的性能、

此外，还评估了MapCoder在不同编程语言上的性能。使用了xCodeEval数据集，它支持多种语言。上图显示，MapCoder在不同编程语言上与基线相比实现了一致的熟练度。

各Agent作用的影响

通过移除MapCoder中的特定Agent进行了研究，以评估每个Agent在我们整个流程中的作用。与预期中想象的一样，每个Agent都是流程中不可或缺的一部分，关闭任何一个Agent都会影响MapCoder的性能。

特别地，调试Agent对流程的影响最为显著，仅当它被排除时，性能下降了17.5%，而在所有情况下平均性能下降了24.83%。

规划Agent的重要性位列其次，其在所有情况下的平均性能下降为16.7%。

局限性

在这里插入图片描述

• 首先，MapCoder 会消耗大量Token，这可能在资源受限的环境中造成挑战。上表展示了在默认参数设置下平均API调用和令牌消耗的数量，未涉及最小化令牌/ API调用的问题，计划在未来的研究中解决。
• 其次，MapCoder目前基于样本输入输出对进行错误修正。虽然样本输入输出对为大语言模型的代码生成提供了宝贵的洞见，但其数量有限，可能无法完全覆盖所有可能的测试案例。因此，提升额外测试用例生成的质量可以减少对样本输入输出的依赖，进而增强MapCoder的稳健性。
• 此外，对诸如 CodeLLaMa、LLaMa3、Mixtral 8x7B 等开源代码生成模型的进一步探索，可能会为MapCoder带来宝贵的见解和潜在的改进。另一个重要的考虑是，在执行机器生成的代码时，建议在沙箱环境中运行，以规避潜在风险.