构建智能代理：5种工具注册策略提升agentic Ai应用效率

介绍

我们都知道，生成性人工智能在人工智能世界中占据了主导地位，并在转变为代理人工智能时开始成熟，其中生成性人工智能大语言模型被用作人工人类的“大脑”。

让我用通俗的语言向您解释这些代理是什么。它们是自动化人类，执行提供的任务，但它们以智能的方式执行这些任务，使用大语言模型作为“大脑”，就像人类用大脑聪明地完成任务一样。

现在，这些代理知道如何执行特定的任务，但它们并不知道如何解决提供给它们的任何任务。因为它们在专业任务上有边界，只能访问某些工具。例如，正在时尚行业工作的代理可以向特定客户发送邮件，提供个性化的服装推荐，因为它们可以访问特定工具以获取客户购买历史、进行数据分析、识别相似服装并通过邮件推荐它们。相同的代理不会执行其他任务，因为它们没有特定工具的访问权限来执行这些任务。可以将这些工具视为代理的技能，就像人类操作一样。

现在，我们理解了代理与工具的工作原理。但是，如何构建代理和工具，以及生产级系统的最佳策略是什么？让我们来看看。

1. 与代理结合的工具

此策略非常基础，工具将在代理应用环境中开发、构建和部署。

当您正在构建小型到中型代理应用或为特定领域和用例开发应用时，此策略效果良好。

让我们看看当工具在代理应用中时，应用程序可能是什么样子的。考虑代理应用具有3个层次，其中工具部署在工具执行层内，如下图所示（工具在工具执行层内以粉红色突出显示）。

工具与应用中的工具执行相结合。

策略考虑

这是一个简单的策略过程，您可以在代理应用的源代码中开发工具，并与代理打包在一起，随时部署到需要的地方。但正如我所说，这一策略仅在以下两种场景中非常有效：

1. 应用程序应该轻量、易于部署和管理。
2. 应用程序是为单一用例开发的，其中工具可重用性并不重要。

然而，如果用例增长到拥有多个代理和工具，这一策略很快就会成为瓶颈。

2. 工具作为功能

如果您想构建和扩展更大的代理应用，这一策略非常有效，工具将在专用服务器上运行。

与第一种策略（与代理结合的工具）相比，这有助于您以更少的工具执行开发来扩展和管理应用程序。您只需专注于将各种工具作为业务功能启用，并在不重建和重新部署整个代理应用的情况下进行部署。

让我们看看当工具作为功能运行并与代理应用连接时，应用程序可能是什么样子。考虑代理应用有3个层次，工具在工具执行层中连接和集成，如下图所示（工具以粉色突出显示，位于工具执行层之外）。

工具作为功能进行部署，并连接到代理应用中。

策略考虑

当您想要考虑您的代理应用需要与工具一起扩展时，这种方法是有效的。您可以考虑工具的开发可以单独进行，而无需修改代理的代码。只有这些代理具有适当的工具调用器和动态工具标识符配置，以识别给定用例所需执行的正确工具。

您可以将这些工具开发并部署到您选择的云中的云函数（Azure functions、Google cloud functions、AWS Lambda 和其他云平台特定函数服务）。

该策略非常适合以下场景：

1. 代理解决方案的规模可以根据任何用例要求进行调整。
2. 可以单独部署尽可能多的工具，并与代理应用注册，而无需重新部署。
3. 工具版本控制和维护非常重要。

3. 工具作为服务

这个策略与第二个策略（工具作为功能）相似，但唯一的区别是工具组将作为微服务部署，并通过REST或MQ层进行调用。

考虑您已经将后端应用程序作为微服务运行，但您可能不需要在代理应用中重新开发相同的业务功能，而是希望重用这些服务，那么这个策略更为合适。

让我们看看当工具在服务中运行并与代理应用连接时，应用程序可能是什么样子。考虑代理应用具有3个层次，其中工具连接并集成在工具执行层中，如下图所示（工具以粉红色突出显示，位于工具执行层之外）。

工具作为微服务部署，并连接在代理应用中。

战略考虑

此战略使您能够将工具以传统微服务的方式部署，并通过 REST 和 MQ 将服务连接到代理。此战略可能看起来并不像上图所示的那么简单，您可能需要考虑开发标准的 REST 和 MQ 集成，其中 REST 允许您以同步和异步的方式进行通信，而 MQ 允许您以异步方式进行通信，并且您需要在工具执行后处理消费消息事件。

此战略非常适合以下场景

1. 工具更多的是业务事务服务，如 CRUD 操作，并且它们被构建为微服务。
2. 如果解决方案必须采用领域驱动的解决方案，则考虑使用此战略。

4. 工具作为连接器

这个策略与上述策略不同，并且可以与上述任何策略结合使用。这使您能够构建工具的语料库，作为与外部集成的连接器，如数据库连接器、MQ 连接器、存储连接器、REST API 连接器等。

让我们看看当工具在代理应用中运行时，应用程序可能是什么样子。考虑代理应用有 3 层，其中工具在工具执行层内连接和集成，如下图所示（工具在工具执行层内以粉色突出显示）。

工具被开发为连接器

战略考虑

当您想要构建代理应用时，您可能希望与数据库服务、存储服务、传输服务等进行集成，这种策略最适合于您可以将工具开发为连接器，并查询、发送、保存数据。如我所述，您可以考虑使用上述三种策略中的任何一种来开发工具。

这种策略非常适合以下场景：

1. 如果您的需求更多的是连接多个数据库、存储服务和与多个外部服务的集成，那么您可以将这种策略应用于工具开发和代理集成。

5. 第三方工具

有时您不想仅仅开发功能，因为这些功能可以从第三方开源库中轻松获取，例如 LangChain、CrewAI、Microsoft 代理人工智能工具和其他流行库。

您可以在应用程序中安装工具库，并在开发过程中导入这些工具。

让我们看看当工具被安装、导入并在代理应用中运行时，应用程序可能是什么样子。考虑代理应用有 3 层，其中工具在工具执行层中被导入和执行，如下图所示（工具在工具执行层内以粉红色突出显示）。

第三方工具已在应用程序中安装并导入。

战略考虑

此策略非常适合以下场景：

1. 当开发时间较短时，我们尝试重用现成的工具来解决问题。
2. 当维护这些工具成为一个难题，因为这些工具被认为是长期使用的。

6. 动态工具

这个策略非常有趣，它是软件行业的未来。如果我们考虑朝这个策略发展，那么未来就会被采纳。

一些流行的代理框架，如微软的 autogen，通过将工具作为代码编写并能够执行它们来提供支持。因此，这更像是使用代理来构建满足需求的技能。

让我们看看当工具在代理应用中创建和执行时，应用程序可能是什么样子。考虑代理应用有 3 层，其中工具在工具执行层内创建和执行，如下图所示（工具在工具执行层内以粉色突出显示）。

工具在运行时使用代理创建和执行。

策略考虑

考虑一下，您正在构建未来可持续的代理应用，在这种情况下，您不想开发和维护工具，而是希望将这一技能赋予代理，以便他们可以为您完成这项工作。

该策略适用于以下用例：

1. 应用需要根据用例和需求动态执行技能和功能。
2. 工具开发和维护难度大。

就这些！！我将继续撰写关于代理应用的策略、集成和标准实践，因为这将是技术的未来。