Open Scouts：開源 AI 網頁監控平台，把搜尋與提醒做成排程任務

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Open Scouts 是 Firecrawl 官方在 GitHub 維護的開源網頁監控平台，把一段自然語言查詢變成會定期執行的 Scout 任務，背後由 GPT-4 規劃搜尋策略、Firecrawl SDK 負責抓網頁、Supabase 排程與資料庫撐起排程與儲存，再透過 Resend 寄出 HTML 格式的提醒信。它想做的是把 Google Alerts 那種關鍵字通知，升級成可以描述「我要追蹤什麼變化」的 AI 監控工作。這篇文章給的是認識，不是把它裝起來跑三個月的評測：內容以官方倉庫的 README、.env.example、package.json 與 GitHub API 的授權端點為事實來源，跑起來的實際表現、回應速度與各種抓取涵蓋率，仍需要讀者自己驗證。

Pin

一個 Scout 任務的內部依賴：四個服務串在一起

從 package.json 與 README 的依賴清單可以看出 Open Scouts 的工作假設：Next.js 15.2.6 與 React 19 構成前端介面，@mendable/firecrawl-js 4.5 版負責網頁搜尋與內容擷取，ai 套件（OpenAI SDK 5.0）擔任 GPT-4 agent 與 embeddings，@supabase/supabase-js 2.81 處理資料庫、認證與排程，Resend 處理郵件。換句話說，它不是一個把所有事情做在自己的工具，而是一個把四個外部服務用 Scout 任務這個抽象包起來的調度層。Scout 任務的核心邏輯也來自這層依賴：使用者用自然語言描述要監控的目標，GPT-4 agent 自動產生搜尋查詢，Firecrawl 負責把候選網頁抓回來，agent 再用函式呼叫挑出相關結果並產生一句語意摘要，搭配向量 embeddings 存進 Supabase，最後有結果就透過 Resend 寄信。

排程與隔離是這套架構兩個會直接影響你怎麼用的決策。README 的「Scalable Dispatcher Architecture」段落寫得相當明白：dispatcher 是 PostgreSQL 層的 pg_cron 工作每分鐘跑一次，檢查哪些 Scout 到期，再用 pg_net 對 Supabase Edge Function 發 HTTP 請求，每一個 Scout 在獨立的 edge function 執行個體裡跑，配 256MB 記憶體與 400 秒 timeout。另外有一個獨立的清理工作每五分鐘掃一次卡住的執行紀錄。這個設計的好處是 scout 之間不會互相阻塞，也比較容易橫向放大；對使用者的實際影響是，單次 Scout 能處理的範圍被 400 秒這個數字框住，想要一次掃完整個品類的數千個頁面，並不是它預設擅長的任務。

Pin

資料隔離與金鑰管理也寫在 README 裡。所有資料表都套了 Supabase 的 Row Level Security（列層級權限），使用者只能讀自己的 Scout、訊息與執行紀錄；Firecrawl API 金鑰的設計則有兩條路徑，官方建議的做法是每個使用者自己在設定頁填入個人的 Firecrawl key，使用量計到各自的 Firecrawl 帳號，另一條是自架者提供一組共用金鑰給所有使用者。把這幾條官方敘述拼起來，可以看出 Open Scouts 在架構上把成本與責任分攤到各個外部帳號，平台本身不吸收任何一條 API 帳單。

官方資料看得到什麼、看不到什麼

這篇文章的接觸層級只到官方倉庫文件為止，沒有實際安裝 Open Scouts、沒有跑過任何 Scout、也沒有造訪 demo 站 openscouts.firecrawl.dev 驗證目前是否可用。讀者要明白這個限制：官方資料足以說明工具的依賴、架構與設定需求，能證明「這個能力存在」，但不能用來支持效果、穩定度或與其他監控工具的真實差異。舉例來說，README 標榜 AI agent 自動產生搜尋策略，這是官方作者的宣稱，不是我們親眼看到 agent 對某個查詢做出了什麼判斷；同樣的，架構圖寫每分鐘 dispatch 一次、每個 Scout 配 400 秒，這些是 README 揭露的設計參數，不是實測出來的瓶頸。

這個誠實邊界也意味著 Open Scouts 不該被當成 Google Alerts 或 Feedly 這類 RSS 閱讀器的 直接替代品來推銷。Google Alerts 的優點是免費、設定秒殺、覆蓋整個 Google 索引；Feedly 走 RSS 訂閱模型，速度與涵蓋取決於來源有沒有提供 RSS。Open Scouts 的價值主張完全不同：用 AI agent 做語意判斷、用 Firecrawl 做網頁擷取、自己掌握排程與資料。代價是你要自架、要備好三條 API 金鑰、且每一次 Scout 都在燒外部服務的額度。把它當「加強版 Google Alerts」之前，得先確認這個交換對你的使用情境值得。

