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

Facebook Line Messenger Telegram

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

同樣在 README 標 MIT、倉庫卻沒有 LICENSE 檔的情況，也出現在這篇Craft-Agent 開源框架評析點出的同一種落差，採用前都得先釐清授權。

Open Scouts 的 GitHub 倉庫頁面，顯示 1.4k stars、189 forks、最後一次 push 時間，以及根目錄檔案清單（可見 .env.example、README.md，獨缺 LICENSE 檔） — Open Scouts 倉庫首頁。1350 顆星、189 個 fork，根目錄可見 .env.example 與各種設定檔，獨缺 LICENSE 檔案。

一個 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 寄信。Firecrawl 生態系的其他工具，像是能用幾毫秒判斷 PDF 要不要 OCR 的 Firecrawl PDF Inspector，我們先前也介紹過。

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

Open Scouts README 的 Scalable Dispatcher Architecture 段落，顯示 pg_cron 每分鐘觸發 dispatch_due_scouts、透過 pg_net 發 HTTP POST 到各自獨立的 edge function（每個 scout 配 256MB 記憶體、400 秒 timeout）的排程架構 — README 揭露的 dispatcher 架構：pg_cron 每分鐘觸發、pg_net 對每個到期 Scout 發一個獨立 edge function，每次執行配 256MB 與 400 秒上限。

資料隔離與金鑰管理也寫在 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 適合追蹤「某個範圍裡有沒有出現符合條件的新東西」，不適合拿來做需要即時、完整、穿透登入牆的監控。如果需求偏向把抓取本身做成可重複執行的任務，BrowserAct 這類 AI 網頁抓取平台走的是另一條路線。

這個範圍限制不算缺點，比較像是設計選擇。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 看過一遍、確認授權風險，是三個能在投入自架之前就拿到判斷的低成本動作。

關於 Open Scouts 的三個常見問題

Open Scouts 是免費的嗎？

程式碼本身免費取得，但每跑一個 Scout 都在消耗外部服務的額度：Firecrawl 與 OpenAI 是必填金鑰、按用量計費，Resend 免費層每月上限 3000 封、每日 100 封，Supabase 免費方案也對 edge function 調用次數與資料庫容量設有上限。把它當「開源的監控框架」而不是「免費的監控產品」，會更接近它的真實成本結構。

Open Scouts 可以取代 Google Alerts 嗎？

定位不同，不是直接的替代關係。Google Alerts 免費、設定快、覆蓋整個 Google 索引；Open Scouts 用 AI agent 做語意判斷、用 Firecrawl 抓網頁、排程與資料都自己掌握，代價是要自架、備好 API 金鑰，且每次執行都在消耗外部服務額度。想把關鍵字通知升級成「描述我要追蹤什麼變化」的監控工作，才值得考慮它。