大模型重塑软件研发,从辅助编程到多 Agent 协同还有多远?

发布日期: 2024年8月7日

【导读】当编程成为最高频的 AI 应用场景,代码大模型的技术与产品发展之路该怎么走?本文作者从大模型软件研发的三大阶段和四大技术难点出发,分析了 AI 如何提升编程效率,并预测了未来软件研发工具的形态,终极目标是实现 AI 程序员,通过多智能体协同工作,大幅提升研发效率。

本文整理自阿里云云效、通义灵码产品技术负责人陈鑫在 2024 全球软件研发技术大会中的演讲,同时收录于《新程序员 008》。《新程序员 008》聚焦于大模型对软件开发的全面支撑,囊括 Daniel Jackson 和 Daniel Povey 等研发专家的真知灼见与“AGI 技术 50 人”栏目的深度访谈内容,

出品丨新程序员编辑部

大模型带来了前所未有机遇,突破传统软件工程和研发效能工具的局限,让 AI 成为软件研发必选项。
据统计,当前大模型技术近 30 %的应用需求来自于软件研发,在软件研发领域的应用也已经从简单的代码辅助生成,演进到能够实现自主处理和开发,市场上丰富的代码辅助工具也验证了这一点。
这些工具借助大语言模型来提高生成代码的准确性和性能,同时强调数据个性化的重要性,以满足不同企业和个人的编码习惯。我一直在思考,怎么才能进一步挖掘大语言模型的强大推理能力、理解能力和分析能力,给研发提供更强的辅助?代码大模型以及相关产品和技术发展之路该怎么走?
接下来,我将从大模型软件研发的三大阶段,四大难点等角度深入剖析。
 

大模型软件研发演进三步走
自AI技术浪潮再度袭来,大模型在编程领域的普及是个不可忽视的趋势。据统计数据显示,大模型技术近 30 %的应用需求来自于软件研发,编程成为最高频的 AI 应用场景。编程领域代码生成也是大模型擅长的方向,它可显著提升内部工作效率,让开发者协同的方式变得更加优雅、高效、流畅。AI已成为软件开发行业提升效率的关键要素。
据 CSDN、《新程序员》发起的《2024 中国开发者调查报告》显示,专门为开发而打造的 AI 辅助编码工具上,通义灵码使用率位居第一,占比 19 %。生成代码、解释 Bug 并提供修正、生成代码注释或者代码文档是开发者常用 AI 辅助编码工具来实现的事情,分别占比 41 %、29 %和 28 %。而我们正努力通过大模型与软件研发工具链的融合,逐步优化这些任务。
大模型正从两大方向影响着软件研发:

图 1  大模型对软件领域的影响

1、编程事务性工作的普遍替代

开发者的工作中存在大量重复性任务,例如编写胶水代码、框架代码和简单的业务逻辑。这些任务并非开发者核心关注点,如果大模型可以有效替代这些重复性工作,将显著提高个体效率。
此外,编程过程中通常涉及大量角色的协同工作,如产品经理、架构师、开发、测试和运维等。沟通往往耗时费力、协作成本高。如果能引入智能体,打造“超级个体”,将部分编码任务交由 AI 完成,就可以减少复杂的协同工作,提高整体协作效率。

2、知识传递模式的革新