README 寫 MIT，但倉庫沒有 LICENSE 檔案

授權狀態是這次查證最值得點出來的一條。README 末尾「License」段落寫著 MIT，看起來是標準的開源專案；但實際進入倉庫根目錄列出所有檔案，找不到任何一個名為 LICENSE 或 LICENSE.md 的檔案，.gitignore 與 .gitattributes 都在，獨缺授權檔。對應到 GitHub API：呼叫 /repos/firecrawl/open-scouts/license 回傳 404 Not Found，呼叫 /repos/firecrawl/open-scouts 取回的 license 欄位是 null，stargazers_count 是 1350、forks_count 189、最後一次 push 的時間戳記是 2026-05-22。

這個落差值得停下來解釋。軟體授權的法律效力來自授權條款文字本身是否隨程式碼附上，README 寫一行「MIT」傳達了作者的意圖，卻不等同於已經把 MIT 授權條款的完整文字以 LICENSE 檔案的形式放進倉庫。在沒有授權檔的情況下，預設狀態其實是 All Rights Reserved，也就是其他人原則上沒有重製、修改或商用的權利。Firecrawl 是活躍的開源組織，作者意圖相當清楚是 MIT、補上 LICENSE 檔應該只是一個 commit 的差距，但對打算把 Open Scouts 用於正式產品的公司或團隊來說，這條空白仍是一個會影響決策的授權風險，正式採用前至少應該開 issue 向作者確認、或等授權檔補上再下手。

專案活躍度也是同理。1350 顆星、189 個 fork 在這個品類的開源專案裡算是有一定關注度，但最後一次 push 距離現在已經有兩個多月，README 也提到 Partner Integration 功能「目前是 closed beta、只開放企業客戶」。這兩條訊號說明 Open Scouts 還在迭代、但節奏不算激進，把它當生產級監控之前，最好先觀察一兩個月的 commit 頻率與 issue 處理速度。

自架前要先算進去的幾條成本

Open Scouts 本身的程式碼可以免費取得，但每跑一個 Scout 都會牽動三條外部帳單，這是它與 Google Alerts 或 Uptime Robot 這類監控服務最大的成本結構差異。Firecrawl 這一條最容易看到：.env.example 把 FIRECRAWL_API_KEY 列為必填欄位，支援標準 key（fc-xxx）或 partner key 兩種模式，README 明文建議每個使用者自己到設定頁填入個人的 Firecrawl 金鑰，使用量追蹤到各自的帳號；Firecrawl 本身有免費額度，超過之後要付費，Scout 跑得越勤、抓得越多，這條帳單成長得越快。

OpenAI 這一條隱藏得更深一些。OPENAI_API_KEY 同樣在 .env.example 必填欄位之列，README 寫它用於 Scout 設定階段的 chat、後續 agent 的函式呼叫，以及每次執行後產生一句語意摘要時的 embeddings。GPT-4 與 embeddings 都按 token 計費，Scout 越多、每次抓的頁面越多、摘要向量越密集，OpenAI 的費用就越可觀，這條帳單不會出現在 Firecrawl 的儀表板裡，卻一樣會在月底結算。Resend 這一條是郵件通知的成本：.env.example 把 RESEND_API_KEY 列為可選欄位（註明留空就停用郵件通知），RESEND_FROM_EMAIL 的預設值是 Open Scouts <[email protected]>，這是 Resend 的 sandbox 位置；README 在「Free Tier Limitations」一段寫得很明白，免費層每月 3000 封、每日 100 封，沒有驗證自有網域時只能寄到自己 Resend 帳號的 email，要寄給其他人就得到 resend.com/domains 驗證網域。

另外還有一條成本不算帳單，卻會直接決定你能不能把它跑起來：Supabase 自架門檻。README 的設定流程要求你先在 supabase.com 建一個專案、啟用 vector、pg_cron、pg_net、supabase_vault 這幾個延伸模組，再用 Supabase CLI 把專案連回來、執行 bun run setup:db 讓腳本自動建資料表、同步 secrets 與部署兩個 edge function（scout-cron 與 send-test-email）。Supabase 有免費方案，但免費方案的 edge function 調用次數、資料庫容量與 cron 數量都有上限，使用量較大的監控工作可能較快面臨升級壓力。對已經熟悉 Supabase 的人這條門檻很低，對只在共享主機跑過 WordPress 的人則是一個完全不同的部署模型。

