企业官网建设流程全解析

• 逆向工程
• MCP 服务
• AI 技能

本文以 docs/roadmap.md 为主线，解读 REA（Reverse Engineer Anything）这一“用 Agent 逆向任意目标”的开源项目如何规划自己的能力演进：读完你可以掌握 REA 的证据优先（evidence-first）工具设计原则、当前六项开发优先级、已交付的 25 个 Ghidra 只读操作与 Windows x64 P0 边界，以及每个“Real-provider”能力声明背后必须通过的验证 lane，从而判断哪些能力可以直接用于生产分析、哪些仍属于实验或规划状态。

工具方向：证据直接返回，Agent 自己组合实验

roadmap 开篇即给出 REA 的产品定位：提供“检查、捕获、比较”三类工具，并且这些工具直接把证据（evidence）返回给调用方。Agent 负责选择命令、路径、浏览器动作、脚本和本地 fixture 服务器，然后基于返回的结果自行组合实验。这里有一条硬性约束：CLI 与 MCP 两种入口必须暴露等价行为，并且都要保留 observations（观察）、inferences（推断）与 unknowns（未知）三类信息——这正是 REA 区别于“黑盒自动化”的核心理念：工具不做替人下结论的事，只保证证据链完整。

roadmap 同时明确了两项已退役的设计，这帮助读者理解当前版本为什么“没有”某些常见功能：

• 上游 PR #555 移除了 REA 的权限授予（permission grants）、作用域上限（scope ceilings）、elicitation 与重复审批字段——即 Agent 调用工具不需要再走一套独立的授权协议；
• 上游 PR #572 移除了回放引擎（replay engines）、Node 特性化 prepare/execute 流程，以及 plan-only 的 managed runtime correlation 工具。这些系统属于已退役的 roadmap 项。

但退役不等于数据不可读：既有的 evidence authority 标签仍作为 provenance（出处标记）保留可读，只是不再隐含存在一个当前的回放执行器。

在安全边界上，roadmap 的表述是：本地操作使用当前操作系统的用户权限，不另建沙箱化的授权体系。每个工具的契约仍然包含输入与协议校验、provider 前置条件检查、目标身份验证、取消（cancellation）与自有资源清理；setup 流程在安装或写入前必须披露（disclose）变更并取得批准。这一原则在仓库源码中可以直接对应：例如 Windows 侧的原生控制模块（addon.cc、authority.hpp、filesystem.cc、process.cc）实现的是“当前用户 DACL + Job Object 进程归属”，而非越权沙箱，与 roadmap 的表述一致。

当前开发优先级（Planned work）

roadmap 将现有工作流指向 website 指南，然后列出了当前开发优先级的六个方向：

1. 保持生成式元数据与叙述性文档和工具、provider、setup 选项、发布版本对齐；
2. 在 Hopper 与 Ghidra 两个 provider 上扩展原生架构、类型与间接调用（indirect-call）的验证；
3. 将更多静态提取器与运行时观察连接起来，形成跨层（cross-layer）功能追踪；
4. 改进混淆 .NET 的比较能力，以及 managed 发现与已验证原生分析之间的关联；
5. 扩展 process、protocol、filesystem、reconnect 与 build-comparison 覆盖，以及 browser 与 Electron 场景动作；
6. 评估基于 LLDB、Frida、系统日志与 API tracing 的原生运行时观察，并评估 Binary Ninja、Rizin、LIEF 等额外工具，以及 Windows 原生工作流、移动应用与固件等目标。

其中第 2 项与上图所示的 Hopper 分析输出直接相关：roadmap 承诺的不是“能跑通 Hopper/Ghidra”，而是把两者的架构、类型与间接调用验证扩展到可互相印证的程度。仓库中对应的源码结构也印证了双 provider 并存的现状：src/ghidra/（约 45 个文件）与 src/hopper/（约 20 个文件）各自实现完整的会话、值提取与诊断逻辑。

roadmap 同时给出了一条准入规则：任何 provider 新增或平台支持，都必须具备对应的真实验证 lane（real verification lanes），并指向 docs/testing.md 与 docs/provider-evaluation.md 作为前置条件与具体命令的依据。这一点在仓库的 scripts/ 目录中有直接体现——verify-real-ghidra.mjs、verify-real-hopper.mjs、verify-real-ida.mjs、verify-real-ghidra-windows.mjs、verify-windows-native.mjs等脚本一一对应 roadmap 所说的“验证 lane 先行”原则。

