论文信息

• 题目：《Communicative Agents for Software Development》
• 作者：Chen Qian and et al.
• 发表时间：28 Aug 2023

Abstract

软件工程是一个复杂的领域,通常需要仔细的决策过程,往往依赖于细微的直觉和咨询。近些年深度学习技术的进步开始改变软件工程实践,通过在软件开发各个阶段的精心设计来实现软件工程的革新。本文提出了一个创新的范式,利用大型语言模型贯穿整个软件开发过程,通过自然语言交流简化并统一关键过程,因此无需在每个阶段使用专门的模型。这个范式的核心是 CHATDEV,一个由虚拟聊天驱动的软件开发公司,它严格遵循瀑布模型,将开发过程细分为四个不同的顺序阶段:设计、编码、测试和文档编制。每个阶段都会让不同角色的代理进行有效沟通,促进无缝工作流程。聊天链充当促进者,将每个阶段分解成原子子任务。这使得双重角色成为可能,允许通过情景感知的交流提出和验证解决方案,从而有效解决特定的子任务。CHATDEV 的关键性分析强调了其在软件生成方面的显著效果,使整个软件开发过程在七分钟内完成,成本不到1美元。它不仅识别和缓解潜在的漏洞,而且在保持可观的效率和成本效益的同时,还能纠正潜在的幻象。CHATDEV的潜力揭示了将大型语言模型融入软件开发领域的崭新可能性。我们的代码可以在 链接: https://github.com/OpenBMB/ChatDev 上获取。

1. Introduction

“协作使我们能够知道比我们自己能知道的更多。它让我们能够以不同的方式思考,获取我们本不会获得的信息,并在共同努力实现共同目标的过程中结合想法。” ——保罗·索拉兹

软件工程需要一种规范化和纪律严明的方法来开发、运行和维护软件系统[4]。但是,软件智能的复杂性通常会导致基于直觉和有限咨询的决策[14]。最近深度学习技术的进步促使研究人员探索将其应用于软件工程,旨在提高效果、效率和成本减少。此前的深度学习驱动的软件工程研究致力于软件要求、设计、实现、测试和维护等各个阶段的各种任务[34;29]。软件开发过程涉及多个角色,包括组织协调、任务分配、代码编写、系统测试和文档准备。这是一个高度复杂和精细的活动,需要仔细地关注细节,因为它的开发周期很长[17;4]。

近年来,大型语言模型在自然语言处理[5]和计算机视觉[35]领域取得了重大突破。在被大规模语料训练后,大型语言模型在广泛的下游任务上展示了令人印象深刻的表现,如情景感知的问答、机器翻译和代码生成。事实上,软件开发的核心要素代码和文档都可以看作是“语言”(即字符序列)[7]。从这个角度来看,本文探索了一个由大型语言模型驱动的端到端软件开发框架,涵盖需求分析、代码开发、系统测试和文档生成,旨在提供一个统一的、高效的和费用效益高的软件开发范式。

直接利用大型语言模型生成整个软件系统在一定程度上会导致代码臆想,类似于自然语言知识查询中出现的臆想现象[2]。这些臆想包括功能实现不完整、缺少依赖项以及潜在的未被发现的错误。代码臆想主要由两个原因造成。首先,缺乏任务特异性会使大型语言模型在一次生成一个软件系统时感到困惑。像编程语言选择这样的软件开发细粒度任务提供了在高层次任务中缺失的引导式思考。其次,决策过程中缺乏相互审查的存在带来巨大风险[9]。个别模型实例提出各种各样的答案,需要将要求推到辩论或者检查其他模型实例的响应,以便汇聚到一个更准确的公共答案[12],比如代码同行评审和建议反馈。

为了解决上述挑战,我们“成立”了一个虚拟的聊天驱动软件技术公司——CHATDEV。它遵循经典的瀑布模型[3],并将过程分为四个阶段:设计、编码、测试和记录。在每个阶段,CHATDEV招募了多个角色的智能体,如程序员、审查员和测试人员。为了促进有效的交流和协作,CHATDEV利用所提出的聊天链将每个阶段细分为原子子任务。在聊天链中,每个节点表示一个特定的子任务,两个角色进行情景感知的多轮讨论以提出和验证解决方案。这种方法可以确保分析用户/客户需求、生成创意想法、设计和实现原型系统、识别和解决潜在问题、解释调试信息、创建吸引人的图形以及生成用户手册。通过沿着聊天链引导软件开发过程,CHATDEV向用户交付最终软件,包括源代码、依赖环境规范和用户手册。

