Questions about mediator mode-> Reading Notes Series

In the book <Agile Software Development>, the mediator mode provides an example of the following link:

Use a jlist and a jtextfield to construct an instance of the quickentrymediator class. quickentrymediator registers an anonymous documnetlistener with jtextfield. (I have never systematically studied java. At this point, the syntax is not very clear, but I still know what to do ). when the text changes, the listener calls the textfieldchanged method. next, this method searches for the elements prefixed with this text in jlist and selects it. (In short, after the content of the text box changes, the list box must respond to this change .)
Users of jlist and jtextfield do not know the existence of the Mediator. It waits quietly and applies its policy to those objects without the need to allow or know them.
However, I read the books of gof and other design patterns (mainly <Java and mode>) and found that the structure of the Mediator mode is as follows:

I think the difference between them is quite big. the figure below clearly requires that the colleague object need to know mediator without knowing the other colleagues (and there is an abstract colleague class ). when the status of a colleague object changes, it only needs to notify the mediator object. The mediator object will naturally notify the colleagues who care about this change to make corresponding changes. so for" Users of jlist and jtextfield do not know the existence of the mediator. "How to understand it.
According to the <Java and mode> book, this mode is similar to team management. The group members must communicate with each other through the team lead. Therefore, each group member must know which team lead is, that is, the collection object must have references to the Mediator object.
However, <agile> the implementation of this book is not the case. Communication between the two is implemented through event triggering through mediator management. Is it a simplification of this model by using events?
The intent of the Mediator defined by gof is to encapsulate a series of object interactions with an intermediary object. The intermediary makes the objects do not need to be explicitly referenced to each other, so that the coupling is loose and the interaction between them can be changed independently.
The <agile> example provided by the book is the simplest and very consistent with this intent. mediator is responsible for the interaction between jlist and jtextfield, avoiding direct interaction between the two, thus decoupling them.

So can we think this way: No matter how you implement it, I only need to ensure that the objects do not communicate with each other directly, and when the status of myself (Object A) changes, it can trigger a response to other classes of interest, but object a itself does not know that it has affected others (this ensures that "interaction between them can be changed independently ", I only need to use the quickentrymediator class above to manage the communication. ^_^), then it is the mediator mode. What is the idea of the Mediator implementation in the backend?

It seems like the observer mode. I don't know what the real difference is between them ??, I personally feel that the implementation of the example in <agile> is similar to that in the Observer mode using delegate to simplify the implementation, except that an abstract subject is missing in <agile>, the registration event is registered in quickentrymediator. ideology is close to it.

I am still relatively immature in the design model. Maybe these are all the questions that I have not understood the essence of them and may have caused by wrong understanding. I hope you will be able to give me some advice.
I think it is also a kind of communication that can identify the defects expressed by others. It is also a kind of arrangement for my own thoughts on this aspect to correct others' mistakes. ^_^