autogen crewai multi-agent agentops llm ai-agents

AutoGen与CrewAI对比：构建智能体团队及计算其成本。

构建智能体团队时AutoGen与CrewAI的对比：代理循环、针对任务与团队的批评与群聊功能，以及AgentOps用于查看每次运行实际产生的成本。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 15 分钟3499 词

来源: Multi-Agent Systems in Action: A Deep Dive into AutoGen and CrewAI

在很长一段时间里，应用大型语言模型时的交互模式都是一种简单的循环：有人输入提示词，模型给出回答，然后对话继续。这种模式在解答问题时效果不错。但一旦需要完成实际任务，比如编写和调试程序、规划研究报告，或是运行涉及多种工具和数据源的多步骤工作流程，这种模式就会出现问题。

多智能体系统正是为填补这一空白而存在的。它不会让一个庞大的提示语承担所有任务，而是将工作拆分为不同的角色：工程师、评审员、研究员、写作者。每个角色都成为一个智能体，即一个带有自身人格、记忆和职责的LLM封装体。这些智能体之间会相互交流，传递部分结果，互相评审，并不断迭代直至任务完成。这种体验更像是管理一支小型且高效的团队，而非咨询神谕。

目前该领域主要有两个框架，此处对其进行了比较：由微软研究院开源的AutoGen，以及专为企业工作流程设计的较新平台CrewAI。还有第三种工具AgentOps，它增加了可观测性功能，能够让人了解智能体正在执行什么任务以及相关成本。

角色分工而非单一庞大提示语

概念上的转变先于任何工具的出现。在单智能体架构中，一个系统提示同时承担两项任务：定义角色定位以及预判模型可能被问及的问题。多智能体框架则能分散工作负荷。每个智能体都有更为明确的职责描述，包括角色定位、目标，有时还包括影响其工作方式的背景故事。

这模仿了人类团队的工作方式。资深工程师不会同时兼任质量审核员、项目经理和技术文档撰写人。将这些职能分配给不同的智能体能带来三重实际好处：

专业化提升质量。专门负责检查代码安全问题的智能体，其检查的一致性会高于同时处理多项任务的通用型智能体。
反馈循环变得明确。将某个智能体的输出转发给专门负责对其进行评价的另一个智能体，从而形成有意识的审查流程，而非依赖同一模型自行发现错误。
并行工作成为可能。在更复杂的系统中，智能体可以同时处理更大目标的不同部分，例如由研究智能体和写作智能体分别承担不同的子任务。

每个框架都以各自的方式解决通信这一难题。智能体如何交换信息？它们是共享同一对话，还是进行彼此独立的交流且仅偶尔交汇？AutoGen与CrewAI在这一点上存在差异，而这种差异又影响了其他所有方面。

AutoGen：一切都是对话

Microsoft的AutoGen将每次智能体交互视为一场对话。其设计理念是让智能体以自然语言相互交流，就像人们在聊天窗口中对话一样。这样一来非常直观：任何看过同事在Slack频道中反复讨论完善某个想法的人，都能立刻理解AutoGen中可对话智能体背后的运作逻辑。

在AutoGen Studio中体验

在编写任何Python代码之前，AutoGen Studio就提供了图形化实验方式。它可通过pip安装，从环境变量中读取API密钥，仅需一次命令行调用即可启动。随后会打开一个浏览器界面，在其中输入任务，用户代理智能体就会与一个或多个辅助智能体协同工作直至任务完成。

这种出现模式值得学习，因为它随处可见。假设需求是绘制某个搜索词的热度随时间变化的趋势图。辅助代理会开始为各个子任务生成代码片段，然后用户代理会在沙箱环境中运行这些代码片段，并判断结果是否正确。如果代码出错或输出有误，代理会反馈回来，辅助代理再对其进行修改，如此循环往复地进行编码、执行、评估和修改，直到代理满意为止。

那个循环自动完成了代码审查中需要人工操作的部分。在常规流程中，开发人员会编写代码、运行它，观察它出错后亲自修复漏洞。而在这里，代理程序负责执行运行与检测的步骤，这样人们就可以离开，由两个智能体来解决问题。虽然这种方法并非完美无缺，因为某些被修改的库或已废弃的功能有时会让智能体犯错，但对于范围明确的问题而言，它的效果极为显著。图像生成、数据可视化以及小型应用程序通常只需几次迭代就能完成。

有一个建议被反复提及：每当生成的代码可能接触到底层操作系统时，都应在 Docker 中运行 AutoGen 和 AutoGen Studio。由于这些智能体被设计为能够编写和执行任意代码，因此容器可以保护主机免受意外影响。随着智能体被赋予更多自主权，这一建议的重要性愈发凸显。

技能作为额外能力

