Keenable 是什麼？獲 2,600 萬美元投資，要替 AI Agent 重做網路搜尋
Keenable 獲 2,600 萬美元 Seed 輪，要替 AI Agent 重做網路搜尋。本文解析 Search、Fetch、WebQL、MCP、費用與風險。
AI 很會回答常識，但只要問到你真正熟悉的領域，就常出現一種尷尬情況：答案不一定完全錯，卻只停在平均水準，細節也可能已經過時。
Keenable 想解決的就是這個問題。它不是另一個讓人輸入關鍵字的搜尋網站，而是替 AI Agent 提供搜尋結果與完整網頁內容的底層服務。AI Agent 是能自行呼叫工具、分解任務並完成多個步驟的 AI 系統；Keenable 則負責讓這些系統查到最新、可追溯來源的網路資料。
2026 年 8 月 25 日，Keenable 正式走出 stealth mode，也就是結束低調開發階段，並宣布完成 2,600 萬美元 Seed 輪。這筆早期募資由 Accel 領投，Conviction 與天使投資人參與。
我的判斷是：Keenable 是目前很值得 AI 開發者測試的搜尋基礎設施，但還不能只憑募資金額與公司自製 benchmark，就把它稱為「下一個 Google」。真正有價值的地方，是它把搜尋、讀取網頁與歷史版本查詢做成 Agent 可以頻繁呼叫的介面；最大的未知數，則是未公開的客戶、索引品質與長期營運成本。
Keenable 是什麼？它不是給人用的搜尋引擎
Keenable 官方定位是 AI 搜尋基礎設施公司，主要客戶是 AI labs、推論服務商與建立 Agent 的開發團隊。所謂「搜尋基礎設施」，可以把它想成搜尋引擎藏在後台的資料層：系統先抓取網頁、建立索引，再根據查詢找出相關內容。
傳統搜尋產品通常把結果整理成「10 個藍色連結」，讓人自己點開閱讀。AI Agent 的需求不太一樣。它可能在一次研究任務中連續搜尋數十次，需要限定日期、指定網站，還要直接取得頁面正文，而不是只看標題與短摘要。
Keenable 因此沒有把重心放在消費者搜尋首頁，而是提供 API、CLI 與 MCP。API 是讓不同軟體交換資料的介面，CLI 是從終端機下指令的工具。MCP（Model Context Protocol）則是一套讓 AI 連接外部工具的共通規格。
這個定位很重要。Keenable 不是要你放棄 Google，改去另一個網站搜尋餐廳；它想成為 ChatGPT、Claude、Codex、Cursor 或企業內部 Agent 背後的搜尋供應商。
為什麼 AI Agent 需要另一套網路搜尋？
大型語言模型的知識主要來自訓練資料。當問題涉及剛發生的新聞、最新產品文件或很冷門的專業細節，模型可能沒有足夠資訊，只能依過去學到的模式推測。
搜尋可以補上這個缺口，但現有搜尋 API 多半延續人類使用搜尋引擎的習慣：查一次、看少量結果，再決定要不要點進網頁。Agent 卻能讀取更多資料，也會在規劃、驗證與執行階段反覆查詢。若每次搜尋與抓取頁面的成本太高、速度太慢，Agent 就會減少查證，最後仍回到憑模型記憶作答。
Keenable 的核心主張，是讓網路資料像模型內部知識一樣容易取用。這個方向合理，因為 Agent 越能自主執行任務，搜尋就越不是最後一步，而是整個推理流程中的反覆動作。
但「為 AI 而生」本身不構成護城河。最後仍要回到三件事：索引是否夠廣、排序是否真的更適合 Agent，以及大量呼叫時的速度與成本能不能成立。
Keenable 有哪些功能？Search、Fetch、Time Machine 一次看
Keenable 目前公開、文件也最完整的能力，可以分成四層。
| 功能 | 白話說明 | 適合用途 |
|---|---|---|
| Search API | 依問題搜尋網頁，回傳標題、網址、摘要與時間資訊 | 新聞查核、資料蒐集、找官方文件 |
| Fetch API | 把指定網頁轉成適合程式讀取的 Markdown 文字格式 | 讓 Agent 讀全文、摘要或抽取欄位 |
| Time Machine | 指定一個過去時間點，搜尋當時已被收錄的網頁版本 | 歷史研究、比較頁面變更、避免新資料干擾 |
| MCP、CLI 與整合套件 | 把搜尋與讀頁功能接進 Agent 工具 | Claude、Codex、Cursor、LangChain 等工作流 |
Search API：不只回傳連結，也能控制時間與網站
官方 Search API 文件顯示，查詢除了關鍵字，還能限制特定網站、發布日期、收錄日期、結果數量與摘要長度。對 Agent 來說，這些欄位比華麗的搜尋頁面更重要，因為系統可以直接把篩選條件寫進工作流程。
Keenable 也提供不需 API key 的公開端點。雷司紀在 2026 年 8 月 26 日依官方文件送出測試請求，服務成功回應，並正常提供 3 筆含標題、網址與發布時間的結果。這證明產品並非只有候補名單，但單次測試只能確認服務可用，不能證明它已在所有查詢類型勝過其他搜尋供應商。
Fetch API：讓 Agent 直接讀頁面內容
搜尋結果只是入口，Agent 往往還需要讀全文。Fetch API可以從 Keenable 已建立的索引取回 Markdown，也能用 live=true 即時讀取來源網站。開發者還能附上抽取指令，只要求系統整理頁面中的價格、方案或特定欄位。
這項功能可減少開發者另外串接爬蟲與正文清理工具的工作。不過，即時抓取仍受來源網站、robots 規則、登入限制與頁面結構影響，不能理解成任何網站都能無條件讀取。
Time Machine：重新搜尋某個時間點的網路
Time Machine 是 Keenable 較有辨識度的功能。開發者可以加入 query_time，讓搜尋排除該時間之後才被收錄的內容，並取得特定歷史快照。
這對金融研究、事件時間線與公司盡職調查很實用。例如，要研究某家公司在併購消息公開前有哪些產品說法，就能把搜尋時間固定在消息公布以前，降低後來文章倒灌進結果的問題。
它的限制也很直接：歷史搜尋的價值取決於 Keenable 當時是否已抓到那個頁面。設定過去日期，不代表所有網站的每個舊版本都一定存在。
Web Query Language 是什麼？野心比一般搜尋 API 更大
創辦人 Andrey Styskin 在發布貼文中表示，Web Search API 與 Web Query Language 已經上線。Web Query Language 常被簡稱為 WebQL，目標不是只找一份文件，而是讓 AI 從多個網路來源組合答案，即使沒有任何單一頁面包含完整資訊。
Keenable 共同創辦人 Andrey Styskin 發布的官方影片，說明為何 AI Agent 需要新的網路搜尋基礎設施。影片來源：Andrey Styskin 官方 X 貼文。
這個方向確實更貼近 Agent 的研究工作。例如，要比較 5 家公司的營收、員工數與募資歷史，資料通常散在財報、公司網站與新聞稿。一般搜尋 API 回傳多組結果後，還要由 Agent 自行讀取、對齊與整理；WebQL 想把跨來源查詢做成更接近資料庫語言的操作。
不過，Keenable 目前公開文件的主體仍是 Search 與 Fetch，WebQL 尚未像這兩套 API 一樣提供完整、獨立的串接規格頁。這讓 WebQL 現階段更適合被視為值得試用的進階搜尋層，而不是已被充分驗證的通用查詢標準。
2,600 萬美元 Seed 輪，投資人真正押注的是團隊經驗
根據 TechCrunch 報導，Keenable 由 Andrey Styskin 與 Matthias Petri 共同創辦。Styskin 曾負責 Yandex 的搜尋、AI 與雲端業務，之後進入 Amazon AGI；Petri 則曾在 Amazon Alexa AI 擔任應用科學家。
這段背景比「前大廠團隊」的標籤更有意義。建立網路索引不只是訓練一個模型，還要長期處理爬取、去重、更新、排序、延遲與儲存成本。真正做過大型搜尋系統的團隊，較有機會理解這些不容易從產品畫面看出的工程問題。
Keenable 宣稱索引已超過 1,000 億份文件，並已在數家 AI labs 與推論服務商的訓練、執行環境中使用，但公司沒有公布客戶名稱。它目前公開的合作案例是語音 AI 公司 Gradium，讓語音 Agent 能在對話中查詢即時網路資訊。
因此，2,600 萬美元募資是團隊與市場方向的強烈背書，卻還不是產品已取得市場主導地位的證據。後續若能公布可驗證的客戶留存、查詢量與第三方評測，這個看多理由才會更扎實。
Keenable 搜尋品質真的比較好嗎？先看 benchmark 怎麼做
Keenable 公開了 NEEDLE benchmark，持續測試新聞、財務、學術、法律與少見查詢。專案程式碼採 MIT License，也會保存歷史結果，讓外部研究者查看評測方式。
這比只放一張沒有方法說明的排行榜更透明。NEEDLE 會限制不同搜尋引擎回傳的內容長度，並依任務使用 LLM 評審、答案召回率或文件識別碼比對，盡量避免單純以主觀印象評分。
但它仍是 Keenable 自己設計與維護的 benchmark。測試項目、搜尋引擎模式、價格方案與理想答案的定義，都可能影響結果。官方網站上的品質與成本圖，可以當成試用線索，不能直接當成獨立第三方證明。
我目前對 Keenable 的產品判斷是中性偏多。公開程式碼與持續評測增加可信度，但要把評價提高到明確看多，還需要外部團隊在相同查詢集、相同內容長度與相同價格條件下重現結果。
Keenable 費用多少？新手可以先免費測試
截至 2026 年 8 月 26 日，Keenable 定價頁提供每月 10 萬次免費請求。一般隨用隨付方案為每 1,000 次請求 4 美元；需要每秒 100 次以上專用容量的 AI labs 與推論平台，官方列出的起始價為每 1,000 次 1 美元，並可使用雲端或部署在企業自有環境。
沒有帳號也能使用公開端點，但官方限制是每個 IP 每小時 1,000 次，最高每秒 10 次。登入後的免費額度每月重置，組織預設上限同樣是每秒 10 次，更高吞吐量需要另外洽談。
這個免費層足以做概念驗證。若只是想替個人 Agent 加入搜尋，不必一開始就建立完整帳務流程；若要投入正式產品，則應另外計算 Search、Fetch、即時抓取與更深層查詢各自消耗的額度，不能只拿首頁最低價估算總成本。
Keenable 怎麼用？不寫程式也能接到 AI 工具
Keenable 已提供 REST API、CLI、MCP 與多種框架整合。對一般使用者來說，最簡單的起點不是自己寫 API，而是透過 MCP 或現成 plugin，把 search_web_pages 與 fetch_page_content 兩項工具交給 Agent 呼叫。
官方整合目錄列出 Claude、ChatGPT、Codex、Cursor、LangChain、LlamaIndex、Vercel AI SDK、n8n 與多個 Agent 框架。不同工具的安裝方式不完全相同，有些可從 plugin 目錄加入，有些需要設定 MCP URL。
第一次測試時，我會先讓 Agent 只做三件事：搜尋官方來源、讀取指定頁面、附上引用連結。等結果穩定後，再加入多來源比較或自動化流程。這樣比較容易分辨錯誤來自搜尋結果、頁面讀取，還是 Agent 自己的推理。
Keenable 的 4 個風險：不是有索引就等於下一個 Google
1. 大型索引的營運成本很高
超過 1,000 億份文件代表龐大的抓取、儲存與更新成本。Styskin 也向 TechCrunch 坦言，建立大型索引「非常昂貴」。Keenable 必須同時維持低價、低延遲與內容新鮮度，任何一項失衡都會削弱產品優勢。
2. 客戶與實際使用量尚未公開
公司表示已有 AI labs 與推論服務商在正式環境使用，但沒有公布名稱、合約規模或留存率。目前能確認的是產品已可用，以及與 Gradium 的公開合作；這和大規模商業驗證仍有距離。
3. 搜尋品質證據主要來自公司自己的 benchmark
NEEDLE 的方法公開是加分，但主辦者與受測產品仍是同一家公司。對開發團隊來說，最可靠的做法是拿自己的真實查詢集，與 Exa、Brave 或現有搜尋供應商做盲測，而不是只看官方圖表。
4. 網路內容的權利與存取規則不會消失
Agent 可以一次閱讀更多內容，不代表網站授權、付費牆、隱私與 robots 規則就不重要。搜尋供應商仍要處理內容來源、更新與移除要求，使用者也要確認取得的資料能否用於自己的產品。
結論：Keenable 值得試，但現在更像 AI 搜尋供應商，不是 Google 接班人
Keenable 抓到了一個真問題：AI Agent 不只需要更聰明的模型，也需要能頻繁、快速而且可追溯地讀取網路。Search、Fetch、Time Machine、MCP 與 WebQL 的組合，正是在補這一層基礎設施。
對個人開發者與小團隊，我會給「值得測試」的結論。每月 10 萬次免費額度與免 API key 端點，已足以拿真實任務比較搜尋品質。對準備採購企業搜尋服務的團隊，我則維持中性偏多，因為 1,000 億份文件、低延遲與正式客戶等關鍵指標，目前仍以公司自述為主。
最可能讓我提高評價的證據，是可重現的第三方 benchmark、具名客戶與穩定的高流量案例。反過來說，若索引更新速度、跨語言品質或大量查詢成本不如既有供應商，Keenable 的「為 Agent 重做搜尋」就會停留在好故事，而不是新的市場標準。
Keenable 常見問題
Keenable 是搜尋引擎嗎？
Keenable 有自己的網路索引與排序系統，但主要產品不是給人瀏覽的搜尋網站，而是提供給 AI Agent 與開發者使用的 Search API、Fetch API、MCP 與整合工具。
Keenable 和 Google Search 有什麼不同？
Google Search 主要服務一般使用者，Keenable 則把重點放在 AI 系統的大量查詢、全文讀取、時間篩選與工具串接。兩者都有搜尋與排序能力，但產品介面、目標客戶與使用方式不同。
Keenable 可以免費使用嗎？
可以。截至 2026 年 8 月 26 日，官方提供每月 10 萬次免費請求，也有不需 API key 的公開端點。公開端點受每個 IP 每小時 1,000 次等限制，正式產品仍要依流量與功能估算費用。
WebQL 和一般搜尋 API 有什麼差別？
一般搜尋 API 主要回傳相關網頁；WebQL 的目標是從多個網路來源組合與查詢資料，處理沒有單一頁面能完整回答的問題。目前公開文件仍以 Search 與 Fetch 為主，WebQL 的完整使用規格較少。
Keenable 適合哪些人？
它較適合建立研究 Agent、客服 Agent、語音助理、AI Coding 工具或需要即時資料的產品團隊。只想手動搜尋幾個網頁的一般使用者，直接使用現有搜尋引擎會更簡單。
