基于大型语言模型的软件工程智能体：一篇综述

作者/机构: Junwei Liu, Kaixin Wang, Yixuan Chen, Xin Peng, Zhenpeng Chen, Lingming Zhang, Yiling Lou

A1 主要贡献

本文首次对106篇将基于大型语言模型（LLM）的智能体应用于软件工程（SE）的论文进行了全面综述。研究从软件工程和智能体两个视角，分析了现有基于LLM的智能体是如何设计并应用于软件开发与维护的。此外，论文还探讨了该关键领域的研究机遇和未来发展方向。

A3 背景知识与调研方法

背景与前置知识

基于LLM的智能体的基本框架
基于LLM的智能体通常由四个关键组件构成：规划（planning）、记忆（memory）、感知（perception）和行动（action）【21, Zhiheng Xi et al. The rise and potential of large language model based agents: A survey. CoRR, abs/2309.07864, 2023】。规划和记忆是LLM控制的大脑的核心，它通过感知和行动组件与环境交互以实现特定目标。图2展示了基于LLM的智能体的基本框架。

规划：规划组件将复杂任务分解为多个子任务，并调度这些子任务以达成最终目标。具体而言，智能体可以 (i) 通过不同的推理策略生成一个无需调整的计划，或 (ii) 根据外部反馈（如环境反馈或人类反馈）调整已生成的计划。
记忆：记忆组件记录智能体执行过程中产生的历史思考、行动和环境观察【21, Zhiheng Xi et al. The rise and potential of large language model based agents: A survey. CoRR, abs/2309.07864, 2023】, 【26, Lei Wang et al. A survey on large language model based autonomous agents. Frontiers Comput. Sci., 18(6):186345, 2024】, 【27, Zeyu Zhang et al. A survey on the memory mechanism of large language model based agents. CoRR, abs/2404.13501, 2024】。基于积累的记忆，智能体可以重访并利用之前的记录和经验，从而更有效地处理复杂任务。记忆的管理（如何表示记忆）和利用（如何读/写或检索记忆）至关重要，直接影响智能体系统的效率和效果。
感知：感知组件从环境中接收信息，这有助于更好的规划。特别是，智能体可以感知多模态输入，例如文本输入、视觉输入和听觉输入。
行动：基于大脑的规划和决策，行动组件执行具体动作与环境互动并影响环境。行动中的一个基本机制是控制和利用外部工具，这可以通过访问更多外部资源和扩展超越纯文本交互的行动空间来扩展LLM的固有能力。

图1: 本综述的结构

图2: 基于LLM的智能体的基本框架

先进的基于LLM的智能体系统
多智能体系统使多个智能体之间能够协作，从而解决与不同知识领域相关的更复杂任务。在多智能体系统中，每个智能体被分配一个独特的角色和相关专业知识，专门负责不同任务；此外，智能体可以相互通信并共享任务进展/信息。通常，智能体可以协作（通过处理不同子任务以实现最终目标）或竞争（通过处理相同任务同时进行对抗性辩论）。另一方面，智能体系统可以进一步整合来自人类的指令，并在人类指导下进行任务。这种人机协调范式促进了与人类偏好的更好对齐并利用人类的专业知识。在人机交互期间，人类不仅可以向智能体提供任务要求和当前任务状态的反馈，还可以与智能体合作共同实现目标。

相关综述
通用领域中基于LLM的智能体已被广泛讨论和综述【21, Zhiheng Xi et al. The rise and potential of large language model based agents: A survey. CoRR, abs/2309.07864, 2023】, 【26, Lei Wang et al. A survey on large language model based autonomous agents. Frontiers Comput. Sci., 18(6):186345, 2024】, 【28, Taicheng Guo et al. Large language model based multi-agents: A survey of progress and challenges. CoRR, abs/2402.01680, 2024】-【32, Saikat Barua. Exploring autonomous agents through the lens of large language models: A review. CoRR, abs/2404.04442, 2024】。本综述与之不同，专注于专门为软件工程领域设计的基于LLM的智能体的设计和应用。在软件工程领域，已有几篇关于LLM在软件工程中普遍应用的综述或文献回顾【2, Xinyi Hou et al. Large language models for software engineering: A systematic literature review. CoRR, abs/2308.10620, 2023】, 【3, Shubho Sengupta et al. Large language models for software engineering: Survey and open problems. In IEEE/ACM International Conference on Software Engineering: Future of Software Engineering, ICSE-FoSE 2023, Melbourne, Australia, May 14-20, 2023, pages 31–53. IEEE, 2023】, 【10, Junjie Wang et al. Software testing with large language models: Survey, landscape, and vision. IEEE Trans. Software Eng., 50(4):911–936, 2024】, 【32, Saikat Barua. Exploring autonomous agents through the lens of large language models: A review. CoRR, abs/2404.04442, 2024】, 【33, Juyong Jiang et al. A survey on large language models for code generation. CoRR, abs/2406.00515, 2024】。本综述与之不同，专门关注智能体视角，并更全面地涵盖了基于LLM的智能体在软件工程中的应用。此外，He等人【34, Junda He et al. Llm-based multiagent systems for software engineering: Vision and the road ahead. arXiv preprint arXiv:2404.04834, 2024】提出了一篇关于多智能体系统在软件工程中潜在应用和新兴挑战的愿景论文。与该愿景论文不同，本工作侧重于对现有智能体系统（包括单智能体和多智能体系统）进行全面综述。

调研方法

调研范围的定义
本综述关注应用基于LLM的智能体解决SE任务的论文。其中，SE任务涵盖软件生命周期的所有任务，包括需求工程、软件设计、代码生成、软件质量保证（静态检查和测试）以及软件改进。基于LLM的智能体不仅将LLM作为其“大脑”核心，还具备与环境迭代交互、实时接收反馈并采取行动的能力。

论文筛选的纳入与排除标准
纳入标准包括：(i) 论文提出使用LLM智能体解决特定SE任务的技术、框架或工具；(ii) 论文提出的通用技术、框架或工具，其评估至少包含一项SE任务；(iii) 论文是评估LLM智能体在特定SE任务上表现的实证研究。排除标准包括：(i) 论文不涉及任何SE任务；(ii) 论文仅在讨论或未来工作中提及LLM智能体；(iii) 论文仅使用独立的LLM处理文本输入输出，无环境的迭代交互。

关键词搜索
我们遵循SE综述的既定实践【35, Zhenpeng Chen et al. Fairness testing: A comprehensive survey and analysis of trends. ACM Trans. Softw. Eng. Methodol., 33(5):137:1– 137:59, 2024】-【39, Jie M. Zhang et al. Machine learning testing: Survey, landscapes and horizons. IEEE Transactions on Software Engineering, 48(2):1–36, 2022】，使用DBLP数据库【40, DBLP. https://dblp.org, 2024】进行论文收集。通过迭代试错法确定了搜索关键词，最终关键词包括("agent" OR "llm" OR "language model") AND ("api" OR "bug" OR "code" OR "coding" OR "debug" OR "defect" OR "deploy" OR "evolution" OR "fault" OR "fix" OR "maintenance" OR "program" OR "refactor" OR "repair" OR "requirement" OR "software" OR "test" OR "verification" OR "vulnerab")。于2024年7月1日在DBLP上进行了57次搜索，获得了10,362个结果，经过人工筛选后，确定了67篇相关论文。

