Agent任务上共享机前，先做这五项假设检查

在共享硬件上运行Agent任务，失败的原因往往不是模型本身有问题，而是工作区突然变为只读、时钟漂移导致token过期、某个外部主机被阻断，或者两个任务同时写入同一目录。这些问题不会出现在能力评估里，因为它们问的不是"这台机器能做什么"，而是"你默认它会一直保持什么状态"。

原文作者提出了一套轻量级操作框架：把隐性假设转化为五项检查、三个角色和一张Wiki页面，在任务启动前完成验证。

Agent任务共享环境检查框架

为什么共享环境让假设更容易失效

专用主机上环境稳定，你根本不会去想它。但免费层或共享实例的本质就是：机器是共享的、可能被回收、你无权配置。原文指出，MonkeyCode提供免费模型访问和免费服务器选项，把Agent运行成本压到接近零——而这恰恰是团队停止记录环境假设的诱因，因为重试看起来比写文档更便宜。

核心论点在这里：成本越低，越容易忽略环境验证。但一次静默写入失败、一次token过期导致的401，排查时间远超提前做检查的成本。

五项值得检查的假设

原文给出的检查表刻意排除了性能测量和模型对比，只关注环境假设。每一项都便宜可验，但发现晚了代价很高。

假设	不成立时的后果	低成本检查
工作区可写且有空间余量	运行中途写入失败，或磁盘静默占满	`touch`探针文件，再用`df -Pm`
系统时钟大致正确	token过期、缓存TTL、日志顺序全部失真	对比HTTP `Date`响应头
任务需要的每个主机可达	调用挂起直到超时，而非服务端返回	对每个主机发一个`HEAD`请求
凭证存在且不会被打印	一小时浪费在看不见的401上	长度检查加短哈希
本次运行只有你在写	两个Agent交错写入同一目录	对运行锁执行`flock`

注意这里没有吞吐量声明、没有模型比较。这是一份假设台账，不是基准测试。作者建议把预检脚本放进代码仓库而不是某个人的home目录，这样评审者能读到到底检查了什么。

flock 与建议性锁：flock 是 Linux 上基于文件描述符的 advisory lock（建议性锁），它并不会在内核层面阻止其他进程写入同一目录，只对“愿意先获取同一把锁”的协作进程生效。因此原文强调它“只阻止协作的运行，不阻止蓄意的运行”。exec 9>"$LOCK" 的作用是把锁文件绑定到文件描述符 9，随后 flock -n 9 以非阻塞方式尝试加锁；一旦脚本退出，描述符关闭，锁自动释放，避免死锁残留。需要注意的是，flock 依赖文件系统支持，NFS 等网络文件系统上的行为可能与本地磁盘不一致，跨主机协作时应改用带租约的分布式锁。

df -Pm 的可移植输出：-P 强制 POSIX 格式，保证每行固定为六列且长设备名不换行；-m 以 MB 为单位输出。两者组合的目的是让脚本可以用稳定的列号（通常是第 4 列）解析可用空间，而不依赖人类可读的 -h 输出。若目标系统没有 GNU coreutils（如 BusyBox 或 macOS），df -Pm 的参数可能不被接受，预检脚本需要为此准备回退分支。

三个角色与两次交接

角色数量要少到小团队真的会执行。

Run Owner（运行负责人）：写运行行、维护五项假设、把预检报告粘贴到Wiki页面。无权宣布任务就绪。

Box Steward（机器管家）：负责共享主机或层级，维护出站白名单，是唯一能签署例外的人。当检查失败但任务仍须运行时，管家要记录哪项假设被豁免、豁免到何时。

Reviewer（评审者）：在合并前读取运行行和报告哈希。评审者的工作不是重跑脚本，而是注意到报告已经三天了，或者运行行悄悄多了一个出站主机。

两次交接都是Wiki编辑而非消息通知：任何FAIL触发Run Owner → Box Steward；门禁通过后触发Run Owner → Reviewer。这样下一个接触该任务的人能继承推理过程。

实操：预检脚本与门禁

