Mozilla AI 問：誰為你的代理程式搜尋網絡？

Mozilla AI 正透過 Otari 挑戰代理程式搜尋服務綑綁供應的模式，讓團隊可獨立於模型選擇搜尋服務。誰為你的代理程式搜尋網絡？其 10 月 19 日的文章讓這個問題變得具體：選用某個 AI 模型，未必代表你知道其搜尋查詢會傳送到哪裏。

Otari 位於代理程式——即利用工具完成任務的軟件——與模型供應商之間。Mozilla AI 表示，這個位置讓它可在保留支援客戶端介面的同時，重新導向搜尋。這項建議的改變關乎誰掌控資訊檢索，而非由哪個模型撰寫答案。

競爭中的做法很直接：接受隨模型服務綑綁的搜尋，或將搜尋作為獨立依賴項管理。Claude Code 提供了有用的參考，因為其內置搜尋使用 Anthropic 的後端。Otari 則透過將搜尋路由變成獨立決策來挑戰這項安排，而作出該決策的一方亦須承擔額外責任。

誰為你的代理程式搜尋網絡？Otari 讓選擇變得明確

在其 代理程式搜尋分析中，Mozilla AI 描述了三種選擇：由 Otari 營運的搜尋、客戶自己的搜尋帳戶，或自行託管的端點。該公司列出 Brave、Exa 及 Tavily，作為客戶可利用自己憑證連接的服務。

Mozilla AI 表示，客戶可保留 Claude、GPT 或 Gemini，同時更改處理搜尋的服務。搜尋憑證會留在閘道——即負責路由請求的中介層——而不會傳送給代理程式。該公司亦描述了與模型使用情況相關的工作區控制及搜尋記錄。

關鍵改變在於，讓團隊可將搜尋視為獨立於模型而自行選擇的依賴項。

當應用程式呈現單一答案框時，這個區別很容易被忽略。使用者提出問題、等待，然後收到附有引文的回應。即使由不同服務執行檢索與推理，介面仍可令兩者看似同一項操作。

將這些操作分開，會改變買家評估系統的方式。模型評估回答的是模型是否能遵循指示及有效推理。搜尋評估則探討系統能否檢索合適證據、恰當處理查詢，以及是否支援機構的營運要求。

兩種評估均不能取代另一種。再好的推理，也無法找回從未進入證據集的文件。強大的檢索，亦無法防止每一個缺乏支持的結論。分開看待兩者，讓團隊可更清楚地調查故障，而不會將所有問題歸咎於模型。

Mozilla AI 的文章亦應被準確理解為對產品方向及已記錄能力的說明。其發佈日期並不能證明每項底層功能何時已可使用。該公告亦不能證明客戶已經取得更佳答案或更低營運成本。

因此，眼前的新聞範圍比「代理程式搜尋已被解決」的說法更窄。Mozilla AI 正讓搜尋供應商成為採購及架構討論中明確的一環。這為接受隨所選模型附帶的檢索服務，提供了一個實際替代方案。

對已滿意於綑綁搜尋的團隊而言，替代方案需要證明其營運負擔合理。對因不可接受的搜尋安排而受阻的團隊而言，分離這項依賴處理的是完全不同的問題。他們需要的是可供評估的選擇，而不是另一個模型排行榜。

查詢本身值得審視

即使所求答案涉及公開資訊，搜尋查詢仍是一種向外披露。

設想一個假設情境：編程助手正調查軟件故障。有用的公開查詢可能會描述錯誤訊息及程式庫版本。不必要地具體的查詢，則可能還包括內部服務名稱、客戶識別資料，或尚未發佈的專案名稱。

區別在於甚麼資訊離開了機構，而不是公開文件是否可安全閱讀。助手即使有正當理由進行搜尋，仍可能構造不恰當的查詢。選擇搜尋供應商處理的是接收者；審查查詢構造處理的則是內容。

這種分離對工程經理及企業買家很重要。批准某個模型，並不能回答附連於它的工具的每一個問題。每項額外服務都引入值得獨立評估的營運關係，尤其在查詢源自私密工作脈絡時。

合理的做法是追蹤實際任務。哪些資訊進入提示？哪些文字變成搜尋查詢？哪項服務收到它？返回了甚麼結果，而當中哪些結果影響了答案？

