這次我們來看一個更偏架構(gòu)和協(xié)議層面的項目An open protocol for AI-mediated product discovery。一句話解釋它想定義一套開放協(xié)議讓 AI Agent 在幫用戶找產(chǎn)品、比較產(chǎn)品、給出購買建議的時候不依賴某個平臺的私有接口而是有一套通用的消息格式、權(quán)限模型和數(shù)據(jù)規(guī)范。對這個方向我的判斷是它比單個推薦算法、某個搜索工具更值得關(guān)注因為它解決的是AI 助手接入電商、本地生活、企業(yè)采購等場景時的“最后一公里協(xié)議問題”。這次文章不聊模型顯存不聊推理優(yōu)化重點是拆解這套協(xié)議的動機、核心設(shè)計、工程落地方法和適合哪些團隊跟進。1. 核心能力速覽能力項說明項目類型面向 AI Agent 與產(chǎn)品發(fā)現(xiàn)場景的開放協(xié)議規(guī)范要解決的問題AI 助手無法統(tǒng)一獲取、比較、決策產(chǎn)品信息的碎片化問題核心能力意圖解析、候選發(fā)現(xiàn)、參數(shù)提取、結(jié)果重排、決策解釋、權(quán)限控制與 MCP 的關(guān)系可看作 MCP 思路在產(chǎn)品發(fā)現(xiàn)場景的垂直延伸用于連接商品/服務(wù)數(shù)據(jù)源適用平臺電商平臺、本地生活服務(wù)、企業(yè)采購系統(tǒng)、線下門店商品庫是否支持 API協(xié)議定義的是接口交互規(guī)范工程落地時提供 SDK / HTTP / gRPC 實現(xiàn)是否支持批量任務(wù)可在代理層設(shè)計批處理任務(wù)例如批量商品比對、批量報價更新啟動方式非獨立應(yīng)用需要以 SDK 或網(wǎng)關(guān)服務(wù)方式集成適合讀者AI 應(yīng)用開發(fā)者、推薦系統(tǒng)工程師、電商平臺架構(gòu)師、Agent 平臺設(shè)計者需要強調(diào)這更多是一份協(xié)議設(shè)計愿景與技術(shù)規(guī)范不是某個可以直接啟動的 WebUI 項目。進入正文前先把邊界說清楚。2. 為什么需要一套 AI 產(chǎn)品發(fā)現(xiàn)協(xié)議2.1 現(xiàn)在 AI 找產(chǎn)品是“拼接口”過去一年大模型讓“幫用戶找產(chǎn)品”這件事變得可用但工程上依舊很痛苦。一個 AI 購物助手要完成一次完整推薦通常需要從用戶對話里提取品牌、價格區(qū)間、品類、使用場景調(diào)用電商平臺的搜索接口拿到商品列表后做過濾、排序再把結(jié)果轉(zhuǎn)成自然語言推薦話術(shù)。聽起來不復(fù)雜實際上每一個環(huán)節(jié)都是私有實現(xiàn)。每家平臺的商品字段不統(tǒng)一有的叫title有的叫itemName有的叫product_title庫存狀態(tài)、價格字段、優(yōu)惠信息、配送范圍的表達更是千差萬別。AI Agent 每接入一個新平臺就要重新寫一遍適配層。這是典型的接口碎片化問題。MCPModel Context Protocol解決了模型與工具之間的連接問題但產(chǎn)品發(fā)現(xiàn)場景還需要一層更垂直的協(xié)議來統(tǒng)一“產(chǎn)品意圖”“候選結(jié)果”“決策解釋”這些業(yè)務(wù)概念。2.2 用戶要的不是鏈接是決策支持傳統(tǒng)搜索框給用戶一堆結(jié)果鏈接點擊后自己判斷。AI 產(chǎn)品發(fā)現(xiàn)則不同用戶期望的是“2000 元以內(nèi)適合編程的 4K 顯示器有哪些”“通勤單程 40 分鐘預(yù)算 15 萬幫我選一輛電車?！薄跋轮苋ズ贾莩霾?3 天幫我找公司附近評分最高的酒店?！边@些請求背后是多條件約束下的產(chǎn)品發(fā)現(xiàn)需要協(xié)議層支持結(jié)構(gòu)化意圖、候選集合并、屬性過濾和可解釋的排序結(jié)果。而現(xiàn)有平臺的開放接口主要面向“關(guān)鍵詞搜索”沒有為 AI 決策設(shè)計。2.3 關(guān)鍵詞與協(xié)議的核心定位從標(biāo)題可以看出這套協(xié)議強調(diào)兩個關(guān)鍵詞open protocol開放協(xié)議不綁定單一平臺、單一模型任何數(shù)據(jù)提供方都可以按規(guī)范暴露產(chǎn)品發(fā)現(xiàn)能力。AI-mediatedAI 中介由 AI 作為用戶與產(chǎn)品之間的中介層協(xié)議設(shè)計要圍繞模型的意圖理解和生成能力展開。換句話說這不是一個搜索引擎協(xié)議也不是一個電商 API 規(guī)范而是一套“AI 作為對話式產(chǎn)品發(fā)現(xiàn)入口”的場景協(xié)議。3. 協(xié)議要覆蓋的關(guān)鍵能力3.1 意圖語義與約束提取傳統(tǒng)搜索用關(guān)鍵詞AI 產(chǎn)品發(fā)現(xiàn)要支持自然語言請求的結(jié)構(gòu)化轉(zhuǎn)換。協(xié)議需要定義一套統(tǒng)一的意圖消息結(jié)構(gòu)至少包含請求意圖類型查詢、比較、推薦、解釋、購買前驗證等。約束條件集合品牌、價格、尺寸、顏色、評分、發(fā)貨時效。用戶上下文場景、預(yù)算、歷史偏好需要用戶授權(quán)。排序偏好價格優(yōu)先、評分優(yōu)先、距離優(yōu)先、綜合推薦。這塊是協(xié)議最核心的抽象。如果沒有統(tǒng)一的意圖格式AI Agent 接每個平臺都要重寫一套意圖解析邏輯。3.2 候選產(chǎn)品發(fā)現(xiàn)協(xié)議需要定義產(chǎn)品發(fā)現(xiàn)的請求與響應(yīng)格式包括數(shù)據(jù)源選擇單平臺搜索還是多平臺聚合。分頁與游標(biāo)AI Agent 可能需要多輪翻頁。結(jié)果歸一化不同平臺的商品必須映射到統(tǒng)一產(chǎn)品檔案。可用性與庫存實時庫存、預(yù)售、區(qū)域限購的表示。如果沒有統(tǒng)一響應(yīng)結(jié)構(gòu)多平臺聚合就只能靠爬蟲和接口逆向既不穩(wěn)定也有合規(guī)風(fēng)險。3.3 結(jié)果重排與解釋AI 推薦產(chǎn)品不能只丟列表還要說明“為什么推薦這個”。協(xié)議應(yīng)包含重排參數(shù)用戶顯式約束、模型推薦分?jǐn)?shù)、平臺排序、商業(yè)策略如廣告標(biāo)注。解釋字段每個候選結(jié)果需要附帶可讀的推薦理由。對比維度多產(chǎn)品對比時的屬性差異高亮。協(xié)議層面如果支持“解釋”字段AI 應(yīng)用就可以直接生成帶理由的推薦話術(shù)而不是事后為每個商品編理由。3.4 權(quán)限與用戶授權(quán)AI 訪問用戶購物歷史、位置、企業(yè)采購預(yù)算等信息涉及敏感數(shù)據(jù)。協(xié)議需要設(shè)計權(quán)限層例如用戶顯式授權(quán)的數(shù)據(jù)范圍。臨時令牌與短時有效期。用戶取消授權(quán)的機制。商業(yè)數(shù)據(jù)與個人數(shù)據(jù)的分離。沒有權(quán)限設(shè)計這類協(xié)議很難被嚴(yán)肅平臺采用。4. 協(xié)議消息設(shè)計示例協(xié)議不能只停留在概念層下面給一組簡化的消息結(jié)構(gòu)示例用于說明“統(tǒng)一產(chǎn)品檔案”和“意圖請求”應(yīng)該如何設(shè)計。實際項目落地時可以按這套思路擴展 JSON Schema。4.1 產(chǎn)品檔案對象{ product: { product_id: platform_a:sku_90831, source: platform_a, name: 某品牌 4K 27 英寸顯示器, brand: 某品牌, category: [顯示器, 辦公設(shè)備], 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 } } }這個結(jié)構(gòu)解決的是字段歸一化問題。無論底層平臺用什么字段名協(xié)議層統(tǒng)一用name、price、attributes這類標(biāo)準(zhǔn)字段暴露給上層 Agent。4.2 發(fā)現(xiàn)請求{ request_id: req_20250601_001, intent: recommend, query_text: 2000元以內(nèi)適合編程的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] } }從這個請求結(jié)構(gòu)可以看出協(xié)議層把“自然語言”和“結(jié)構(gòu)化約束”同時保留。query_text是為大模型準(zhǔn)備的constraints是為檢索系統(tǒng)準(zhǔn)備的兩者互補。4.3 發(fā)現(xiàn)響應(yīng){ 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 元符合預(yù)算約束。, 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 } }響應(yīng)里最值得借鑒的是explanation和ranking_signals。有了這兩個字段AI Agent 的下游任務(wù)就會簡單很多直接基于explanation生成推薦話術(shù)同時可以判斷結(jié)果是否被商業(yè)策略干擾。5. 關(guān)鍵流程設(shè)計5.1 一次完整的產(chǎn)品發(fā)現(xiàn)流程用戶輸入自然語言 ↓ 意圖解析與約束提取 ↓ 數(shù)據(jù)源路由單平臺/多平臺 ↓ 候選產(chǎn)品檢索 ↓ 結(jié)果歸一化與屬性映射 ↓ 重排與過濾約束校驗 ↓ 解釋生成與結(jié)果返回 ↓ 用戶反饋采納/放棄/追問這個流程本質(zhì)上把“對話式產(chǎn)品推薦”拆成了可以各自獨立迭代的模塊。協(xié)議要做的就是把每個環(huán)節(jié)之間的數(shù)據(jù)結(jié)構(gòu)固定下來讓不同團隊可以獨立開發(fā)、聯(lián)動測試。5.2 狀態(tài)機設(shè)計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工程落地時建議用狀態(tài)機管理請求生命周期。分布式環(huán)境下每個請求都是一個狀態(tài)實例方便追蹤、統(tǒng)計、告警。6. 與其他方案的邊界對比方案定位產(chǎn)品發(fā)現(xiàn)能力AI 解釋能力開放程度傳統(tǒng)電商開放 API提供商品搜索接口有但字段分散無各平臺各自定義MCP模型與工具連接協(xié)議無垂直場景抽象無開放但需要自己設(shè)計這套產(chǎn)品發(fā)現(xiàn)協(xié)議面向 AI 產(chǎn)品發(fā)現(xiàn)的場景協(xié)議有核心賣點有包含解釋字段目標(biāo)開放MCP 和該協(xié)議不是替代關(guān)系。MCP 更底層負責(zé)模型怎么調(diào)用工具產(chǎn)品發(fā)現(xiàn)協(xié)議更上層負責(zé)產(chǎn)品發(fā)現(xiàn)場景的語義定義。實際工程中可以在 MCP Server 內(nèi)部實現(xiàn)這套協(xié)議的邏輯讓 Agent 通過 MCP 調(diào)用。7. AI Agent 接入場景與工程化落地7.1 適合接入的 Agent 類型電商導(dǎo)購 Agent從“找商品”到“對比商品”再到“購買前答疑”。企業(yè)采購助手批量詢價、供應(yīng)商比對、預(yù)算約束過濾。本地生活推薦找餐廳、找酒店、找服務(wù)門店需要位置和營業(yè)時間數(shù)據(jù)。比價工具 Agent多平臺同一商品的價格、庫存、優(yōu)惠對比。7.2 統(tǒng)一產(chǎn)品檔案映射層落地這套協(xié)議時最臟最累的活是字段映射。建議用一個獨立的映射服務(wù)來處理{ 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 } } }這個映射層的好處是平臺側(cè)字段變化時只需要改映射配置不需要改上層 Agent 邏輯?？紤]到電商平臺接口經(jīng)常變動這是維護成本的關(guān)鍵。7.3 批量任務(wù)設(shè)計如果 Agent 要做批量商品比對而不是單次查詢建議在上層增加一個批量任務(wù)管理器。一個典型的批量任務(wù)可能包括輸入一個商品清單每行包含商品名、需要的屬性、目標(biāo)預(yù)算。處理逐條調(diào)用產(chǎn)品發(fā)現(xiàn)協(xié)議接口抽取結(jié)構(gòu)化結(jié)果。輸出統(tǒng)一的 MongoDB / CSV / JSON 結(jié)果集。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: # 這里替換為實際的產(chǎn)品發(fā)現(xiàn)協(xié)議客戶端調(diào)用 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))批量場景下要特別注意控制并發(fā)數(shù)避免對數(shù)據(jù)源接口造成壓力。每個請求單獨記錄耗時和結(jié)果狀態(tài)。失敗重試要有退避策略建議指數(shù)退避。輸出結(jié)果中保留request_id便于回查日志。7.4 日志與可觀測性協(xié)議層接口的觀測重點和普通接口不同要額外關(guān)注約束命中率用戶有 5 個約束最終結(jié)果滿足幾個解釋覆蓋率返回的候選結(jié)果里有說明的比例。數(shù)據(jù)源錯誤率平臺接口超時、參數(shù)錯誤、字段變更。首次響應(yīng)時間從用戶提問到返回第一批候選的時間。建議把日志結(jié)構(gòu)化成 JSON集中到日志平臺方便做漏斗分析。8. 安全、隱私與合規(guī)邊界這類協(xié)議一旦跑起來必然涉及用戶數(shù)據(jù)、商品數(shù)據(jù)、商業(yè)策略數(shù)據(jù)部署和接入時必須先解決合規(guī)問題。用戶授權(quán)邊界讀取用戶位置、歷史訂單、瀏覽記錄前必須獲得明確授權(quán)并支持一鍵撤回。商業(yè)數(shù)據(jù)隔離平臺側(cè)的價格策略、廣告排序權(quán)重屬于商業(yè)數(shù)據(jù)協(xié)議接口不能暴露內(nèi)部排序細節(jié)只輸出最終結(jié)果。個人信息最小化AI Agent 請求中只傳完成任務(wù)所必需的字段不傳手機號、身份證、詳細地址等無關(guān)信息。內(nèi)容安全AI 生成的推薦理由不能包含虛假宣傳、絕對化用語、未經(jīng)核實的產(chǎn)品功效描述。版權(quán)與商標(biāo)使用品牌名、商品圖、詳情文案時必須確認有授權(quán)或?qū)儆诤侠硪梅秶?。這里尤其要提醒如果產(chǎn)品發(fā)現(xiàn)涉及“換臉、聲音克隆、數(shù)字人導(dǎo)購、AI 直播帶貨”等生成式應(yīng)用素材授權(quán)和肖像權(quán)確認是硬門檻不能跳過。技術(shù)協(xié)議解決不了法律風(fēng)險接入前必須由業(yè)務(wù)方完成合規(guī)評估。9. 推薦實施路線9.1 第一階段最小協(xié)議跑通在內(nèi)部搭建一個最小可用的產(chǎn)品發(fā)現(xiàn)協(xié)議服務(wù)定義 3 個核心接口意圖解析、產(chǎn)品搜索、產(chǎn)品詳情。接入 1 個數(shù)據(jù)源完成字段映射。用 1 個 AI Agent 場景做端到端驗證。目標(biāo)讓 Agent 能在 10 秒內(nèi)返回帶解釋的產(chǎn)品推薦。9.2 第二階段擴展數(shù)據(jù)源接入第 2、3 個平臺驗證映射層設(shè)計是否夠用。增加多平臺聚合排序。增加批量任務(wù)能力。目標(biāo)讓同一個 Agent 無差別調(diào)用不同平臺的數(shù)據(jù)。9.3 第三階段生態(tài)開放把協(xié)議文檔、SDK、Schema 開放給第三方開發(fā)者和商家。增加沙箱環(huán)境方便新數(shù)據(jù)源快速接入。建立認證和配額機制。目標(biāo)讓“接入新平臺”從數(shù)周縮短到數(shù)天。10. 常見問題與排查思路問題現(xiàn)象可能原因排查方式解決方案Agent 返回結(jié)果缺少品牌字段上游字段映射未配置品牌查看映射配置和數(shù)據(jù)源原始響應(yīng)補充field_mapping中的品牌映射多平臺價格單位不一致一個平臺返回元一個返回分檢查價格字段的歸一化邏輯統(tǒng)一在協(xié)議層轉(zhuǎn)換為amount currency結(jié)構(gòu)候選結(jié)果不滿足用戶約束重排階段沒有強制過濾約束檢查過濾邏輯執(zhí)行順序先硬過濾再做模型排序解釋字段為空上游沒有生成解釋的模型能力查日志看解釋生成模塊是否被調(diào)用增加基于規(guī)則的解釋模板或引入 LLM 生成數(shù)據(jù)源接口超時平臺限流或網(wǎng)絡(luò)問題查看數(shù)據(jù)源調(diào)用耗時和錯誤碼增加超時重試與降級策略批量任務(wù)部分失敗個別商品在平臺上找不到匹配查看失敗任務(wù)的 item_id單獨記錄失敗原因不阻塞其他任務(wù)用戶取消授權(quán)后舊數(shù)據(jù)仍在緩存設(shè)置了過長 TTL檢查緩存生命周期授權(quán)變更時主動清理緩存11. 最佳實踐與工程建議11.1 協(xié)議先行平臺后接不要一開始就追求接入很多平臺。先把協(xié)議的消息結(jié)構(gòu)定穩(wěn)特別是產(chǎn)品檔案、意圖請求、響應(yīng)結(jié)果這三張表。后面每接一個新平臺只是加一套映射配置。11.2 保留一條純規(guī)則鏈路AI 生成推薦理由時建議同時保留一條純規(guī)則鏈路基于約束條件、商品屬性、價格對比生成固定模板解釋。這樣在 LLM 不可用或響應(yīng)超時時系統(tǒng)還能降級返回基礎(chǔ)結(jié)果。11.3 一次請求一個 request_id從用戶提問到最終推薦全鏈路都帶同一個request_id。排查問題的時候能省大量時間。協(xié)議層、Agent 層、平臺適配層都要記錄這個 ID。11.4 建立“約束可滿足性”檢測當(dāng)用戶約束條件互相沖突時如“2000 以內(nèi)”和“頂配”協(xié)議層最好能識別出無解情況而不是硬返回空結(jié)果。可以在響應(yīng)中增加suggestion字段提示“放寬價格約束”或“降低分辨率要求”。11.5 注意接口的冪等性批量任務(wù)和重試機制都要求接口冪等。請求會帶request_id服務(wù)端做去重。否則重試時可能產(chǎn)生重復(fù)的訂單、重復(fù)的推薦記錄。12. 總結(jié)與下一步這套協(xié)議的思路能落地關(guān)鍵不在于定義多少消息字段而在于能否做到“一次接入多平臺復(fù)用”。如果協(xié)議設(shè)計得好AI 應(yīng)用團隊只需要開發(fā)一次意圖解析和推薦話術(shù)生成邏輯后續(xù)接新平臺只是新增映射配置和適配器。最值得先驗證的兩個功能統(tǒng)一產(chǎn)品檔案的字段映射一個真實平臺的數(shù)據(jù)能否低成本映射到協(xié)議標(biāo)準(zhǔn)結(jié)構(gòu)。解釋生成與重排邏輯返回的結(jié)果能否讓用戶感覺“這個 AI 真的懂我要什么”而不是簡單的關(guān)鍵詞搜索。最容易踩的坑也在前面提到了字段分散、商業(yè)數(shù)據(jù)隔離、授權(quán)管理、解釋生成的穩(wěn)定性。這四個問題不解決協(xié)議設(shè)計得再漂亮也跑不起來。后續(xù)可以擴展的方向包括商品知識圖譜接入、比價與降價通知、多模態(tài)商品搜索、基于用戶反饋的個性化重排。如果你正在做 AI 電商導(dǎo)購、Agent 工具鏈、企業(yè)采購助手這類項目建議把“產(chǎn)品發(fā)現(xiàn)協(xié)議”納入技術(shù)選型調(diào)研。它未必能直接抄代碼但能幫你把系統(tǒng)邊界和數(shù)據(jù)結(jié)構(gòu)理清楚。收藏備用后面接新平臺時再回頭看會有參考價值。