ASP.NET Extensions 项目中的 AI 服务生命周期管理优化

在 ASP.NET Extensions 项目中，开发团队正在讨论如何优化 AI 相关服务的依赖注入生命周期管理。当前实现中，IChatClient 的注册默认使用了 Singleton（单例）生命周期，这在某些特定场景下可能不够灵活。

当前实现的问题

目前，Microsoft.Extensions.AI 包中的服务注册扩展方法强制使用了单例生命周期。这种设计在大多数情况下是合理的，因为它符合 Aspire 框架的约定，并且对于大多数 AI 服务来说，单例模式是最优选择。

然而，在某些特殊场景下，这种硬编码的生命周期限制会带来问题。例如，在 GitHub Copilot 代理的实现中，客户端需要根据每个请求中使用的特定 GitHub 令牌进行范围限定（Scoped）。当前的单例实现无法满足这种需求。

解决方案讨论

开发团队提出了几种可能的改进方案：

1. 多方法方案：按照 .NET 依赖注入的命名惯例，提供不同生命周期版本的注册方法，如 AddSingletonChatClient、AddScopedChatClient 和 AddTransientChatClient。这种方案虽然直观，但会引入 API 破坏性变更。

2. 参数化方案：借鉴 Entity Framework Core 的做法，在现有方法中添加一个可选的 ServiceLifetime 参数。例如：

   services.AddChatClient(configure, lifetime: ServiceLifetime.Scoped);
   

团队更倾向于第二种方案，因为它：

• 保持了 API 的简洁性
• 与现有 .NET 生态系统的设计模式一致
• 提供了更大的灵活性而不破坏现有代码

技术考量

在实现这种改进时，需要考虑几个技术细节：

1. 默认值保持：为了向后兼容，默认生命周期应保持为 Singleton。

2. 性能影响：对于 AI 服务这种可能涉及网络调用的组件，需要仔细评估不同生命周期对性能的影响。

3. 线程安全：如果选择支持非单例生命周期，需要确保客户端实现是线程安全的。

4. 资源管理：特别是对于 Scoped 和 Transient 生命周期，需要妥善处理资源的创建和释放。

最佳实践建议

基于这个讨论，可以总结出一些服务注册的最佳实践：

1. 优先使用单例：对于无状态的、线程安全的服务，单例是最佳选择。

2. 按需灵活：当服务需要请求特定上下文时，应支持更灵活的生命周期。

3. 一致性设计：遵循框架已有的模式（如 EF Core 的参数化生命周期）可以提高 API 的易用性。

4. 明确文档：对于支持多种生命周期的服务，应在文档中明确说明每种情况下的适用场景和注意事项。

这个改进将使 ASP.NET Extensions 项目中的 AI 服务注册更加灵活，同时保持与整个 .NET 生态系统的一致性。