TABLE 1: 论文收集统计

雪球抽样法
为了增强综述的全面性，我们采用了雪球抽样法来识别传递相关的论文并扩大我们的论文收集范围【35, Zhenpeng Chen et al. Fairness testing: A comprehensive survey and analysis of trends. ACM Trans. Softw. Eng. Methodol., 33(5):137:1– 137:59, 2024】。具体来说，在2024年7月1日至7月10日期间，我们进行了向后和向前雪球抽样。向后雪球抽样涉及检查每篇已收集论文的参考文献，以识别我们范围内的相关文献，而向前雪球抽样则使用Google Scholar查找引用已收集论文的相关文献。这个迭代过程一直持续到没有发现新的相关论文为止。在此过程中，我们额外检索了39篇论文。

收集论文的统计数据
如表1所示，本综述共收集了106篇论文。图3展示了截至2024年7月10日，随时间发表的论文累积数量。我们观察到该领域的研究兴趣持续增长，凸显了本综述的必要性和相关性。此外，图4展示了论文发表渠道的分布，涵盖了软件工程、人工智能和人机交互等多个研究社区。值得注意的是，大多数论文来自arXiv，尚未经过同行评审。这是预料之中的，因为该领域正在兴起并仍在快速发展中。

图3: 随时间变化的论文累积数量

图4: 所有论文的发表渠道分布

A2 方法细节

从软件工程视角分析

本节从不同软件工程（SE）任务的角度组织收集的论文。图5展示了沿常见软件开发和维护生命周期的SE任务。值得注意的是，基于LLM的智能体不仅可以设计用来解决单个SE任务，还可以支持涉及多个SE活动的端到端软件开发或维护过程。我们观察到基于LLM的智能体被设计用于(i) 端到端软件开发和(ii) 端到端软件维护。与主要专注于单个SE任务的独立LLM相比，基于LLM的智能体通过其组件（规划、记忆、感知、行动）、多智能体协调和人类交互，提供了处理这些复杂任务所需的自主性和灵活性。

图5: 软件开发和维护任务中的智能体分布

不同SE活动中基于LLM的智能体分布
在图5中，括号内的数字表示每个类别中收集的论文数量。值得注意的是，如果基于LLM的智能体是为端到端软件开发或维护而设计的，它们只在端到端层面报告，而不在单个任务层面报告。总的来说，我们观察到大多数基于LLM的智能体专注于个体层面的SE任务，特别是代码生成和代码质量保证（例如，静态检查和测试）；此外，一部分智能体是为端到端软件开发或维护任务而设计的，这表明基于LLM的智能体在处理更复杂的现实世界SE任务方面具有潜力。

4.1 需求工程

需求工程（RE）概述
需求工程是启动软件开发过程的关键阶段，通常包括需求获取、建模、协商、规约、验证和演化等阶段【44, Klaus Pohl. Requirements engineering: An overview. Citeseer, 1996】-【46, Vivek Shukla et al. Requirements engineering: a survey. Communications on Applied Electronics, 3(5):28–31, 2015】。尽管已有研究利用包括独立LLM在内的深度学习模型来辅助需求工程活动，但大多仍停留在RE的单个任务上。最近，多智能体系统被设计用于自动化单个或多个阶段。表2总结了专门为RE设计的现有LLM智能体，图6展示了它们的通用流程。

图6: 基于LLM的需求工程智能体流程

用于单个RE阶段的LLM智能体
Elicitation【54, Mohammadmehdi Ataei et al. Elicitron: An LLM agent-based simulation framework for design requirements elicitation. CoRR, abs/2404.16045, 2024】是一个用于需求获取阶段的多智能体框架，旨在尽可能完整地挖掘需求。它首先在设计好的情境中初始化具有不同角色的多个智能体以覆盖各种用户视角，然后让它们模拟与目标产品的交互，同时记录每一步的记录（行动、观察、挑战）。最终通过智能体访谈和预设标准过滤来识别潜在需求。SpecGen【55, Lezhi Ma et al. Specgen: Automated generation of formal program specifications via large language models. arXiv preprint arXiv:2401.08807, 2024】是一个用于生成给定程序需求规约的系统。它包含两个阶段：对话驱动的规约生成和基于变异的规约生成。第一阶段，智能体生成JML需求规约，并由外部OpenJML验证器验证，反馈信息被整合到提示中进行迭代生成。第二阶段，验证失败的规约被变异和验证，以生成更多样化的规约。

用于多个RE阶段的LLM智能体
Arora等人【56, Chetan Arora et al. Advancing requirements engineering through generative ai: Assessing the role of llms. In Generative AI for Effective Software Development, pages 129–148. Springer, 2024】提出了一个覆盖RE四个阶段（获取、规约、分析、验证）的多智能体系统。在获取阶段，智能体扮演利益相关者或需求工程师的角色收集初步需求，然后在规约阶段由另一个智能体格式化为结构化文档。分析阶段涉及多个利益相关者智能体，旨在评估、优先排序和细化需求。验证阶段由利益相关者智能体进行最终验证，然后确定需求文档。MARE【57, Dongming Jin et al. MARE: multi-agents collaboration framework for requirements engineering. CoRR, abs/2405.03256, 2024】是另一个覆盖多个RE阶段的多智能体框架，包括获取、建模、验证和规约。在获取阶段，一组利益相关者智能体表达需求，由收集者智能体整理成草案。随后，建模者智能体识别实体和关系并构建需求模型；在验证阶段，检查者智能体评估当前需求草案的质量，然后交给文档撰写者智能体编写需求规约或报告错误。

TABLE 2: 现有的用于需求工程的基于LLM的智能体

4.2 代码生成

代码生成背景
随着人工智能技术的发展，代码生成得到了广泛探索【33, Juyong Jiang et al. A survey on large language models for code generation. CoRR, abs/2406.00515, 2024】。LLM在根据给定代码上下文或自然语言描述生成代码方面表现出巨大潜力。然而，LLM生成的代码有时因幻觉【60, Yue Zhang et al. Siren’s song in the AI ocean: A survey on hallucination in large language models. CoRR, abs/2309.01219, 2023】等问题而不尽人意。因此，研究人员构建了能够通过规划和迭代优化来增强LLM能力的基于LLM的智能体。图7展示了现有LLM如何扩展独立LLM在代码生成中的能力。

图7: 基于LLM的代码生成智能体流程

