📒论文笔记

基本信息 标题: AGILE CODER: Dynamic Collaborative Agents for Software Development based on Agile Methodology 作者: Minh Huynh Nguyen、Thang Chau Phan、Phong X. Nguyen、Nghi D. Q. Bui（通讯作者） 作者单位: FPT Software AI Center、Fulbright University 期刊/会议: FORGE(ICSE) 2025 (CCF-A, EI) 发表年份: 2025.07.02 DOI: 10.1109/Forge66646.2025.00026 开源地址: Github 关键词: Software Development, Multi-Agent System, Large Language Models 研究问题 (Research Questions) 解决仓库级别的代码生成问题 研究背景 (Background) 专业软件开发的敏捷方法 敏捷源自敏捷宣言 [agi, 2001]，是一种灵活的软件开发方法，强调交付最终产品的实用主义。它促进持续交付、客户协作以及快速适应不断变化的需求。与瀑布模型等传统线性方法不同，敏捷通过Sprint（短周期）采用迭代开发，可以快速调整和频繁重新评估项目目标。这种迭代方法增强了与客户需求的一致性，并促进团队内部的开放沟通和共同责任。敏捷的适应性使其对于管理需求可能随时间变化的复杂项目特别有效。通过将敏捷原则与软件开发中的协作代理相结合，我们为设计多代理系统提供了一种新颖的视角。 仓库级别的代码理解和生成 在存储库级别生成代码是现实世界软件工程任务中大型语言模型（llm）面临的重大挑战。现实世界的代码库是复杂的，具有相互连接的模块，并且随着上下文大小的增加，llm面临限制。这导致了选择相关上下文的研究并优化其使用。软件智能体，如ChatDev和MetaGPT，旨在生成功能齐全的可执行软件，包括各种文件，类和模块，而不仅仅是像HumanEval [Chen等人，2021]或MBPP [Austin等人，2021b]中简单任务的解决方案。这要求代理在生成代码或修复错误时理解所有现有上下文，包括文件、类、函数和库。然而，在以前的研究中，对全面的库级代码理解和生成的需求经常被忽视。 核心贡献 (Key Contributions) 引入了AgileCoder，是一种受到敏捷开发启发的新型多智能体软件开发框架，强调智能体之间的有效沟通和增量开发。 引入了动态代码图生成器（DCGG）将静态分析方法整合到多智能体工作流中，该生成起可以动态生成代码依赖图（CDG）。这个图会记录代码库的演变过程中各个代码组件之间的依赖关系，为智能体提供了一个可靠的来源以获取相关上下文信息，从而提高了生成工程的质量。评估结果显示，使用了CDG获取到的上下文信息，性能表现显著增长。 实验证明AgileCoder在HumanEval、MAPP上达到了SOTA，并提出了ProjectDev作为软件开发的Benchmark。在这个框架上，超越了MetaGPT和ChatDev。 方法 (Methodology) 上图呈现了AgileCoder的总体框架，其中包括多个智能体：产品经理（PM, Product Manager）、敏捷开发负责人（SM, Scrum Master）、开发人员（Dev, Developer）、高级开发人员（SenDev, Senior Developer）和 测试人员（Tester）， 各个智能体通过敏捷开发方式进行协作开发。开发过程包括执行环境（Execution Environment）以在测试期间运行代码，并有动态代码生成器（DCGG）在代码更新时动态生成代码依赖图（Code Dependency Graph）。执行环境（Execution Environment）为智能体提供回溯以进行代码优化，而DCGG使智能体能够获取相关上下文以准确地生成和修正代码。...