对CHATDEV针对70个用户需求生成的所有软件进行分析。平均而言,CHATDEV为每个软件生成了17.04个文件,减轻了由代码臆想引起的潜在代码漏洞13.23次,软件生产时间为409.84秒,制造成本为0.2967美元。审查员与程序员之间的讨论导致识别和修改近20种代码漏洞,而测试员与程序员之间的讨论导致识别和解决超过10种潜在错误。总之,我们的主要贡献如下:

• 提出CHATDEV,一个聊天驱动的软件开发框架。仅通过指定一个任务,CHATDEV可以顺序处理设计、编码、测试和记录。这种新范式通过统一主要过程的自然语言交流来简化软件开发,消除了每个阶段都需要专用模型的需要。
• 提出聊天链将开发过程分解成顺序的原子子任务。每个子任务需要不同角色之间的协作互动和交叉检查。这种框架使多智能体协作、用户检查中间输出、错误诊断和推理干预成为可能。它确保每个聊天中对特定子任务的细粒度关注,有助于有效的协作并促进实现期望的输出。
• 为了进一步减轻代码臆想的潜在挑战,我们在代码完成、审查和测试的每个独立聊天过程中引入思维指示机制。通过“角色切换”,指导者明确地将特定的代码修改思路注入指示中,从而更准确地引导助手程序员。
• 实验表明CHATDEV自动化软件开发过程的效率和经济效益。通过每个聊天中角色之间的有效沟通、提议和相互检查,该框架实现了有效的决策。

2. CHATDEV

图1：CHATDEV 是我们由虚拟聊天驱动的软件开发公司，汇集了来自不同社会身份的代理，包括首席官员、专业程序员、测试工程师和艺术设计师。当人类“客户”提出初步任务（例如，“开发五子棋游戏”）时，CHATDEV 的代理通过协作聊天进行有效的沟通和相互验证。此过程使他们能够自动制作全面的软件解决方案，包括源代码、环境依赖关系和用户手册。

与使用大型语言模型进行自然语言查询时遇到的臆想类似[2],直接使用大型语言模型一次生成整个软件系统会导致严重的代码臆想,如功能不完整、缺少依赖项和未被发现的错误。这些臆想可能源自任务的不具体性和决策过程中缺乏相互审查。为了解决这些局限性,如图1所示,我们成立了一个虚拟的聊天驱动软件技术公司—— CHATDEV,它汇集了来自不同社会身份的智能体,如首席执行官、专业程序员、测试工程师和艺术设计师。当给予一个任务时,CHATDEV多样化的智能体将协作开发所需的软件,包括可执行系统、环境准则和用户手册。这种范式围绕利用大型语言模型作为核心思维组件展开,使智能体能够模拟整个软件开发过程,规避了额外模型训练的需要,在一定程度上减轻了不良代码臆想。

2.1 聊天链

CHATDEV采用广泛采用的瀑布模型,一个突出的软件开发生命周期模型,将软件开发过程划分为四个明确的阶段:设计、编码、测试和记录。在设计阶段,通过协作头脑风暴生成创新思路,并定义技术设计要求。编码阶段涉及源代码的开发和审查,而测试阶段将所有组件集成到一个系统中,并利用解释器的反馈信息进行调试。记录阶段包括环境规范和用户手册的生成。这些阶段都需要不同角色之间的有效沟通,在确定交互顺序和识别相关个体方面都很有挑战性。

为了解决这个问题,我们通过将每个阶段细分为多个具有特定重点的任务导向角色扮演的原子对话来提出一个泛化架构。通过参与智能体之间的指示交换和协作,每个聊天的期望输出形成目标软件的一个重要组成部分。此过程如图2所示,其中出现了一系列中间任务解决聊天的序列,称为“聊天链”。在每个聊天中,指导者发起指示,引导对话朝任务完成方向发展,而助手则遵循指示,提供合适的解决方案并讨论可行性。指导者和助手通过多轮对话合作,直到他们达成共识并确定任务已成功完成。