带规划的代码生成
基于LLM的智能体采用先进的规划方法来扩展LLM的代码生成能力。思维链（CoT）【99, Jason Wei et al. Chain-of-thought prompting elicits reasoning in large language models. In Advances in Neural Information Processing Systems 35, 2022】是最流行的策略，它将代码生成任务分解为子任务，从而实现更高的生成正确性【61, Eric Zelikman et al. Parsel: Algorithmic reasoning with language models by composing decompositions. In Advances in Neural Information Processing Systems 36, 2023】, 【70, Zijun Liu et al. Dynamic llm-agent network: An llm-agent collaboration framework with agent team optimization, 2023】, 【76, Andy Zhou et al. Language agent tree search unifies reasoning acting and planning in language models. CoRR, abs/2310.04406, 2023】, 【84, Dong Huang et al. Codecot: Tackling code syntax errors in cot reasoning for code generation, 2024】, 【86, Xinyi He et al. CONLINE: complex code generation and refinement with online searching and correctness testing. CoRR, abs/2403.13583, 2024】, 【91, Martin Josifoski et al. Flows: Building blocks of reasoning and collaborating AI. CoRR, abs/2308.01285, 2023】-【93, Hung Le et al. Codechain: Towards modular code generation through chain of self-revisions with representative sub-modules, 2024】, 【95, Dong Huang et al. Agentcoder: Multi-agent-based code generation with iterative testing and optimisation, 2024】。例如，CodeCoT【84, Dong Huang et al. Codecot: Tackling code syntax errors in cot reasoning for code generation, 2024】利用CoT将给定需求分解为自然语言描述的步骤，然后将其转换为代码。一些工作采用动态规划策略，其中当前行动的观察决定下一步【62, Noah Shinn et al. Reflexion: Language agents with verbal reinforcement learning, 2023】, 【85, Xingyao Wang et al. Executable code actions elicit better llm agents, 2024】, 【87, John Yang et al. Intercode: Standardizing and benchmarking interactive coding with ee cution feedback, 2023】, 【88, Ramakrishna Bairi et al. Codeplan: Repository-level coding using llms and planning, 2023】。例如，CodePlan【88, Ramakrishna Bairi et al. Codeplan: Repository-level coding using llms and planning, 2023】采用自适应规划算法，动态检测仓库中受影响的代码片段并调整计划。为弥合叙述性步骤与最终生成代码之间的差距，一些工作提出了不同的表示方法来描述规划步骤，包括伪代码【95, Dong Huang et al. Agentcoder: Multi-agent-based code generation with iterative testing and optimisation, 2024】、中间代码【61, Eric Zelikman et al. Parsel: Algorithmic reasoning with language models by composing decompositions. In Advances in Neural Information Processing Systems 36, 2023】或代码骨架【93, Hung Le et al. Codechain: Towards modular code generation through chain of self-revisions with representative sub-modules, 2024】, 【97, Yoichi Ishibashi et al. Self-organized agents: A LLM multi-agent framework toward ultra large-scale code generation and optimization. CoRR, abs/2404.02183, 2024】。一些工作还探索了多路径规划策略，如LATS【76, Andy Zhou et al. Language agent tree search unifies reasoning acting and planning in language models. CoRR, abs/2310.04406, 2023】和MapCoder【98, Md. Ashraful Islam et al. Mapcoder: Multi-agent code generation for competitive problem solving. CoRR, abs/2405.11403, 2024】。

带迭代优化的代码生成
智能体的一个基本能力是根据环境反馈采取行动。在代码生成场景中，一些智能体通过多次迭代，根据反馈动态地优化先前生成的代码。我们将相关研究根据反馈来源进行组织，包括模型反馈、工具反馈、人类反馈和混合反馈。表3总结了用于带迭代优化的代码生成的现有LLM智能体。

TABLE 3: 现有的用于代码生成的基于LLM的智能体

模型反馈
模型反馈可分为同伴反思和自我反思。同伴反思指多个模型之间的信息交换和互动，最常见的范式是通过角色专业化和结构化通信（如代码审查）在多智能体系统中协作【62, Noah Shinn et al. Reflexion: Language agents with verbal reinforcement learning, 2023】, 【64, Erkang Zhu et al. Autogen: Enabling next-gen llm applications via multiagent conversation, 2023】, 【68, Guohao Li et al. Camel: Communicative agents for ”mind” exploration of large language model society, 2023】。自我反思则指单个模型进行自我优化【71, Xinyun Chen et al. ¨ Teaching large language models to self-debug, 2023】, 【73, Zhao Tian et al. Test-case-driven programming understanding in large language models for better code generation, 2024】, 【90, Aman Madaan et al. Self-refine: Iterative refinement with self-feedback. In Advances in Neural Information Processing Systems 36, 2023】。

工具反馈
为解决模型生成代码质量有限的问题，一种方案是为LLM智能体配备工具，收集有信息的反馈并辅助代码生成和优化。常见的工具有动态执行工具（如编译器、解释器）【79, Shuyang Jiang et al. Selfevolve: A code evolution framework via large language models, 2023】, 【81, Yiheng Xu et al. Lemur: Harmonizing natural language and code for language agents, 2023】-【87, John Yang et al. Intercode: Standardizing and benchmarking interactive coding with ee cution feedback, 2023】, 【92, Xingyao Wang et al. Mint: Evaluating llms in multiturn interaction with tools and language feedback, 2024】-【98, Md. Ashraful Islam et al. Mapcoder: Multi-agent code generation for competitive problem solving. CoRR, abs/2405.11403, 2024】；静态检查工具（如静态分析器）【82, Kechi Zhang et al. Codeagent: Enhancing code generation with tool-integrated agent systems for real-world repo-level coding challenges, 2024】, 【88, Ramakrishna Bairi et al. Codeplan: Repository-level coding using llms and planning, 2023】, 【89, Chong Wang et al. Teaching code llms to use autocompletion tools in repository-level code generation, 2024】；以及检索工具（如本地知识库检索、在线搜索引擎）【78, Kechi Zhang et al. Toolcoder: Teach code generation models to use api search tools, 2023】, 【80, Xiaoxue Ren et al. From misuse to mastery: Enhancing code generation with knowledge-driven ai chaining, 2023】, 【82, Kechi Zhang et al. Codeagent: Enhancing code generation with tool-integrated agent systems for real-world repo-level coding challenges, 2024】, 【86, Xinyi He et al. CONLINE: complex code generation and refinement with online searching and correctness testing. CoRR, abs/2403.13583, 2024】, 【96, Binfeng Xu et al. Gentopia: A collaborative platform for tool-augmented llms, 2023】。

人类反馈
另一种方法是将人类反馈纳入流程，因为人类在澄清模糊需求方面起着关键作用。例如，人类可以检查生成的代码是否符合其初始意图【91, Martin Josifoski et al. Flows: Building blocks of reasoning and collaborating AI. CoRR, abs/2308.01285, 2023】, 【92, Xingyao Wang et al. Mint: Evaluating llms in multiturn interaction with tools and language feedback, 2024】。ClarifyGPT【94, Fangwen Mu et al. Clarifygpt: Empowering llm-based code generation with intention clarification, 2023】能自动识别手动给定需求中的潜在模糊性，并主动向人类提问以优化需求。

