AI4SE 论文阅读：《Large Language Model-Based Agents forSoftware Engineering: A Survey》

写在前面

这篇文章主要是对于《Large Language Model-Based Agents for Software Engineering: A Survey》这篇科研性质的文献进行阅读与总结。文章于2024年9月发表于arXiv，主要介绍了大型语言模型（LLMs）在软件工程（SE）领域的最新进展，并总结产生的 LLM-Agent 服务于软件工程的综述性文章。据文章所述，这是首次专门针对基于LLMs for SE 的综述型文献。

总体来看，所选文章为软件工程领域提供了一个全面和系统的LLM基础代理的综述，在LLM agent兴起并极大程度取代人类程序员重复“造轮子”的时代背景下，对于软件工程的发展具有借鉴意义，引发“时下AI agent 如何演化产生新的软件工程和开发模型”的深刻思考。

我选取这篇论文基于自身团队发展过程中，正在探索一种Agent与人类工程师协作的敏捷模型。早期的敏捷开发总是小而精的，容易受限于面向架构的成规模开发；而大语言模型对于架构的热知识在储备量上远超人类，更容易在特定领域、特定架构下实践 DSSA 或 CBSE，缺点是则是对全局记忆难以维持，常常需要重新解释。我正在寻找一种能够支持小型团队在架构视角下开发系统，并能驱动AI，产生持续性协作的开发模型。如果你有好想法，欢迎友友来讨论~！

关键词：大型语言模型；软件工程；智能代理；程序生成；软件测试

原文链接：arXiv:2409.02977v1

摘要和文献搜集工作

随着大型语言模型（LLMs）的快速发展，基于LLM的智能代理在软件工程（SE）领域展现出了显著的应用潜力。与传统的独立LLM相比，LLM基础的智能代理通过集成外部资源和工具的感知与利用能力，极大提升了LLM的通用性和专业能力。本文综述了LLM基础智能代理在SE中的应用现状，系统地收集并分析了106篇相关论文，并从SE和智能代理两个维度进行了分类。此外，本文还探讨了该领域的开放性挑战和未来发展方向。

综述结构如下：

该综述所引用文献的入选标准：

如果一篇论文满足以下任何一项标准，则将被纳入我们的调查：（i）该论文提出了使用基于LLM的代理来解决特定SE任务的技术、框架或工具;（ii）该论文提出了适用于各个领域的通用技术、框架或工具，前提是其评估至少包括一项SE任务;（iii）本文提出了一个实证研究，评估了基于LLM的Agent在特定SE任务上的表现

Agent for SE 方向的发展：下图显示了截至2024年7月10日随时间推移发表的论文累积数量。研究者注意到，对这一领域的研究兴趣不断增加，突出了这项调查的必要性和相关性。

大多数论文来自arXiv，尚未经过同行评审。这是预料之中的，因为这一领域正在出现，而且仍在迅速发展。

Agent for SE不同活动的研究现状：

除了自动执行单个RE阶段之外，一些代理还可以处理多个RE阶段

正文内容

Basic Framework of LLM-based Agents

基于LLM的代理（LLMs Agent）通常由四个关键组件组成：规划，记忆，感知和行动。规划和记忆是LLM控制的大脑的关键组成部分，它通过感知和行动组件与环境相互作用，以实现特定的目标。

其四个关键的组成部分的详细描述如下：

规划（Planning）

规划组件将复杂任务分解为多个子任务，并调度子任务以实现最终目标。具体地，Agent 可以生成计划而不需要通过不同的推理策略进行调整，或者利用外部反馈（例如，环境反馈或人反馈）。

记忆（Memory）

记忆组件记录在 Agent 执行期间生成的历史思想、动作和环境观察结果。在此基础上，Agent可以重新访问和利用以往的记录和经验，从而更有效地处理复杂的任务。存储器管理（即，如何表示记忆）和利用（即，如何读/写记忆内容）是必不可少的，这直接影响Agent系统的效率和有效性。

感知（Perception）

感知组件接收来自环境的信息，这可以促进更好的规划。特别地，Agent 可以感知多模态输入，文本输入、视觉输入和听觉输入。

行动（Action）

基于大脑做出的规划和决定，行动组件进行具体的行动，与环境互动并影响环境。一个重要的作用机制是控制和利用外部工具，这可以通过访问更多的外部资源和扩展超出文本单独交互的动作空间来扩展LLM的固有功能。

Advanced LLM-based Agent Systems

Multi-agent Systems.（多智能体系统）

