Brief survey on Multi-Agents System(MAS)

（持续更新中…)

目前两个主流的多智能体开发框架，其中langgraph是langchain的原生团队扩展开发而来，基础版本诞生于2024年6月，在7月进行的暑假实训，我们使用还未发布正式文档的langgraph开发了一个面向软件开发场景的多智能体应用，主要功能为引导用户描述需求并使用多个智能体：项目经理、技术架构师、多个工程师协同给出一个初步的完善开发文档。项目仓库：LangGraph-MAS4SE

在开发过程一个比较细节的难点：langgraph以图的方式构建多智能体的关联，使用router路由函数选择下一步跳转，当时只有OpenAI提供了完善的tool_call工具调用的函数接口，这导致我们想使用开源模型Zhipu/Qwen等的想法无法实现，最终我强行使用output_parser做格式化输出的限制实现了router的跳转选择。

项目结束后，正处于llama3.1横空出世，项目的经验让我更关注模型 tool_call / function_call 的支持。时至今日，绝大多数模型都明确自己支持 tool_call，function_call 似乎提到的不多。后续让我关注更多的是两个点：

1. tool call 工具调用。开发Claude的Antrophic公司提出 MCP (Model Context Protocol) 模型上下文协议，希望以这样一个标准统一工具调用。我的理解，这个协议直观的想法是把将面向LLM和面向Tool的接口明确划分开来，面向LLM的开发者专心开发MCP Client，面向Tool的开发者专心开发MCP Server。
   1. 此外，claude3.5开始支持直接对屏幕进行操作、一时爆火的Manus以及开源的工具 brower-use，这样的尝试无疑是将大模型从单纯的文本生成到实际辅助开发更近一步的尝试。
2. 格式化输出。格式化输出的问题在很多场景都给我造成不小的困扰，不仅是初期langgraph的router路由跳转，还是批量处理模型输出文本时的格式规范，我使用的方式就是尽量添加 output_parser 将输出按照 JSON 格式进行规范，但这样的输出对应用到下游不是很好适用。
   1. 后续让我重新关注格式化的输出，是一些AI应用结合应用工具，比如生产内容后直接生成PPT，这样的应用对格式输出的限制无疑是十分严格的。

新项目的契机，我们还是想做一个多智能体的开发，重新阅读langgraph的指导手册，发现比较新的两点更符合实际需求的设计：

1. human in the loop，支持人工在中途向模型生成加入新的输入。在老项目的开发我们也有这样的需求，但因为模型的生成是一个异步async的过程，导致很难将输入操作这一同步的过程加入代码，当时的实现是制造一个空循环的等待，开一个短暂的窗口留给用户进行输入。当然这是不合理的设计。
2. checkpoint，把输出流程经过每一个结点的state保存下来，和深度学习的模型训练一样，这样可以使得在一个workflow中可以回到某一个state进行branch off尝试不同的生成路径。

但是，langgraph选择从图结点的方式进行多智能体的构建，对于功能的设计需要非常细粒度，开发的难度和学习成本是比较高的。在这时，我接触到了另一个多智能体开发框架 CrewAI，单从 Github 的 star 数来看，CrewAI 有2w多的收藏，接近langgraph的2倍。

CrewAI 的项目搭建更有”框架“的感觉，而且整体的设计更粗粒度一些，更多的注意力可以放在Agent的角色描述与设计上。CrewAI 也有 Flow 模块，实现与 LangGraph 思路较为一致的对生产流程较细粒度的把控。

Conditional Path