這次我們來看一個很有意思的協議提案Shelf Protocol作者把它直接定義為 Robots.txt for Commerce也就是“商業版 robots.txt”。這個名字起得很準確因為它的目標不是再做一套通用爬蟲協議而是把 robots.txt 的思路遷移到電商和商業數據場景站點所有者可以通過一份機器可讀的策略文件聲明自己的商品數據、價格、庫存、優惠信息允許誰抓取、以什么目的使用、是否需要授權。如果你在做電商平臺、比價工具、AI 訓練數據采集、第三方數據服務或爬蟲治理這個項目值得仔細看一遍。它不是本地部署那類模型工具不挑顯卡、不占顯存本質上是一個標準提案和基礎設施層的約定。本文會從協議動機、與 robots.txt 的對比、部署思路、驗證方法、自動化接入、性能觀察和常見排查幾個方向展開盡量把“能不能用、怎么用、怎么驗證”講清楚。1. 核心能力速覽Shelf Protocol 目前屬于社區提案和標準討論階段從 Hacker News 上的展示內容和命名方式來看它的核心能力可以整理成下面這張表能力項說明協議類型面向商業數據的訪問控制與授權聲明協議核心定位Robots.txt for Commerce解決電商數據抓取與使用授權問題主要功能聲明商品價格、庫存、優惠、商品描述等數據的使用條件適用對象電商平臺、比價站點、價格監測服務、AI 數據采集方、數據治理平臺部署位置站點根目錄、.well-known目錄、HTTP 響應頭或 DNS 記錄具體以項目文檔為準數據格式預計為 JSON 或 YAML 一類機器可讀格式需要按實際項目確認硬件要求無特殊硬件要求普通 Web 服務器和 CDN 邊緣節點即可承載是否支持一鍵啟動不適用屬于 Web 協議基礎設施不需要本地安裝是否支持 API協議文件本身可作為機器可讀端點被調用是否支持批量任務適合對大量站點做批量策略采集和合規校驗開源狀態社區提案項目建議以倉庫 README 和討論帖為準從材料來看這個項目的重點不是“阻止所有爬蟲”而是建立一套“商業數據使用的君子協定”和可執行聲明。這里需要先明確一個邊界Shelf Protocol 解決的是“聲明問題”不是“防護問題”。它告訴數據使用方哪些行為被允許、哪些行為需要授權但它本身不是一個 WAF不能物理阻斷惡意抓取。實際落地時它需要配合訪問控制、反爬策略、法律條款和審計機制一起使用。2. 適用場景與使用邊界2.1 適合誰用Shelf Protocol 最適合下面幾類團隊角色典型訴求Shelf Protocol 能做什么電商平臺不希望比價插件直接抓價格和庫存在協議文件中聲明價格數據是否允許抓取、是否允許轉售品牌方管控渠道價格透明度統一聲明商品數據使用條款比價工具需要合法合規地獲取商品信息通過協議文件判斷是否可以直接抓取、是否需要申請授權AI 數據服務商需要大規模商品數據做訓練自動識別數據使用邊界規避侵權風險合規與安全團隊建立數據訪問審計基線將協議文件作為企業級合規審查的組成部分2.2 能解決什么問題過去電商網站只有兩個選擇要么全開放讓所有爬蟲隨便抓要么全封禁導致正常的比價、搜索、數據分析渠道也受影響。Shelf Protocol 試圖提供一個中間層你可以明確寫出“搜索引擎可以索引商品詳情頁”也可以寫“價格和庫存只允許授權合作伙伴調用”還可以寫“AI 公司需要單獨申請數據許可”。這套機制一旦被爬蟲工具、瀏覽器插件、數據平臺和 AI 公司遵守就能從源頭降低數據糾紛。2.3 不適合什么場景需要注意Shelf Protocol 不適合作為唯一的反爬手段。理由很簡單它依賴調用方主動讀取和遵守。遇到不遵守協議的抓取者協議文件本身起不到攔截效果。需要防護的場景仍然要配合 IP 策略、訪問頻率控制、滑塊驗證、接口簽名、數據加密等手段。另外Shelf Protocol 也不是法律文書。它的表達能力再強也不能替代正式的數據授權協議、隱私政策和條款。2.4 合規與安全邊界涉及商品價格、庫存、用戶評價、銷量等數據時必須區分數據是否屬于個人信息、是否屬于商業秘密、是否受反壟斷約束。商業數據的使用邊界不能只靠一個協議文件解決需要由法務和合規團隊共同確定策略。如果協議聲明被用作排除競爭的借口或者涉及價格協同可能引發反壟斷合規風險。這類問題要特別謹慎不要用技術聲明的形式掩蓋商業策略上的合規缺陷。涉及用戶行為數據比如用戶點擊、購買記錄時更要遵守個人信息保護相關法規不能通過協議文件繞開用戶授權。3. 協議設計核心Robots.txt for Commerce 如何解決數據授權問題要理解 Shelf Protocol最直接的方式是把 robots.txt 的機制搬過來看。傳統 robots.txt 的規則很簡單在站點根目錄放一個文本文件告訴爬蟲哪些路徑可以抓、哪些路徑不能抓。它的工作模式是聲明式的站點說了算爬蟲自愿遵守。Shelf Protocol 本質上延續了這個邏輯但擴展了三個維度身份、資源、條件。維度robots.txtShelf Protocol 的擴展方向身份靠 User-agent 區分爬蟲類型可能擴展為組織身份、用途身份比如“AI 訓練爬蟲”“比價插件”“學術研究”資源用路徑表達 URL 范圍可能直接面向商業數據對象比如價格、庫存、促銷條件只有 allow 和 disallow可能支持“允許抓取但需要署名”“允許查看但不允許轉售”“需要付費授權”等條件用一句話概括robots.txt 解決的是 Web 資源索引邊界Shelf Protocol 解決的是商業數據使用邊界。3.1 常見能力模塊從“商業數據授權聲明”這個目標反推一個成熟的 Shelf Protocol 實現通常會包含以下模塊權限聲明這是最核心的模塊。站點聲明誰可以訪問哪些商業數據。可以按爬蟲身份區分也可以按訪問目的區分。典型聲明包括“允許搜索引擎索引商品標題和描述”“禁止第三方工具抓取價格和庫存”。使用條件權限聲明只說明“能不能拿”使用條件說明“拿了之后能做什么”。常見條件包括非商業用途允許、商業用途需要署名、禁止整合轉售、禁止用于模型訓練、需要先申請 API Token。配額與頻率真實場景中同一份數據對不同消費者的開放頻率不同。Shelf Protocol 可能會支持聲明訪問頻率上限和批量抓取限制避免正常授權和數據濫用之間的邊界模糊。歸屬要求站點所有者可以要求數據使用方在展示數據時附上來源鏈接或品牌標識。這和學術引用的邏輯類似也是很多比價網站與品牌方爭議的焦點。聯系與授權通道聲明不能只告訴對方“不允許”還得告訴對方“如果你有正當需求應該去哪里申請”。所以協議中大概率會包含授權聯系入口比如授權 API 地址、商務聯系人、申請表單地址。3.2 與 robots.txt 的定位關系一個常見誤區是Shelf Protocol 要取代 robots.txt。實際上不需要。兩者定位不同robots.txt 控制的是“搜索引擎爬蟲對 Web 資源的索引行為”核心是路徑級控制。Shelf Protocol 控制的是“商業數據的使用與授權”核心是數據級控制。一個合理的技術棧是站點同時部署 robots.txt 和 Shelf Protocol。robots.txt 繼續管搜索引擎爬蟲Shelf Protocol 管商業數據抓取方和 AI 數據采集方。兩者形成互補關系而不是相互替代。3.3 關鍵機制機器可讀與人工可讀協議要能落地必須有非常好的機器可讀性。爬蟲工具和數據處理平臺在請求商品頁面之前先讀取站點發布的協議文件然后根據規則決定是否繼續、是否需要走授權流程。同時站點運營人員也需要能看懂。所以協議文件的結構應該簡潔字段命名要直觀。從 Robots.txt for Commerce 這個類比看Shelf Protocol 的目標就是讓“不懂代碼的運營”也能理解“哪些數據被允許抓取”。4. 環境準備與部署思路Shelf Protocol 不是本地軟件不需要安裝依賴也不需要 GPU。它更像一份約定你需要在站點服務器上提供一個可訪問、可解析的策略文件。下面給出通用的部署思路具體路徑和字段以實際項目文檔為準。4.1 前置條件準備項說明域名需要在主域名或指定子域上部署協議文件Web 服務器Nginx、Apache、靜態托管服務或 CDN 邊緣函數均可DNS 控制臺如果需要通過 TXT 記錄做驗證需要域名解析權限HTTPS建議強制開啟協議文件涉及數據授權明文傳輸不合理測試工具curl、瀏覽器開發者工具、Postman 或自寫腳本4.2 策略文件生成協議文件的核心是生成一份結構化的策略聲明。這里給一個通用參考結構字段命名不代表 Shelf Protocol 官方規范僅用于演示如何組織“權限、條件、聯系信息”{ protocol: shelf-protocol, version: 1.0, domain: example.com, issued_at: 2025-01-01T00:00:00Z, policy: { search_engine: { allow: true, path: [/products*] }, price_comparison: { allow: false, note: 需要授權后開放 }, ai_training: { allow: false, note: 如需獲取數據請通過下方 address 申請 }, authorized_partner: { allow: true, requires_token: true, token_endpoint: https://example.com/api/token } }, usage_terms: { attribution_required: true, resale_forbidden: true, rate_limit_per_minute: 60 }, contact: { authorization_url: https://example.com/data-license, email: data-accessexample.com } }實際字段需要按項目文檔確認。上面這個結構只是用于說明“商業數據授權聲明”可以包含哪些信息。4.3 Nginx 部署示例假設你已經生成好協議文件放在站點服務器的/var/www/example.com/.well-known/shelf.json可以通過 Nginx 直接暴露server { listen 443 ssl; server_name example.com; location /.well-known/shelf.json { alias /var/www/example.com/.well-known/shelf.json; default_type application/json; add_header Cache-Control public, max-age3600; add_header X-Content-Type-Options nosniff; } location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }這個配置做了三件事將協議文件以application/json類型返回。設置 1 小時緩存避免每次被爬蟲請求都回源。開啟nosniff避免瀏覽器或客戶端對內容類型做錯誤判斷。如果你的站點托管在純靜態服務上直接把文件傳到對應目錄即可不需要額外服務端配置。4.4 邊緣函數動態生成如果協議內容會動態變化也可以在 Cloudflare Workers、邊緣函數上動態生成。這里給一個通用偽代碼export default { async fetch(request, env, ctx) { const url new URL(request.url); if (url.pathname /.well-known/shelf.json) { const policy await getShelfPolicy(); // 從 KV 或數據庫讀取 return new Response(JSON.stringify(policy), { headers: { Content-Type: application/json } }); } return new Response(Not Found, { status: 404 }); } };動態生成的好處是可以按請求方身份或 IP 返回不同策略版本也可以隨時調整授權條件不需要改服務器文件。4.5 DNS 驗證與聲明從協議標準化角度來看DNS TXT 記錄也是常見驗證方式。它可以用于證明域名所有者認可該協議也可以聲明協議文件當前位置# 示例在 DNS 控制臺添加 TXT 記錄 # 主機記錄_shelf # 記錄值Shelf-Protocol v1.0; policyhttps://example.com/.well-known/shelf.json不同 DNS 服務商的操作方式不同但原理一致通過 DNS 驗證讓數據使用方先確認協議真實性再讀取具體策略。5. 功能測試與效果驗證部署完成后要驗證協議文件的可用性和正確性。下面給出一套通用驗證流程。5.1 測試目標協議文件是否可以公開訪問。返回內容類型是否正確。JSON 結構是否能被正常解析。爬蟲客戶端讀取后能否做出正確判斷。訪問頻率和緩存是否符合預期。5.2 用 curl 驗證訪問# 請求協議文件輸出 HTTP 狀態頭和響應體 curl -I https://example.com/.well-known/shelf.json # 輸出完整響應 curl https://example.com/.well-known/shelf.json預期結果HTTP 狀態碼為 200。Content-Type為application/json。響應體包含完整的策略聲明結構。如果返回 404檢查文件路徑、Nginx alias 路徑、靜態托管目錄是否正確。 如果返回 403檢查目錄權限或 WAF 規則是否誤攔截。5.3 用 Python 解析并輸出決策這里模擬一個爬蟲工具讀取協議文件后判斷自己是否有權限訪問商品價格數據。腳本結構是通用示例實際字段需要按項目文檔調整import json import requests # 1. 讀取協議文件 url https://example.com/.well-known/shelf.json resp requests.get(url, timeout10) if resp.status_code ! 200: print(f協議文件獲取失敗HTTP {resp.status_code}) exit(1) # 2. 解析 JSON try: shelf resp.json() except json.JSONDecodeError: print(協議文件不是合法 JSON) exit(1) # 3. 按調用方身份查找策略 # 這里只是通用示例實際需要按項目字段調整 client_type price_comparison policy shelf.get(policy, {}).get(client_type) if policy is None: print(未找到當前調用方策略默認拒絕訪問) exit(0) if policy.get(allow) is True: print(允許抓取商品價格數據) if policy.get(requires_token): print(需要先申請訪問 Token) else: print(禁止抓取商品價格數據請聯系授權入口申請) auth_url shelf.get(contact, {}).get(authorization_url) print(f授權申請地址{auth_url})判斷成功的標準能穩定獲取協議文件。JSON 解析無異常。不同調用方身份返回不同策略結果。未知身份默認拒絕而不是默認放行。5.4 模擬多站點批量校驗如果你做的是數據合規平臺需要批量檢查多個電商站點是否部署了協議文件。可以用腳本批量處理import json import requests from concurrent.futures import ThreadPoolExecutor domains [ https://example1.com, https://example2.com, https://example3.com, ] def check_shelf(domain): paths [/.well-known/shelf.json, /shelf.txt] for path in paths: url domain path try: resp requests.get(url, timeout10) if resp.status_code 200: return {domain: domain, status: ok, content_type: resp.headers.get(Content-Type)} except requests.RequestException: continue return {domain: domain, status: not_found} with ThreadPoolExecutor(max_workers5) as executor: results list(executor.map(check_shelf, domains)) for result in results: print(json.dumps(result, ensure_asciiFalse))5.5 失敗場景判斷現象可能原因排查方式返回 404文件路徑不對檢查目錄結構和 Nginx alias返回 403目錄權限或 WAF 攔截檢查服務日志和安全策略Content-Type 錯誤服務器默認類型不是 JSON顯式設置 default_typeJSON 解析失敗編輯器保存了 BOM 頭或格式錯誤用 JSON 校驗工具檢查爬蟲不遵守協議協議還在推廣階段覆蓋率不夠配合 robots.txt 和訪問控制使用6. 自動化接入與協議文件調用的實踐Shelf Protocol 不提供傳統意義上的“本地啟動”但它提供的協議文件本身就是機器可讀端點。可以把“讀取協議文件—解析策略—執行決策”當成一個標準化接口流程接到自己的數據采集系統、合規平臺或瀏覽器插件中。6.1 將協議文件作為接口使用協議文件本質上是一種輕量級接口請求路徑固定返回格式固定狀態碼語義清晰。和傳統 API 相比它有這些特點特點說明公開只讀通常不需要鑒權即可讀取適合前置判斷標準化路徑便于成為行業默認約定低消耗靜態文件或邊緣函數資源開銷小可緩存數據變化不頻繁時緩存友好6.2 curl 調用示例# 讀取協議文件并把響應體保存到本地 curl -s https://example.com/.well-known/shelf.json -o shelf.json # 請求時帶 User-Agent便于站點識別調用方身份 curl -s https://example.com/.well-known/shelf.json \ -H User-Agent: MyDataCrawler/1.0 (contactexample.com)6.3 Python 批量接入示例面對數千個電商域名的接入場景可以先通過協議文件判斷授權狀態再執行抓取。這里給出一個通用任務隊列示例import json import requests import time import csv # 目標站點列表 targets [ {domain: https://example1.com, client_type: ai_training}, {domain: https://example2.com, client_type: price_comparison}, ] def get_policy_status(domain, client_type): shelf_url f{domain}/.well-known/shelf.json try: resp requests.get(shelf_url, timeout10) if resp.status_code ! 200: return shelf_missing policy resp.json().get(policy, {}).get(client_type, {}) if policy.get(allow): return allowed return denied except Exception: return error results [] for t in targets: status get_policy_status(t[domain], t[client_type]) results.append({domain: t[domain], client_type: t[client_type], status: status}) time.sleep(0.3) with open(shelf_check_result.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[domain, client_type, status]) writer.writeheader() writer.writerows(results) print(results)6.4 與數據治理平臺集成更工程化的做法是把 Shelf Protocol 校驗納入數據采集環節數據采集任務啟動前先請求目標站點的協議文件。解析策略判斷當前任務類型是否被允許。如果允許記錄本次采集依據的協議版本。如果拒絕任務進入審核隊列由人工或法務判斷是否走授權流程。所有判斷結果落庫留作合規審計。通過這套流程數據團隊就不再是“先抓再說”而是“先查協議、再抓數據、全程留痕”。7. 資源占用與性能觀察Shelf Protocol 不是重協議性能壓力理論上很小但真實場景中的資源占用仍然要看部署方式。7.1 靜態文件部署開銷如果協議文件是純靜態 JSON文件大小通常只有幾 KB 到幾十 KB。對 Web 服務器來說這個開銷可以忽略不計。實際觀察重點放在指標觀察方式正常范圍參考響應時間curl 觀察 Time Total靜態文件應穩定在幾十毫秒內文件大小LS 或響應體大小幾 KB 到幾十 KBHTTP 狀態碼訪問日志統計200 占絕大多數緩存命中率CDN 控制臺或日志越高越好7.2 邊緣函數部署開銷如果使用邊緣函數動態生成協議文件資源占用取決于每次請求要執行的計算和 IO。建議把動態內容盡量做成 KV 緩存避免每次回源數據庫。7.3 高峰流量與突發請求當比價插件、AI 爬蟲大規模上線時協議文件的請求量會同步上升。這時要重點觀察CDN 緩存命中率是否下降。源站是否出現 5xx 錯誤。協議文件響應時間是否劣化。一個穩妥的策略是給協議文件設置較長的緩存時間比如 1 小時到 24 小時。協議策略本身不會頻繁變化過度實時反而不利于生態穩定。7.4 端口與進程管理Shelf Protocol 不涉及本地服務因此不需要關注端口占用和進程殘留。只需要注意 HTTPS 證書是否有效、CDN 節點是否覆蓋主流區域即可。8. 常見問題與排查方法問題現象可能原因排查方式解決方案請求協議文件返回 404文件路徑錯誤或未部署檢查服務器文件目錄、Nginx 配置將文件放在正確路徑并重載配置返回 403服務器權限或 WAF 規則誤攔截檢查 Nginx/Apache 錯誤日志、WAF 規則調整目錄權限添加放行規則返回 Content-Type 是 text/html服務器未識別 JSON 文件類型用 curl -I 查看響應頭在服務器配置中強制指定 application/jsonJSON 無法解析文件編碼問題或格式錯誤用 JSON 校驗工具檢查重新生成文件去掉 BOM 頭爬蟲完全不讀取協議協議生態尚未普及查看訪問日志確認是否有爬蟲訪問配合 robots.txt、法律聲明和 API 鑒權使用CDN 緩存了舊策略Cache-Control 設置不恰當檢查響應頭中的緩存字段更新緩存設置必要時手動清除DNS TXT 驗證失敗記錄未生效或格式錯誤使用 nslookup 或 dig 查詢檢查記錄名稱和值格式協議聲明與實際授權不一致運營人員和數據團隊沒有對齊人工復核策略文件建立策略文件發布審核流程9. 最佳實踐與工程化落地建議9.1 與 robots.txt 疊加部署不要二選一Shelf Protocol 和 robots.txt 是互補關系。robots.txt 繼續留給搜索引擎爬蟲用Shelf Protocol 用于商業數據使用方。兩者疊加部署覆蓋面更完整。9.2 策略文件發布要走變更流程商業數據授權策略屬于運營決策不應該由工程師直接改完上線。建議參考這種做法運營或法務提出策略變更需求。平臺審核通過后生成新的策略文件。先在測試站點驗證 JSON 格式和訪問路徑。灰度發布到部分域名。觀察訪問日志和授權申請量后全量上線。9.3 默認拒絕顯式允許協議聲明最好遵循“未知即拒絕”原則。當調用方身份不明確時默認返回不允許訪問。這樣可以避免策略漏洞。9.4 協議文件要帶上聯系方式一個只有“禁止”沒有“如何聯系”的協議很容易把正常的數據合作需求擋在門外。協議文件中應該包含授權申請入口和聯系郵箱。9.5 監控和日志審計建議對協議文件的訪問日志做獨立分析記錄哪些爬蟲在讀取協議、它們隨后是否訪問了受限數據。這些日志可以作為審計材料也能幫助發現異常抓取行為。9.6 對調用方的合規提醒如果你是需要訪問商業數據的調用方也要意識到協議文件中可能存在價格、庫存等敏感數據不能因為“站點的協議文件允許讀取”就直接用于二次銷售或 AI 訓練。技術上的允許不等同于法律上的授權。9.7 版權和使用邊界商品圖片、品牌 Logo、用戶生成的評論都可能涉及版權問題。Shelf Protocol 只聲明數據使用權限不能替代圖片版權和商標授權。凡是涉及人臉、個人信息、品牌素材的必須單獨核對授權。10. 總結與下一步Shelf Protocol 值得關注的核心點不是它能立刻解決所有數據抓取糾紛而是它提供了一個非常清晰的思路把 robots.txt 的聲明式邏輯從 Web 資源層擴展到商業數據層。這個思路一旦成為行業共識后續演化出的標準配置、解析器、授權平臺會非常豐富。最先要驗證的事情有兩個自己站點部署協議文件后正常爬蟲和搜索引擎是否不受影響。數據使用方能否通過腳本正確解析協議并執行授權判斷。最容易踩的坑也有兩個一是把協議文件當作反爬工具期望它能攔截惡意請求二是字段和路徑沒有按實際項目文檔確認導致自己造的協議文件不被社區工具識別。后續可以繼續關注這幾個方向Shelf Protocol 是否進入標準化組織或開源社區的統一維護。主流電商框架是否把協議文件生成邏輯內置到后臺。比價工具和 AI 數據平臺是否開始默認讀取協議文件。是否出現基于協議文件的商業化授權市場。如果手頭有電商站點或數據合規平臺建議先把協議文件部署到測試環境寫一套解析腳本驗證數據團隊和業務團隊是否能按這份聲明執行。跑通之后你會更清楚它在真實業務里能承接到哪一層。這個項目不需要多高的技術門檻但它可能是未來商業數據合作的默認規則之一。建議先收藏再動手驗證。