一个被忽视的问题：harness 到底能不能替模型扛事
搞智能体的人近几个月都在纠结同一件事：到底是 harness（那套提示、工具、检查的外壳）在决定能力，还是底模自己在决定。Stanford 这篇 arXiv 2610.11655 给了到目前为止最可操作的答案。它的办法很朴素——把每一次失败运行，按最早出现的失败信号贴上标签，再分成两类：一类是过程失败，比如调用被拦、陷入无意义循环、步数预算耗尽；另一类是内容失败，也就是交付出来的方案本身就比较糟。结论也干脆：过程失败靠演化 harness 去修，内容失败只有训练权重才救得回来。
在 DeepPlanning 上，一套自演化的 harness 把 Qwen3.5-4B 的留出率从 0.16 抬到 0.30（交付率从 55% 到 90%），9B 从 0.32 到 0.44。但注意，无论 harness 怎么演化，那些交付了烂方案的运行占比几乎纹丝不动。真正把 9B 的内容失败从大约四分之一砍到二十分之一的，是拿演化后的 harness 运行轨迹去训一个 LoRA 适配器——而且这个 LoRA 单靠自己，就追平了整轮 harness 演化的成绩。换句话说，harness 把下限抬上去了，却碰不到内容质量的天花板。
读失败信号，再决定动哪根杠杆
这张图的价值不在某个百分比，而在它把工程直觉变成了可执行的分工。卡死、循环、预算耗尽，这些交给 harness 去调提示、补工具、加检查；方案本身就是歪的，别指望改外壳能救，老老实实回去训权重。在 WebArena-Lite 上，演化循环对 117 个未见任务只带来 0.09 的提升，而且增益几乎都活在模型看到的东西里，适配器那边加不上去——这又反过来提醒，换环境时，harness 和权重各自的边界在哪，得重新量。
对做 Agent 框架的团队，这篇等于给了一把尺子：先别急着堆更复杂的 harness，先把失败分分类。很多团队把大量精力花在调提示和加护栏上，确实能解决卡死和循环，但如果是模型本身想不出好方案，那部分投入基本是打水漂。该把资源挪到数据、轨迹和微调上，而不是无限加戏给外壳。harness 很重要，但它有自己的天花板，认清这根线，比盲目相信「调一调外壳就能更强」要实在得多。