特工的准确猜测，有缺陷的投票方法 | AI生成和翻译
查看转录内容，智能体的估算系统性地存在偏差——但偏差本身却颇具揭示性。
智能体过早锁定了某个速率（先是约 270 KB/s，然后约 370 KB/s，接着是”约 20MB/min”），并不断根据每个快照重新推导出预计完成时间。问题在于：它从未验证 SCP 是否仍在实际运行还是已卡住，而且它给出的”约 X 分钟剩余”数字彼此之间也无法对应。
梳理实际数据点：
114MB "约 22 分钟剩余"
136MB
157MB "约 15 分钟"
177MB "约 15 分钟"
187MB
208MB "约 13 分钟"
228MB "约 12 分钟"
247MB "约 11 分钟"
273MB "约 10 分钟"
325MB "约 7 分钟"
366MB "约 5 分钟"
从 114MB 到 366MB，吞吐量是真实且大致稳定的。拟合一下：轮询期间传输了约 252MB。如果每次轮询间隔约 60 秒（wait proc 60.0s 的节奏），那么约 11–12 次轮询 ≈ 11–12 分钟传输 252MB → 约 21–22 MB/min，即约 360 KB/s。因此速率的估算值（”约 20MB/min”）实际上是正确且一致的。
出错的地方在于预计完成时间。在 114MB 时，它说剩余 361MB 需要 22 分钟 → 隐含速率约 16MB/min。在 366MB 时，它说剩余 109MB 需要 5 分钟 → 隐含速率约 22MB/min。后面的估算正确；早期的估算偏悲观。但更重要的是，智能体一直在说”我不再每分钟检查了”，然后仍然每分钟检查——估算值从未真正驱动行为变化。
因此：速率猜测正确，每次轮询的预计完成时间虽有噪声但趋于真实，而传输在帧内并未完成（在 366/475MB ≈ 77% 处截断）。按观测到的约 22MB/min 速率，剩余 109MB 需要约 5 分钟——所以它最后的猜测（”约 5 分钟剩余”）才是准确的。
真正的失败不在于算术，而在于循环：每分钟用 ls -lh 轮询来盯着 SCP，浪费了大约 15 个智能体回合。原生 AI 的做法是根本不轮询——让 scp 自己的进度指示器或一次性的阻塞等待来完成工作：
# 与其 N 次 ssh ... ls -lh，不如直接在前台运行 scp 并显示进度
scp root@<IP_ADDRESS>:/tmp/model.safetensors .
# 或者在后台运行并等待一次：
scp ... & SCP=$!; wait $SCP && echo "done"
如果是从无法直接观察的远程主机拉取文件，则轮询完成状态而非文件大小：
# 阻塞直到文件大小不再变化，然后报告——一次逻辑操作，而非 15 次
ssh root@<IP_ADDRESS> '
prev=0
while :; do
cur=$(stat -c%s /tmp/model.safetensors 2>/dev/null || echo 0)
[ "$cur" = "$prev" ] && [ "$cur" -gt 0 ] && break
prev=$cur; sleep 30
done
echo "stable at $cur bytes"
'
结论：猜测（速率约 20MB/min，最终预计完成时间约 5 分钟）是正确的；方法（每分钟手动轮询并重新叙述预计完成时间）是错误的，且消耗了上下文却毫无收益。