聊天链提供了对软件开发过程的透明视图,关注决策路径并在出现错误时提供调试机会,这使得用户可以检查中间输出、诊断错误并在必要时干预推理过程。此外,聊天链确保每个阶段内每个聊天对特定子任务的细粒度关注,有助于有效的协作并促进实现期望的输出。

图2: CHATDEV架构由阶段级和聊天级组件组成。在阶段级别,瀑布模型用于将软件开发过程划分为四个顺序阶段。在聊天级别,每个阶段进一步划分为原子聊天。这些原子聊天涉及两个智能体之间以特定任务为导向的角色扮演,促进协作沟通。交流遵循指示-遵循的风格,其中智能体互动以完成每个聊天中的特定子任务。

2.2 设计

在设计阶段,CHATDEV从人类客户那里获得初始想法。这个阶段涉及三个预定义角色:首席执行官(CEO)、首席产品官(CPO)和首席技术官(CTO)。 然后,聊天链将设计阶段分解为顺序的原子聊天任务,包括针对目标软件的模式(CEO和CPO)和编程语言(CEO和CTO)的决策。

图3：每次聊天中使用的三个关键机制。角色专业化确保每个代理履行其指定的职能，并有效地促进面向任务的对话。内存流保留了聊天中之前对话的全面记录，使代理能够做出明智的决策。当双方达成共识而不触发预定义的终止条件时，自我反思会促使助理反思拟议的决策。

角色分配系统提示用于在角色扮演过程中向每个智能体分配角色。与其他会话语言模型相比,我们对提示工程的方法仅限于启动角色扮演场景。指导者用$P_I$表示,助手的系统提示/消息用$P_A$表示。这些提示在对话开始前分配角色给智能体。令$L_I$和$L_A$代表两个大型语言模型。使用系统消息,我们有$I\leftarrow L_I^{P_I}$和$A\leftarrow L_A^{P_A}$,它们分别充当指导者和助手智能体(图3(a))。在我们的框架中,指导者最初扮演CEO的角色,进行交互式计划,而助手则扮演CPO的角色,执行任务并提供响应。为实现角色特定性,我们采用开端提示[23],这已被证明可以使智能体有效地发挥其角色作用。指导者和助手的开端提示包含与指定任务和角色、交流协议、终止条件以及旨在预防不良行为(例如指示冗余、无信息回复、无限循环等)的约束相关的关键细节。

记忆流[32]是一种机制,维护智能体先前对话的全面记录,以在后续决策中提供语句感知帮助。正式地,在时间$t$,指导者的消息表示为$I_t$,助手的消息表示为$A_t$,相关决策表示为$S_t$。等式1封装了到时间t的会话消息集合。
$$M_t=<(I_1,A_1),(I_2,A_2),\cdot \cdot \cdot ,(I_t,A_t)>S_t\leftarrow \psi (I_t,A_t)$$

其中$\psi$表示基于大型语言模型的决策提取器,可以通过交流协议检测或自我反思(详见下文)来实现。在后续时间步$t+1$,指导者利用历史对话消息集合$M_t$发出新的指示$I_{t+1}$,然后将其连同Mt一起传达给助手,如图3(b) 所示。助手以解决方案或消息的形式做出回应,表示为$A_{t+1}$,如等式2所示:
$$I_{t+1}=A(M_t,S_t)A_{t+1}=I(M_t,I_{t+1},S_t)$$

在获得响应$A_{t+1}$后,消息流使用等式3进行更新:
$$M_{t+1}=M_t\cup (I_{t+1},A_{t+1})S_{t+1}=S_t\cup \psi (I_{t+1},A_{t+1})$$

我们通过提示建立交流协议。例如,当双方达成共识时,遵循特定格式要求的结束消息(例如“<模式>:桌面应用程序”)会被生成。系统监测交流以确保遵守指定格式,允许结束当前对话。

