玩转Harness后，我终于知道哪些是必须，哪里会翻车，加什么能救命了！

随着大模型能力的持续提升，业界一个共识逐渐形成：模型越强，所需的Harness（脚手架）就越少。Claude Code之父Boris在近期的演讲中提到，一年后Claude Code可能只需100行代码。OpenAI也明确表示：「Scaffolding is coping, not scaling」。然而，现实情况是模型种类繁多——不同尺寸（flash、pro）、不同推理深度（thinking low、high）对Harness的需求截然不同。本文通过一系列实验，帮你找到答案：哪些Harness是必须的？拿掉什么会翻车？加什么能救命？

简单任务：小模型足以胜任

实验选取了阶跃星辰的Step Plan系列模型进行测试，包括step-3.5-flash（196B MoE）、step-3.5-flash-2603（Agent场景强化版）和step-router-v1（动态路由模型）。测试任务分为三个梯度：简单修bug、中等加功能写测试、最难的us-003（从零实现多范围解析器，12条验收标准）。

复杂任务：两个护栏就够

简单和中等难度的任务测试结果不出意料：两个模型全部通过。令人惊喜的是，step-3.5-flash反而是最快的，仅用30次工具调用、48秒就完成了中等任务。这验证了Boris的观点：在很多场景下，你可能不需要复杂的Harness，小尺寸的worker模型照样可以完成得很好，速度更快、更便宜。复杂规划任务交给大尺寸模型就可以了。

us-003测试结果最有意思。step-3.5-flash裸跑时完全停不下来，做了267次工具调用。它其实写对了代码，但不知道自己写对了——写完后继续改，又改出新bug，循环往复直到超时。解决方案出奇简单：添加两个护栏即可。第一，给工具调用设置上限（80次）；第二，添加auto-resume commit，在worker被kill前自动执行git commit防止代码丢失。添加这两个护栏后，step-3.5-flash在151秒内成功通过us-003。

实验还发现一个反直觉的现象：经过Agent优化的step-3.5-flash-2603在复杂任务上反而失败了。原因在于它表现过于谨慎——每改一点代码就跑一次测试。在复杂任务上，这种每步验证很快就把工具调用额度用完了。这印证了OpenAI的观点，但方向相反：内化过多scaffolding行为，在有限budget下反而丧失效率。

深度思考模式的陷阱

更令人惊讶的是，在低推理模式下，step-3.5-flash-2603全场最快，一轮通过。低推理模式下模型每次输出更短、更聚焦，不花token犹豫。而好的feedback替代了内部推理——代码有bug时不需要模型自己推理出问题在哪，Harness直接告诉它。这说明：Harness不是模型的拐杖，而是模型的杠杆。

如有侵权，请联系删除。