混合反馈
智能体也可以整合多种类型的反馈作为混合反馈。一种常见方法是结合工具反馈和模型反馈，LLM接收程序执行或测试用例后的错误信息，并利用其上下文理解能力提供相应的反馈输出【62, Noah Shinn et al. Reflexion: Language agents with verbal reinforcement learning, 2023】-【67, Bin Lei et al. Autocoder: Enhancing code large language model with aiev-instruct. CoRR, abs/2405.14906, 2024】, 【71, Xinyun Chen et al. ¨ Teaching large language models to self-debug, 2023】-【77, Ajinkya Deshpande et al. Class-level code generation from natural language using iterative, tool-enhanced reasoning over repository, 2024】, 【91, Martin Josifoski et al. Flows: Building blocks of reasoning and collaborating AI. CoRR, abs/2308.01285, 2023】, 【97, Yoichi Ishibashi et al. Self-organized agents: A LLM multi-agent framework toward ultra large-scale code generation and optimization. CoRR, abs/2404.02183, 2024】。例如，多智能体系统INTERVENOR【65, Hanbin Wang et al. Intervenor: Prompting the coding ability of large language models with the interactive chain of repair, 2024】中，一个教师编码员观察程序执行结果，并为学生编码员提供错误解释和修复计划。

4.3 静态代码检查

静态代码检查概述
静态代码检查是指在不执行代码的情况下检查代码质量，是现代持续集成管道中必不可少的一环。实践中，通常采用静态分析技术自动检测错误/漏洞（即静态错误检测）或通过同行评审来检查代码质量（即代码审查）。

静态错误检测
现有研究表明，LLM可以帮助识别给定代码中的潜在质量问题【2, Xinyi Hou et al. Large language models for software engineering: A systematic literature review. CoRR, abs/2308.10620, 2023】, 【3, Shubho Sengupta et al. Large language models for software engineering: Survey and open problems. In IEEE/ACM International Conference on Software Engineering: Future of Software Engineering, ICSE-FoSE 2023, Melbourne, Australia, May 14-20, 2023, pages 31–53. IEEE, 2023】。然而，由于代码问题的根本原因多样复杂以及检查的代码上下文较长，独立LLM在真实世界的静态代码检查场景中准确率和召回率有限【101, Xueying Du et al. Vul-rag: Enhancing llm-based vulnerability detection via knowledge-level rag. arXiv preprint arXiv:2406.11147, 2024】。最近，研究人员构建了基于LLM的智能体来增强独立LLM在错误或漏洞检测方面的能力。表4总结了这些智能体，图8展示了它们的通用流程。

图8: 基于LLM的静态错误检测智能体流程

多智能体协同检查
一种有效的漏洞检测策略侧重于多智能体协作的视角。Mao等人【111, Zhenyu Mao et al. Multi-role consensus through llms discussions for vulnerability detection. CoRR, abs/2403.14274, 2024】提出了一种通过代表测试人员和开发人员的不同LLM之间相互讨论和达成共识的漏洞检测方法。GPTLENS【104, Sihao Hu et al. Large language model-powered smart contract vulnerability detection: New perspectives. In 5th IEEE International Conference on Trust, Privacy and Security in Intelligent Systems and Applications, TPS-ISA 2023, Atlanta, GA, USA, November 1-4, 2023】是一个用于检测智能合约漏洞的对抗性协同框架，涉及多个审计员智能体和一个评论家智能体。Fan等人【105, Gang Fan et al. Static code analysis in the AI era: An in-depth exploration of the concept, function, and potential of intelligent code analysis agents. CoRR, abs/2310.08837, 2023】提出了智能代码分析智能体（ICAA）的概念，用于静态代码分析，它集成了AI模型、工程流程设计和传统非AI组件。

工具执行的附加知识
其他方法则通过工具调用来增强LLM的能力。ART【102, Bhargavi Paranjape et al. ´ ART: automatic multi-step reasoning and tool-use for large language models. CoRR, abs/2303.09014, 2023】是一个通用框架，通过多步规划和有效工具利用来提升LLM处理未知任务的能力。Sun等人【110, Yuqiang Sun et al. Llm4vuln: A unified evaluation framework for decoupling and enhancing llms’ vulnerability reasoning. CoRR, abs/2401.16185, 2024】提出了LLM4Vuln，通过解耦和增强LLM的漏洞推理能力。该智能体从漏洞报告的原始文本和总结的关键句子中检索外部知识，并调用工具通过函数调用主动寻求目标代码的进一步上下文。

与传统静态错误检测结合
一些研究人员将基于LLM的智能体与传统静态检查技术相结合，以提高其静态错误检测能力。例如，LLIFT【115, Haonan Li et al. Enhancing static analysis for practical bug detection: An llm-integrated approach. Proc. ACM Program. Lang., 8(OOPSLA1):474–499, 2024】是一个LLM辅助的“使用前未初始化”（UBI）错误检测工具。E&V【107, Yu Hao et al. E&v: Prompting large language models to perform static analysis by pseudo-code execution and verification. CoRR, abs/2312.08477, 2023】是一个用于对Linux内核代码进行静态分析的智能体。IRIS【113, Ziyang Li et al. Llm-assisted static analysis for detecting security vulnerabilities, 2024】是一个增强了CodeQL（一种静态分析工具）【114, Pavel Avgustinov et al. Ql: Object-oriented queries on relational data. In 30th European Conference on Object-Oriented Programming (ECOOP 2016), 2016】的智能体，用于漏洞检测。

TABLE 4: 现有的用于静态错误检测的基于LLM的智能体

代码审查
开发人员互相审查代码更改以确保和提高代码质量。为了减轻代码审查中的手动工作，研究人员利用学习方法来自动化代码审查过程。与这些工作不同，基于LLM的智能体通过包含多个智能体作为不同的代码审查员来模仿真实世界的同行审查过程。表5总结了现有的用于代码审查的智能体。

CodeAgent
CodeAgent【119, Daniel Tang et al. Codeagent: Collaborative agents for ´ software engineering. CoRR, abs/2402.02172, 2024】是一个多智能体系统，模拟一个包含四个阶段（基本信息同步、代码审查、代码对齐和文档）的瀑布式流程，并设立了一个由六个不同角色（用户、CEO、CPO、CTO、编码员和审查员）组成的审查团队。实验结果表明，CodeAgent在各种代码审查任务中具有有效性和效率。

其他代码审查智能体
与CodeAgent构建一个可以执行各种代码审查任务的团队不同，Rasheed等人【120, Zeeshan Rasheed et al. Ai-powered code review with llms: Early results. CoRR, abs/2404.18496, 2024】设计了一种方法，每个智能体专门负责一个单一的代码审查任务。ICAA【105, Gang Fan et al. Static code analysis in the AI era: An in-depth exploration of the concept, function, and potential of intelligent code analysis agents. CoRR, abs/2310.08837, 2023】设计了一个多智能体系统来识别代码与意图的不一致性。CORE【121, Nalin Wadhwa et al. Frustrated with code quality issues? llms can help! CoRR, abs/2309.12938, 2023】设计了一个包含两个智能体和传统静态分析工具的系统，以自动修复代码质量问题。

