论文链接：https://dl.acm.org/doi/10.1145/3712003

这篇论文梳理地很细致，值得一读。

本篇中的参考文献标号直接使用的原文的标号，可对照原文直接查询对应papers。

1、多智能体系统（Multi-Agent System）是由多个智能体组成的计算框架，智能体通过交互、协调与知识共享共同解决复杂问题。随着 LLM 的引入，形成了 LLM-Based Multi-Agent Systems，作者定义该系统由两个主要部分组成：Orchestration Platform（编排平台）和 LLM-Based Agents（基于大模型的智能体）。

（1）Orchestration Platform（编排平台）

        编排平台是系统的核心基础设施，负责管理智能体之间的交互与信息流动，确保协作有序。它包含三个关键特征：

        a. Coordination Models（协作模型），它定义智能体之间如何交互，类比于现实团队的协作关系结构：Cooperative：协作型（共同目标）、Competitive：竞争型（个体目标可能冲突）、Hierarchical：层级型（主从结构）、Mixed：混合型（多种模式结合）

        b. Communication Mechanisms（通信机制），决定信息如何流动：Centralized（集中式）——由中央智能体负责调度。Decentralized（去中心化）——智能体直接通信。Hierarchical（层级式）——信息通过权力层级流动。在软件工程语境下，交换的信息形式（代码片段、提交信息、论坛帖子、漏洞报告等）。

        c. Planning and Learning Styles（规划与学习方式），定义多智能体系统中的计划与学习模式，强调任务如何分配、协调与学习。：

        Decentralized Planning, Decentralized Execution：完全分布式规划与执行。

        Centralized Planning, Decentralized Execution：集中规划、分布执行。

（2）LLM-Based Agents（基于LLM的智能体）

• 每个智能体都有独特的能力与角色，用于提升系统在多样化任务中的表现。可分为两种属性：

• Predefined or Dynamically Generated（预定义或动态生成）

• 智能体可事先定义好角色，也可由 LLM 动态生成 → 具备灵活性与自适应能力

• Homogeneous or Heterogeneous（同质或异质）

• 同质：功能相同（如多个“程序员”智能体并行执行）。

• 异质：功能不同（如“架构师”“测试员”“产品经理”等角色分工）。

2、作者工作主要包括了SE的几个方面：需求工程（requirements engineering），代码生成（code generation），软件质量保证（QA），软件维护（software maintenance）。

        论文检索策略：使用DBLP 数据库进行关键词检索，DBLP是SE调查中广泛使用的资源，该数据库覆盖 750 万+ 篇计算机科学文献。使用了两组关键词：

• [Agent words]：与 LLM 多智能体系统相关，如 “Agent” OR “LLM” OR “Large Language Model” OR “Collaborat”；

  [SE words]：与软件工程任务相关，如：

• Maintenance（维护）：debug, repair, refactor, patch

• QA（质量保证）：bug, test, vulnerab, validat

• Code Generation（代码生成）：software, code, program

• Requirements Engineering（需求工程）：requirement, specification, stakeholder

• 最终检索式：[Agent words] AND [SE words]，确保涵盖软件生命周期的四个阶段。其中内部的每个词用OR连接。

在说到检索关键词的确定上，作者这样陈述：Papers may use variations of the same keyword. For example, the term “vulnerability” may appear as “vulnerable” or “vulnerabilities.” To address this, we use truncated terms like “vulnerab” to capture all related forms.

• 筛选标准如下：

• 

        滚雪球检索（Snowballing Search），为补充遗漏的研究，作者进行了：

• 后向滚雪球：查找已纳入论文的参考文献；

• 前向滚雪球：查找引用这些论文的后续研究。

  该过程重复进行直到无新增论文，共补充 30 篇 相关研究。

3、Requirements Engineering（需求工程）

        需求工程关注如何定义和管理软件系统的需求，确保其符合质量标准与用户目标。 LMA 系统在需求分析阶段的典型框架和角色设计包括：需求获取（elicitation）→ 建模（modeling）→ 规格化（specification）→ 分析与验证（analysis & validation）。

框架	角色与机制	特点
Elicitron [9]	多个基于 LLM 的“模拟用户”智能体，进行产品交互，表达需求、观察与挑战。	专注于需求获取阶段，通过模拟用户群体收集需求洞察。
MARE [59]	五类智能体：stakeholder、collector、modeler、checker、documenter。	覆盖需求获取、建模、验证与规格说明四阶段；共执行九种操作。
Sami et al. [115]	四类智能体：product owner、developer、QA、manager。	多智能体协作生成与优先排序用户故事（user stories）；QA 评估风险、developer 评估技术可行性、manager 负责整合与决策。

