文／Laban（優創智能 AI 導入工程師）
REA 是讓 AI 代理在本機檢查程式、網站與 App 的開源逆向工程工具。我們用它對自家官網首頁做了一次實測。結論先講：對多數企業來說，REA 最實際的第一個用途不是破解什麼，而是看清楚「自己的網站在訪客打開時，到底載入了誰的程式」；這次實測單次載入就有 86 個請求、12 個來源。其他應用都可行，但每一個都要先回答「誰有權檢查這個對象」。
本文是應用篇，寫給想知道 REA 能做什麼的 IT 承辦人與行銷主管。REA 是什麼、合法界線在哪，請先看REA 是什麼？讓 AI Agent 拆解軟體的開源 MCP 工具；代理該被允許呼叫哪些 REA 工具，請看REA 工具標註與三級核准規則。本文不是法律意見。
一、實測：REA 看到我們官網首頁載入了什麼？
1. 實測口徑
2026 年 11 月 9 日，我們用 REA 6.7.0 的 capture-browser-scenario（網站情境擷取）打開 yotron-ai.com 首頁，條件如下：
| 項目 | 設定 |
|---|---|
| 瀏覽器 | REA 自行啟動的無頭 Chromium 156，臨時設定檔，結束後關閉 |
| 環境 | 視窗 1280×720、語系 en-US、時區 UTC、封鎖 Service Worker |
| 動作 | 打開首頁後等待 5 秒，不捲動、不點擊、不操作 Cookie 橫幅 |
| 記錄內容 | 只記網路請求的網址、類型與參數名稱；不記請求內容與標頭值（REA 預設） |
| 次數 | 單次載入 |
這個口徑的意思是：它代表「一位第一次來訪、什麼都沒點的訪客」看到的情況，不代表所有訪客。語系、時區、是否同意 Cookie，都可能改變載入的內容。
2. 結果
| 來源 | 請求數 | 說明 |
|---|---|---|
| yotron-ai.com（自家網域） | 71 | 其中 41 個是字型檔，為自架的思源黑體（Noto Sans TC）依字元切分的分片 |
| geo.yotron-ai.com（自家子網域） | 2 | 自家服務 |
| Google 相關（google.com、google.com.tw、Google Tag Manager、Google Analytics、DoubleClick） | 9 | 分析與廣告 |
| Cloudflare Web Analytics | 1 | 分析 |
| Ahrefs Analytics | 1 | 分析 |
| OpenAI（bzr、bzrcdn 兩個網域） | 2 | 依網域與參數判斷為廣告或量測相關，未進一步驗證用途 |
| 合計 | 86 | 12 個來源，其中 10 個是第三方網域 |
依類型分：字型 41、腳本 24、圖片 7、fetch 6、樣式表 3，其餘 5 個為文件、manifest、xhr 等。
3. 怎麼判讀這份結果
- 自家請求多數是字型：41 個字型請求是中文字型依字元切分後按需下載，屬於正常設計，不是問題；但它提醒我們，字型是首頁請求數最大宗，之後做效能調整時要先看這裡。
- 第三方網域有 10 個：每一個都代表訪客的瀏覽資訊會送到另一家公司。我們在報告中只看到參數名稱（例如 Google Analytics 的
cid、dl、dt），沒有記錄參數值，這是刻意的：檢查自己的網站，不需要留下訪客資料。 - 看不出誰載入了誰：REA 在結果的
limitations欄位寫明，情境擷取沒有請求發起者的呼叫堆疊，接收順序不代表因果。所以我們不能從這份報告判斷某個追蹤碼是被 Tag Manager 還是被其他腳本載入的，要另外對照埋碼設定。
這次實測給我們的行動項目只有一個：拿這 10 個第三方網域，對照行銷團隊的埋碼清單，確認每一個都有人知道、有用途、有負責人。這就是這個場景的價值。
二、REA 的 4 個企業應用場景
每個場景先回答同一個問題：這個對象，公司有權檢查嗎？
場景 1：盤點自家網站與 App 載入的第三方程式
| 項目 | 內容 |
|---|---|
| 誰有權檢查 | 公司自己的網站與 App，有權 |
| REA 做什麼 | 網站情境擷取、頁面腳本分析；App 可做靜態檢查 |
| 產出 | 第三方網域清單、請求類型、參數名稱 |
| 誰要看 | 行銷（追蹤碼用途）、IT（效能與資安）、個資窗口（隱私權政策是否列出） |
這是門檻最低、最常被忽略的場景。追蹤碼往往由不同時期的行銷人員或外包加上去，很少有人知道現在總共有幾個。
場景 2：了解沒有原始碼的舊系統或外包交付程式
| 項目 | 內容 |
|---|---|
| 誰有權檢查 | 依合約。公司擁有程式權利，或合約未禁止逆向工程時才做 |
| REA 做什麼 | 原生程式反編譯、.NET 組件檢查、Electron 應用的模組與 IPC 關係 |
| 產出 | 系統連到哪些外部服務、讀寫哪些檔案、匯出格式怎麼產生 |
| 誰要看 | 負責接手或汰換這套系統的工程師 |
常見情境是：外包商結束營運或不再維護，公司要汰換系統，卻沒人知道舊系統把資料存在哪裡、跟哪些服務連線。REA 能協助回答「資料怎麼搬出來」，目的是互通與遷移，不是複製對方的程式。
場景 3：資安事件中分析可疑檔案
| 項目 | 內容 |
|---|---|
| 誰有權檢查 | 公司在自家設備上取得的可疑檔案，有權；涉及他人系統時依調查授權 |
| REA 做什麼 | 字串、符號、呼叫關係；網路封包摘要 |
| 產出 | 檔案會連到哪些位址、可能做什麼動作 |
| 誰要看 | 資安負責人或外部事件處理團隊 |
一律在隔離環境分析，不要在日常電腦上執行可疑檔案。REA 的執行期擷取會以使用者權限實際執行目標，這點在可疑檔案上特別要小心。
場景 4：上線前檢查自家 App 或網站的實際行為
| 項目 | 內容 |
|---|---|
| 誰有權檢查 | 自家產品，有權 |
| REA 做什麼 | 比對兩個版本的網站擷取或 JavaScript 應用 |
| 產出 | 新版本多了哪些網路請求、哪些模組改變 |
| 誰要看 | 開發與 QA |
開發團隊加了一個新套件，可能順帶多了一個對外連線。用 REA 比對上線前後兩次擷取，可以在發布前發現這類變化。
三、不該用 REA 做的事
依 REA 專案自己的免責聲明，以下用途不在支援範圍，我們也不建議：
- 破解軟體授權、DRM、反作弊或其他技術保護措施。
- 把競爭對手 App 的功能逆向後，照著做成自己的版本。
- 繞過你沒有被授權測試的系統的登入、機器人防護或存取控制。
- 分析合約明文禁止逆向工程的軟體。
專案 README 的訴求是「看到喜歡的功能，就調查它怎麼做」。對企業來說，觀察公開行為和複製對方的實作是兩回事，後者可能涉及著作權與契約，請先諮詢法律專業。
四、5 步驟：把一次實測變成每季例行檢查
步驟 1：確認授權並寫下範圍
列出這次要檢查的網址或 App，確認都是公司自己的。網址清單建議包含首頁、主要服務頁、聯絡表單頁與結帳頁，因為不同頁面可能載入不同的第三方程式。
步驟 2：固定擷取條件
每次都用相同的瀏覽器設定：視窗大小、語系、時區、是否同意 Cookie。建議跑兩組：未同意 Cookie、已同意 Cookie，兩者的差異就是你的同意機制實際擋住了什麼。條件不固定，兩次結果無法比較。
步驟 3：整理第三方網域清單
從結果中列出所有非自家網域，標上類型（分析、廣告、客服、字型、CDN）。這一步可以交給 AI 代理整理，但網域歸屬與用途要由人確認，像這次的 OpenAI 網域，我們就標成「未進一步驗證用途」，不讓代理猜。
步驟 4：對照埋碼清單與隱私權政策
每個第三方網域都要能對應到：誰加的、用途是什麼、現在還有沒有在用、隱私權政策有沒有列出。對應不到的，就是要處理的項目。
步驟 5：保存結果，下一季比對
保存這次的 JSON 結果與證據編號。下一季用相同條件再跑一次，用 REA 的比對功能看差異：多了哪些、少了哪些。新增的第三方網域，要能說出是誰在什麼時候加的。
驗收標準：做完五步，你要能回答三個問題：官網首頁目前載入幾個第三方網域、每一個的用途與負責人是誰、上一季到這一季新增了哪些。三題都答得出來，這份檢查就可以交給下一個人接手。
五、結語：先從自己看得到的地方開始
REA 能做的事很多，但企業最該先用它做的，是看清楚自己。官網載入了誰的程式、舊系統把資料存到哪裡，這些問題過去要專家花時間查，現在可以交給代理先整理，再由人判讀。
如果你想盤點公司官網目前載入了哪些第三方程式、追蹤碼是否都還有人負責，歡迎填寫諮詢表單。我們可以先用相同口徑跑一次檢查，再和你的行銷與 IT 團隊一起判讀結果。
免責說明：本文實測於 2026 年 11 月 9 日以 REA 6.7.0 對優創智能自家官網首頁進行，為單次載入結果，不代表所有訪客或所有頁面的情況；第三方網域的用途依網域名稱與參數名稱判斷，未逐一向服務商確認。REA 功能與限制以專案最新文件為準。本文不是法律意見，逆向工程是否合法依軟體授權合約與適用法律而定。本文不代表對該專案的背書。
參考來源
- morluto/rea，GitHub 專案頁（2026-11-09 查詢）：https://github.com/morluto/rea
- morluto/rea，DISCLAIMER.md：https://github.com/morluto/rea/blob/main/DISCLAIMER.md
- rea-agents，npm 套件頁（2026-11-09 查詢）：https://www.npmjs.com/package/rea-agents
- 優創智能，REA 網站情境擷取實測紀錄（2026-11-09，REA 證據編號 ev_db0d4b05…）
相關推薦與延伸閱讀
- Zendesk 推出 Outcome AI Platform：AI 客服改按已解決問題計費，台灣企業簽約前該先定義的五件事：AI 客服改按結果計費，簽約前要先定義什麼算已解決、額度用完怎麼收費、外部 AI 代理能動哪些工單。Zendesk 於 2026-11-10 發表 Outcom
- 5 個行政自動化場景：會議、郵件、排程與報表驗收：AI 行政自動化怎麼做才有效？從會議摘要、郵件草稿、社群排程到費用及定期報表，整理五類行政自動化的輸入、人工覆核與驗收方式，不把工具設定完成當成效益保證。文中附
- AI 客服 API 當機怎麼辦？Timeout、Retry、熔斷與人工降級標準：AI 客服遇到上游 API timeout、429 或 5xx 時，不能無限重試。本文整理 timeout、backoff、circuit breaker 的建