Agents Need a New Kind of Web Search（Agent 需要一種新型的 Web 搜尋）

原始來源與檔名：2026-07-17T100708+0800-Agents Need a New Kind of Web Search.md

SOURCE | 資訊源評估

準確性：中 - 這是 Seltz.ai 贊助的業配文（文末作者明示 “Seltz for partnering with me on this article”）。核心數據（token 對比）來自作者自家實驗，方法論設計合理（用模型已知的問題隔離 retrieval 成本），但「4x」等結論明顯導向自家產品，且無第三方複現，需打折看待。
易理解性：高 - 用「anterograde amnesia（前向失憶症）」「table of contents vs document」等類比，搭配具體實驗數字與三段程式碼範例，技術門檻低但論證紮實。
閱讀策略建議：把它當成「retrieval tax（檢索稅）」這個概念的優秀入門，而非 Seltz 的產品評測。重點吸收三種 retrieval shape 的回傳差異、跨記錄 join 的價值；對 Seltz 的讚美一律視為行銷。

NAPKIN | 餐巾紙

餐巾紙公式

Agent 迴圈成本 ≈ Σ（每個 search call 回傳的「半成品程度」× 迴圈跳數）每一次搜尋若只回傳「方向」（URL / snippet）而非「成品」（完整文件），agent 就得在每一跳把同一批頁面重新 fetch、清洗、塞進 context window，成本隨跳數複利疊加、最終爆炸。

一句話

把 search API 從「回傳連結的圖書館目錄」升級成「回傳完整文件的預爬索引」，是降低 agent 迴圈成本的最大槓桿——比換更聰明的模型或更好的 prompt 都有效。

餐巾紙草圖

┌─────────────────────────────────────────────
│ Agent 迴圈成本取決於「search 回傳的是方向還是成品」
│
│   問題 Q
│     │
│     ▼
│   [search call] ── 回傳三種形狀 ──┐
│      ├─ SERP        : URL + 30 字 snippet
│      ├─ Neural      : highlight 片段
│      └─ Owned index : 完整結構化文件
│
│   回傳越「半成品」→ agent 越要自己 fetch/clean
│                   → 每跳重付 context window 稅
│                   → token 隨跳數疊加爆炸 (4x)
│
└─ 槓桿：讓成品在 query 抵達前就備好

ROUND 1: SKELETON | 骨架掃描

核心問題：為什麼給 agent 接上 web search 後，token 消耗令人失望？如何讓 agent 的 web 檢索真正高效？
核心答案：問題不在 agent 多聰明或多會下 prompt，而在「search call 回傳什麼」。回傳方向（URL / snippet）會逼 agent 每跳重複 fetch + 清洗，形成 retrieval tax；回傳完整文件（owned index）才能消滅這個稅，並進一步解鎖「跨記錄 join」這類單一文件無法回答的問題。
論證結構：先指出 LLM 的時間盲（anterograde amnesia）→ 點出 web search 是補盲的唯一窗口 → 診斷 token 去向（大都耗在 raw page text）→ 定義 retrieval tax → 用控制實驗量化（4x）→ 比較三種 retrieval shape → 展示跨記錄問題 → 提出工具鏈策略（chain discovery + depth）→ 收束於 Seltz 產品。

章節骨架（條列）

（開場）LLM 的前向失憶與 web search 的角色
Every loop iteration pays the retrieval tax
Good retrieval returns documents, not directions
Some answers only exist across records
Chain discovery and depth, and every iteration gets cheaper

ROUND 2: DISSECTION | 血肉解剖

論證鏈

┌──────────────────────────────────────────────────
│ 論證鏈
│
│ LLM 有時間盲（訓練截止後的事不知道）
│   │
│   ▼
│ web search 是唯一窗口
│   │
│   ▼
│ 但 search API 只回傳 URL + snippet = 「目錄」非「內容」
│   │
│   ▼
│ agent 被迫自己 fetch HTML / 去標記 / 抽可用文字
│   │
│   ▼  (每跳重來)
│ retrieval tax 隨迴圈跳數疊加 → token 爆炸
│   │
│   ▼  (實驗佐證)
│ memory 600  <  owned index 6.9k  <  3-hop loop 28.7k (≈4x)
│   │
│   ▼
│ 解方：讓 search 回傳「成品文件」而非「方向」
│   │
│   ▼
│ 進而解鎖：跨記錄 join 才能回答的問題
└──────────────────────────────────────────────────