传统的知识传递方式主要依赖于口口相传,如 code review、培训和代码规范的宣导等,这些方式往往滞后且效率低。智能化的研发工具链可以直接赋能一线开发者,提升团队整体水平。未来,每个团队可能会有专门擅长知识沉淀和梳理的成员,通过不断训练和优化大模型,使整个团队受益。
纵观整体趋势,大模型软件研发相关技术将分三步演进:
第一阶段:代码辅助生成
如 GitHub Copilot、通义灵码这类工具作为 IDE 插件,安装后可以显著提升编码效率,但并没有改变现有的编程习惯和研发工作流。AI 只是生成代码、编写测试或解释问题,最终的校验和确认依然由人完成,这个阶段,依然以人类为主导。
第二阶段:任务自主处理
AI 可以通过智能体技术自主校验生成的结果,例如,AI 编写测试用例后,能够自主判断测试是否通过、能否解决程序遇到的问题或发现新的问题。当我们进入智能体阶段,开发者可以减少对 AI 生成结果的人工校验。在此阶段,虽然仍以人类为主导,但AI已展现出独立完成特定任务的能力。此时将出现一条明显的产品分界线。
第三阶段:多智能体协同工作
多个智能体协同工作,并由大模型进行规划,完成复杂任务,如编写测试、写代码、撰写文档和需求分解等,而人类主要负责创意、纠偏和确认。这一阶段,AI 不只是 IDE 插件,而是可以实现功能的自主开发。代表性的产品有 GitHub Workspace 和今年 6 月阿里云刚推出的 AI 程序员,这些都标志着我们正在迎来 AI 自主化编程的时代。
以上前两个阶段,软件效率的提升大约在 10 %至 30 %之间,包括编码效率的提升 和 DevOps 流程的优化。那么,在第三阶段,我们可以通过打破现有的软件研发流程框架,面向 AI 设计新的编码框架和编程模式,效率提升有望突破 30 %,达到 50 %甚至 70 %。

死磕 Copilot 模式四大核心技术难点

 

接下来,当我们聚焦每个阶段,现有产品、技术发展的现状以及技术细节,就会发现未来还需攻坚的技术难点。以第一阶段最常见的 Copilot 模式为例,它主要分为以下几层:表现层、本地服务端、服务端、模型层、数据处理层、基础设施层。

图 2  Copilot 阶段通义灵码的核心功能架构

当我们聚焦现有代码助手产品技术发展的现状,以及技术细节,就会发现未来需要攻坚的难点主要有四点:

  • 生成的准确度:准确率是决定产品能否应用于生产的关键因素;

  • 推理性能:代码生成速度和整体性能的提升;

  • 数据个性化:适应不同企业和个人的编程习惯;

  • 代码安全与隐私:确保代码生成过程中数据的安全和隐私。
其中准确度包含生成准确度和补全信息准确度两方面。
1、加强生成准确度
根据内部调研报告显示,准确率才是产品的核心,开发者可以接受慢一点,也可以接受有瑕疵,但准确率才是决定能否应用于生产、会不会持续使用的最关键因素,而过硬的基础模型能力是准确度的基础。我们通常认为模型是产品能力的上限,一个靠谱的基础模型是首要的。
通义灵码的靠谱模型主要依赖以下两个:
通义灵码补全模型。它专做代码补全,被称为“ CodeQwen2 ”技术模型,是目前世界范围内非常强大的模型,在基础模型中排名第一,主要通过持续训练,提升其跨文件感知能力、生成代码能力及各个语言的细节优化,纠正其基础模型上的一些缺点,最终训练而成。
通义灵码问答模型。要想模型不仅基础能力强,还能很好地处理专项代码任务,就需要构造大量数据用于训练。单元测试、代码解释和代码优化等复杂任务,都需要构造大量数据进行训练,让模型遵循固定范式,从而持续输出稳定的结果。阿里目前基于 Qwen2 模型进行训练,它支持最大 128K 的上下文,不论是处理具体代码任务、Agent 任务,还是 RAG 优化,都表现出色。
除此之外,还需补全信息准确度开发者在写代码时,不仅关注当前文件,还有查看引用、工程框架及编码习惯等。因此我们在端侧还设置了复杂的代码分析功能,专门构建整个工程的引用链及相关数据,将其转化为全面的上下文传给大模型进行推理。在代码补全方面,我们进行插件与模型的联合优化,每增加一种上下文都需要构造大量数据训练模型,使其能感知到输入上下文与预测结果的关联关系。通过一系列处理,可大幅降低模型生成的幻觉,使其更好地遵循当前工程开发者的习惯,模仿人类编写相应代码,从而提升生成代码的质量。

图 3  通义灵码补全准确度的方式

 

2、解决性能问题
如何解决代码生成既快又好的问题,还是得在性能方面下功夫。各种代任务通常不是由单一模型完成的,而是多个模型组合完成。因此,在代码补全方面,我们使用了 CodeQwen2 这个 7B 参数的小模型能保证在 500 到 800 毫秒内完成推理,做到快;在代码任务训练方面,使用千亿参数模型成本高且不划算,用中等参数模型训练,性价比高且更擅长;对于问答任务,通过大参数模型 Qwen-Max 和互联网实时检索技术,可以快速且准确地回答这些问题。

