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

发布时间：2024 年 05 月 18 日

多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带来宝贵的见解和潜在的改进。另一个重要的考虑是，在执行机器生成的代码时，建议在沙箱环境中运行，以规避潜在风险.

• • 论文原文: https://arxiv.org/abs/2405.11403

• • 获取更多最新 Arxiv 论文更新: https://github.com/HuggingAGI/HuggingArxiv!

• • 加入社群，+v: iamxxn886