随着大型语言模型智能体及其相关工具的发展，管理变更成为它们长期可用性的重要部分。正如软件应用需要更新和版本控制一样，您的智能体所依赖的工具也需要一套系统化的演进方法。如果缺乏周全的管理，更新可能会无意中破坏智能体功能，导致不可预测的行为，或让大型语言模型对工具的能力感到困惑。本节将介绍工具的版本控制和更新实施策略，以确保您的大型语言模型智能体的稳定性和清晰度。

为何大型语言模型工具需要版本控制

想象一个智能体，它已经学会使用您的image_analyzer工具，该工具目前接受一个URL并返回描述。如果您在没有任何警告或版本变更的情况下，突然将工具更改为要求图片字节而不是URL，那么该智能体将开始失效。版本控制带来以下多项好处：

可预测性： 大型语言模型及其运行的智能体框架可以依赖于特定版本的工具，使其行为保持一致。这对于可靠的智能体性能来说是根本。
可控的演进： 它允许您在工具中引入新功能或修复缺陷，而不干扰依赖旧版本的现有智能体工作流程。
回滚能力： 如果工具更新引入了问题，版本控制系统可以更容易地回滚到之前稳定版本，最大限度地减少停机时间或错误的智能体行为。
大型语言模型的清晰度： 当工具描述包含版本信息时，大型语言模型可以更好地理解它们正在与哪个版本交互，特别是在存在多个版本或需要请求特定版本时。
调试： 当出现问题时，了解使用了哪个版本的工具可以显著简化调试过程。

选择有效的版本控制方案

虽然您可以发明任何版本控制系统，但采用广泛认可的标准通常更好。对于包括大型语言模型工具在内的软件，最常用和推荐的方法是语义化版本控制（SemVer）。

语义化版本控制规定了MAJOR.MINOR.PATCH的版本号格式：

MAJOR（例如，1.0.0 -> 2.0.0）： 当您进行不兼容的API变更时增加。这意味着工具的输入、输出或基本行为发生了变化，这会破坏现有集成。对于大型语言模型而言，这可能是必需参数的变化、输出结构的显著改变或功能的移除。
MINOR（例如，1.0.0 -> 1.1.0）： 当您以向后兼容的方式添加功能时增加。例如，向工具添加新的可选参数，或在保持旧结构不变的情况下扩展输出，加入新信息。使用旧契约的智能体应仍能正常运行。
PATCH（例如，1.1.0 -> 1.1.1）： 当您进行向后兼容的缺陷修复时增加。这解决不正确的行为，而不改变工具接口或添加新功能。

例如，考虑一个名为stock_price_fetcher的工具：

stock_price_fetcher_v1.0.0：初始版本，接受股票代码，返回当前价格。
stock_price_fetcher_v1.0.1：修复了特定交易所价格不正确的缺陷。（PATCH）
stock_price_fetcher_v1.1.0：添加可选的currency参数，以指定货币返回价格；如果未提供，则默认为美元。（MINOR）
stock_price_fetcher_v2.0.0：将输出从单一价格更改为包含price、high、low和volume的JSON对象。这是一个破坏性变更。（MAJOR）

使用语义化版本控制可以向开发者以及大型语言模型（如果经过训练或提示以理解它）提供关于工具变更性质的明确信号。

工具更新的实施方法

更新工具需要仔细考虑其对大型语言模型智能体的影响。

优先考虑向后兼容性

尽可能争取使更新向后兼容（导致次要版本或补丁版本变更）。这意味着：

添加新的可选参数： 不带新参数的现有调用仍应正常工作。
扩展输出结构： 向JSON输出添加新字段，而不是更改或移除现有字段。
维护现有端点/函数签名： 除非绝对必要，否则避免重命名函数或更改必需参数名称。

如果一个大型语言模型成功使用get_weather(location="Paris")，一个向后兼容的变更可能允许get_weather(location="Paris", units="celsius")，但get_weather(location="Paris")仍应像以前一样运行，可能默认使用华氏度。

