Opus 5 写长期项目严格通过率只有 24%：Agent 最难的是别把代码越改越乱
作者：林岚｜OC 开发者生态编辑
林岚
据 HumanLayer 的测试记录 和 SlopCodeBench 论文 显示，Claude Opus 5 在一组长期迭代编程任务中，严格通过率只有 24%。测试同时观察到代码规模、复杂度和重复逻辑随需求轮次增长。
一句话结论：编程 Agent 会完成下一项需求，不代表它能维护一个持续变化的项目；长期质量正在成为比单次通过率更难的考题。
传统代码基准通常给模型一个完整任务，然后检查测试是否通过。SlopCodeBench 故意换了一种方式：先给出初始需求，再分阶段加入新约束。模型必须在自己此前写下的代码上继续工作，既不能破坏旧功能，也要为下一次变化保留结构。
这更像真实维护，而不是算法考试。开发者经常面对“增加一个选项”“支持另一种后端”“现在还要兼容旧格式”这类需求。一次次局部补丁都可能通过当下测试，却让条件分支、重复实现和隐式状态不断堆积。
24% 需要带着限定条件阅读。HumanLayer 对 Opus 5 的测试规模有限，所用 Agent、提示词、工具权限和严格评分规则都会影响结果。它不能证明 Opus 5 在日常编程中只有四分之一任务可用，也不能直接与厂商公布的单轮 SWE 基准比较。
但它指出了一个经常被掩盖的问题：功能测试只检查“现在能不能跑”，不会自动检查架构是否正在腐烂。Agent 特别擅长在现有结构上增加一层兼容代码，因为这通常是最短的局部路径。多轮以后，每一轮都正确，整体仍可能变得难以理解。
问题不在于再给 Agent 写一页“保持代码整洁”的规则。更有效的做法是把复杂度预算、重复检测、模块边界和回归测试变成机器可检查的约束，并在需求之间安排重构阶段。否则，Agent 提高的是功能交付速度，技术债也会以相同速度增长。
关键事实
- 来源：HumanLayer 测试记录、SlopCodeBench 论文与数据集
- 涉及项目：Claude Opus 5、SlopCodeBench
- 核心技术：长周期代码基准、分阶段需求、静态质量指标
- 关键数字：小规模测试严格通过率 24%；基准论文包含 20 个问题和 93 个检查点
OC 判断
24% 不是模型能力总分，但这个基准问对了问题。生产代码的价值不是某一轮测试变绿，而是下一位开发者还能安全修改。编程 Agent 的下一阶段竞争，会从“写得快”转向“在第十次改动后仍能解释和收敛复杂度”。
为什么重要
- 对开发者：验收 Agent 代码时，需要同时看回归测试、复杂度、重复和架构边界。
- 对企业：用一次性 benchmark 估算长期维护收益，会系统性高估节省的人力。
- 对用户：代码快速上线并不代表后续更新更稳定，隐藏技术债最终会表现为故障和安全问题。
评论
围绕这篇文章补充信息、提出问题或分享观察。