摘要第 6 篇文章讲了如何将 Flow 发布为 HTTP API 或 MCP 工具。Flow 一旦进入外部系统调用链路，性能问题就会变得更明显：用户不再只关心“能不能运行”，还会关心“多久返回、是否稳定、是否会拖垮服务、失败时能不能定位”。复杂 Flow 的性能瓶颈通常不是单点问题，而是多个因素叠加：文档重复解析。Embedding 重复计算。模型重复调用。向量库检索过慢。外部 API 阻塞。Prompt 和中间结果过大。分支过多导致无效节点执行。组件内部创建了过多临时对象。并发执行触发第三方限流。本文围绕一个实践目标展开：如何定位并优化一个复杂 Flow 的性能问题。重点不是给出某个固定配置，而是建立一套可复用的方法：先收集证据 - 再定位瓶颈 - 再做小步优化 - 最后验证结果一致性和稳定性读者预期读完本文后，读者应该能够回答以下问题：复杂 Flow 的性能瓶颈通常来自哪里。如何利用节点运行事件、日志和 Trace 判断慢在哪里。Graph、Vertex 和组件执行之间是什么关系。为什么不能只看总耗