今天的重點，是把整個服務裡最關鍵的一塊 —— Bot —— 的技術選型先定下來。
這個 Bot 就像是系統的「核心大腦」，負責透過 WhatsApp 與客戶互動，串起所有的資料、判斷與回應。

資料的存放與追蹤
在「對話紀錄」的設計上，我一開始就想到未來的需求不只是純文字訊息，還可能涉及：

• 報價草稿
• 人工審核記錄
• 多語版本的訊息
  因此直接選擇 MongoDB 來處理會話與狀態。它的結構彈性高，後續要加欄位來追蹤就很方便，不會被固定 Schema 卡住。

快速檢索與 FAQ 回答
為了讓 Bot 能快速回答「大稻埕適合拍什麼？」這類常見問題，我引入了 Pinecone 當向量庫。
搭配embedding模型，就能把地點資訊、常見問題整理成知識庫，讓客戶查詢更即時，不用每次都人工回覆。

後台與 Bot 框架
後台框架：依舊選用 FastAPI，輕量、好用，也能接上後續的 LangChain / LangGraph。
Bot 開發：主力放在 LangChain + LangGraph。其中 LangGraph 可以幫我把 Agent 串起來，整合

• StyleIntent（風格意圖判斷）
• LocationSearch（地點搜尋）
• WeatherForecast（天氣匹配）
• TransitEstimator（交通估算）
  工具，更重要的是，他能讓流程暫停等待使用者回饋，再接續後續行為，這會讓整體服務更加順暢符合人性。

模型與外部服務
模型：在poc階段，選擇使用 Groq 提供的 Llama 3.3–70B。原因很單純：延遲低、有免費額度，非常適合即時對話場景。
天氣資訊：串接 中央氣象局 OpenData，取得降雨率、溫度預報，讓推薦更貼近實際狀況。
交通時間：使用 Google Maps API MCP 服務，幫客戶算出大眾運輸的方式與時間。

與客戶的互動管道
主要進線通道會放在 WhatsApp Business Cloud API。
考量到國際旅客的使用習慣，WhatsApp 在台灣以外的接受度高得多，比 LINE 更符合我們的服務定位。

初步的需求分析和技術選擇就到這裡。接下來，就是一步一步把這些規劃落實出來，讓 Bot 真正運作起來。