Key exchange and man in the middle issue. Secure solution I am trying to design MiTM protected key exchange algorithm.
For instance I am using RSA asymmetric keys.

Alice and Bob respectively have each their own pair of keys. And they should be able to exchange public keys. In real life implementation there would be a relay 3rd party which should only allow Alice and Bob exchange messages in case if there is no way for direct connection. However this relay party can be compromised by Eve where she would have her own pair of keys, accept Alices And Bobs public keys during the exchange and send out hers instead. Therefore all encrypted messages will be decrypted, read, encrypted again and sent further by Eve compromising the whole key exchange process.

Apparently there can be Trent that could sign the key before it is sent to the recipient and later after it has been received could verify the signature. However I feel that this schema also has a flaw as Eve could somehow obtain public key signed by Trent.

Is there a way to make sure that if Trent is not compromised (means that it is not someone disguised as Trent) we can make sure that keys are exchanged securely?

What comes to mind is that any party can have information about Trent (certificate, public key or something similar) using which they can make sure they communicate with Trent, whereas Trent would confirm to each party from whom they received the key. Does this schema has a flaw or any issues that I haven't noticed?
You are right that the session public keys can be replaced if they are not signed by long term private key known to all parties.

What you want to do is not have Trent do anything but be a relay, then you need a standard key exchange process between the two parties using new random key pairs. Then once all parties have both public keys, they can generate an authentication hash of the key pairs as well as the prime/exponent and any other common data. After the key exchange completes and the session key is generated, you would need some way to compare them, even if it is an insecure channel, as long as that comparison cannot be modified.

Several programs use this method or one like it. I use one over IRC, with the IRC server taking the place of Trent. The obvious alternative is known long term keys that are only used for signing the session public keys.