驯服工具乱象：生成式人工智能代理和工具注册表

Rifx.Online
Generative AI , Technology , Programming/Scripting
09 Jan, 2025

管理生成式 AI 代理工具的实用指南

概述

生成式AI代理积极与其环境互动以实现目标，严重依赖工具。随着企业的扩展，它们使用的代理往往会积累数十、数百甚至数千种不同类型的工具——数据工具、代码工具、API等——这使得有效管理成为一项重大挑战。本文重点介绍工具注册表，这是管理生成式AI代理所使用工具的关键组成部分。它解释了为什么中央工具目录是必不可少的，以及它如何改善可重用性、安全性和标准化。文章涵盖了代理从工具注册表中选择工具的不同策略，包括使用所有可用工具或较小的精选工具集。还讨论了如何管理在不同云环境中部署的工具，并提出了利用标准化代码库和CI/CD管道自动化工具注册的方法。最后，倡导将所有工具转变为API，以便于管理和集成，为构建有效的生成式AI代理系统提供实用指南，从而将生成式AI和运营（GenAIOps）扩展到代理和运营（AgentOps）。

快速回顾生成式人工智能代理

在上一篇文章中，揭开生成式人工智能代理的神秘面纱，我们深入探讨了生成式人工智能代理的激动人心的世界，以及它们如何改变我们与基础模型的互动。与基础生成式人工智能应用程序被动处理信息不同，代理会主动与其环境进行交互。它们利用工具收集信息、执行操作并实现目标。

一个核心概念是将生成式人工智能代理定义为 “一个提示，指示 一个 基础模型 与 特定工具 进行交互。”

通过建立这一核心结构——一组工具、一个基础模型和一个指令提示——用户可以与代理进行多轮交互，以完成一个或多个任务。代理在整个对话中保持上下文，利用短期记忆能力，并智能地使用可用工具，直到目标实现。而且，由于代理记住过去的交互（长期记忆），它可以反复用于类似或新任务，随着时间的推移变得越来越有帮助。

作为提醒，每个“工具”本质上是功能规范的集合（或者我们称之为“声明”）。这些声明包括：

功能名称： 工具的标识符。
描述： 工具目的的全面解释，解决的问题，以及在何种情况下可以使用它。
参数： 输入参数的列表，包含它们的含义、类型和预期值的描述。
输出（可选）： 预期输出格式和内容的描述。

为了说明这些工具声明是如何形式化的，市场上通常使用基于 JSON 的 OpenAPI 格式。以下是一个使用 OpenAPI 格式在工具列表中检索股票价格的函数声明示例：

{
  "tools": [
    {
      "functionDeclarations": [
        {
          "name": "get_stock_price",
          "description": "Fetch the current stock price of a given company.",
          "parameters": {
            "type": "object",
            "properties": {
              "ticker": {
                "type": "string",
                "description": "Stock ticker symbol (e.g., AAPL, MSFT)."
              }
            },
            "required": ["ticker"]
          },
          "returns": {
              "type": "number",
              "description": "The current stock price."
          }
        }
      ]
    }
  ]
}

最近，出现了一些新的相关协议，例如 Anthropic 的模型上下文协议 (MCP)。MCP 提供了一种标准化的方式，将人工智能模型连接到不同的数据源和工具。本文不专注于特定格式或协议，因为我们的目标是为组织工具提供基础。

通过在指令提示的上下文中提供功能声明作为可用工具，基础模型可以识别最合适的工具及其相应的输入参数，以执行用户请求的特定任务。然后，代理的开发者需要使用该模型的响应并触发特定的代码功能或 API。示例和详细信息可以在揭开生成式人工智能代理的神秘面纱的“什么是代理？”部分找到。

这为工具设定了舞台，但许多问题随之而来：

不同类型的工具有哪些，如何统一它们？
我们如何集中可用工具，以实现可重用性和标准化？
所有这些工具实际上位于云环境的哪里？
我们能否自动化和标准化工具的创建？

在本文中，我们将重点解决这些问题。

工具类型与考虑因素

正如我们所建立的，工具是使生成性AI代理与世界互动并执行复杂任务的关键。但并非所有工具都是平等的。它们在实现、可访问性和能力上各不相同。理解这些差异对于构建有效且强大的代理至关重要。