TABLE 5: 现有的用于代码审查的基于LLM的智能体

4.4 测试

软件测试概述
软件测试对保证软件质量至关重要。LLM在测试生成方面显示出巨大潜力，包括生成测试代码、测试输入和测试预言。然而，实践中生成高质量测试具有挑战性，因为生成的测试不仅需要语法和语义正确，还应具有足够的覆盖率。因此，研究人员构建了基于LLM的智能体来扩展LLM在测试生成方面的能力。我们将这些工作按测试级别（单元测试和系统测试）进行组织。

图9: 基于LLM的单元测试智能体流程

单元测试
单元测试检查被测软件中孤立的小单元，有助于快速识别和定位错误。然而，独立LLM生成的单元测试仍存在编译/执行错误和覆盖率有限的问题。因此，最近的工作构建了基于LLM的智能体，主要通过迭代优化生成的单元测试来提高其正确性、覆盖率和故障检测能力。表6总结了现有的用于单元测试生成的基于LLM的智能体，图9展示了它们的通用流程。

迭代优化以修复编译/执行错误
LLM直接生成的测试用例可能存在编译或执行错误。因此，受程序修复【128, Chunqiu Steven Xia and Lingming Zhang. Conversational automated program repair. arXiv preprint arXiv:2301.13246, 2023】的启发，基于LLM的智能体通过迭代收集错误信息并修复错误的测试代码来消除此类错误【122, Zhiqiang Yuan et al. No more manual tests? evaluating and improving chatgpt for unit test generation, 2024】-【124, Zhuokui Xie et al. Chatunitest: a chatgpt-based automated unit test generation tool. CoRR, abs/2305.04764, 2024】。例如，TestPilot【123, Max Schafer et al. An em-¨ pirical evaluation of using large language models for automated unit test generation, 2023】通过构建详细的提示生成测试，并根据失败测试和错误信息的反馈进行迭代优化。

迭代优化以提高覆盖率
CoverUp【126, Juan Altmayer Pizzorno and E. Berger. Coverup: Coverage-guided llm-based test generation. ArXiv, abs/2403.16218, 2024】是一个旨在实现高覆盖率的LLM驱动的测试生成系统。它通过分割源代码来分解任务，并使用SlipCover工具【129, Juan Altmayer Pizzorno and Emery D. Berger. Slipcover: Near zero-overhead code coverage for python. In ISSTA ’23. ACM, July 2023】进行详细的覆盖率分析。Yang等人【125, Chen Yang et al. Enhancing llm-based test generation for hard-to-cover branches via program analysis, 2024】提出了TELPA，通过前后向方法调用分析和反例采样来增强难以触达分支的覆盖率。

迭代优化以提高故障检测能力
MuTAP【127, Arghavan Moradi Dakhel et al. Effective test generation using pre-trained large language models and mutation testing, 2023】是一个基于单个LLM的智能体系统，旨在通过变异测试的反馈生成具有更好错误检测能力的单元测试。在每次迭代中，LLM首先生成初始测试用例并自我修正语法错误，然后测试用例在变异程序上运行，存活的变异体作为反馈指导LLM改进测试用例。

TABLE 6: 现有的用于单元测试的基于LLM的智能体

系统测试
系统测试是一个全面的过程，评估一个集成的软件系统/组件，以保证其满足规约并在不同环境下按预期运行。基于LLM的智能体被设计用于更好地整合被测软件系统的领域知识，以生成有效的系统级测试。我们将这些工作根据被测软件系统进行组织。表7总结了不同软件系统的现有智能体。

操作系统内核
KernelGPT【130, Chenyuan Yang et al. Kernelgpt: Enhanced kernel fuzzing via large language models, 2023】是一个用于内核模糊测试的基于LLM的智能体。分析智能体作为大脑自动生成驱动程序系统调用规约。它首先识别驱动程序，然后迭代地完成每个规约组件。一个代码提取器（使用LLVM工具链【132, The LLVM Compiler Infrastructure. https://llvm.org】实现）被调用来解析内核代码库以提供源代码信息。KernelGPT最终调用Syzkaller工具【131, Syzkaller. https://github.com/google/syzkaller/】并接收其反馈信息，以迭代地验证和修正生成的系统调用规约。

编译器
WhiteFox【133, Chenyuan Yang et al. White-box compiler fuzzing empowered by large language models, 2023】包含两个协同工作的基于LLM的智能体：一个分析智能体和一个生成智能体。前者检查低级优化源代码并生成能够触发这些优化的高级测试程序的需求，而后者根据总结的需求制作测试程序。LLM4CBI【134, Haoxin Tu et al. Isolating compiler bugs by generating effective witness programs with large language models. IEEE Transactions on Software Engineering, page 1–20, 2024】是一个旨在通过生成具有更好故障检测能力的测试用例来隔离编译器错误的单智能体。

移动应用
基于LLM的智能体被提出来自动化移动应用的测试过程，包括GUI测试、错误复现和用户验收测试。对于GUI测试，GPTDroid【139, Zhe Liu et al. Make llm a testing expert: Bringing human-like interaction to mobile gui testing via functionality-aware decisions. In ICSE, 2023】框架中，LLM通过感知GUI页面信息、生成问答形式的测试脚本、通过工具执行这些脚本并接收应用反馈来迭代整个过程。DroidAgent【144, Juyeon Yoon et al. Autonomous large language model agents enabling intent-driven mobile gui testing. ArXiv, abs/2311.08649, 2023】框架则采用多个LLM智能体协同工作。对于错误复现，AdbGPT【15, Sidong Feng and Chunyang Chen. Prompting is all you need: Automated android bug replay with large language models. In ICSE 2024. ACM, 2024】分析错误报告，将识别的实体转化为一系列用于错误复现的动作。对于用户验收测试，XUAT-Copilot【148, Zhitao Wang et al. Xuatcopilot: Multi-agent collaborative system for automated user acceptance testing with large language model, 2024】系统主要由三个负责动作规划、状态检查和参数选择的LLM智能体组成。

TABLE 7: 现有的用于系统测试的基于LLM的智能体

Web应用
RESTful API在Web应用中非常流行。RESTSpecIT【149, Alix Decrop et al. You can rest now: Automated specification inference and black-box testing of restful apis with large language models, 2024】利用LLM自动推断RESTful API规约并进行黑盒测试。给定一个API名称，RESTSpecIT通过一个反思循环生成并变异HTTP请求。通过向API端点发送这些请求，它分析HTTP响应以进行推断和测试。LLM使用有效的请求作为反馈，在每次迭代中优化变异。

