TripStar 旅途星辰：開源 AI 旅行規劃工具，多智能體＋小紅書資料的自架方案

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

TripStar（旅途星辰）是一套把「查景點、看天氣、排住宿、算預算、畫路線」交給多個 AI 分工的開源旅行規劃工具，兩千多顆星、GPL-2.0 授權、前後端分離的 Vue 加 FastAPI。它的核心亮點，同時也正是它最現實的門檻：景點與配圖資料不是官方 API，而是用你自己的小紅書登入 Cookie 去抓小紅書的遊記，再交給大模型提煉。這代表它漂亮、可玩性高，但對多數本地讀者來說，得先搞懂資料從哪來、覆蓋到哪裡、自架要付出什麼。

TripStar 適合「想玩多智能體、不怕花時間搞定一堆 API Key、主要規劃中國大陸行程」的開發者與重度玩家。如果你只想快速排一趟日本或台灣行程，直接用現成線上工具會省事很多；它的核心價值是架構和可改性，開箱即用的台灣在地體驗本來就不是它的重點。

把行程交給一個主控 Agent 和幾個專員的規劃器

說白一點，TripStar 想做的事是：你填城市、天數、偏好（交通方式、住宿風格、興趣），它就派一個主控 Agent 出來，把任務拆給不同角色去跑。讀它的原始碼與 README 可以看到幾個具體分工：一個負責去小紅書找景點並補上經緯度、一個查天氣、一個按預算找住宿，最後由主控把三方結果兜成一份帶地圖路線、逐日行程、預算明細與知識圖譜的完整規劃。

它建構在 HelloAgents 這個框架上（jjyaoao 的開源專案，兩千多顆星），用 React 推理模式讓 Agent 一步步拆解任務，再用 asyncio.gather 讓景點、天氣、住宿三條線並行跑，最後串行聚合。這個工程設計對想研究多智能體協作的人來說很有參考價值，也是它和一般「問答生行程」工具在架構上很根本的差別之一。

Pin

台灣和海外能用嗎？答案要先看資料從哪裡來

這是最該先問的一個問題，而答案藏在 backend/app/services/xhs_service.py 這個檔案裡。TripStar 的景點資料心臟是小紅書，不是高德、也不是 Google。這個檔案的開頭註明它「基於 Spider_XHS 原生簽名引擎，使用本地 JS 簽名直連 edith.xiaohongshu.com API，解決 300011 帳號異常風控誤殺問題」。

Pin

把這句話翻譯成人話：它會在本地端算出小紅書內部介面需要的請求簽章，直接打小紅書的後端 API 去撈遊記內容，還得閃躲小紅書的反爬蟲風控（300011 是小紅書的「帳號異常」錯誤碼）。景點是這樣來的，景點配圖也是同一條路，README 寫得很明白：圖片是「以景點名搜尋小紅書最新發布的帖子，取首張圖」。

這件事的影響很直接，至少有三條會卡到：

• 小紅書的遊記密度在中國大陸城市最高（README 自己舉的例子是西安、故宮、陝西歷史博物館）。台灣本地、或日本東南亞的景點，小紅書上的中文遊記相對少，規劃品質會跟著打折。
• 它的地圖引擎預設走高德。高德在台灣的覆蓋與解析度本來就比 Google 差一截，街道與 POI 細節偏粗。
• 想要海外與 Google 地圖體驗，你得額外在 Google Cloud 開通、綁卡、申請 Key，而且在中國大陸境內還得掛代理才能穩定打到 Google API（台灣本地則不需要）。

專案的 issue 也印證了這個限制：#33 有人建議「除了小紅書能不能多接其他平台」，#28 則反映「抓取的小紅書圖片無法正常顯示」。單一平台來源與抓取穩定性，是已知而尚未解決的問題，不是我測試時偶發的狀況。

「本地部署」其實還是全部連網

TripStar 常被介紹成「可以自己架的本地工具」，這句話只對一半：程式碼確實跑在你自己的機器上（FastAPI 後端加 Vue 前端，官方推薦用 Docker Compose 一鍵起來），但它幾乎沒有任何離線成分，所有資料都來自雲端。

把它需要的東西列出來就清楚了：景點與配圖來自小紅書（透過你的 Cookie 抓取）；大模型推理透過 OpenAI 相容介面呼叫雲端 LLM，README 還建議改用豆包這類中國本土、按 Token 計費的模型，把 API 測試花費壓低一點；地圖與地理編碼走高德或 Google；而你的旅行需求、偏好、預算，會連同小紅書 Cookie、地圖查詢一起送到這些第三方服務。

所以「自部署」在這裡只代表你自己控制程式和編排邏輯，資料並不會留在本機處理。把它當成離線隱私方案會完全誤解它的運作方式。它和那種檔案真的不出本機的 PDF 塗黑工具是不同層次的事，也比「儲存在本地、但其實送到雲端語音辨識」的工具更澈底：連資料本身都是從雲端抓回來的。如果你在意的是純粹的本地優先，這類只在本機跑、聯網只用來檢查更新的工具會是更貼近的選擇。

