何时使用 API 插件
使用 API 插件，可以允许声明性代理与 API 通信以读取和修改外部数据。 了解如何决定何时使用 API 插件来扩展声明性代理。
决策条件
API 插件为声明性代理提供强大的集成功能。 以下条件可帮助你确定 API 插件是否适合你的方案。
基础模型之外的数据
需要了解的第一件事是代理是否可以仅使用其基础模型中的信息来满足你的要求。 如果需要访问其他信息（例如内部数据库），则需要使用 API 插件等对其进行扩展。
数据形状
接下来需要了解的是代理需要访问的数据的形状。 数据是结构化的（如客户记录或订单），还是像文档或报表一样是非结构化的？ 如果数据是结构化的，则非常适合用于 API 插件。 如果是非结构化的，是否有搜索索引和代理可以使用的 API？ 否则，可以考虑使用 Copilot 连接器将数据引入到 Microsoft 365 并受益于其搜索功能。
数据访问
决定使用 API 插件的决定和所涉及的工作量的最后一件事是插件访问数据的能力。 是否有代理可以连接到的 API？ 是否有描述 API 的 OpenAPI 规范？ API 是否使用代理可以处理的身份验证机制？ API 是否易于理解或使用，还是使用语言模型无法进行的复杂查询？
应用条件
当需要将声明性代理连接到其基础模型之外的结构化且经常更改的数据时，API 插件效果最佳。 由于此决定存在细微差别，因此让我们考虑如何将这些条件应用于示例方案。
- 代理是否需要访问基础模型以外的数据？ 是。 有关修复的信息不是代理基础模型的一部分。 相反，信息存储在数据库中并通过 API 公开，这就是为什么使用 API 插件是授予代理访问此信息的好方法的原因。
- 信息是否结构化？ 是。 修复信息是通过 API 公开的结构化数据。 由于不需要更多处理，因此适合由 API 插件使用。
- 信息是否可通过 Internet 通过 API 公开？ 是。 修复信息通过 API 公开。 该 API 可通过 Internet 访问，并使用 API 密钥进行保护，这意味着代理可以安全地与其交互。
具有 API 插件的声明性代理似乎非常适合我们的方案。 它满足我们所有的要求，甚至使我们能够在未来扩展助手，以允许用户修改有关维修的信息。
指导摘要
以程图总结了考虑使用 API 插件扩展声明性代理时要问的关键问题。
