上线时间 2026年4月

这是什么
REA 回答的是源码回答不了的那个问题:一个已经发出去的程序,是怎么做出这个功能的。
它是一个跑在本机的 MCP 服务器加命令行,agent 逐个工具去调,每次调用返回的是它查到了什么,以及这个结论背后的证据。
用它打开一个原生二进制,走的还是你机器上已经装好的 Hopper、Ghidra 或 IDA,读出伪代码、汇编、字符串、交叉引用和调用图;
解开一个 JavaScript 或 Electron 应用,一路跟到它的 IPC 边界;
不运行就读取 .NET 程序集的元数据和 CIL;
用本机的 Chrome 系浏览器打开页面,记录它请求了什么;
录下一个进程的终端输出、退出状态和对文件系统的改动;
解包固件、反编译安卓包,或者读一份存下来的 HAR。
分析全程在本机完成,项目的规矩是 local-only,除了 agent 自己的模型服务商收到的东西之外什么都不外发。
某个工具看不到的地方,结果会写成一条未知,而不是把空白补上。
反编译本身不在这个包里,安装包也不在:release 页面一个文件都没挂。
谁做的
一个 2020-12-22 注册的 GitHub 账号,252 个公开仓库、1,549 个关注者,简介写着 member of technically staff,所在地标的是 Sinsai。贡献者表上有 92 个账号。除作者之外,主要出力的是三个:@N0zoM1z0 445 次提交、@kaoru0822-kitauji 373 次、@rudycelekli 85 次,对比作者本人的 1,214 次。README 里挂的两个 showcase 就是第一个账号自己的仓库:N0zoM1z0/dx-ball 和 N0zoM1z0/th04。
它是怎么搭起来的
组成 · 6组织方式是:分析是一条由声明式契约搭起来的流水线,agent 只是它的一个客户端。每项能力都是一个带具名输入 schema、具名输出 schema 和一份审计过的效果记录的工具,而同一份清单同时支撑 MCP 服务器、命令行和自动生成的文档——正因如此,CATALOG_IDENTITY 才能对整个表面发布一份 sha256,验证器才能拿发布出去的包去比对它声称的那个源码版本。围绕这份清单有四层,依赖只有一个方向:领域语义与契约在中间,外面是 provider 适配器,再外面是共享的应用流程,最外面是 CLI 与 MCP 适配器;AGENTS.md 把这条写成规则,.github/workflows/ci.yml 用模块边界检查去强制它。provider 不随包分发。每一个都是 REA 写给别人的脚本接口的桥:Hopper 走它的 Python 接口,Ghidra 走一份无头的 Java 脚本,IDA 和 JEB 走调用者本来就起着的 MCP 服务器。这样 REA 不必自己发布一个反编译器,agent 仍然拿得到反编译结果。什么都不上传,什么都不改:原生分析跑在临时的 Ghidra 数据库上或只读挂载的 IDA 上,批注落在会话里而不是可执行文件里,AGENTS.md 也禁止安装器去碰无关的软件。
- src/contracts 与 src/server
- 公开表面:172 条工具契约,各带具名 schema 和效果审计,旁边是提示词契约、给预算更小的客户端用的 schema 档位,以及把这一切注册进去、并用同一种规范编码返回结果的 MCP 服务器。
- src/domain
- 458 个文件、约十万行语义:Evidence 记录及其打包、带标签的错误代数、分析视图与档位、调用路径、函数对比、重构覆盖率与它的义务账本、dyld 解析,以及 JavaScript 的语义图和静态分析。
- src/hopper、src/ghidra、src/ida、src/jeb 与 bridge/
- 四个 provider 适配器和它们驱动的脚本。Hopper 走一条 socket 连到加载在应用内部的 Python 桥,配目标租约和可取消的正则 worker;Ghidra 用
AnalyzeHeadless加 REA 自己的 Java 脚本无头启动;IDA 和 JEB 走调用者自己起的 MCP 服务器。 - src/dotnet、src/native、src/artifacts 与 src/javascript
- 不需要任何引擎的读取器:一个覆盖元数据堆、表布局和 CIL 的托管程序集解析器,Mach-O 与 PE 资源检查、plist、归档、代码签名、Apple 应用包解剖、包格式、source map 解码,以及 JavaScript 源码恢复。
- src/browser、src/process、src/inspector、src/adb 与 native/windows
- 看东西跑起来的那一半:DevTools 协议上的浏览与场景录制、进程归属与录制、Node Inspector 目标、经 adb 的安卓设备控制,以及那个用 C++ 写的 Node-API 插件——它在 Windows 上提供基于句柄的文件系统权限、Job Object 归属和私有 DACL。
- src/cli、install.sh、.agents/skills 与 .github/workflows
- 入口:和工具一一对应的单次命令、先出计划再改客户端配置并留备份的 setup、随包的
reverse-engineer-anythingskill 及其参考文件,以及二十二个 workflow——其中大多数名字里带Real,因为它们跑的是真引擎而不是夹具。
取舍,以及另一种做法
驱动用户已经装好的引擎,而不是自己带一个反编译器 替代 自带一套分析引擎
third_party/README.md把政策和理由写在一起:上游源码原样留在按提交钉住的 submodule 里,绝不复制进 REA 的领域层或应用层,分析过程中也不下载任何引擎。REA 留下的是桥、契约和解释,这也是为什么 Ghidra 的桥是这仓库里 3,833 行 Java,而不是一个依赖。审计每个工具的效果,再从这份审计里推出它的 MCP 注解 替代 逐个手工决定只读与破坏性提示
toolEffects.ts为全部 172 个工具声明了效果记录,annotationsFromEffects只从那八个布尔值推出四个 MCP 提示,完全不看工具名,而toolContractMetadata在缺条目时直接抛错。新增一个工具,就必须有人先写清它对目标、会话、文件系统和网络做了什么。让面向 agent 和面向人的两个表面共用同一份清单 替代 给命令行另开一套顺手的命令
命令行的名字是
src/cliCommandNames.ts里一个冻结的对象,工具契约是一个有序数组,catalogIdentity.ts把三份目录合在一起做摘要。正因如此验证才有意义:可以拿发布出去的包去问,它的工具清单是不是那份规范清单。不让 setup 安装或升级任何它非装不可之外的东西 替代 让 setup 一步到位装好整套工具链
AGENTS.md给安装器写死了这条规则,点名 Homebrew、Node.js、npm、Java 和 Ghidra 都不许碰,并要求rea setup在写文件之前先展示计划、取得批准。Hopper 是唯一的例外,而即便是它,也是提出建议而不是直接动手。在调用者的机器上分析,什么都不上传 替代 做一个托管的在线分析服务
仓库自称 local-only,目标从本机路径读取,引擎作为子进程启动,README 对上传问题的回答是把数据政策指向 agent 自己的模型服务商。这是一份用户不被允许发到任何地方的目标也能拿来分析的原因。
依据morluto/rea 的 README.md、AGENTS.md、CONTRIBUTING.md、SECURITY.md、package.json、server.json、.gitmodules、third_party/README.md、docs/installation.md、docs/testing.md、docs/mcp-contracts.md、docs/windows-ghidra-p0.md、docs/roadmap.md、docs/architecture.mermaid、vitest.config.ts、.github/workflows/ 下的 ci.yml 及其余 workflow、scripts/verify-deepseek-client.mjs、src/catalogIdentity.ts、src/contracts/、src/domain/、src/native/、src/dotnet/、src/hopper/、src/ghidra/、bridge/、native/windows/ 与 .agents/skills/,2026-10-11 读取。
制作过程
7 个阶段- 01
这 30 MB 里是什么
我在 2026-10-11 的
14:58Z克隆了main,量的是代码树而不是仓库页面。树里有 2,779 个文件、31,123,835 字节,合 29.7 MiB。GitHub 自己的size字段写 46,708 KB,因为那统计的是 packfile 里存的东西。语言统计和这棵树只差零头:TypeScript 14,136,292 字节,JavaScript 1,714,588,HTML 521,528,Python 292,270,Java 274,198,C++ 69,042,汇编 4,208 字节。 只算源码不算数据,2,467 个文件里有 497,077 行。体量在src/:1,497 个 TypeScript 文件共 300,089 行,其中 340 个是长在源码树里的测试文件、占 77,189 行,于是非测试的 TypeScript 是 222,900 行。光src/domain一个目录就是 458 个文件、100,001 行。tests/另有 578 个文件、127,061 行,scripts/是 241 个.mjs、48,664 行,docs/是 47 份 Markdown、10,460 行。把src/和tests/合起来数,742 个文件里有 4,463 个it(块,分散在vitest.config.ts里那十二个 vitest 项目下。单文件最大的不是一张表:src/adb/AdbProvider.ts有 2,070 行,后面跟着 1,798 行的src/domain/native/nativeAotPe.ts、1,531 行的进程录制生命周期文件、1,459 行的客户端配置文档,以及两个各 1,220 行和 1,119 行的 JavaScript 语义分析文件。 剩下的不是代码。website/locales/下有 18 份 gettext 目录,分别是ar、de、es、fa、fr、id、it、ja、ko、pl、pt-BR、ru、th、tr、uk、vi、zh-CN和zh-TW。合起来 237,154 行、9,094 KB,单份文件从中文的 471,205 字节到泰文的 619,905 字节。英文 README 旁边还有十八份译本。有四座桥不是用 TypeScript 写的:光bridge/ghidra/ReaGhidraBridge.java一份就是 3,833 行、185,179 字节,Ghidra 那批脚本合计 4,879 行 Java;bridge/hopper_bridge.py是 1,162 行 Python,bridge/native/rea_lldb_tracer.py是 839 行;native/windows/src是 1,326 行 C++,编译成唯一一个预编译的 Windows 插件。 - 02
一台服务器、172 个工具,以及每个工具背后站着谁
公开的工具清单就是一个有序数组。
src/contracts/toolContracts.ts把 25 个文件摊进TOOL_CONTRACTS,而每条契约都经由一个辅助函数调用toolContractMetadata(name);只要src/contracts/toolEffects.ts里没有对应条目,这个函数就抛出Missing effect audit for <name>。那份文件就是审计表,所以它的键就是工具名单:172 个名字,从open_binary、list_procedures、procedure_pseudo_code,经analyze_javascript_application、inspect_managed_artifact、observe_web_execution、capture_process_scenario、extract_firmware、pull_adb_package,一直到verify_reconstruction和build_reconstruction_obligation_ledger。直接解析那 28 个契约数组得到 170 个名字,另外read_bytes和address_to_file_offset单独放在另一个文件里,两个数在 172 上对上。src/catalogIdentity.ts把同一个数字发布成CATALOG_IDENTITY.counts.mcp_tools,旁边是命令行条数和三份 sha256,分别覆盖工具目录、提示词目录以及两者合并后的结果。 每个名字背后站着的东西并不一样。做原生分析时,REA 里没有反编译器,只有通往三个反编译器的桥。Hopper 由bridge/hopper_bridge.py驱动,REA 把这份脚本加载进正在运行的应用里,src/hopper/是它的客户端:请求队列、目标租约、可取消的正则 worker、清理,以及 1,026 行的HopperClient.ts。Ghidra 通过ghidra.app.util.headless.AnalyzeHeadless无头启动,用-scriptPath和-postScript挂上 REA 自己写的脚本,包括ReaGhidraBridge.java、ReaGhidraPrepareCom.java、ReaGhidraApplySeeds.java和ReaGhidraNoReturnFix.java。IDA 走调用者自己起的 IDA MCP 服务器,JEB 走调用者自己起的 JEB 客户端,JADX 走调用者自备的无头 MCP JAR,固件走 Binwalk 或 Unblob。 另外一些名字背后是 REA 自己的读取器。src/dotnet是 28 个文件、9,278 行,不运行就解析托管程序集:PE 读取器、元数据堆、表布局与行宽、CIL 指令解码器、方法体读取器,以及异常区的校验。src/native是 54 个文件、11,982 行,做 Mach-O 检查、PE 资源解析、plist 与归档、代码签名读取、胖二进制选择、dyld 解析和 LLDB 调用跟踪。src/browser是 113 个文件、24,424 行,跑在 DevTools 协议上;src/process是 57 个文件、13,917 行,管进程归属与录制;JavaScript 那一侧自带解析器、语义图和 source map 解码器,不叫外部分析器。third_party/README.md用一段话交代了这个安排:REA 通过 provider 适配器接入已有工具,上游源码原样留在按提交钉住的 submodule 里,不会被复制进 REA 的领域层或应用层。五个 submodule 各钉了一个提交:JADX 的无头 MCP、Binwalk、Unblob、一个 NativeAOT 的 Ghidra 扩展,以及 Wakaru。分析过程中 REA 不会去下载任何引擎。 - 03
「什么都能逆」这句话能核到哪一步
说法写在仓库简介里:
Reverse engineer anything with agents, from app behavior down to native binaries.能核它的地方是 README 自己那张能力表,因为最后一列写明了每个目标需要什么。表里一共 15 行。两行除了 Node 什么都不用:JavaScript 与 Electron 应用,以及 .NET 程序集,后者的要求一栏写的是None (static only)。另外两行需要读者大概率已经有的东西:网站要一个 Chrome 系浏览器,存下来的抓包要一份 HAR。剩下十一行都点名了一个引擎或一套操作系统。原生二进制要 Hopper、Ghidra 或 IDA。离线 ELF 布局要在 Linux x64 上由调用者自备 pwntools。WASM 产物要 WABT 1.0.42。EVM 字节码要在 Linux x64 上有一个原始载体。录下来的 Linux 崩溃要 pwntools,可选再配 GDB 与 pwndbg。安卓包要无头 JADX 和完整 JDK,安卓设备要 adb,安卓资源要 Apktool。固件要在 Linux 上跑 Binwalk 或 Unblob。JEB 工程要调用者先起一个 JEB 客户端。进程行为要 Linux 或 macOS 上的原生 PTY。 Windows 的边界是写下来的,不是踩出来的。docs/windows-ghidra-p0.md把它在 Windows x64 上的支持称作实验性的、只读的,点名可用的只有 25 个只读的 Ghidra 清单、内存与函数操作,并用自己的话写着,这条边界不构成 Windows 上的功能对齐。32 位 x86 的 PE 支持在main上,5.0.0 之前的 npm 版本里没有。Ghidra 的图形界面状态、批注、其他架构与格式,以及所有只属于 Hopper 的操作,都不在这条边界内。Hopper 本身是 REA 在 macOS 和 Linux 上驱动的应用,项目为它单独留了一条 Linux 验证通道和一个私有显示探测。 分析是不是真的,和它能不能带走,是两个问题,而在前一个问题上这棵树给得很具体。.NET 读取器自己解 CIL,还校验异常区。Mach-O 那一侧会预测 dylib 的加载顺序,再拿 dyld 实际加载的镜像去对。JavaScript 那一侧建的是带成员改写、promise 归属和引用生命周期的语义图,并在同一个进程里解析 source map。src/domain/native/nativeAotPe.ts从一个只读镜像里解析 NativeAOT 的 ready-to-run 快照。树里没有的是反汇编器、反编译器和模拟器。README 结尾那句免责声明就是整件事的形状:REA 提供的是合法的逆向研究工具,而深度原生那条通道是别人的引擎,跑在 REA 维护的一份契约上。 - 04
DeepSeek Harness:文档里有,POSIX 上验过,setup 不支持
本站读者和这一节直接相关。DeepSeek Harness 不在 REA 的客户端表里。那张表列了
rea setup --client能配置的 17 个客户端:Claude Code、Claude Desktop、Codex、Cursor、Gemini CLI、Windsurf、Devin、OpenCode、Antigravity、GitHub Copilot CLI、Command Code、Qwen Code、VS Code、Grok Build、OMP、Pi 和 Hermes,Grok Bot 因为连接器不是这些文件而单列在表后。Harness 在表下面另起一节,标题就说明了差别:它用的是 Cordis 的 YAML 补丁序列,而不是mcpServers对象,setup --client不改这种格式。 文档给的是一段手写补丁,针对 Harness0.2.0-rc.2。往$DSH_HOME/cordis.patch.yml里追加一条,DSH_HOME未设时是~/.dsh/cordis.patch.yml;条目里写id: rea-mcp、name: "@deepseek-ai/dsh-mcp-client"、serverName: rea、transport: stdio,以及node和scripts/rea.mjs的绝对路径。Harness 之后把这些工具暴露成mcp__rea__<tool_name>。skill 是第二步,用rea setup --skill装进~/.agents/skills;Harness 自己会扫这个目录,配置了$DSH_AGENTS_HOME/skills时扫那里,然后它原生的skill工具就能装载reverse-engineer-anything。 这条集成有一条验证通道,而且很窄。npm run verify:deepseek-client跑的是scripts/verify-deepseek-client.mjs:它要求本机已经装了dsh,按@deepseek-ai/dsh@0.2.0-rc.2验过;把 Cordis 补丁写进一个隔离的DSH_HOME,把HOME和USERPROFILE绑到一个一次性账号上。它检查 skill 能否加载、完整目录能否被发现、转发过去的输入 schema 和正则,以及一个路径里带非 ASCII 字符的 JavaScript Evidence 结果。它的第 9 行直接断言平台不是 Windows,附带一句Native Windows coverage is unverified.背后的模型是一个本机的 OpenAI 兼容假服务,声明着一百万 token 上下文,也就是 Harness 默认那个 DeepSeek Flash 模型的容量,所以这条通道建立的是「接通了」,不是「线上 DeepSeek API 可用」;docs/testing.md原话就是这么说的。这条通道只在 POSIX 上跑,.github/workflows/里没有任何一个 workflow 调它,所以它只在有人手动跑的时候才跑。 缺口在 issue 列表上,而且带着方案。#1839,标题是[Feature] Add native DeepSeek Harness (DSH) client support to REA setup,2026-10-11 提交,标签是enhancement和triage,我读的时候一条评论都没有。正文把缺的东西列得很具体:rea setup --client dsh --dry-run --json、rea doctor --client dsh --json、可重复执行的注册、安全移除,以及不能碰 Cordis 里无关的内容;作者同时表示愿意自己实现,并请维护者就 Cordis YAML 该怎么安全处理给个方向。开着的就是这个问题。前一天还有一条 #1636,问的是 Harness 那种进程不退出就算跑完的无头模式该怎么跟踪。 - 05
半年的提交历史,大半在最后一周
GitHub 在 2026-04-14 建了仓库,第一次提交落在同一分钟,
2026-04-14T00:51:30Z。然后是空白,一直到 2026-07-11。main上现在有 2,323 次提交,最后一次在2026-10-11T14:58:01Z。 按月算是四月 1 次、七月 697 次、八月 21 次、九月 100 次、十月 1,504 次。按周看更陡。2026-07-06 那一周 110 次,下一周 364 次,然后 172、56、11、4,八月和九月大部分时间一周只有一次;再往后 2026-09-28 那一周 107 次,截至 2026-10-11 的最后七天是 1,496 次。整个项目将近三分之二的历史写在它最后一周里,十月那七天的日计数依次是 117、113、281、205、351、268 和 161。 提交标题说明了这是哪一种工作。2,323 次提交里 1,005 次以fix开头,对比 200 次test、187 次feat、181 次docs、164 次refactor和 105 次perf。作者名有 103 个;按 GitHub 账号算是morluto1,214 次、N0zoM1z0445 次、kaoru0822-kitauji373 次、rudycelekli85 次,贡献者接口返回 92 个账号。380 次提交带Co-authored-by尾注,489 行尾注里有 297 行点名了某个模型或 agent:Claude Opus 5.5 占 260 行,Cursor Agent 23 行,Devin 5 行,Claude Sonnet 5.5 3 行。78 次提交带Signed-off-by。分支列表翻一页基本都是 agent 分支:agent/…、codex/…、cursor/…,和release/…、fix/…混在一起。 release 很密,而且是空的。从 2026-07-12 的rea-0.2.0到 2026-10-11 的rea-agents-6.4.0一共 35 个,每一个挂的附件都是 0,因为分发走的是 npm。npm 上有 31 个rea-agents版本,6.4.0 解开是 7,776,450 字节。下载量的形状和提交一样:九月每天 10 到 43 次,然后 2026-10-03 是 418 次,次日 798 次,再往后 4,048、5,032、9,000、19,983 和 34,790。最后这一周占了整月 74,461 次下载里的 73,651 次。README 里有两行属于同一个事实:星数那一段现在写的是90,000 GitHub stars,下面那段免责声明说项目没有发行也没有背书任何加密货币或代币,用 REA 名字的代币与本项目无关。这个数字跑得比一条记录能记住的速度快:2026-10-11 的 22:52 接口返回 91,053 颗星,同一天 23:07 本站写入的监控基线读到的是 91,384。 - 06
159 个未关闭的条目
2026-10-11 这天 GitHub 的计数器读数是 159 个未关闭条目。同一天晚上把 issue 接口翻完,得到 107 条 issue 和 50 条 PR,而单查 PR 接口是 51 条,所以这个数字主要是 issue,加上一部分来自贡献者的在办工作。107 条里只有 15 条挂着
bug标签,71 条是enhancement,45 条还挂着triage,也就是维护者还没读到。其余高频标签是P1: high36 条、roadmap22 条、area: mcp18 条、P2: medium16 条、area: providers12 条、area: domain11 条、P0: critical10 条。另外 19 条一个标签都没有。 107 条里有 53 条一条评论都没有,66 条是这条记录之前七天内提的。11 条超过三个月,27 条在一到三个月之间。最老的那十条全部提于 2026-07-12,也就是第一个 release 的第二天,它们是几份总纲:#32「把 REA 演进成 agent 优先的多工具逆向平台」;#39 浏览器与 Web 支持;#48「Evidence v2 与确定性进程保真」;以及 #54、#55、#59,讲 Hopper 函数档案和进程树录制。同一批里还有一组 Hopper 一致性验证器的总纲,#333 和 #339 到 #344。 最大的一簇是 Windows,而且是一份总纲拆成了十六条 issue。#287 到 #290、#318 到 #329 全部提于 2026-07-16 和 2026-07-20,讲的都是同一个原生 Node-API 包:基于句柄的、防重解析点的文件系统权限,带 kill-on-close 的 Job Object 归属,运行根目录上的私有 DACL,以及每一项各自的真机 Windows 验证器。它们到现在还开着。下一簇要的是新的 provider 通道而不是修 bug:MIPS16(#1851)、armhf(#1745)、PowerPC(#1741)、6502 与 65816(#1641)、MIPS32(#1620)、PSP(#1330)、AArch64 跳转表(#487)、dSYM 匹配(#1193)、NativeAOT(#744),外加三条干脆想换引擎的:Binary Ninja(#1551)、Hex-Rays 官方的 IDA MCP 服务器(#1416)和 rsleigh(#1389)。客户端接入是单独一小撮:DeepSeek Harness(#1839)、Kimi Code(#1791)、Codex 插件(#1269),以及一个不需要包管理器的安装方式(#1316)。 bug 那一类是用户会撞上的那种。#1387 说analyze-javascript-application --json在一个 6.2.0 能跑完的 bundle 上中止,也就是一个人手里那个版本的回归。#1554 说完整的 MCP 输入目录会让 GitHub Copilot CLI 的普通对话直接卡住。#1720 说查询类调用死在一个固定的 60 秒超时上,比配置的 Ghidra 启动期限还短。#1719 说open_binary根本没起 provider 客户端就返回了。#1701 说 Windows 原生权限自检在真机上失败,还留下探测目录。#1808 说 demo 模式的 Hopper 6.6.0 在分析一个系统二进制时段错误,并留下一个中毒的会话。#1859 提于写这条记录的同一天,说 Windows 上的真机 Ghidra 验证器在所有主机上都失败。讨论最多的是设计类而不是 bug:#1065 有 40 条评论,#740 有 21 条,#287 有 15 条,#724 有 11 条。 - 07
它跑得起来,以及跑起来之前要装什么
安装是一条命令。
npx rea-agents setup把你选的客户端注册好并装上配套 skill;npm install --global rea-agents得到一个终端里的rea;仓库里的install.sh只要平台不是 Darwin 或 Linux 就直接退出。Node 是唯一的硬要求,22.x 从 22.19 起,24.x 从 24.11 起,或者 26 及以上。 我没有描述发布包,而是把它拉了下来。rea-agents@6.4.0压缩后 1,825,761 字节,解开 7,776,450 字节,一共 1,161 个条目:其中 1,112 个是dist/下的 JavaScript,7 个是随包的 skill,21 个是那几座桥,还有一个是预编译的 Windows x64 Node-API 插件,在native/windows/build/rea-windows-x64.node。Ghidra 那批 Java 脚本和 Hopper 的 Python 桥都在 npm 包里,所以没有人需要自己拼一座桥。包里有 35 个运行时依赖。rea setup先给一份计划、要批准才动文件,改动之前会备份,而且不会安装或升级 Ghidra、Java、Python、Node、npm、Hopper 或编译器。Hopper 是它唯一能提出帮你装的引擎,而且只在批准之后。分析在本机完成,README 对「REA 会不会上传我的应用」的回答是:目标在本机分析,agent 自己的模型服务商另有它的数据政策。 持续集成是体量显形的地方。注册在案的 workflow 有二十二个,二十一个在跑、一个被手动关掉,接口记录的运行次数是 13,777。主ci.yml自 2026-09-01 起完成了 2,500 次,其中 800 次落在写这条记录之前的 25 小时里。这 800 次里 198 次成功、115 次失败、266 次被更新的提交取消,还有 221 次停在action_required,那是 GitHub 在等维护者批准一个 fork 的 workflow。在main上被取消才是常态:214 次 push 触发的运行里,182 次被取消。包验证矩阵跑在 Linux x64、Linux arm64、macOS 15 的两种架构和 Windows x64 上。 有两条边界写在仓库自己里面。Windows 上的原生分析就是前面那条实验性、只读的边界,而 DeepSeek Harness 的验证通道干脆拒绝在 Windows 上运行。另外main上有的功能,你装的那个 npm 版本里不一定有;docs/installation.md专门留了一节Released package and main,里面点名说 2026-10-11 查过的版本是 6.4.0。
他会告诉你什么
- 没有安装包可下载。35 个 release 的附件全是零,而
install.sh只要平台不是 Darwin 或 Linux 就直接退出,所以在 Windows 上走的是 npm 加那个预编译的 x64 插件。Windows 上的原生分析在docs/windows-ghidra-p0.md里被写成实验性、只读,可用的是 25 个 Ghidra 操作;32 位 x86 的 PE 支持在main上,5.0.0 之前的 npm 版本里没有。 - 这句话的边界是读者手里已经有什么。README 那十五行目标里有两行除了 Node 什么都不用,另外十一行点名了一个引擎、一个设备工具或一套 POSIX 主机,而且 README 就在提出主张的那张表里写明了是哪一种。所以这里的「什么都能」指的是:格式要么在这仓库里有读取器,要么你盘里有引擎。
- 星数和项目年龄不是同一个测量。91,053 颗星和 20,140 个 fork 在不到半年里到齐,可仓库在头三个月里只躺着一次提交,2,323 次提交里有 1,496 次落在最后七天,1,005 次提交以
fix开头。4.0.0、5.0.0、6.0.0 三个大版本分别在 2026-10-05、2026-10-07 和 2026-10-08 发出,相隔三天。 - 未关闭的队列很年轻,而且大多不是 bug。107 条开着的 issue 里 66 条是最后一周提的,53 条一条评论都没有。一份拆成十六条的 Windows 原生权限总纲从 2026-07-16 和 2026-07-20 开到现在,Hopper 函数档案和一致性那几份总纲从 2026-07-12 开到现在;还没收敛的工作其实都在那里。
- CI 的通过率没有它的体量那么好看。25 小时里完成 800 次
ci.yml,其中 198 次成功、266 次被取消、221 次在等维护者批准 fork 的 workflow;在main上,214 次 push 触发的运行里有 182 次被后来的提交取消。这里的一个绿勾说的是某一次提交的某一刻,而五个 runner 上的包验证矩阵才是那张矩阵里值得数的部分。 - DeepSeek Harness 在文档里有,在 setup 里没有。
rea setup --client覆盖 17 个客户端,Harness 不在其中,集成方式就是文档里一段手写的 Cordis 补丁加一次单独的 skill 安装。验证通道拒绝在 Windows 上运行,用的是本机模型夹具而不是线上 API,而且没有任何 workflow 会调它。#1839 要的是把它做成一等支持,写这条记录时还没有回复。 - 有四条开着的 bug 说的不是分析本身,而是答案的形状。#1719 说
open_binary没起 provider 客户端就返回;#1720 说查询类调用死在一个 60 秒上限上;#1387 说新的小版本在一个上一版能跑完的 bundle 上中止;#1808 说 demo 模式的 Hopper 段错误之后留下一个中毒的会话。这四条里工具都答了话,而答出来的东西不是契约上写明的那个。
相关档案
全部档案 →第 135 号
OKF Agent Memory
把编码 agent 学到的东西以纯 Markdown 留在仓库里(一个用进程内 BM25 检索的 OKF v0.2 知识 bundle)于是这份记忆可以被 diff、被审阅,而不必住进数据库。
第 117 号
Whiteboard
一个桌面应用,让 agent 和人共用同一块画布。agent 把审查画出来(时序图、实体关系图、钉在某次提交上的代码引用)而画布上的每个形状都能跳回它被画出来时所指的那段代码。
第 107 号
OpenMausBot
一个开源聊天应用:侧栏里每个 bot 都是通过你机器上已有的 CLI 跑起来的真 agent,而且每一个都能分到一台电脑。这台电脑可以是云端 Linux 桌面、同一台主机上的 Docker 或 Podman 容器、你自己 VPS 上的容器,或者在平台能证明安全的前提下,就是你面前这台机器。