把這幾條加起來看，Open Scouts 比較接近一個「開源的監控框架」而不是「免費的監控產品」：原始碼免費、但每一次執行都是使用者自掏腰包養四個外部服務，而且要有一個人願意顧 Supabase 專案與 edge function 部署。對個人開發者想做側邊專案、或團隊已有 Supabase 與 OpenAI 帳號要內部監控，這個成本結構很合理；對只是想免費收到關鍵字通知的輕度使用者，像 RSS 加 AI 摘要這類聚合器或原本的 Google Alerts 會是現實許多的選擇。

「自動搜全網」的實際範圍會被幾個數字限制

Open Scouts 的官方介紹常被外部文章形容為能「自動搜尋整個網路」，這個說法在技術上需要打折。從依賴與架構可以推回幾個會限制實際範圍的條件。搜尋與擷取這一層走的是 Firecrawl SDK，能找到的頁面取決於 Firecrawl 可抓取的範圍，封在登入牆、Paywall、JavaScript 重度渲染或反爬蟲保護後面的內容，未必進得來。單次執行這一層由 Supabase Edge Function 的資源限制框住，每次 Scout 只有 256MB 記憶體與 400 秒可以跑完所有 agent 判斷、抓取與摘要，超過就會被 cleanup 工作標成卡住。排程這一層的最低粒度是 README 提到的「每分鐘 dispatch 一次」，但每個 Scout 各自的頻率仍由使用者設定（每小時、每三天、每週等），不是無限密集。把這三條疊起來看，Open Scouts 適合追蹤「某個範圍裡有沒有出現符合條件的新東西」，不適合拿來做需要即時、完整、穿透登入牆的監控。

這個範圍限制不算缺點，比較像是設計選擇。Firecrawl 的可抓取範圍與 OpenAI 模型都會隨時間變動，這些都是會漂移的動態事實，不該寫死在評估結論裡。對讀者來說，比較務實的做法是把自己最想追蹤的一兩個查詢丟進 demo 站或自架實例，看回來的結果涵蓋哪些來源、漏掉哪些來源，再決定 Open Scouts 在自己的監控工作流裡要放在哪一層。和以 OSINT 為主題的監控儀表板相比，Open Scouts 走的是 narrower 的「主動搜尋與摘要」路線，而不是「整合多個資料來源呈現全景」那種定位。

怎麼用最低成本判斷值不值得進一步試用

如果讀到這裡還在考慮，有兩個不花錢的動作可以先做。第一個是直接造訪官方 demo 站 openscouts.firecrawl.dev，建立一個 Scout、用一個你最在意的真實查詢跑跑看（例如某個競品的名稱、某個技術關鍵字、某個政策議題），觀察回來的結果涵蓋哪些網域、AI 摘要的品質如何、多久會收到第一封郵件提醒。看見結果貼近你期待的覆蓋範圍，就值得進一步考慮自架；如果回來的東西明顯漏掉你預期該抓的來源，或摘要常常抓不到重點，那這個工具對你的情境就不是好選擇，無需再投入設定成本。

第二個動作是 clone 倉庫、打開 .env.example，把十個欄位看過一遍：NEXT_PUBLIC_SUPABASE_URL、NEXT_PUBLIC_SUPABASE_ANON_KEY、SUPABASE_SERVICE_ROLE_KEY（檔案裡特別標註它會繞過 RLS、不可 expose 到瀏覽器）、DATABASE_URL、OPENAI_API_KEY、FIRECRAWL_API_KEY、RESEND_API_KEY、RESEND_FROM_EMAIL、NEXT_PUBLIC_SITE_URL 與 NEXT_PUBLIC_VERCEL_URL。這份檔案比任何介紹文章都更能告訴你「這個工具實際上需要什麼」：如果你看到這十個欄位還想不到對應的帳號與金鑰從哪裡來，自架這條路目前對你可能還太早。能在這一步果斷判斷不適合，也是這篇文章想達成的價值之一。

最後一個會影響決策的變數是 LICENSE 缺檔那條。如果是個人側邊專案、純學習用途，等作者補上再跟進也不遲；如果是公司或團隊要把它放進正式產品流程，建議在採用前先到 GitHub 開一個 issue 或 discussion，請維護者確認授權意圖並補上 LICENSE 檔，這個小動作可以省掉日後法務往返的成本。Open Scouts 的設計理念與依賴選擇都有它的道理，把自己最在意的查詢丟進 demo、把 .env.example 看過一遍、確認授權風險，是三個能在投入自架之前就拿到判斷的低成本動作。