对当前特工工具包的独到见解

对当前代理工具包的评估（来源：David Broda 和 Eric Broda）

本文与 Davis Broda 和 Eric Broda 合作。Davis Broda 是一名高级技术架构师、团队负责人和软件工程师，专注于生成式人工智能、自主代理和大规模数据平台。

代理工具包分析

随着新兴代理生态系统的形成，必须越来越多地关注代理如何融入企业应用环境。然而，构建强大且易于使用的代理是相当具有挑战性的。在本文中，我们将介绍当前可用的代理框架，评估它们在多种不同指标上的表现——包括企业级能力——让您决定哪种框架最适合您的用例。

我们使用许多标准来评估当前的代理框架。我们将这些标准分为几个类别。

开发者体验：开发者使用框架开发涉及代理的代理和应用程序的难易程度。

文档：高质量文档的可用性加快了开发速度，并使维护变得更容易。
调试的便利性：易于调试的应用程序在出现故障时更容易修复，加快了迭代开发的速度。
可扩展性：框架修改以包含库本身未包含的新行为的难易程度。
预构建组件：框架默认包含的预构建组件的数量和实用性。
可配置性：用户在无需广泛技术知识的情况下配置框架的能力。

代理能力：由给定框架创建的代理或代理组执行任务的能力，以及它们执行此任务的一致性。

自定义：代理调优以适应您的用例的难易程度。
组件重用：在使用相同框架制作的不同应用程序之间重用应用程序中组件的难易程度。
任务规划：对复杂任务的规划效果，以及该计划的稳健性。
任务执行：代理执行所分配任务的可靠性和能力。
工具使用：代理可以访问的工具的广度，以及开发者添加新工具的便利性。

企业级能力：一组大型企业在使用框架进行生产时所需的能力，以便对框架的安全性和可靠性有足够的信心。

日志记录：有关正在运行的应用程序的信息的可用性，包括其正在做什么，以及顺序。
安全性：框架支持构建安全应用程序的程度。这包括安全连接和访问控制等内容。
可发现性：找到可能对应用程序有用的代理和工具的难易程度，包括其他人开发的工具。
可观察性：用户观察代理和任务状态的难易程度，除了任务结束通知之外。
可操作性：框架在用户环境中运行的设置难易程度。
信任框架：框架用于确定或通知用户哪些代理、工具或任务被认为是可信的机制（如果有的话）。

CrewAI

CrewAI 是一个以机组人员抽象为中心的代理框架，CrewAI 将机组人员定义为“… 一个协作的代理组共同工作以完成一系列任务。”它既可以作为一个开源库，也可以作为 CrewAI 提供的平台使用。

图 1，CrewAI

CrewAI 具有出色的代理能力。机组人员抽象包含大量可重用的功能，例如共享内存、消息共享和自动链接代理。这些可重用的功能易于组合，使得该框架易于上手。它的配置也相对简单，内置了使用配置文件创建和修改系统的方法，使非技术人员能够与框架进行交互。这些功能组合在一起，形成一个能够有效规划、良好利用可用工具并相对可靠地执行任务的框架。

然而，这些好处以开发者体验的一些元素为代价，特别是可扩展性、日志记录和调试的便利性。虽然存在允许创建自定义工具的接口，但在当前版本的框架中，日志记录行为和解析等功能并不容易配置。此外，由于错误发生时日志信息不清晰，以及代码中的行为不明确或反直觉（示例？），使用该接口开发自定义工具变得困难。此外，CrewAI 框架将信息记录到控制台，虽然在控制台上看起来不错，但使用的字符集不容易导出到文件中，导致难以检查或利用生成的日志，除非在框架运行时有人工监视控制台。

CrewAI 的企业级功能因使用开源库还是平台而异。CrewAI 的开源库不提供处理安全性或可观察性的功能，但如果使用他们的企业平台，则在这方面提供了一些功能。虽然新模型的可发现性仅限于平台附带的少数模板，但该平台提供了一些基本的安全功能，允许定义用户和角色，并更改组织中拥有这些角色的人员的权限。唯一的主要缺点是安全性必须在平台本身中定义，无法与现有的身份验证来源进行集成。尽管缺少信任框架，但所有竞争对手也同样缺乏这一框架，因此在这一方面并不比其他框架更糟。