3 個關鍵證據

控制實驗設計：用「What was Y2K?」這類模型已從訓練得知答案的問題，確保三組（memory / owned index / web loop）的「思考成本」恆等，於是 token 差異 100% 來自 retrieval——這是把 retrieval tax 「單獨隔離」的乾淨實驗法。
三組 token 數據：memory ≈ 600（baseline）/ owned index ≈ 6,900 / 單次 web hop ≈ 3,750 / 三跳 loop ≈ 28,700（> 4x owned index）。關鍵洞察是「每跳重新計費整個不斷增長的 context window」，所以第三跳時 agent 多半在為「已讀過的頁面」付錢。
三種 retrieval shape 的回傳差異（以 Christoph Molnar 查詢示範）：SERP 回傳「分頁列表」、neural search 回傳「highlight 片段」、owned index 回傳「完整結構化 record」。只有 owned index 能「一次呼叫、直接 reasoning」。

隱形假設與邏輯邊界

贊助偏誤：文章為 Seltz 贊助，「4x」數字與產品優勢皆由作者自家測得，無第三方複現；owned index 的 6.9k 也包含其服務回傳的全文，與 SERP 的 snippet 未必在「資訊量」上公平可比。
鮮度代價被淡化：owned index「預先爬蟲清洗」意味內容有爬蟲週期延遲，無法涵蓋「今早才上線的頁面」——作者後段也承認 open web search 才適合 discovery，但前段把 owned index 講得太萬能。
people scope 的覆蓋局限：作者自承 people scope 在「最高階主管」層不準，建議用 open search 起頭再用 Seltz 補下層——等於承認索引覆蓋有階層盲區。
單一問題外推：實驗只用一個模型已知問題，未涵蓋「模型不知道、必須靠網路」的真實情境；真實情境下「思考成本恆等」的前提不成立，4x 的相對差距可能縮小。

ROUND 3: SOUL | 靈魂提取

作者盲點：把「retrieval shape」抬升為唯一槓桿，卻低估了鮮度、覆蓋率、預爬成本（爬蟲/清洗/儲存/保鮮本身要錢）、以及「agent 何時該停止迴圈」的問題。另外把 Seltz 包裝成通用解，但實際它只贏在「可結構化、可預爬、穩定實體」的查詢類型。
知識連接：與 RAG（檢索品質決定生成品質）、context engineering、以及「按 token 計費的 context window」經濟模型（prompt caching、context compaction）高度相關。retrieval tax 本質是「把檢索結果塞進按 token 計費的 context」的經濟問題。
行動觸發：設計 agent loop 時，先把查詢分類成 discovery（要鮮度、要連結）vs depth（要完整實體），再分派不同 retrieval 後端；並在迴圈中監控「每跳 context window 增量」，把 retrieval tax 列為可觀測指標。

留白提問（2 題）

若 owned index 的預爬成本（爬蟲、清洗、儲存、保鮮）全部轉嫁到 API 價格，在「查詢量小 / 鮮度要求高」的場景，它相對 SERP 的總成本優勢是否還成立？
retrieval tax 的根源其實是「按 token 計費的 context window」經濟模型；若未來模型原生 prompt cache 或 context compaction 成熟，這個稅是否會自動消失，使 owned index 的差異化被抹平？

跨域映射

資料庫設計：SERP 對應「指標索引（pointer index）」，owned index 對應「物化視圖（materialized view）」——後者預先把 join 結果算好，查詢時不必臨時計算。retrieval tax 就是「在查詢時臨時做 ETL」的成本。
CPU cache vs main memory：owned index 是把「熱資料」預先放進 L1 cache，避免每次都要從主記憶體（open web）搬運。
編譯器：open web search = 直譯（每次都重新 parse HTML）；owned index = 預編譯（提前把 web 編成結構化 AST）。