4、Code Generation（代码生成）

代码生成一直是软件工程自动化的核心研究方向，LMA 框架在这一阶段的重点是多角色协作与反馈循环（feedback loop），以提高代码质量与开发效率。

常见的角色与功能：

角色	主要职责
Orchestrator（协调者）	高层规划与任务分配，负责目标拆解、进度监控与整体流程衔接。
Programmer（程序员）	编写初始代码。
Reviewer（审查员）	代码评审与质量反馈。
Tester（测试员）	测试与问题发现（可生成测试用例）。
Information Retriever（信息检索者）	检索外部知识、代码示例或上下文。

典型系统与机制：

系统	特点
PairCoder [158]	Navigator 负责规划、Driver 负责实现 → 模拟“驾驶员/导航员”式协作。
Self-Organized Agents [56]	母智能体（Mother）层级式分派任务给子智能体（Child）。
CODES [155]	RepoSketcher 将需求转化为代码仓库草图（结构+依赖），再由下级智能体生成文件与实现。
INTERVENOR [132]	Code Learner + Code Teacher 互评机制：Learner 写代码，Teacher 根据错误报告反馈修复策略。
Self-Repair [102]、TGen [96]	使用测试反馈循环修复错误。
Agent4PLC [87]、MapCoder [57]	引入 Retrieval Agent，检索相似代码案例与知识以辅助生成。
CodexGraph [85]	使用图数据库（graph DB）与静态分析，Translation Agent 将查询转化为图查询语言。
Agent Forest [77]	多智能体独立生成候选方案，通过“相似性投票”选出最优结果。

5、Software QA（软件质量保证）

这一节聚焦于 LMA 系统如何提升软件测试、漏洞检测、缺陷分析与故障定位等任务。

QA 的四个核心方向：

(1) Testing（测试）：多智能体用于自动化生成测试用例、执行测试与评估结果。

• Fuzz4All [149]：使用 distillation agent 简化用户输入，generation agent 生成并变异测试输入，跨语言进行模糊测试。

• AXNav [123]：自动化可访问性测试系统，含 Planner、Action、Evaluation 三类智能体，解释自然语言测试指令并在设备上执行。

• WhiteFox [150]：编译器优化的模糊测试框架，两个智能体：一个提取需求，另一个生成测试程序。

• 其他任务：渗透测试、用户验收测试、GUI 测试等，也都用到 LMA 协作框架。

(2) Vulnerability Detection（漏洞检测）

• GPTLens [51]：针对智能合约漏洞检测，多个 auditor agents 独立审计，critic agent 过滤误报、优先级排序。https://arxiv.org/pdf/2310.01152

• MuCoLD [94]：多角色协作（tester、developer）通过多轮讨论与迭代达成漏洞共识分类。

• Widyasari et al. [142]：引入交叉验证机制：多个 LLM 相互验证，提高漏洞分类可靠性。

• https://arxiv.org/abs/2409.01001

(3) Bug Detection（缺陷检测）

• ICAA（Intelligent Code Analysis Agent）[35]：

  • 多智能体用于静态代码分析；

  • Report Agent 生成报告；

  • False-Positive Pruner 消除误报；

  • Code-Intention Consistency Checker 对比代码与开发者意图是否一致。

  • https://arxiv.org/abs/2310.08837

(4) Fault Localization（故障定位）

• RCAgent [138]：利用多智能体收集系统数据与日志，在云环境中进行根因分析。

• AgentFL [110]：将定位过程分三步：Comprehension Agent 识别可能出错区域；Navigation Agent 精确缩小搜索范围；Confirmation Agent 验证错误。

6、Software Maintenance（软件维护）

(1) Debugging（调试）

特点：多智能体形成闭环 → “发现错误 → 提议修复 → 审核验证 → 再反馈”，实现上下文感知与自我改进的调试循环。主要任务：错误定位 → 生成补丁 → 修复验证。

代表框架：