可以实现多个Agent之间的协作可以进一步解决与不同知识领域相关的更复杂的任务。

在多智能体系统中，每个Agent都被分配了不同的角色和相关的专业知识，使其专门负责不同的任务;此外，Agent可以相互通信，并在任务进行时共享进度/信息。通常，Agent可以协同工作（即，通过在不同的子任务上工作以实现最终目标）或竞争性地（即，通过在进行对抗性辩论的同时进行相同的任务）

Human-Agent Coordination.（人机协调）

Agent系统可以进一步合并来自人类的指令，然后在人类的指导下继续执行任务。这种人-代理协调模式有助于更好地与人类偏好保持一致，并使用人类的专业知识。特别是在人机交互过程中，人类不仅可以向智能体提供任务需求和当前任务状态的反馈，还可以与智能体合作，共同实现目标。

Requirements Engineering（需求工程）

需求工程（Requirements Engineering, RE）是软件工程中的一个重要阶段，它涉及到从利益相关者那里获取、分析和文档化软件需求的过程。需求工程的目标是确保软件开发团队对用户的需求有准确的理解，并在整个开发过程中管理这些需求的变化。需求工程通常包括以下几个阶段：需求的收集（Elicitation）、建模（Modeling）、协商（Negotiation）、规格说明（Specification）、验证（Verification）和需求的演化（Evolution）。

在现实世界的软件开发中，RE可能需要大量的手动工作，因为需要与各种利益相关者进行大量的交互。尽管研究人员已经利用深度学习模型（包括独立的LLM）来促进需求工程活动，但他们中的大多数仍然停留在RE期间的单个任务上，例如分类[49]，规范[50]，信息检索[51]，评估[52]和现有需求的增强[53]。最近，多智能体系统被设计为自动化单个阶段或多个阶段。表2总结了专门为RE设计的现有基于LLM的Agent，下图说明了它们的通用pipeline。

启发（Elicitation）是一个多Agent框架，旨在全面挖掘需求工程中的用户需求。它通过初始化多个具有不同角色的Agent来模拟用户交互，并记录交互过程中的行动、观察和挑战，以识别潜在需求。这种方法在降低成本的同时，能有效发现并分类隐藏需求。例如，SpecGen系统专注于从Java程序中生成需求规格说明。它通过生成JML规范、进行验证以及变异验证失败的规范来迭代优化，以生成更全面的规格说明。
 

Code Generation

随着人工智能技术的进步，代码生成已成为一个广泛研究的领域。大型语言模型（LLM）由于在海量文本数据，尤其是大型代码库上的预训练，已展现出在根据给定代码上下文或自然语言描述生成代码方面的潜力。然而，LLM生成的代码有时会因幻觉等问题而不完美。因此，研究人员不仅利用独立的LLM进行代码生成，还开发了基于LLM的Agent，这些Agent通过规划和迭代细化来提升LLM的能力。图7展示了现有的LLM如何在代码生成任务中增强独立LLM的功能。
 

使用规则的代码生成

使用规划生成代码是指在代码生成过程中，LLM基础的智能体会采用一种系统化的方法来分解复杂的编程任务，将其拆解为多个子任务，并为这些子任务制定执行顺序和计划，以实现最终的编程目标。这种规划过程涉及到智能体的“大脑”部分，即LLM控制的核心，它通过与环境的交互来调整和优化规划步骤。

具体来说，规划组件负责将复杂的编程任务分解成一系列更小、更易于管理和执行的子任务。这些子任务可以是算法的选择、数据结构的设计、代码逻辑的构建等。在制定了详细的计划之后，智能体会根据这个计划来指导代码的生成过程，确保每一步都能够朝着最终目标迈进。例如，CodeCoT是一种利用链式思考（Chain-of-thought）策略的LLM基础Agent，它通过将给定的需求分解成用自然语言描述的步骤，然后将这些步骤转换成代码。这种方法可以提高代码生成的正确性，并使得生成的代码更加符合预期的功能和逻辑。通过这种方式，LLM基础的智能体能够更有效地处理复杂的编程任务，生成更高质量、更可靠的代码。

使用迭代细化的代码生成

在代码生成过程中，LLM基础的Agent不仅生成初始代码，而且通过迭代的方式对代码进行持续的优化和改进。这种方法的核心在于，Agent能够根据环境反馈（如模型反馈、编译错误、测试结果或人类反馈）来动态调整和完善代码。

