這次我們來看一個更偏架構和協議層面的項目An open protocol for AI-mediated product discovery。一句話解釋它想定義一套開放協議讓 AI Agent 在幫用戶找產品、比較產品、給出購買建議的時候不依賴某個平臺的私有接口而是有一套通用的消息格式、權限模型和數據規范。對這個方向我的判斷是它比單個推薦算法、某個搜索工具更值得關注因為它解決的是AI 助手接入電商、本地生活、企業采購等場景時的“最后一公里協議問題”。這次文章不聊模型顯存不聊推理優化重點是拆解這套協議的動機、核心設計、工程落地方法和適合哪些團隊跟進。1. 核心能力速覽能力項說明項目類型面向 AI Agent 與產品發現場景的開放協議規范要解決的問題AI 助手無法統一獲取、比較、決策產品信息的碎片化問題核心能力意圖解析、候選發現、參數提取、結果重排、決策解釋、權限控制與 MCP 的關系可看作 MCP 思路在產品發現場景的垂直延伸用于連接商品/服務數據源適用平臺電商平臺、本地生活服務、企業采購系統、線下門店商品庫是否支持 API協議定義的是接口交互規范工程落地時提供 SDK / HTTP / gRPC 實現是否支持批量任務可在代理層設計批處理任務例如批量商品比對、批量報價更新啟動方式非獨立應用需要以 SDK 或網關服務方式集成適合讀者AI 應用開發者、推薦系統工程師、電商平臺架構師、Agent 平臺設計者需要強調這更多是一份協議設計愿景與技術規范不是某個可以直接啟動的 WebUI 項目。進入正文前先把邊界說清楚。2. 為什么需要一套 AI 產品發現協議2.1 現在 AI 找產品是“拼接口”過去一年大模型讓“幫用戶找產品”這件事變得可用但工程上依舊很痛苦。一個 AI 購物助手要完成一次完整推薦通常需要從用戶對話里提取品牌、價格區間、品類、使用場景調用電商平臺的搜索接口拿到商品列表后做過濾、排序再把結果轉成自然語言推薦話術。聽起來不復雜實際上每一個環節都是私有實現。每家平臺的商品字段不統一有的叫title有的叫itemName有的叫product_title庫存狀態、價格字段、優惠信息、配送范圍的表達更是千差萬別。AI Agent 每接入一個新平臺就要重新寫一遍適配層。這是典型的接口碎片化問題。MCPModel Context Protocol解決了模型與工具之間的連接問題但產品發現場景還需要一層更垂直的協議來統一“產品意圖”“候選結果”“決策解釋”這些業務概念。2.2 用戶要的不是鏈接是決策支持傳統搜索框給用戶一堆結果鏈接點擊后自己判斷。AI 產品發現則不同用戶期望的是“2000 元以內適合編程的 4K 顯示器有哪些”“通勤單程 40 分鐘預算 15 萬幫我選一輛電車。”“下周去杭州出差 3 天幫我找公司附近評分最高的酒店。”這些請求背后是多條件約束下的產品發現需要協議層支持結構化意圖、候選集合并、屬性過濾和可解釋的排序結果。而現有平臺的開放接口主要面向“關鍵詞搜索”沒有為 AI 決策設計。2.3 關鍵詞與協議的核心定位從標題可以看出這套協議強調兩個關鍵詞open protocol開放協議不綁定單一平臺、單一模型任何數據提供方都可以按規范暴露產品發現能力。AI-mediatedAI 中介由 AI 作為用戶與產品之間的中介層協議設計要圍繞模型的意圖理解和生成能力展開。換句話說這不是一個搜索引擎協議也不是一個電商 API 規范而是一套“AI 作為對話式產品發現入口”的場景協議。3. 協議要覆蓋的關鍵能力3.1 意圖語義與約束提取傳統搜索用關鍵詞AI 產品發現要支持自然語言請求的結構化轉換。協議需要定義一套統一的意圖消息結構至少包含請求意圖類型查詢、比較、推薦、解釋、購買前驗證等。約束條件集合品牌、價格、尺寸、顏色、評分、發貨時效。用戶上下文場景、預算、歷史偏好需要用戶授權。排序偏好價格優先、評分優先、距離優先、綜合推薦。這塊是協議最核心的抽象。如果沒有統一的意圖格式AI Agent 接每個平臺都要重寫一套意圖解析邏輯。3.2 候選產品發現協議需要定義產品發現的請求與響應格式包括數據源選擇單平臺搜索還是多平臺聚合。分頁與游標AI Agent 可能需要多輪翻頁。結果歸一化不同平臺的商品必須映射到統一產品檔案。可用性與庫存實時庫存、預售、區域限購的表示。如果沒有統一響應結構多平臺聚合就只能靠爬蟲和接口逆向既不穩定也有合規風險。3.3 結果重排與解釋AI 推薦產品不能只丟列表還要說明“為什么推薦這個”。協議應包含重排參數用戶顯式約束、模型推薦分數、平臺排序、商業策略如廣告標注。解釋字段每個候選結果需要附帶可讀的推薦理由。對比維度多產品對比時的屬性差異高亮。協議層面如果支持“解釋”字段AI 應用就可以直接生成帶理由的推薦話術而不是事后為每個商品編理由。3.4 權限與用戶授權AI 訪問用戶購物歷史、位置、企業采購預算等信息涉及敏感數據。協議需要設計權限層例如用戶顯式授權的數據范圍。臨時令牌與短時有效期。用戶取消授權的機制。商業數據與個人數據的分離。沒有權限設計這類協議很難被嚴肅平臺采用。4. 協議消息設計示例協議不能只停留在概念層下面給一組簡化的消息結構示例用于說明“統一產品檔案”和“意圖請求”應該如何設計。實際項目落地時可以按這套思路擴展 JSON Schema。4.1 產品檔案對象{ product: { product_id: platform_a:sku_90831, source: platform_a, name: 某品牌 4K 27 英寸顯示器, brand: 某品牌, category: [顯示器, 辦公設備], price: { amount: 1899, currency: CNY, original_amount: 2399 }, stock_status: in_stock, attributes: { screen_size: 27英寸, resolution: 3840x2160, panel_type: IPS, interface: [HDMI, DP, Type-C] }, seller: { name: 品牌官方旗艦店, rating: 4.8 }, shipping: { area_available: true, eta_days: 2 } } }這個結構解決的是字段歸一化問題。無論底層平臺用什么字段名協議層統一用name、price、attributes這類標準字段暴露給上層 Agent。4.2 發現請求{ request_id: req_20250601_001, intent: recommend, query_text: 2000元以內適合編程的4K顯示器, constraints: { price_max: 2000, category: 顯示器, attributes: { resolution: 3840x2160 } }, sort: { primary: score, secondary: price_asc }, pagination: { page_size: 10, cursor: null }, context: { scenario: coding_setup, priority: [screen_size, color_accuracy] } }從這個請求結構可以看出協議層把“自然語言”和“結構化約束”同時保留。query_text是為大模型準備的constraints是為檢索系統準備的兩者互補。4.3 發現響應{ request_id: req_20250601_001, candidates: [ { product_ref: platform_a:sku_90831, match_score: 0.92, matched_attributes: [resolution, price, panel_type], explanation: 27英寸 IPS 面板4K 分辨率價格 1899 元符合預算約束。, ranking_signals: { user_constraint: 0.7, model_score: 0.15, platform_rank: 0.15 } } ], total: 1, next_cursor: null, data_source_info: { platform: platform_a, cached: false, latency_ms: 320 } }響應里最值得借鑒的是explanation和ranking_signals。有了這兩個字段AI Agent 的下游任務就會簡單很多直接基于explanation生成推薦話術同時可以判斷結果是否被商業策略干擾。5. 關鍵流程設計5.1 一次完整的產品發現流程用戶輸入自然語言 ↓ 意圖解析與約束提取 ↓ 數據源路由單平臺/多平臺 ↓ 候選產品檢索 ↓ 結果歸一化與屬性映射 ↓ 重排與過濾約束校驗 ↓ 解釋生成與結果返回 ↓ 用戶反饋采納/放棄/追問這個流程本質上把“對話式產品推薦”拆成了可以各自獨立迭代的模塊。協議要做的就是把每個環節之間的數據結構固定下來讓不同團隊可以獨立開發、聯動測試。5.2 狀態機設計from enum import Enum class DiscoveryState(Enum): PENDING pending PARSING_INTENT parsing_intent ROUTING routing SEARCHING searching FILTERING filtering RERANKING reranking EXPLAINING explaining COMPLETED completed FAILED failed def next(self, event: str): transitions { submit: (DiscoveryState.PENDING, DiscoveryState.PARSING_INTENT), intent_ready: (DiscoveryState.PARSING_INTENT, DiscoveryState.ROUTING), sources_selected: (DiscoveryState.ROUTING, DiscoveryState.SEARCHING), candidates_found: (DiscoveryState.SEARCHING, DiscoveryState.FILTERING), filter_done: (DiscoveryState.FILTERING, DiscoveryState.RERANKING), rerank_done: (DiscoveryState.RERANKING, DiscoveryState.EXPLAINING), explain_done: (DiscoveryState.EXPLAINING, DiscoveryState.COMPLETED), timeout: (DiscoveryState.PARSING_INTENT, DiscoveryState.FAILED), no_results: (DiscoveryState.SEARCHING, DiscoveryState.FAILED), } if event not in transitions: raise ValueError(finvalid event: {event}) current, next_state transitions[event] if self ! current: raise ValueError(finvalid transition from {self} on {event}) return next_state工程落地時建議用狀態機管理請求生命周期。分布式環境下每個請求都是一個狀態實例方便追蹤、統計、告警。6. 與其他方案的邊界對比方案定位產品發現能力AI 解釋能力開放程度傳統電商開放 API提供商品搜索接口有但字段分散無各平臺各自定義MCP模型與工具連接協議無垂直場景抽象無開放但需要自己設計這套產品發現協議面向 AI 產品發現的場景協議有核心賣點有包含解釋字段目標開放MCP 和該協議不是替代關系。MCP 更底層負責模型怎么調用工具產品發現協議更上層負責產品發現場景的語義定義。實際工程中可以在 MCP Server 內部實現這套協議的邏輯讓 Agent 通過 MCP 調用。7. AI Agent 接入場景與工程化落地7.1 適合接入的 Agent 類型電商導購 Agent從“找商品”到“對比商品”再到“購買前答疑”。企業采購助手批量詢價、供應商比對、預算約束過濾。本地生活推薦找餐廳、找酒店、找服務門店需要位置和營業時間數據。比價工具 Agent多平臺同一商品的價格、庫存、優惠對比。7.2 統一產品檔案映射層落地這套協議時最臟最累的活是字段映射。建議用一個獨立的映射服務來處理{ source: platform_a, field_mapping: { product_id: spu_id, name: item_title, price: sale_price, brand: brand_name, category: category_path, stock_status: stock_state }, value_mapping: { stock_status: { 1: in_stock, 2: out_of_stock, 3: pre_order } } }這個映射層的好處是平臺側字段變化時只需要改映射配置不需要改上層 Agent 邏輯。考慮到電商平臺接口經常變動這是維護成本的關鍵。7.3 批量任務設計如果 Agent 要做批量商品比對而不是單次查詢建議在上層增加一個批量任務管理器。一個典型的批量任務可能包括輸入一個商品清單每行包含商品名、需要的屬性、目標預算。處理逐條調用產品發現協議接口抽取結構化結果。輸出統一的 MongoDB / CSV / JSON 結果集。import asyncio import json from pathlib import Path async def run_batch_discovery(input_path: str, output_path: str, concurrency: int 5): tasks_input json.loads(Path(input_path).read_text(encodingutf-8)) semaphore asyncio.Semaphore(concurrency) results [] async def process_one(item): async with semaphore: # 這里替換為實際的產品發現協議客戶端調用 result await discovery_client.request( intentrecommend, query_textitem[query], constraintsitem.get(constraints, {}) ) return {item_id: item[id], result: result.model_dump()} results await asyncio.gather(*(process_one(item) for item in tasks_input)) Path(output_path).write_text( json.dumps(results, ensure_asciiFalse, indent2), encodingutf-8 ) if __name__ __main__: asyncio.run(run_batch_discovery(batch_input.json, batch_output.json))批量場景下要特別注意控制并發數避免對數據源接口造成壓力。每個請求單獨記錄耗時和結果狀態。失敗重試要有退避策略建議指數退避。輸出結果中保留request_id便于回查日志。7.4 日志與可觀測性協議層接口的觀測重點和普通接口不同要額外關注約束命中率用戶有 5 個約束最終結果滿足幾個解釋覆蓋率返回的候選結果里有說明的比例。數據源錯誤率平臺接口超時、參數錯誤、字段變更。首次響應時間從用戶提問到返回第一批候選的時間。建議把日志結構化成 JSON集中到日志平臺方便做漏斗分析。8. 安全、隱私與合規邊界這類協議一旦跑起來必然涉及用戶數據、商品數據、商業策略數據部署和接入時必須先解決合規問題。用戶授權邊界讀取用戶位置、歷史訂單、瀏覽記錄前必須獲得明確授權并支持一鍵撤回。商業數據隔離平臺側的價格策略、廣告排序權重屬于商業數據協議接口不能暴露內部排序細節只輸出最終結果。個人信息最小化AI Agent 請求中只傳完成任務所必需的字段不傳手機號、身份證、詳細地址等無關信息。內容安全AI 生成的推薦理由不能包含虛假宣傳、絕對化用語、未經核實的產品功效描述。版權與商標使用品牌名、商品圖、詳情文案時必須確認有授權或屬于合理引用范圍。這里尤其要提醒如果產品發現涉及“換臉、聲音克隆、數字人導購、AI 直播帶貨”等生成式應用素材授權和肖像權確認是硬門檻不能跳過。技術協議解決不了法律風險接入前必須由業務方完成合規評估。9. 推薦實施路線9.1 第一階段最小協議跑通在內部搭建一個最小可用的產品發現協議服務定義 3 個核心接口意圖解析、產品搜索、產品詳情。接入 1 個數據源完成字段映射。用 1 個 AI Agent 場景做端到端驗證。目標讓 Agent 能在 10 秒內返回帶解釋的產品推薦。9.2 第二階段擴展數據源接入第 2、3 個平臺驗證映射層設計是否夠用。增加多平臺聚合排序。增加批量任務能力。目標讓同一個 Agent 無差別調用不同平臺的數據。9.3 第三階段生態開放把協議文檔、SDK、Schema 開放給第三方開發者和商家。增加沙箱環境方便新數據源快速接入。建立認證和配額機制。目標讓“接入新平臺”從數周縮短到數天。10. 常見問題與排查思路問題現象可能原因排查方式解決方案Agent 返回結果缺少品牌字段上游字段映射未配置品牌查看映射配置和數據源原始響應補充field_mapping中的品牌映射多平臺價格單位不一致一個平臺返回元一個返回分檢查價格字段的歸一化邏輯統一在協議層轉換為amount currency結構候選結果不滿足用戶約束重排階段沒有強制過濾約束檢查過濾邏輯執行順序先硬過濾再做模型排序解釋字段為空上游沒有生成解釋的模型能力查日志看解釋生成模塊是否被調用增加基于規則的解釋模板或引入 LLM 生成數據源接口超時平臺限流或網絡問題查看數據源調用耗時和錯誤碼增加超時重試與降級策略批量任務部分失敗個別商品在平臺上找不到匹配查看失敗任務的 item_id單獨記錄失敗原因不阻塞其他任務用戶取消授權后舊數據仍在緩存設置了過長 TTL檢查緩存生命周期授權變更時主動清理緩存11. 最佳實踐與工程建議11.1 協議先行平臺后接不要一開始就追求接入很多平臺。先把協議的消息結構定穩特別是產品檔案、意圖請求、響應結果這三張表。后面每接一個新平臺只是加一套映射配置。11.2 保留一條純規則鏈路AI 生成推薦理由時建議同時保留一條純規則鏈路基于約束條件、商品屬性、價格對比生成固定模板解釋。這樣在 LLM 不可用或響應超時時系統還能降級返回基礎結果。11.3 一次請求一個 request_id從用戶提問到最終推薦全鏈路都帶同一個request_id。排查問題的時候能省大量時間。協議層、Agent 層、平臺適配層都要記錄這個 ID。11.4 建立“約束可滿足性”檢測當用戶約束條件互相沖突時如“2000 以內”和“頂配”協議層最好能識別出無解情況而不是硬返回空結果。可以在響應中增加suggestion字段提示“放寬價格約束”或“降低分辨率要求”。11.5 注意接口的冪等性批量任務和重試機制都要求接口冪等。請求會帶request_id服務端做去重。否則重試時可能產生重復的訂單、重復的推薦記錄。12. 總結與下一步這套協議的思路能落地關鍵不在于定義多少消息字段而在于能否做到“一次接入多平臺復用”。如果協議設計得好AI 應用團隊只需要開發一次意圖解析和推薦話術生成邏輯后續接新平臺只是新增映射配置和適配器。最值得先驗證的兩個功能統一產品檔案的字段映射一個真實平臺的數據能否低成本映射到協議標準結構。解釋生成與重排邏輯返回的結果能否讓用戶感覺“這個 AI 真的懂我要什么”而不是簡單的關鍵詞搜索。最容易踩的坑也在前面提到了字段分散、商業數據隔離、授權管理、解釋生成的穩定性。這四個問題不解決協議設計得再漂亮也跑不起來。后續可以擴展的方向包括商品知識圖譜接入、比價與降價通知、多模態商品搜索、基于用戶反饋的個性化重排。如果你正在做 AI 電商導購、Agent 工具鏈、企業采購助手這類項目建議把“產品發現協議”納入技術選型調研。它未必能直接抄代碼但能幫你把系統邊界和數據結構理清楚。收藏備用后面接新平臺時再回頭看會有參考價值。