I have a Macro-A that runs at a fixed point every day.
This Macro-A has a lot of found image related functions, and the whole Macro-A running time needs to last about 90 minutes, so when the Macro-A is running (this Macro-A only needs to use three apps during the period).
If another app accidentally jumps out and goes to the top of the window during this period Macro-A will stop, because it cannot recognize the set image and it stops running.
I wonder if I can set a macro-B to run asynchronously and hide the window when there is other app at the top of the window.
Wherever macroA performs a found image action make sure the correct app window is at the front by inserting an Activate application action just before the found image activity. That way, the correct app window will always be available to macroA. You don’t really need a second macro to “police” your windows for you.
The problem with your idea is that Macro B has to somehow know which of the 3 apps need to be in front while Macro A is working; in other words Macro B has to track the progress of Macro A somehow and I can’t see an obvious way of achieving that.
Does macro B need to run when macro A is running? How is macro B triggered? Those tie into @peternlewis's suggestion -- you could disable B at the start of A and re-enable it at the end, or start B with "If A is running then Cancel this Macro", if B doesn't use the same apps as A you could put it in a Group that isn't enabled when A's apps are frontmost, etc.
Does B need access to the UI or can you get round that somehow? That'll depend on what the macro does -- you could manipulate text files directly rather than via an app, move files by action/script rather than in the Finder, and similar.
Or can you change A to be less image dependent? Such long-running, UI-reliant, macros are inherently fragile (as you've found) and perhaps a change in process -- even a change of apps to ones that are more directly scriptable -- is worth considering.