REA 逆向工程工具：讓 AI 代理從軟體行為追到程式證據
REA 逆向工程工具把 AI 代理接上本機分析軟體，協助開發者理解應用程式行為、原生二進位檔與 JavaScript 程式。本文依官方程式庫和網站，說明 MCP、分析工具與代理的分工，整理證據如何支持結論、不同標的為何需要不同路徑，以及團隊如何從一個小型調查評估實際用途與交付品質。
看到應用程式的搜尋、剪貼簿或音效功能，開發者常想知道背後怎麼運作。REA 逆向工程工具把這類調查接進 AI 代理的工作流程。
使用者用自然語言指定想理解的行為，代理再透過本機工具，沿著檔案、程式結構與執行線索尋找證據。
這個開源專案近日出現在 X 的熱門 GitHub 清單，官方則把「分析結果附上證據與限制」作為產品的重要方向。
它把原本需要在多個工具間移動的調查串起來，但能讀到多少內容，仍取決於標的種類與已安裝的分析工具。
對有程式背景、需要理解自己有權分析的軟體的人，它適合用來縮短摸索路徑，也讓後續討論有檔案和程式依據。
第一個問題，是先挑對分析層次，才不會把合理猜測當成已經看見的事實。
REA 逆向工程工具幫代理做什麼？
REA 讓代理使用本機分析能力，從使用者看見的軟體行為，往背後的程式與資料結構追查。
逆向工程是從結果回頭理解設計
一般寫程式是先有設計與原始碼，再把它做成可執行軟體。逆向工程則從已有的軟體、檔案或行為出發，分析它如何運作。
這不代表一定能拿回原作者的完整程式。編譯、最佳化和打包會改變呈現方式，分析者通常需要從保留下來的資訊推想結構。
例如，使用者可能只看見「複製內容後能貼到另一個程式」。調查要進一步分辨，傳遞的是純文字、格式化文字、圖片，還是應用程式自訂的資料。
這些差異會影響重新實作的方式。只模仿畫面操作，可能看起來相似，卻無法在相同情境下產生正確結果。
MCP 把代理和工具接起來
依 REA 官方程式庫，代理透過 MCP 呼叫檢查工具，再根據回傳的程式、參照和未知事項繼續追問。
MCP 可以理解為 AI 接上外部工具的共同通訊規則。它讓模型知道有哪些操作可用，但實際分析仍由對應工具完成。
這裡的代理，是能安排多個步驟、呼叫工具並根據結果繼續工作的 AI。模型負責整理問題與解釋，分析工具則提供它可以依據的資料。
REA 的分工很重要。若只有模型回答，它可能依常見設計猜測，接上工具之後，才有機會把結論對到目前正在研究的軟體。
官方網站 也提供圖解和案例，讓開發者觀察一個功能問題如何轉成調查路徑，並把結果接回自己的專案。
但 REA 面對的軟體保留資訊不同，調查前仍要先辨認標的是哪一類。
不同軟體為何需要不同分析路徑？
原生程式、JavaScript 應用程式和網站，能取得的結構不同，因此適合使用的工具也不同。
原生程式需要理解編譯後的內容
原生二進位檔是電腦能直接執行的程式形式，常見於桌面應用程式。它通常不保留人類撰寫時的完整變數名稱與註解。
REA 可以連接 Hopper、Ghidra 或 IDA 等分析工具，取得組合語言、字串、符號、函式呼叫與參照，再讓代理沿線索繼續調查。
組合語言接近處理器實際執行的指令，反編譯產生的偽程式碼則把這些內容整理成比較容易閱讀的形式。偽程式碼仍是工具重建的表示，不能當成原作者的原始碼。
因此，代理若說某個函式「可能負責搜尋」，還要看它依據的是名稱、字串，還是實際呼叫關係。證據越具體，後續越容易確認或推翻。
JavaScript 和 Electron 可以從模組關係切入
JavaScript 應用程式可能保留模組、匯入關係和打包內容，分析起點和原生程式不同，不一定需要先使用原生反編譯引擎。
Electron 是用網頁技術製作桌面軟體的一種架構。它把顯示畫面的部分和具備本機能力的部分接起來，因此分析時常需要看兩者如何傳遞訊息。
例如，畫面上的按鈕只是入口，實際讀寫檔案的動作可能在另一個程序處理。若只看前端，就容易漏掉功能最後如何完成。
REA 官方文件列出的分析結果包含模組、匯入、路由和程序間訊息等關係。這些內容能讓代理從「按鈕在這裡」往「動作交給誰處理」繼續追查。
網站行為還要注意執行時的資訊
有些功能只有在實際操作後才會出現線索，例如請求、回應或執行中的狀態。單讀靜態檔案，可能看不到完整流程。
REA 的靜態分析是先讀檔案而不執行程式，動態觀察則是在程式運作時查看行為。兩者能互相補充，前者指出可能路徑，後者幫忙確認實際發生了什麼。
這些方法都需要對應的工具與環境。官方列出多種標的支援，不代表安裝單一套件之後，就能在所有作業系統分析每一類檔案。
所以，導入時應從手上那一個標的決定工具，不必為了功能清單把所有分析引擎都裝上。
從看見行為到重做功能，證據怎麼接起來？
有用的 REA 調查應能交代「觀察到什麼、找到哪些依據、還缺哪一步」，讓下一個人可以沿著相同路徑檢查。
先把問題縮到能重現的範圍
「研究整個程式」範圍太大，容易得到大量檔案摘要，卻沒有回答原本的需求。較好的起點是一個能重做的行為，例如特定搜尋如何排序。
接著記下輸入、操作與輸出。相同資料做相同動作，若每次結果不同，就先查清楚差異是否來自設定、網路回應或快取。
快取是把先前資料暫時保存，減少重複讀取的方式。若忽略快取，同一個功能在不同時間看起來不同，可能被誤解成不同程式路徑。
問題範圍縮小後，代理就比較能從字串、函式或模組關係，找出與行為有關的部分，而不必每次重新掃描整個應用程式。
檔案線索要能支持目前的結論
找到一段與搜尋有關的字串，可以證明程式裡存在這段文字，但尚不足以證明使用者按下搜尋時一定走過該函式。
若再找到呼叫關係或執行觀察，結論就更有依據。分析過程應把這些線索接起來，讓讀者看懂推想是如何逐步被支持的。
同樣地，沒有找到某個字串，也不代表功能不存在。程式可能壓縮、改名或把資料放在其他位置，工具的搜尋範圍也可能有限。
REA 強調回傳證據與限制，價值就在這裡。好的答案會讓開發者知道下一步該確認什麼，而不只是用肯定語氣把缺口蓋過去。
重新實作要另外測試
理解行為與寫出相似功能，仍然是兩段工作。調查結果提供設計線索，新的實作則需要使用自己的程式和測試驗證。
例如，原軟體可能在特定格式下保留剪貼簿資訊。新版本即使能複製文字，也應再試格式、空內容和跨應用程式貼上等實際需求。
如果某個假設沒有證據，實作時可以把它列成待驗證條件，避免把分析者的推想直接當成產品規格。
這也是 AI 代理工作需要保留版本與檢查紀錄的原因。有人能對照原本問題和最後輸出，才能知道它完成的是哪一部分。
延伸閱讀：PostHog Context Mill 是什麼？把文件做成版本化 Skills，讓 AI 代理跟上產品
有了這種證據觀念，才適合把工具放進小型調查，衡量它是否幫團隊節省時間。
導入前怎麼安排一個小型調查？
挑一個自己熟悉、也能確認結果的功能，會比從完全陌生的大型軟體開始，更容易判斷代理的分析品質。
選擇可回答的第一個問題
REA 適合的起點可以是自有應用程式的一個模組、測試用小程式，或團隊已獲准分析的套件。重點是知道原本期待看到什麼，才有比較標準。
先說清楚目標，例如「找出這個選項影響哪些檔案」，會比「告訴我整個軟體怎麼做」容易完成，也比較容易看出工具有沒有找錯方向。
完成範圍也應具體。可以要求一段行為說明、對應檔案與函式，以及仍不能確定的部分，讓成果直接服務下一個開發工作。
也可以先寫出什麼結果會推翻目前猜測。這讓代理有理由主動找反例，避免調查只累積支持原先想法的片段。
若這個問題需要執行程式，再安排可以重現的測試環境。把分析標的和自己的日常工作資料分開，能減少狀態差異造成的干擾。
本機分析與 AI 服務的資料路徑要分開理解
官方說明分析在本機進行，但代理會接收工具結果。如果所使用的 AI 代理連到外部服務，送給模型的內容仍取決於該代理的設定與操作。
因此，「本機分析」不能直接推成所有資訊都永遠不離開電腦。團隊可以先用可公開的測試程式確認流程，再依實際資料選擇可用環境。
這個區分與效能也有關。分析引擎在哪裡執行、模型在哪裡回答，可能是不同環節，各自影響等待時間和能處理的內容。
若需要由代理接手更多步驟，先把它能讀到的工具結果與專案範圍講清楚，後續調查才比較容易維持一致。
用結果品質評估，別只數產生多少文字
一份很長的報告，可能只是把目錄和函式名稱重新排列。比較有用的指標，是它有沒有回答原本問題，以及證據是否足以讓別人重做檢查。
還可以記錄人工需要補多少步。若代理已找到相關模組，但仍需人類確認最後一段行為，這仍可能節省時間，只是應把節省的部分描述清楚。
反過來說，若解釋很流暢，卻常把不確定推論寫成事實，團隊會花更多時間回頭查核。這種成本也應算進導入評估。
當調查成果能附上來源、可重現操作和後續測試，代理就比較容易成為工程協作的一部分。缺少這些內容時，再多自動化也難以支撐可靠修改。
延伸閱讀：iFixAi 開源 AI 代理稽核工具：60 項檢查與 A 到 F 評級，報告該怎麼讀？
保留調查快照，才能重做比較
軟體更新可能改變檔案結構，也可能修掉原本正在追查的行為。REA 調查應記錄分析的是哪個版本，讓報告能對應到具體標的。
如果團隊之後換了分析工具，也可保留先前的問題與觀察，對照新結果是找到更多證據，還是因環境不同而改變了解釋。
這種比較對維護工作尤其有用。當功能在新版出現差異，開發者可以回到相同情境確認變動，不必重新回想當初為什麼採用某個實作方式。
因此，REA 的產出最好能和專案紀錄放在一起。短而有來源的結論，通常比無法對應版本的長篇解釋，更容易接到後續修正。
REA 逆向工程常見問題
它會自動還原原作者的完整原始碼嗎？
分析工具能提供偽程式碼、字串、參照與其他線索，完整度取決於檔案和工具。編譯後遺失的命名、註解與設計意圖，無法保證全部恢復。
每種分析都需要 Hopper、Ghidra 或 IDA 嗎？
原生分析通常需要對應引擎，但靜態 JavaScript 分析有不同路徑。應依官方標的支援與環境需求選擇工具，無須預先安裝所有引擎。
沒有程式背景也適合直接使用嗎？
自然語言降低了提出問題的門檻，但判讀程式證據仍需要基礎知識。對一般讀者，先看官方案例理解分工，比直接分析陌生軟體更合適。
本機執行代表模型也在本機嗎？
不一定。分析工具和 AI 模型可能在不同環境，資料是否送往外部服務，要看使用的代理與模型設定。
用一個可重現行為開始
REA 適合有程式背景、需要讓軟體調查更有依據的開發者。它把工具操作與代理解釋接起來，是否值得長期採用，仍應看證據品質與人工補查成本。
下一步挑一個有權分析的小型功能，先寫下輸入、操作與預期結果，再用官方指南安排調查。完成後對照來源重做一次，也可訂閱發布紀錄，追蹤對應工具支援的變化。
