SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks¶

会议: NeurIPS 2026
arXiv: 2603.24755
OpenReview: https://openreview.net/forum?id=xxD8UZjGl8
代码: https://scbench.ai
领域: 代码智能
关键词: 代码智能, 智能体评测, 软件工程演化, 结构退化, 冗余代码

一句话总结¶

提出了包含 36 个长程演化任务与 196 个检查点的基准测试 SlopCodeBench，揭示了代码智能体在多轮自主迭代扩展自身代码时架构持续侵蚀且冗余膨胀的核心退化规律。

研究背景与动机¶

软件工程本质上是一个伴随需求变更不断演化的渐进过程，每一个早期架构决策都是在与未知的未来需求进行妥协与权衡。然而，现有的代码智能体基准测试（如 SWE-bench 等）大都采用单次交互（single-shot）评测范式，在完整的最终规格说明下测试模型一次性生成或修补代码的正确性，完全掩盖了由于不良设计决策引发的后续维护与扩展隐患。即使部分近期提出的多轮评测工作试图引入需求递进，也往往预先严格限制了内部模块接口，或者直接将单一方案机械拆解为有向无环子任务；而基于真实开源仓库演化历史的方法则将智能体置于人类构建好的成熟架构中，使其永远不必为自己前期的粗糙设计埋单。

这种评估机制的缺失导致业界无法对智能体生成代码的“质量退化”（code degradation）与“垃圾代码堆积”（slop）进行量化度量。在长程迭代编码中，智能体往往倾向于打局部补丁而非系统重构，反复使用冗余繁琐的语法结构、过度嵌套的条件分支，并将所有新功能粗暴堆砌在已有函数内。这类代码在功能测试集上可能侥幸通过当前检查点，但其内部架构已经严重退化并迅速丧失可维护性。为了真实复现这一失败模式，评测环境必须满足四个核心条件：智能体完全基于自身先前产出的代码库持续扩展；题目仅约束外部黑盒契约而开放内部架构选择；测试用例严格保密以防止逆向泄露设计线索；以及支持跨语言接口规范。

本文正是在这一背景下构想并设计了 SlopCodeBench。核心 idea：构建首个黑盒外部契约约束、完全由智能体自主决策内部架构并跨检查点迭代演化的基准测试 SlopCodeBench，并通过结构侵蚀度与冗余度两大轨迹级指标，系统量化代码智能体在长程扩展过程中的退化动力学。

方法详解¶

整体框架¶

SlopCodeBench 包含 36 个语言无关的人工精选软件开发问题，总计跨越 196 个检查点（Checkpoints）。在每个问题中，智能体面对的是一个逐步演化的需求序列 $[C_1, C_2, \dots, C_n]$。在初始检查点 $C_1$，智能体从空工作区 $y_0$ 开始，根据输入规格说明 $x_1$ 自行设计模块结构、数据流与命令行/服务契约，产出代码工作区 $y_1$；在后续的任意检查点 $C_i$，智能体仅接收当前增量需求 $x_i$ 以及自身在上一轮遗留的代码库 $y_{i-1}$，自主探索并修改自身代码得到 $y_i$。基准评测全程对智能体隐藏测试用例集与历史对话上下文，迫使智能体完全从代码库现状出发进行理解与重构，并对每一次提交独立计算功能正确性与两项轨迹级代码质量指标。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    A["初始需求规格 x1<br/>（空工作区 y0）"] --> B["黑盒契约约束规范<br/>CLI / API 外部边界声明"]
    B --> C["检查点迭代演化机制<br/>基于自身代码前向递推生成 yi"]
    C --> D["双维度代码质量量化<br/>结构侵蚀度 + 冗余度"]
    D -->|黑盒测试| E["分层测试集验收<br/>Core / ISO / Strict 评估"]

关键设计¶

1. 黑盒契约约束规范：剥离内部接口约束以迫使智能体承担架构决策风险

