If you have a 384-bit shared secret and you only need a 256-bit key, then the first 256-bit of shared secret can serve as a session key. This applies only if the shared secret is indistinguishable from a pseudorandom number or has enough entropy to resist brute force attack.
Hashing the shared secret
SHA256(SharedSecret-384) should work because that's basically what X9.63 does. X9.63 appends a counter and a sharedInfo with the sharedSecret to generate a key that is bigger than the hash length. The X9.63 version would be
SHA256(SharedSecret||Counter||SharedInfo) where Counter = 1.
HKDF of sharedSecret is close to SP 800-108r1. Like x9.63, SP 800-108r1 appends counter and context data to the sharedSecret to generate the derived key. The SP 800-108r1 version would be
NIST SP 800-56A has a detailed recommendation for generating session keys out of a shared secret.
More detail on X9.63 and SP 800-108r1
But, if you need more than a 384-bit key, then a KDF must be run to expand the 384 shared secret. There are multiple standards or recommendations around it. NIST has SP 800-108r1 Recommendation for Key Derivation Using Pseudorandom Functions (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1.pdf). The payment industry uses ANSI-X9.63-KDF (https://www.secg.org/sec1-v1.99.dif.pdf Section 3.6.1). X9.63 originally used SHA-1 which is deprecated. SHA-1 should be replaced by SHA256 or 384 if you want to use X9.63.
Both the standards append a counter value and context information with the shared secret and feed that into a hash function (X9.63) or a pseudorandom function (NIST SP 800-108r1).
For i in 1 to (desiredKeyLenBits/hashLenBits)
Ki = F(SharedSecret||Counter||SharedInfo or Context)
Here, F is SHA256 or SHA384 for X9.63 and HMAC or CMAC or KMAC for SP 800-108r1. The naming of the variables is from x9.63. SP 800-108r1 uses the Key derivation key for SharedSecret, (Label||0x00||Context||OutputLenBits) for SharedInfo.