Lyft 如何利用 LangGraph 和 LangSmith 構建自助式 AI 代理平臺
Lyft 採用 LangGraph 和 LangSmith 構建了一個自助式 AI 代理平臺，用於客戶支援，將代理開發時間從數月縮短至數週。該平臺透過路由多代理架構、LangGraph 的子圖功能以及 LangSmith 的追蹤與監控工具，賦能非技術領域專家獨立開發 AI 代理，並藉助 LLM-as-a-Judge 評估系統確保質量。
文章情報
要點
- Lyft 透過讓運營團隊、VoC 負責人和產品經理直接使用提示和配置來定義代理，減少了機器學習工程師的介入。
- 基於路由器的多代理架構使用 LangGraph 協調專業子代理，實現安全檢查和狀態管理。
- 生產質量依賴於評估、監控和提示紀律，Lyft 使用 LangSmith 進行追蹤和 LLM-as-a-Judge 評估。
- 結構化提示編寫成為代理可靠性的關鍵因素。
為什麼重要
這條新聞值得關注，因為Lyft 透過讓運營團隊、VoC 負責人和產品經理直接使用提示和配置來定義代理，減少了機器學習工程師的介入。
技術影響
可能影響模型選型、推理成本、產品能力和評測基準。
Lyft 利用 LangGraph 和 LangSmith 構建了一個自助式 AI 代理平臺，用於客戶支援，顯著加快了代理開發速度。該平臺透過路由多代理架構，實現了對乘客和司機請求的智慧處理。
在架構方面，系統採用 LangGraph 的路由多代理模式：一個元代理充當有狀態路由器，根據傳入請求分類並分派到專門的子代理。每個子代理都是一個完整的 LangGraph StateGraph，作為子圖節點註冊在元代理中。對於乘客和司機，系統分別執行獨立的路由器例項。當乘客聯絡客服時，元代理路由到乘客意圖子代理；司機則路由到司機意圖子代理。若意圖代理在對話過程中發現需要更專業的代理，它可以透過 Command(goto=..., graph=Command.PARENT) 將控制權交回元代理，元代理再重新路由到合適的專家代理。
子代理遵循一致的節點模式：安全檢測與惡意意圖檢測透過 LangGraph 的 Command(goto=[...]) 並行執行，先於任何 LLM 推理。這種設計既保證了安全性，又實現了模組化部署——新增新代理只需定義新子圖並註冊到元代理。
Lyft 將代理分為兩類：專業代理（由 MLE 手工構建，處理複雜高風險的工單）和可配置代理（自助服務層）。可配置代理在執行時從 JSON 配置中動態載入，提示從 LangSmith 的 Prompt Hub 中獲取。領域專家按照結構化模板編寫提示，包含角色、範圍、工作流階段和內容指南等五個必需部分。然後，ConfigurableAgent 類處理圖構建、工具繫結、安全門和狀態管理。產品經理可透過編寫提示和 JSON 配置來定義新代理，無需 MLE 程式碼變更。
狀態持久化方面，Lyft 構建了自定義的 DynamoDBSaver，實現了 LangGraph 的 BaseCheckpointSaver 介面，為多輪對話提供持久狀態儲存。每個檢查點儲存完整的圖狀態、執行後設資料和父檢查點引用，支援對話回放和除錯。
LangSmith 用於全面追蹤和監控：每個代理呼叫都被追蹤，捕獲圖執行詳情。透過 LLM-as-a-Judge 評估管道，代理在全面上線前必須透過自動評估。評估指標包括任務完成率、安全違規率、回覆相關性和客戶滿意度。此外，每個代理都有生產監控儀表板，跟蹤執行量、錯誤率、延遲、令牌使用和評估分數，並與 PagerDuty 整合實現自動告警。
Lyft 團隊發現，最大的瓶頸不是基礎設施，而是提示質量。領域專家雖然瞭解問題型別，但難以將知識轉化為 LLM 可靠遵循的指令。為此，Lyft 開發了結構化提示編寫框架和自動提示驗證管線，確保每個提示在生產前透過審查。這包括五部分模板和審查清單，以及基於 Git 的提示檢查流程。
透過這一平臺，Lyft 將代理開發週期從數月縮短至數週，同時保持了高標準的質量和安全。