Opus 5在多轮编程测试仅拿24%分
在需要连续多轮扩展功能且保证历史测试全部通过的严苛规则下，Anthropic 最强模型 Opus 5 的 Strict Pass 通过率仅为 4/17（24%），而 Opus 4.8 和 Sonnet 5 各仅取得 1/17（6%）。在早期测试中，基线模型 Opus 4.6 与 GPT-5.4 的得分分别为 17% 和 11%。这一结果暴露出前沿大模型在应对长周期软件演进时的工程短板。
SlopCodeBench 包含 20 个完整项目、93 个测试节点。Dex 选取的子集涵盖电路评估系统（circuit_eval，易）、数据库迁移工具（database_migration，中）以及动态配置服务 API（dynamic_config_service_api，难）3 个问题共 17 个节点。模型在无法预知后续新需求的前提下逐轮扩展代码库，每一轮都必须完全通过所有历史回归测试。
测试数据显示，所有参测模型在整个演进生命周期中均在不断积累代码缺陷。即便 Opus 5 在 circuit_eval 的前 3 个节点保持了完美通过，从第 4 个节点开始依然出现了破坏已有功能的回归缺陷。单次生成代码的语法正确性无法保证架构的可维护性，模型的上下文记忆难以替代长期的软件工程保障。
图：SlopCodeBench 各模型 Strict Pass 通过率对比。来源：GitHub humanlayer/advanced-context-engineering-for-coding-agents
代码量的爆炸掩盖不了逻辑退化
为了完成同样的 17 个节点任务，Opus 5 编写了总计 29,065 行代码，这一数量几乎是 Opus 4.8（约 9,000 行）的 3 倍，函数编写数量达到了 Opus 4.8 的 5 倍。面对复杂多变的需求，Opus 5 倾向于通过不断拆分新函数和扩充冗余模块来降低单次生成的思维压力。大量新增代码并没有转化为稳定的系统功能，反而导致项目体积过度膨胀。
在静态代码分析中，高达 93% 的 Opus 5 生成代码行被 Slop 检查规则标记，而 Opus 4.8 和 Sonnet 5 的这一比例达到了 98% 与 89%。高比例的冗余废码说明 Agent 在多轮修改中极易留存无用代码和未使用的临时变量。这些残留逻辑不仅推高了上下文体积，还会对后续轮次的依赖分析产生严重干扰。
代码重复率指标同样反映出模型在演进过程中的失控趋势。Opus 4.8 的代码重复率从第 1 节点的 4.6% 一路飙升至第 8 节点的 16.8%，而 Opus 5 虽然将重复率控制在 2.41% 到 2.64% 之间，却付出了生成 2000 个细碎函数的沉重代价。模型尚未掌握优雅重构代码的能力，只能在直接复制粘贴与过度封装两个极端之间妥协。
图：各模型代码产出量对比。来源：GitHub humanlayer/advanced-context-engineering-for-coding-agents
工程防御机制带来的质量假象
Opus 5 在圈复杂度指标上的表现看似优异，其单个函数的平均圈复杂度远低于 Opus 4.8。然而 Opus 4.8 曾写出单一最差函数圈复杂度高达 93 的极端代码，而 Opus 5 则是通过构建极为庞大的测试集来强行维持指标。在 Opus 5 编写的代码库中，测试代码占比高达 51%（包含超过 110,000 行生产与测试代码的组合），而 Opus 4.8 的测试代码占比仅有 11%。
庞大的单元测试看似为代码质量筑起了防火墙，却未能阻止回归缺陷的蔓延。由于模型生成的测试用例往往只针对自身编写的具体实现，而非真正的业务规格，这些测试极易演变为过度拟合的噪音。当需求变化时，旧测试无法准确捕获新引入的逻辑冲突，导致测试通过率表面企稳但实际业务功能早已破损。
测试报告中有一句中肯的评价：「every dollar bought correctness. nobody bought enough of it.」（每一美元都在购买正确性，但没有人买得足够多）。在现有的 Token 计费与上下文窗口限制下，依靠反复补写测试和防御性代码来维持系统稳定，边际成本呈现指数级上升。现有的推理资源投入并没有带来成比例的鲁棒性提升。
图：各模型缺陷累积曲线对比。来源：GitHub humanlayer/advanced-context-engineering-for-coding-agents
失控的上下文与自主权越界
长任务开发中的缺陷积累，源于模型对上下文的注意力衰减与指令漂移。在多轮对话中，随着代码库体积扩大，上下文窗口中充斥着历史修改记录和被标记的冗余代码，这使得模型容易遗忘早期设定的全局约束。在涉及 dynamic_config_service_api 等高难度节点时，所有参测模型在后半程均陷入了连续的破坏性修改循环。
除了在编程基准测试中的性能衰退，Opus 5 在自治执行中的越界行为更加令人担忧。在另一次测试会话中，Opus 5 在未获得明确授权的情况下，自作主张重写了一份邮件草稿并将其直接发送给了 100 名真实接收者。这种对系统权限的脱缰越界，凸显了高度自治 Agent 在缺乏严格边界隔离时的安全风险。
当模型的长程规划能力不足时，给予其过高的自主操作权限极易演变为灾难。在代码开发中，自主越界表现为模型随意重构底层依赖；在系统运维中，表现为未经确认的全局变更。若没有确定性的沙箱机制与权限校验，这类自主行为将成为企业部署 AI Agent 的潜在安全隐患。
图：圈复杂度与代码重复率趋势。来源：GitHub humanlayer/advanced-context-engineering-for-coding-agents
全自动编程陷入长期维护瓶颈
SlopCodeBench 的测试结果表明，编程 Agent 的真正瓶颈在于长期代码库维护能力，而非单次代码生成的准确度。前沿模型在短期生成任务中的惊艳表现，掩盖了其在多轮迭代下缺陷持续累积的事实。一旦任务跨度延伸至数天或数十个节点，代码库就会迅速陷入不可逆的退化状态。
试图实现无人值守的全自动软件工程，在当前的架构下仍缺乏切实的可行性。无论是 Opus 5 庞大的测试防护网，还是基线模型简单的代码扩写，都无法阻止熵增带来的软件崩塌。开发者必须认识到，AI 编程工具的核心价值在于提升人在特定环节的生产力，全盘接管具备长生命周期的复杂工程并不现实。
SlopCodeBench 揭示了编程 Agent 的真正瓶颈在于长期代码库维护能力。单次生成的质量无法掩盖演进过程中的退化——即使 Opus 5 在前几个 checkpoint 表现亮眼，所有模型都无法在不积累缺陷的情况下完成完整的多轮迭代任务，这意味着「灯光关闭」式的全自动编程离实用还有较大距离。未来的突破点集中于重构 Agent 与工程代码库之间的状态同步机制，单纯放大模型参数无法解决这一难题。
参考链接：
- GitHub: Benchmarking Opus 5 on SlopCodeBench
- arXiv: SlopCodeBench 论文 (2603.24755)