剩余的证据与 Provider 工作

roadmap 指出，上游的 platform roadmap、process/Hopper fidelity tracker 与 browser tracker 三个 issue 仍在追踪剩余能力与证明（proof）。它们的范围遵循同一原则：以直接工具与 Agent 组合实验为准；自定义回放语言和授权系统不构成完成度门槛。

已落地的证据与比较行为方面，roadmap 描述了若干具体语义（这些是理解当前版本比较/诊断行为的准确依据）：

• Inline Evidence composition（上游 PR #585）：现在会把比较工具接受的完整记录直接返回，而不是截断视图；
• Managed 检查独立选靶：managed inspection 使用显式的 PE/CLI 目标，独立于原生 provider 的选择；
• 不完整观察保留 unknown：比较工具在观察不完整时保留 unknowns，而不是补默认值；
• PTY 诊断保留真实失败：loader 或启动失败以实际原因保留在诊断中；
• 浏览器清理报告不完整 teardown：清理不完整时与主失败一起上报；
• 瞬时文档失效范围收敛：transient documents 只使受影响 frame 的 WebMCP 注册失效，而不是全局失效。

roadmap 再次强调：real-provider 与平台声明仍然必须经过对应的验证 lane，才允许成为事实性声明。

已交付行为：Setup 与 12 个 Agent 客户端

roadmap 的“Shipped behavior”一节描述了当前 setup 的交付边界：

• setup 让你选择 Agent 集成与可选的 Hopper 安装；
• 它安装捆绑的工作流（workflow）、配置已检测到的 Agent，并可以为已存在的 Ghidra 安装保存经过验证的路径；
• 配置格式按各客户端自身规范适配，覆盖的客户端为：Claude Code、Claude Desktop、Codex、Cursor、Gemini CLI、Windsurf、Devin、OpenCode、Antigravity、GitHub Copilot CLI、Command Code 与 VS Code。

这一列表与源码完全对应：SupportedClients.ts 中为每个客户端定义了configPath、markerPath与format（json/toml/vscode/copilot_cli/opencode/commandcode等），并处理了各平台差异——例如 VS Code 在 Windows 上读%APPDATA%\Code\User、macOS 上读~/Library/Application Support/Code/User、Linux 上读$XDG_CONFIG_HOME/Code/User；OpenCode 则支持OPENCODE_CONFIG环境变量并探测opencode.json(.c)等多种文件名。配套的 Setup.ts、SetupPlan.ts、SetupClientConfiguration.ts 实现了 roadmap 提到的“披露安装变更并在写入前要求批准”的规划—批准流程，对应的行为测试包括 Setup.configuration.test.ts、Setup.planning.test.ts、Setup.recovery.test.ts。

Ghidra 分析能力边界：25 个只读操作

roadmap 对已交付的 Ghidra 能力给出了精确数字，这也是判断“现在能做什么”的关键依据：

• 平台：Linux x64 与 macOS x64/arm64，Ghidra 12.1.x；
• Java：需要 64 位 full JDK，取安装所声明的版本区间；当前 12.1 系列要求 JDK 21 或更新且不设上限，桥接层以Ghidra 12.1.4 + JDK 21验证；
• macOS 额外要求：匹配的 native decompiler（原生反编译器）；
• 操作面：13 个 inventory 操作 + 12 个 function-analysis 操作，共25 个只读操作；
• Linux/macOS 附加能力：原子化的函数改名与入口注释编辑（带刷新分析）；关闭时元数据被丢弃，可执行字节保持不变；
• setup 行为：经批准的 setup 只是把已验证的安装路径写入 Agent 配置，不会安装或修改 Ghidra 与 Java。

这些数字在源码中可以直接核验：GhidraProviderCapabilities.ts 从 GhidraInventoryValues.ts 导入GHIDRA_INVENTORY_OPERATIONS、从 GhidraFunctionValues.ts 导入GHIDRA_FUNCTION_OPERATIONS，并据此构造 provider 的能力描述符与 limitations；其中 inventory 的说明明确“符号清单包含内存与外部符号（含动态符号），但排除变量与无地址命名空间记录”。生成式的 product-catalog.json 则把全部 135 个工具按 family（direct、browser 等）分组列出，可作为 CLI/MCP 能力对齐的机器可读对照。

真实 provider 验证使用“宿主原生 debug 与 stripped 测试夹具 + 一个 native 类型布局对象”，并有独立 lane 覆盖 AArch64 ELF、PE 与 Mach-O 跨目标夹具；前置条件与精确命令见 docs/testing.md。