通常,采用多个模型组合来保证时延的优化是比较靠谱的做法。大参数的模型,具有广泛的知识面和强大的编程能力,能够获取实时支持;各种加速和缓存技术,包括在端侧使用流式补全也可以降低延时;使用本地缓存、服务端缓存,再加上推理加速等多种技术,可以兼顾实现速度和准确性。这些措施共同作用,能让通义灵码能提供高效、准确的编程辅助。

图 4  通义灵码提升推理性能的方式

 

3、攻克数据个性化
数据个性化依然针对两个典型场景:代码补全和研发问答。

图 5  在代码补全、研发问答两方面提升推理性能

 

代码补全中,对于相似逻辑的编写,可以用企业已写过的优质逻辑代码来生成,避免重复造轮子。在自研框架的使用中,尤其是在前端开发,每个企业的前端框架往往不尽相同,如果直接使用基于开源数据训练的模型,生成的结果可能会有瑕疵,可以通过 RAG 技术,使员工在代码补全过程中实时获取所需的参考范例,从而生成符合企业规范的代码。

而研发问答这一领域相对成熟,文档问答、API 生成代码规范、代码校验等比较简单就能做到,假设开发者选中一段代码并请求模型根据团队规范进行修正,其背后的原理是通过 RAG 技术,模型能够检索团队当前语言的规范,并据此对代码进行校验和生成,这些都属于数据个性化场景应用。

代码补全场景更加关注时延,力求将检索时间降低到 100 毫秒以内,技术实现有一定难度。而研发问答场景更注重精准度,目标是召回率达到 70 %以上甚至 90 %以上,以提高回答效率。尽管优化目标不同,两者在基础设施上都涉及知识库管理、 RAG 流程、推理引擎和向量服务,这也是通义灵码重点优化的方向。

4、代码安全与隐私
为解决代码的安全隐私问题,我们设计了全链路安全防护策略,让企业可以以较低的成本享受到 AI 的能力,每月仅需一两杯咖啡钱。
图 6  通义灵码的全链路安全防护
  • 加密端侧代码,确保即使请求被拦截也无法复原代码;
  • 制定本地向量存储和推理全部在本地完成的策略,除非是主动上传的企业级数据,否则代码不会上传到云端,保证了云端没有代码残留,即使黑客攻破了通义灵码集群,也无法获取用户数据,确保了安全性;
  • 设置敏感信息过滤器,确保所有企业上传的代码都合规,能够放心使用公共云的推理服务,实现极高的性价比。

从简单走向复杂的代码生成,并非一蹴而就
通义灵码在以 Copilot 为代表的代码助手方面已经比较成熟,从满意度调查和替代率两个重要方向来评估它在企业中的满意度。基于 1124 份有效样本,超过 72.5 %的受访者在编码工作效率提高方面给予了四分以上的评分(总分为五分)。针对后端语言,通义灵码生成代码的替代率在 30 %以上,而前端由于存在大量的复制粘贴操作,生成率略低,约为 20 %左右。
那么,在大模型软件研发相关技术演进的第二阶段,我们如何从简单的代码任务逐步走向复杂的代码生成?
2024 年 3 月,Devin 发布,只需一句指令,它可以端到端地进行软件开发和维护。虽然只是一个预览版,但它让我们看到 Multi Agent 方向的可行性。这是从 0 到 1 的突破,Devin 显著提升了 AI 在实际编码任务中的应用能力。同年 4 月,GitHub  发布了 Workspace,它是编码自动化的初步尝试。
以上再次证明了 AI 在代码生成领域的潜力巨大,尽管还有很长的路要走,但这表明我们正在朝着实现更高效、更智能的编程环境迈进。在技术路线上,我认为需要分为四个阶段逐步发展,而非一次性跃迁。
图 7  从单一 Agent,走向多 Agent 架构的四大阶段

第一阶段:单工程问答 Agent

