Yossi Eliaz 5 月 5 日发了一个基于 Islo 沙箱原语的 meta-harness POC。
规模很小：约 200 行 bash orchestrator，MIT licensed，跑的是离线 deterministic simulator。任务也很小：FizzBuzz、primes、list reverse、sum-of-evens、palindrome check 五个玩具任务。
结果路径是 0/5 → 2/5 → 3/5 → 4/5 → 5/5。4 次 proposer step 收敛，低于 10 次迭代上限。
这事有意思的地方，不是“200 行脚本让 agent 变强”。更准确地说，它把一个老问题摆到了台面上：自动改进 LLM agent harness，最缺的可能不是再写一个评分器，而是能复现失败现场、能并行复制任务、能长期保存运行轨迹的底座。
meta-harness 真正在修什么
meta-harness 想做的事，是让 proposer 根据运行结果改 harness。这里的 harness 可以理解为围绕 agent 的提示词、工具调用方式、评测脚本和运行约束。
问题在于，很多 eval 系统给 proposer 的信息太薄。只看 pass rate、平均分，或者几行失败摘要，适合做排行榜；要让系统自己修自己，就不够用了。
proposer 需要看到更完整的东西：stdout、stderr、grader 反馈、每个任务的失败路径，以及不同任务之间是否有同一种失败模式。
这个差别很像看病。只看体温，能知道病人不舒服；要开药，还得看症状、检查结果和病程记录。meta-harness 也是这个逻辑。
对 LLM agent/eval 基础设施团队来说，动作会更具体：如果现在只存最终分数和少量失败文本，就很难支撑自动提示词优化或工具链优化。更现实的投入顺序，是先把运行轨迹、失败样本和可复现环境管起来，再谈更聪明的 proposer。
Islo 补的是执行现场，不只是观测面板
这个 POC 把 Islo 的几个原语用得很直白。它不是在展示复杂算法，而是在展示一条 eval loop 怎么落到工程对象上。
| Islo 原语 | POC 里的作用 | 对 meta-harness 的意义 |
|---|---|---|
snapshot save | 保存基准环境 | 候选 harness 可以在同一环境复跑，减少环境噪声 |
use --snapshot | 为候选和任务 fork sandbox | 支撑 candidate × task 的并行评测 |
logs | 保存运行轨迹 | proposer 能读取持久诊断上下文 |
这里要和常见 tracing 工具做一个区分。LangSmith、Weights & Biases Traces 这类工具更偏观测和分析；Islo 在这个 POC 里强调的是“执行现场”本身。
环境能冻结，任务能复制，日志能留下来。对 agent eval 来说，这三件事比一个漂亮面板更接近底层矛盾。
因为 agent 失败常常不是单点失败。可能是 prompt 少了一句边界条件，可能是工具调用顺序错了，也可能是 grader 反馈没有被正确吸收。没有可复现场，后面所有自动改进都容易变成猜。
这也是我更在意的地方：meta-harness 的关键资产不是某次分数，而是每次失败留下来的上下文。没有留痕，就没有复盘；没有复盘，就谈不上稳定迭代。
5/5 有价值，但边界要守住
这次从 0/5 到 5/5，是在确定性玩具任务套件里发生的。这个结论不能外推到 SWE-bench，也不能写成生产 agent 性能提升。
proposer 也不是一个真实 LLM。它是约 80 行 pattern-matching 脚本：读取 runs/iter-N/，找失败任务，再把对应 hint 追加到下一版 system.md。
最值得看的细节，是第一次提升。针对 fizzbuzz 的 hint 写了 “count from 1 through N inclusive”。这里的 “inclusive” 顺带修好了 sum-of-evens。
这个小例子说明，跨 trace 诊断可能有转移收益。一个任务里的失败提示，可能修掉另一个任务里的边界错误。
但要克制。它目前只能说明：在这个 simulator、这组任务、这个 proposer 规则下，完整轨迹确实帮上了忙。它不构成“无回归”保证，也不构成“单调提升”保证。
更不能把它读成 Islo 已经证明能处理 10M token 上下文。原文能支撑的说法更窄：meta-harness 需要大量诊断上下文，而这个 POC 展示了日志供给路径。
对工程团队来说，这里有一个很实际的取舍：
| 路线 | 现在能得到什么 | 主要风险 |
|---|---|---|
| 继续堆 leaderboard 和汇总分 | 更容易比较模型或版本 | 很难解释失败，也很难自动修 harness |
| 先建设 sandbox、snapshot、logs | 更容易复现失败并喂给 proposer | 短期跑分不一定好看，工程成本更前置 |
| 直接押真实后端和长任务 | 更接近生产问题 | 成本、延迟、稳定性目前没有由这个 POC 验证 |
如果你在做 agent/eval 平台，比较稳的动作不是马上迁移全部评测，而是挑一小组失败率高、复现成本高的任务，把日志契约和 snapshot 流程先跑通。
如果你在做自动 prompt 或工具链优化，也不该只问“proposer 多聪明”。更该问三件事：失败现场能不能复现，轨迹能不能完整读取，候选 harness 能不能并行对照。
接下来要看的变量很清楚。
一是 simulator 换成真实 Claude/Islo backend 后，成本、延迟和稳定性是否还能接受。原文提到这是下一步，不是已经验证的结果。
二是 Harbor 或 long-horizon workload 接入后，runs/ 里的日志结构还能不能支撑诊断。长任务的失败噪声会更大，单靠几条 hint 未必够。
三是真实 proposer 读完整轨迹后，改动会停留在 prompt hint，还是能提出工具、grader、任务拆分层面的修改。后者才更接近 meta-harness 的工程价值。
回到开头那个 5/5。它当然小，小到不能拿来讲能力跃迁。但它把一件事说得很清楚：自动改进要先有可复现的现场。皮之不存，毛将焉附。