前言

微软在智能体方面的又一重大工作，通过对话式多智能体协作的方式构建智能体系统，以解决各种应用场景下的问题。相对于文章本身，我更希望读者关注其在github上项目的工作，毕竟智能体的工作本质上都是工程化的内容，只有实际参与了项目本身你才能真正理解AutoGen的意义并感受其实用性。

Paper	https://arxiv.org/pdf/2308.08155.pdf
Code	https://github.com/microsoft/autogen
From	ICLR 2024 WorkShop

Abstract

AutoGen是允许开发者通过多智能体的形式构建LLM应用的开原框架，这些智能体通过对话完成任务。AutoGen可定制化、可对话，并且可以在各种LLMs、用户输入和工具组合的模式下运行。使用AutoGen，开发者可以灵活定义智能体交互行为。自然语言和计算机代码都可以用于为不同的应用程序编写灵活的对话形式。AutoGen是构建各种复杂且融合LLM能力的应用程序的通用框架，实验证明该框架在各种领域的有效性。

Motivation

1. 多智能体合作的方式从直觉上可以更好完成复杂的任务。
2. 为什么采取多智能体对话的形式？
   1. LLM本身基于对话，利于通过彼此或人类对话的形式合作。
   2. 多智能体对话可以取长补短。
   3. LLM可以解决被分解为子任务的复杂任务。
3. 如何灵活实现不同应用程序的需求？
   1. 如何设计有能力、可重用、可定制且有效进行多智能体协作的单个智能体？
   2. 如何开发一个简单、统一的界面来适应各种智能体对话模式？

AutoGen通过如下方法的实现解决上面的问题：

1. 定制化和可对话的智能体。
2. 对话式编程。角色特定 + 对话为中心。

Framework

AutoGen的核心原则是使用多智能体对话来简化和整合多智能体工作流程。AutoGen具有两个关键概念：可对话智能体和对话编程。

Conversable Agents

1. 支持常见的智能体组合功能，比如LLMs，人类和工具。
2. 根据特定应用程序的需求，每个智能体可以通过多个组件的混合来展现复杂的行为。AutoGen允许通过重用或者跨站来创建专门的功能或角色的智能体。

虽然可对话智能体是有用的构建块，但是为了智能体在任务上取得有意义的进展，开发人员还需要指定和塑造这些多智能体对话。

Conversation Programming

对话编程可以解决“有意义”的问题。它考虑了两个概念：

1. 计算：智能体在多智能体对话中计算自己响应的动作。
2. 控制流：计算发生的顺序或者条件。在此基础上设计了统一的接口、自动回复、编程和自然语言融合等设计模式。

对话式编程的设计模式允许在编程和自然语言之间进行控制，一方面，可以让智能体通过自然语言来控制对话流程，另一个方面可以用Python代码来终止条件、人类输入和工具执行逻辑，甚至可以调用自动回复函数来控制对话流程。
此外，对话编程可以根据当前上下文同时执行当前对话以及调用其它智能体的对话。总的来说，这种对话式编程，可以让复杂的多智能体对话实现更简单直观。

Application

作者在六个应用上使用AutoGen以展示其在简化高性能多智能体应用程序开发中的潜力。

A1: Math Problem Solving

自动化解决数学问题的系统通过直接复用两个内置的智能体完成，并与LangChain ReAct、原始GPT-4等在MATH数据集上进行评估。研究者随机选取了120个随机的level 5的问题，解决表明AutoGen仅用内置的智能体就有最好的表现。

为了研究人机协同解决问题的有效性，作者在系统中融入了人类反馈，实验证实系统可以借助人类输入来解决那些没有人类介入无法解决的问题。

A2: Retrieval-Augmented Code Generation and Question Answering

RAG已被证明缓解语言模型固有限制的实用方法，本文构建了一种检索增强型对话系统，由检索增强型用户智能体和检索增强型助手智能体组成。作者在两种情况下进行评估：问题回答和代码生成。作者与DPR进行比较，AutoGen会在找不到信息时不终止对话，而是会回应“找不到任何关于xxx的信息，更新上下文”，这将唤起更多检索。结果如下图所示，显示交互检索机制在这过程中确实起到重要的作用。

A3: Decision Making in Text World Environments

略
AutoGen对任意应用场景定制任务特定的多智能体协作系统，从而在各种场景上取得很好的效果。更多的应用这里就不再赘述了，感兴趣的朋友可以阅读原文观看。

Conclusion

AutoGen最大的亮点正如它所宣传的那样：对话式多智能体，智能体通过互相协作以及对话交互，从而在各个应用场景定制多智能体协作系统，取得非常好的效果。通过对文章的阅读，我也有一些想法和疑惑：

1. 智能体工作的文章一定要如此包装吗？在看文章的时候，很多内容读起来还是很吃力的，作者创造了很多概念，比如对话编程，计算响应，给我唬的一愣一愣的，不知其所以然。看完文章，以及相关的应用后，我才恍然大悟，我觉得作者如果能够将重点围绕在对话式多智能体交互上，即通过一个pipeline讲解整个框架，而不是拆分成一个个组件，然后将重点放在实验上（AutoGen应用部分还是很充分的），可能更利于读者的理解，不过这样的包装可能更好中论文吧。毕竟智能体相关的工作太过于工程，发论文吃力不讨好。
2. 不同的应用场景需要定制不同的多智能体协作系统，这显得不够智能，能不能在积累一定不同类型智能体之后，用户仅仅通过任务就能自动组合智能体来协作完成任务，这我认为是值得去做的工作。
3. Framework的图实在是暴殄天物，流程看着很乱，一些函数写在上面不明所以，不利于读者理解。
4. 实验部分限于当时AI assistant的benchmark还没有出来，所以只能以6种应用形式呈现，实际上现在AutoGen已经在GAIA benchmark取得了最好的成绩，确实有力证明了对话式多智能体协作系统的优越性。