假设我们在云环境中实现工具，我们可以根据其来源和访问方式对工具进行分类：

代码函数： 这些是在代理的代码库中直接实现的函数，提供对本地资源和逻辑的直接访问。这些可以用各种编程语言实现（例如，Python、Java）。例如，在Google Cloud上，这些函数可以使用Artifact Registry（用于存储代码库）进行管理和存储，并使用Cloud Code（用于仓库管理）进行管理。
本地VPC REST API： 这些是在虚拟私有云（VPC）中托管的API，提供安全和受控的环境以访问内部服务和数据。Google Cloud提供了几种服务来促进这一点，包括Cloud Run用于部署容器化应用程序（包括API），API Gateway用于管理和保护API，以及Apigee API Management用于更高级的API管理功能。
公共REST API： 这些是第三方服务提供的公开可用API，提供广泛的功能，可以通过互联网访问。要从Google Cloud环境内部连接到这些API，可以使用NAT Gateway为VPC内的资源提供安全的出站互联网访问，而无需直接暴露给公共互联网。

重要的是要注意，代码函数和本地VPC REST API都可以用来触发与内部数据库或存储系统、其他内部服务或甚至组织基础设施内的其他代理的安全交互。这为代理访问和操作内部数据和流程提供了强大的机制。

下表总结了每种工具类型的优缺点：

什么是工具注册表，为什么它很重要？

为了有效管理和利用这一多样化的工具生态，我们引入了工具注册表的概念。工具注册表是一个集中式的目录，列出了组织或生态系统内所有可用的工具。它提供了一种标准化的方式来发现、访问和管理工具，从而实现：

可重用性： 工具可以被不同的代理轻松发现和重用，从而减少开发时间和精力。注册表保存了如何触发工具的信息（例如，函数调用、API端点、所需参数）以及在哪里找到它（例如，代码库、API文档），使其能够无缝集成到不同的代理中。
可共享性/可见性： 使工具对所有授权开发人员 readily available，促进协作和知识共享。可以将其视为餐厅菜单：一个中央目录，列出所有可用的菜肴（工具），允许顾客（代理）轻松查看可用内容并选择所需的工具。
安全性/可访问性： 强制访问控制，确保只有授权代理可以使用特定工具。注册表可以存储工具所有者的详细信息以及订阅的消费者（代理或团队），以管理和审计访问。这允许对哪些代理可以使用哪些工具进行细粒度控制。
标准化： 促进工具实施和使用的一致性，提高代码可维护性和代理互操作性。在企业环境中，这充当了一个所有人都需要遵循的合同，以便在注册表中注册工具。该合同定义了工具元数据、输入/输出格式、错误处理、安全考虑和其他相关方面的要求。
稳健性： 集中管理允许更好的监控，通过标准化或特定工具的指标（想象代理作为工具）和测试框架进行更好的评估，以及工具的强大版本控制机制。注册表还可以存储所有版本的工具的血统，使所有者能够跟踪更改，评估性能改进或回归，并在必要时轻松恢复到先前版本。
可审计性： 提供清晰的工具使用记录，便于审计和合规。这包括保留每个工具可以访问的代码工件（例如，库、模块）和数据源（例如，数据库、API）的详细信息，以确保透明度和问责制。

为了简化上述列表，我们可以将工具注册表的关键特性总结如下：

工具元数据： 存储每个工具的基本信息，包括名称、描述、参数和输出格式、评估结果（质量）。
版本控制： 跟踪工具的不同版本，确保与不同代理的兼容性。
搜索和发现： 允许开发人员根据关键字、类别或功能轻松找到工具。
访问控制： 管理权限，确保只有授权代理可以访问特定工具。

对于那些有MLOps经验的ML工程师或数据科学家来说，工具注册表的概念将非常熟悉。工具注册表与MLOps中的模型注册表密切相关。正如模型注册表是管理机器学习模型的集中元数据存储，工具注册表则作为管理生成AI代理使用的工具的集中元数据存储。这一平行关系突显了工具注册表在生成AI代理操作化中的重要性，就像模型注册表对于机器学习模型的操作化至关重要一样。有关操作化AI的深入探讨，您可以参考我之前的文章，GenAIOps: 操作化生成AI — 实用指南。