DEEP READ | 精讀指引

精讀時聚焦三個層次。第一，把「retrieval tax」當成一個可量化的工程指標，而非比喻：親自在自家 agent trace 裡量「每跳 context window 增量」與「真正進入 reasoning 的 token 占比」，驗證作者「thin slice went into answering」的觀察。第二，仔細比對三種 retrieval shape 的回傳 payload（SERP / neural / owned），理解「回傳的粒度」如何決定 agent 能否省去後續 fetch——這是整篇的技術核心，值得逐行讀那三段程式碼範例。第三，跨記錄 join 那段是全文最被低估的部分：它指出「某些答案不存在於任何單一頁面，只存在於記錄的交集」，這其實是把 web search 從「文件檢索」升級到「知識圖譜查詢」的分水嶺，值得花時間想清楚它的邊界（哪些問題永遠無法靠預爬解決）。

推薦理由：這篇用最低門檻講清楚了一個 agent 工程的關鍵經濟結構（retrieval shape → 迴圈成本），且實驗設計（用模型已知問題隔離變因）具備方法論上的乾淨度，可作為設計自家 agent 檢索層的決策起點；但要帶著「贊助偏誤」濾鏡讀產品段落。

STRUCTURE MAP | 全書結構圖

┌──────────────────────────────────────────────────────
│ Agents Need a New Kind of Web Search — 結構圖
│
│ [開場] LLM 時間盲 → web search 是唯一窗口
│   │
│   ▼
│ [診斷] token 大都耗在 raw page text
│   │  → search 只回傳「目錄」非「內容」
│   ▼
│ [量化] retrieval tax 實驗 (What was Y2K?)
│   │   memory 600 / owned 6.9k / loop 28.7k (4x)
│   ▼
│ [解方] Good retrieval returns documents, not directions
│   │   ├─ SERP      (URL + snippet)
│   │   ├─ Neural    (highlight)
│   │   └─ Owned idx (完整文件) ◄── Seltz 產品
│   │      └─ 3 scopes: people / news / wiki
│   ▼
│ [進階] Some answers only exist across records
│   │   → 跨記錄 join (GTM 用例)
│   ▼
│ [策略] Chain discovery + depth
│       open web 做 discovery，owned index 做 depth
└──────────────────────────────────────────────────────

Agents Need a New Kind of Web Search (Architectural Deep Dive)

前言/背景

Andrej Karpathy 曾形容 LLM 像一個患有前向失憶症（anterograde amnesia）的同事——舊記憶保留，卻無法形成新記憶。LLM 的這種「時間盲」體現在兩個層面：跨對話不記得你、訓練截止後的事一概不知。memory 功能修補了第一個缺口，而本文處理第二個缺口，因為 agent 多半是被雇來「處理當下」的。

市場波動、人事異動、價格更新、新聞爆發——agent 要感知這一切，唯一窗口就是 web search，而它的好壞直接決定整個 agent 的可用性。於是你給 agent 接上搜尋工具，以為它從此能讀懂網頁；但檢視前幾條 trace 後卻大失所望：你付的 token 幾乎全耗在「agent 得自己挖掘的原始頁面文字」上，真正用來回答問題的只佔一小薄片。

原因在於 search call 實際回傳了什麼。典型的搜尋 API 只回傳連結與三十字的 snippet，如此而已。所以 agent 並不是「在讀網頁」，而是在讀「目錄（table of contents）」。取得實際頁面變成它的工作——拉 HTML、去標記、抽出可用文字，真正的工作還沒開始。單一查詢幾乎察覺不到這個開銷；但在需要多次搜尋的任務（研究調研、簡報管線）裡，每一個查詢都要重付一次。

問題不在 agent 搜尋得差，而在「每次搜尋回傳的是內容的指標（pointer）而非內容本身」，agent 得在每次呼叫時為彌補這個缺口付錢。作者把同一個問題跑過三種 retrieval 設定並計算 token，最貴的設定大約是最便宜的 4 倍。本文會走過這些數字，展示當 agent 是讀者時，搜尋回應應有的長相；並涵蓋一類「只有完整文件才能回答」的問題。