在迭代细化的过程中，智能体首先生成一段代码，然后通过执行、测试或其他验证手段来收集关于这段代码的反馈。根据这些反馈，Agent识别出代码中存在的问题或不足之处，并据此调整其生成策略，以产生更好的代码版本。这个过程可以重复多次，每次都基于前一次迭代的结果进行改进，直到达到满意的代码质量为止。反馈的形式可以有以下几种：

模型反馈

1）Peer-reflection.（同行反映） 多个模型之间的信息交换和交互。最常见的范例是通过角色专门化和结构化通信（例如，代码审查）。这种方法强调了每个角色的专门职责以及其交互的信息。例如：DyLAN 允许多个Agent参与多轮动态交互，组织成多层前馈网络。

2）Self-reflection.（自我反省） 单个模型进行自我改进，这意味着当前修改基于模型的先前输出，通过这种方法迭代优化。受益于自然语言反馈，每增加一轮自然语言反馈，绝对性能就会提高2-17%

工具反馈

由模型生成的代码可能质量有限，具有许多不确定性。解决这一难题的一个解决方案是配备工具，这些工具可以收集信息反馈并帮助Agent生成和细化代码。

1）动态执行工具。调用编译器、解释器和执行引擎来直接编译或执行代码。这种方法利用输出和运行时行为，如测试结果或编译错误，作为代码改进的反馈

2）静态检查工具。通过代码分析工具，Agent可以获得更多关于代码约束的知识。例如，一些Agent应用静态分析工具来获得语法有效的程序符号或代码生成期间代码之间的依赖关系。将分析的信息包括到提示中可以引导LLM生成有效代码。

3）检索工具。Agent可以通过应用检索或搜索工具来访问丰富的外部资源。例如，一些代理检索本地知识库[86]，例如私有API文档。通过API提供有用的信息，可以减轻对LLM的幻觉。

人类反馈

另一种方法涉及将人类反馈纳入过程，因为人类在澄清模糊的需求方面发挥着关键作用。例如，在软件开发中，人们可以检查生成的代码是否符合他们的初始意图。例如，ClarifyGPT 自动识别手动给定需求中的潜在歧义，并主动向人类提出相关问题;然后人类的响应进一步用于细化需求。

混合反馈

Agent还可以合并多种类型的反馈，并作为混合反馈逐渐增强彼此。具体地，LLM接收在执行程序或测试用例之后返回的错误消息，并利用其上下文理解来提供相应的反馈输出（例如，解释、建议、指示等）

借助反馈的优势在于，它允许Agent逐步提高代码的准确性和可靠性，同时能够适应不断变化的需求和环境条件。通过迭代细化，LLM基础的智能代理能够更好地处理复杂的编程任务，生成更符合实际需求的代码，从而提高软件开发的效率和质量。

Static Code Checking

静态检查是指在不执行代码的情况下对代码质量进行审查的过程。它在现代持续集成流程中至关重要，因为它能够在广泛执行测试之前高效地识别出各类代码质量问题，例如不同的错误、漏洞或代码异味。在实践中，静态检查通常采用静态分析技术来自动检测代码中的缺陷（即静态缺陷检测），或者通过同行审查来检查代码质量（即代码审查）。

近期的研究表明，LLMs可以帮助识别给定代码中潜在的质量问题。例如，通过对现有错误/正确代码的微调，或者简单地提示LLMs，已经在识别给定代码片段中的错误、漏洞或代码异味方面显示出了希望的效果。然而，鉴于不同代码问题的根本原因的多样性和复杂性，以及待审查的长代码上下文，独立的LLMs在现实世界的静态代码检查场景中显示出了有限的准确性和召回率。最近，研究人员的相关成果聚焦在这个方向上，以增强独立LLMs在缺陷或漏洞检测方面的能力。

LLM基础的Agent通过以下方式增强静态检查能力：

1. 多智能体协作检测：一种有效的漏洞检测策略专注于多智能体协作的视角。例如，Mao等人提出了一种通过不同LLMs之间的相互讨论和共识来进行漏洞检测的方法，即设计两阶段的方法，涉及多个审计代理和一个批评代理，所有代理都采用GPT-4作为后端。审计员代理随机生成潜在的漏洞和相应的尽可能彻底的推理，而批评家根据特定的标准审查和评价候选。这种方法模拟了现实世界中的代码审查过程，通过LLMs之间的交互和反思增强了检测效果。

2. 工具执行的额外知识：其他方法专注于通过工具调用来增强LLMs的能力。例如，ART是一个通用框架，它通过多步骤规划和有效的工具利用来提升LLMs在未见任务上的表现。