Studio 自带的功能工具寥寥几项，比如获取网页内容或生成图片。它的真正优势在于自定义技能。所谓技能，其实就是具有明确名称且文档说明完善的普通 Python 函数，框架会通过读取这些文档说明来决定何时以及如何调用该函数。

一个示例代码演示了describe_image技能的实现，该技能可将图像发送给具备视觉功能的模型，并获取对应的描述。将其注册到主助手后，就可以提出非常具体的请求：为指定书名创建封面，然后使用图像描述技能来检查书名文字的拼写是否正确。众所周知，图像生成工具在生成清晰可读的文字方面表现较差，因此这种设计形成了一个自然的验证循环——助手先生成图像，视觉技能再检查文字，如果出错则助手会重新尝试。通过构建小型且文档完善的工具，能够实现出人意料地稳定的功能表现。

其背后有一套设计理念。与其指望智能体为每个需求都编写全新的代码，不如将经过测试的固定技能库交给它们。大语言模型即时生成的代码可能在库更新或依赖关系变化时出错，而经过审核并封装好的技能则表现更为稳定可预测。智能体是应动态编写代码还是调用预构建工具，这一问题将在后续关于规划与执行的讨论中探讨，这也是设计智能体系统时较为重要的决策之一。

使用 pyautogen 编写原始代码

在完成 Studio 的开发后，下一步就是利用 pyautogen 包编写 Python 代码。其中有两个关键组件：

ConversableAgent 是一种通用型智能体，可直接与大语言模型交互。
UserProxyAgent 负责代表人类用户，在工作目录中执行代码。

通过简单的设置即可将两者连接起来并开始对话，例如要求给出一行版的FizzBuzz解决方案。程序运行时，助手提出方案后会询问反馈；若直接按回车键而不给出反馈，则表示让助手直接运行代码。如果缺少如Pygame这样的必要软件包，代理会先将其安装后再执行程序。这种自我配置能力虽看似微小，却体现了这些系统可能拥有的自由度，当然这也存在相应的优缺点。

用于测试模型的实用编程挑战包括判断一个数是否为质数、制作贪吃蛇游戏，以及用Pygame开发小行星游戏。这些挑战都是独立的、可测试的，且难度各异，足以揭示不同模型或配置之间的差异。

通过嵌套聊天添加评估者

助手加上代理固然有用，但多智能体系统靠的是专门的角色定位来发挥作用。第二个助手可以担任代码审查员，系统会发送相应消息，要求其全面审查、严格遵循标准，并重点关注安全与质量问题。

AutoGen并未将审查者直接纳入主对话中，而是提供了嵌套聊天功能。用户代理会注册一个嵌套聊天窗口，每当工程师智能体生成新内容时就会触发该窗口。代码会自动进入一个独立的子对话发送给审查者，审查者给出审查意见后，这些意见又会反馈到主对话中。这样既加入了审查步骤，又不会让审查者干扰每一轮对话，只有有新内容需要检查时它才会发言。

在用 Pygame 编写蛇形游戏这样的任务中，与普通工程师加上代理运行的方式相比，差异十分明显。代码执行完毕后，评审工具会给出一系列改进建议，这实际上重现了人工团队每天进行的拉取请求审查流程。

通过缓存控制成本

多智能体对话很快就会产生高昂成本。每次交流都会消耗令牌，而复杂的任务可能需要数十轮对话。AutoGen 内置了缓存系统：默认情况下，对话状态会保存到磁盘上的 .cache 文件夹中，这样即使任务时间较长或被中断，也可以继续执行而无需再次支付相同的令牌费用。

可以通过将聊天调用封装在提供 cache_seed 的上下文管理器中来明确设置该行为。这一点的重要性往往容易被低估。在智能体开发中，为了调试或向相关方展示智能体是如何得出特定结果的，人们通常希望重新播放或审查之前的运行过程，而非重新生成它。

群组聊天与“传话游戏”问题

嵌套式聊天存在类似儿童游戏“传话游戏”的结构缺陷。信息以链式方式从一个智能体传递到另一个智能体，而在每一轮传递中，细节都可能丢失、失真或被重新解读。如果评估者从未看到完整的原始任务，仅看到工程师决定传递的内容，其反馈就很可能偏离重点。

AutoGen的解决方案是群组聊天。群组聊天对象会维护一个共享的智能体与消息池，类似于团队频道，从而取代一系列点对点的传输方式。群组聊天管理器负责协调发言顺序，避免所有智能体同时回复。其核心优势在于每位成员都能查看完整的对话历史，而不仅仅是直接传递给自己的内容。

使用群组聊天重新构建工程师与评论者的示例，能够实现更连贯的协作。评论者所依据的背景信息与工程师完全一致，工程师也可以直接针对具体评论作出回应，而无需基于转述内容处理。不出所料，这样的方式带来的代价是文本冗长。群组对话会消耗更多令牌，因为每个智能体实际上都会监听所有的交流内容，这在按令牌数量计费的情况下尤为重要。