自我反思 有时,我们观察到双方达成共识但未触发预定义的交流协议作为终止条件的对话。在这种情况下,我们引入自我反思机制,它涉及提取和检索记忆。为实现这一机制,我们聘请一个“伪自我”作为新的提问者,并发起新的聊天。伪提问者通知当前的助手有关先前对话的所有历史记录,并请求对话中的决定性信息进行总结,如图3(c） 所示。这种机制有效地鼓励助手反思对话期间提出和讨论的决定。

2.3 编码

编码阶段涉及三个预定义角色:CTO、程序员和艺术设计师。聊天链将编码阶段分解为顺序的原子聊天任务,例如生成完整代码(CTO和程序员)以及设计图形用户界面(设计师和程序员)。基于前一阶段讨论的主要设计,CTO指示程序员使用markdown格式实现一个软件系统。程序员生成代码并根据markdown格式提取相应代码。设计师提出一个以图形图标代替文本命令的用户友好图形用户界面。然后,设计师使用外部文本转图像工具[35]创建视觉吸引力的图形,程序员使用标准工具集将其合并到GUI设计中。

代码管理 为处理复杂的软件系统,CHATDEV使用面向对象的编程语言如Python。面向对象编程的模块性有利于自包含对象的故障排除和协作开发。复用性通过继承实现代码重用,减少冗余。我们引入“版本演变”机制,限制不同角色之间只能看到最新代码版本,从记忆流中丢弃早期代码版本。程序员使用Git相关命令管理项目。建议的代码修改和更改使软件版本增加1.0。版本演变逐步消除代码臆想。面向对象编程和版本演进的结合适合涉及长代码段的对话。

思维指示 传统的问答可能导致不准确或不相关的信息,特别是在代码生成时,朴素的指令可能导致意外的臆想。当指示程序员实现所有未实现的方法时,这一问题尤其成问题。例如,朴素的指令可能导致臆想,如包括作为未实现接口保留的方法。为解决此问题,我们提出“思维指示”机制,其灵感来自链式思维提示[44]。它明确地在指令中表达特定的问题求解思路,类似顺序解决子任务。如图4(a) 和4(b) 所示,思维指示包括切换角色以询问哪些方法还未实现,然后再切换回来更准确地为程序员提供遵循的指示。通过合并思维指示,编码过程变得更加聚焦和目标明确。指令中对特定思想的明确表达有助于减少歧义,确保生成的代码符合预期目标。这种机制使代码完成更准确、更符合情景,最大限度地减少臆想的发生,从而产生更可靠和全面的代码输出。

图4：思维指令减轻了编码和测试阶段的代码幻觉。思想指导不是提供通用指令，而是涉及角色交换以询问未实现的方法或解释由错误引起的反馈消息。此步骤可以让您更清楚地了解现有代码并确定需要解决的具体差距。通过获得这种意识，角色可以切换回来，讲师可以提供更具体的说明来准确地指导程序员。

2.4 测试

即使对于人类程序员来说,也无法保证他们第一次编写的代码就完全没有错误。人类通常分析和调查代码执行结果以识别和纠正实现错误[8],而不是直接丢弃错误的代码。在CHATDEV中,测试阶段涉及三个角色:程序员、审查员和测试员。该过程包括顺序的原子聊天任务,包括同行评审(程序员和审查员)和系统测试(程序员和测试员)。同行评审或静态调试检查源代码以识别潜在问题。系统测试是一种动态调试,通过程序员使用解释器进行的测试来验证软件执行。这种测试着重评估应用程序性能的黑箱测试。

在我们的实践中,我们观察到仅根据解释器的反馈消息使两个智能体进行交流无法产生无bug系统。程序员的修改可能不严格遵循反馈,导致臆想。为解决此问题,我们进一步采用思维指示机制在指令中明确表达调试思路(图4(c） 和4(d))。测试员执行软件,分析bug,提出修改,并相应地指示程序员。这一迭代过程持续进行,直到潜在bug被消除并且系统成功运行。

当解释器在识别细粒度逻辑问题时遇到困难时,人类客户参与软件测试是可选的。 CHATDEV使人类客户能够以类似审查员或测试员的方式提供自然语言反馈和建议,使用黑箱测试或其他策略。基于人类输入,CHATDEV可以理解并利用此反馈来完善软件系统。

2.5 记录

在设计、编码和测试阶段之后,CHATDEV聘用四个智能体(CEO、CPO、CTO和程序员)生成软件项目文档。利用大型语言模型,我们通过使用上下文示例的少样本提示[5]进行文档生成。 CTO指示程序员提供环境依赖性的配置说明,生成类似requirements.txt的文档。此文档允许用户独立配置环境。同时,CEO将需求和系统设计传达给CPO,后者生成用户手册。

3. 实验

图5：文档化阶段涉及生成相关文档，例如外部依赖规范和用户指令。用户手册提供了有关软件技术架构、安装说明和功能的全面信息，是用户的宝贵资源。一旦安装了依赖项，人类客户端就可以使用合适的解释器来执行该软件。

我们的实验设置使用ChatGPT的gpt3.5-turbo-16k版本来模拟多智能体软件开发。语言模型温度设置为0.2以实现可控生成。在编码阶段,我们允许代码完成最多5次尝试。允许审查员进行5次聊天来提出修改建议,测试阶段最多进行5次软件系统测试。对于基于Python的系统,我们使用Python 3.8.16作为测试的解释器。

Camel[23]整理了一个跨越20种编程语言、50个领域和每个领域50个任务的指示遵循对话数据集。从这个庞大的任务集中,我们随机选择了70个任务[1],包括具体的和相对抽象的案例,作为CHATDEV软件开发的分析基础。

软件统计 我们对CHATDEV生成的软件系统进行了统计分析。检查关键指标,包括对话轮数、消耗tokens、软件文件、图像资产和版本更新。表1显示了这些指标,提供了关于基于交流的软件开发过程的有价值的洞察。它全面概述了CHATDEV的开发,涵盖版本控制、文件组成、代码复杂性和开发迭代等方面。

表1: CHATDEV软件开发的统计分析,包括各个方面的最小值(Min)、最大值(Max)和平均值(Avg)。

生成的软件通常包含2到8个代码文件,平均4.26个文件。资产文件数量,即设计师使用外部工具[35]创建的图像,从0到21个,平均8.74个文件。程序员通过简洁的文本描述请求设计师创建图像,例如“用户可以输入数据的文本输入字段”、“财务信息展示仪表盘的背景图像”和“游戏中玩家角色的图像”。软件随附4到5个文档文件,平均数为4.04,如依赖项要求规范、用户手册、开发日志和软件元信息。

CHATDEV开发的软件源代码行数通常在39到359行之间,平均131.61行 $[2]$。数据表明CHATDEV倾向于产生相对小规模的代码软件。这在一定程度上是面向对象编程的设计所致,其中的复用性通过继承实现代码重用,减少冗余。我们还注意到,当用户指定的任务不太明确时,CHATDEV生成的源代码往往更短,平均约110.97行。这主要是因为CHATDEV采用高层次逻辑来满足非具体任务,通常生成侧重于为界面表示提供打印信息的代码。因此,我们建议为CHATDEV提供具体的指示,如所需的软件特性、系统规则、UI设计和其他详细规范。通过提供更清晰和更具体的指示,用户可以引导CHATDEV生成更全面和量身定制的代码,以符合他们的具体要求。环境依赖项数量,表示所需的外部软件组件数量,介于1到5之间,平均为2.90个依赖项。CHATDEV的软件环境通常包括numpy、matplotlib、pandas、tkinter、pillow或flask。该软件的用户手册由31到232行组成,平均53.96行。根据我们的经验,用户手册通常包括简介、快速安装、主要功能、使用说明等部分。

软件的版本更新次数在5到42之间,平均为13.23次更新。这表明源代码平均进行约13次修改,反映了编码阶段包括编码、审查和测试在内的整个软件开发过程中,智能体共同努力减轻代码臆想问题的协作。在极少数软件未通过最大测试次数的异常情况下,CHATDEV会主动采取措施,通过全面重新开发软件。在大多数情况下,软件开发过程涉及1到5个开发周期,平均为1.4个周期。

在我们的实验中，我们通过直接安装所需的软件依赖项来轻松设置沙箱环境。随后，我们使用 main 函数执行生成的软件。值得注意的是，大约 86.66% 的软件系统执行完美，展示了我们开发的软件的稳健性和可靠性。然而，一小部分（13.33%）的软件遇到了执行失败。在分析失败的软件创建后，我们确定了两个主要影响因素。首先，在 50% 的情况下，失败归因于 API 的令牌长度限制。此限制阻止了在代码生成的指定长度限制内获取完整的源代码。在处理复杂的软件系统或需要大量代码生成的场景时，此类挑战尤其明显。其余 50% 的失败软件创建主要受到外部依赖性问题的影响。当某些依赖项在云中不可用或版本不正确时，就会出现这些挑战，从而导致当前版本中特定应用程序编程接口 (API) 发生冲突和不可用。这些与外部依赖性相关的问题强调了对所需软件组件进行细致管理和协调以确保顺利执行和功能的重要性。总体而言，尽管遇到了一小部分失败，但我们的实验结果证明了 CHATDEV 在生成可执行软件系统方面的可行性和有效性，并且大多数系统成功执行。

持续时间分析 我们进行了持续时间分析,以检查使用CHATDEV的不同请求提示生成软件所需的时间。跨提示的开发时间变化反映了分配任务的复杂性和清晰度的差异。图6中的图形可视化表示了这个分布。最长的软件生产持续时间,由图左侧最高的条表示,为1030.00秒。这种扩展时间是由于审查员和程序员之间的大量对话,导致详细的修改方案。相比之下,图右端最短的条表示最小软件开发时间为169.00秒。这更短的持续时间是由于代码和测试阶段对话较少,没有明显的bug。平均而言,使用CHATDEV开发小规模软件和接口花费409.84秒,不到7.00分钟。相比之下,传统的定制软件开发周期,即使在敏捷软件开发方法中,每个周期通常需要2-4周,甚至几个月[22;10]。

图6：持续时间分布。图中的条形按降序排列，显示了不同任务的软件开发运行时的分布。

对话统计 在CHATDEV中,我们采用聊天链机制来促进软件开发。每个聊天链表示针对一个特定任务的软件生产,由多个多语句聊天轮组成。在这些轮中,智能体进行讨论以解决预定义的子任务,如语言选择、提出解决方案和做出最终决定。完成所有子任务后,聊天链以开发软件产品而结束。对于我们的案例学习任务,我们分析了聊天链并收集了统计数据,包括语句总数和使用的提示标记数。这些统计数据如表2所示。

我们注意到对话中偶尔出现重复的感谢表达,即使在达成共识和做出决定后。但是,这种现象并不会对最终结果产生重大影响。自我反思机制可以有效地使智能体通过类似文本摘要的能力提取决策结果和结论。这种机制有助于智能体避免不必要的对话,专注于从对话中提取有意义的信息。对话中的自我反思次数在1到4之间,平均为1.24。在大多数情况下,智能体可以根据预定义的交流协议自主结束对话。

平均而言,一个聊天链包含45.60个语句,最小的为24个,最大的为104个。语句计数包括有关子任务可行性的讨论、对生成代码质量的评估、测试反馈、改进建议以及实际编写和生成软件代码文件和文档。同样,我们观察到CHATDEV在抽象任务中往往进行更少的交流语句,平均约34.40个。对对话的分析表明,在设计和编码阶段,智能体进行了多轮讨论,深入探讨许多要求的细节或提出修改建议。这些讨论旨在就特定任务作出知情决定。这一现象与现实世界的实践一致,解决具体任务通常需要更详细的讨论和审议。

我们监控CHATDEV软件生产中的API交互和令牌使用情况。平均而言,CHATDEV需要36,902.23个提示令牌、11,567.37个补全令牌,总计48,469.60个令牌来开发单个软件。平均软件生产总成本约为0.1569美元[3]。为确定CHATDEV的整体软件开发成本,我们还要考虑设计师产生的图像成本。平均每个软件的设计师成本为0.1398美元,每个软件平均涉及8.74个图形创建。因此,CHATDEV的平均软件开发成本为0.2967美元,远低于传统定制软件开发公司的费用[18;21;31]。

审查员-程序员对话分析 在这部分,我们深入探讨编码阶段审查员和程序员之间关于代码相关事项的主要交流。我们总结了审查员对程序员源代码的评估。图7以饼图形式可视化表示了审查员在代码审查中的建议。如图所示,审查员与程序员沟通中讨论最频繁的问题是“未实现的方法”(34.85%)。这个挑战通常出现在复杂模型的代码生成中,其中核心功能通常被贴上占位标签(如Python中的“pass”),以待进一步完成。此外,对话中经常提到“未导入模块”(19.70%)的话题。这一问题源于代码生成的特点,生成的代码倾向于忽略细节。但是,在代码生成的背景下,确保代码的可执行性变得至关重要。幸运的是,本文提出的思维指示机制可以有效解决这些问题,迫使审查员识别不完整的方法,并要求程序员填写它们。这种机制可以应用于其他基于大型模型但部分缺失的任务完成情景。有趣的是,审查员还强调代码健壮性的重要性。他们强调考虑未来潜在异常的处理和避免重复类别的提示(3.03%)。此外,审查员提供关于代码中未使用的类的建议(1.52%)、识别无限循环(1.52%)以及强调正确环境初始化的必要性(1.52%)。

图7：审稿人建议的分布。饼图中的每种颜色代表审阅者提供的特定建议类别。

测试员-程序员对话分析 同样,我们分析测试阶段测试员和程序员之间的调试对话,并分类遇到的主要bug类型。结果如图8所示。如图所示,测试员和程序员之间最常见的调试问题是“未找到模块”(45.76%),近一半的情况。这反映了模型忽略非常细微的细节的倾向,尽管它们非常简单。幸运的是,通过本文提出的思维指示机制,这样的bug通常可以通过导入所需的类或方法来轻松解决。第二常见类型的错误是“属性错误”和“未知选项”,各占15.25%。“属性错误”是指类属性使用方面的错误,而“未知选项”表示方法调用的参数错误。另一种常见类型的错误是“导入错误”,与“未找到模块”相似,主要是由导入语句中的错误引起的,如导入错误的类或使用错误的导入路径。除了这些常见的错误类型之外,CHATDEV还具有检测相对较少见的错误类型的能力,如错误初始化的GUI(5.08%)、错误的方法调用(1.69%)、缺少文件依赖项(1.69%)、未使用的模块(1.69%)、装饰器语法错误(1.69%)等。

图8：测试人员建议的分布。饼图中的每种颜色代表测试人员提供的特定类别的错误。

案例学习 图9展示了一个CHATDEV开发五子棋游戏的示例。在左侧,我们看到没有GUI的朴素软件版本。这个游戏版本只能通过命令终端进行游戏,限制了其互动性和整体乐趣。相比之下,通过结合GUI设计,CHATDEV可以创建一个视觉上诱人的小游戏。这个版本在交互性和用户体验方面超越了无界面版本,提供了更令人愉快和吸引人的游戏环境。此外,CHATDEV的设计师可以协助程序员创建额外的图形来增强GUI的美观性和可用性,而不会影响其功能。这些由设计师精心制作的图形有助于使GUI在视觉上更令人愉悦和用户友好。

图9：“设计一个基本的五子棋游戏”任务的产品软件。

此外,如果人类用户对艺术设计师创建的图像不满意,他们可以在CHATDEV完成软件后自行替换原始图像。这允许根据用户的偏好进行进一步定制,而不会影响软件的核心功能。用户可以根据自己的喜好定制视觉元素,从而获得个性化的软件体验。

为了更全面地理解,我们举例设计阶段进行编程语言选择的对话过程。更多从五子棋游戏聊天链中提取的示例对话如附录A所示,包括我们设计的提示以及每个阶段智能体之间的对话过程。请注意,由于空间限制,我们在对话中只显示关键信息,省略过于细致的细节。

4. 讨论

尽管CHATDEV提供了一个新颖的软件开发范式,训练不需要,高效且具有成本效益,但我们认识到存在潜在的风险和限制,需要进一步的研究和解决。

即使我们将大型语言模型的温度参数设置为一个非常低的值,我们也观察到生成输出中存在固有的随机性。因此,每次运行生成的软件可能有所不同。因此,这种技术最适合开放和创造性的软件生产场景,其中的变化是可以接受的。此外,在某些情况下,生成的软件未能满足用户的需求。这可能是由于用户要求不明确以及文本或代码生成中固有的随机性所致。

虽然设计师智能体能够创建图像[35],但重要的是要认识到直接生成的图像在提升GUI美观方面可能并不总是有效。有时,它们可能引入过度复杂性,这可能阻碍用户体验。这主要是因为每个图像都是独立生成的,缺乏直接的视觉关联。为解决此问题,我们提供了自定义GUI的选项作为系统超参数,允许用户决定是否启用此功能。

此外,大型语言模型可能展示固有偏见[30],导致生成的代码模式不一定与真实程序员的问题求解思维保持一致。

关于风险,重要的是要注意,现有的大型语言模型没有完全调优以无害化,这使得它们容易被恶意用户滥用作有害用途。此外,生成的软件目前缺乏识别敏感文件操作的恶意意图。因此,在运行软件之前,用户应进行代码审查,以防止不必要的数据损失。

另外,评估我们的CHATDEV框架在软件级任务完成能力方面具有巨大的挑战,因为生成的任务范围广泛且异构,需要大量的领域专家参与。

虽然这项研究可能潜在地帮助真实世界中的初级程序员或工程师,但系统独立生成高级或大规模软件需求的完美源代码仍具有挑战性。这种困难源于智能体独立确定具体实现细节的有限能力,往往导致多轮冗长的讨论。此外,大规模软件开发对审查员和测试员来说也很具挑战性,因为在给定的时间约束内很难识别缺陷或漏洞。

5. 相关工作

基于深度学习的软件工程 软件工程(SE)是以规范化和纪律严明的方式设计、开发、测试和维护软件的过程[4]。由于软件工程的复杂性,大量决策是基于直觉做出的,最多也只是咨询高级开发人员。随着深度学习(DL)技术的快速发展,许多研究人员致力于将DL应用于SE,以提高软件开发的有效性和效率,降低人力成本。现有的基于DL的SE工作聚焦于软件生命周期中五个SE阶段的各种任务[14]:(1)软件需求分析是分析用户需求并规定软件需求的过程[34;46;13]。(2)软件设计涉及对软件框架、模块、协议和其他开发所需特征的规范[27;38;47]。 (3)软件实现是详细创建软件以实现设计的过程[16;1;6;29;11]。(4)软件测试是在一组测试用例上验证软件是否提供预期行为[42;40;43;39]。(5)软件维护是为软件用户提供必要支持,例如文档生成[19;40;28;20]。尽管通过适配DL方法进入SE取得了令人印象深刻的表现,但这些方法是隔离的,只能完成软件工程过程的一个特定步骤。更不用说这些基于DL的方法需要大规模的专门训练数据来实现某个目标,收集广泛的数据用于软件工程全过程是不实际的。

多智能体协作 大型语言模型(LLM)在广泛的领域展现出显著的专业知识。最近,一些工作探索了LLM之间的交互来实现几个目标。(1)行为模拟:Park等[33]在沙盒环境中创建多个生成式智能体来模拟可信的人类行为。Wang等[41]使用多个智能体来模拟推荐场景中的用户行为。(2)数据构建:Wei等[45]分配不同角色的智能体来收集和评估多方对话。Li等[24]提出一个角色扮演框架,利用智能体为复杂任务生成多样化和详细的指令。(3)性能改进:Salewski等[36]发现让智能体承担不同角色可以提高它们的表现。Du等[12]通过多智能体辩论改进事实正确性和推理准确性。 Liang等[25]使用多个智能体相互辩论以解决自我反思中的思维退化问题。Fu等[15]发现多个智能体可以在买卖谈判游戏中通过角色扮演和学习智能体反馈来互相改进。Liu等[26]设计了一个模拟的社交互动沙盒以实现LLM的社交调整。Talebirad等[37]引入具有独特属性和角色的多个智能体来处理黑盒环境中的复杂任务。

6. 结论

在这项研究中,我们提出了CHATDEV,一个基于聊天的端到端软件开发框架,利用LLM促进软件开发过程中涉及的多个角色之间的有效沟通和协作。通过使用聊天链分解开发过程为顺序的原子子任务,CHATDEV使每个子任务聚焦成为可能。另外,思维指示机制在代码完成、审查和测试阶段减轻了与代码臆想相关的挑战,通过明确表达特定的代码修改思路来指导程序员。我们的实验结果表明CHATDEV自动化软件开发过程的效率和成本效益。通过每个聊天中不同角色之间的合作互动和相互验证,该框架实现了每个子任务的有效决策。

展望未来,进一步的研究可以关注优化每个聊天中的交流协议和互动动态,以增强CHATDEV的性能和效果。此外,探索整合其他新兴技术,如强化学习和可解释AI,可以为解决挑战和改进整体软件开发过程提供宝贵的见解。我们的研究将持续探索CHATDEV智能体、工作流程和开发环境的增强和进步。总目标是通过改进各种特征,如缩短聊天链长度或优化子任务求解逻辑和策略,实现软件生产中更高效率,最终导致更精简和有效的软件生产过程。我们希望所提出的自然语言到软件框架的潜力可以为软件开发中大型语言模型的集成开辟崭新的可能性。