小紅書 Cookie 的代價：拿你的登入狀態去抓資料

要跑 TripStar，你必須先在小紅書網頁端登入，再從瀏覽器開發者工具複製一整串 Cookie 填進 .env 的 XHS_COOKIE，範例長相是 a1=xxx; web_session=xxx; webId=xxx。這是它「必填」的環境變數之一，沒填就跑不出景點。

拿你的登入 Cookie 去抓資料，代價不只是配置麻煩，還有幾個現實問題得承擔：

• 這是非官方、反向工程的接法，等於用你的帳號狀態去做小紅書服務條款不樂見的自動化抓取，理論上有帳號被風控、甚至停用的風險。原始碼裡那個 300011 風控碼，就是小紅書反爬蟲和工具閃躲之間的攻防痕跡。
• Cookie 會過期。xhs_service.py 裡有一個 XHSCookieExpiredError 例外，專門用來在前端跳「Cookie 過期」的警報，意思是過一陣子你就得重新登入、重新複製 Cookie。
• 抓回來的遊記文字與圖片，版權屬於小紅書上的原作者。自己玩沒問題，但若要二次開發成對外服務或商業產品，這層內容授權得自己釐清，跟把別人平台文件抓來做第三方搜尋是同一類的合法性問題。

會走到這一步，是因為 TripStar 把小紅書 Cookie 當成它選定的資料取得方式，算不上技術瑕疵；只是這份代價被轉嫁到每個想自架的人身上。

多智能體架構怎麼把行程兜起來

撇開資料來源的爭議，TripStar 的工程設計確實有看頭，也是它真正值得開發者研究的地方，和用自然語言查資料庫的多智能體助手屬於同一條「把任務拆給多個 Agent」的技術脈絡。

整個流程是這樣跑的：你把請求 POST 到 /api/trip/plan，後端不讓你乾等，而是立刻回一個 task_id，把可能長達數分鐘的推理工作丟到背景跑，前端再透過 WebSocket（也保留每三秒輪詢狀態的備援）即時收到「正在搜尋景點」「正在查天氣」這類進度。這個設計直接回應了一個很實際的痛點：大模型長文推理很慢，如果前端同步死等，很容易在閘道層撞上 504 timeout。

並行階段用 asyncio.gather 同時跑三條線（景點搜尋、天氣、住宿），地圖地理編碼是 Google 優先、失敗才降級高德。串行聚合階段把三方結果餵進終極 Planner Prompt，要模型吐出一份結構化的 JSON 行程。這裡有個很誠實的工程細節：模型輸出的 JSON 常常是髒的，所以程式裡有一套五步驟的容錯解析（清雜字、補跳脫引號、截斷修復、暴力抽取、最後才回頭問模型修補），反映了「要 LLM 穩定吐結構化資料」在實務上的真實難度。

最後它還會把行程轉成知識圖譜，用城市、天數、景點、預算之間的節點關係畫成網狀結構，這種把非結構化內容轉成可視知識圖譜的思路在開源圈越來越常見。它還提供一個帶完整行程脈絡的懸浮 AI 問答視窗，讓你針對「這個景點要不要預約」「適合帶長輩嗎」追問。

一個值得一提的細節是景點預約提醒。它會從小紅書遊記裡辨識出需要提前預約的景點（README 舉的例子是故宮、陝西歷史博物館這種一票難求的地方），在行程卡片上標出預約提示與管道，降低你到了現場才發現沒位的風險。這個功能的效果當然取決於小紅書遊記有沒有寫到預約資訊，不是萬能，但對中國大陸熱門景點的確實用，也看得出這個專案把「真實出遊會踩的坑」放進了設計裡。

兩套地圖引擎與多城市行程：和不少介紹文章說的不一樣

不少介紹文章把 TripStar 簡化成「用高德地圖的工具」，但讀 README 與 map_dispatcher.py 會看到更完整的設計：地理編碼是 Google 優先、失敗才降級高德 REST，前端地圖也設計成「海外用 Google Maps、中國大陸境內則退回高德」的自動切換。這代表前面講的「台灣覆蓋偏弱」其實有解，只要你願意申請 Google Key、綁卡（中國大陸境內還要掛代理，台灣本地則不用），海外與台灣的地圖體驗可以拉到 Google 的水準。

但有個前提得講清楚：換掉的是地圖引擎，不是景點資料來源。景點本身仍來自小紅書，所以就算地圖再清楚，能選的景點選項還是偏中國大陸。這也是讀原始碼比看二手介紹有價值的地方：它的地圖策略其實比「高德工具」更國際化，只是這份國際化得你自己把 Google 那條線接起來才拿得到。

另一個常被略過的能力是多城市行程。你可以在一次旅行裡排進多個城市、各自設停留天數，系統會自動算總天數、在移動日標註城際交通建議、把城際交通費獨立算進預算，天氣與知識圖譜也按城市分開呈現。對排「北京加西安」或「東京加大阪」這類跨城行程，這比只會排單一城市的工具實用得多。官方在魔搭社區也放了「Journey to the China」線上 demo 可以直接試，不想架環境的人能先上去感受一下互動與生成節奏，再決定要不要自己裝。

