论文阅读 AutoDev: Automated AI-Driven Development

为什么要读这篇论文？
学习一个coding agent的技术架构，建立对coding agent架构的基本认知。在此基础上再进一步探究MetaGPT、LDB、AgentCoder等业界SOTA coding agent的技术架构。

1. 背景

论文发表时间： 2024/05/13

原文下载地址： https://arxiv.org/abs/2403.08299

当前AI编程解决方案（例如GitHub Copilot）的局限性：

• 并未利用IDE中提供的所有潜在功能，例如building，testing，executing code，git operations，linter等
• 缺乏上下文感知

2. AutoDev模块介绍

2.1 Rules, Actions, and Objective Configuration

• 使用yaml文件配置rules和actions以进行process的初始化
• 文件中定义agent的数量和行为（角色，例如developer or reviewer）

2.2 Conversation Manager

职责：

• 初始化历史对话
• 管理正在进行的对话
• 决定合适中断正在进行中的process
• 确保用户、AI agents、系统之间的无缝对话
• 维护一个对话的object，里面包括：来自AI agents的信息、Evaluation Environment中action的结果

子模块：

• Parser：
  • 用于解析agents生成的响应结果，以预定义的格式提取命令和参数
  • 确保指令的格式正确，验证指令参数的数量和正确性
  • 确保指令符合用户的权限
  • 如果指令通过校验，Conversation Manager将调用工具库中对应的action
• Output Organizer：
  • 处理的Evaluation Environment输出，提取出其中的关键信息、选择性地总结相关内容，再对其进行结构化、格式化后存储到对话历史记录中
  • 这确保每个用户的历史对话记录是清晰和有条理的
• Conversation Conclusion：
  • 决定何时结束对话
  • 结束对话的原因：Agent发出任务完成信号（停止命令），对话达到用户定义的最大迭代/令牌数，在process或Evaluation Environment中检测到了问题

2.3 Agent Scheduler

职责：

• 编排AI agents以达到用户定义的目标
• 配置了特定角色和可用命令集的agent可以协同工作以执行各种任务
• 采用各种协作算法去决定agent参与对话的顺序和方式：Round Robin, Token-Based, or Priority-Based
• Agents：
  • Large Language Models (LLMs) ，例如OpenAI GPT-4
  • 针对代码生成优化过的Small Language Models(SLMs)
  • 不同的agent之间通过自然语言进行通信
  • 从Agent Scheduler接受目标以及对话历史

2.4 Tools Library

职责：

• 存储了各种指令，是的agent能够对repository执行多种操作

• 这些指令旨在将复杂的操作、工具和实用程序封装在一个简单直观的命令结构后面

  • File Editing：此类别包含用于编辑代码、配码和文档等文件的命令
  • Retrieval：包括使用基础CLI命令（grep, find）的检索和基于向量的检索，去查找与对话内容类似的代码片段
  • Build & Execution：编译、构建和执行代码库
  • Testing & Validation：使得agent能够通过执行单个测试用例、特定测试文件或整个测试套件，进行代码库的测试
  • Git：用户可以配置git操作的（精细权限）Fine-grained permissions
  • Communication：代理可以调用一组命令，旨在促进与其他代理和 / 或用户的通信

2.5 Evaluation Environment

职责：

• 底层是一个docker容器，Tools Library中的各种工具均在这个docker容器中运行
• 提供了一个简单的交互界面
• Evaluation Environment抽取出标准输出/错误到Output Organizer模块

2.6 Putting Everything Together

1. 用户通过指定目标和关联的设置来初始化对话
2. Conversation Manager初始化对话对象，整合来自AI agent和Evaluation Environment的消息
3. Conversation Manager将对话分派给Agent Scheduler，Agent Scheduler负责协调AI agent之间的action
4. AI agent（LLM或者SLM）通过文本交互给出指令建议
5. Commands Interface包含了多种指令，File Editing, Retrieval, Build and Execution, Testing, and Git operations
6. Conversation Manager会解析这些建议的指令，然后将对应指令传输到Evaluation Environment中进行执行
7. 所有的指令在Evaluation Environment的docker容器中执行。执行后，action结果会无缝集成到对话历史中，作为上下午信息参与到后续的对话迭代中
8. 当Agent发出任务完成信号（停止命令），对话达到用户定义的最大迭代/令牌数，在process或Evaluation Environment中检测到了问题等条件满足时，对话结束

3. AutoDev的评估

从以下三个维度对AutoDev进行评估：

1. AutoDev在代码生成任务中的效果如何？
2. AutoDev在测试生成任务中的效果如何？
3. AutoDev完成任务的效率如何？

3.1 代码生成评估

评估数据集： HumanEval数据集，包含了针对Python语言的164个编程问题，每个问题都包含a function signature（函数签名）, docstring（注释）, body（函数主体）, and an average of 7.7 unit tests（平均7.7个单元测试用例）。
单元测试用例

评估指标： Pass@k指标，其中k表示尝试次数。一次成功的问题解决定义为AutoDev 生成了函数体代码，且满足了所有的单元测试用例。评估时k=1，即仅考虑第一次尝试取得成功的情况。

评估结果：

3.2 测试生成评估

评估数据集： 修改了HumanEval数据集，保留了数据集中人工编写的问题解决代码，丢弃了其中人工编写的unit tests（单元测试用例）。要求AutoDev为代码中的focal method（核心函数）编写测试用例，并从测试是否成功、focal method的调用、测试用例覆盖度三个维度进行评估。

评估指标： Pass@1指标，成功测试通过并成功调用了focal method，则视为一次成功。将AutoDev生成测试的覆盖率和人工编写的测试样例进行了对比。

评估结果：

3.3 完成任务的效率

评估结果：

• 对于代码生成，AutoDev 平均执行了 5.5 个命令，包括 1.8 个写入操作、1.7 个测试操作、0.92 个停止操作（表示任务完成）、0.25 个错误命令，以及最少的检索（grep、find、cat）、语法检查操作和通话通信命令
• 对于测试生成，命令的平均数量与代码生成任务基本一致。但是，测试生成涉及更多的检索操作和更多错误操作的发生率，导致每次运行平均总共有 6.5 个命令。
  

如果命令引用不可用的指令或者指令解析失败（例如，格式或参数计数不正确），我们会将命令归类为错误。最普遍的错误命令涉及 AI 代理将自然语言与代码或指令混合。这些问题可能通过更灵活的解析或改进的提示来解决。
AutoDev解决每个HumanEval中代码生成问题和测试生成问题的对话平均长度分别为1656和1863 个token。与之对比，零样本GPT-4（Baseline）平均使用200个token（估计）用于代码生成，每个任务使用373个令牌用于测试生成。

4. 更多的讨论

文中有两个观点值得进一步探索：

1. Multi-Agent Collaboration： 多个agent之间相互协作，例如developer agent和reviewer agent的相互协作
2. Human in the Loop： AutoDev允许agent分别使用talk和ask命令来传达任务进度或请求人工反馈。可以进一步探索更好地把人类集成到整个流程中，或者说更好的agent与人的协作方式