3. 与传统静态缺陷检测的结合：一些研究人员将LLM基础的智能代理与传统的静态检查技术结合起来，以提高它们的静态缺陷检测能力。例如，LLIFT是一个LLM辅助的Use-Before-Initialization (UBI)缺陷检测工具，它基于强大的静态分析工具UBITECT报告的未决定缺陷，进一步利用LLMs在代码理解和总结上的能力来识别Linux内核中的UBI缺陷。

Code Review

代码审查（Code Review）是软件工程中用于确保和提升代码质量的一个重要环节。在代码审查过程中，开发者相互审查对方的代码变更，以确保代码在合并到主分支前符合质量标准。为了减轻人工代码审查的工作量，研究人员利用学习方法自动化代码审查流程。

在机器学习的视角下，代码审查可以被表述为一个二分类问题（即代码质量分类）或一个序列到序列的生成问题（即审查评论生成），这些任务通过微调或提示深度学习模型（包括LLM）来解决。与这些工作不同，基于LLM的Agent通过模仿现实世界的同行审查流程，包含多个作为不同代码审查者的Agent。

CodeAgent是一个多Agent系统，它模拟了一个包含六个具有不同角色的Agent的瀑布式流程，这些角色包括用户、CEO、CPO、CTO、编码者和审查者。在基本信息同步阶段，CEO、CPO和编码者Agent分析输入模式和编程语言。之后，编码者和审查者Agent合作进行代码审查并生成分析报告。在代码对齐阶段，编码者和审查者Agent根据分析报告继续修订代码。最后，在文档阶段，CEO、CTO和编码者Agent合作记录整个代码审查过程。实验结果表明CodeAgent在各种代码审查任务中的有效性和效率，包括一致性分析、漏洞分析、格式分析和代码修订。

Testing

软件测试是软件质量保证的关键环节。LLMs在测试生成方面展现出了显著的能力，包括生成测试代码、测试输入和测试规范。然而，在实践中生成高质量的测试是一个挑战，因为生成的测试不仅要在语法和语义上正确（即输入和规范必须满足被测试软件的规范），而且要足够充分（即测试应尽可能覆盖软件的更多状态）。根据之前的工作，独立LLM生成的测试仍然存在正确性问题（即编译错误、运行时错误和规范问题）和覆盖不足。

在单元测试中，单元测试检查被测试软件中的孤立和小单元（例如方法或类），这有助于快速识别和定位错误，特别是对于复杂的软件系统。Yuan等人的研究表明，LLMs（例如ChatGPT）在生成具有良好可读性和可用性的单元测试方面具有潜力。然而，独立LLM生成的单元测试仍然存在编译/执行错误和有限的覆盖范围。因此，最近的工作构建了基于LLM的Agent，主要通过迭代细化生成的单元测试来提高其正确性、覆盖范围和故障检测能力。

例如，TestPilot通过构建详细的提示信息来生成测试，包括函数签名、实现、文档和使用示例；它根据失败测试的反馈和错误消息来细化提示信息，并迭代生成修正测试。ChatTester利用LLM理解焦点方法的意图，然后生成相应的单元测试；此外，ChatTester的迭代测试细化器执行了比TestPilot更细粒度的细化，它分析错误消息并利用静态分析工具定位需要下一次迭代细化的bug代码。同样，ChatUniTest 采用“生成-验证-修复”机制来细化测试。

系统测试是对集成后的软件系统/组件进行全面评估的过程，以确保它满足规范并在不同设置下按预期运行。例如，模糊测试和图形用户界面（GUI）测试是系统测试中常见的测试范式。利用LLM进行系统测试可能具有挑战性，因为生成有效和系统的系统级测试用例需要满足隐含和明确包含在被测软件系统的规范或领域知识中的约束。与通过独立LLM生成系统级测试相比，基于LLM的Agent被设计为更好地整合被测软件系统的领域知识。

例如，KernelGPT是一个基于LLM的Agent，用于内核模糊测试。分析Agent作为大脑自动生成驱动syscall规范。它首先识别驱动程序，然后迭代完成每个规范组件，在过程中可以根据之前的记忆判断是否需要额外信息。代码提取器（使用LLVM工具链实现）被调用以解析内核代码库以提供源代码信息。KernelGPT最后调用Syzkaller工具并接收其反馈消息，以迭代验证和纠正生成的syscall规范。

Debugging