通用软件类别
一些智能体系统并非为特定任务工作流设计，使其能普遍适用于各种目标软件系统。Fuzz4All【150, Chunqiu Steven Xia et al. Fuzz4all: Universal fuzzing with large language models, 2024】是首个通用的基于LLM的模糊测试器。PentestGPT【151, Gelei Deng et al. Pentestgpt: An llm-empowered automatic penetration testing tool, 2024】设计了一个模块化框架，用于进行渗透测试。Fang等人【153, Richard Fang et al. Llm agents can autonomously exploit one-day vulnerabilities, 2024】开发了一个包含15个一日漏洞的基准测试，以评估其智能体框架在利用此类弱点方面的效力。

4.5 调试

软件调试概述
软件调试通常包括两个阶段：故障定位【157, W Eric Wong et al. A survey on software fault localization. IEEE Transactions on Software Engineering, 42(8):707–740, 2016】和程序修复【158, Luca Gazzola et al. Automatic software repair: A survey. In Proceedings of the 40th International Conference on Software Engineering, pages 1219–1219, 2018】。我们将LLM智能体在调试中的工作分为三部分：故障定位、程序修复和统一调试。

图10: 基于LLM的故障定位智能体流程

故障定位
基于学习的故障定位在LLM时代之前就已被广泛研究。然而，鉴于软件系统的庞大规模和海量多样的错误信息，精确定位错误元素具有挑战性。因此，最近的工作构建了基于LLM的智能体，通过多智能体和工具使用来帮助LLM应对这些挑战。表8总结了现有的用于故障定位的基于LLM的智能体，图10展示了它们的通用流程。

多智能体协同
AgentFL【160, Yihao Qin et al. Agentfl: Scaling llm-based fault localization to project-level context. CoRR, abs/2403.16362, 2024】是一个用于项目级故障定位的多智能体系统。其核心思想是通过多个智能体的协同作用，将基于LLM的故障定位扩展到项目级代码上下文。该系统由四个不同的LLM驱动的智能体组成：测试代码审查员、源代码审查员、软件架构师和软件测试工程师。RCAgent【162, Zefan Wang et al. Rcagent: Cloud root cause analysis by autonomous agents with tool-augmented large language models. CoRR, abs/2310.16340, 2023】是一个用于工业云环境中根本原因分析的多智能体系统，包括一个控制器智能体和多个专家智能体。

工具调用
AUTOFL【163, Sungmin Kang et al. A preliminary evaluation of llm-based fault localization. CoRR, abs/2308.05487, 2023】是一个单智能体系统，通过工具调用（即四个专门的函数调用）来增强独立LLM，以更好地探索代码仓库。它首先进行根本原因解释，调用工具来监视源代码仓库以获取相关信息，仅需一个失败的测试及其失败堆栈。此外，AgentFL【160, Yihao Qin et al. Agentfl: Scaling llm-based fault localization to project-level context. CoRR, abs/2403.16362, 2024】和RCAgent【162, Zefan Wang et al. Rcagent: Cloud root cause analysis by autonomous agents with tool-augmented large language models. CoRR, abs/2310.16340, 2023】也在其框架中集成了工具调用。

TABLE 8: 现有的用于故障定位的基于LLM的智能体

程序修复
微调和固定提示是基于独立LLM的程序修复技术最广泛采用的范式。然而，LLM在单次迭代中生成的补丁并不总是正确的。因此，现有的基于LLM的智能体都遵循迭代范式，根据每次迭代中的工具或模型反馈来优化补丁生成。表9总结了现有的用于程序修复的基于LLM的智能体，图11展示了它们的通用流程。

图11: 基于LLM的程序修复智能体流程

迭代修复
ChatRepair【128, Chunqiu Steven Xia and Lingming Zhang. Conversational automated program repair. arXiv preprint arXiv:2301.13246, 2023】, 【166, Chunqiu Steven Xia and Lingming Zhang. Automated program repair via conversation: Fixing 162 out of 337 bugs for \$0.42 each using chatgpt. In ISSTA, 2024】是首个根据环境反馈迭代优化补丁或程序生成的自动化方法。CigaR【169, David Hidv ´ egi et al. Cigar: Cost-efficient program repair with llms. CoRR, abs/2402.06598, 2024】是一个类似的用于函数级程序修复的智能体系统。RepairAgent【171, Islem Bouzenia et al. Repairagent: An autonomous, llm-based agent for program repair. CoRR, abs/2403.17134, 2024】采用了更具智能体特性的设计，通过让LLM自行决定何时或调用哪个工具来使硬编码的反馈机制更灵活。

多智能体修复
AutoSD【172, Sungmin Kang et al. Explainable automated debugging via large language model-driven scientific debugging. CoRR, abs/2304.02195, 2023】是一个模拟科学调试【179, Andreas Zeller. Why Programs Fail - A Guide to Systematic Debugging, 2nd Edition. Academic Press, 2009】来迭代修复错误程序的多智能体系统。ACFIX【174, Lyuye Zhang et al. ACFIX: guiding llms with mined common RBAC practices for context-aware repair of access control vulnerabilities in smart contracts. CoRR, abs/2403.06838, 2024】是一个用于修复智能合约中访问控制漏洞的多智能体系统。FlakyDoctor【175, Yang Chen. Flakiness repair in the era of large language models. In ICSE Companion, pages 441–443, 2024】是一个修复不稳定测试的智能体。

TABLE 9: 现有的用于程序修复的基于LLM的智能体

统一调试
统一调试技术将故障定位和程序修复视为一个统一的过程。最近，基于LLM的智能体通过利用LLM来理解、利用和统一故障定位和程序修复的输出来增强传统的统一调试技术。FixAgent【159, Cheryl Lee et al. A unified debugging approach via llm-based multi-agent synergy. CoRR, abs/2404.17153, 2024】是一个用于统一调试的多智能体系统，实现了端到端的故障定位、错误修复和错误分析。LDB【75, Lily Zhong et al. LDB: A large language model debugger via verifying runtime execution stepby-step. CoRR, abs/2402.16906, 2024】是一个用于端到端故障定位和程序修复的智能体，它将错误程序划分为基本块，并利用LLM通过运行时执行值检测不正确的块并提供优化建议。

4.6 端到端软件开发

端到端软件开发概述
鉴于高度的自主性和多智能体协同的灵活性，基于LLM的智能体系统可以进一步处理端到端的软件开发过程，而不仅仅是软件开发的单个阶段。这些智能体系统可以通过整合具有不同角色和相关专业知识的多个智能体之间的协同作用，来覆盖整个软件开发生命周期。表10总结了现有的用于端到端软件开发的基于LLM的智能体。

TABLE 10: 现有的用于端到端软件开发的基于LLM的智能体

软件开发过程模型
现实世界的软件团队通常遵循经典的软件过程模型。现有的用于端到端软件开发的基于LLM的智能体也根据常见的软件过程模型（如瀑布模型和敏捷开发）设计其工作流程。图12展示了现有LLM智能体如何经历不同的过程模型。

