目錄
這篇的目的不是說「Groundlane 比傳統方案好」，而是把差異放在可驗證的維度上：確定性（結果是否可逐行解釋）、可替換性（更換來源時需要改多少程式碼）、身份邊界（認證與資源限制在誰的邊界內）、維運成本（每次執行需要管理什麼）。所有比較均以 v0.1.0 可驗證功能為基準，不引入假設的未來改進。
比較維度（先定義，再對照）
為了讓比較可重現，先明確四個維度的定義（這些定義來自實際操作場景，而非抽象理論）：
- 確定性：每個輸出結果是否對應一個可驗證的輸入與處理步驟。若結果依賴隱式模型推論（例如「從這頁找出標題」），確定性較低；若結果對應明確的 CSS selector 或固定解析邏輯，確定性較高。
- 可替換性：更換檢索或擷取來源時，代理端需要修改的範圍。若每個來源有獨立的工具 schema 與解析邏輯，可替換性較低；若所有來源共享同一合約，可替換性較高。
- 身份邊界：認證憑證、資源限制、錯誤處理的責任歸屬。若這些邊界混合在代理流程中（例如代理腳本直接持有各提供者的 API 金鑰），身份邊界較模糊；若邊界明確分離（例如遠端 MCP 層管理認證與限制），身份邊界較清晰。
- 維運成本：每次執行需要管理的操作步驟（例如瀏覽器啟動、代理輪換、錯誤重試、結果驗證）。若這些步驟由遠端層統一處理，代理端的維運成本較低；若代理端需要自行管理，維運成本較高。
這四個維度不是互斥的評分，而是不同場景下的權衡點。例如，一個小型內部腳本可能不需要高可替換性（因為來源固定），但需要低維運成本（因為執行頻率低、無需大規模管理）。相反，一個需要長期維護、多來源驗證的流程，則需要高確定性與清晰的身份邊界。
傳統方案的實際行為（依據站內現有工具）
站內已存在的工具（WebFetch、stealth_fetch、puppeteer 相關流程、requests 直接調用）各有明確的行為模式，這些模式可以直接對照 Groundlane 的三工具：
WebFetch：內建的網頁擷取工具，通常返回內容摘要與部分結構化資訊。它的優勢在於與站內流程整合簡單（無需額外部署），但缺點在於：無統一 MCP 合約（每次調用的參數與回傳格式可能隨版本變化）、無雙認證邊界（認證與限制混合在站內流程中）、無提供者替換機制（若需要切換來源，通常需要修改調用邏輯或增加額外步驟）。stealth_fetch：隱匿式擷取工具，適合需要繞過簡單反機器人機制的場景。其優勢在於隱匿性，但缺點在於：無結構化 selector 擷取（無法執行確定性的 CSS 選擇器提取）、無確定性來源證據欄位（無engine、backend、finalUrl的明確標註）、身份邊界與WebFetch類似（混合在站內流程中）。puppeteer直接控制：透過程式碼控制瀏覽器執行，適合需要完整互動流程（例如點擊、捲動、表單提交）的場景。其優勢在於互動完整性，但缺點在於：維運成本高（每次執行需要啟動瀏覽器、管理資源、處理渲染時間與錯誤）、確定性較低（渲染結果受瀏覽器版本、網路延遲、頁面動態行為影響）、無統一合約（每個代理端腳本需要自行管理參數與解析邏輯）。requests直接調用：最直接的 HTTP 客戶端調用，適合簡單靜態頁面。其優勢在於簡單與低成本，但缺點在於：無結構化擷取（需要自行解析 HTML）、無確定性邊界（認證與限制由代理腳本自行管理）、可替換性低（每個來源的解析邏輯通常不同）。
這些方案的共通點在於：它們都適合特定場景（小規模、固定來源、低頻率執行），但在需要長期維護、多來源驗證、明確身份邊界的場景中，會暴露維運成本與確定性風險。
Groundlane 的實際行為（依據 v0.1.0 可驗證功能）
Groundlane 的三工具（web_search、web_fetch、web_extract）提供統一的 MCP 合約，這意味著：
- 確定性較高：
web_extract以 CSS selector 為確定性來源，每個結果可逐行解釋；web_fetch提供明確的來源證據欄位（engine、backend、finalUrl）；web_search保留各提供者的原始排名與 RRF 合併邏輯，可驗證合併過程。 - 可替換性較高：所有搜尋來源共享同一
web_search合約，更換提供者時只需修改參數（提供者列表或自動模式），而非重寫解析邏輯。同樣地，web_fetch與web_extract對任何可直接存取的 URL 使用相同合約，無需為每個來源設計獨立解析流程。 - 身份邊界較清晰：認證（
GROUNDLANE_AUTH_TOKEN、OAUTH_OWNER_PASSPHRASE）與預設限制（URL 政策、DNS 檢查、單一期限、位元組與輸出上限、併發限制、搜尋預算）由遠端 MCP 層統一管理，代理端不需要持有各提供者的 API 金鑰或自行管理限制邏輯。 - 維運成本較低（對代理端而言）：代理端只需要知道如何呼叫三個 MCP 工具（參數組合與預期回傳結構），而不需要管理瀏覽器啟動、代理輪換、錯誤重試、結果驗證等操作步驟（這些由遠端層統一處理）。但這並不意味著「零成本」：遠端層本身需要部署、維護與監控（本機 Node、Docker、Cloudflare 部署），這是維運成本的轉移，而非消除。
值得重申：這些優勢僅在 v0.1.0 可驗證功能範圍內成立。例如，自動搜尋的提供者選擇邏輯可能隨配置與網路狀態變化，瀏覽器渲染的結果受瀏覽器版本與頁面動態影響，預設限制是安全邊界而非可調整的性能參數。因此，這些比較應理解為「在目前可驗證的邊界內，這些差異存在」，而非「在所有未來版本中，這些差異永遠成立」。
四維度對照表（簡要，不完整）
| 維度 | 傳統本機方案（WebFetch / stealth_fetch / puppeteer / requests） | Groundlane 三工具（v0.1.0） | 備註（可驗證限制） |
|---|---|---|---|
| 確定性 | 低至中（依賴解析邏輯與渲染結果，無統一證據欄位） | 高（web_extract 確定性選擇器、web_fetch 來源證據欄位、web_search 原始排名與 RRF 證據） | 確定性高不代表「永遠正確」；若目標 DOM 變化，選擇器結果會不一致，這是確定性與穩定性的區別 |
| 可替換性 | 低（每個來源通常需要獨立解析邏輯與參數管理） | 高（統一 MCP 合約，提供者替換僅需修改參數） | 可替換性高不代表「無需驗證」；更換提供者後仍需驗證回傳結構與來源證據 |
| 身份邊界 | 模糊（認證與限制混合在代理流程中，代理腳本持有各來源憑證） | 清晰（遠端層統一管理雙認證與預設限制，代理端不持有提供者金鑰） | 清晰邊界不代表「無風險」；遠端層仍需妥善部署與監控（本機、Docker、Cloudflare），否則邊界本身成為單點風險 |
| 維運成本（代理端） | 中至高（需管理瀏覽器、代理、錯誤重試、結果驗證） | 低（代理端僅呼叫三個工具，操作步驟由遠端層統一處理） | 低代理端成本伴隨遠端層部署與維護成本；這是成本轉移，不是消除 |
這個表格的目的不是給出「最終評分」，而是提供可執行的對照依據：你可以根據實際場景（小規模固定來源 vs. 長期多來源驗證流程）的需求，選擇對應維度作為決策重點，而非依賴抽象的「好壞」判斷。
各方案適合與不適合的實際場景
基於目前可驗證的功能與限制，以下場景描述是可執行的操作建議（非未來承諾）：
WebFetch適合：與站內流程緊密整合的小規模、低頻率檢索需求（例如單次內容預覽、簡單參考驗證），且不需要多來源對照或確定性證據欄位的場景。不適合：需要長期維護、多來源驗證、明確身份邊界的流程（因為認證與限制混合在站內流程中，維運成本隨時間累積）。stealth_fetch適合：需要隱匿性且內容簡單（無需結構化選擇器擷取）的場景。不適合：需要確定性結構化擷取（無fields選擇器機制）、明確來源證據（無engine/backend標註）、或長期可重現驗證的流程。puppeteer直接控制適合：需要完整互動流程（點擊、捲動、表單提交）且執行頻率低、可接受高維運成本的場景。不適合：需要低維運成本、高確定性、統一合約的長期自動化流程（因為每次執行需管理瀏覽器啟動、渲染時間、錯誤重試，且結果確定性受多因素影響）。requests直接調用適合：目標為簡單靜態頁面、解析邏輯固定、來源單一且低頻率執行的場景。不適合：需要多來源對照、結構化選擇器擷取、明確身份邊界的流程（因為每個來源需獨立解析邏輯，認證與限制由腳本自行管理）。- Groundlane 三工具適合：需要統一 MCP 合約、明確身份邊界（遠端層管理認證與限制）、確定性來源證據（
engine/backend/finalUrl）、可替換提供者（僅修改參數而非重寫邏輯）的長期流程。不適合：需要完整互動流程（例如點擊、表單提交）的場景（因為web_fetch的瀏覽器渲染僅支援讀取與等待，不支援互動操作）、或不願意承擔遠端層部署與維護成本的場景（因為低代理端維運成本伴隨遠端層責任轉移，而非消除）。
這些「適合」與「不適合」的判斷，應理解為「在目前可驗證的功能與限制範圍內，這些場景描述成立」，而非「在所有未來版本中，這些判斷永遠有效」。若未來版本增加互動支援、改變預設限制、或調整合約行為，這些場景描述應重新驗證。
整體取捨與選擇建議
基於本篇與前兩篇的內容，一個可執行的選擇流程（非唯一方案，而是基於目前可驗證事實的建議）：
- 確認場景需求：是小規模、固定來源、低頻率的檢索（適合傳統本機方案），還是長期、多來源、需要確定性證據與明確身份邊界的流程（適合 Groundlane 遠端合約）？
- 驗證功能邊界：確認所需功能（例如結構化選擇器擷取、瀏覽器渲染、多來源合併、確定性證據欄位）在
v0.1.0可驗證範圍內存在，且對應限制（預設邊界、預算、確定性依賴 DOM 穩定性）可接受。 - 評估維運責任分配：若選擇 Groundlane，確認遠端層的部署與維護責任（本機、Docker、Cloudflare）已明確分配；若選擇傳統方案，確認代理端腳本的維護責任（解析邏輯、認證管理、錯誤重試）可接受。
- 執行小範圍驗證：無論選擇哪種方案，先執行小範圍測試（僅關鍵參數與回傳結構），保存參數與結果，驗證確定性與可重現性，然後再擴展到完整流程。
這個流程不依賴未來功能承諾，僅依賴目前可驗證的合約與限制，因此可在 v0.1.0 下安全執行，並在未來版本更新時透過保存的參數與結果進行對照驗證。
參考資料
- Groundlane GitHub 原始碼（v0.1.0 自述與文件結構） — 三工具合約、十適配器、預設限制與預算語義
- .claude/skills/groundlane 技能（站內 MCP 工具路由）
- 站內現有工具（
WebFetch、stealth_fetch、puppeteer相關流程、requests直接調用）的實際行為與限制（依據站內技能與現有文章描述，而非推測） - Groundlane 安全說明（SECURITY.md） — SSRF 風險、身份邊界、預設安全限制
Loading...