Scry 發布:具備擁塞定價機制的程式化網際網路搜尋
Scry 讓 AI 代理能夠針對即時、多來源的網路語料庫執行任意且有邊界的 SQL 風格查詢
重點摘要: Scry 提供單一 MCP 端點 (https://mcp.scry.io),讓 ChatGPT、Claude、Codex、Cursor 以及任何相容 MCP 的客戶端,能夠跨越 43 個公開資料來源(涵蓋 4,160 億筆資料列)執行唯讀查詢,並根據每個查詢宣告的執行時間進行計費。
Scry 實際提供的功能
- 程式化搜尋:AI 代理可以使用支援短語匹配、時間視窗、JOIN 和向量組合的 SQL 方言,查詢 Reddit、Hacker News、LessWrong、arXiv、Stack Exchange、Wikipedia、預測市場以及許多其他來源。
- 即時結構描述探索:
GET /v1/scry/schema會回傳一份機器可讀的合約,描述每個關聯、其欄位、資料列數以及更新延遲。AI 代理必須從此目錄中選擇關聯;無法使用的名稱將會被省略。 - 資料列層級的來源追溯:查詢結果保留了來源原生的識別碼與時間戳記,確保能夠追溯回原始文件。
- 有邊界的執行:每個查詢都在截止時間、記憶體上限與資料列上限下執行。AI 代理可以透過
x-scry-explain: 1標頭請求執行計畫,在付費前查看預估的資料列數、位元組數與運算量。 - 向量基本運算:嵌入(Embeddings)是第一類值。諸如
scry_centroid、scry_contrast_axis_balanced和scry_cosine_similarity等函式,讓 AI 代理能夠對向量進行算術運算,並沿著自訂的語意軸對語料庫進行排序。 - 重新排序:
x-scry-rerank標頭(或/v1/scry/rerank端點)讓 AI 代理能夠以零成本使用本地 LLM 對已擷取的資料列進行重新排序。
截至 2026-09-11 的規模與即時性
- 可查詢資料列:跨 43 個來源,約 1,610 億筆資料列可立即查詢。
- 總持有資產:4,160 億筆資料列,每日攝取率為 +326 億筆資料列(約每分鐘 2,270 萬筆)。
- 主要來源細分(精選範例):
- Reddit 評論:270 億筆資料列(涵蓋 2005 年至今近乎完整的封存)。
- Hacker News 項目:4,500 萬筆資料列,15 分鐘內更新。
- Common Crawl 頁面:208 億筆擷取的文字資料列。
- OpenAlex 作品:5.11 億筆學術詮釋資料列。
- 程式碼與依賴圖:跨 GitHub 事件、deps.dev 與套件註冊表的 439 億筆資料列。
- 未公開來源:2,550 億筆資料列計入持有資產,但若無特殊存取權限則無法查詢。
定價模式 – 「擁塞定價」
| 等級 | 費用 | 目標受眾 |
|---|---|---|
| 研究人員 | $0 (包含 $5 註冊抵用金) | 非商業、個人研究人員 |
| 贊助者 | $100 / 月 (可結轉) | 業餘愛好者與小型團隊 |
| 團隊 | $2,000 / 月起 | 商業用途、專屬容量 |
| AI 代理 | $0.05 / 宣告秒數 | 自主代理按使用量付費 |
AI 代理僅需為其在查詢標頭 (x-scry-max-seconds) 中宣告的時間付費。 此模式抑制了會消耗來源資料列預算過大比例的廣泛掃描,有效地對擁塞而非原始資料量進行定價。
如何連接
- ChatGPT – 啟用 Developer mode,新增一個名為
scry的外掛程式並指向https://mcp.scry.io,然後登入。 - Claude – 在 Settings → Connectors 下新增一個具有相同 URL 的自訂連接器。
- 開發人員 – 使用儀表板提供的 API 金鑰搭配 HTTP API (
https://api.scry.io/v1/scry/query),或使用任何 MCP 客戶端(Claude Code, Codex, Cursor)。
典型請求(curl 範例):
curl -s https://api.scry.io/v1/scry/query \
-H "Authorization: Bearer $SCRY_API_KEY" \
-H "Content-Type: text/plain" \
--data "SELECT hn_id, title FROM hackernews.items WHERE hn_id >= (SELECT max(hn_id) FROM hackernews.story_scores WHERE observed_on >= today() - 7) - 100000 ORDER BY hn_id DESC LIMIT 20"
展示 Scry 強大功能的範例查詢
- 尋找書籤數多於按讚數的小型追蹤帳號(在 2.04 億筆推文修訂中耗時 4.9 秒)。
- 使用兩個立場句子之間的對比軸來衡量 LessWrong 上的立場漂移(約 0.1 秒)。
- 識別 Elon Musk、Sam Altman 與 Eliezer Yudkowsky 的共同追蹤者(在 290 萬筆資料列中耗時 171 毫秒)。
- 定位同時引用《Scaling Laws》與《Chinchilla》的論文(0.1 秒,195 個匹配結果)。
- 偵測 Hacker News 上的反覆爭執(在 4,670 萬筆資料列中耗時 1.6 秒)。
這些範例展示了單一宣告式語句如何取代數十個手動抓取與後處理步驟。
來自 Hacker News 的社群回饋
codexon: “你是如何抓取 Reddit 評論的?這不需要昂貴的授權嗎?” – 該貼文未揭露授權細節;此評論突顯了對資料來源的普遍擔憂。
ashkankiani: “定價讓我想起了演算法交易。你能像 Wikipedia 那樣透過 P2P 分發資料集嗎?” – 建議透過開源分發來減少查詢端的擁塞。
vova_hn2: “定價模式很難理解;‘查詢時間秒數’的定義不明確。” – 確認這種新穎的定價術語可能需要更清晰的文件說明。
DylanMerigaud: “查詢的擁塞定價聽起來很有創新性。” – 對經濟模式的正面評價。
MrDrMcCoy: “這能補充較小的搜尋引擎並打破 Google/Bing 的壟斷嗎?” – 突顯了潛在的生態系統影響。
整體情緒是熱情的,但呼籲對資料授權、定價機制以及底層語料庫的潛在開放分發進行更清晰的解釋。
為什麼 Scry 很重要
- 實現真正的程式化研究:AI 代理不再需要拼湊逐頁抓取的資料;它們可以向網路提出單一、可組合的查詢,並接收結構化且來源豐富的結果。
- 減少冗餘爬取:透過公開原始來源資料表,Scry 消除了每個下游工具維護自身爬蟲的需求,降低了頻寬與儲存成本。
- 引入經濟誘因:擁塞定價抑制了浪費性的高量掃描,使資源使用與所獲得的洞察價值保持一致。
- 公共利益基礎設施:為非商業研究人員提供的免費層級降低了大規模資料分析的門檻,而商業參與則為服務提供資金。
使用者的後續步驟
- 註冊免費研究人員帳號以取得 API 金鑰。
- 擷取即時結構描述 (
/v1/scry/schema) 並探索可用關聯。 - 使用
x-scry-explain標頭進行查詢原型設計,以在執行前評估成本。 - 將 MCP 端點整合到您的 LLM 驅動代理或分析管線中。
所有效能數據(例如每 GB Hacker News 文字 0.86 秒)均於 2026-09-11 在即時生產系統上測量,並反映了典型負載下的單伺服器執行情況。
Sources
相關
- 專案
- Dispatch
- 專案
- Dispatch
- Dispatch