Agent 的
即插即用
搜尋原語

每個 agent 都需要搜尋能力。寫程式的 agent 需要搜尋數百萬個程式碼檔案；客戶支援 agent 需要搜尋工單記錄和產品文件；法律 agent 需要搜尋案例和合約。搜尋不是 agent 的「可選功能」，它是基礎原語。

但自己建 RAG pipeline 的成本很高：需要一個向量索引、一個索引更新 pipeline、某種機制保持索引和來源資料同步、另一個關鍵字搜尋索引、以及把兩者結果合併的融合邏輯。如果每個 agent 或每個客戶都需要自己的搜尋上下文，這一切還要乘以 agent 數量。

AI Search（原 AutoRAG）就是要解決這個問題——讓搜尋成為 Workers binding，就像 KV 或 R2 一樣隨手可用。這次 Agents Week 的升級把它從「可設定的向量搜尋服務」變成了真正的 agent 搜尋原語：

向量搜尋的根本限制在這個情境最清楚：ERR_CONNECTION_REFUSED timeout。向量模型理解「連線失敗」的語意，可以找到所有關於「connection error troubleshooting」的文件——但它可能永遠不會把含有這個精確 error string 的文件排第一，因為向量距離反映的是語意相似度，不是字面吻合度。

BM25 填補了這個缺口，但它有自己的盲點：找得到含 ERR_CONNECTION_REFUSED 的文件，但找不到描述同一個問題、卻用了不同措辭的文件（比如「socket connection was reset」）。

AI Search 的 Hybrid 模式同時跑兩個索引，用 Reciprocal Rank Fusion（RRF）或 max score 把結果合併。有四個關鍵設定選項：

const instance = await env.AI_SEARCH.create({
  id: "my-instance",
  index_method: { keyword: true, vector: true },
  indexing_options: { keyword_tokenizer: "porter" },
  retrieval_options: { keyword_match_mode: "or" },
  fusion_method: "rrf",
  reranking: true,
  reranking_model: "@cf/baai/bge-reranker-base"
});

舊版 AutoRAG 的設定流程相當繁瑣，即使 Cloudflare 幫你抽象了很多底層細節，你還是需要：建立 R2 bucket → 把 bucket 連結到 AutoRAG → AutoRAG 生成 service API token → Vectorize 索引在你的帳號下被 provision → 把文件上傳到 R2 → 等待同步 job 執行 → 索引完成後才可搜尋。每個步驟都是摩擦力。

新版 AI Search 的流程是：create() → instance 自帶儲存 + 向量索引 → uploadAndPoll() → 立刻可搜尋。

// 取得（或建立）instance
const instance = env.AI_SEARCH.get("my-instance");

// 上傳文件，等待索引完成
const item = await instance.items.uploadAndPoll("faq.md", content, {
  metadata: { category: "onboarding" }
});
console.log(item.status); // "completed"

// 立刻可以搜尋
const results = await instance.search({
  messages: [{ role: "user", content: "onboarding guide" }],
});

uploadAndPoll() 會等到文件索引完成才 resolve，所以你不需要另外輪詢狀態——上傳完成即可搜尋。

值得注意的是，內建儲存和外部 R2 並不互斥。一個 instance 可以同時連接一個外部 R2 bucket（或一個網站 URL 作為爬取來源）以及使用內建儲存。適合的場景是：R2 放全局知識庫（由另一個 pipeline 維護），內建儲存放 agent 或 customer 特定的資料（由 agent 自己寫入）。

ai_search_namespaces binding 取代了舊版的 env.AI.autorag()。最重要的差異是：你可以在 Worker 執行時動態建立和刪除 instance，不需要修改 wrangler 配置或重新 deploy。

這意味著：每個新客戶註冊，你的 Worker 可以立刻為他們建立一個專屬的搜尋索引；客戶刪除帳號，索引連同所有資料一起刪除。整個生命週期由程式邏輯控制，不需要 ops 介入。

// wrangler.jsonc
{
  "ai_search_namespaces": [
    { "binding": "AI_SEARCH", "namespace": "example" }
  ]
}

// 執行時建立（每個客戶一個 instance）
const instance = await env.AI_SEARCH.create({ id: "customer-abc123" });

// 執行時刪除（連同所有索引資料）
await env.AI_SEARCH.delete("old-instance");

Metadata boosting 讓你可以控制搜尋結果的排名邏輯，不只依賴相關性分數。最常見的用途是讓最新文件優先，或按自定義欄位（優先級、語言、部門）調整：

const results = await instance.search({
  query: "deployment guide",
  ai_search_options: {
    boost_by: [{ field: "timestamp", direction: "desc" }]
  }
});

這對於文件持續更新的場景特別重要：如果你的 agent 需要回答「最新的部署流程是什麼」，你不希望它找到三年前的舊版文件，即使那份文件的語意相關性更高。

把以上功能組合起來，看一個實際的應用場景：一個客戶支援 agent，需要同時搜尋產品知識庫（全局共享）和每個客戶的歷史解決記錄（per-customer）。

資料架構如下：

Namespace 結構：

跨實例搜尋的呼叫方式：

const results = await env.SUPPORT_KB.search({
  query: "billing error",
  ai_search_options: {
    instance_ids: ["product-knowledge", "customer-abc123"]
  }
});

AI Search 目前在 Open Beta 階段，完全免費。Beta 結束後會進入一般定價，但 Cloudflare 還沒有公布具體價格。以下是各方案的實例和使用限制：

Hybrid Search 的每實例檔案上限是純向量搜尋的一半（50 萬 vs 100 萬），因為同時維護兩個索引需要更多儲存空間。網站作為資料來源的爬取功能使用 Browser Run 內建，不另外計費 Browser Run 的用量。

舊版 AutoRAG 建立的 instance 繼續正常運作，不受此次升級影響。如果要使用新功能（Hybrid Search、namespace binding），需要建立新的 instance。

立即開始：

npx wrangler ai-search create my-search