早期示例带来的启示

综合来看，这些工作室会议与原始代码实验得出了几条适用于任何智能体项目的原则。任务规模应足够小，以便能够及时判断是否成功，因为只有当有机制能判定输出是否正确时，代理循环才能发挥作用。执行过程应当被隔离，因为正是那种让循环具备实用价值的自主性，也会使其能够安装软件包并运行任意程序。一旦明确了各角色的职责，添加评审机制的成本其实很低，因此几乎总是值得尝试引入评审环节。此外，成本问题应从一开始就纳入设计考量：缓存、回放功能以及对任务所需步骤数的评估，都是系统构建的一部分，而非事后才考虑的因素。

还有一个关于该将精力投入何处的教训：为批评者撰写出色的系统消息，或为某个技能编写清晰的文档字符串，其改变行为的效果远胜于增加更多智能体。这两种框架都鼓励对每个智能体的功能进行精确、具体的描述。

CrewAI：结构化而非即兴发挥

AutoGen侧重于开放式对话，而CrewAI则更具结构性和明确性，显然是为商业及生产环境设计的。它不采用自由流动的对话方式，而是要求明确三个要素：具有角色、目标及背景故事的智能体；分配给它们的任务；以及在既定处理策略下将它们整合在一起的团队。

智能体的构成

CrewAI智能体是通过少量参数来配置的：

role：代理功能的简短标签，例如“高级笑话研究员”。
goal：用自然语言描述代理试图实现的目标，通常采用模板形式以便配合不同输入重复使用。
backstory：用于构建角色的叙述内容，为角色提供背景设定与性格特征，类似系统提示中的角色设定。
memory与verbose：用于控制代理是否在多次交互间保留上下文，以及是否将推理过程输出到控制台。
allow_delegation：代理是否可以将任务分配给团队中的其他成员。

任务是单独定义的。每个任务都包含工作描述、用于说明对智能体及读者而言成功标准的结果输出字段、负责处理该任务的智能体信息，以及诸如异步执行或将结果写入文件之类的选项。

Crew对象最终会将智能体与任务以及协作方式的相关设置整合在一起，这些设置决定了协作是按顺序进行还是分层进行，同时还包括内存共享、缓存功能，以及为控制API使用频率而设定的每分钟请求上限。

一个有趣的示例：搞笑团队

为使这一流程具体化，便组建了一个由两名成员构成的笑话创作团队。一名资深笑话研究员负责分析什么能让某个主题变得有趣，并记录相关的社会趋势，而另一名笑话撰写员则将这些分析成果转化为实际的笑话。研究员可以授权他人完成任务，但撰写员则不能。这样的分工很合理，因为撰写员应是整个流程的最后一步，而非负责再将任务分派出去的枢纽。

以“人工智能工程师笑话”这样的主题为例，该团队通过“先研究再撰写”的流程来产出真正有趣的笑话，而非仅依靠一个统一的提示词。尽管这听起来有些荒谬，但它说明了为何将领域理解与创意成果的生成分开处理，才能得到更周全的成果。研究员所做的前期工作为撰写员提供了基础背景，相当于在工作流程中内置了一个小型检索步骤。

AgentOps：追踪资金流向

智能体开发者们始终面临着一个核心问题：运行这些智能体会产生多少成本，时间又都用在了哪里？如果不对多智能体系统进行监控，其产生的费用可能会高得惊人，因为每一次智能体间的交互、任务委托以及工具调用都会累积成本。AgentOps是一个专为大型语言模型智能体行为设计的可观测性平台，不同于那些并非为自主对话型智能体而设计的传统MLOps工具。

将其集成到CrewAI项目中非常简单：只需安装相应包，获取API密钥，将该密钥放入环境配置中，然后在脚本开头初始化该库即可。之后每次任务运行都会被记录在仪表板上，显示以下信息：

运行总时长及所使用的环境，
每次大型语言模型调用对应的提示词和响应token数量，
每次单独调用的耗时，
整个运行过程的预估费用。

最后一个例子初次看到时会让人大为震惊。对人类而言看似微不足道的简单笑话生成任务，一旦计入所有中间推理、任务分配以及工具调用成本，其花费竟也是一小笔不小的美元。对于那些怀有商业抱负、正在构建智能体系统的人来说，这是一个现实的警示：虽然智能体编排功能强大，但并非免费；而可观测性则能将抽象的成本转化为可预算、可优化的具体数值。

游戏开发团队

为了与AutoGen的编程示例进行直接对比，这里使用CrewAI组建了一个由三个智能体构成的小型游戏开发团队：