在当前状态下，CrewAI 是一个非常适合用于简单代理应用的框架，因为它设置简单且具有大量预构建的功能。它也适合于更复杂的应用程序，在这些应用程序中，预构建的功能足以实现您的目标，或应用程序必须能够被非技术用户配置。然而，对于需要超出预构建功能的自定义特性的应用程序来说，它并不适合。尽管如此，CrewAI 库目前仅处于 0.80 版本，而不是完整的 1.0 版本，因此很可能会有进一步的改进，使该框架在未来具有很大的潜力。

LangGraph

LangGraph 是更广泛的 LangChain 生态系统的一部分，是一个将代理与工具及其他代理连接的框架。它围绕图形抽象进行组织，包含一系列代表代理和工具的节点，以及决定节点何时被调用的边。这种抽象非常灵活，允许以多种方式进行定制和扩展，并以复杂的方式实现和与工具交互。然而，很明显 LangGraph 并不打算作为一个独立的应用程序，而是作为一个更大系统中的一个组件，依赖于系统的其他部分来实现库本身缺失的几种行为，如安全性、日志记录、可发现性和配置。出于类似原因，大多数企业级功能在这个框架中缺失。

图 2，LangGraph

LangGraph 在其代理能力方面表现出色。LangGraph 高度可定制，主要通过在图中任意重新排序节点的能力实现，使得生成的工具和代理网络可以具有任何所需的结构。此外，它具有非常好的接口，允许在任何所需的点引入自定义行为。这种定制使其能够处理开发者可能需要的几乎所有用例，包括复杂的工具使用和代理层次结构。LangGraph 的可扩展性目标已经实现，很难看到 LangGraph 如何在当前状态下有意义地改善其可扩展性。此外，如果构建了合适的图，规划和执行能力证明非常可靠。

然而，这种灵活性以开发者体验为代价。几乎没有为您预构建的图的设置，导致陡峭的学习曲线。尽管文档相当不错，但仍需要开发者付出相当大的努力才能理解库，才能实现一个可工作的应用程序。此外，这种灵活性使得几个功能模块——日志记录、配置、安全性等——成为开发者的责任，缺乏预构建的组件。虽然这些功能的实现并不困难，但确实增加了产品的学习曲线。然而，库的可定制性允许大量的扩展性，提供了当前市场上最好的定制接口。

总之，LangGraph 的高学习曲线使其成为您第一个代理开发框架的一个具有挑战性的选择，因为与其他可用选项相比，入门会更加困难。然而，如果您已经熟悉代理开发，或者您需要 LangGraph 提供的更高程度的可定制性，它可能非常适合您的任务，只要您准备好将企业级功能交由应用程序的其他部分处理。

OpenAI Swarm

OpenAI Swarm 是一个将代理连接成网络的框架，围绕着表示松散耦合和去中心化代理组的 Swarm 抽象进行组织。这个抽象对代理如何互动的假设很少，从而允许相当程度的灵活性。然而，这个框架仍在不断完善中，被标记为实验性，使用时其不完整的特性显而易见，缺乏可扩展性、预构建组件和文档。此外，还缺乏任何支持企业级系统的特性，如可观察性、可发现性和安全性。

图 3，OpenAI Swarm

在开发者体验方面，OpenAI 追求灵活性，但这种灵活性的实现使得使用该库变得困难。代理和工具之间的依赖链使得初始化和组装一个 swarm 变得困难，导致代码笨拙且令人困惑。此外，提供的接口的低级特性意味着用户必须付出大量努力来组装一个 swarm，从而增加了开发难度。不幸的是，这段代码的复杂性也提供了许多难以诊断的问题出现的机会，这些问题非常难以调试。由于库中缺乏日志记录，当发生故障时几乎没有提供关于发生了什么的信息，这并没有帮助。

可用于 OpenAI swarm 的文档非常有限，仅提供了一些核心类的非常基本的概述，其他部分没有文档可用。现有的文档也不是最新的，包括至少一个实例，其中文档被写入以包含尚未开发的功能的使用，导致了大量的困惑，并进一步增加了开发的困难。

在代理能力方面，OpenAI Swarm 的表现不佳。即使开发难度被解决，相同 swarm 实例的不同运行结果也不一致。这种不一致的任务执行和规划使得在实践中使用该框架变得非常困难。