图12: 基于LLM的端到端软件开发智能体采用的过程模型

瀑布过程模型
大多数现有的基于LLM的智能体系统（如AISD【191, Simiao Zhang et al. Experimenting a new programming practice with llms. CoRR, abs/2401.01062, 2024】, LCG【194, Feng Lin et al. When llm-based code generation meets the software development process. CoRR, abs/2403.15852, 2024】, ChatDev【186, Chen Qian et al. Communicative agents for software development. CoRR, abs/2307.07924, 2023】, CTC【197, Zhuoyun Du et al. Multi-agent software development through cross-team collaboration, 2024】和Self-Collaboration【4, Yihong Dong et al. Self-collaboration code generation via chatgpt. CoRR, abs/2304.07590, 2023】）遵循经典的瀑布过程模型。一些端到端软件开发智能体通过在特定阶段加入迭代来扩展传统瀑布过程，以确保生成内容的高质量。

敏捷开发
一些工作探索了基于LLM的智能体在敏捷开发中的潜力，包括测试驱动开发（TDD）【194, Feng Lin et al. When llm-based code generation meets the software development process. CoRR, abs/2403.15852, 2024】和Scrum【194, Feng Lin et al. When llm-based code generation meets the software development process. CoRR, abs/2403.15852, 2024】, 【198, Minh Huynh Nguyen et al. Agilecoder: Dynamic collaborative agents for software development based on agile methodology. arXiv preprint arXiv:2406.11912, 2024】。在函数级代码生成基准测试上的实验表明，Scrum模型可以实现最佳和最稳定的性能，其次是TDD模型【194, Feng Lin et al. When llm-based code generation meets the software development process. CoRR, abs/2403.15852, 2024】。

软件开发团队的角色专业化
模仿现实世界的软件开发团队，用于端到端软件开发的多智能体系统通常分配不同的角色来处理专门的子任务，并在整个软件开发生命周期中进行协作。现有智能体中的角色主要通过模拟现实世界的软件开发团队或根据工作流程进行专业化设计。角色的创建方式可以是预定义的，也可以是动态的。

多智能体中的协作机制
在用于端到端软件开发的多智能体系统中，调度每个智能体如何相互协调至关重要。协作模式主要有两种：有序模式（顺序执行）和无序模式（如辩论机制）。通信协议包括纯自然语言和结构化通信（如交换文档和图表）。

智能体评估
鉴于端到端软件开发的复杂性，研究人员构建了多样的基准和指标进行全面评估。表11总结了用于评估现有LLM智能体的基准。表12总结了评估指标，除了常见的Pass Rate等，还包括相似性度量、成本、人工干预程度和生成程序的规模。

TABLE 11: 端到端软件开发的基准

TABLE 12: 评估端到端软件开发智能体的指标

4.7 端到端软件维护

端到端软件维护概述
软件系统因需求不断变化或出现意外行为而需要维护。实践中，用户报告不满意的行为，开发人员诊断并修改软件以解决问题。这个端到端的软件维护过程在实践中可能耗时且劳动密集。最近，越来越多的多智能体系统旨在自动解决真实世界软件项目的问题。表13总结了这些智能体的特点。

TABLE 13: 现有的用于端到端软件维护的基于LLM的智能体

通用流程
图13展示了现有用于端到端软件维护的LLM智能体系统的流程。基本上所有现有智能体都遵循一个三阶段的通用流程：问题定位、补丁生成和补丁验证。一些智能体还包括额外的阶段，如预处理、问题复现、任务分解、补丁排名等。

图13: 基于LLM的端到端软件维护智能体流程

各阶段策略
- 预处理：一些智能体首先进行预处理，为整个过程准备先验知识，如构建代码仓库的知识图【209, Yingwei Ma et al. How to understand whole software repository? arXiv preprint arXiv:2406.01422, 2024】或将项目转换为树状结构【211, Chunqiu Steven Xia et al. Agentless: Demystifying llm-based software engineering agents. CoRR, abs/2407.01489, 2024】。
- 问题复现：一些智能体设计了问题复现阶段，旨在生成能够触发用户遇到的意外行为的测试脚本，如SWE-agent【207, John Yang et al. Swe-agent: Agent-computer interfaces enable automated software engineering. arXiv preprint arXiv:2405.15793, 2024】和CodeR【208, Dong Chen et al. Coder: Issue resolving with multi-agent and task graphs. arXiv preprint arXiv:2406.01304, 2024】。
- 问题定位：这是最重要的阶段之一，智能体需要精确定位与问题相关的代码元素。常见的定位策略包括基于检索的定位、基于导航的定位、基于频谱的定位和模拟。
- 任务分解：在生成补丁之前，一些智能体将任务分解为更细粒度的子任务，如MAGIS【205, Wei Tao et al. MAGIS: llm-based multi-agent framework for github issue resolution. CoRR, abs/2403.17927, 2024】。
- 补丁生成：此阶段，智能体为定位到的可疑代码元素生成补丁。
- 补丁验证：智能体验证生成补丁的正确性，验证策略包括代码审查、静态检查和动态检查。
- 补丁排名：由于补丁验证阶段有时不足以过滤掉所有不正确的补丁，一些智能体还包括补丁排名阶段，如MASAI【210, Daman Arora et al. Masai: Modular architecture for softwareengineering ai agents, 2024】。

基准
为了评估LLM智能体如何处理端到端软件维护，研究人员从真实的GitHub问题中构建了基准，包括SWE-bench【213, Carlos E. Jimenez et al. Swe-bench: Can language models resolve real-world github issues? CoRR, abs/2310.06770, 2023】、SWE-bench Lite【214, SWE-bench Lite, 2024. https://www.swebench.com/lite.html】、SWE-bench Lite-S【211, Chunqiu Steven Xia et al. Agentless: Demystifying llm-based software engineering agents. CoRR, abs/2407.01489, 2024】和SWE-bench Verified【215, Introducing SWE-bench Verified, 2024. https://openai.com/index/ introducing-swe-bench-verified/】。表14总结了现有端到端软件维护基准的演变时间线。

图14: 软件维护基准的演变

从Agent视角分析

本节从智能体的角度组织收集的论文。具体来说，5.1节总结了现有用于SE的LLM智能体的组件；5.2节关注现有用于SE的多智能体系统，总结了它们的角色和协作机制；5.3节总结了人类如何与用于SE的智能体进行协调。

5.1 智能体框架

规划（Planning）
在SE中，开发和维护等复杂任务需要多个智能体通过多轮迭代协同工作。因此，规划是智能体系统的重要组成部分。图15展示了现有用于SE的LLM智能体中规划组件的分类。规划可以由单个规划器或多个规划器处理，采用单轮规划或多轮规划（如ReAct-like架构），以及单路径或多路径规划策略。规划的表示形式包括自然语言、半结构化表示（如JSON）或图。

图15: SE中LLM智能体规划策略的分类

