REA 讓 agent 逆向任何軟體，最該抄走的是它的證據規則：八天七次 breaking 的版本史

REA 的 README 開頭用粗體寫：「See a feature you like. Understand how it works, down to the binary level.」看到喜歡的功能，就把它拆到二進位層級看懂。同一個 repo 的 SECURITY.md 換了一種口氣：「This is not a sandbox」，後面接著說，打開一個不受信任的二進位檔，等於把解析工作交給本機選定的分析工具，用的是你這個使用者的權限。

一邊說什麼都能拆，一邊說我不負責擋。兩句都是官方寫的。最有意思的東西剛好夾在這兩句中間：它對 agent 下了一條很硬的規定，每個結論都要分清楚哪些是看到的、哪些是推出來的、哪些還不知道。

REA（Reverse Engineer Anything）住在 morluto/rea 這個 repo，MIT 授權，npm 套件叫 rea-agents。2026 年 10 月 12 日用 GitHub API 查，132,359 顆星；contributors API 回 114 筆，扣掉一個 github-actions[bot]，是 113 位。README 底下還掛著一行「110,000 GitHub stars — thank you!」，比 API 少了兩萬多。那行字沒跟著改。

四月建 repo，八月停在 3.1

repo 的建立時間是 2026 年 4 月 14 日，到今天 181 天。GitHub releases 上，3.1.0 在 8 月 9 日發出，下一版 3.2.0 要等到 10 月 3 日，中間空了 55 天。

那段時間它加了什麼，我沒有逐版讀 CHANGELOG，沒辦法告訴你哪個功能是哪天進來的。能講的是現在的樣子。以 6.4.0 的 README 為準，它的自我介紹只有一句：「One MCP for reverse engineering across binaries, applications, and runtime behavior.」把一整排逆向工具包進同一個 MCP server，讓你的 agent 直接叫。README 表格列的分析對象長這樣：

表外還有 ELF layout、EVM bytecode、Linux crash、HAR／mitmdump、JEB、Apktool 資源。範圍大到有點扯。

安裝是一行 npx rea-agents setup，跑完要重開 agent；只想臨時用一次 CLI，README 給的是 npx rea-agents@latest <command>。它說「CLI commands use the same workflows」，終端機跟 agent 走的是同一套流程，分析都在本機跑。Node 版本卡得很細：npm 上 6.4.0 的 engines 寫 ^22.19.0 || ^24.11.0 || >=26.0.0（2026-10-12 查），照這個範圍，23 和 25 都不在內。

有兩個設計細節我很喜歡，因為它們都在拒絕「自作主張」。第一個是 provider 的選法：只有一個可用的 provider 支援這個目標時，REA 才自動選它；兩個以上都行，你得用 --provider 或 REA_ANALYSIS_PROVIDER 講清楚，選定之後綁在那個 session 上，直到你明確切換。第二個是它把靜態和執行期分得很開：靜態的 JavaScript 與 .NET 檢查「read the supplied files without running the application」，執行期擷取則「runs or interacts with the selected target using your user permissions」。讀檔跟跑起來，是兩種風險等級，文件沒有混在一起講。

另外，Ghidra 的啟動期限預設 330,000 ms，也就是五分半，可以用 REA_GHIDRA_STARTUP_TIMEOUT_MS 調。文件自己承認 Ghidra 啟動慢，大型二進位建議把期限再拉高。

十月三日到十一日：八天，七次 BREAKING

然後節奏突然變了。

3.2.0 到 6.4.0 相隔 8 天，跨了三個 major。CHANGELOG 裡，4.0.0、5.0.0、6.0.0、6.1.0、6.2.0、6.3.0、6.4.0 都有「BREAKING CHANGES」區塊，一共七個。

版本政策 CHANGELOG 自己寫了。6.2.0 那段原文是：「REA’s always-bump-minor policy includes breaking changes; 6.2 is not a backward-compatibility promise.」並要求升級前先讀 6.1 到 6.2 的 migration guide。在這個專案裡，minor 版號跳一格也可能打破相容，別拿 semver 的直覺去猜。

文件自己記了兩條死路，值得先看過再動手。一條是 6.0.0 的改動：MCP 的檔案類輸入現在都要絕對的 host 路徑，範圍包括分析目標與 snapshot 的路徑、evidence bundle 路徑、browser 與 Electron 的啟動路徑。你的 agent 如果習慣丟相對路徑，升到 6.0 以後就會撞牆。另一條在安裝文件：DeepSeek Harness（dsh）的支援只在 main 分支，不在 npm 的 6.4.0 裡，用 @latest 跑 --client dsh 會回 unsupported。看到 main 的文件寫了某個 client，不代表你裝到的那版有。

好消息是它的安裝設計替你擋了一層。安裝文件寫：「persistent MCP registrations are pinned to the version that performed setup」，持久的 MCP 註冊會釘在當初執行 setup 的那個版本，裝了新版的說明也不會去更新正在跑的 server 或它的註冊。你不主動動它，它就不會偷偷跟著升。

在這種節奏下，給 agent 長期用的那份註冊我會讓它釘著，升級當成一次遷移來排，先讀那幾版的 BREAKING 區塊再動。@latest 留給臨時跑一次的 CLI。會讓我改變想法的條件很具體：CHANGELOG 連續一段時間不再出現 BREAKING 區塊，版本號開始只動 patch。

三個抽屜：觀察、推論、未知

