新智元报道
编写：桃子 润
【新智元导读】全球首个 AI 程序员 Devin 诞生之后，让码农纷纷恐慌。没想到，微软同时也整出了一个 AI 程序员 ——AutoDev，能够自主生成、履行代码等工作。网友惊呼，AI 编码发展太快了。
全球首个 AI 程序员 Devin 的横空出世，可能成为软件和 AI 发展史上一个重要的节点。它掌握了全栈的技能，不仅可以写代码 debug，训模型，还可以去美国最大求职网站 Upwork 上抢单。
一时间，网友们惊呼，「程序员不存在了」？甚至连刚开始攻读计算机学位的人也恐慌，「10 倍 AI 工程师」对未来的工作影响。
除了 Cognition AI 这种明星初创公司，美国的各个大厂也早就在想办法用 AI 智能体降本增效了。就在 3 月 14 日同一天，微软团队也发布了一个「微软 AI 程序员」——AutoDev。
论文地址：https://arxiv.org/ pdf / 2403.08299.pdf
与 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 工程师的诞生，程序员们的工作可能会一大部分实现自动化。
参考资料：
AutoDev: Automated AI-Driven Development – Microsoft 2024
byu/Singularian2501 insingularity
本文来自微信公众号：新智元 （ID：AI_era）