基本信息 标题: Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies 作者: Han Zhou（通讯作者）、Ruoxi Sun、Hamid Palangi、Shariq Iqbal、Ivan Vulić、Anna Korhonen和Sercan Ö. Arık。 作者单位: Google和剑桥大学 期刊/会议: ArXiv 发表年份: 2025.02.04 DOI: 2502.02533 开源地址: Github 关键词: Multi-Agent System, Large Language Models 研究问题 (Research Questions) 大语言模型，作为多个相互交互协作的智能体，可以解决复杂任务。这些智能体通过声明其功能的提示词以及协调智能体间交互的拓扑结构进行编程。本文所研究的主要问题是优化多智能体系统中的提示词以及智能体的拓扑结构。 研究背景 (Background) 尽管最近的研究探讨了自动化智能体设计各个方面，但在理解哪些因素对改进MAS性能最为关键方面仍存在差距。例如，DSPy自动化了设计示例以改进提示编程的过程。J Li(More agents is all you need作者)提出通过扩大多数投票中的代理数量来优化MAS。ADAS通过基于LLM的元代理编程代码表达的新拓扑。AFlow在预定义操作集中使用蒙特卡洛树搜索来寻找更好的拓扑。然而，包括提示词和拓扑在内的多个设计空间之间的相互作用仍然不明确。 核心贡献 (Key Contributions) 深入分析了影响基于LLM的MAS性能的设计因素，强调了prompt的重要性，并确定了有影响力的拓扑结构。 提出了一种名为Mass的新型多阶段优化器，通过在具有影响力的搜索空间中交错优化prompt和拓扑结构来自动化MAS设计。 大量数据在各种评估基准上显示出显著的性能提升，为构建有效的未来多智能体系统提供了指导。 设计多智能体系统（Designing Multi-Agent Systems） 作者认为MAS的设计可以分为两个层级：块级设计(Block-level)和工作流编排(Workflow-level orchestration)。对于块级，目标是设计单个智能体，通过更好的提示词设计最好的提示词来表现出特定的角色。对于工作流编排，它的优化涉及要包含智能体的类型和数量，以及如何以最有效的方式编排他们，这被称为拓扑优化。 $\mathcal{W}^{*}(a)=\arg\max\mathbb{E}_{(x,y)\sim\mathcal{D}}[f(\mathcal{W}(a)(x)),y]$ 块级：智能体的提示词设计（Block-level: Prompt Design for Agents） 对于块级，对下游任务影响最主要的是prompt，它定义了智能体的角色（例如，“You are an expert in reflecting on errors…”），提供额外的指令来塑造其行为（例如，“You should think step by step…”）以及可选地包含少量示例（zero-shot/one-shot/few-shot）来指导智能体的回复。比如，一种SOAT提示词优化器同时搜索指令和少量示例，其中示例是从模型自身在验证集上的正确预测中引导出来的，基于验证指标。基于这些示例，提示词优化器会为指令提出一些候选方案，并提供数据集摘要或各种提示词以提高候选方案的多样性。然后指令和示例会被联合优化。...

基本信息 标题: DocAgent: A Multi-Agent System for Automated Code Documentation Generation 作者: Dayu Yang（通讯作者）、Antoine Simoulin、Xin Qian等。 作者单位: Meta AI 期刊/会议: ArXiv 发表年份: 2025.04.11 DOI: 2504.08725 开源地址: Github 关键词: Code Documentation, Multi-Agent System, Large Language Models 研究问题 (Research Questions) 如何自动生成代码文档注释，尤其是处理函数/类中复杂的依赖关系和上下文信息？ 研究背景 (Background) 像现在的方法FIM（Fill in the Middle）和 chat agent可以实现自动化生成文档注释，但还是有一些局限性： 省略了必要的信息（例如，参数或返回值描述）。 它们通常提供最少量的上下文或理由，限制了生成文档注释的价值。 由于LLM的幻觉，会虚构不存在的组件，尤其是规模比较大的项目中。 核心贡献 (Key Contributions) DocAgent，一个多智能体、拓扑结构化的上下文感知文档生成系统。 一个衡量代码文档完整性、实用性和事实一致性的稳健评估框架。 全面实验表明，DocAgent在多个数据集中持续优于最先进的基线。 方法 (Methodology) DocAgent分两个阶段来处理复杂的依赖关系并确保上下文的相关性。 用一个Navigator确定一个最佳的依赖感知的处理顺序 Multi-Agent System系统增量地生成文档注释，利用专门的Agent进行代码分析、信息检索、编写文档注释和验证 Navigator: 感知依赖顺序 生成文档注释需要理解依赖代码之间的关系，然而如果给出所有内容，很容易超出上下文窗口的限制。Navigator模块就是为了解决这个问题，Navigator建立了一个处理顺序，确保处理依赖关系之后才对组件做文档注释，从而实现增量上下文构建。 构建依赖图 首先对整个存储库进行静态分析，解析源文件的抽象语法树（AST，Abstract Syntax Tree），以识别代码组件（函数、方法、类）及其相互关系（函数调用、继承、属性方法和模块导入），用一个有向无环图（DAG， Directed Acyclic Graph）来表示，节点是组件，边是依赖关系。为了实现拓扑排序，用Tarjan算法检测图中的循环，并将其浓缩单个超级节点。...