虽然 OpenAI swarm 毫无疑问有优秀的头脑在背后，并且在未来可能具有潜力，但在目前的状态下，其能力低于标准，不推荐使用。由于开发的困难和一致性问题，构建代理可能是一种具有挑战性的体验。

Magentic-One

Magentic-One 是由微软研究院创建的一个代理框架，基于他们的 Autogen 工具包构建。它旨在构建能够完成复杂任务的多代理应用程序。通过将一组相关代理连接在一起，每个代理在系统中都有特定的角色——文件浏览器、编码器、执行器、多模态浏览器、用户代理和协调者——以完成代理的任务。该系统的结构允许这些代理具有很大的灵活性，特别是通过多模态网络浏览器的组合——使代理能够访问互联网——和编码器——生成并运行可执行代码。能够从互联网收集新信息并编写任意代码以应对意外问题，使得可以完成非常广泛的任务。

图 4，Magentic-One

Magentic-One 强调代理能力的特定方面，同时在其他领域有所欠缺；Magentic-One 在处理任务类型方面非常灵活，但架构相对僵化。代理被设计为以特定方式连接在一起，并且只能使用随 Magentic-One 预打包的工具。虽然原则上存在可以进一步扩展的接口，但没有关于如何使用这些接口的文档，并且它们的设计使得在实践中非常难以使用。同样，将新的代理或代理类型添加到系统中也是非常困难的。然而，它自带的代理和工具在处理任务方面具有极大的灵活性，并且会自动重复用于每个任务。虽然任务的灵活性使其具有广泛的开箱即用功能，但如果需要更多功能，扩展框架将非常困难。

Magentic-One 的显著企业级能力包括全面的日志记录和可观察性套件，提供了对框架工作情况的洞察，包括开发视角和用户视角，其中显示了当前任务状态的信息。然而，框架中没有包含安全性或可发现性功能。

关于开发者体验，文档的全面性不如预期，但包含了基本信息和足够的示例，使开发者能够在其预期范围内合理地使用该应用程序。关于组件重用，预构建组件旨在用于所有代理，这在重用评分上得分很高。然而，由于接口的设计不适合扩展，加上缺乏调试信息来解决扩展过程中遇到的问题，使得框架在这些限制之外的扩展非常困难。

总体而言，Magentic-One 是一个能够开箱即用地处理多种任务的框架，但在超出其当前处理能力的情况下扩展能力有限。不幸的是，这种扩展能力依赖于生成和执行任意代码的能力，这带来了必须仔细评估的安全风险。然而，如果安全风险可接受，并且任务在模型的当前能力范围内，那么它并不是一个坏选择。

PydanticAI

PydanticAI 是一个相对较新的框架，用于创建利用生成性 AI 代理的应用程序。它提供了一个抽象层和易于使用的组件，使生成性代理的使用更简单、更一致，并允许为代理构建和提供工具。由与广泛使用的 Pydantic 库相同的团队开发，这并未使其在竞争中获得实质性优势。虽然该库允许构建相互通信的节点网络，但它主要面向单代理用例，以及每个代理独立工作而不直接与其他代理互动的用例。

图 5，PydanticAI

使用该库创建多个相互作用的代理是困难的。尝试这样做通常会导致不直观的行为，并且需要开发者自己管理大部分交互细节，几乎没有库的帮助。这大大增加了开发多代理应用程序的开发者工作量，并使其可靠性降低。库中缺乏日志和调试信息也没有改善这一点，提供的信息对于运行时的情况非常有限。

虽然对于单代理应用可能有用，但 PydanticAI 对于任何需要多个代理的应用程序都带来了挑战，因为库的开发工作量和不可靠性将阻碍使用它进行开发的尝试。

结论

有多种代理框架服务于不同的细分市场，但有两个明显的领先者从中脱颖而出。如果您希望以最小的开发工作量使用代理，或者作为您首次接触代理工作的尝试，那么 CrewAI 是领先者，因其易用性和易于配置的特点。而如果您需要比 CrewAI 提供的更高的灵活性或可定制性，LangChain 是首选，它提供了一个强大的库，足够灵活以满足更广泛的用例。

每个工具包都有其优势，所有工具都应因其在快速发展的领域中的创新而受到赞扬，但其他工具包——Magentic-One、PydanticAI 和 OpenAI Swarm，因其早期发展阶段可能带来的挑战，使得构建稳健的代理变得困难。