原文提供了可直接落地的preflight.sh，核心逻辑是断言五项假设并逐行打印结果，任何失败都以非零码退出。几个值得注意的实现细节：

工作区检查用mkdir -p加touch探针，再用df -Pm取可用MB数，默认阈值512MB
时钟检查取第一个出站主机的Date头，与本地UTC时间对比，默认容差120秒
凭证检查只输出sha256前10位，绝不打印原值
运行锁用exec 9>"$LOCK"加flock -n 9

作者特别提醒可移植性问题：脚本假设bash 4以上（用于${!SECRET_VAR}间接展开）、GNU coreutils和flock；macOS上需要把date -u -d替换为gdate或Python单行命令。

门禁脚本gate.sh解决"没人读的预检只是装饰"的问题：它拒绝在报告不完整时启动任务，逐项确认workspace、clock、egress、secret、run五类关键词都有OK记录，最后用报告哈希（sha256前12位）作为可粘贴到Wiki的指纹。

${!SECRET_VAR} 间接展开：这是 bash 4 引入的间接变量引用语法。当变量名为动态拼接（例如 API_TOKEN 与 CI_TOKEN 共用一段检查逻辑）时，${!name} 会先展开 name 的值，再以该值作为变量名取其内容。bash 3.2（macOS 自带版本）不支持这一语法，脚本会直接报 bad substitution。可移植的替代写法是 eval 或 printf -v，但 eval 在涉及密钥时存在注入风险，因此原文建议整体升级工具链而非临时改写。

报告哈希作为指纹：门禁用 sha256 前 12 位标识一份报告，是一个折中：完整哈希过长不便粘贴，前 12 位（48 bit）在团队规模下碰撞概率可忽略，同时足以让 Reviewer 确认“我读的报告”与“门禁放行的报告”是同一份。哈希只证明内容未被改动，不证明内容为真，所以仍需 Reviewer 人工判断报告是否过期。

一页Wiki模板

原文给出的Wiki页面包含运行行、步骤和例外表。运行行记录job、box、workdir、egress、secret、deadline_utc，步骤从预检到门禁再到运行后追加退出码和耗时。

有一个容易被忽略的步骤：运行结束后追加"第一行滚过去的输出"。作者指出，这一行通常解释了下一次失败的原因，在运行还新鲜时记下来成本为零。

例外表记录日期、被豁免的假设、签署人和过期时间——这比事后复盘便宜得多。

运行行（run row）的设计意图：运行行是一行结构化字段而非自由文本，目的是让放置决策、环境假设和责任人可以在一个固定位置被检索和比对。deadline_utc 使用 UTC 而非本地时间，正是为了与时钟检查的基准一致，避免因时区换算在交接时产生歧义。把 box= 写进运行行，等价于给任务贴上“它依赖哪台机器”的标签，当某台共享机被回收或白名单变更时，可以反查受影响的运行。

任务该放哪：写进运行行

原文用一张表把放置决策从聊天里拉回文档：交互式调试放本机；可重复批处理放共享免费机；需要稳定公网IP或入站端口的放自己管理的主机；大数据集或GPU放付费的足量主机；涉密或受监管数据放自有环境。

选定哪一行，就写进运行行的box=字段。未来的你不会记得任务为什么搬家，表格比事后复盘便宜。

局限与不该用的人

原文坦率地列出边界：预检是时间点断言，只证明你运行那一刻的环境，共享机十分钟后就可能改变主意；门禁是减速带不是保证；它不测量性能、质量或成本；flock检查是建议性的，只阻止协作的运行，不阻止蓄意的运行。

如果配置管理或现有健康检查已经覆盖你的主机、你运行完全控制的单租户基础设施、或任务启动不到一秒且无法容忍探针，就不该套用这套流程。受监管工作负载同样应跳过：五项检查告诉你机器可用，不告诉你它可审计。

对于想先练手的团队，原文建议用MonkeyCode的免费模型访问和免费服务器选项，在一台可以随意丢弃的机器上弄清楚自己的任务到底假设了什么——先从项目自身文档开始，让运行行匹配当前限制。