REA 把逆向工程任务接到 CLI 和 MCP 服务上，让你从终端或 Agent 发起分析。第一次配置，更推荐用一个自有的小项目走通“入口验证—客户端连接—分析—证据核对”，不要直接拿生产程序试手。
教程的关键是把两件事分开验收：REA 是否正常运行，以及它对目标的解释是否正确。前者看进程和工具调用，后者看原始文件与可复现的行为。
查文档确认支持对象与依赖
从 REA 条目 进入项目文档，先找安装说明、CLI 用法和 MCP 接入示例。“对任何东西进行逆向工程”是能力概述，不能拿它替代输入格式清单。
安装前，把下面几项记下来：
| 要确认的内容 | 后面用在哪里 |
|---|---|
| 接受源码目录、单个文件还是其他对象 | 选择分析样例 |
| 运行时及版本要求 | 创建本地环境 |
| 官方安装命令和 CLI 入口名称 | 安装与入口检查 |
| MCP 启动参数及传输方式 | 配置客户端 |
| 模型、凭据与外部工具要求 | 排查启动和分析失败 |
尤其要区分“CLI 分析命令”和“MCP 服务启动命令”。直接运行一次分析的入口，通常会完成任务后退出；客户端连接的服务则要按协议持续交互。把前者填进服务配置，常见结果就是进程启动后立刻断开。
下面的终端步骤使用 macOS 或 Linux 的 Bash。样例选择 Python 源码；确认 REA 接受这类输入后，再走这条路线。二进制、流量文件和网页各有不同的处理链路，不要靠修改扩展名把它们塞进源码分析流程。
准备自有或授权的最小样例
首个项目只保留一个入口、一个转换函数和几组输入输出。这样分析结果出现偏差时，可以直接定位到某一行。
mkdir -p "$HOME/rea-lab/input"
cd "$HOME/rea-lab"
cat > input/token_demo.py <<'PY'
import base64
import sys
def encode_token(text):
payload = text.strip().encode("utf-8")
return base64.urlsafe_b64encode(payload).decode("ascii").rstrip("=")
if __name__ == "__main__":
print(encode_token(sys.argv[1]))
PY
python3 input/token_demo.py ' hello '
python3 input/token_demo.py 'hello'
python3 input/token_demo.py ' '
前两次输出都是 aGVsbG8，第三次输出空行。这个样例包含三个适合核对的行为：去除首尾空白、URL-safe Base64 编码、删除末尾的填充字符。
再保存一份带行号的源码，方便后面逐条检查：
nl -ba input/token_demo.py > source-numbered.txt
只把 input 目录交给分析工具，测试记录留在外面。先让它从目标中推导行为，再和记录比较，验收更有意义。
自有项目也可能包含密钥。分析目录中不要放 .env、访问令牌和真实用户数据；如果配置了远程模型，相关文件内容可能被发送到模型服务，首轮用这里的纯测试代码就够了。
安装并验证命令行入口
按 REA 文档里的安装命令安装，保留完整输出。不要从项目名称猜包名，再尝试 pip install 或 npm install：同名包和错误入口会把后续排查带偏。
安装结束后，在当前终端检查真实的 CLI 名称。下面的变量由你输入，不预设 REA 的可执行文件名：
read -r -p "输入文档中的 CLI 入口名称：" REA_CLI
command -v "$REA_CLI"
成功检查点是输出可执行文件路径。没有输出时，先检查安装是否完成，以及安装目录是否进入 PATH，不要急着配置客户端。
接着运行文档列出的帮助命令和最小调用。此时要确认三件事：帮助信息正常显示、参数能被识别、没有运行时或模块缺失错误。帮助信息能显示，只说明入口可执行，还没验证分析链路。
如果安装过程使用了虚拟环境，保存该环境内入口的绝对路径。GUI 客户端不会自动继承你在终端里执行过的环境激活操作。
配置客户端并检查接入
先确认 MCP 传输方式。下面仅展示 stdio 接入结构，用于理解字段；其中的占位值要替换成文档中的真实路径和参数，不能原样粘贴启动。
{
"mcpServers": {
"rea": {
"command": "/ABSOLUTE/PATH/TO/EXECUTABLE",
"args": ["MCP_START_ARGUMENT"],
"env": {}
}
}
}
command 放可执行文件，args 按参数拆成数组。不要把整条带空格的启动命令塞进 command。只在 env 中加入文档要求的环境变量。
客户端使用其他配置结构时，把这三个信息映射到它的服务配置中；HTTP 接入则填写服务地址，不套用上面的 stdio 示例。
保存配置并重新连接后，按这个顺序验收：
- 客户端启动了服务进程，且没有立即退出。
- MCP 初始化完成。
- 客户端列出了 REA 暴露的工具。
- 工具描述中的输入参数和目标类型符合预期。
第三步特别重要。聊天窗口显示“已连接”还不足以确认分析工具可调用。先看工具列表，再发任务；不要自己编一个 analyze 工具名让 Agent 调用。
发起分析并核对原文件
在终端拿到样例的绝对路径：
cd "$HOME/rea-lab"
pwd -P
把输出路径与 /input 拼接，交给客户端。分析请求可以这样写：
请调用已连接的 REA 工具分析下面的自有源码目录：
<替换为 input 目录的绝对路径>
目标：
1. 找出程序入口与调用关系。
2. 解释输入字符串到输出字符串的每一步转换。
3. 说明空白输入、非 ASCII 输入和缺少命令行参数时的行为。
4. 每个结论附上文件路径、函数名和相关代码位置。
5. 将源码直接支持的结论与推测分开列出。
只做静态阅读，不修改文件，不安装依赖，不执行目标代码。
检查客户端的工具调用记录：实际调用了哪个工具，传入了什么路径，返回了内容还是错误。没有发生工具调用的回答，不计入这次接入验收。
阅读结果时，优先找证据定位。样例中，strip() 解释了为什么 ' hello ' 和 'hello' 输出相同；rstrip("=") 解释了为什么结果没有填充字符。把 Base64 描述为加密属于概念错误，应回到 base64.urlsafe_b64encode 这一行纠正。
缺少参数的行为也值得核对：
python3 "$HOME/rea-lab/input/token_demo.py"
源码直接访问 sys.argv[1]，没有参数检查，这条命令会触发 IndexError。如果分析结果写成“显示使用帮助”，就要求它重新引用入口代码。
按依赖、路径、权限、输入排错
排错时保留第一条有意义的错误，别只截最后一句“连接失败”。
遇到 command not found，先查 CLI 入口和 PATH。遇到 ModuleNotFoundError 或 Cannot find module，检查启动入口所属的运行环境，避免把依赖装到另一个解释器或包环境里。
遇到 ENOENT、No such file or directory，分别验证可执行文件路径和目标路径。终端的当前目录与客户端工作目录经常不同，目标统一使用绝对路径。
遇到 Permission denied，检查目标是否可读、目录是否可进入、入口是否可执行。不要用 chmod -R 777 掩盖问题，它会扩大整个目录的写入权限。
进程能启动但 MCP 初始化失败，再查启动参数和传输方式。stdio 服务的标准输出用于协议通信，启动脚本向 stdout 打印欢迎语也会干扰连接，诊断日志应写到 stderr。
最后才查输入支持范围：缩小到一个文件，对照工具参数和支持对象重新调用。首轮验收建议保留三份记录：启动命令、实际工具调用、带源码位置的分析结论。以后换成真实项目，哪一层出了问题，会清楚得多。