版本號跳得再快，有一樣東西我覺得值得整段抄走。REA 隨附一份給 agent 讀的 SKILL.md，裡面有這一段：

「Every conclusion must distinguish observations, inferences, and unknowns. Cite Evidence IDs, preserve limitations and incomplete coverage, and never imply that static analysis observed execution.」

每個結論都要分開觀察、推論、未知，要引用 Evidence ID，要保留限制與沒涵蓋到的部分，而且絕不能暗示靜態分析「看到了」程式執行。

拿看病來比會比較好懂。X 光片上有一塊陰影，這是觀察。可能是肺炎，這是推論。痰液培養還沒做，這是未知。好的病歷會把三件事分開寫，壞的病歷直接寫「肺炎」。逆向工程的 pseudocode 特別容易讓人寫出壞病歷，因為反編譯出來的程式碼讀起來就像程式正在跑，看久了，「這段可能會被呼叫」很自然就滑成「它呼叫了」。最後那半句「never imply that static analysis observed execution」，就是在擋這個滑坡。前面講的靜態與執行期分開，到這裡接上了：工具層把兩種行為分開，skill 層再要求 agent 講話時也不准混。

同一份 SKILL.md 還要 agent 維護一份 finding ledger，把每個結論連到 Evidence ID、信心程度與證據類型、搜尋邊界，以及剩下的未知。

我最想借走的是「搜尋邊界」這一欄。agent 回報「找不到」的時候，你通常不知道它找了哪裡。grep 沒命中，只證明那幾個目錄裡沒有字面相符的字串，證明不了東西不存在。要求每個結論附上「搜了哪些範圍」，等於逼它把結論的有效範圍寫出來，讀的人一眼就看得出哪裡還是空白。這條跟逆向無關，放進任何讓 agent 查資料、查程式碼的流程都用得上。

README 對外也是同一句承諾：「results include the evidence and limitations behind each conclusion」。CLI 文件舉了一個量級的例子：一份 334 MB 的 Obsidian 應用程式 Evidence 檔，摘要檢視大約 10 KB。證據留著完整的，給人和 agent 先看的是摘要，要追的時候再拿 Evidence ID 回去找原件。

如果你自己也在寫給 agent 的指示，這是我今天唯一建議你直接做的事：把「觀察／推論／未知」三個抽屜和「搜尋邊界」寫進去。不用裝 REA 也能用。

它先把話講在前面

回到開頭那句「This is not a sandbox」。SECURITY.md 的完整意思是：REA 擋不住已經用同一個作業系統使用者身分在跑的惡意程式；打開不受信任的二進位，就是用你的權限把解析交給本機選定的 provider。

它在 Ghidra 這邊做了不少隔離：每個 session 用一個獨立的暫存專案，配上私有的 home、cache 與 runtime 目錄，只匯入你要求的那個目標，session 關閉時刪掉暫存專案，而且「REA does not open or modify user-owned Ghidra projects」。做了這麼多，文件還是補一句，這些控制「do not make Ghidra a sandbox」。它也不會替你下載、安裝、升級或修改 Ghidra 和 Java，setup 只在列出計畫、取得你同意之後，才把 GHIDRA_INSTALL_DIR、JAVA_HOME 寫進偵測到的 client 設定。

兩個範圍限制也寫得很老實。Windows 支援是 experimental 的 x64，官方叫它「read-only P0 boundary」，開放 25 個唯讀的 Ghidra 操作。client 支援方面，安裝文件說 registry 上的套件「accepted dry-run setup plans for the 17 client IDs in that release」，驗的是 dry-run 的設定規劃，名單裡點名了 Qwen Code、Pi 和 Hermes。

IDA Pro、Hopper、JEB 這類商用工具要使用者自己合法取得，README 寫「REA grants no tool license, key, or activation entitlement.」Disclaimer 的原文是：「REA is for lawful research, education, interoperability, software preservation, and analysis of software you own or are authorized to examine.」法律面我只轉述這兩句，不延伸。

如果要我讓 agent 去開一個來路不明的檔案，我會先準備一台用完就丟的 VM 再讓它動手。這是我自己的判斷，官方文件沒有這樣建議，它只講了自己不是沙箱。會讓我改變想法的條件：分析對象是你自己編出來的二進位，或是來源完全可信的檔案。

這篇我只讀了 REA 的 README、CHANGELOG、SECURITY.md、幾份 docs 和隨附的 SKILL.md，沒有安裝、也沒有實際跑過 REA 或 Ghidra。下面提到的案例成果都是官方自述，我沒有重跑。

下一個版本號

README 的展示案例裡，最硬的一個是 DX-Ball：原文寫「The reconstruction passes 3,205 original-x86 cases and reproduces all 63 compiled function bytes.」另一個是 PC-98 遊戲 TH04，從 16-bit 指令還原 fixed 與 aimed 兩種角度計算。還有一個拿 Notion 當目標：「Find the renderer’s clipboard API, follow it through preload and IPC into the main process, and inspect the rich clipboard format.」兩個重建出來的 repo 掛在 N0zoM1z0 名下，我沒有點進去看。

dsh 還在等一個 6.4.0 之後的 release。照十月這個速度，下一版可能就在這幾天，版號是 6.5 還是 7.0，CHANGELOG 不會先告訴你。我比較想看的是另一件事：版本一路往前衝的時候，「觀察、推論、未知」這三個抽屜，會不會是整個專案裡最後一個被動到的東西。