Claude Code 之父 Boris 在红杉 2026 AI Ascent 上说：一年后，Claude Code 可能只剩 100 行代码。模型足够聪明时，你不需要那么多脚手架。OpenAI 前不久的博客也说过："Scaffolding is coping, not scaling."

一个很明显的共识是：随着模型变强，Harness 会持续缩小。但是，模型种类太多了，不同尺寸 flash、pro；不同推理深度 thinking low、high... 对 Harness 的需求绝对是不同的。

本文通过实验来回答：这么多模型，到底哪些 harness 是必需的？拿掉什么会翻车？加什么能救命？

实验准备

使用阶跃星辰的 Step Plan 订阅进行实验。该订阅包含多种文本模型：step-3.5-flash（196B MoE，11B 激活，高速推理）、step-3.5-flash-2603（基于 flash 做了 agent 场景强化）、step-router-v1（自动在 deepseek-v4-pro 和 step-3.5-flash 之间路由）。不同尺寸，有 agent 特调版本，可以指定不同思考深度，非常适合做这个验证。

复用 hero-coding 开源 Go 框架（约 400 行代码），做了 Windows 适配，接入了 Step Plan。设计了 3 个梯度的任务：最简单的修一行 bug，中等的加功能写测试，最难的 us-003 是从零实现一个完整的多范围解析器，设置了很多条件，12 条验收标准。

简单和中等任务没什么好说的，两个模型全过。step-3.5-flash 反而是最快的，30 次工具调用 48 秒搞定中等任务。这其实非常符合 Boris 说的，在很多场景下，你可能不需要什么 harness 了。甚至小尺寸的 worker 模型照样可以完成得很好，速度更快，更便宜。只需要把复杂的规划任务交给大尺寸的模型就可以了。

复杂任务翻车实录

但 us-003 的结果就很有意思了。一开始用 step-3.5-flash 裸跑这个任务，没有任何 harness 的时候，flash 根本停不下来，它做了 267 次工具调用。Round 1 做了 91 次撞了 5 分钟条件限制，Round 2 做了 23 次自然停下来但代码编译不过，Round 3 又做了 153 次再次撞墙。三轮跑满，gave_up。

但其实有一个很讽刺的事情：flash 其实写对了代码。它把功能全实现了，测试也写了，代码逻辑是对的。但它不知道自己写对了。写完之后继续改，改出新 bug，又改，又出新 bug，循环往复直到超时。

第一个护栏：工具调用上限

所以第一个护栏特简单，给一个工具调用上限，80 次就够了。

第二个护栏：Auto-Rescue Commit

但是直接限制次数不够，因为架构设计。被 kill 的时候代码已经写好了，但没 commit。kill 之后工作区重置，代码还是丢了。所以还需要第二个东西：auto-rescue commit。在 worker 被 kill 之后，工作区重置之前，自动执行一次 git add -A && git commit。

就这 2 个护栏，加上之后，step-3.5-flash 就可以在 151s 内成功通过 us-003 了。

所以，harness 其实可能不会是什么高端、顶级的 trick 操作，只需要观察模型行为，补充一些让模型行为轨迹正确的操作就够了。

反面案例：过度优化的陷阱

但从上图可以看出来，step-3.5-flash-2603 在这个 case 上还是失败了，同样的 harness，但是输给了基础版本。

分析日志后发现：step-3.5-flash-2603 的 agent 优化，表现上会更谨慎，模型改了一些就跑一次测试。简单任务，这样可以更快确认。但是在复杂任务上，每步验证就把工具调用额度用完。

OpenAI 说「Scaffolding is coping, not scaling」，step-3.5-flash-2603 恰好反过来，它内化了太多 scaffolding 行为，在有限 budget 下反而丧失了效率。但其实它真正的原因是反馈失效了：原始的 hero-coding 框架，judge 提供给 worker 的反馈缺失了详细的完整验证堆栈信息。

就这么一行代码的修复，step-3.5-flash-2603 一轮就过了。这可能就是 harness 的魅力！

思考深度的选择

日常选择模型的时候，还会考虑用不用 thinking、用什么程度的 thinking。其实真的没必要什么都用最顶级、最大、最高推理的模型。同样用 us-003 测试了下，在 low 推理下，step-3.5-flash-2603 全场最快，一轮通过。

在低推理模式下模型每次输出更短、更聚焦，不花 token 犹豫。而好的 feedback 替代了内部推理，代码有 bug 时不需要模型自己推理出问题在哪，harness 直接告诉它。

苏米注：Harness 不是模型的拐杖，是模型的杠杆。

错误 Harness 的危险

但是 harness 不是随便抄过去都是有用的，错误的 harness 可能比没有 harness 更危险。

在 prompt 层面，给 step-3.5-flash-2603 加一个结构化 Planning Prompt，先读代码，写计划，再执行。结果，整个系统钻了个 judge 漏洞，没有做任何代码更新。

Cognition 的博客也谈过类似的话题：对于 Agent 壳子来说，最大的失败模式不是模型写错代码，而是系统层面的设计错误，给了不该给的约束，或者没给该给的信号。

Worker / Judge 分离：Smart Friend Routing

现在比较成熟的 Agent 架构，基本都可以收敛到一张图：有思考的脑子，有干活的手，持续的循环迭代。

所以，Agent 系统的脑子、手，完全可以用不同的模型。让 step-router-v1 负责思考统筹，step-3.5-flash-2603 做快速执行，结果是的，在前面最好的基础上，进一步取得了巨大的进步，只花了 step-3.5-flash-2603 一半的时间，就达标了。

更关键的是，除了耗时变成一半，token 消耗可能只有 1/3。Worker / Judge 用不同模型，在 Cognition 的博客里边称为 "smart friend routing"。

Scale AI 的数据说，harness 对 SWE-bench 分数贡献在 5-15 个百分点。而且这些百分点会越来越集中在"模型无法自己做到的事"，比如物理约束、确定性验证... 这可能才是 harness 今天爆火的主要原因。

总结

从测试来看，像 step-3.5-flash 这种 200B 左右的模型，完全可以扛住日常高频的 coding 任务，速度极快，30 次调用搞定别人 50+ 次的事。

实际体验下来，日常用 step-3.5-flash 做 worker，复杂规划交给 step-router-v1 动态路由到 deepseek-v4-pro，这种分工方式配上 harness，token 能省到很夸张。

Step Plan 文档：https://platform.stepfun.com/docs/zh/step-plan/overview

hero-coding 开源框架：约 400 行代码的 Go 框架