基本信息 标题: Paper2Code: Automating Code Generation from Scientific Papers in Machine Learning 作者: Minju Seo, Jinheon Baek, Seongyun Lee, Sung Ju Hwang等。 作者单位: KAIST, DeepAuto.ai 期刊/会议: ArXiv 发表年份: 2025 DOI: 2504.17192v2 开源地址: Github 关键词: Large Language Models (LLMs), Code Generation（Machine Learning） 研究背景 (Background) 尽管机器学习研究的迅速增长，但相应的代码实施通常无法实现，这使研究人员重现结果并在先前的工作基础上进行劳动密集型。同时，最近的大型语言模型（LLMS）在了解科学文档并生成高质量代码方面表现出色。 研究问题 (Research Questions) 用agent复现机器学习相关的论文方法与实验 核心贡献 (Key Contributions) 提出从科研论文自动生成代码的框架: PaperCoder ​​三阶段工作流程​​：PaperCoder框架将代码生成任务分解为三个结构化的阶段，规划、分析、编码。 构建基准数据集（包含90篇来自ICML、NeurIPS和ICLR 2024的论文） 在PaperBench基准测试中的优异表现：在新发布的PaperBench基准测试中，PaperCoder表现出色，显著优于其他强基线方法。 方法（Methods） 作者引入了PaperCoder，是一种新颖的框架，用于实现研究仓库（论文复现出来的代码仓库）的生成。作者将工作过程建模为M(R) = C，其中M是模型，R是论文，C是代码。受软件开发方法的启发，作者采用了一种结构化的方法，该方法反映了良好的经验验证的软件工程原则，即：规划-分析-实现的工作流程。为了实现这一目标，作者将过程分解为三个阶段：1）规划（Planing）. 2）分析（Analyzing）. 3）编码（Coding）。每个阶段都利用多智能体方案。更加规范化的定义是C = M (P) = M_code(R, P, A)，其中R是论文，P是规划，A是分析。每个部分的生成遵循：P = M_plan(R), A = M_analysis(R, P) and C = M_code(R, P, A)。完整的流程如下图所示：...

基本信息 标题: PlanGEN: A Multi-Agent Framework for Generating Planning and Reasoning Trajectories for Complex Problem Solving 作者: Mihir Parmar、Xin Liu等 作者单位: Google、Arizona State University 期刊/会议: ArXiv 发表年份: 2025 DOI: 2502.16111 开源地址: 🈚️ 关键词: Agent 研究背景与问题 (Background & Questions) 有效的计划是设计在解决复杂现实世界问题的系统的关键组件。传统的用模板化的方式缺乏通用性。 LLM 可以较好的做一些规划任务，比如用 LLM 在自然语言中做规划可以解决一些代码问题。因此作者考虑增强 LLM 生成计划的能力，并证明其在科学和金融领域下游任务的实用性。 核心贡献 (Key Contributions) 总结本文的主要贡献点： PlanGEN，一种新颖的、模型无关的、可扩展的多智能体框架，用于增强LLM的自然规划。 在一些复杂规划和推理的 Benchmarks 上达到了 SOTA 级别。 一种基于约束的验证和基于实例级复杂性的推理算法选择的新方法。 PlanGEN LLM Agents PlanGEN 包括三个 大模型 Agent：Constraint Agent、 Verification Agent 和一个 Selection Agent。每个Agent使用现成的 LLM（如：Gemini, GPT）。...