自己架一遍要準備什麼

想在本機跑，環境不算輕。後端要 Python 3.10 以上加 uv 套件管理員，前端要 Node.js 18 以上，小紅書簽章引擎還額外需要 npm install 裝一包 Node 依賴。.env.example 把必填項標得很清楚：

• LLM 三件組：LLM_API_KEY、LLM_BASE_URL、LLM_MODEL_ID，而且模型必須支援結構化（JSON）輸出，若只接一般的聊天對話模型，後端常常解析不出 JSON、直接報錯。
• XHS_COOKIE：你的小紅書登入 Cookie，前文提過它的代價。
• VITE_AMAP_WEB_KEY：高德的 Web 服務 Key；前端還要另一個 JS API Key，並在 index.html 注入安全密鑰 securityJsCode。
• 選填：GOOGLE_MAPS_API_KEY 與 GOOGLE_MAPS_PROXY，填了才會優先用 Google 地圖。

官方推薦用 Docker Compose 一起起來會比較省事。但即使如此，把四種 Key（LLM、小紅書 Cookie、高德、Google）湊齊再加上 securityJsCode，對沒架過前後端專案的人還是一段不短的路。挑大模型服務本身就是一門成本學問，這裡還要再加上地圖與抓取端的設定，說白一點，如果你不想碰這些設定檔，TripStar 對你的邊際效益很低。

和現成線上工具比起來，它的位置在哪

TripStar 的差異化很明確：它是一套你可以自己架、自己改、看得到多智能體怎麼跑的方案，想打開網頁就排好行程的人它幫不上忙。把幾種方案擺在一起比，就能看出它的定位：

最省事的一頭是 ChatGPT、Gemini，丟一句話就有文字行程，但沒有地圖也沒有預算結構；往中間走是 Wanderlog 這類成品服務，體驗完整，代價是邏輯全黑箱、你也改不動。TripStar 卡在最自由的那一端，什麼都能改，代價是什麼都得自己接，跟成品服務各做各的市場。

授權、商用與第三方 API 的現實

TripStar 是 GPL-2.0，屬於 copyleft 性質：你可以免費用、可以改，但把衍生作品散布出去時，也得用相容授權開源。這對個人研究沒影響，對想拿它做商業 SaaS 的人則是必須先想清楚的事。

更大的現實在第三方 API：小紅書（非官方抓取）、高德、Google、LLM 服務商，每一個都有自己的計費規則與商業授權範圍。README 也明講，要做二次開發或商用前，建議你先把這些介面的並發上限和商用授權條款一條條對清楚，免得產品上線了，才發現額度或計費方式跟你的使用情境兜不起來。其中小紅書這條是非官方接法，把它帶進商業產品的合規風險，得由部署者自行承擔。

適合誰、不適合誰

講白了，TripStar 是給願意花一個晚上把四支 Key 湊齊、想親眼看多智能體怎麼拆任務、而且主要排中國大陸行程的人玩的；你願意定期重抓小紅書 Cookie，它就回報你一份看得到每一步運作的行程。若你只是週末想排一趟京都或墾丁的輕旅行，不想碰設定檔，也對「資料靠抓小紅書」有顧慮，那打開 Wanderlog 或直接問 ChatGPT，同一個晚上會給你更可用的答案。

常見問答

TripStar 免費嗎？

程式碼本身免費開源（GPL-2.0）。但它依賴的 LLM、高德、Google 地圖 API 各有計費，小紅書則是用你的帳號 Cookie 抓取。所以免費的只有程式本身，背後每一項雲端服務都還是要花錢或付出帳號代價。

不填小紅書 Cookie 能用嗎？

不能。XHS_COOKIE 是必填，景點資料與配圖都靠它抓。Cookie 過期時程式會丟 XHSCookieExpiredError，你得重新登入小紅書、再複製一份 Cookie 進去。

它支援台灣或海外城市嗎？

技術上能輸入任意城市，但景點資料來自小紅書，中國大陸城市覆蓋最密，台灣與海外景點的遊記相對少，規劃品質會打折。地圖想在台灣看得清楚，建議改用 Google 引擎，不過那需要額外申請 Key 與代理。

多智能體會比直接問 ChatGPT 排得好嗎？

不一定。多智能體的優勢是結構化輸出（地圖、預算、逐日行程、知識圖譜）和可拆解性，規劃品質不一定更好。行程好壞最終取決於小紅書資料密度與 LLM 能力，AI 排出來的行程和預算只能當參考，實際出發前還是要自己再對一次官網資訊。

可以拿來做商業產品嗎？

程式碼授權允許（須遵守 GPL-2.0），但小紅書資料是非官方抓取，內容版權屬原作者，把它商業化的合規風險很高。高德、Google、LLM 的商業授權與計費也需逐項釐清。

整體來看，TripStar 最迷人的地方是架構拆得開、改得動，讀原始碼本身就是收穫；但它要你湊齊好幾支 Key、定期維護小紅書 Cookie，換來的也不會是一份開箱即用的台灣在地行程。先確認自己要的是哪一種，再決定要不要花這個晚上動手。