這些問題令採購討論更具體，也揭示一項主張的界線。知道目的地，能確立對路由的可見性；但不能證明每個查詢均屬必要、措辭恰當，或受可接受的處理條款保障。

同樣的推理亦適用於客戶研究。想像一名助手正為潛在客戶準備簡報。公開公司資訊本應是研究過程的一部分。私人銷售備註、擬議合約措辭及內部評估，則應在出現在外部查詢前另作決定。

這些是說明性情境，而非已有文件記載的 Otari 客戶部署案例。其價值在於顯示，搜尋選擇的重要性不止於開發者偏好。一項看似普通的查詢，可能跨越最終答案無法揭示的界線。

知識工作者亦需區分公開探索與搜尋自己的資料。一個 個人知識庫 所處理的資訊需求，與尋找新的公開來源不同。有效的工作流程應在決定到哪裏搜尋前，先識別任務需要哪一類證據。

對產品經理而言，這可能代表先查閱內部研究，才索取最新競爭對手資訊。對工程師而言，這可能代表先核對私密設計決策，才查找公開文件。重點是有目的地檢索，而不是將每個不確定之處都送到開放網絡。

這對批准代理程式部署的人帶來壓力。他們需要足夠可見性，以說明資訊路徑及其限制。能揭示搜尋目的地的產品可協助作出這種說明，但機構仍須決定哪些資訊應出現在這條路徑上。

誰為你的代理程式搜尋網絡？對買家而言，足夠的答案包括營運者、相關協議，以及所傳送資訊的範圍。只說出一個知名模型的名稱，仍未完整回答當中的搜尋部分。

綑綁搜尋提供便利，而獨立搜尋增加問責

綑綁搜尋最有力的理由是便利。開發者可獲得受支援的工具介面，而毋須自行組裝檢索的每一部分。當機構的要求符合供應商服務及已記錄行為時，可能會偏好這種安排。

Anthropic 的 網絡搜尋工具 展示了整合式做法。Claude 決定何時搜尋，服務執行搜尋，最終回應則包括引文。其文件亦描述了網域控制及不同工具版本。

這些能力之所以重要，是因為可配置搜尋並非獨立閘道獨有。客戶應區分對搜尋行為的控制，與對搜尋供應商的控制。供應商可以提供實用限制，同時仍負責營運底層服務。

核心選擇在於，誰擁有檢索決策，以及誰承擔維護相關安排所需的工作。

Otari 的主張吸引希望掌握該所有權的團隊。但獨立性也帶來由綑綁服務吸收或簡化的責任。必須有人管理憑證、評估服務行為、調查故障，以及維持代理程式與其搜尋工具之間可運作的關係。

Ollama 提供了另一個有用對照。其 託管式網絡搜尋 文件說明了向 ollama.com/api/web_search 發出的已驗證請求。回應包括含有頁面標題、網址及內容摘要的結果。

這個例子確立了一個有限但重要的觀點：使用本機模型，並不代表其網絡搜尋也留在本機。已記錄的搜尋請求會到達託管服務。客戶在評估處理位置時，需分別檢視推論、搜尋及頁面擷取。

這並非證據顯示託管搜尋本質上不合適。當條款、行為及可靠性符合機構需要時，託管服務可以是可接受的選擇。真正的失誤是，假定某一項架構選擇會自動決定所有其他組件。

同樣的紀律亦適用於答案品質。更改搜尋服務會改變模型可取得的證據。同時更改模型與搜尋的評估，難以清楚說明是哪項改變改善或損害了結果。

分開這些變數，能支持更具資訊價值的比較。團隊可固定模型來檢視檢索，然後固定證據來檢視綜合。這類評估仍需謹慎設計，但可避免將整個應用程式視為不可分割的黑箱。

因此，Otari 網絡搜尋評估應從團隊自身任務開始。公開文件查找、近期公司研究及專門技術探索，可能需要不同證據。若要聲稱某項搜尋服務普遍最佳，便需要超越個別工作負載的證據。

Mozilla AI 的公告沒有提供任何獨立比較研究，以確立這類贏家。更有力的解讀是，客戶應能選擇及測試這項依賴。這是支持控制與評估的論點，而非已證明的搜尋引擎排名。

壓力同時落在兩種做法上。綑綁供應商需要足夠清楚地解釋其搜尋安排，讓買家能作評估。獨立基建則需展示，在客戶端、模型及工具介面改變時，額外控制仍然可用。