Every loop iteration pays the retrieval tax（每次迴圈迭代都在付檢索稅）

那個重複「fetch 再清洗」的工作有個名字——retrieval tax（檢索稅），也就是 agent 在針對你的問題進行推理之前，為了「備料」而燒掉的 token。只要一個會迴圈的 agent 就足以讓人感受到它：研究型 agent 搜尋、讀回傳結果、決定下一步查什麼、再搜尋，每一跳都在前一跳之上再付一次稅。

控制實驗：用模型已知的問題隔離檢索成本

以下是在單一問題上的成本。作者刻意挑選「What was Y2K?」——一個模型已從訓練得知答案的問題——用三種方式回答，並計算每次的總 billing token：

純記憶（from memory）
透過 web search loop
透過 owned index（一種事先爬蟲並清洗頁面、儲存自己處理過版本的搜尋服務）

挑一個模型已知的問題，是讓實驗乾淨的關鍵：三組的「思考成本」完全相同，因此任何超出 baseline 的 token 都純粹來自 retrieval。

純記憶：整件事約 600 tokens。這是 baseline——零檢索、純作答的成本。
Owned index：這類服務已事先爬蟲並清洗頁面，一次呼叫就回傳完整文件。走完它約 6,900 tokens。
Web search loop：單一 hop 約 3,750 tokens；但 snippet 通常太薄、無法直接作答，於是 agent 反覆 refetch 與 refine，三跳累積到約 28,700 tokens——超過 owned index 的 4 倍。

loop 與 index 之間的差距就是「檢索稅現形」。每一跳都重新計費整個不斷增長的 context window，所以到第三跳時，agent 多半在為「已經讀過的頁面」付錢。owned index 完全跳過這一切——query 抵達時完整文件已在原地。讓這一切成為可能的，正是 search call 本身回傳的內容。

Good retrieval returns documents, not directions（好的檢索回傳文件，而非方向）

解方不是更聰明的 agent 或更好的 prompt，而是「search call 回傳什麼」。

SERP：搜尋 API 回傳的陽春結果清單，給你一串 URL，要 agent 自己去讀網頁。
Scraper-first 工具：回傳原始 HTML 或 markdown，較接近，但 agent 仍得先清洗才能用。
Owned index：在 query 抵達前就把上述工作全部做完，回傳的內容已可直接讀。

以下用同一個查詢（搜尋《Interpretable Machine Learning》作者 Christoph Molnar）示範三者差異。

SERP —— agent 拿到的是「分頁清單」而非答案：

# query
results = search("Christoph Molnar interpretable ML")

# response
[
  {"title": "Interpretable Machine Learning", "url": "christophmolnar.com/books/...", "snippet": "A guide for making black box models explainable..."},
  {"title": "Christoph Molnar - Google Scholar", "url": "scholar.google.com/...", "snippet": "Cited by 12,847..."},
  # 5 more results across different domains
]

Neural search —— 找對了人，但只是 highlight 片段；要拿完整 record 仍需再呼叫一次：

# query
results = neural_search("Christoph Molnar", type="person")

# response
[
  {"highlight": "Christoph Molnar is a statistician and machine learning interpretability researcher..."},
  {"highlight": "Author of Interpretable Machine Learning, an open access book with 400k+ readers..."},
  # one stray paragraph about a different researcher
]

Owned index —— 一次呼叫回傳完整 record，agent 直接進入 reasoning：

# query
result = client.search("Christoph Molnar", scope="people")

# response
{
  "name": "Christoph Molnar",
  "roles": [
    {"title": "Research Scientist", "org": "Mindful Modeler", "start": "2021"},
    {"title": "Author", "work": "Interpretable Machine Learning", "editions": 3}
  ],
  "education": [{"degree": "PhD Statistics", "institution": "LMU Munich"}],
  "websites": ["christophmolnar.com", "github.com/christophM"],
  "languages": ["German", "English"]
}

Seltz 就是為此打造：事先爬蟲、把每個頁面處理成結構化文件、透過單一 API 呼叫回傳成品內容。它附帶三種 scope，各自回傳不同類型的成品文件，視 agent 需求而定：

