首先我要猜想一下您所謂的“聚合打車”的概念。您是希望搭建一個平臺，使用者輸入打車需求，透過您的系統選定最佳打車軟體的服務並推薦給使用者嗎？

如果是這樣的想法的話，我們可以從另一個“聚合”案例談起，就是“聚合支付”。“聚合支付”的原理是一家企業同時接入多加平臺的支付方式，集中提供給使用者，讓使用者自行選擇喜歡的方式支付結算。搭建這樣的平臺，系統需要申請多個平臺的API介面呼叫許可權，而各平臺申請API許可權所需要的材料不同，有的需要註冊公司才能申請。完成申請之後，就可以再自身搭建的系統上利用各平臺API介面進行資料獲取和下單了。

所以聚合打車平臺也是如此，首先要申請各平臺的API介面，目前市面上不是所有打車軟體都有可供第三方呼叫的介面，而且介面可能是付費的，所以如果沒有介面，可能需要實力強大的公司區各打車平臺商討介面開放事宜。拿到了各平臺介面後，就可以在使用者輸入要素之後，同時呼叫多加打車平臺介面獲取費用資訊，系統透過資料比對，選擇合適得方案提供給使用者。不過和聚合支付不同的是，打車流程裡，下單只是第一步，接下來使用者會產生與司機溝通和導航等需求，這種情況下目前大部分平臺都沒有執行緒介面可用，系統理論上只有兩條路走，一條是開啟對應打車軟體，由對方託管後面得流程，另一條路是看看打車軟體中有沒有H5頁面直接提供服務的，在您的系統裡開啟對方的H5頁面進行後續服務。

總之，技術上並沒有瓶頸，瓶頸可能在申請流程和準備材料上，希望可以幫到您。