刚读完arXiv上这篇FlowAgent，核心思路是把工具链从离散的逐步调用变成语义空间的连续轨迹生成，这个视角挺有意思。传统ReAct或Plan-and-Solve那种逐步范式，在长程任务里确实容易出“一步错步步错”的问题，而且对新工具的泛化往往依赖prompt工程硬撑。FlowAgent把工具调用当成连续流来建模，本质上是在尝试让模型在更高维的语义空间里规划工具使用的“路径”，而不是机械地决定下一步调哪个API。这让我想到之前做Agentic RAG时，多跳检索经常在第三跳就偏了，回溯成本极高。如果真能通过连续轨迹生成减少这种累积偏差，那对复杂工作流自动化会是质变。不过我的疑问是：连续轨迹生成的计算开销怎么控制？论文里提到动态真实环境评估，但没细说推理时延和token消耗。另外，当工具集规模大到几百个时，语义空间里的轨迹规划会不会反而引入新的歧义？从行业看，这种思路要是落地，可能比单纯堆agent数量更优雅，尤其适合需要长期记忆和动态工具编排的场景，比如自动化代码调试或科研实验调度。想请教熟悉连续生成框架的朋友：这种连续轨迹和diffusion-based planning方法有本质区别吗？会不会只是换了个马甲？