Otari 網絡搜尋取決於保留客戶端的預期

可配置的搜尋服務，只有在代理程式能正確使用時才有幫助。應用程式所預期的不只是連結清單。它們依賴可辨識的工具回應、錯誤行為，以及足夠的來源資訊以繼續完成任務。

Otari 的 搜尋攔截文件 描述了在啟用攔截時，接管受支援、以供應商命名的搜尋宣告。攔截是指處理原本會傳送至供應商工具的請求。文件將這種行為與轉送供應商原生請求作出區分。

它亦說明工作區限制，包括停用搜尋、限制結果數量及縮窄網域範圍。文件警告，隨附的 SearXNG 設定對持續使用設有速率限制。相較於短暫示範，這項警告在評估是否適合投入生產環境時尤其重要。

保留介面可減少整合工作，但不代表行為完全一致。

客戶端可以接受回應，卻取得不同的證據。它亦可能正確處理成功的查詢，但對服務不可用的情況反應不佳。因此，兼容性必須涵蓋日常運作，以及會中斷運作的情況。

一項假設性的程式開發任務可突顯箇中差異。助理搜尋遷移指南、閱讀結果，然後提出程式碼修改建議。一項有用的評估會檢視，取得的指南是否符合相關軟件版本，以及是否支持所建議的修改。

即使搜尋沒有返回結果，同一項任務亦應保持可理解。能清楚報告缺乏證據的代理，與即興編造答案的代理表現不同。閘道的回應格式固然重要，但客戶端如何理解失敗情況亦同樣重要。

正因如此，只以答案流暢度作比較會造成誤導。一段修飾精緻的解釋可能掩蓋薄弱的證據；而一個較不圓滑、但能指出自身限制的回應，對影響深遠的技術決策可能更有用。

Otari 的搜尋設定記錄了具名搜尋實例及預設選擇。它亦說明供應商專屬設定及憑證要求。這些細節顯示，搜尋獨立性是一項營運設定，而不只是提示詞中表達的偏好。

對平台團隊而言，設定帶來熟悉的維護問題：誰可更改預設值？變更如何傳達至不同工作區？甚麼證據可證明請求使用了預定服務？答案決定了控制權能否經受日常組織運作的考驗。

某項設定可以存在，卻未必成為有效政策。評估需要確定實際部署設定下會發生甚麼，包括允許的例外情況。否則，可選搜尋的示範可能被誤當作對每個生產請求的保證。

當應用程式有多種途徑取得外部資訊時，這項區別尤其重要。搜尋工具、頁面擷取工具及瀏覽器可代表不同路徑。控制其中一條路徑，並不等於控制全部路徑。

這項觀察屬於架構考量，並非指稱 Otari 存在某種特定繞過方法。買家應要求與其客戶端及已啟用工具相符的涵蓋證據。「所有代理流量」等籠統說法，需要比一次成功攔截的搜尋更廣泛的驗證。

這個機制具潛力，因為它將路由決定置於模型判斷之外。其實際價值取決於周邊應用程式是否一致地使用受控制的路由。評估必須追蹤完整任務，包括預期路由失敗的時刻。

自行託管會改變責任，卻不會消除依賴關係

自行運行搜尋中介服務，並不代表在運行獨立的網絡索引。

SearXNG 的元搜尋架構會整合其他搜尋引擎的結果。這使自行託管的意義更為精確：組織可自行運行聚合服務，但結果仍依賴上游搜尋引擎。

對使用 SearXNG 的 Otari 部署而言，這項區別可避免誇大私隱主張。營運者可控制其實例，但實例設定的上游關係仍然重要。完整評估會追蹤查詢越過組織首部伺服器後的去向。

這是檢驗更廣泛訊息的一項實用懷疑測試。若自行託管被描述為完全獨立，元搜尋會令這項承諾變得複雜；若它被描述為對明確組件的控制，主張就較狹窄，亦較易評估。

同樣的嚴謹態度亦應適用於成本比較。移除隨附搜尋服務的收費，並不會移除營運檢索服務的工作。即使並非以每次查詢帳單呈現，基礎設施、維護、事故應對及員工投入時間都應納入評估。

這裡沒有依據宣稱自行託管必然較便宜。相關比較取決於工作負載、服務要求及組織既有能力。已在營運相關基礎設施的團隊，與缺乏該等專業知識的團隊，面對的是不同決策。

