REA 逆向工程 Agent 工具让你的第一个 PR 顺利合并【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/reaREAReverse Engineer Anything逆向工程任意目标把 Hopper、Ghidra、IDA 和真实浏览器这类逆向工具收敛为一套 MCP 工具集让 AI Agent 一路干到原生二进制层面。本地环境怎么把第一条检查命令跑通、仓库里每层测试各自证明了什么、提交 PR 前要走哪些关卡下面按实操顺序讲清楚。 先弄清 REA 是干什么的以及去哪提问架构上一句话概括src/composition/里的生产工厂只负责构建 provider 而不启动引擎各逆向工具的专有协议收在对应适配器里共享的 CLI/MCP 工作流放在应用层最终对外暴露为一组 MCP 工具。社区的日常阵地是 Discord 服务器入口见 README.md安装、provider 选型这类问题在这里问最快你逆向出的结论也可以直接贴出来打算动契约或架构级别的大改动前建议先到那里把范围说清楚别急着动手。️ 第一条检查命令的四步跑通流程环境准备的最小目标是跑通npm run check:fast把 Node 切到锁定版本——.nvmrc和package.json#packageManager各钉了一个当前是 Node 24.18、npm 11.16先执行nvm use克隆仓库git clone https://gitcode.com/GitHub_Trending/rea2/rea进入 rea 目录npm ci装锁定依赖顺带挂好 Husky hooks此时不做编译npm run check:fast即带缓存的类型检查加 lint能过就算环境就绪。只有当你需要单独拉起 CLI 或 MCP server 时才执行npm run build:cached它会编译运行时并打包 skill日常改源码看反馈即可不必每轮都构建。 从单元测试到验收测试每个目录各自证明了什么docs/testing.md 的思路是用能证明行为的最强证据说话按行为深度分了七层目录就是边界。src/**/*.test.ts是模块层只碰单个领域、服务或适配器的窄公开面不起子进程也不开网络监听tests/composition/是组合层只验证不依赖具体 provider 的会话与注册表接线tests/boundary/是边界层每个用例恰好跨越文件系统、进程、网络、浏览器这类生产边界之一tests/boundary/mcp/专门管 MCP 传输与工具契约tests/acceptance/跑编译后的 CLI 或 MCP 完整旅程tests/conformance/校验收各 provider 共享的契约tests/evaluation/只覆盖确定性评分逻辑。还有一条硬规则涉及 Hopper、Ghidra、IDA、浏览器等真实工具的行为声明必须走对应的npm run verify:*通道在真机上跑出来。mock 或录制式 provider 的测试只能证明 schema 漂移和失败投影这类事不允许充当引擎确实可用的证据。⌨️ 日常开发高频命令四条覆盖 90% 场景npm run test:local——只跑被改动源文件的测试且不构建改代码时最常用npm run test:focused -- src/config.test.ts——按精确路径跑指定测试文件路径对不上会直接报错npm run test:changed——相对origin/main的选择受影响测试提交前用它过一遍npm run check:fast——缓存版类型检查与 lint每次提交前的底线动作。大范围改动或排查 CI 失败时才需要跑全量本地门禁npm run check:pr它包含完整静态检查、全量测试、docs 校验和重复代码扫描耗时明显更长。 从分支到合并一份不会被秒退的清单先开 Issue 再动手契约或架构级的大改动先在 issue 里讲清范围和关联讨论。评审者要先确认方向再看代码没对齐的改动大概率白写。改动保持内聚provider 专有协议留在适配器里共享 CLI/MCP 工作流放应用层别把两类东西搅在一个文件里。导入边界有 lintverify:module-boundaries方向混了会直接挂。按改动选检查相关测试加npm run check是基础动了契约或生成元数据补npm run docs:check动打包加npm run verify:package和npm pack --dry-run。检查要和行为对得上少跑多跑都要有理由。PR 描述写清验证情况跑了哪些检查、哪条真实 provider 通道在哪个主机上跑过、还有哪些覆盖没跑。CI 负责完整确定性套件与覆盖率本地只是反馈主动交代比被追问体面。这些东西不进仓库二进制文件、dist/构建产物、node_modules/、凭据、provider 项目文档、本地规划产物。生成的输出如docs/public/product-catalog.json由 CI 校验改的是源契约然后重新生成。另外两个固定动作新增或移动测试后跑npm run verify:test-discovery新增 MCP 工具时遵循 docs/tool-design.md 并维护生成的工具目录。文档站如何热更发布分支为何冻结文档站是 VitePress源文件就是docs/目录下的 Markdownnpm run docs:dev本地热编辑npm run docs:build校验生产构建与链接。发布由维护者按 docs/releasing.md 执行main 的推送只会刷新版本预览 PR真正的发包从冻结的release/VERSION分支出发普通 main 推送发不出包。️ 入坑前看一眼三个最常见的误会误会本地全绿就是功能正确。表现只跑了 changed 选择边界和 provider 行为上的回归漏掉等 CI 全量套件亮红灯。正解把变更选择当提示而非结论显式补跑对应的tests/boundary/用例完整覆盖交给 CI 判定。误会mock 过了就说引擎已验证。表现录制式集成测试全绿PR 里却写 Hopper/Ghidra 行为已确认。正解引擎类声明只有对应verify:*通道实跑后才有资格写评审一定会追问你跑了哪条通道。误会加完测试直接提交。表现新增或挪动测试文件后发现目录与元数据不同步CI 挂在不相干的地方。正解提交前先跑npm run verify:test-discoverylint 会顺带把模块边界查一遍。安装与 provider 配置细节见 docs/installation.md。最小可行贡献就一个先修一条文档里的笔误或给某个源文件补一个聚焦的单元测试跑通check:fast加test:focused把验证情况写进 PR 描述。走完这一圈最短闭环再谈架构级的东西评审体验会好很多。【免费下载链接】reaReverse engineer anything with agents, from app behavior down to native binaries.项目地址: https://gitcode.com/GitHub_Trending/rea2/rea创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考