传统基准测试常通过预定义类名、函数签名或单元测试断言变相泄露了软件内部架构，使模型沦为函数填空器。为了真实测试智能体的系统设计能力，SlopCodeBench 制定了严格的外部黑盒设计原则：每个检查点仅在命令行接口（CLI）或对外服务 API 边界上声明输入输出与可观测行为（如参数解析规范、JSON/JSON Lines 返回格式规范）。评测环境不规定任何内部模块划分、数据结构或内部调用链，智能体必须完全自行决定如何组织文件结构、提取通用算子与解耦业务逻辑。测试套件仅通过外部子进程调用或标准 API 发送请求并对结果做无害归一化对比，杜绝测试代码对架构提示的反向泄漏。

2. 检查点迭代演化机制：长程自我继承的真实软件生命周期模拟

现有的长程评测若在每轮重置为标准参考答案，便切断了缺陷累积的因果链。SlopCodeBench 强制智能体直接继承自身上一轮生成的完整文件系统目录作为初始输入，即满足递推关系： $$y_i = \pi_{\theta}(x_i, y_{i-1})$$ 评测环境清除了先前轮次的对话历史提示词，智能体必须像人类接盘维护者一样，通过静态阅读并理解现有工程代码来完成增量特性的开发。若智能体在 $C_1$ 采取了缺乏扩展性的硬编码或扁平化脚本设计，该不良架构将在 $C_2$ 及后续检查点转化为严重的认知负荷与修改障碍，使其无法逃避技术债务的惩罚。

3. 双维度代码质量量化：解耦控制流复杂度堆积与代码冗余表征

针对智能体生成代码普遍存在的打补丁恶习，本文建立了独立于功能正确性的两维质量度量体系。首先定义“结构侵蚀度”（Structural Erosion），捕捉逻辑被粗暴堆砌在已有复杂函数中的“上帝函数”现象。通过 McCabe 圈复杂度 $\text{CC}(f)$ 与代码行数 $\text{SLOC}(f)$ 构造函数的复杂度质量质量度量： $$\text{mass}(f) = \text{CC}(f) \times \sqrt{\text{SLOC}(f)}$$ 设定圈复杂度阈值 10，侵蚀度即为超过该阈值的高复杂度函数所占总复杂度质量的比例： $$\text{Erosion} = \frac{\sum_{f \in \mathcal{F}} \mathbb{I}[\text{CC}(f) > 10] \cdot \text{mass}(f)}{\sum_{f \in \mathcal{F}} \text{mass}(f)}$$ 其次定义“冗余度”（Verbosity），量化低效模板代码与重复代码段的膨胀比例。结合 137 条针对常见 LLM 坏味道定制的 AST-Grep 规则集以及结构克隆检测行数，通过总代码行数归一化计算： $$\text{Verbosity} = \frac{|\{\text{AST-Grep Flagged Lines} \cup \text{Clone Lines}\}|}{\text{LOC}}$$ 两项指标正交互补，全面刻画了代码库在演化过程中的内部架构劣变。

一个完整示例¶

以基准中的 code_search（代码检索工具）任务为例： 1. $C_1$ 阶段：规格要求编写命令行程序，接收 --rules <file> 扫描 Python 代码中的精确字面量与基础正则，输出标准 JSON Lines。模型通常定义了一个简单主函数，利用单层循环完成了文件遍历与正则匹配； 2. $C_2$ 阶段：增量需求加入对 JavaScript 与 C++ 多种文件后缀的支持，并允许规则指定适用语言列表。优秀的人类架构会拆分出语言分发器与抽象文件加载层，但多数智能体选择直接在主扫描循环中增加 if/elif 分支； 3. $C_3$ 阶段：需求进一步引入含元变量（如 $NAME、$NAME?）的结构化 AST 模式匹配规则（pattern matching），要求捕获代码段的行号与列号。此时此前使用纯正则处理的结构彻底崩溃。由于智能体未在前期解耦解析器与规则执行引擎，智能体在 $C_5$ 时将核心逻辑堆积至长达 117 行的 find_matches_in_file() 函数中，单个函数的圈复杂度突破极限，导致后续检查点全线崩溃。

