检查二进制布局
对获准分析的制品使用 rea inspect-binary-layout 并输出 JSON，取得文件布局证据。
REA
REA 为编程 Agent 提供 CLI 和 MCP，可检查获准分析的二进制与应用。先选一份本地制品，再为每条结论保留对应的检查证据。
用 REA 检查获准分析的二进制
明确本地制品和要核验的问题，再选静态检查方式。
带入 Floatboat 的请求
请求可预览和复制，不会从此处自动发送。
参考来源: REA https://github.com/morluto/rea 先阅读原始说明并核对当前环境与依赖。需要安装或连接新工具时，先提出方案。 我的任务: 阅读 REA 官方二进制诊断文档，先检查 CLI 或 MCP 是否可用，再展示针对我获准分析的二进制的只读布局检查方案。我确认后执行检查，无需启动被检查的程序，并把证据与摘要一起保存。 期望交付: 一份带制品引用和对应证据的布局摘要。
关于 REA
REA 的全称是 Reverse Engineer Anything。它将软件制品检查工具接到编程 Agent，可按上游文档安装 Codex 插件、注册 MCP 服务，或在获准使用的终端运行 CLI。
逆向分析 Skill 提供工作流程，实际检查由已接入的 REA 工具执行。插件可以同时提供 Skill 与服务；单独安装 Skill 时，还需按任务配置 MCP 和分析引擎。
先根据制品类型和问题选择检查操作。静态布局报告可以说明架构或节区信息，深入分析可能需要兼容的后端。记录工具返回的证据，并标明自己的解释与待核查项。
REA 可以检查哪些内容
先确认当前客户端能运行哪些工具，再选静态检查或需要分析后端的操作。保存输入与结果来源，方便其他人复现关键观察。
核对分析工具
在当前 MCP 会话调用 binary_session，查看工具可用性及不可用的原因。
保留观察依据
记录输入、检查操作与分析后端，并在报告中保留无法完成的检查。
REA 的软件制品检查场景
从一个已知的本地制品开始，按问题逐步扩展范围。可以交付静态布局报告、两个版本的证据对比，或后续分析所需的交接记录。
核对内部构建产物
提供自己团队编译的二进制和预期目标架构，让 Agent 在不启动程序的情况下检查布局，再对照构建配置核对架构和节区信息。
盘点桌面应用包
将团队有权检查的桌面应用包交给 REA，整理可执行文件和资源候选。由复核人选定相关文件，并界定下一步检查范围。
比较两个发布版本
为两个获准使用的二进制执行同一项静态检查，分别保存证据。整理变化的节区或布局细节，再交给发布工程师核对。
诊断分析后端缺口
让 Agent 从已连接的 MCP 服务查询工具可用性。将返回结果与待做操作对照，记录缺失的前提，并为暂时无法执行的部分提出更小的检查范围。
运行 REA 前的准备
先提供获准分析的制品和具体问题。根据操作核对客户端、平台与可选分析后端，并确定保存输出的位置。
获准检查的制品
提供有权分析的文件或应用，明确路径，第一次先做静态检查。
可用的 CLI 或 MCP
遵循所用客户端的一种官方安装路径，并在当前客户端验证插件或服务。
任务所需的分析后端
在当前客户端检查对应操作是否可用，需要时再配置额外工具。
相关软件项目
比较这些项目的用途、运行条件和源码许可。
REA 常见问题
REA 是 Skill 还是检查工具？
项目提供 CLI 和 MCP 工具，也包含流程 Skill。Agent 可以按 Skill 组织检查，实际操作取决于已安装的工具。
Codex 能调用 REA 吗？
上游安装指南提供 Codex 原生插件和独立 MCP 注册两种路径。可以在对应客户端中核对当前接入状态。
安装 Skill 后就有 MCP 吗？
单独安装 Skill 会提供任务指引与参考资料。需要 MCP 服务或分析引擎时，按上游文档另外配置。
可以不运行二进制就做检查吗？
可以。inspect-binary-layout 是静态布局检查，能返回文件布局证据，无需启动被检查的程序。
怎样核对二进制分析工具是否可用？
调用当前 MCP 服务的 binary_session，查看 tool_availability。它反映的是该客户端实际连接的服务环境。
交接时应保留什么？
让每条观察带上制品引用、所用操作、分析后端和对应证据，并写明未解决的问题，便于复查。