软件调试通常包括两个阶段：故障定位和程序修复。故障定位技术旨在根据软件的症状（例如，测试失败信息）识别程序中的错误元素（例如，错误的语句或方法）；然后，基于故障定位阶段识别的错误元素，程序修复技术生成补丁以修复错误代码。此外，最近的工作还提出了统一调试，以双向方式桥接故障定位和程序修复。我们然后根据故障定位、程序修复和统一调试三个方面组织LLM基础的Agent的工作。

在故障定位方面，基于学习的方法在LLM时代之前已被广泛研究，这些方法通常训练深度学习模型来预测每个代码元素是否有错误的概率。然而，精确识别软件中的错误元素是具有挑战性的，因为软件系统的规模庞大以及错误消息的庞大和多样性，这通常超出了包括LLM在内的独立学习模型的能力。因此，最近的工作构建了LLM基础的Agent，它们通过多Agent和工具使用来帮助LLM解决这些挑战。

例如，AgentFL是一个多Agent系统，用于项目级别的故障定位。AgentFL的主要洞见是通过多个Agent的协同作用，将基于LLM的故障定位扩展到项目级别的代码上下文。该系统由四个不同的LLM驱动的Agent组成：测试代码审查员、源代码审查员、软件架构师和软件测试工程师。每个Agent都定制有专门的工具和独特的专业知识。通过这四个Agent，AgentFL通过将项目级别的故障定位过程分解为三个阶段：故障理解、代码库导航和故障确认，从而简化了项目级别的故障定位过程。

在程序修复方面，基于LLM的Agent通过模拟科学调试过程来迭代修复错误程序。例如，AutoSD包括四个组件：基于LLM的假设生成器、基于执行的验证器、基于LLM的结论制定者和基于LLM的修复者。在每次迭代中，生成器首先生成关于错误的假设，然后调用调试工具进行假设验证；结论制定者进一步确定假设是否被拒绝；最后，修复者返回潜在的补丁和解释。

在统一调试方面，与将故障定位或程序修复视为孤立阶段的传统方法不同，统一调试技术将它们视为一个统一的过程，利用每个阶段的输出来细化对方。例如，FixAgent是一个多Agent系统，用于统一调试，实现端到端的故障定位、错误修复和错误分析。基于手动调试（例如，橡胶鸭调试），FixAgent使用Agent专业化和协同（即LLM定位器、LLM修复者、LLM制作者和LLM复查者）来整合关键变量跟踪和程序上下文理解。FixAgent能够修复QuixBugs基准测试中的79个错误中的80个。LDB是一个Agent，用于端到端的故障定位和程序修复。LDB根据控制流图将错误程序划分为基本块，并利用LLM检测带有运行时执行值的错误块，然后提供细化建议。

End-to-end Software Development

鉴于多Agent协同带来的高度自主性和灵活性，基于LLM的Agent系统可以进一步处理软件开发的端到端流程（例如，从零开始开发一个贪吃蛇游戏应用），超越软件开发的单个阶段。特别是，这些Agent系统可以像真实世界的软件开发团队一样，通过整合多个专业化、具有不同角色和相关专业知识的Agent之间的协同作用，覆盖整个软件开发生命周期（即需求工程、架构设计、代码生成和软件质量保证）。表10总结了现有的LLM基础的端到端软件开发Agent。

软件开发模型

瀑布模型（Waterfall Process Model）

现有的LLM基础Agent系统（例如AISD、LCG、ChatDev、CTC和Self-Collaboration）主要遵循传统的瀑布模型进行软件开发。传统的瀑布模型是一种线性和顺序的软件开发工作流程，将项目分为不同的阶段，即需求工程、设计、代码实现、测试、部署和维护。一旦一个阶段完成，项目就会向前移动到下一个阶段，不会迭代。

基于此流程，一些端到端软件开发Agent（例如Self-Collaboration、MetaGPT、ChatDev和CTC）进一步扩展了传统的瀑布模型，包括在特定阶段进行迭代以确保生成内容的高质量。例如，测试阶段的结果可能会反馈给开发Agent以修订生成的代码；MetaGPT进一步将瀑布模型与类似人类的标准化操作程序（SOPs）集成，为每个角色分配责任并标准化中间输出，促进不同团队成员之间的协作。

敏捷开发（Agile Development）

一些工作探索了基于LLM的Agent与敏捷开发的可能性，包括测试驱动开发（TDD）和Scrum。TDD优先编写测试，然后编写实际代码以通过测试套件，并以反思阶段结束。Scrum是一种敏捷软件开发过程模型，通过几次冲刺将软件开发分解，通过迭代更新实现复杂的软件系统。在功能级代码生成基准测试中的实验表明，Scrum模型可以实现最佳且最稳定的性能，其次是TDD模型。