实验关键数据¶

主实验¶

评测涵盖来自 6 家主流服务商的 15 种前沿代码智能体，在标准 just-solve 提示词与原生 Docker 沙箱环境下运行（各检查点独立两小时时限）。各模型在严格通过率（Strict）、单检查点隔离通过率（Iso.）、核心用例通过率（Core）、至少解决一个检查点的题目占比（Partial）、以及侵蚀度与冗余度上的表现如下表所示：

模型	Strict 通过率 (%)	Iso. 隔离通过率 (%)	Core 核心通过率 (%)	Partial 题目解决率 (%)	平均单检查点成本 ($)	结构侵蚀度 (Erosion)	冗余度 (Verbosity)
GPT 5.5	14.8	28.1	66.8	50.0	1.51	0.49	0.32
GPT 5.3 Codex	11.2	26.0	60.7	41.7	0.66	0.64	0.46
GPT 5.4	10.7	23.5	62.8	36.1	0.72	0.51	0.33
Kimi K2.6	10.7	18.9	51.0	33.3	0.74	0.76	0.51
Opus 4.6	9.7	20.9	67.3	27.8	3.17	0.75	0.44
GPT 5.2 Codex	9.7	21.9	56.1	36.1	0.85	0.73	0.50
GLM 5.1	9.7	13.8	40.3	30.6	1.47	0.71	0.41
Opus 4.5	9.2	17.3	57.7	25.0	2.53	0.70	0.43
Opus 4.7	8.2	20.9	65.8	36.1	2.17	0.76	0.48
Sonnet 4.6	7.1	16.8	57.7	27.8	1.96	0.75	0.44
Composer 2	6.1	16.3	52.6	13.9	0.44	0.72	0.45
MiniMax M2.7	2.0	4.1	28.1	8.3	0.34	0.73	0.47

注：严格通过率（Strict）要求自开始至当前检查点的所有回归用例及隐藏用例全部通过；全场没有模型能端到端解决任何一个完整问题（36 个问题的全通过率均为 0%）。

消融实验¶

为了验证提示词干预对减缓代码退化的有效性，论文对比了基础提示（Just-Solve）、明确列出反模式的防退化提示（Anti-Slop）以及规划优先提示（Plan-First）：

模型	提示策略	Strict 通过率 (%)	Iso. 隔离通过率 (%)	Core 通过率 (%)	结构侵蚀度 (Erosion)	冗余度 (Verbosity)	单检查点开销 ($)
GPT 5.3 Codex	Just-Solve	11.2	26.0	60.7	0.64	0.46	0.66
GPT 5.3 Codex	Anti-Slop	11.2 (+0.0)	23.5 (-2.6)	57.1 (-3.6)	0.42 (-0.22)	0.31 (-0.15)	0.73 (+0.07)
GPT 5.3 Codex	Plan-First	8.2 (-3.1)	21.4 (-4.6)	62.2 (+1.5)	0.55 (-0.10)	0.40 (-0.06)	0.68 (+0.02)
GPT 5.4	Just-Solve	10.7	23.5	62.8	0.51	0.33	0.72
GPT 5.4	Anti-Slop	9.2 (-1.5)	25.5 (+2.0)	61.2 (-1.5)	0.28 (-0.23)	0.24 (-0.09)	0.90 (+0.18)
GPT 5.4	Plan-First	9.7 (-1.0)	25.0 (+1.5)	63.3 (+0.5)	0.39 (-0.11)	0.30 (-0.02)	0.83 (+0.11)
GPT 5.5	Just-Solve	14.8	28.1	66.8	0.49	0.32	1.51
GPT 5.5	Anti-Slop	9.2 (-5.6)	24.0 (-4.1)	63.3 (-3.6)	0.21 (-0.28)	0.21 (-0.11)	1.68 (+0.17)
GPT 5.5	Plan-First	8.2 (-6.6)	24.0 (-4.1)	67.3 (+0.5)	0.29 (-0.21)	0.25 (-0.06)	1.61 (+0.11)

