能力边界与接入判断

接入决策从目标开始

前面已经把用途、源码和一次入门练习连接起来。本章不再增加工具名，而是回答最后一个问题：如果把它放进实际工作流程，哪些条件必须由我们补齐？先读采用判断，再核对版本、数据流和执行权限。

先写出待调查的软件产物、一个具体问题，以及能够判断回答对错的依据。再检查提供方、平台和真实可用工具。若没有可验收的问题，安装更多工具往往只是增加环境成本。

六章在这里回到采用决策：先明确逆向任务，再看产物、工具材料、模型解释与独立验证能否形成可复查的链。前面讲的是能力、方法和一个入门小样本，没有把它们写成某个完整应用已经调查成功。接入要看任务究竟缺少哪一环，而不是看到新工具就把整个系统改写。

本章的源码事实绑定 d13c9f84。公开 npm 6.4.0 来自 a56f7bb6；main 保留相同 package version，但已经增加功能与修正。因此版本字符串不足以辨别两份安装的内容。发布与 main 的区别

两项特别容易混淆的新能力

这不意味着发布版完全无法经手工 MCP 配置接入 Harness；“自动 setup 尚未发布”与“任何方式均不能连接”是不同结论。REA 的 main 配置走 Harness 官方的 @deepseek-ai/dsh-mcp-client，把外部 MCP 工具接入宿主工具注册表。

宿主的 Agent Loop 和模型调用仍在 Harness 中。该 bridge 不支持 MCP prompt templates；REA 的验证脚本使用本地 OpenAI-compatible 模型 fixture，文档没有把它声明为 live DeepSeek API 验证。REA client 配置说明、Harness 官方 MCP-client 文档

这个组合的边界可以写成：DeepSeek 等模型提供语义推理；Harness 推进调用、管理上下文和权限；MCP bridge 适配协议；REA 工作流取得目标证据；分析引擎或观察器实际读取或操作目标。它们各自可失败，连接成功不代表这条业务调查已经完成。

因此不需要为了研究 REA 更换现有宿主，也不必先申请另一家模型的 API Key 才开始静态练习。等到真的比较不同模型的调查能力，再记录提供方、模型标识、采样配置、成本和任务条件。当前不把已有的协议 fixture 测试算成远端模型成绩。

本地运行的真实含义

REA 取得本地分析结果后，宿主 Agent 会消费这些结果。若宿主使用远端模型，相关内容可能进入模型请求。分析引擎自身也有不同模式与数据政策，需要按实际配置确认。不能从“本地解析”直接推出整个调查过程离线或所有资料都留在本机。项目的数据说明

部分观察器会减少敏感字段，但范围有限。例如浏览器 metadata 测试明确要求删除 Authorization、Cookie 等 header，同时保留完整链接中的 query。截图、源码、日志或终端输出也可能包含待审查内容。具体脱敏测试

运行进程时，sensitive 输入字段可以被隐藏；这不能被理解为终端回显会自动消失。结果记录有保留 raw terminal data 的路径，应根据实际输出判断公开边界。输入表示、终端数据保留

需要分别画出三条数据流：目标文件进入本地解析器或外部引擎；分析结果进入宿主上下文或模型请求；经过筛选的研究结果进入公开网站。第一条留在本地，不代表后两条也留在本地。把结果保存为 JSON 也不意味着它适合上传 GitHub。

软件产物中的字符串、日志、网页提示和工具返回内容还可能包含误导模型的指令。REA 的来源与工具输出标记有助于说明这些是待分析数据，但不构成对 prompt injection 的完备防御。宿主应将目标内容作为数据，不允许它修改授权范围、发起额外网络传输或要求泄露凭据。MCP 不可信内容边界

资源控制与执行权限

REA 为多个路径设计了私有工作目录、进程所有权、超时、响应预算和清理机制。这有助于控制资源、绑定目标和处理失败，但不是通用操作系统 sandbox。打开不可信二进制，会让实际分析引擎以当前用户权限解析它；运行时捕获则会执行或操作选定目标。项目的安全边界

Frida 的用户脚本在目标进程中执行，拥有该进程的内存、文件系统和网络权限。消息保留预算不限制脚本的全部资源；它与只读静态分析应采用不同的使用判断。main 的 Frida 说明

我们的练习先使用自己编写或明确允许分析的目标。REA 本身为 MIT 许可，外部引擎及第三方材料保留各自许可；REA 不提供商业工具的授权。第三方说明

平台与预算要落到选定路径

