In cases where Alice and Bob are guaranteed to arrive at the same key, this is impossible: the function that takes Alice and Bob's private info as input, and produces the public transcript as output, must be a one-way function if the scheme is to be secure and if it always negotiates a shared key. If it sometimes fails, then you don't necessarily get a OWF; you get a function which can be turned into a OWF, but it's more complicated. Assuming that either Alice or Bob knows if it succeeded, you can make this construction work.
It should be pretty clear why the nonexistence of OWFs implies that you can, given a transcript, compute a possible set of private info for Alice and for Bob that gives that transcript. In comments, you suggested many inputs giving the same transcript but different keys. This is impossible if, after the protocol, either Alice or Bob knows if they successfully negotiated a key or not (and the other one doesn't think they know but actually have it wrong). In that case, any two inputs that lead to successful key exchange and produce the same transcript must negotiate the same key.
Each party has private information for any particular run; it's just whatever secret they had, plus the result of every single coin flip that happened during that run of the protocol. We can specify this in advance; if you need more coin flips than are in the private information, the algorithm just fails. Then at any step, whatever message is sent is a deterministic function of the transcript so far and the private information the sender has (all randomness got embedded in the private info). Also, include whatever check you're doing to verify key exchange worked in the protocol.
Suppose the set of private info $A_0,B_0$ and the set $A_1,B_1$ produced the same transcript. WLOG, Alice sent the first message each time. Consider what happens with $A_0,B_1$; we want it to be the same transcript as well. Alice sends the first message again; this is based only on $A_0$, so it's the same as the first message there. Now, suppose the first $k$ messages are the same in this new transcript as in $A_0,B_0$. Alice has exactly the same information as after the first $k$ messages in $A_0,B_0$, so she does the same thing (either doesn't send or sends the same message as there). Bob has exactly the same info as after $k$ messages in $A_1,B_1$, so does the same thing he did there. As the transcripts of $A_0,B_0$ and $A_1,B_1$ are the same, Bob did the same thing in the latter as in the former, so after message $k$, Alice and Bob behave the same as they did in $A_0,B_0$. So the first $k+1$ messages are the same if the first $k$ are. So, $A_0,B_1$ produces the same transcript as $A_0,B_0$.
Alice now computes a key from $A_0$ and the transcript. She can't know whether Bob had $B_0$ or $B_1$, so the key is the same. Likewise, Bob can't know if Alice had $A_0$ or $A_1$, so he produces the same key as $A_1,B_1$. If Alice and Bob know whether or not key exchange was successful, and Alice knew $A_0,B_0$ led to successful exchange, then she also knows $A_0,B_1$ did. That means the key from $A_0,B_0$ is that from $A_0,B_1$ is that from $A_1,B_1$. The only other option is that $A_0,B_1$ failed; in that case, Alice did not know it failed, so she doesn't ever know if her key exchange succeeded or failed.
The reason one party has to know if it succeeded or failed in this proof is that that's how we get that $A_0,B_1$ necessarily succeeded. It may be possible to prove that without someone having to know, but even without that, just extend the private info to contain the actual message being sent (e.g. if it's a one-way message, then Alice has it in her private info and the negotiated key is really the message itself). If the proof doesn't work because neither one knows, then that means neither Alice nor Bob knows whether or not Bob got Alice's message correctly, which is a bit of a problem.
