This is most likely an accidental effect of the graph being modified. Pathfinding on navmesh/recast graphs can sometimes lead to suboptimal paths (see the note at the bottom of this page: Using navmeshes - A* Pathfinding Project), and I think that’s what you are seeing here. The RichAI will try to simplify the path even more while it moves, which is why it can take the faster route anyway.
Good news, though: the pathfinding is much more optimal in the latest beta version. So if you can, I would suggest you try that out
just for my understand it, the “Bug” is beacuse the NavMeshCut gen some small triangle. so it make it different for seeker search path and RichAI seach. (beacuse RichAI will optimize the path as it’s moving)
so for anyone is concern. i may have a walk around solution (not test it yet.)
use a very fast ghost unit to travel the start pos to end pos . and record the path . use that data to generate the line.