在不同的开发模型下，Agent系统一般以角色特化（Role Specialization ofSoftware DevelopmentTeam）的方式对单个Agent分配不同种类的角色（Role），角色的管理或产生主要有两种方式：预定义（Pre-defined）和动态创建（Dynamic Creation）。

1. 预定义（Pre-defined）： 大多数专门化角色是由Agent框架预先定义的。这意味着对于每个任务，角色都是由Agent框架固定设定的。例如，在CodeS、Co-Learning和AutoAgents等系统中，角色是根据Agent框架的工作流程预先设定好的，每个角色都有特定的职责和任务。

2. 动态创建（Dynamic Creation）： 除了预定义的角色外，一些Agent系统采用动态方式分配角色，这使得多Agent系统更加灵活。例如，AutoAgents设计了一个起草阶段，通过两个元Agent（规划者和观察者）之间的通信来确定多Agent小组的角色。AgentVerse通过专家招募阶段来设定不同角色的Agent群体。Talebirad等人提出的框架中，允许Agent动态地生成额外的Agent加入系统。这种动态策略旨在以更多样化和灵活的方式创建角色。

这些角色的创建和管理方式使得基于LLM的Agent系统能够模拟真实世界的软件开发团队，每个角色都负责特定的子任务，并在整个软件开发生命周期中协作。通过这种方式，Agent系统能够更有效地处理复杂的软件开发任务。

在这个过程中，调度各个Agent之间的协作是非常重要的。现有的文献主要讨论了Agent的协作方式和通信协议。

协作模式主要是有序模式和无序模式。有序模式是一种顺序模式，其中每个Agent独立地做出决定，并使用可选的反馈机制来提高它们生成的内容的质量，是现有Agent系统中采用的最普遍的协作模式。无序模式主要引入了一种无序的辩论机制，即多个主体分别平等地发表意见，通过总结得出最终决策。例如，LCG 涉及Scrum过程模型中的冲刺会议，其中参与的Agent提出他们的意见，并与所有其他Agent分享。Scrum Master最终会总结和提取用户故事。

通信协议现有文献分为自然语言和结构化语言。由于大部分都是自然语言，这里不再展开了。

 

---

进一步思考

对于SE中的design和verify

目前，LLM based Agent system覆盖了SE开发的多个过程，但对于design和verify，有统计数据表明暂未有相关文献被引用。对于design，其输入是需求分析，通过确定软件的高层次结构和组件，包括系统架构和关键组件的识别完成概要设计和详细设计文档的输出。这个过程可被分解为多个子过程，实际在本篇综述的一些环节也有体现。只是没有细分为“design”这样一个过程。

而验证工作，一般指形式化地对目标软件系统进行转义，对其进行严谨数学形式的抽象。由于验证工作在涉及生产环境中涉及不多，而且验证所用工具方法基于目标系统的特有性质产生极大的分化，因此在语料和正确性方面较难保障。

对于开发模型

现有研究只提及了Agent-Agent协同，以模拟人类参与者在Srcum、TDD和Waterfall模型下的协同形式。但是未提及有专门针对 Agent-Human 的协同形式。从业界角度讲，纯粹的Agent-Agent实际上同样是“只有人类参与”的另一种极端。目前的研究没有在这个方面有太过深入的、聚焦于SE而不是Agent侧的研究。

总结

阅读这篇文献以前，我自带了几个下问题，希望能从文章中找到答案。

1）UML作为半形式化的描述，有没有可能，让 LLM agent 根据uml描述，形式化的给出原子构件的代码？AI能否为该原子构件匹配合适的资源？如果二者兼是，则基本具备CBSE及OOP自底向上设计的先决条件。

2）LLM agent 如何理解架构？能否站在需求角度上对架构设计进行完善和变通？如果是，则基本具备结构化方法自顶向下的设计能力。

3）AI4SE的现如今难题是什么？相关研究聚焦在LLM侧还是SE侧？

4）如何设计出专门面向AI的需求文档，这部分内容作为需求分析还是概要设计？

对于上述问题的回答，通过该综述和相关知识的搜集，大致有了答案。本综述能够很全面地结合SE开发背景，对现有Agent的实现路线展开归纳，以及不同环节、不同阶段的研究现状整理。属于深入浅出的绝世好文，由衷感谢相关研究者~！

---

相关资源

 原文链接：arXiv:2409.02977v1