代理工具选择策略：从通用到专业

工具注册表充当企业内所有可用工具的综合目录。这个目录的规模可以从几个工具到数百甚至数千个工具不等，具体取决于业务的规模和复杂性。虽然注册表提供了一个中央存储库，但理解为基础模型提供对整个工具集的访问可能会导致挑战是至关重要的。

如果呈现给基础模型的是一份过长的工具清单，模型可能会感到不知所措或困惑，尤其是当某些工具具有重叠功能或相似描述时。这可能导致错误的工具选择、性能降低和不可预测的代理行为。想象一下，从一个庞大且杂乱无章的工具箱中选择合适的工具——这变成了一个耗时且容易出错的过程。

为了解决这个问题，我们可以借用微服务架构的类比。在微服务环境中，每个服务旨在执行特定的一组任务，并具有自己明确定义的API。同样，我们可以将生成式AI代理视为微服务。每个代理应仅配备与其特定职责直接相关的工具子集。

通过为代理提供一个专注的“工具列表”（工具注册表的子集），我们可以实现几个好处：

性能提升： 基础模型的搜索空间更小，从而加快和提高工具选择的准确性。
可预测性提高： 限制工具集使得代理的行为更加可预测和易于理解。
简化测试： 当代理的范围有限时，测试和调试显著更容易。
增强安全性： 通过限制代理可以访问的工具，我们可以减少其对敏感数据或系统的潜在影响。

然而，这也存在权衡。为代理提供有限的工具集需要更仔细的设计和协调。这要求清楚理解每个代理的职责以及实现这些职责所需的工具。

企业可以遵循两种一般策略：

完全工具集访问（通用代理）： 为代理提供访问整个工具注册表的权限，并依赖基础模型的推理能力来选择适当的工具。这种方法提供了灵活性，但可能导致前面提到的性能和可预测性问题。
有限工具集（专业代理）： 为每个代理提供一个精心策划的工具列表，仅包含其特定任务所需的工具。这种方法促进了性能、可预测性和安全性，但需要更多的前期设计工作。

最佳策略取决于企业的具体需求和背景。需要考虑的因素包括工具数量、任务复杂性、所需的控制水平以及用于代理设计和维护的可用资源。在未来，我们计划发布基于这两种场景的一些实验结果，并定义明确的定量比较。

分布式工具环境与集中式工具注册表

在前面的部分中，我们根据工具的实现和访问方式（代码函数、本地 VPC REST API 和公共 REST API）对工具进行了分类。同样重要的是考虑这些工具在您的基础设施中所处的位置。在像 Google Cloud 这样的云环境中，工具可以跨多个项目进行部署，每个项目代表一个具有自己资源、安全策略和访问控制的独特环境。具体来说：

数据作为工具： 对数据源（例如数据库和存储系统）的访问通常位于专用的数据环境或数据湖/网格环境中。这种分离确保了数据安全性和治理。
API 和代理作为工具： API 和代理都可以视为提供特定功能的服务。这些服务通常部署在应用环境中，通常由 API 网关（对于 API）或在 GenAI 应用的生产环境中管理和保护（对于其他代理使用的代理）。内部 API 和代理可能位于 VPC 中，并可被同一 VPC 或连接的 VPC 中的其他服务访问。这个统一的类别承认 API 和代理都提供通过网络调用可以访问的服务，即使它们的内部实现可能不同。
代码库作为工具： 存放代码函数和其他代码工件的代码库通常在中央工具/工件环境中进行管理。这个环境可以托管那些未作为服务部署但在执行过程中被其他工具或代理使用的工具。

这种工具部署的分布式特性带来了一个挑战：我们如何在这些不同的环境中维护所有可用工具的一致和统一的视图？

虽然工具可能跨多个 Google Cloud 项目（环境）进行部署，但工具注册表必须是一个中央资源，理想情况下位于中央 AI 治理环境中。这种集中化对于几个原因至关重要：

