新聞

Uber Eats日前揭露Agent購物助手Cart Assistant背後的技術設計，說明他們如何用大型語言模型（LLM）和多階段Agent工作流程，讓使用者用自然語言描述需求，系統就能協助規畫購物清單、挑選商品，甚至給出可直接加入購物車的商品組合。

這項設計，反映電商AI應用的重要轉變：AI不再只是幫使用者搜尋商品或回答問題，而是可以協助完成一項具體購物任務。對Uber Eats來說，生鮮雜貨購物特別適合這種Agent模式，因為使用者往往不是只想買單一商品，而是想完成一個情境，例如準備一餐、補齊家用品，或為某個活動採買食材。

從搜尋優先走向購物車清單優先

進一步來說，傳統電商購物流程，多半是搜尋導向。使用者輸入關鍵字後，系統列出商品結果，再由使用者自行比較品牌、規格、價格與庫存，最後逐一加入購物車。

但Uber Eats認為，雜貨採買的真實需求，常常不是「我要搜尋某個商品」，而是「我要完成某件事」。例如，使用者可能輸入「幫我準備4人份的Taco食材」。在傳統搜尋模式下，使用者可能要分別搜尋玉米餅皮、牛絞肉、起司、生菜、番茄與莎莎醬等商品。但在Cart Assistant的設計中，系統會先理解這是一個餐食準備任務，再推理出需要哪些商品類別，最後才到商品目錄中尋找對應的品項。

換句話說，Uber Eats想把購物流程，從搜尋優先（Search-first）轉向購物車清單優先（Cart-first）。使用者不必從搜尋結果開始慢慢挑，而是先由AI產生一個接近可用的購物車清單，再讓使用者確認、調整。

採多階段Agent工作流程，而不是一次生成答案

Cart Assistant並不是把使用者需求丟給LLM，然後一次產生最終購物車。Uber Eats採用的是多指令狀態圖學（Multi-Prompt State Graph），也就是多提示、多狀態的工作流程架構。

用白話來說，這套系統會把購物任務拆成多個步驟，每個步驟處理不同問題，而不是期待模型一次把所有事情做好。

整體流程大致包括：先理解使用者需求，再產生購物計畫，接著搜尋候選商品，檢查商品是否符合需求與限制條件，最後再整理成購物車清單。

這樣做的好處是，每個階段都能檢查與修正。若直接讓模型一次產生結果，可能很難追蹤錯誤；但拆成工作流程後，系統可以知道問題出在哪裡，比如需求理解、商品搜尋、數量規畫，還是限制條件驗證。

購物車規畫是關鍵中介層

這篇文章中最重要的技術概念之一，是購物車規畫（Cart Plan）。它可以理解為，AI在真正挑商品前，先產生的一份購物計畫。它不是最終購物車，而是介於使用者需求與實際商品間的中介層。

例如，使用者說「準備Taco晚餐」，系統不會立刻搜尋商品，而是先建立一份計畫，判斷這個任務可能需要哪些食材類別，以及每一類食材在購物車中扮演什麼角色。

這層設計很重要，因為LLM雖然擅長理解自然語言，但若直接把抽象需求對應到商品目錄，很容易出現漏項、誤選或商品組合不完整的問題。購物車規畫可讓系統先拆解需求，分為比較明確的購物結構，再進入商品搜尋階段。

也就是說，這套系統不是從「使用者輸入」直接跳到「商品結果」，而是多了一層「購物規畫」。

商品選擇不只看語意相關，還要檢查限制條件

在商品搜尋階段，Cart Assistant會根據Cart Plan尋找相關商品。不過，Uber Eats也強調，商品是否語意相關，並不代表就一定適合加入購物車。

例如，某個商品可能和使用者需求很接近，但它可能不符合飲食限制、過敏原條件、預算，或當下商店庫存不足。這些都是Agent必須處理的現實問題。

因此，系統除了判斷商品與需求的語意相關性，也會進一步檢查多種限制條件，包括使用者偏好、商品可得性、庫存狀態與其他購物條件。

這也是購物Agent和一般聊天機器人的差異。聊天機器人只要回答得合理即可，但購物Agent一旦把商品加入購物車，就會影響實際交易，因此必須更嚴格地確認商品是否真的適合。

數量規畫是雜貨Agent的一大難題

相較於推薦商品，Uber Eats也提到，決定商品數量是更困難的挑戰。

例如，使用者要求準備4人份餐點時，系統不只要知道要買哪些品項，還要判斷每個品項該買多少。比如牛肉要買多少？醬料需要幾罐？蔬菜是一包就夠，還是需要兩包？這些問題，不像一般商品搜尋那麼單純。

數量規畫若做不好，使用者仍然需要大量手動調整，Cart Assistant就很難真正節省時間。因此，系統必須在商品搜尋後，進一步處理商品規格、份量與購物車組合的合理性。

這也讓Cart Assistant更接近任務規畫型Agent，而不是單純的推薦系統。

防護護欄是Agent能否落地的關鍵

Uber Eats在文章中也提到多種安全與品質控管機制，也就是常說的防護護欄（Guardrails）。

這些機制的目的，是避免Agent產生看似合理、但實際上不適合的購物結果。例如，商品名稱相似但類別不同、替代商品不合理、購物車缺少關鍵品項，或推薦了目前無法購買的商品。

因此，Cart Assistant會在不同階段檢查商品類別、商品可用性、購物車完整性與限制條件，避免AI直接把錯誤結果送到使用者面前。

這點也反映出Agent產品化的核心挑戰：真正困難的不是讓AI生成一份清單，而是讓這份清單在真實商業環境中可用、可買，而且符合使用者期待。

延遲也是工程挑戰

多階段Agent工作流程雖然能提高品質，但也會帶來新的問題：系統反應時間可能變長。

因為Cart Assistant需要理解需求、產生購物計畫、搜尋商品、限制條件驗證與購物車生成等多個步驟，如果每一步都花太久，使用體驗就會下降。

因此，Uber Eats也必須在準確率、回應速度與系統成本之間取得平衡。這是許多Agent應用走向產品化時，都會遇到的共同問題：流程越完整，品質越可控，但也可能讓系統變慢、成本變高。

評測重點從回答正確，轉向任務是否完成

Uber Eats也用評估驅動開發（Evaluation-Driven Development）的方式來開發Cart Assistant。意思是，團隊不只看模型回答是否流暢，而是更重視整個購物任務是否真的完成。

以購物Agent來說，評測標準包括商品是否正確、購物車是否完整、是否符合限制條件、數量是否合理，以及整體結果是否能滿足使用者需求。

這與傳統LLM評測很不一樣。一般聊天機器人評估回答是否正確、是否自然即可，但Agent更重要的是執行結果。使用者最後在意的不是AI說得好不好，而是購物車能不能用。

從Uber Eats公開的技術架構來看，Agent應用已經從模型能力本身，轉向工作流程設計、商品資料整合、限制條件驗證和任務執行品質。對電商來說，新一代的AI購物體驗，可能不只是讓使用者更快找到商品，而是讓AI真正參與購物決策，協助使用者更快完成整個採買流程。