要解决基于单工程的问答需求。典型的功能如代码查询、逻辑查询、工程解释,基于工程上下文的增删改查接口、编写算法,在 MyBatis 文件中增加 SQL 语句等,都属于简单任务,已经充分利用了单库的 RAG 技术以及简单的Agent来实现。这为更复杂的多 Agent 协同系统打下了基础。

第二阶段:编码 Agent

进入能够自主完成编码的阶段。Agent 将具备一定自主任务规划能力,以及使用工具能力,可自主完成单库范围内的编码任务。例如,在集成开发环境(IDE)中遇到编译错误或缺陷报告时,用户可以一键让 AI 生成相应的补丁。

第三阶段:测试 Agent

到达具备自主测试能力的 Agent 阶段,它不仅能够编写单元测试,还能理解任务需求、阅读代码并生成测试。不管是单元测试还是黑盒测试方法。而另一些 Agent 可以用于架构分解、文档编写、辅助阅读等功能。

第四阶段:Multi-Agent

接下来,多 Agent 基于 AI 调度共同完成任务,就可以实现更复杂的任务管理和协作实现,从需求->代码->测试的全流程自主化。我们的终极目标是 AI 程序员的水平,类似于 Devin 项目。这一阶段将涵盖更复杂的编程任务,需要更高级的 AI 调度和协同能力。

 

 

Code Agent 落地门槛:问题解决率至少 50 %以上

 

从整个技术路线图来看,前三步通义灵码已覆盖。它展示了整体工作流,以本地库内检索增强服务为核心,提高了代码和文档的准确检索及重排效率,并结合企业知识库,增强了系统的综合问题解决能力。
这一过程需要不断优化,其过程涉及几个关键点:首先,深入理解需求,这是整个优化流程的基石;其次,提升需求在库内检索的成功率,它直接影响到后续步骤的效率与效果;再者,模型本身的性能提升,将检索到的信息整合并解决问题的能力至关重要,这是 Code Agent 的前身。
接下来要重点攻克的是 Code Agent 技术。SWE-bench-Lite 测试集是业界公认的Code Agent 测试标准,在测试集上,通义灵码 Agent 实现了 33 %的问题解决率,领先业界。然而,要推动这一技术走向实际应用,仍面临诸多挑战。
图 8  灵码 Agent 在 SWE-bench-Lite SOTA 测试集的表现
难点一:当前 Code Agent 的效果高度依赖 GPT-4 等先进基础模型,基础模型的能力可能是整个领域往前走的一大阻碍,这限制了技术的普及与自主可控性。
难点二:上述方案在调优上比较困难,容易牵一发动全身,难以快速迭代;
难点三:长上下文依赖和多轮次复杂 Action 处理仍是技术瓶颈;
难点四:模型调优问题,这是当前的一个重要挑战,即便是使用 GPT-4,我们在SWE-bench-Lite SOTA 测试集上的表现也仅为 30 %以上的问题解决率,这与生产级可落地的标准仍存在较大差距。因为测试集中不仅包含了相对简单的单文件修改任务,还涉及到了更为复杂的多文件和多任务修复场景,这对模型的上下文理解、逻辑推断及代码生成能力提出了更高的要求。要达到生产级可落地的标准,需要至少将问题解决率提升至 50 %以上,继续加大技术研发投入是必要的。

未来的软件研发工具形态

 

对于通义灵码仍有差距的第四阶段——Multi-Agent 阶段,我们也已经有了清晰的概念架构,其工作流程大概是:用户输入指令后,一个复杂的多 Agent 协同系统随即启动。该系统核心解决三大问题:
  • 首先,通过结构化的任务管理,模拟人类团队分解大型任务的行为,实现高效协作;

  • 其次,简化工作流程,将复杂任务细化为小任务,并借助 Agent 特性逐一执行;

  • 最后,高效执行任务,让每个智能体专注自身任务并协同工作,共同完成复杂任务。

未来的软件研发工具链也将呈现三层架构:
图 9  未来的软件研发工具链架构

底层为 AI 基建层,为中层的通义灵码与AI程序员等提供基础支持,涵盖运行环境、模型推理服务、模型微调 SFT、检索增强 RAG、企业管理功能及核心模型。在 AI 基建层,工具共享、不同模型各司其职,这进一步验证了我们的技术演进路线。