统一发现： 注册表提供了一个单一的访问点，用于发现所有可用工具，无论它们的位置如何。代理和开发人员可以查询注册表以找到所需的工具，而无需了解其特定的部署环境。
一致的元数据： 注册表确保所有工具都使用一致的格式和元数据进行描述，从而更容易理解其功能和使用。
集中治理： 通过将注册表放置在中央 AI 治理环境中，我们可以实施一致的工具注册、访问控制和审计政策。这确保了合规性并减少了安全漏洞的风险。
增强的可审计性和可观察性： 中央注册表促进了对工具使用、版本控制和访问历史的全面跟踪。这对于审计、调试以及理解生成 AI 应用程序的整体性能和行为至关重要。

这种关注点的分离——集中式工具注册表、分布式工具——是构建可扩展、可管理和安全的生成 AI 系统的关键。

为了说明所讨论的概念，我们扩展了在之前的博客文章“GenAIOps：将生成 AI 落实为操作——实用指南”中提出的架构。该图强调了与工具管理和工具注册表相关的关键新增项和修改。主要架构变更如下：

工具注册表： 最重要的新增项是在 GenAI/工件治理项目中引入工具注册表。作为示例，我们利用工件注册表进行代码和元数据管理，利用 Firestore 进行 API/数据治理及相应的元数据（例如评估指标、测试结果），以及利用 Apigee APIHub 进行工具的目录编制。

工具： 该架构现在明确突出了不同类型工具的位置和管理：

数据作为工具： 这些位于数据湖/网格项目中。
代理和 API 作为工具： 这些位于 GenAI 应用生产项目（以及可能的测试项目）中。
作为工具使用的代码函数和其他代码工件： 这些在 GenAI/工件治理项目中进行管理，具体在工件注册表和代码构建组件中。

这些变化反映了在强大的生成 AI 和运营（GenAIOps）平台中，或在我们将在单独的博客文章中讨论的 AgentOps 平台中，集中工具管理和治理的重要性。通过实施这些变化，企业可以提高其生成 AI 应用程序的性能、安全性和可维护性。

工具注册自动化

为了简化工具注册流程并确保企业内部的一致性，我们提议为代理和工具建立一个标准化的仓库结构，并配合自动化的CI/CD管道。这种方法减少了人工干预，降低了错误率，并促进了最佳实践。

为代理和工具标准化存储库结构

提议的结构将代码组织到逻辑目录中，使其易于理解、维护和自动化。我们关注的关键目录如下：

tools/ 
├── shared_libraries/ 
│   ├── <help_functions1>.py 
│   └── <help_functions2>.py 
├── api_tools/ 
│   └── <api_tool_a> # 例如创建和访问API
│       ├── test/ 
│       │   ├── input/ # （可选） 
│       │   ├── output/ # （可选） 
│       │   └── test.py 
│       ├── api_tool_a.py # API的后端代码
│       ├── requirements.txt # 定义库的要求
│       └── image_configuration.json # 定义docker自定义容器 
├── code_tools/  
│   └── <code_tool_a> # 例如自定义Python脚本
│       ├── test/ 
│       │   ├── input/ # （可选） 
│       │   ├── output/ # （可选） 
│       │   └── test.py 
│       └── code_tool_a.py # API的后端代码
├── data_tools/ # 访问数据的所有工具的定义
│   └── <data_tool_a> # 例如访问数据库a 
│       ├── test/ 
│       │   ├── input/ # （可选） 
│       │   ├── output/ # （可选） 
│       │   └── test.py 
│       └── data_tool_a.py 
...

tools/: 该目录包含代理使用的所有不同类型的自定义工具。这里的关键消息是，每种类型的工具（API工具、代码工具、数据工具等）在tools/中都有其专用的子目录。每个工具需要有一个特定的文件，包含所有函数，并且可以选择性地包含docker文件和要求，以便开发者希望在容器中自动化代码工具的实例化，例如通过使用CloudRun。此外，这些子目录中的每个单独工具必须包含一个test/目录，包含单元测试。这确保所有工具在被注册和被代理使用之前都经过彻底测试（由了解逻辑的创建者进行）。理想情况下，工具开发者可以为测试定义特定的输入和输出。