处理破坏性变更（主版本更新）

当破坏性变更不可避免时，您可以采用以下几种策略：

引入具有独特名称的新工具版本： 这通常是大型语言模型最清晰的方法。您不是以破坏性的方式修改my_tool，而是引入my_tool_v2。
- 例如：search_web_v1和search_web_v2。
- 大型语言模型的工具选择过程，在更新的描述引导下，可以选择合适的版本。
- 旧版本（my_tool_v1）可以维护一段时间，以允许平稳过渡。
在工具规范内进行版本控制（如果支持）： 一些智能体框架可能允许您在通用名称下注册同一工具的多个版本，由大型语言模型或框架根据标准或明确请求选择版本。这对于直接的大型语言模型工具使用来说不太常见，并增加了复杂性。
仔细更新工具描述： 无论采用何种方法，提供给大型语言模型的工具描述必须更新以反映新版本中的变更。这个描述是大型语言模型“理解”如何使用该工具的方式。请清晰说明：
- 新的版本号。
- 哪些内容发生了变化（参数、输出、行为）。
- 如果它与之前的版本相比是破坏性变更。

旧工具的弃用生命周期

当您引入一个取代旧版本的新版本时（特别是在主版本更新后），您需要一个淘汰旧版本的计划：

宣布弃用： 更新旧工具版本的描述，指明它已被弃用，提及新版本，并提供一个“终止”日期，此日期之后它将被移除。示例：“此工具calculate_shipping_v1已弃用，将于2024年12月31日之后移除。请使用calculate_shipping_v2，它提供更准确的费率。”
监控使用情况： 记录弃用工具的调用。这有助于查明您的智能体系统（或哪些用户）的哪些部分仍依赖它。
提供迁移支持： 如果变更重大，提供指导，甚至自动化协助，以迁移智能体提示或配置来使用新工具版本。
移除工具： 在终止日期之后，并确保影响最小的情况下，移除旧工具版本。

以下图表说明了一个典型的版本控制路径：

典型的工具版本控制演进过程，突出显示了补丁、次要和主版本更新，并引向旧版本的弃用。

确保大型语言模型了解工具版本

大型语言模型了解工具版本和变更的主要机制是通过您提供的工具描述。

在描述中包含版本： 将版本号作为工具名称或描述的突出部分（例如，“weather_reporter_v1.1.0：获取当前天气。可选地接受‘单位’（摄氏度/华氏度）。”）。
突出变更： 当工具更新时，其描述应清晰阐明新增了什么、改变了什么或修复了什么。如果添加了参数或更改了输出格式，则必须指定。
智能体框架支持： 一些先进的智能体框架可能允许智能体查询可用工具版本或明确请求特定版本的工具（例如，use_tool("calculator", version="2.1.0")）。如果您的框架支持此功能，请确保您的版本控制策略与其功能保持一致。

如果一个大型语言模型经过微调，并且它所依赖的工具发生重大（破坏性）变更，您可能需要考虑更新您的微调数据集，并可能重新微调模型，以保持与新工具版本的最佳性能。

规划回滚

即使经过仔细测试，更新后的工具仍可能引入意想不到的问题。您的更新策略的一个重要部分是能够回滚到工具的先前稳定版本。

基础设施： 您的部署系统应支持轻松重新部署旧工具版本。这可能涉及容器注册表、带版本的无服务器功能或类似机制。
配置管理： 记录哪些工具版本被认为是稳定的，哪些是活跃的。
监控： 正如前面章节所讨论的，更新后监控工具性能和错误率是必不可少的。如果检测到异常，快速回滚可以防止大规模问题。

通过实施周全的版本控制和更新策略，您可以确保大型语言模型智能体能够继续有效地依赖其工具，即使这些工具随着时间的推移而演进和改进。这为您的智能体系统整体稳定性和可维护性做出了重大贡献。

这部分内容有帮助吗？