通义灵码与中层的 AI 程序员之间存在递进的技术演进关系,虽然共享同一 AI 基建,但在产品交互及与开发者的连接方式上,两者差异显著。AI 程序员拥有自主化工作区,采用问答式交互方式,这种非传统 IDE 形态却能无缝连接最上层的 IDE 端、开发者门户及 IM 工具,成为开发者主要入口的延伸。
右侧,与现有 DevOps 工具链紧密链接,在不颠覆现有 DevOps 或 CICD 流程的基础上,极大地简化和优化了这些流程。
AI 程序员边界明确,专注于从任务输入到文档编写、测试用例测试完成的全过程,未涉及 CICD 或复杂运维操作,作为现有工具链的有效补充,它将大幅简化工具链交互,优化流程协作,对组织结构和开发者技能产生深远影响,甚至可能引领未来编程软件向 AI+Serverless 的架构转型。
当前的 Serverless 主要由各类 function 构成,并通过 workflow 紧密相连。AI 擅长独立完成单一的 function,但面对庞大、复杂的代码工程,尤其是质量欠佳的代码时,修复能力尚显不足。未来,Serverless 与 AI 融合的编程架构有望成为主流趋势,这并非无稽之谈。我们坚信,随着技术和基础模型的不断演进,预计在未来 3-6 个月内,将有相应产品推出,并有望在部分生产级场景中实现落地应用。

阿里云内部代码助手落地实况

 

阿里云已经全员推行 AI 辅助编码,同时充分考虑各部门的差异。面对不同部门的框架差异,主要采取两种策略。一种是通过 RAG 来实现,即根据每个部门自身需求建立知识库,用于补全和问答优化。每个部门都能梳理并优化其常用代码样例、框架示例及 API 示例,尽量保持其独特性。这种方式让一个工具能够灵活覆盖所有部门的需求。
另一种是进行模型微调,已在一些企业中尝试过。利用小规模数据集对模型进行微调,结果显示,这种基于个性化业务代码的微调能够显著提升模型的准确率,虽然有效,但其成本较高且过程复杂。
从采纳率和 AI 代码生成占比来看。目前,阿里云内部的 AI 代码生成占比已达到 31%,后端语言如 Java 的占比更高,达到 30 %以上。这些数字表明,基于开源代码训练的模型已经能够在实际应用中发挥重要作用,未来通过 RAG 的进一步优化,我们有信心进一步提升这些指标。
关于前文提到的通过前端工具将上下文学习与后端大模型结合,以在代码补全方面取得更好效果,我们主要根据不同语言的特性来解析代码的依赖关系,以构建整个工程的依赖树。当我们需要为某个文件进行代码补全时,会找到该文件所处的上下文,类似于人类编写代码时的行为。为确保代码补全的准确性,需要将当前文件的所有依赖项都纳入上下文考虑范围,否则模型可能会产生“幻觉”,即生成与上下文不符的代码。
此外,我们还会寻找与当前编写位置相似的代码片段,帮助模型理解工程内部的编写风格,为代码补全提供有价值的参考。以 Spring Boot 等框架为例,许多内部扩展或“胶水层”代码都具有一定的相似性。通过找到这些相似代码,模型能够生成更贴近实际需求的代码,从而提高采纳率。
同时我们会收集跨页面的相似组件信息,以供模型参考。判断哪些上下文对当前位置的代码生成具有更高的采纳概率,再通过算法调优来确保模型能够优先利用最重要的上下文信息,包括优先级排序、筛选和压缩等一系列操作。
一般情况下业务研发部门无需直接参与前端上下文知识的处理工作,这取决于具体的业务需求和项目复杂度。

为了进一步提升效果,我们还需要收集和处理业务单位的反馈。在实际应用中,开发者们可能会遇到一些“ bad case ”,即插件生成的代码不符合他们的期望或需求。为了优化插件的性能和准确性,我们需要基于具体场景进行调优。我们会不断优化通义灵码并持续发布先进的产品,向着大模型赋能软件开发的终极形态坚定地走下去。