agents/ 
├── agent_a/ 
│   ├── deployment/ # （可选 - 否则，CICD处理此事）
│   │   └── infrastructure/ ... # TerraForm脚本，例如CloudRun
│   ├── evaluation/
│   │   ├── evaluation.py # 代理性能评估脚本
│   │   └── configuration.json # 评估配置，例如数据/指标
│   ├── monitoring/
│   │   ├── monitoring.py # 实时监控脚本
│   │   └── configuration.json # 监控配置，例如阈值 
│   ├── tests/
│   │   ├── integration/ ... # 所有组件的端到端测试
│   │   ├── stress/ ... # 测试边缘情况
│   │   └── ...
│   ├── agent_a.py # 代理的实现  
│   ├── configuration.json # 包含模型的代理配置
│   └── instruction_prompt.txt # 指令提示
├── agent_b/ ...
...

agents/: 该目录包含单个代理的代码。每个代理都有自己的子目录，必须包括：

deployment/（可选）：（如果未使用，CI/CD处理部署 — 见下一部分）此文件夹包含基础设施即代码（IaC）脚本，通常使用Terraform等工具，将代理基础设施部署到其目标环境。这可以是Cloud Run、Kubernetes或任何其他相关平台。
evaluation/: 此文件夹存放评估代理性能的脚本和配置（我们将在另一篇博客文章中讨论这个主题）。
monitoring/: 此文件夹包含实时监控代理行为的脚本和配置。
tests/: 此文件夹包含各种类型的测试，以确保代理的功能和性能。例如，集成测试执行代理内所有组件的端到端测试，确保它们无缝协作，或对代理进行压力测试，以评估其在高负载下的性能。
agent_a.py： 此核心文件包含代理的核心实现。它定义了协调工具（可能来自tools/目录）、与模型交互以及处理数据的逻辑。
configuration.json： 此文件存储代理的配置详细信息，包括它所使用的模型及其设置。
instruction_prompt.txt： 此文件包含代理使用的指令提示。这些提示可能包括代理在操作过程中所需的特定数据的占位符。

这种结构化的方法确保所有工具都经过测试，并且代理组织良好，促进注册过程的自动化。下一步是讨论CI/CD管道如何利用此结构来自动化注册过程。

自动化工具注册与标准化的 CI/CD 流水线

基于标准化的仓库结构，我们可以实施 CI/CD 流水线来自动化工具注册过程。此自动化确保一致性，减少人工工作量，并使迭代周期更快。以下概述了一个示例标准化 CI/CD 流水线在代理和工具生产化过程中的关键阶段：

验证仓库结构： 流水线首先验证仓库结构是否符合定义的标准（如前一小节所述）。这包括检查所需目录的存在（例如，每个工具目录中的 test/，每个代理目录中的 evaluation/ 和 monitoring/）以及特定文件（例如，agent_a.py、configuration.json）。这确保所有必要的工具注册信息都存在。
代码级测试： 流水线随后运行代码级测试，例如单元测试和静态代码分析，以验证代码的质量和正确性。这对工具尤其重要，确保它们在注册之前按预期功能运行。
构建自定义容器： 如果工具或代理需要作为容器化服务（例如，使用 Docker）进行部署，此阶段构建自定义容器镜像。这确保在不同环境中一致的部署。
部署代理和工具（开发）： 流水线将代理及其相关工具部署到开发环境。这允许进行早期测试和集成。 4a. 仓库定义的基础设施： 如果代理的仓库中存在基础设施即代码（IaC）（例如，在之前描述的 deployment/ 文件夹中），流水线将使用这些 IaC 脚本（例如，Terraform）来配置所需的基础设施组件。这允许对部署环境进行细粒度控制。 4b. 标准化流水线基础设施： 如果仓库中没有 IaC，流水线将使用预定义的标准化基础设施配置。此标准化配置通常由 IT 管理员或平台工程师创建和维护，确保所有代理和工具的一致和安全的部署。这种方法特别有助于强制执行安全最佳实践并防止错误配置。它还可以使快速响应和 AI 工程师专注于创建最佳代理，而不是他们可能没有必要技能或知识的基础设施。此外，工具可以如前所述部署到多个环境（例如，数据、工具和应用程序的单独项目）。如果不使用这种多环境策略，工具将在 GenAI 应用程序的开发环境（稍后提升到暂存和生产）中与代理一起部署。这简化了简单设置的部署过程，但可能不适合所有企业用例。
手动批准门（开发）： 在此阶段引入手动批准门，以允许快速响应和 AI 工程师进行手动测试并验证代理在开发环境中的功能。此步骤在进入进一步阶段之前提供了关键的人为检查。
部署到暂存： 在手动批准后，流水线将代理和工具部署到暂存环境。该环境尽可能接近生产环境，并允许在现实条件下进行更严格的测试。
运行评估和测试（暂存）： 在暂存环境中，执行自动化的大规模评估脚本（来自 evaluation/ 目录）和各种测试（例如，集成、压力测试）。此阶段提供有关代理性能和稳定性的自动反馈。评估和测试结果应集中存储在治理环境中。
手动批准门（暂存）： 在部署到生产之前，存在另一个手动批准门。这允许在经过大规模测试和评估后，最终验证代理在暂存环境中的性能和稳定性。
部署到生产： 一旦代理通过所有测试并获得最终批准，流水线将其部署到生产环境。
（隐式）工具注册： 这是一个关键步骤，隐式地在部署到生产过程中执行（或可能更早，例如开发、暂存，具体取决于实现）。从仓库结构中提取的元数据（例如，工具名称、描述、输入/输出参数、部署服务的位置）会自动注册到工具注册表中。这种自动化消除了手动注册的需要。

