企业官网建设流程全解析

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 八个环境上 Pass@1 比最强基线高 +10.07 / +9.91 pp，而且工具与基础上下文冻结，只让程序性知识长。

所以结论不是「harness 要死了」，而是harness 的重心在迁移：从「补偿模型短板」转向「承载业务约束 + 累积程序性知识」。

我的判断

模型越强，harness 越该「瘦」，这是对的——但瘦的是补偿层，不是约束层。我赌接下来 12 个月，行业会从「给 agent 加更多脚手架」卷成「精准移除过期脚手架」。这话可以证伪：要是 2027 年主流 agent 框架的默认模板反而比今天更厚，说明我错了——那只有一种可能，长程任务的可靠边界扩张速度，跟不上任务复杂度涨的速度。

小结

• 吃了的是补偿层：verifier / reflection / sprint 分解，本质是补「模型假装干完」的窟窿，模型变诚实它们就贬值。
• 吃不动的是约束层：constraint + verification 编码你的业务，永远是你自己的，模型发布吸收不了。
• 动手做一件事：翻你现在的 harness，把每个组件标成「补模型短板」还是「载业务约束」，前者逐个移除做 A/B，别一把梭。

写在最后

说实话，写完这篇我自己也去翻了下项目里的 agent 配置——那堆 reflection prompt 是不是也该瘦一瘦了。你要是也在维护一套 harness，今晚不妨干同一件事：别问「还能加什么」，改问「哪个假设已经过期了」。聊完了，去试试？

来源区

1. ZOOZ Engineering —Opus 4.8 is eating our agent harness：https://engineering.zooz.com/@arunsr1ni_arch/opus-4-8-is-eating-our-agent-harness-and-thats-mostly-good-2e8052a91a73
2. Anthropic 工程博客 —Harness design for long-running application development：https://www.anthropic.com/engineering/harness-design-long-running-apps
3. Living-Harness（arXiv 2607.26598，浙大+阿里）：https://arxiv.org/abs/2607.26598v2
4. 鉅亨号 —Anthropic Harness: AI Agent 從野馬到戰車（中文）：https://hao.cnyes.com/post/241855
5. 虎嗅 —阿里千问正式开源 Qwen3.8 系列模型（中文一手）：https://www.huxiu.com/ainews/14605.html
6. 掘金 —鲫鱼科技周报 2026-08-07 GitHub 趋势周榜（中文一手）：https://juejin.cn/post/7670593377076084787
7. obra/superpowers（GitHub Trending 顶流）：https://github.com/obra/superpowers