Opus 4.8 把脚手架吃了模型越诚实围着它的补偿性脚手架越多余钩子上周我让某个 coding agent 写个小工具它拍胸脯说「搞定了」。我一跑——空文件。这种「假装干完了」的翻车你肯定也遇过。很多人觉得是模型笨。其实不是。是 harness 里那一整套 verifier、reflection、post-hoc QA 子 agent全在替模型补一个窟窿它太爱提前交差。现在 Opus 4.8 把这个窟窿自己填上了——自己代码里的 bug 漏过去不吱声的概率比 4.7 低了约 4 倍。脚手架这一下就显得有点多余了。一、先认清楚你那套 harness 到底是干嘛的好多人把 harness 想成「让 agent 更强」的魔法层。说白了它就是围着模型搭的一圈脚手架工具、上下文、记忆、工作流、评测接口。模型在中间推理harness 决定活怎么分、上下文怎么带、跨会话怎么续。有个扎心的事实——Anthropic 自己那篇 long-running harness 工程博客写得很直白harness 的每个组件都编码了一个「模型自己做不到」的假设。这些假设值得你一个个去压。因为模型一升级它们就可能直接失效。图里标红的那层Scaffolding就是被吃的主角。绿的两层吃不动——它们编码的是你的业务不是模型的短板。二、Opus 4.8 吃掉了哪一层ZOOZ 那篇「Opus 4.8 is eating our agent harness」把账算得很清楚。生产级 agent 系统之所以复杂根子几乎都同一个失败模式模型提前宣布任务完成。verifier 子 agent、reflection pass、confidence prompt、post-hoc QA——全是在补偿这个「假装干完」的毛病。Opus 4.8 干了件安静但要命的事它自己承认不确定、主动 flag 自己输出里的问题的概率大幅上升。内部评测里「无脑报告错误结果」归零首个做到的 Claude对自家代码 bug 漏报的概率比 4.7 低约 4 倍。这五类全是「模型不够诚实」这个假设下的产物。假设松了这棵树的叶子就枯了。注意一个细节Opus 4.8 的 Dynamic Workflows 能 fan-out 上百个子 agent 做大规模迁移——但它 eat 的是通用层不是你的业务约束层。三、不是 Anthropic 一家在减脚手架把时间线拉直了看这其实是 Opus 一条清晰的演化主线不是 4.8 突然抽风。鉅亨号那篇把这套演化讲得很透Opus 4.6 时期因为模型原生规划力够了sprint 分解脚手架直接被拿掉evaluator 从「每 sprint 都打分」退化成「只有任务超出模型可靠边界时才值得开」。4.8 只是把这件事推到极致——连 verifier 的「常开」都变「按需」。四、模型自己怎么把 verifier 干掉的看一次具体任务的执行链路就懂了。老范式里generator 产出 → evaluator 像 GAN 的判别器一样挑刺 → 打回去改。Opus 4.8 之后generator 自己就会在产出前 flag 问题evaluator 的「常驻复查」多数时候是空转。关键变化左边那条G-G的自检是 4.8 新长的「肌肉」。它把 evaluator 从「每单必查」降级成「兜底才查」。五、但别高兴太早有两层它永远吃不动这里我得泼盆冷水。ZOOZ 文章自己也画了张分层图——平台 eat 的是通用层而五层模型里有两层永远是你自己的constraint你的任务、工具、护栏和 verification你的验收标准、你对「正确」的定义。没有任何模型发布能吸收这两层因为它们编码的是你的业务不是 Anthropic 的。Living-Harness 这篇 arXiv浙大阿里正好补上这个视角它把每次执行轨迹 评测信号转成可跨周期累积的程序性修复episodic memory 记触发条件/失败模式/恢复动作 state graph 记修复边。在 τ²-Bench / MultiWOZ-2.4 八个环境上 Pass1 比最强基线高 10.07 / 9.91 pp而且工具与基础上下文冻结只让程序性知识长。所以结论不是「harness 要死了」而是harness 的重心在迁移从「补偿模型短板」转向「承载业务约束 累积程序性知识」。我的判断模型越强harness 越该「瘦」这是对的——但瘦的是补偿层不是约束层。我赌接下来 12 个月行业会从「给 agent 加更多脚手架」卷成「精准移除过期脚手架」。这话可以证伪要是 2027 年主流 agent 框架的默认模板反而比今天更厚说明我错了——那只有一种可能长程任务的可靠边界扩张速度跟不上任务复杂度涨的速度。小结吃了的是补偿层verifier / reflection / sprint 分解本质是补「模型假装干完」的窟窿模型变诚实它们就贬值。吃不动的是约束层constraint verification 编码你的业务永远是你自己的模型发布吸收不了。动手做一件事翻你现在的 harness把每个组件标成「补模型短板」还是「载业务约束」前者逐个移除做 A/B别一把梭。写在最后说实话写完这篇我自己也去翻了下项目里的 agent 配置——那堆 reflection prompt 是不是也该瘦一瘦了。你要是也在维护一套 harness今晚不妨干同一件事别问「还能加什么」改问「哪个假设已经过期了」。聊完了去试试来源区ZOOZ Engineering —Opus 4.8 is eating our agent harnesshttps://engineering.zooz.com/arunsr1ni_arch/opus-4-8-is-eating-our-agent-harness-and-thats-mostly-good-2e8052a91a73Anthropic 工程博客 —Harness design for long-running application developmenthttps://www.anthropic.com/engineering/harness-design-long-running-appsLiving-HarnessarXiv 2607.26598浙大阿里https://arxiv.org/abs/2607.26598v2鉅亨号 —Anthropic Harness: AI Agent 從野馬到戰車中文https://hao.cnyes.com/post/241855虎嗅 —阿里千问正式开源 Qwen3.8 系列模型中文一手https://www.huxiu.com/ainews/14605.html掘金 —鲫鱼科技周报 2026-08-07 GitHub 趋势周榜中文一手https://juejin.cn/post/7670593377076084787obra/superpowersGitHub Trending 顶流https://github.com/obra/superpowers
Opus 4.8 把脚手架吃了
Opus 4.8 把脚手架吃了模型越诚实围着它的补偿性脚手架越多余钩子上周我让某个 coding agent 写个小工具它拍胸脯说「搞定了」。我一跑——空文件。这种「假装干完了」的翻车你肯定也遇过。很多人觉得是模型笨。其实不是。是 harness 里那一整套 verifier、reflection、post-hoc QA 子 agent全在替模型补一个窟窿它太爱提前交差。现在 Opus 4.8 把这个窟窿自己填上了——自己代码里的 bug 漏过去不吱声的概率比 4.7 低了约 4 倍。脚手架这一下就显得有点多余了。一、先认清楚你那套 harness 到底是干嘛的好多人把 harness 想成「让 agent 更强」的魔法层。说白了它就是围着模型搭的一圈脚手架工具、上下文、记忆、工作流、评测接口。模型在中间推理harness 决定活怎么分、上下文怎么带、跨会话怎么续。有个扎心的事实——Anthropic 自己那篇 long-running harness 工程博客写得很直白harness 的每个组件都编码了一个「模型自己做不到」的假设。这些假设值得你一个个去压。因为模型一升级它们就可能直接失效。图里标红的那层Scaffolding就是被吃的主角。绿的两层吃不动——它们编码的是你的业务不是模型的短板。二、Opus 4.8 吃掉了哪一层ZOOZ 那篇「Opus 4.8 is eating our agent harness」把账算得很清楚。生产级 agent 系统之所以复杂根子几乎都同一个失败模式模型提前宣布任务完成。verifier 子 agent、reflection pass、confidence prompt、post-hoc QA——全是在补偿这个「假装干完」的毛病。Opus 4.8 干了件安静但要命的事它自己承认不确定、主动 flag 自己输出里的问题的概率大幅上升。内部评测里「无脑报告错误结果」归零首个做到的 Claude对自家代码 bug 漏报的概率比 4.7 低约 4 倍。这五类全是「模型不够诚实」这个假设下的产物。假设松了这棵树的叶子就枯了。注意一个细节Opus 4.8 的 Dynamic Workflows 能 fan-out 上百个子 agent 做大规模迁移——但它 eat 的是通用层不是你的业务约束层。三、不是 Anthropic 一家在减脚手架把时间线拉直了看这其实是 Opus 一条清晰的演化主线不是 4.8 突然抽风。鉅亨号那篇把这套演化讲得很透Opus 4.6 时期因为模型原生规划力够了sprint 分解脚手架直接被拿掉evaluator 从「每 sprint 都打分」退化成「只有任务超出模型可靠边界时才值得开」。4.8 只是把这件事推到极致——连 verifier 的「常开」都变「按需」。四、模型自己怎么把 verifier 干掉的看一次具体任务的执行链路就懂了。老范式里generator 产出 → evaluator 像 GAN 的判别器一样挑刺 → 打回去改。Opus 4.8 之后generator 自己就会在产出前 flag 问题evaluator 的「常驻复查」多数时候是空转。关键变化左边那条G-G的自检是 4.8 新长的「肌肉」。它把 evaluator 从「每单必查」降级成「兜底才查」。五、但别高兴太早有两层它永远吃不动这里我得泼盆冷水。ZOOZ 文章自己也画了张分层图——平台 eat 的是通用层而五层模型里有两层永远是你自己的constraint你的任务、工具、护栏和 verification你的验收标准、你对「正确」的定义。没有任何模型发布能吸收这两层因为它们编码的是你的业务不是 Anthropic 的。Living-Harness 这篇 arXiv浙大阿里正好补上这个视角它把每次执行轨迹 评测信号转成可跨周期累积的程序性修复episodic memory 记触发条件/失败模式/恢复动作 state graph 记修复边。在 τ²-Bench / MultiWOZ-2.4 八个环境上 Pass1 比最强基线高 10.07 / 9.91 pp而且工具与基础上下文冻结只让程序性知识长。所以结论不是「harness 要死了」而是harness 的重心在迁移从「补偿模型短板」转向「承载业务约束 累积程序性知识」。我的判断模型越强harness 越该「瘦」这是对的——但瘦的是补偿层不是约束层。我赌接下来 12 个月行业会从「给 agent 加更多脚手架」卷成「精准移除过期脚手架」。这话可以证伪要是 2027 年主流 agent 框架的默认模板反而比今天更厚说明我错了——那只有一种可能长程任务的可靠边界扩张速度跟不上任务复杂度涨的速度。小结吃了的是补偿层verifier / reflection / sprint 分解本质是补「模型假装干完」的窟窿模型变诚实它们就贬值。吃不动的是约束层constraint verification 编码你的业务永远是你自己的模型发布吸收不了。动手做一件事翻你现在的 harness把每个组件标成「补模型短板」还是「载业务约束」前者逐个移除做 A/B别一把梭。写在最后说实话写完这篇我自己也去翻了下项目里的 agent 配置——那堆 reflection prompt 是不是也该瘦一瘦了。你要是也在维护一套 harness今晚不妨干同一件事别问「还能加什么」改问「哪个假设已经过期了」。聊完了去试试来源区ZOOZ Engineering —Opus 4.8 is eating our agent harnesshttps://engineering.zooz.com/arunsr1ni_arch/opus-4-8-is-eating-our-agent-harness-and-thats-mostly-good-2e8052a91a73Anthropic 工程博客 —Harness design for long-running application developmenthttps://www.anthropic.com/engineering/harness-design-long-running-appsLiving-HarnessarXiv 2607.26598浙大阿里https://arxiv.org/abs/2607.26598v2鉅亨号 —Anthropic Harness: AI Agent 從野馬到戰車中文https://hao.cnyes.com/post/241855虎嗅 —阿里千问正式开源 Qwen3.8 系列模型中文一手https://www.huxiu.com/ainews/14605.html掘金 —鲫鱼科技周报 2026-08-07 GitHub 趋势周榜中文一手https://juejin.cn/post/7670593377076084787obra/superpowersGitHub Trending 顶流https://github.com/obra/superpowers