people scope：完整結構化個人檔案，含每個職位與任期日期、學歷、網站、任職過的組織。
news scope：完整文章正文，並以時間窗（date-windowed）過濾，可只拉取某段特定期間發布的內容。
wiki scope：乾淨的 Wikipedia 文件，適合在深入前為公司、產業、主題建立背景脈絡。

一個 caveat 值得在採用 people scope 前知道：它在「總監／區域主管（director and regional-leader）」這層表現最好。對最高階主管（most senior executives），建議先用 open web search，再用 Seltz 補強其下所有成員。

Some answers only exist across records（某些答案只存在於記錄的交集）

完整文件解鎖的，不只是降低檢索稅。有些問題根本不存在於任何單一搜尋結果中——答案只有在「跨越多筆記錄、找到它們的交集」時才會浮現。SERP 與 neural search 在第一跳都做不到這件事：它們握有的每筆記錄資訊不足以 join，於是工作落回 agent 身上。

考慮一個 GTM（go-to-market）團隊實際會跑的問題：你要找出「上一季聘用過資料或 AI 領導職位（data or AI leadership role）」的所有目標客戶帳號（target account）。回答它需要兩件事同時到位：

完整的職位歷史（role histories）——找出誰、何時就任新職
近期新聞（recent news）——確認時機並浮現觸發事件（trigger event）

做法是：先查 people scope 找出近期異動到相關職位的人，再用 news scope 交叉比對觸發事件。產出是一份排序過的「暖帳號（warm accounts）」清單，附帶足夠脈絡，讓你為每個帳號寫出切題的首封開發信（first outreach line）。這個答案在任何網頁上都找不到——它只在記錄 join 後才存在；而 join 只有在你一開始就握有完整記錄時才成立。

Chain discovery and depth, and every iteration gets cheaper（串接發現與深度，每次迭代都更便宜）

Seltz 並非要取代 open web search，而是針對特定類型問題的正確工具。open web search 擅長 discovery——找出誰目前握有某頭銜、確認某產品上週發布、讀今早上線的頁面。一旦你鎖定目標，Seltz 就能在一跳內回傳完整 record，而非標題加連結。

許多管線不論問題需求，對所有查詢都用同一個搜尋工具：discovery 查詢與深度查詢（deep-dive lookups）走同一個 call，迴圈兩邊都付檢索稅。改成把兩者串接（chain），每個迴圈迭代就能拿到「貼合它實際目的」的 retrieval 形狀。

這正是本文的核心論點：agent 迴圈的成本，由「每次搜尋回傳什麼」決定的程度，遠高於由模型決定；而回傳成品文件，就是讓你停止為同一批頁面付兩次錢的方法。若你正在打造會命中這些查詢形狀的迴圈，作者建議試試 Seltz。

總結與結論

retrieval shape 是 agent 迴圈成本的最大槓桿：換模型、改 prompt 的效益，遠不及改變「search call 回傳方向（URL / snippet）還是成品（完整文件）」。後者直接消滅每跳重複 fetch + 清洗的 retrieval tax。
檢索稅隨迴圈跳數複利疊加：實驗顯示 3-hop loop（28.7k tokens）是 owned index（6.9k）的 4 倍以上，因為每跳重新計費整個不斷增長的 context window——第三跳時 agent 多半在為「已讀頁面」付錢。
跨記錄 join 是「文件檢索 → 知識查詢」的分水嶺：某些答案不存在於任何單一頁面，只存在於記錄的交集（如 GTM 的「近期聘用 AI 主管的帳號」）；只有握有完整記錄才能 join，SERP / neural 在第一跳都做不到。
工具鏈應分層而非一體適用：discovery 查詢（要鮮度、要連結）交給 open web search；depth 查詢（要完整實體）交給 owned index；chain 兩者，讓每個迴圈拿到對的 retrieval 形狀。
帶著贊助濾鏡讀產品段落：本文為 Seltz 贊助，4x 等數字與產品優勢皆作者自家測得，且淡化 owned index 的鮮度延遲與 people scope 的階層覆蓋盲區；其方法論（用模型已知問題隔離 retrieval 成本）值得借鑑，但結論需打折。