新智元报道
编辑：桃子 润
【新智元导读】全球首个 AI 程序员 Devin 诞生之后，让码农纷纷恐慌。没想到，微软同时也整出了一个 AI 程序员 ——AutoDev，能够自主生成、执行代码等任务。网友惊呼，AI 编码发展太快了。
全球首个 AI 程序员 Devin 的横空出世，可能成为软件和 AI 发展史上一个重要的节点。它掌握了全栈的技能，不仅可以写代码 debug，训模型，还可以去美国最大求职网站 Upwork 上抢单。
一时间，网友们惊呼，「程序员不存在了」？甚至连刚开始攻读计算机学位的人也恐慌，「10 倍 AI 工程师」对未来的工作影响。
除了 Cognition AI 这种明星初创公司，美国的各个大厂也早就在想办法用 AI 智能体降本增效了。就在 3 月 14 日同一天，微软团队也发布了一个「微软 AI 程序员」——AutoDev。
与 Devin 这种极致追求效率和产出结果的方向有所不同。AutoDev 专为自主规划、执行复杂的软件工程任务而设计，还能维护 Docker 环境中的隐私和安全。
在此之前，微软已有主打产品 GitHub Copilot，帮助开发人员完成软件开发。
然而，包括 GitHub Copilot 在内的一些 AI 工具，并没有充分利用 IDE 中所有的潜在功能，比如构建、测试、执行代码、git 操作等。
基于聊天界面的要求，它们主要侧重于建议代码片段，以及文件操作。AutoDev 的诞生，就是为了填补这一空白。
用户可以定义复杂的软件工程目标，AutoDev 会将这些目标分配给自主 AI 智能体来实现。
然后，这些 AI 智能体可以对代码库执行各种操作，包括文件编辑、检索、构建过程、执行、测试和 git 操作。
甚至，它们还能访问文件、编译器输出、构建和测试日志、静态分析工具等。
在 HumanEval 测试中，AutoDev 分别在代码生成和测试生成方面，分别取得了 91.5% 和 87.8% Pass@1 的优秀结果。
网友表示，AI 编码发展太快了，2021 年 GitHub Copilot 能解决 28.8% 的 HumanEval 问题，到了 2024 年，AutoDev 直接解决了 91.5% 的问题。
不用人类插手，AutoDev 自主完成任务
AutoDev 工作流程如下图所示，用户定义一个目标，比如「测试特定方法」。
AI 智能体将测试写入一个新文件，并启动测试执行命令，以上都在安全的评估环境中进行。
然后，测试执行的输出（包括失败日志）将合并到对话中。
AI 智能体分析这些输出，触发检索命令，通过编辑文件合并检索到的信息，然后重新启动测试执行。
最后，Eval 环境提供有关测试执行是否成功，以及用户目标完成情况的反馈。
整个过程由 AutoDev 自主协调，除了设定初始目标之外，无需要开发人员干预。
相比之下，如果现有的 AI 编码助手集成到 IDE 中，开发人员必须手动执行测试（比如运行 pytest）、向 AI 聊天界面提供失败日志、可能需要识别要合并的其他上下文信息，并重复验证操作确保 AI 生成修改后的代码后测试成功。
值得一提的是，AutoDev 从以前许多在 AI 智能体领域的研究中汲取了灵感，比如 AutoGen—— 编排语言模型工作流并推进多个智能体之间的对话。
AutoDev 的能力超越了对话管理，使智能体能够直接与代码存储库交互，自动执行命令和操作，从而扩展了 AutoGen。
同样，AutoDev 的研究也借鉴了 Auto-GPT。这是一种用于自主任务执行的开源 AI 智能体，通过提供代码和 IDE 特定功能来支持执行复杂的软件工程任务。
AutoDev 构架
上图是 AutoDev 架构的简单示意图。
AutoDev 主要由 4 个功能模块组成：
-用于跟踪和管理用户与代理对话的对话管理器（Conversation Manager）；
-为代理提供各种代码和集成开发环境相关工具的工具库（Tools library）；
-用于调度各种代理的代理调度器（Agents Scheduler）；
-以及用于执行操作的评估环境（Evaluation Environment）。
下面就给大家详细介绍每种功能模块。
规则、行动和目标配置
用户通过 yaml 文件配置规则和操作来启动流程。
这些文件定义了 AI 代理可以执行的可用命令（操作）。
用户可以通过启用 / 禁用特定命令来利用默认设置或细粒度权限，从而根据自己的特定需求量身定制 AutoDev。
配置步骤目的是实现对 AI 代理能力的精确控制。
在这一阶段，用户可以定义人工智能代理的数量和行为，分配特定的责任、权限和可用操作。
例如，用户可以定义一个 「开发者 」代理和一个 「审核者 」代理，让它们协同工作以实现目标。
根据规则和操作配置，用户可以指定 AutoDev 要完成的软件工程任务或流程。
例如，用户可以要求生成测试用例，并确保其语法正确、不包含错误（这涉及编辑文件、运行测试套件、执行语法检查和错误查找工具）。
对话管理器（conversation manager）
会话管理器负责初始化会话历史，在对正在进行的会话进行高级管理方面发挥着关键作用。它负责决定何时中断对话进程，并确保用户、人工智能代理和整个系统之间的无缝交流。
它维护和管理的对话对象，主要包括来自代理的信息和来自评估环境（eval environment）的操作结果。
解析器
解析器解释代理生成的响应，以预定格式提取指令和参数。它能确保指令格式正确，验证参数的数量和准确性（例如，文件编辑指令需要文件路径参数）。
如果解析失败，就会在对话中注入错误信息，阻止对资源库的进一步操作。
通过强制执行特定的代理权限和进行额外的语义检查，成功解析的命令会被进一步分析。
它能确保建议的操作符合用户指定的细粒度权限。
如果命令通过审查，对话管理器就会调用工具库中的相应操作。
输出组织器
输出组织器模块主要负责处理从评估环境接收到的输出。
它选择关键信息（如状态或错误），有选择地总结相关内容，并将结构良好的信息添加到对话历史记录中。
这可确保用户对 AutoDev 的操作和结果有一个清晰、有条理的记录。
对话终止器
会话管理器决定何时结束会话。这可能发生在代理发出任务完成信号（停止命令）、对话达到用户定义的最大迭代次数 / token、或在进程或评估环境中检测到问题时。
AutoDev 的全面设计确保了人工智能驱动开发的系统性和可控性。
代理调度程序（Multi-Agents）
代理调度器负责协调人工智能代理，以实现用户定义的目标。
配置了特定角色和可用命令集的代理协同运行，执行各种任务。调度器采用各种协作算法，如循环、基于令牌或基于优先级的算法，来决定代理参与对话的顺序和方式。
具体来说，调度算法包括但不限于以下几种：
(i) 循环协作，按顺序调用每个代理，让每个代理执行预定数量的操作；
(ii) 基于令牌的协作，让一个代理执行多个操作，直到它发出一个令牌，表示完成了分配的任务；
(iii) 基于优先级的协作，按照代理的优先级顺序启动代理。代理调度器通过当前对话调用特定代理。
代理
由 OpenAI GPT-4 等大型语言模型（LLM）和为代码生成而优化的小型语言模型（SLM）组成的代理通过文本自然语言进行交流。
这些代理从代理调度程序（Agent Scheduler）接收目标和对话历史，并根据规则和行动配置指定的行动做出响应。每个代理都有其独特的配置，有助于实现用户目标的整体进展。
工具库（Tools Library）
AutoDev 中的工具库提供了一系列命令，使代理能够对资源库执行各种操作。
这些命令旨在将复杂的操作、工具和实用程序封装在简单直观的命令结构中。
例如，通过 build 和 test <test_file> 这样的简单命令，就能抽象出与构建和测试执行有关的复杂问题。
-文件编辑：该类别包含用于编辑文件（包括代码、配置和文档）的命令。
-该类别中的实用程序，如写入、编辑、插入和删除，提供了不同程度的精细度。
-代理可以执行从写入整个文件到修改文件中特定行的各种操作。例如，命令 write <filepath> <start_line>-<end_line> <content> 允许代理用新内容重写一系列行。
检索：在这一类别中，检索工具包括 grep、find 和 ls 等基本 CLI 工具，以及更复杂的基于嵌入的技术。
这些技术能让代理查找类似的代码片段，从而提高他们从代码库中检索相关信息的能力。
例如，retrieve <content> 命令允许代理执行与所提供内容类似的基于嵌入的片段检索。
-构建与执行：这类命令允许代理使用简单直观的命令毫不费力地编译、构建和执行代码库。底层构建命令的复杂性已被抽象化，从而简化了评估环境基础架构中的流程。这类命令的示例包括：构建、运行 <文件>。
-测试与验证：这些命令使代理能够通过执行单个测试用例、特定测试文件或整个测试套件来测试代码库。代理可以执行这些操作，而无需依赖特定测试框架的底层命令。
这类工具还包括校验工具，如筛选器和错误查找工具。这类命令的例子包括：检查语法正确性的 syntax <file> 和运行整个测试套件的 test。
-Git：用户可以为 Git 操作配置细粒度权限。包括提交、推送和合并等操作。例如，可以授予代理只执行本地提交的权限，或者在必要时将更改推送到源代码库。
-通信：代理可以调用一系列旨在促进与其他代理和 / 或用户交流的命令。值得注意的是，talk 命令可以发送自然语言信息（不解释为版本库操作命令），ask 命令用于请求用户反馈，而 stop 命令可以中断进程，表示目标已实现或代理无法继续。
因此，AutoDev 中的工具库为人工智能代理提供了一套多功能且易于使用的工具，使其能够与代码库进行交互，并在协作开发环境中进行有效交流。
评估环境（Eval Environment）
评估环境在 Docker 容器中运行，可以安全地执行文件编辑、检索、构建、执行和测试命令。
它抽象了底层命令的复杂性，为代理提供了一个简化的界面。评估环境会将标准输出 / 错误返回给输出组织器模块。
整合
用户通过指定目标和相关设置启动对话。
对话管理器初始化一个对话对象，整合来自人工智能代理和评估环境的信息。随后，对话管理器将对话分派给负责协调人工智能代理行动的代理调度器。
作为人工智能代理，语言模型（大型或小型 LM）通过文本互动提出指令建议。
命令界面包含多种功能，包括文件编辑、检索、构建和执行、测试以及 Git 操作。对话管理器会对这些建议的命令进行解析，然后将其引导至评估环境，以便在代码库中执行。
这些命令在评估环境的安全范围内执行，并封装在 Docker 容器中。
执行后，产生的操作将无缝集成到对话历史中，为后续迭代做出贡献。
这种迭代过程一直持续到代理认为任务完成、用户干预发生或达到最大迭代限制为止。
AutoDev 的设计确保了系统、安全地协调人工智能代理，以自主和用户控制的方式完成复杂的软件工程任务。
实证评估设计
在研究人员的实证评估中，评估了 AutoDev 在软件工程任务中的能力和有效性，研究它是否能够提升人工智能模型的性能，而不仅仅是简单的推理。
此外，研究人员还评估了 AutoDev 在步骤数、推理调用和 token 方面的成本。
主要是确定了三个实验研究问题：
-𝑅 𝑄 1 : AutoDev 在代码生成任务中的效果如何？
-𝑅 𝑄 2 : AutoDev 在测试生成任务中的效果如何？
-𝑅 𝑄 3 : AutoDev 完成任务的效率如何？
𝑄 1 : AutoDev 在代码生成任务中的效率如何？
研究人员使用 Pass@k 指标来衡量 AutoDev 的有效性，其中𝑘表示尝试的次数。
成功解决的问题是指 AutoDev 生成的方法主体代码满足所有人工编写的测试。一次尝试相当于一次完整的 AutoDev 对话，其中涉及多个推理调用和步骤。
这与其他方法（如直接调用 GPT-4）形成鲜明对比，后者通常只涉及一次推理调用。有关多次推理调用和步骤的细节将在𝑅 𝑄 3 中进一步探讨。在本次评估中，研究人员设置𝑘 = 1，从而计算 Pass@1，只考虑第一次尝试的成功率。
𝑄 2：AutoDev 在测试生成任务中的效果如何？
对于这个研究问题，研究人员修改了 HumanEval 数据集，来评估 AutoDev 在生成测试方面的能力。
研究人员考虑人工编写的解决方案，并放弃所提供的人工编写的测试。
他们指示 AutoDev 为重点方法生成测试用例，并根据测试成功率、重点方法的调用和测试覆盖率对其进行评估。
研究人员报告 Pass@1，如果测试通过并调用了焦点方法，则认为测试成功。
此外，研究人员还将 AutoDev 测试的覆盖率与人工编写的测试覆盖率进行了比较。
𝑅 𝑄 3：AutoDev 完成任务的效率如何？
在本研究问题中，研究人员将调查 AutoDev 完成 SE 任务的效率。
研究人员分析了所需步骤或推理调用的数量、所使用命令的分布（如写入、测试）以及对话中使用的 token 总数。
AutoDev 设置
在本次评估中，AutoDev 基于 GPT-4 模型（gpt-4-1106-preview）与一个代理保持一致的设置。
启用的操作包括文件编辑、检索和测试。
唯一可用的通信命令是表示任务完成的 stop 命令。
其他命令，如询问，都是禁用的，这就要求 AutoDev 在初始目标设定之外，在没有人类反馈或干预的情况下自主运行。
实验结果
- AutoDev 在代码生成任务中的效率如何？
表 1 显示了，将 AutoDev 与两种替代方法和零样本基线进行了比较。
研究人员将 AutoDev 与语言代理树搜索（LATS）和 Reflexion 进行了比较，这两种方法是截至 2024 年 3 月 HumanEval 排行榜上的两种领先方法。
零样本基线（GPT-4）的结果取自 OpenAI GPT-4 技术报告。
AutoDev Pass@1 率为 91.5%，在 HumanEval 排行榜上稳居第二。
值得注意的是，这个结果是在没有额外训练数据的情况下获得的，这将 AutoDev 与 LATS 区分开来，后者达到了 94.4%。
此外，AutoDev 框架将 GPT-4 性能从 67% 提升至 91.5%，相对提升了 30%。
这些结果体现出，AutoDev 有能力显著提升大模型完成软件工程任务方面的表现。
- AutoDev 在测试生成任务中的效果如何？
AutoDev 在针对测试生成任务修改的 HumanEval 数据集上，获得了 87.8% Pass@1 分数，与使用相同 GPT-4 模型的基线相比，相对提高了 17%。
AutoDev 生成的正确测试（包含在 Pass@1 中）实现了 99.3% 的鲁棒覆盖率，与人工编写的测试的 99.4% 覆盖率相当。
- AutoDev 完成任务的效率如何？
图 3 显示了，AutoDev 在代码生成和测试生成任务中使用的命令累积数，其中考虑到问题 1 和问题 2 中每个 HumanEval 问题的平均评估命令数量。
对于代码生成，AutoDev 平均执行 5.5 条命令，其中包括 1.8 条写入操作、1.7 条测试操作、0.92 条停止操作（表示任务完成）、0.25 条错误命令，以及最少的检索（grep、find、cat）、语法检查操作和通话通信命令。
在「测试生成」任务中，命令的平均数量与「代码生成」任务一致。
不过，「测试生成」任务涉及的检索操作更多，错误操作的发生率也更高，因此每次运行的平均命令总数为 6.5 条。
在前两个问题中，为解决每个 HumanEval 问题而进行的 AutoDev 对话的平均长度分别为 1656 和 1863 个 token。
这包括用户的目标、来自 AI 智能体的信息和来自评估环境的响应。
相比之下，GPT-4（基线）的零样本在每个任务中平均使用 200 个 token（估计值）生成代码，使用 373 个 token 生成测试。
虽然 AutoDev 使用了更多的 token，但大量 token 用于测试、验证和解释自己生成的代码，超出了基线方法的范围。
最后，AutoDev 会产生与协调人工智能智能体、管理对话以及在 Docker 环境中执行命令相关的执行成本。
接下来，一起看一下 AutoDev 如何执行测试生成任务。
开发者给到任务：设定生成遵循特定格式的 pytest 测试。
AutoDev 智能体启动 write-new 命令，提供测试文件的文件路径和内容。
随后，AutoDev 智能体触发测试操作，AutoDev 在其安全的 Docker 环境中运行测试，并给出测试执行报告 JSON。
然后，AutoDev 开始自主执行：
AutoDev 智能体在 pytest 输出中发现了一个错误，认识到需要进行修复，以使测试与函数的预期行为保持一致。
继续如图 5 所示，AutoDev 智能体发出写入命令，指定文件路径和行号范围 (5-5)，以重写错误的断言语句。
随后，AutoDev 智能体继续执行测试，并测试成功。
从上面例子中看得出，AutoDev 能够自我评估生成的代码，并解决自身输出中的错误。
此外，AutoDev 可以帮助用户深入了解智能体的操作，并允许智能体在任务期间进行交流。
随着 Devin、AutoDev 等 AI 工程师的诞生，程序员们的工作可能会一大部分实现自动化。
参考资料：
-
https://www.reddit.com/r/singularity/comments/1bfolbj/autodev_automated_aidriven_development_microsoft/
本文来自微信公众号：新智元 （ID：AI_era）