“有 Node 就能启动 CLI”不等于每个 provider 都能运行。Hopper、Ghidra、IDA，以及设备、浏览器和运行时观察都有各自宿主条件；购买或安装引擎之前，要核对所用 release 的安装文档、目标架构和真实可用性。某个 Windows 实验路径也不能扩写成所有工具均跨平台支持。固定源码的安装与平台说明

本网站承载的是研究文档，不是一个远程二进制执行服务。若以后想把 REA 工具接到服务器，必须另行设计目标上传、存储、访问控制、进程隔离、引擎授权和清理。不能因为网站部署成功，就认为本地引擎、GUI 或任意目标进程能原样运行在相同托管环境。

一次调查的总成本至少包含环境准备、产物解析与引擎时间、模型 token 与往返、人工复核、独立测试。摘要可以减少单次交付体积，但不保证整体解析成本或总 token 一定下降；模型不停重复读取相同结果也可能增加成本。应为任务设置查询与时间预算，并允许以带未知的调查报告结束，而不是无限追求“还原全部”。

如何与已有 Agent 系统结合

如果系统的任务需要调查软件产物，可以把 REA 接在工具层：明确目标和允许的操作，保存分析配置，取得证据，再由宿主控制循环与预算。最终业务决策还要使用可验证的规范与独立测试。

如果现有任务只是搜索文档、计算确定性指标或处理拥有完整源码的普通业务逻辑，先用已有工具更直接。是否采用 REA，应由缺少的观察能力决定。REA 的加入也不会自动解决 Agent 的上下文整理、长任务恢复或业务正确性问题。

与 Harness 专题中的接入判断交叉阅读时，可以分别问三个问题：宿主怎样推进任务？工具实际能观察什么？结论由谁、用什么证据验证？

一个可以复用的接入判断表

对我们已有的 Agent Evidence Lab 或 a-stock-strategy，这次不作替换或接入。前者只有在研究任务需要软件产物证据时才可能把 REA 当作一个专用工具；后者的策略信号、回测时序与指标计算需要其自身数据契约和确定性测试，不能交给 REA 或模型语言解释决定。这里是职责划分建议，不是对两个项目当前代码的重新审查。

最小接入契约应写清什么

如果后来确定需要接入，应至少声明：哪些目标允许读取；是否允许执行、驱动浏览器或插桩；固定哪个 REA 与引擎版本；输出怎样绑定目标与保存；什么内容可以交给远端模型；未知怎样记录；由谁验证并决定停止。

先开放足够回答问题的只读路径，再根据真实缺口增加运行权限。默认把高权限工具全部交给模型，并不能替代这种范围设计。失败时也不应自动换 provider、改目标或扩大权限，因为这些变化会影响原来结论的含义。

可以先用下面的检查单与工程同伴或协作 Agent 对齐。它是采用前的约定，不是已实现的权限策略配置，也不会仅因贴进提示词就得到强制执行。

任务：待回答的问题，以及独立验收依据。
目标：允许接触的产物、版本、目录与实际运行环境。
操作：静态读取 / 实际执行 / 浏览器驱动 / 插桩，分别授权。
版本：REA release/commit、所选 provider、引擎版本与平台。
数据：什么可留本地、什么可送模型、什么可公开。
保留：Evidence、原始命令、未知修订与输出目录的保存规则。
验收：由谁判断，通过哪些固定条件，而非由模型自评。
停止：时间与查询预算、环境失败时的处理、何时需要人工决定。

运行时系统仍需用真实的工具权限、进程隔离、访问控制和审计来落实这些约定。文档帮助明确边界，不代替边界本身。

这个专题接下来怎样增长

已经从源码首版推进到最小 JavaScript 实跑：两份自有产物在 Linux 上完成静态分析，Mac 上完成已保存 Evidence 的返回形状比较，五项行为对照区分了正确版、缺陷版和候选。Mac 分析启动失败也保留在实践记录。这些是特定版本和小样本的结果，不扩展为原生引擎或复杂应用已验证。

仍待回答的研究问题包括：Agent 比人工调查节省了哪些步骤；复杂动态应用的 unknown 怎样影响结果；摘要与证据分页怎样影响上下文；不同模型怎样改变调查质量；失败后怎样可靠恢复。完成对应实验后，再追加数字、失败记录和采用判断。

下一阶段应优先增加带独立 oracle 的原生小函数与实际 MCP 连接记录，再考虑跨进程 Electron 场景和人工/不同模型的对照。当前写作 Agent 事先知道样本答案，不能用本次记录判断独立逆向能力或提效。每项结果继续绑定版本、目标和输入范围，保留失败与后续修正。