You should not use this in any production system, period. You're trying to design cryptographic primitives, which is something which is extremely easy to get horribly wrong. If you aren't yourself a cryptographer, don't try to design cryptographic algorithms - perfectly good ones already exist. (In general, you should use well-tested systems wherever you can in security - never roll your own primitive, avoid rolling your own protocol wherever you possibly can, avoid rolling your own implementation when practical).
In fact, this scheme is highly vulnerable to MitM attacks. A MitM is not someone who's listening in on traffic; they're active attackers, and can modify any communication going between the two parties. In this case, the MitM intercepts Alice's first message and encrypts it with their key; when Alice removes her encryption, the attacker now has it encrypted with their own key and nothing else. You have to somehow verify that it's Bob's key that was added in step 2, not an attacker's; your scheme doesn't even try to solve this.
A far, far better way to do this is public-key encryption. Alice and Bob give each other their public keys through some out-of-band communication, or a trusted third party verifies their public keys. Alice encrypts her message with Bob's public key, and Bob then decrypts it. You need to share public keys, but that's a plus: in your scheme (where you don't know the key Bob should use nor whether the message was in fact re-encrypted with it), you're extremely vulnerable to a MitM attack.
So use proper public-key encryption in a properly tested protocol, if possible in properly tested library code (note "tested" means "tested for security, which only trained experts can really do).
