Walmart Rufus
可回答問題、推薦商品與追蹤價格，卻不會為單一買方形成還價方案。
返回專案列表
TurnDeal 團隊獲得蝦皮購物母公司 Sea × OpenAI 黑客松亞太區系列賽台灣站第一名 
TurnDeal 團隊在蝦皮購物母公司 Sea × OpenAI 黑客松亞太區系列賽台灣站現場開發原型 
TurnDeal 團隊在蝦皮購物母公司 Sea × OpenAI 黑客松亞太區系列賽台灣站現場展示原型
TurnDeal — 電商 Agent-to-Agent 協商機制
Turn Any Need into a Deal
讓買家與賣家 agent 形成個人化方案、再由後端驗證的電商協商層，最後仍由消費者做出選擇。
查看 GitHub 專案專案紀錄
操作展示
問題
購物 AI 多半止步於公開商品資訊
AI 正逐漸成為購物入口，但使用者仍會回到電商平台核對資訊並完成購買。現有助理能協助探索、比較與結帳，卻仍停留在公開商品資訊之間做最佳化，無法針對買方需求協商價格、交期、組合或會員權益。
市場訊號
Amazon Sparky
可進行對話式商品探索與購物籃建立，卻不會代表買方跨賣家協商。
ACP / UCP
可串接目錄、結帳與付款，卻未定義買方與賣家 Agent 在購買前如何形成已驗證的協商方案。
我們提出的解法
由平台掌握的電商協商層
01
平台資料層
即時商品、庫存、評分、物流、退貨與會員權益資料保留在電商平台內；Formatter 再將自然語言需求轉為探索可用的硬條件與排序偏好。
02
Agent 協商層
私有買方分支與合格賣家 Agent 平行協商。每個分支保護賣家的政策與脈絡；同步回合僅共享匿名且經後端驗證的市場條件。
03
信任與驗證層
賣家可設定 22 項 Offer 限制。後端會檢查歸屬、庫存、總價、交期、配件與政策範圍，通過後才發布不可變的 Offer 供 Evaluator 排序。
04
決策與結帳層
React 介面在桌機與手機呈現排序後的 Deal Card。使用者明確確認一個方案後，平台會再次驗證，再開啟模擬 ACP 結帳流程。
系統架構
TurnDeal 如何形成可信任的交易方案
私有買方分支先平行協商，再由平台驗證、排序並為選定方案建立結帳流程。
步驟 01
買方需求
使用者以自然語言描述預算、交期與商品偏好。
步驟 02
Formatter
將需求轉為可驗證的硬條件與排序偏好。
步驟 03
Orchestrator
挑選合格賣家、凍結本次需求脈絡，並建立隔離的協商分支。
步驟 04
私有協商工作階段
每位賣家只看到自己的政策、商品脈絡與分支歷史；同步回合可共享匿名且經後端驗證的市場條件。
賣家設定：價格策略
買方分支 A賣家 A
詢價與協商需求（RFQ）：買方需求與已驗證市場條件
賣家回覆：接受、還價或拒絕
自身底價與交期條件
賣家設定：速度策略
買方分支 B賣家 B
詢價與協商需求（RFQ）：買方需求與已驗證市場條件
賣家回覆：接受、還價或拒絕
自身物流與服務條件
賣家設定：組合策略
買方分支 C賣家 C
詢價與協商需求（RFQ）：買方需求與已驗證市場條件
賣家回覆：接受、還價或拒絕
自身配件與權益條件
後端驗證後，匿名市場條件會帶入下一個協商回合
步驟 05
Offer Validator
檢查賣家歸屬、庫存、總價、交期、配件與政策限制，才發布不可變的 Offer。
步驟 06
Evaluator
在不讀取賣家私有政策的前提下，對完整合格 Offer 集合排序。
步驟 07
使用者確認
使用者瀏覽 Deal Card，並明確確認選擇的方案。
步驟 08
ACP 測試結帳
重新驗證已接受的 Offer，再建立模擬 ACP 結帳與付款流程。
實作與成果
可控的 Multi-Agent 電商協商流程
Multi-Agent Pipeline
我們設計串接需求格式化、商品探索、私有協商、Offer 驗證、評估與結帳確認的 pipeline；共用契約讓前端、runtime 與測試都依同一套協商模型運作。
平行協商
我們實作五個賣家分支，讓它們在同步回合中平行協商。後端只有在驗證前一回合後才提交共用 revision，使競爭資訊能流通，同時不暴露賣家私有條件。
賣家指標與 Offer 驗證
我們建模 22 項可由賣家設定的商業指標並實作 Offer 驗證，讓系統只評估符合賣家庫存、價格、交期、配件與政策限制的方案。
響應式 React 體驗
我們以 React 建立介面，讓買方能在桌機與手機透過同一套響應式流程輸入需求、追蹤進度、檢視 Deal Card 並確認選擇。
- 蝦皮購物母公司 Sea × OpenAI 黑客松亞太區系列賽台灣站
- 冠軍
- 由四人團隊在一天內完成
- 私有賣家協商分支
- 5 位賣家
- 每個分支各自隔離政策與脈絡
- 賣家商業指標
- 22 項
- Offer 成為合格方案前必須通過的限制條件
限制
仍待驗證的部分
TurnDeal 是黑客松原型。商品資訊與價格爬取自電商網站，現階段資料庫僅限滑鼠；賣家底線則依原先設定的 Persona 由 LLM 生成，並非真實商家政策。若要正式導入，仍需取得可驗證的商品與價格資料、串接真實賣家、加強政策與防詐控管、進行隱私審查、符合支付規範，並以真實使用者與物流結果驗證。