系统	特点
FixAgent [70]	Learner–Teacher 机制：Learner 提出修复方案，Teacher 审查反馈。
AutoCodeOver [165] / SpecRover [113]	用语义和语法树表示程序，自动修复并验证。
MASTER [152]	Code Quizzer、Learner、Teacher 三智能体交替学习式调试。
ACFIX [160]	结合 RBAC（访问控制）模式检测合约漏洞并自动修复。
DEI [159]	多智能体共同决定最优补丁并利用元策略（meta-policy）做重排序。
SWE-Search [7]	包含 SWE-Agent、Value Agent、Discriminator Agent，通过蒙特卡洛树搜索协同修复。
RepoUnderstand [92]	使用知识图谱与代码依赖理解，辅助跨模块调试。

(2) Code Review（代码审查）

系统	特点
Rasheed et al. [111]	自动化代码审查系统，检测臭味代码（code smell）、漏洞和优化建议。
CodeAgent [124]	代码审查多子任务分工（漏洞检测、一致性检查、格式验证等）；QA-Checker 监督智能体间交互质量。

特点：审查过程由多智能体分工执行，既能提高审查速度，又提升评审一致性与准确性。

(3) Test Case Maintenance（测试用例维护）

• Lemner et al. [74] 提出两个多智能体体系结构，预测哪些测试用例在源代码变更后需要更新。

• 智能体执行任务包括：总结代码变更；识别触发维护的因素；定位受影响的测试用例。

7、End-to-End Software Development（端到端软件开发）

        在软件工程语境中，它是指从最初的需求分析开始，到最终交付一个可运行的软件产品的整个过程。不是只写几段代码，而是覆盖软件开发的全生命周期（SDLC）。

        传统代码生成 ≈ “帮你写一个函数”；End-to-End 开发 ≈ “帮你完成整个项目”。

        LMA 系统的端到端设计借鉴了传统的软件过程模型（如 Agile 敏捷开发 和 Waterfall 瀑布模型），但通过多智能体协作，使各阶段能自动衔接。每个阶段（需求、设计、实现、测试）由具备特定专业知识的智能体负责，通过协作完成整个流程。

主要的软件过程模型

(1) Waterfall Model（瀑布模型）

        各阶段顺序进行，前一阶段完成后再进入下一阶段。多智能体框架中，每阶段分配不同角色：

        Requirement Analysis → Architecture Design → Code Development → Testing → Maintenance

框架	特点
MetaGPT [48]	Product Manager → Architect → Engineer → QA Engineer形成严格的线性生产流程；强调角色职责清晰与可追踪性。
AgileCoder [101] / AgileGen [163]	采用 Agile 迭代模式（见下）。

 Waterfall 模型的特点：结构化、线性、有明确责任划分；强调可控性与质量保障，但灵活性较差。

（2）Agile Model（敏捷模型）

• 强调快速迭代、小步开发、持续反馈。LMA 通过角色分工模拟 Scrum 与 Sprint 机制。

框架	特点
AgileCoder [101]	智能体扮演 Product Manager 与 Scrum Master；组织短周期迭代。
AgileGen [163]	引入 Gherkin 语言，将需求转化为可测试用例，实现需求到实现的桥接；人机协同强化对齐度。

Agile LMA 的创新：人类与 AI 角色并存，AI 参与需求、设计、测试环节；强调快速反馈与持续改进。

瀑布模型与敏捷模型示意图

（3）动态与自适应流程（beyond fixed models）

这些系统突破传统“固定阶段”的结构，转向灵活的、自适应的开发流程，适合复杂、个性化项目。

框架	特点
Think-on-Process (ToP) [82]	动态流程生成框架：LLM 根据项目需求自定义流程蓝图（非固定角色/阶段）。
MegaAgent [135]	智能体角色与任务根据项目上下文动态生成与规划；支持上下文适配与跨任务协作。

（4）经验学习与知识迁移

Co-Learning [107]：智能体通过学习历史项目中的执行记录进行协同优化；Instructor 与 Assistant 智能体形成互助学习关系。

Qian et al. [108]：提出迭代式经验优化框架，智能体持续积累并选择性重用历史开发经验，以提升后续项目的效率与协作质量。

这部分强调 “经验复用（Experience Reuse）” —— LMA 不再是一次性执行器，而是具备长期学习与改进能力的持续开发团队。

8、第四章作者选取当前最具代表性的 LMA 框架ChatDev [109]，并用它自动开发两个经典游戏：Snake（贪吃蛇）和 Tetris（俄罗斯方块）。

下面是文章使用的两个prompt：

结果：ChatDev 在两次实验中均能完成从需求到交付的完整开发流程；展现出端到端（End-to-End）自动开发的可行性；但仍有如下问题：可重复性低（不同运行结果存在差异）；错误修复依赖人工干预（部分代码需手动调试）。