---
title: "用 REA 實測自家官網：一次載入 86 個請求、12 個來源，企業能拿逆向工程工具做的 4 件事"
description: "我們用開源逆向工程工具 REA 實測自家官網首頁：單次載入發出 86 個請求、來自 12 個來源，其中 10 個是第三方網域，多半屬於分析與廣告服務。本文說明實測口徑與判讀限制，整理 REA 四個需先確認授權的企業應用場景與不該用的情況，並給出 5 步驟把一次實測變成每季例行檢查。"
canonical: "https://yotron-ai.com/blog/rea-website-third-party-script-audit-use-cases"
published: "2026-11-09"
last-updated: "2026-11-09"
---

# 用 REA 實測自家官網：一次載入 86 個請求、12 個來源，企業能拿逆向工程工具做的 4 件事

我們用開源逆向工程工具 REA 實測自家官網首頁：單次載入發出 86 個請求、來自 12 個來源，其中 10 個是第三方網域，多半屬於分析與廣告服務。本文說明實測口徑與判讀限制，整理 REA 四個需先確認授權的企業應用場景與不該用的情況，並給出 5 步驟把一次實測變成每季例行檢查。

> 文／Laban（優創智能 AI 導入工程師）

REA 是讓 AI 代理在本機檢查程式、網站與 App 的開源逆向工程工具。我們用它對自家官網首頁做了一次實測。結論先講：**對多數企業來說，REA 最實際的第一個用途不是破解什麼，而是看清楚「自己的網站在訪客打開時，到底載入了誰的程式」**；這次實測單次載入就有 86 個請求、12 個來源。其他應用都可行，但每一個都要先回答「誰有權檢查這個對象」。

本文是應用篇，寫給想知道 REA 能做什麼的 IT 承辦人與行銷主管。REA 是什麼、合法界線在哪，請先看[REA 是什麼？讓 AI Agent 拆解軟體的開源 MCP 工具](/blog/rea-reverse-engineer-anything-ai-agent-guide)；代理該被允許呼叫哪些 REA 工具，請看[REA 工具標註與三級核准規則](/blog/rea-mcp-tool-annotations-agent-approval-policy)。本文不是法律意見。

---

## 一、實測：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 能做的事很多，但企業最該先用它做的，是看清楚自己。官網載入了誰的程式、舊系統把資料存到哪裡，這些問題過去要專家花時間查，現在可以交給代理先整理，再由人判讀。

如果你想盤點公司官網目前載入了哪些第三方程式、追蹤碼是否都還有人負責，歡迎[填寫諮詢表單](/contact)。我們可以先用相同口徑跑一次檢查，再和你的行銷與 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 客服改按已解決問題計費，台灣企業簽約前該先定義的五件事](/blog/zendesk-outcome-ai-platform-unlimited-pricing-ai-customer-service-taiwan)：AI 客服改按結果計費，簽約前要先定義什麼算已解決、額度用完怎麼收費、外部 AI 代理能動哪些工單。Zendesk 於 2026-11-10 發表 Outcom
- [5 個行政自動化場景：會議、郵件、排程與報表驗收](/blog/ai-admin-tasks-automation)：AI 行政自動化怎麼做才有效？從會議摘要、郵件草稿、社群排程到費用及定期報表，整理五類行政自動化的輸入、人工覆核與驗收方式，不把工具設定完成當成效益保證。文中附
- [AI 客服 API 當機怎麼辦？Timeout、Retry、熔斷與人工降級標準](/blog/ai-customer-service-api-outage-circuit-breaker)：AI 客服遇到上游 API timeout、429 或 5xx 時，不能無限重試。本文整理 timeout、backoff、circuit breaker 的建