基本信息 标题: MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework 作者: Sirui Hong、Mingchen Zhuge、Chenglin Wu（通讯作者）等。 作者单位: DeepWisdom、阿卜杜拉国王科技大学、厦门大学、香港中文大学、南京大学、宾夕法尼亚大学、加州大学伯克利分校、瑞士人工智能实验室 期刊/会议: ICLR 2023 发表年份: 2023 DOI: 2308.00352 开源地址: Github 关键词: MetaGPT, Multi-Agent Collaboration, Standardized Operating Procedures (SOPs), Large Language Models (LLMs), Code Generation 研究背景 (Background) 利用大语言模型的Agent为增强和复制人类的工作流程提供了机会。但是实际应用中，现有系统将复杂问题过度简化。很多人想努力实现有效、连贯和准确的解决问题，尤其是需要协作的任务。而SOP可以有效的分解任务并且协调各个任务，明确的SOPs能够提高任务执行的一致性和准确性，确保其与定义的角色和质量标准相符。 研究问题 (Research Questions) 如何使用应用SOPs与Agent协作开发。 如何优化Agent协作通信能力。 如何提高代码生成的质量。 核心贡献 (Key Contributions) 总结本文的主要贡献点： 引入了MetaGPT，一个基于LLM的多智能体协作元编程框架。 作者在MetaGPT设计中创新性地集成了SOP，减少了LLM的代理之间的无效协作。此外，还引入了一种新颖的执行反馈机制，可以在运行时调试和执行代码，从而提高了代码生成的质量（MBPP上提高了5.4%） 在HumanEval和MBPP达到了SOAT MetaGPT 框架 (MetaGPT Framework) SOP中的Agent（Agents in Stanndard Operating Procedures） 角色的特定职能 解决复杂的任务或问题通常需要具有不同技能和专业知识的智能体协作，每个智能体都针对特定问题提供专门的输出。如在一家软件公司，产品经理的任务是分析业务、软件工程师负责编程开发。因此MetaGPT定义了五个角色：产品经理（Product Manager）、架构师（Architect）、项目经理（Project Manager）、工程师（Engineer）以及QA工程师（QA Engineer）。如下面图1所示： 图1：MetaGPT与真实世界人类团队之间的软件开发SOPs。...

基本信息 标题: Evaluating Large Language Models Trained on Code 作者: Mark Chen、Jerry Tworek、Heewoo Jun、Qiming Yuan等 作者单位: OpenAI, Anthropic AI, Zipline 期刊/会议: arXiv 发表时间: 2021年7月14日 DOI: 2107.03374 开源地址: GitHub 关键词: 代码生成, 代码评估, 代码理解 研究背景(Background) 对于代码生成任务由于语言模型的推动最早的研究在1963、1971年就开始了（Experiments with a heuristic compiler、Toward automatic program synthesis）,最近的有基于掩码语言模型(masked language modeling)和跨度预测(span prediction)改编用于训练其编程对应物的有CodeBert和PyMT5。OpenAI在GPT3发布的时候，就已经可以通过文档注释(docstrings)生成python代码了，但是能力还是比较有限。 研究目标(Research Objectives) 提出一种评估大型语言模型生成代码能力的方法，包括pass@k指标和HumanEval数据集。 提出Codex，通过对GPT-3进行微调。 提出Codex-S，通过有监督微调Codex。 提出Codex-D，通过训练docstring生成模型。 评估框架 (Evaluation Framework) 作者定义了pass@k指标，以及HumanEval数据集，用于评估Codex的性能。 功能的正确性(Functional Correctness) 评估生成质量可以通过匹配的方式：精确匹配或模糊匹配（如BLEU得分）。然而有研究揭示了基于匹配的代码评估指标的不足。如论文CodeBLEU: a Method for Automatic Evaluation of Code Synthesis中发现BLEU在捕捉代码特有的语义特征方面存在问题，并建议对分数进行几个语义的修改。更加根本的问题是，基于匹配的方式无法评估庞大的并且复杂的代码。近期无监督的代码翻译或伪代码到代码的翻译相关问题也转向了功能性准确性的评估，如果样本通过了测试用例，那么就认为生成的代码是正确的。作者认为这种方式应用到代码生成的评估中是合理的。评估功能正确性最有说服力的理由是程序员常使用这种方式进行评估（单元测试）。 Kual等人在2019(SPoC: Search-based Pseudocode to Code)就用了pass@k，对于每个问题生成k个代码样本，如果其中有一个样本通过了单元测试就认为问题已得到了解决，并计算解决问题的总比例。然而作者认为以这种方式计算pass@k会有很高的方差，而且计算量大。相反，为了评估pass@k，我们给每个任务生成n个样本（n > k, 论文中使用n = 200, k = 100）, 统计通过单元测试的正确样本数c（c <= n），并计算无偏估计量。其中 $\text{pass@}k := \mathbb{E}_{\text{Problems}} \left[ 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} \right]$。...