给代码审查智能体加上隔离安装验证

安装一个陌生项目，风险可能在第一次 npm install 时就发生。RepoPilot 的作者给现有 Agent 增加了一个工具：把 GitHub 仓库放进一次性的 AWS CodeBuild 容器，实际执行安装，再报告运行中发生的行为。

它想补上静态扫描与真实执行之间的缺口。这个方向值得前端和 Node 开发者了解，但提供的原文在问题部分就截断了：能看清方案主张，还看不到完整实现和验证过程。

扫过仓库，为什么还要运行安装

RepoPilot 把检查分成两步：先扫描仓库并评分，再到隔离环境里运行安装。作者将前者称为「猜测」，将后者称为「证据」。

这里最关键的是 postinstall。它是安装生命周期中的脚本入口，安装依赖时可能执行代码。检查文件能发现可疑线索，实际运行则有机会观察这些代码在当前环境中做了什么。

作者声称，新工具捕获到了静态扫描没发现的 curl | bash 行为，也就是下载内容后交给 shell 执行。不过，原文没有展示具体命令、执行日志或扫描规则，无法判断这次漏检是扫描器能力不足、规则缺失，还是行为需要运行条件才会出现。

运行安装能补充行为证据，但一次运行没有异常，不能证明依赖安全。

这个新工具给 Agent 增加了什么

作者没有重新搭建一个 Agent，而是给已有 Agent 增加执行能力。原文描述的流程很直接：

1. 克隆一个 GitHub 仓库。
2. 在临时 AWS CodeBuild 容器中实际执行安装。
3. 报告运行中发生的行为。

「一次性沙箱」可以理解为专门接触不可信代码、用完即弃的执行环境。作者希望把风险从开发者的电脑转移到这个环境里，避免让陌生仓库直接接触日常开发机器。

项目还展示了 Amazon Bedrock、Nova Pro 和 Strands 标识，但这段原文没有说明它们各自负责哪些步骤，也没有给出模型如何解释日志、如何触发工具的细节。不能仅凭这些标识，就推断项目具备完整的自动安全分析能力。

更关键的实现也缺席了：用什么安装命令、采集哪些行为、如何识别异常，以及运行结束后怎样清理资源，都没说清。因此，现在能复述的是工作流程，尚不能照着复现一个隔离可靠的沙箱。

我的判断

我认可把「扫描结果」和「运行证据」放在一起看。对陌生仓库，只看源码和依赖元数据，确实无法回答所有执行行为问题；让 Agent 调用受约束的执行工具，也比让它凭代码内容下结论更有依据。

但标题里的「停止相信 npm 扫描」说得过满。静态检查与动态执行提供的是不同证据，原文没有对照数据，不能据此认定动态方案可以替代静态扫描。作者声称捕获了一次可疑行为，这是一条案例主张，还不是检出率或漏报率的证明。

另一个前提是隔离配置。临时容器是否安全，还取决于权限、凭证、网络访问和资源限制。原文没有展示这些配置，不能把「部署在 AWS CodeBuild」直接当作安全保证。

与直接在开发电脑上安装相比，这个思路有明确价值；与配置完善的隔离 CI 相比，它新增了多少能力，现有材料无法判断。AI 在其中带来的收益，同样缺少证据。

能拿来做什么

• 接手陌生前端或 Node 仓库时，先检查安装脚本和依赖，再决定是否放进隔离环境执行，把源码线索与运行记录一起评估。
• 给 AI 编程助手增加安装工具时，把执行环境与日常开发环境分开，并明确它能读取哪些凭证、访问哪些网络和资源。
• 评估类似产品时，要求查看安装命令、原始日志、异常判定依据和隔离配置。单独一个风险评分，不足以支持安全结论。