ModelContextProtocol C SDK 中 Scoped 服务注入问题的分析与解决方案

在 ModelContextProtocol 的 C# SDK 开发过程中，开发者可能会遇到一个常见的依赖注入问题：当尝试在工具方法中注入 Scoped 生命周期的服务时，系统会抛出"无法从根提供程序解析 Scoped 服务"的异常。这个问题涉及到 .NET Core 依赖注入系统的核心机制，值得我们深入探讨。

问题本质

问题的根源在于 .NET Core 依赖注入容器对服务生命周期的严格管理。Scoped 服务（如 DbContext）设计为在特定作用域内有效，而工具方法的调用通常发生在根容器级别，没有创建适当的作用域。

技术背景

在 .NET Core 的依赖注入系统中，服务有三种生命周期：

1. Singleton - 整个应用程序生命周期内只有一个实例
2. Scoped - 每个作用域内有一个实例
3. Transient - 每次请求都创建一个新实例

DbContext 通常注册为 Scoped 服务，这是因为它需要与单个工作单元相关联，保持跟踪变更和事务的一致性。

解决方案

临时解决方案

开发者可以采用显式创建作用域的方式来解决这个问题：

Task<string> GetKnowledge(
        IMcpServer thisServer,
        IServiceScopeFactory serviceScopeFactory,
        string question)
{
    await using var scope = serviceScopeFactory.CreateAsyncScope();
    var db = scope.ServiceProvider.GetRequiredService<CoreDbContext>();
    // 使用db进行操作
}

这种方法虽然有效，但增加了代码复杂度，需要在每个工具方法中重复这些操作。

框架层面的改进

开发团队已经认识到这个问题，并计划在框架层面进行改进。可能的改进方向包括：

1. 为每个工具调用自动创建作用域，类似于 HTTP 请求中间件和 SignalR Hub 方法的处理方式
2. 优化状态工具调用的服务作用域管理
3. 提供更清晰的错误提示和文档说明

最佳实践建议

1. 对于工具方法中的数据库访问，推荐使用显式作用域管理
2. 考虑将工具方法设计为无状态的，减少对 Scoped 服务的依赖
3. 对于必须使用 Scoped 服务的场景，确保理解其生命周期管理

总结

ModelContextProtocol C# SDK 中的这个限制反映了 .NET Core 依赖注入系统对服务生命周期的严格管理。开发者需要理解不同生命周期服务的适用场景，并根据实际情况选择合适的解决方案。随着框架的不断完善，这个问题有望得到更优雅的解决。