在部署到生产后，代理的性能会持续监控，使用来自 monitoring/ 目录的脚本和配置。这确保了持续的稳定性，并允许快速检测和解决任何问题。

通过 CI/CD 流水线自动化工具注册确保了工具注册表的一致性和实时更新。 工具注册表在 CI/CD 过程中自动更新，消除了手动注册的需要。工具注册表的元数据是从标准化的仓库结构中提取的，手动批准门在关键阶段提供了重要的人为监督。这种自动化方法确保工具注册表始终与最新版本的工具和代理保持同步，促进了高效的工具发现和使用。

合并工具与API抽象

在工具注册表中，最大化工具的可重用性和简化管理的关键策略是将所有工具类型“转换”为API工具。这种方法提供了几个优势，包括标准化访问、改善治理和更容易与代理集成。因此，代码工具和数据工具都需要进行如下转变：

代码工具转为API： 代码工具通常以脚本或函数的形式实现，可以通过将其部署为容器化服务来转变为API。在Google Cloud上，可以使用Cloud Run或Cloud Functions等服务轻松实现这一点。为了促进这种转变，工具的代码库必须包含一个Dockerfile（或等效的容器配置），以定义如何构建容器镜像。CI/CD管道随后构建并部署该容器，将工具的功能暴露为API端点。这种方法还受益于容器注册表（如Artifact Registry）提供的版本控制和回滚功能。
数据工具转为API： 将数据工具转变为API需要稍微不同的方法。数据工具通常涉及使用特定客户端库直接访问数据库或数据湖。为了将这些能力暴露为API，我们需要创建一个位于数据源前面的API层。该层处理身份验证、授权和数据访问控制。至关重要的是，这种转变需要将现有的数据治理政策与API身份验证和治理机制统一。这确保了所有工具在安全性和访问控制方面的一致性，无论它们是访问代码、数据还是其他服务。可以使用Apigee API管理或API Gateway等服务来管理和保护这些数据API。

将数据和代码工具转变为API工具的主要好处包括：

标准化访问： API提供了一个标准化的接口，用于访问所有工具，无论其底层实现如何。这简化了代理的集成，并消除了它们理解每个工具实现具体细节的需要。
改善可重用性： 通过将工具暴露为API，它们变得更易于被不同应用中的多个代理发现和重用。
集中治理： API可以通过API网关或管理平台轻松管理和治理，从而实现对身份验证、授权、速率限制和其他政策的集中监控、日志记录和控制。
简化工具注册表： 工具注册表可以专注于管理API元数据（端点、描述、输入/输出参数），而不是处理不同工具实现的复杂性。

通过采用这种API转型策略，企业可以为其生成式AI应用程序创建一个更强大、可扩展和可管理的工具生态系统。

