REA 逆向工程 Agent 上手指南:从 Discord 提问到 PR 合并的完整路径【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/reaREA 把 Hopper、Ghidra 等逆向工具统一成一套 MCP 工具集,让 AI 代理对二进制和应用做逆向分析。刚接触这个逆向工程 Agent?这里是从 Discord 提问到 PR 合并的贡献指南。REA 是什么:社区维护的逆向工程 Agent 工具集REA(Reverse Engineer Anything)做的事只有一件:让 AI 代理去逆向任意目标——原生二进制交给 Hopper、Ghidra、IDA,应用行为走浏览器与进程捕获,同一套 MCP 工具在终端里也能直接用,结论自带背后的证据与边界。质量和文档由社区共同维护:维护者把守发布流程,普通贡献者提供文档修复、测试补充和工作流改进。代码里依赖方向从 domain 向 contracts、provider、application 再到 server 内流,这也是贡献分工的边界。 进群第一小时:哪些话该发,哪些不该Discord 服务器是社区的主要交流阵地,定位是 QA Show and Tell,加入入口写在 README.md 里,仓库首页也挂着社区徽章。安装、配置、provider 选择这类问题直接问就行;“我用 REA 逆出了 XX 应用的登录流程,证据在这”是分享区最受欢迎的帖子。想动契约或架构,先去讨论区跟开发者对齐范围,再开 PR。别把大量私有二进制内容或凭据贴进公开频道——这条红线没人会容忍。环境冷启动:跑通第一条静态检查工具链是钉死的:Node.js 24.18.x npm 11.16.x,分三步走:用nvm use切换到固定版本;克隆仓库、安装精确依赖,顺手跑一次快速静态检查:git clone https://gitcode.com/GitHub_Trending/rea2/rea cd rea npm ci npm run check:fastnpm run check:fast(缓存的类型检查 lint)第一次转绿,环境就算通了;需要独立 CLI 或 MCP server 时再执行npm run build:cached,普通迭代不必每次全量构建。卡住时先看nvm use是否真的生效、本地 npm 是否与package.json的packageManager一致——这一步卡住的人最多,九成死在版本不匹配,而不是代码。质量门禁:三个圈层的测试分层测试哲学是“用最能证明行为的证据”,按行为深度分成三个圈层。内环不碰真实世界:src/**/*.test.ts验证单个领域或适配器的窄公开面,tests/composition/验证 provider 无关的会话与注册表接线。中环恰好跨一条生产边界:tests/boundary/覆盖文件系统、进程、网络、浏览器这类单一边界,tests/boundary/mcp/验证 MCP 传输与工具契约,tests/acceptance/走完整编译后的 CLI 或 MCP 旅程。外环是共享层:tests/conformance/验证共享 provider 契约,tests/evaluation/验证确定性评分器逻辑。真实引擎各有对应通道,例如:npm run verify:hopper npm run verify:ghidra真实 provider 行为声明必须走npm run verify:*通道,mock 不能冒充平台级证据。日常命令速查:按场景找命令三个场景对应三种心气:改完代码求快,提 PR 前求稳,排查 CI 求全。命令明细可查 docs/testing.md:场景命令用途改完代码后npm run test:local只跑被改动的源文件测试,不构建改完代码后npm run test:focused -- src/config.test.ts精确跑指定测试文件提 PR 前npm run test:changed跑相对 main 分支受影响的测试提 PR 前npm run check:fast缓存的类型检查 lint排查 CI 时npm run check:pr全量本地门禁,大范围改动或排查 CI 用添加或移动测试后记得补跑npm run verify:test-discovery;改了契约或生成元数据,再追加npm run docs:check。还要记住:选择类命令只是快速迭代时的反馈,不是完整证据,边界与 provider 行为必须显式检查。从分支到合并:PR 流程与三行描述模板整条流程线纵着走:先开 Issue,涉及契约或架构的大改动对齐范围再动手;改动保持内聚,依赖沿 domain → contracts → provider → application → server 方向内流;提交前跑通相关测试 npm run check;PR 描述写清行为变化和验证情况,涉及真实 provider 时说明跑了哪条verify:*通道。描述本身只要三行:行为变化: 改变了什么用户可见行为 已跑检查: 测试 / check / verify:* 通道及结果 未覆盖项: 哪些通道没跑、为什么禁止项,逐条排除:❌ 二进制文件、Hopper 文档、凭据 ❌dist/、node_modules/及本地规划产物 ❌ 不遵循 docs/tool-design.md、不维护生成工具目录的 MCP 工具改动文档站与发布机制:谁有权发包VitePress 站点基于 docs/ 目录:npm run docs:dev本地热编辑,npm run docs:build校验生产构建与链接。发布由维护者按 docs/releasing.md 的 checkpoint 流程执行,从冻结的release/VERSION分支出发;main 分支的推送只能刷新版本预览、不能直接发包——这套机制保证每个发布版本都经过完整验证。⚠️ 三个最容易踩的坑本地测试全绿就等于功能正确?不一定。changed 测试选择只是反馈而非完整证据,涉及边界和 provider 行为时要显式检查;CI 才负责完整的确定性测试与覆盖率门槛(语句 65%、行 68% 等)。不会写 TypeScript 也能贡献吗?能。文档改进、测试补充、翻译都是受欢迎的贡献类型,从一条文档修复或一个聚焦测试开始就够。每次都要先全量构建吗?不用。普通迭代跑npm run check:fast和定向测试即可,只有需要独立 CLI 或 MCP server 时才执行npm run build:cached。起步:先修一条文档参与 REA 的核心姿态是八个字:小步提交、证据说话。不需要一次背下整套测试分层体系:在 docs/ 里找一条措辞有误的句子,或补一个聚焦测试,把npm run check:fast跑绿,提 PR 时填好三行描述——你就已经在这个逆向工程 Agent 社区里了。【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考