憑證控制亦需要精確理解。讓憑證遠離代理，可減少其中一條暴露途徑；持有該等憑證的服務仍是敏感系統，需要適當管理及存取控制。

搜尋紀錄帶來另一項取捨。它們可協助解釋代理為何產生某個答案，但亦可能保留敏感的查詢文字。尋求問責性的組織，應決定誰可查閱這些紀錄，以及它們在多久內仍具效用。

因此，更高可見性本身亦帶來管治工作。詳細紀錄並非在所有情境下都必然更好。目標是在調查時提供足夠證據，同時制定與紀錄所含資訊相稱的處理規則。

網域限制同樣只有有限價值。它們可限制合資格來源的範圍，卻不能證明來自獲允許網域的每一頁都準確、最新，或適合特定任務。

選擇搜尋供應商亦不能解決提示詞注入問題，即為重定向助理行為而設計的惡意內容。取得的頁面仍是外部輸入；代理必須將它們當作需要評估的證據，而非對其任務具權威的指令。

這些限制並不否定獨立搜尋的理據，而是界定該理據可以支持甚麼。選擇某項依賴服務，讓組織有地方可行使判斷；卻不保證其判斷必然正確。

可信的成果，是對可辨識選擇承擔更大責任。買家可問：為何選擇某項服務？甚麼假設支持該選擇？甚麼情況會觸發變更？即使最終選擇的是受管供應商，這些問題仍然有價值。

Otari 網絡搜尋部署應按這些具體責任評判。公告本身並不能證明檢索效果更佳、具普遍兼容性，或可帶來完整私隱成果。來自團隊實際環境的證據，必須承擔這些結論。

留意兼容性、比較證據及供應商披露

下一個報道期應聚焦於可觀察的變化，而非對更開放 AI 技術棧的承諾。直至 2026 年底及 2027 年初，有用訊號將關乎獨立搜尋是否變得更易營運及更易評估。

最有力的證據，會展示在真實任務中可靠的控制能力，包括失敗及變更情況。

首個訊號，是針對團隊實際使用的客戶端及工具介面，公開兼容性證據。一個有用的版本發布會列出已測試行為、支援版本及已知限制。可重現的例子會加強以下論點：客戶可在更換搜尋服務時保留其應用程式。

相反，反覆出現的客戶端專屬權宜方案，會削弱獨立性的實際主張。若每次替換都需要大幅修補應用程式，理論上可替換的服務提供的自由便相當有限。隨着周邊軟件演變，兼容性仍須保持可理解。

第二個訊號，是採用受控工作負載的比較評估。維持模型及任務不變，然後檢視檢索相關性、新鮮度、回應時間、失敗情況及整體營運工作量。結果應指出每種安排適用的地方，包括隨附搜尋仍較可取的情況。

一項令人信服的評估，會公開足夠細節，讓讀者理解其界限。從文件查詢得出的結果，不應延伸成對每項研究任務的主張。選擇性效益的證據，會比無從解釋的整體優越宣言更可信。

第三個訊號，是隨附服務供應商提供更清晰的披露或額外供應商選擇。更明確的文件可協助客戶評估現有服務，而無須採用另一個中介服務。獲供應商支援的選擇，亦可檢驗客戶主要是希望獨立，還是只希望有更清晰的控制。

這種發展會加強 Mozilla AI 的核心論點，同時改變 Otari 的競爭位置。即使買家在其他地方行使這項選擇，搜尋仍會成為更明顯的採購決策。長遠問題在於：誰可作出決定並解釋該決定。

誰為你的代理搜尋網絡？隨着這些訊號發展，答案應變得更具體。它應指出實際資訊路徑及支持其使用的證據，而非依賴從模型名稱推斷出的假設。

在擴展代理工作流程前，應檢視一項具代表性的任務，從提示詞直至最終答案。識別外發查詢、其接收方、返回來源及支持結論的證據。然後問：這項安排是否符合工作的敏感度及目的？當隨附搜尋的已記錄行為符合這些需要時，便保留使用它；當供應商選擇、營運控制或更清晰紀錄可滿足具體要求時，便評估獨立搜尋服務。對於結合私有知識與公開研究的任務，應明確檢視該邊界，而非將每次查詢視作相同。下一步應是你的團隊能夠解釋的決定：這個代理應使用哪項搜尋服務，以及甚麼證據證明該選擇合理？