工具注册和组织结构（针对大规模企业）

本节讨论了管理工具及其注册的不同组织模型，特别适用于拥有多个团队和复杂工具生态系统的大规模企业。如果您在较小的组织中工作，或者目前不关心企业级工具治理，您可以选择跳过本节。

工具注册的实施和管理受到企业组织结构的显著影响。不同的结构在灵活性、标准化和中央控制之间提供不同的权衡。我们可以识别出三种主要的工具管理和注册的组织模型：职能型（分散型）、集中型和联合型（混合型）。

1. 职能型（分散型）组织： 在职能型或分散型组织中，每个团队开发和维护自己独立的一套工具。虽然可能存在工具注册，但通常是局限于每个团队或职能，没有中央的监督或团队之间的协调。每个团队负责定义、实施和管理与其特定项目相关的工具。这导致独立的工具开发和管理流程。

优点： 这种方法为各个团队提供了最大的灵活性，使他们能够快速开发和调整工具以满足特定需求。
缺点： 缺乏中央协调导致了孤岛式开发，团队之间工具的可重用性有限，缺乏标准化。这可能导致重复劳动、不一致的工具质量，以及在维护企业范围内可用能力的一致视图方面的困难。

2. 集中型组织： 在集中型组织中，一个专门的中央团队（例如，平台团队或卓越中心，CoE）负责开发、维护和管理工具，以及整个组织的单一全球工具注册。中央团队定义工具开发、注册、元数据和使用的标准。所有团队在利用中央注册的工具时必须遵循这些标准。

优点： 这种方法确保了高度的标准化，促进了工具在组织内部的可重用性，并简化了治理和审计。
缺点： 集中模型可能会造成瓶颈，因为所有工具的开发和注册必须经过中央团队。这可能会降低各个团队的开发速度，并为中央团队带来高额的开销。该模型通常更适合小型到中型企业（SMB），因为团队和工具的数量较少。

3. 联合型（混合型）组织： 联合模型结合了职能型和集中型组织结构的元素。每个团队开发和管理自己的工具，并可能拥有一个本地注册，但在企业层面上会建立共同的标准和指导方针。中央团队（例如，卓越中心或治理团队）审查本地开发工具的质量和适用性，并将高质量、可重用的工具推广到共享的全球工具注册，供整个组织访问。这种混合方法允许团队保持灵活性，同时仍能受益于标准化和可重用性。中央团队充当策展人，确保高质量、可重用的工具在整个企业中可用。

优点： 该模型在灵活性和控制之间取得了平衡，允许团队快速开发工具，同时确保有价值的工具被共享和标准化。与完全集中模型相比，它减少了对中央团队的开销，并促进了最佳实践的更广泛采用。
缺点： 这种方法需要团队与中央治理机构之间的清晰沟通和协作。它还需要一个明确的流程，将本地注册的工具推广到全球注册中。该模型非常适合拥有卓越中心（CoE）和分布式开发团队的大型企业。

但是，您如何选择合适的工具管理模型？工具管理及相关工具注册的最佳模型取决于以下因素：

组织规模和结构： 较大、分布式的组织通常从联合方法中受益。
团队和工具的数量： 较少的团队和工具可能有效地通过集中方法进行管理。
期望的标准化水平： 如果严格的标准化至关重要，则集中或强联合的方法更为可取。
开发速度和团队自主性： 如果优先考虑快速开发和团队自主性，则更职能型或松散联合的方法可能更为合适。

通过仔细考虑这些因素，企业可以选择最适合其需求并最大化其生成性 AI 工具生态系统价值的工具管理组织模型。

结论

本文探讨了工具注册表在管理生成式 AI 代理的多样化工具生态系统中的关键作用。我们强调了集中注册表在可重用性、安全性、标准化和审计方面的好处，并研究了代理工具选择策略。我们还讨论了管理分布式工具部署的问题，并提出了一种使用标准化仓库、CI/CD 管道和 API 转换来自动化工具注册的实用方法。实施这些策略使组织能够构建强大且可扩展的生成式 AI 代理系统。未来的文章将深入探讨 AgentOps，涵盖代理评估、测试以及关键实施角色和操作。