实验性 Windows x64 P0 边界

roadmap 将 Windows 支持明确限定为“Experimental Windows x64 P0”，并给出其交付内容：捆绑的 Job Object 归属、受保护运行时 DACL、以及针对本地 NTFS 上 x86/x86-64 PE 原生应用的 handle-based 准入（admission）。真实普通用户 CLI/MCP 验证覆盖全部 25 个只读操作与清理。

详细边界在 docs/windows-ghidra-p0.md 中：

• 支持边界：Windows 10+ x64、固定本地 NTFS 卷、Node.js 22.x (≥22.19)/24.x (≥24.11)/26+、操作者自备的 Ghidra 12.1.x（以 12.1.4 验证）与 64 位 full JDK、显式的原生非 managed 非 DLL PE 应用；
• REA 不安装Ghidra、Java、Python、npm、Node.js、Hopper 或编译器，也不要求用户自行编译原生 addon；
• rea doctor区分安装前置问题与原生工件/OS 失败，检查 Ghidra release、headless launcher、full JDK、x64 宿主与原生控制；
• 验证命令为npm run verify:windows-native与npm run verify:ghidra:windows（可加--x86），对应脚本 verify-windows-native.mjs 与 verify-real-ghidra-windows.mjs。

原生实现细节见 native/windows/README.md：准入用OPEN_REPARSE_POINT打开每个路径分量并保留 handle 以拒绝替换与源写入；运行时根以NtCreateFile相对已准入父 handle 创建，创建时安装保护 DACL 并回读校验“恰好当前用户 + SYSTEM”；快照通过 64 KiB 缓冲在 async worker 上流式化；PROC_THREAD_ATTRIBUTE_JOB_LIST把挂起的子进程原子地指派给无名、不可继承的 Job Object，disable breakaway，清理时等待所有 job 成员结束。该文档同时声明其不声称事务级崩溃删除：宿主进程猝死会杀死 job，但可能留下私有运行时文件。

roadmap 的表述与此一致：“P0 不暗示 process capture、Hopper 与广泛文件系统的 Windows 对等”。

Ghidra 维护边界

roadmap 用一个专门小节约束了 Ghidra 集成的演进方式，这些是后续贡献者需要遵守的工程规则：

• 格式与语义扩展只允许通过“规范化的、provider 中立的契约”加“真实 source-owned conformance”完成；
• 不期望 Hopper 与 Ghidra 的伪代码或汇编文本逐字一致；无目标的未解析流（targetless flow）保持 unknown；
• 若未来加入自动获取 Ghidra 的能力，那是一个单独规划与审批的相关工具变更；setup 永远不得安装 Java；
• Windows P0 的维护要求独立 DACL 回读、handle-based 准入、私有认证 IPC、以及在 provider 执行前完成 Job Object 指派；
• process capture、Hopper 与广泛文件系统敏感工作流是独立的 Windows 项目。

能力选择性 Setup（未来方向）

roadmap 的最后一个小节规划了 setup 的演进方向：当前 setup 已支持选择 Agent 集成与 Hopper 安装；当 REA 支持安装更多分析工具时，可把这些选择扩展到匹配用户想做的具体工作——例如询问操作者要研究原生二进制、网站、移动应用、固件还是运行时协议，然后只提议所选工作所需的工具。

该未来安装器必须保持当前安全边界的六条规则：

1. 检测并复用已存在的工具；
2. 披露每一个来源、目标、许可证、命令与系统影响；
3. 优先用户级（user-local）安装；
4. 只安装被显式选择的工具链；
5. 无人值守的系统变更需要工具级授权；
6. 报告就绪前逐一验证每个已安装工具。

roadmap 还特别强调：在另一个受支持的工具链让该抽象变得具体之前，不会实现占位式的工具选择或投机性的安装器注册表——这与全文“没有验证 lane 的声明不算数”的基调一致。

如何对照仓库验证 roadmap 声明

把 roadmap 当作事实来源时，仓库提供了三条可复现的核对路径：

适用前提需要说明：以上边界均以当前仓库 main 分支为准（product-catalog.json 中记录版本为 5.0.0），Windows P0 仍属实验性能力，且 roadmap 中指向上游 issue/PR 编号（如 #555、#572、#585）的退役与变更说明，其完整上下文需以上游跟踪器为准，仓库内文档保留了它们的行为后果但不含链接目标。

• 逆向工程
• MCP 服务
• AI 技能