一名高级软件工程师负责根据需求编写相应的Python实现代码。
一名软件质量控制工程师会检查代码中的缺陷，从缺失的导入语句和不平衡的括号，到安全漏洞和逻辑错误。
一名首席质量保证工程师可以分配任务，并最终负责确认成品代码符合最初的需求。

这些任务遵循相同的结构：第一人负责初始实现，第二人检查其中的缺陷，第三人则将两者合并为最终修正版本。这种“编写、评审、定稿”的三阶段审查流程，实际上是AutoGen中“工程师与评审员”模式的进一步细化，通过CrewAI中任务与智能体的明确分工来体现。

当以交互方式运行时，脚本会询问用户希望什么样的游戏以及游戏应如何运作，这样的代码通常会比由单一无人监督的编程智能体生成的代码更加完善。部分原因在于首席质量保证工程师的监督能够发现那些否则可能被忽略的问题。

顺序处理与分层处理

CrewAI提供了两种组织团队处理任务的方式，选择正确的处理方式非常重要。

顺序处理是默认且最简单的方式。任务按照既定顺序依次执行，每个智能体在完成当前任务后才会移交给下一个。这种方式适用于那些步骤确实需要按固定顺序相互依赖的流程：先研究再写作，或先实现再审查最后定稿。

分层处理模式下，会设置一个管理器来统领所有组件，通常使用该系统自身的大语言模型连接仅用于协调工作，该管理器负责监督各个智能体及任务，而非让它们完全同步行动。切换此模式十分简单：只需将Process.sequential改为Process.hierarchical，并指定一个manager_llm，一般为温度值为零的ChatOpenAI实例，以便做出更为稳定的决策。

从理论上讲，层级模式应该更胜一筹，因为管理者角色反映了大型人类组织的运作方式。但实验结果却并非如此。根据AgentOps的测试，在层级管理者模式下执行相同的游戏任务所需成本是其他模式的两倍多，而且代码性能也并未有显著提升。这一数据令人警醒：增加协调机制、监督环节以及更多智能体并不会自动提升效率，若无人密切监控，多智能体系统同样容易陷入成本高昂且效率低下的循环之中。

控制失控的智能体

这一发现与一种潜在的故障模式有关：重复性思维模式。那些对自己输出结果缺乏信心的智能体会不断重复同一思路的不同变体，而非果断采取行动并继续前进，从而导致资源浪费却毫无实际进展。

AgentOps 提供了“重复思维”可视化功能，专门用于展示在任务执行过程中，智能体的推理过程会多次回到相似内容的频率。过度重复表明存在需要调整的结构性问题——可能是任务描述过于模糊，或是针对该问题的复杂性而言参与的智能体数量过多，又或者处理模式本身需要重新审视。这样的诊断工具能够将随意的实验与规范、符合生产标准的工作区分开来。及时发现问题总比等到账单金额异常偏高时才采取行动要好。

并列的沟通风格

开头提出的关于智能体如何传递信息的问题，现在有了具体的答案。AutoGen提供了两种模型。嵌套聊天通过侧边对话传递信息，这样能保持主对话的整洁，但每传递一次就有可能丢失细节。群聊则能让所有人看到完整的历史记录，从而提升连贯性，但代价是消耗更多算力。CrewAI则通过明确指定信息传递方式来避免这种选择：每个任务都会指定执行该任务的智能体及其预期输出，而流程设置则决定结果是直接传递给下一环节还是通过管理者传递。一种方式侧重于自发的协作，另一种则侧重于可预先了解的流程。

这两种方式都无法避免需要监控费用的问题。它们产生的模型调用次数都比单个提示词更多，而且都可能出现循环。正因如此，可观测性工具与框架选择同样重要。

两者之间的选择

这两种框架都没有绝对的优势。它们分别体现了对于多智能体系统应具备多少辅助结构的不同看法。AutoGen允许结构从对话本身中自然形成，而CrewAI则要求构建者在事先明确规划。

适合使用AutoGen的情况：

需要最大的灵活性，智能体可通过开放式对话即兴调整策略；
任务受益于探索性的来回交流，比如头脑风暴或迭代调试，这类场景中正确的操作顺序无法提前确定；
在投入编码之前，需要像AutoGen Studio这样易于使用的可视化工具来进行非技术层面的实验。

适合使用CrewAI的情况：

需要可预测、可审计的流程，且角色与职责明确，例如那些更注重一致性而非即兴发挥的企业工作流程。

与自行实现的版本相比，内置内存、缓存机制及速率限制功能更为可取；

鉴于AgentOps集成几乎毫无障碍，一流的可观测性至关重要。

在实际应用中，许多真实项目会同时借鉴这两种方案：利用CrewAI在流程中已明确的部分所提供的声明式清晰度，以及AutoGen在处理较为复杂、需要探索性的部分时所具备的对话式灵活性。