AI自动编程的智能体语言与框架构建?IDE插件AutoDev示例

代码为聘礼 2024-03-30 01:35:22

上周微软发布了自家的 AI 编程和软件开发智能体框架:AutoDev,其与我们开发的 IDE 插件 AutoDev 有颇多的相似之处,特别是一些设计思路,以及在对于辅助软件开发任务的智能体以及一些基础设施上。

稍有不同的是:

交互介质。我们的 AutoDev 构建基于 IDE API 体系构建的,而微软的 AutoDev 则是构建以 CLI 为主。隔离环境。我们设计了 DevIns 语言来构建隔离环境,而微软的 AutoDev 则是基于 Docker 隔离环境。

当危,我们的 AutoDev 开发人数比较有限,所以相比于微软的 AutoDev 成熟度上是相对比较低的。考虑到我们的 AutoDev 是一年前开源的,而微软的 AutoDev 是最近发布的,他们这取名有点不厚道。

AI 驱动软件开发的本质:“人类—AI—代码”的桥梁

对于 AI 驱动的自动编程来说,无非就是让 AI 能理解好人类的需求,然后实现 AI 与代码环境的自动交互。更详细来说,便是:

人类通过自然语言或者交互描述软件开发任务,如解释代码、生成代码、运行测试等。AI 结合智能体与上下文理解人类的需求,并生成对应的指令文本。代码环境接收指令文本,并执行对应的操作,再返回结果给人类或者 AI。

也因此,我们所要构建的上是一个基于 “人类—AI—代码环境” 的沟通桥梁。实现让 AI 能理解人类的需求,并不是一件复杂的事情,通过额外的需求澄清、展开, 就有初步得到格式化后的需求。而让 AI 与代码环境进行交互,则是一件更复杂的事情,即如何通过指令文本来实现的。

方式 1:基于文本的函数调用

函数调用(Function calling)可以让开发人员声名一系列的函数,将其与对应的说明传递给语言模型,让语言模型根据这些说明来生成格式化的结果。随后, 在对应的工具中,调用对应的 API 来实现对应的操作。诸如于 Google AI 中语言模型生成的返回结果示例:

{"functionCall": {"name": "find_theaters","args": {"movie": "Barbie","location": "Mountain View, CA"}}}

相似的方式,还有让 AI 生成对应的代码,如 shell 等,然后执行对应的代码。

方式 2:语言抽象的开发环境

我们对于自动化的探索是来自于 AutoDev 第一个需求,针对 Spring 框架的 AutoCRUD。在这个需求中,我们发现在复杂的软件开发任务中,需要动态生成 高质量上下文,以让 AI 能在对应的问题域中生成对应的代码。诸如于,生成 Controller 代码,需要知道现有 Controller,规范,以及对应的 Service、Repository 等代码。这一系列的信息,意味着,我们需要一个更高级别的语言来描述这些信息。

随后,我们在 AutoDev 中构建了一系列 Auto 功能(针对 React 的 AutoPage、针对鸿蒙操作系统的 AutoArkUI 等),以探索更合适的语言抽象来描述 “人类—AI—代码环境”,即 DevIns 语言。通过语言来作为人机接口,并作为可执行的代码,来实现对代码环境的操作。诸如于:

/patch```patch// the patch to apply```

通过形式化的方式来描述对 IDE 的操作,易于让 AI 理解,也易于让代码环境执行。

设计基于 IDE 的编程智能体开发

在设计 AutoDev 的自动编码功能时,我们依旧是按照在 Unit Mesh 架构范式下的设计思路来设计的, 即 AI 生成的都是可验证的代码。也因此,在我们设计 AutoDev 的自动测试功能时,也是基于这个思路来设计的。当然了,在有了 DevIns 语言后,就能实现 更多的自动化(理论上)。

接下来,让我们从实际的需求出发,以三个例子来看看日常的编码可以如何设计:

验证生成代码是否工作?进行安全的代码信息提交?探索自动化问题辅助修复?

当然了,还可以有更多的不同示例,这里就不一一列举了。

示例步骤 1:经验证可工作的代码

不论是人类,还是 LLM,要验证一段代码是否工作正确,最简单的方式就是运行它。运行它,通常有多种方式:

直接启动应用。通用 IDE 或者 CLI 来启动应用程序,通过交互界面或者 API 来验证代码的正确性。单元测试验证代码。即通过生成单元测试,以验证生成业务代码的正确性。构建 REPL 环境。而交互环境对于复杂应用的依赖管理并非易事,所以并非那么容易。

与启动应用的效率相比,显然通过测试驱动开发(TDD)来验证代码的正确性更加高效。因此,在结合 IDE 时,则需要多考虑一步:如何运行测试以验证代码。

于是,我们设计了一个简单的测试运行指令:

/run:src/test/java/cc/unitmesh/MathHelperTest.java

这样当我们生成了代码后,便可以通过运行测试来验证代码的正确性。由于 Intellij IDEA 支持不同的语言,但是不同的语言运行方式等是不同的。而由于 JetBrains IDE 使用了统一的底层抽象: RunConfiguration,因此我们构建了一个 RunService 来封装不同语言的运行方式:

interface RunService { fun createConfiguration(project: Project, virtualFile: VirtualFile): RunConfiguration? = nullfun runFile(project: Project, virtualFile: VirtualFile): String? { }}

更详细可以参见 RunService.kt 代码。

示例步骤 2:安全的 Git 操作

既然,我们生成了可验证的代码,那么下一步,我们应该考虑的是结合 VCS 来进行代码提交。为了确保不执行不安全的操作,我们不直接执行 Git 操作,而 是借助于 IDE 的 VCS API 来执行对应的操作。

于是,我们设计了 /commit 指令来提交代码:

/commit```commitfeat: add new feature```

而对于需要更复杂的场景,诸如于远程生成的任务来说,我们通过 /patch 指令来

示例步骤 3:自动化问题辅助修复

接下来,我们的挑战就是如何在 IDE 获取运行结果,并根据结果来进行对应的操作。于是,我们在 AutoDev 中设计了一个 DevInsProcessProcessor 来 处理 DevIns 指令的执行结果:

when { event.exitCode == 0 -> { val comment = lookupFlagComment(devInFile!!).firstOrNull() ?: return /// handle flag comments } event.exitCode != 0 -> { project.service<DevInsConversationService>().tryFixWithLlm(scriptPath) } }

即:

成功。当 exitCode 为 0 时,我们可以通过 flag comments 来决定如何处理失败。当 exitCode 不为 0 (如 -1)时,我们则可以继续通过 AI 来尝试修复对应的问题

在失败的场景时,我们需要构建完整的上下文:输入、编译输出、 执行结果/LLM 返回结果,以便于 AI 能更好的理解问题,再给出对应的修复方案。

更详细可以参见 DevInsProcessProcessor.kt 代码。

其它

我们依旧还在设计适用于 IDE 的自动开发框架与 DevIns 语言,如果大家有兴趣,可以参与到我们的开发中来。

GitHub:https://github.com/unit-mesh/auto-dev

0 阅读:0

代码为聘礼

简介:感谢大家的关注