同时，论文收集了 473 个不同星级规模的真实 Python 开源仓库（共 13,667 个提交），对比人类开发者的代码演化质量基线：人类开源仓库平均冗余度仅为 0.19，平均结构侵蚀度为 0.34；而智能体平均冗余度（0.44）是人类的 2.3 倍，侵蚀度（0.68）是人类的 2.0 倍。在演化速度上，智能体冗余累积速度是人类的 6.6 倍，侵蚀增长速度是人类的 5.0 倍。

关键发现¶

长程任务彻底沦陷：没有任何一个智能体能够在任意一个问题上实现所有检查点完全端到端通过（最高严格通过率仅为 GPT 5.5 的 14.8%）。即便隔离看单轮测试，隔离通过率也仅维持在 28.1% 以下。
质量退化普遍存在：在所有智能体轨迹中，77.0% 的轨迹表现出结构侵蚀度持续上升，75.5% 的轨迹冗余度持续增长。圈复杂度超过 10 的高危函数数量从平均每工程 3.6 个激增至 23.7 个，最大圈复杂度由 27.5 飙升至 69.0。
提示词干预治标不治本：加入 Anti-Slop 与 Plan-First 等显式质量约束提示能显著降低起步阶段的侵蚀度与冗余度（初始指标降幅达三分之一以上），但无法遏制随迭代推进产生的质量退化斜率（各检查点平均退化速率依然高达 1.3 个百分点），同时还会带来 12.1% 的额外 token 开销与 2.4 个百分点的严格正确率下滑。

亮点与洞察¶

跳出单次评估舒适区，切中自主架构演化痛点：通过只约束黑盒 I/O 契约并强制继承上一轮代码库，首次在不泄露内部架构线索的前提下，将智能体早期设计权衡对后续代码可扩展性的深远影响精准暴露出来。
量化工具与软件度量学深度结合：将 McCabe 圈复杂度结合有效代码行数构建连续的“复杂度质量”（complexity mass），配合 AST-Grep 反模式语法扫描与克隆检测，创造性地给出了学术界对大模型“垃圾代码”（slop）客观量化的数学形式。
揭示了“功能看似通过、架构早已腐烂”的隐形危机：实验表明核心测试通过率与最终系统可演化性严重脱节，这为现实工业界使用 AI 辅助编码时审查开销激增、系统快速步入技术债务泥潭提供了坚实的数据证据。

局限与展望¶

作者承认的局限：目前评测语言受成本限制集中在 Python 单一生态，虽然任务设计理论上具备语言无关性，但尚未涵盖跨语言生态（如 Rust、Go、C++）中的退化模式；此外评测使用的是各模型的原生长程环境，未系统测试主动引入重构专用智能体的复杂编排系统。
潜在的研究盲区：目前的基准测试对所有未通过检查点赋予了零分，这对于因为前期极微小输出格式偏差导致级联断裂的智能体可能略微惩罚过重；同时评测未开放交互式调试环境或人类结对审查环境。
改进方向：探索引入主动代码重构触发机制（如在演化循环中引入定期的代码异味自省与重构动作），以及探索结合动态测试覆盖率奖励的多轮强化学习训练，使智能体学会兼顾短期特性交付与长期架构维护。

评分¶

新颖性: ⭐⭐⭐⭐⭐ 首次提出面向代码智能体自演化架构退化与代码异味的黑盒长程迭代评测基准。
实验充分度: ⭐⭐⭐⭐⭐ 涵盖 15 个主流商业与开源大模型，采集数千条执行轨迹，并与 473 个真实人类开源项目做详实校准比对。
写作质量: ⭐⭐⭐⭐⭐ 概念界定清晰准确，公式推导严密且动机陈述极具说服力。
价值: ⭐⭐⭐⭐⭐ 深刻揭示了当下代码智能体在长期系统工程维度的关键软肋，为下一代代码智能体系统设计与训练提供了重要的评测标尺。