用九十分钟验证远程 Agent 环境

免费服务器上，AI 写出的补丁没问题，换到 CI 却跑不起来，原因可能出在运行环境。原文提出一个 90 分钟验证法：先比对两边环境，再让同一个真实补丁通过同一组命令，判断这台免费主机是否适合接入开发流程。

值得借鉴的是验证方法，而不是免费额度。作者没有提供实测结果，文中的脚本也有需要修正的地方，不能复制后就当成完整验收工具。

先写下失败条件，再让 AI 动手

作者要求计时前只写一个假设：免费服务器生成的补丁，能够通过本地 CI 使用的五命令契约测试。这里的「契约测试」，就是两台机器共同遵守的一套检查流程。

把假设提交到仓库，再开始实验，是为了避免看到失败后临时修改标准，最后把一次演示包装成验证通过。

示例记录给出的门槛是：首次通过测试不超过 25 分钟，环境差异最多 2 个字段，每个字段的修复时间最多 10 分钟。这些是预设标准，不是作者测出的成绩。门槛与假设必须放在同一次提交中；修改门槛，就另选一天重新实验。

90 分钟到了就结束，记录不完整也算结果。

记录中的 observed 允许填 null，不允许凭感觉补数字。作者还要求记录首次运行时间、首次通过时间和审查时间，并让同事在没有事先讲解的情况下阅读 diff。机器跑通只是其中一关，人工理解补丁的成本也要算进去。

两边跑同一套命令，才有资格比较

环境指纹脚本 drift.sh 收集操作系统、Node、Python、package-lock.json 哈希、时区、语言区域、CPU 核数和内存。锁文件哈希只保留前 16 个字符，用来快速识别依赖基线是否一致。

作者给出下面的命令，意图是在本地和免费服务器分别采集，再排序比较 JSON：

./drift.sh local.json
ssh <free-server> 'bash -s' < drift.sh > server.json
diff <(jq -S 'del(._end)' local.json) <(jq -S 'del(._end)' server.json) | tee drift.diff

需要检查第二行：按原文脚本，JSON 会写进远端的默认文件 fingerprint.json，标准输出只有 wrote fingerprint.json。因此本地 server.json 接到的是提示文本，后面的 jq 无法按预期解析。实际使用时，需要取回远端文件，或调整输出方式。

作者也明确说，这份脚本只是模板，没有在读者的机器上运行过。发现十几行差异是调查结果，发现缺少 node 则是停止当前方案的信号。

接下来，两台机器按相同顺序执行五个命令：

set -e
npm ci --no-audit --no-fund
npm run lint
npm test -- --runInBand
git status --porcelain   # must print nothing
node -e 'console.log(process.version)'

重点看 npm ci 和最后两行。前者按锁文件安装依赖，不能跳过，也不能加 || true 掩盖失败；后两行用于暴露工作区改动和 Node 版本差异。

不过，git status --porcelain 即使输出了文件列表，通常也会成功退出，set -e 不会自动把它判为失败。最后一行同样只是打印版本，没有自动比较两边是否一致。这套命令提供了检查材料，还需要明确的判定步骤。

免费资源解决的是第二台主机从哪里来

原文披露，这是 MonkeyCode 的产品推广内容。维护者将它介绍为开源 coding-agent 项目，并提供免费模型访问和免费服务器选项。

截至原文标注的 2026-11-07，免费额度据称约为 1000 万 tokens。作者提醒，这不是长期承诺，额度和可用性可能变化；模型名与当时的额度快照都应进入实验记录。

这个产品与实验的连接点很具体：环境对比需要第二台主机，免费服务器降低了取得它的成本。补丁是否合格则交给测试判断，不能从免费额度推导模型质量。

实验只选一个真实待办，不选玩具函数，也不同时测五个补丁。作者用 /usr/bin/time -f '%e s wall, %M KB peak' 包裹测试命令，将输出写入 timing.txt，观察耗时和峰值内存。但单补丁、单次运行只能算一个数据点，不能当性能基准。

记录示例将下次复查日期设为 2026-12-07，并建议每月重跑。defer 表示延期处理，必须有日期和负责人，否则按 kill 处理。它不能变成一个长期悬而未决的「以后再说」。

我的判断

我认同先测环境兼容性，再讨论接入收益。对 Node 项目而言，运行时、锁文件和权限问题足以让正确补丁失去可用性，提前检查能缩小排错范围。

但「多数免费试用失败都源于环境漂移」是作者的判断，原文没有失败样本或对照数据。「花 90 分钟避免一个月间歇性 CI 失败」同样没有实测支撑，不能当成收益承诺。

通过这次实验，只能支持有限的主机兼容性结论。

指纹没有覆盖内核行为和系统调用，测试通过也不等于生产环境一致，更不证明模型优秀。原文对 ship、defer、kill 的完整判定规则也没有展开，团队仍需补齐。

对于原生工具链、GPU 构建、长编译任务，以及单次 npm ci 就超过 10 分钟的 monorepo，作者更推荐固定配置的 devcontainer。它适合把环境要求固化下来；90 分钟实验适合快速筛掉不合适的主机，两者可以接续使用。

能拿来做什么

• 接入远端 AI 编程环境前，先从一个真实 Node 或前端仓库采集两边指纹，把 Node、锁文件、时区等差异记录到仓库，再决定是否开始修补环境。
• 把五命令流程改成可判定的检查：明确拒绝脏工作区，核对允许的 Node 版本，并先修复远端指纹文件的获取方式。
• 给试用设定时间上限，记录首次通过时间、修复时间和人工审查时间；没有测到的项目保留 null，不要把试用结果包装成基准成绩。
• 使用共享主机前先审查密钥处理方式；涉及受监管或客户数据时，遵守原文的排除条件。免费条款变化后重新验证，并把已确认的环境要求固化到 devcontainer。