记忆（Memory）
记忆组件负责存储历史轨迹，使智能体能够维持连贯的推理。我们从记忆持续时间、所有权、格式和操作四个角度详细介绍SE中记忆机制的实现。图16展示了现有用于SE的LLM智能体中记忆组件设计的分类。记忆可分为短期记忆（如对话记录、行动-观察-评论记录、中间输出）和长期记忆（如提炼的轨迹、选择性存储）。记忆所有权可分为特定记忆和共享记忆。记忆格式包括自然语言、编程语言、结构化消息、键值对、嵌入和树。记忆操作包括写入（内存预处理、内存消除）和读取（过滤标准、读取方式如反思、检索、订阅）。

图16: SE中LLM智能体记忆设计的分类

感知（Perception）
现有用于SE的LLM智能体主要采用两种感知范式：文本输入感知和视觉输入感知。文本输入是主要形式，包括自然语言输入（指令和环境辅助信息）和编程语言输入（代码上下文）。视觉输入在移动应用测试任务中更广泛使用，因为可点击的控件可以很容易地在截图中定位。

行动（Action）
现有用于SE的LLM智能体的行动组件主要涉及使用外部工具来扩展其能力。图17总结了这些智能体系统中使用的工具。这些工具包括搜索工具（网络搜索、知识库搜索）、文件操作、GUI操作、静态程序分析（静态信息收集、代码质量检查）、动态分析（方法调用跟踪、运行时值、覆盖率）、测试工具（测试验证、测试生成、变异测试）、故障定位工具和版本控制工具。

图17: SE中LLM智能体行动组件的分类

5.2 多智能体系统

根据我们的统计，现有用于SE的智能体中有52.8%是多智能体系统。这些系统受益于专业角色的划分和智能体之间的协调，有效地解决了SE任务的复杂性。本节概述了现有用于SE的多智能体系统，重点是它们的智能体角色和协调机制。

图18: SE中基于LLM的多智能体系统中智能体角色的分类

智能体角色
在多智能体系统中，每个智能体通常被分配一个专门的角色。图18总结了现有用于SE的多智能体系统中的常见智能体角色。
- 管理者角色：如CEO、CTO、指挥官和控制器，负责决策、规划、任务分解和分配，以及监督团队协调。
- 需求分析角色：负责分析软件需求，将模糊的用户概念转化为连贯、结构化的格式。
- 设计师角色：负责软件架构和系统集成，包括软件架构设计师和UI/UX设计师。
- 开发者角色：在软件开发和维护活动中扮演重要角色，负责生成或最终确定代码。
- 软件质量保证角色：包括代码审查员、测试员和调试员，专注于检查和提高软件质量。
- 助理角色：主要为其他智能体提供协助，如增强对目标仓库架构的理解。

协作机制
协作机制对多智能体系统至关重要。现有用于SE任务的多智能体系统的协作机制可分为四种类型：分层结构、循环结构、树状结构和星状结构。图19展示了每种结构。
- 分层结构：一种层级结构，任务被分解为多个子阶段，每个阶段分配给特定的智能体或智能体组。
- 循环结构：通常表现为多轮对话或在整个协作过程中集成反馈机制，通过迭代循环优化输出。
- 树状结构：与分层结构不同，同一层的智能体不为同一子任务合作，而是专注于自己的工作。
- 星状结构：一种集中式结构，一个中心智能体作为枢纽与其他智能体互动。

图19: 多智能体系统协作机制

5.3 人机协作

虽然大多数智能体旨在实现最大程度的自动化，但一些智能体整合了人机合作范式，以进一步使智能体性能与人类偏好和专业知识对齐和增强。如图20所示，现有智能体主要在四个阶段引入人类参与：规划、需求、开发和评估。
- 规划阶段：一些智能体在智能体工作流的规划阶段引入人类干预，允许用户修改自动生成的工作流。
- 需求阶段：智能体系统通常会引入手动优化需求，以弥合智能体系统最终输出与用户意图之间的差距。
- 开发阶段：在软件开发阶段引入人类参与，以指导智能体制定解决方案并克服潜在的失败。
- 评估阶段：人类参与也作为对智能体系统产出结果的后评估机制，以进一步确保输出符合用户意图。

图20: SE中的人机协作

A4 实验评估

评估指标
当前对软件工程智能体的评估主要关注其解决特定任务的能力（如成功率），而缺乏对中间状态的细粒度度量。这使得难以评估智能体失败的原因。此外，现有指标严重偏重于有效性，而对鲁棒性、安全性和公平性等可信赖性要求探讨不足。成本也是一个关键考虑因素，但只有44.3%的论文明确考虑了效率，包括时间、Token消耗、金钱成本和反馈循环的定量分析。

基准测试
基于LLM的智能体在处理更复杂的端到端SE任务方面显示出巨大潜力，但用于评估这些智能体的现有基准通常存在质量问题。例如，SWE-bench基准包含任务描述模糊或不完整的任务。此外，当前基准中的许多任务远比现实世界的SE挑战简单。例如，端到端开发生成的软件规模相对较小，大部分SWE-bench任务可在一小时内由经验丰富的工程师完成，这凸显了基准任务与现实世界SE挑战之间的差距。

A5 结论与展望

结论

本文对106篇关于基于LLM的软件工程智能体的论文进行了全面而系统的综述。我们从软件工程和智能体两个角度分析了当前的研究。从软件工程的角度，我们分析了基于LLM的智能体如何应用于不同的软件开发和维护活动。从智能体的角度，我们专注于基于LLM的软件工程智能体中组件的设计。此外，我们还讨论了这个关键领域的开放挑战和未来方向。

研究机遇与展望

SE智能体的评估：需要开发更全面、更严格的评估框架，包括设计更多样化的细粒度指标（不仅关注最终成功率，还应包括中间状态和可信赖性需求如鲁棒性、安全性）和构建更高质量、更现实的基准，以反映真实世界软件工程的复杂性。
人机协作：需要探索如何更深入地将人类参与整合到整个软件开发生命周期中，并设计有效的交互机制，以增强智能体输出的质量和适应性。
感知模态：探索和整合更多样化的感知模态（如语音命令、用户手势）进入智能体，可以显著增强编程助手的灵活性和可访问性。
将智能体应用于更多SE任务：设计、验证和特性维护等关键阶段仍未得到充分探索，为这些阶段开发量身定制的智能体系统存在独特的挑战，需要高级的推理和理解能力。
为SE智能体训练面向软件的LLM：利用整个软件开发生命周期中的多样化数据（如设计、架构、开发者讨论、历史代码变更和动态运行时信息）来训练更强大的面向软件的LLM，可以为更先进的智能体系统奠定基础。
在构建智能体中运用SE专业知识：将成熟的SE专业知识（如先进的调试和测试方法、软件过程模型）整合到智能体系统的设计中，可以提高智能体解决方案的有效性、鲁棒性、效率、可解释性和可复制性。

Large Language Model-Based Agents for Software Engineering: A Survey