约束衰减：LLM代理在后端代码生成中的脆弱性

# 约束衰减：LLM智能体在后端代码生成中的脆弱性

来源：https://arxiv.org/html/2605.06445

Francesco Dente  
EURECOM, France  
[email protected]

&Dario Satriani\*  
University of Basilicata, Italy  
[email protected]

&Paolo Papotti  
EURECOM, France  
[email protected]

###### 摘要

大型语言模型（LLM）智能体在宽松规范下的自主代码生成中展现出强大的性能。然而，生产级软件要求严格遵守结构约束，例如架构模式、数据库和对象关系映射。现有基准测试往往忽略这些非功能需求，奖励功能正确但结构任意的解决方案。我们进行了一项系统性研究，评估智能体在多文件后端生成中如何处理结构约束。通过固定一个统一的API契约，涵盖80个绿地生成任务和20个功能实现任务，跨越八个Web框架，我们使用端到端行为测试和静态验证器进行双重评估，从而隔离结构复杂性的影响。我们的发现揭示了一种“约束衰减”现象：随着结构需求的累积，智能体性能显著下降。从基线到完全指定的任务，性能较好的配置在断言通过率（A%）上平均损失30个百分点，而一些较弱的配置则接近零。框架敏感性分析揭示了显著的性能差异：智能体在最小化、显式框架（如Flask）中表现较好，但在惯例密集型环境（如FastAPI、Django）中平均表现明显更差。最后，错误分析确定数据层缺陷（例如，不正确的查询组合和ORM运行时违规）是主要的根本原因。这项工作强调，同时满足功能性和结构性需求仍然是编码智能体面临的关键开放挑战。

## 1 引言

软件工程的格局正经历根本性的转变，这得益于能够自主生成代码的大型语言模型（LLM）智能体的日益普及（Wang et al., 2025；SWE-agent Team, 2025；Yang et al., 2024）。这些智能体在“浅层”生成任务中表现出卓越的能力，其中目标广泛，需求定义松散（Qwen Team, 2026；OpenAI, 2026；Hong et al., 2024；Kimi, 2026）。这种灵活性适用于一系列开发场景，例如快速原型设计、演示应用、前端界面和概念验证实施，在这些场景中，结构决策可以留给智能体。然而，当目标是生产级后端时，这种宽松变得不利。此类系统必须通过公开符合API契约、遵循架构模式、与数据库集成并通过指定ORM层运行的端点来满足功能性和非功能性需求。这些约束对智能体性能的影响在很大程度上尚未被探索。

最近的基准测试评估LLM智能体在绿地代码生成（从零构建应用）或GitHub问题解决方面的能力，但都没有充分捕捉到受约束的多文件后端开发的挑战。现有工作要么专注于在给定描述和现有代码库的情况下解决特定问题（Jimenez et al., 2024；Deng et al., 2025），要么奖励从规定不足的自然语言（NL）提示中进行无约束生成（Luo et al., 2026），要么直接通过提示针对单文件解决方案（Vero et al., 2024），要么为智能体提供骨架代码以供完成（Zhao et al., 2025），忽略了系统性地改变施加在智能体上的结构约束程度的影响。

图1：给定相同的API规范，LLM智能体在无约束条件下生成功能性代码库（上方），但在结构约束下性能下降（下方）。

为了研究这种情况，我们进行了一项系统性研究，评估LLM智能体在受约束的后端生成任务中的表现，利用OpenAPI规范作为表达功能性需求的结构化方式。我们的设计固定了API契约，并在所有条件下部署了一套共享的端到端行为测试，从而隔离四个非功能性约束维度的影响：框架选择、架构模式、数据库后端和ORM集成。通过系统地分层这些约束，我们测量了随着任务复杂性的增加（从基线生成到需要指定架构、预设数据库和ORM层的完全指定系统）性能下降的情况。我们的实证发现表明，随着非功能性约束密度的增加，智能体性能出现下降。图1展示了这种“约束衰减”现象：在基线条件下轻松生成功能性代码库的智能体，在强制执行严格的架构和数据层规则时严重失败。我们证明，即使是最先进的智能体，当无约束生成被对结构化规范的严格遵循所取代时，也难以保持功能合规性。

在本文中，我们报告以下贡献：
- **评估方法**。基于OpenAPI规范和行为测试的评估流程，将功能正确性与结构合规性解耦。我们开源80个绿地生成任务和20个功能实现任务。
- **约束衰减（RQ1）**。实证识别了“约束衰减”：随着显式结构需求（架构、数据库、ORM）的累积，智能体性能下降，性能良好的模型在断言通过率（A%）上平均损失30个百分点。
- **框架敏感性（RQ2）**。框架分析揭示了在相同API契约下，智能体成功率存在显著差异。智能体在轻量级、显式框架（如Flask）中比在惯例密集型环境（如FastAPI）中表现更好。
- **根本原因分类（RQ3）**。广泛的轨迹和错误分析表明，数据层缺陷，特别是不正确的查询组合和ORM运行时违规，是主要的根本原因，导致约45%的智能体逻辑失败。

## 2 相关工作

**绿地应用生成。** 最近的基准测试开始评估LLM智能体从零生成完整应用的能力，但没有一个充分捕捉到受约束的多文件、仓库级后端开发的挑战。Luo等人（2026）根据知名库的现有测试套件衡量输出，但奖励从规定不足的提示中进行无约束生成。Seo等人（2026）针对用于复现研究论文的仓库生成，而Zhao等人（2025）为智能体提供骨架库以供完成。Ding等人（2025）评估编码智能体从逆向工程的Python代码库自然语言规范中生成仓库的能力。这些工作都没有针对后端系统，也没有系统地改变结构约束的程度。Vero等人（2024）更接近我们的设置，他们要求LLM从OpenAPI规范生成跨多个框架和语言的后端服务，并通过端到端功能和安全性测试进行评估。然而，它通过直接提示针对单文件解决方案，而不是通过智能体交互生成的多文件仓库，并且没有研究分层架构约束如何影响生成质量。我们的工作固定一个API契约，并在八个框架上系统地分层结构约束，针对一套完全与内部代码结构解耦的共享端到端行为测试评估实现，无论智能体如何组织其解决方案，都能实现公平比较。

**仓库级编码任务的基准测试。** 基于问题的数据集，如SWE-Bench（Jimenez et al., 2024），提供了真实的软件工程环境，但当前智能体在该基准测试上正接近饱和。扩展通过多语言支持、改进的抗过拟合能力和可扩展的环境构建（Deng et al., 2025；Rashid et al., 2025；Zan et al., 2025；Jain et al., 2025）扩大了范围，而补充基准测试评估智能体添加新功能的能力（Li et al., 2025；Chen et al., 2025；Miserendino et al., 2025）。其他工作侧重于仓库级函数或行补全（Liu et al., 2024；Ding et al., 2023；Zhang et al., 2023）或可扩展的沙箱评估Xie等人（2025）。在我们的工作中，我们要求智能体从零生成后端系统，而不是修改现有代码库，同时系统性增加结构约束。

**软件工程智能体。** SWE-bench 催化了智能体架构的发展。OpenHands 提供了一个框架，包含文件I/O、代码执行和版本控制的工具，采用ReAct风格的规划器进行多步推理（Wang et al., 2025）。SWE-Agent 强调可配置的智能体-计算机接口，用于与隔离环境交互（Yang et al., 2024）；其变体 Mini-SWE-Agent 将脚手架简化为100行Python脚本，使用bash命令。Xia等人（2024）放弃自主规划，将问题解决分解为固定流程：定位、补丁生成和验证。我们的研究利用其中两个开源架构（Mini-SWE-Agent 和 OpenHands）来衡量当前智能体如何与结构约束密度交互作用。

## 3 方法

为了隔离和评估结构约束对代码生成的影响，我们提出了一种受行为驱动开发（North and others, 2006）启发的评估方法。我们方法的原则是保持功能规范不变，同时系统性地改变非功能需求（即结构约束）。这种实验设计将约束的影响与任务的逻辑复杂性隔离开来，从而在智能体和模型之间实现受控、公平的比较。

### 3.1 生成任务设计

我们定义一个**绿地生成任务**：给定目标服务的全面NL描述，LLM智能体必须从零（即从空仓库）合成一个完整的、符合规范的REST API。为了执行此任务，智能体获得一个包含四个组件的输入提示：(i) API规范，(ii) 要强制执行的结构约束，(iii) 执行生成代码所需的必需文件，以及 (iv) 用于评估提交的流程描述（完整示例见附录E）。

**API规范。** 我们采用 OpenAPI 3.0 规范111https://openapis.org/specification/v3.0.0.html 作为所有任务的标准化功能需求格式。OpenAPI 是一种机器可读、语言无关的接口描述标准，在业界广泛用于API优先开发。这种结构化格式相比NL描述具有两个方法论优势。首先，它消除了规范歧义：每个功能行为、端点签名、请求体、响应模式和状态码都有形式化定义。其次，它有助于预先定义行为测试套件，用于评估任何合规实现，无论底层语言、框架或内部架构如何。这种方法保证了评估灵活性和行为覆盖率，这是传统的基于单元测试的流程无法实现的，因为单元测试本质上与特定的实现细节耦合。我们的规范源自 RealWorld Conduit API222https://realworld-docs.netlify.app/。该规范涵盖19个标准的创建、读取、更新和删除（CRUD）操作，分布在五个资源组（文章、评论、用户、个人资料和标签）中。选择这个开源规范是经过深思熟虑的。首先，它在保持LLM上下文窗口限制内的高度细粒度级别定义操作。此外，功能性请求的相对简单性，结合模型在预训练期间可能已经接触过该规范，确保了结构约束的影响与基线功能复杂性之间的精确区分。我们故意固定一个API契约以最大化内部效度：保持功能目标不变，使我们能够隔离结构约束、框架和智能体脚手架的影响，而不会将它们与任务语义的差异混为一谈。

**框架覆盖。** 框架被视为一个实验因素，具有八个离散水平，使我们能够测试相同的功能规范在相同评估条件下是否表现出框架依赖性难度。我们选择了两种最广泛使用的语言运行时中的流行框架：Python 3.12（Flask, FastAPI, Django, aiohttp）和 Node.js 20（Express, Fastify, Hono, Koa）。这两种运行时都基于动态、多范式的编程语言，为代码生成提供最大的自由度。

### 3.2 约束维度

为了系统评估约束的影响，我们定义了三个正交的非功能性轴，这些轴可以在代码规范中包含或省略。

**架构模式。** 代码架构是固定的：必须按照整洁架构模式（Martin, 2017）进行组织。智能体不能自发定义单体或任意的文件结构，而必须将代码库拆分为四个域层，具有严格的自上而下依赖方向：路由/处理器、服务/用例、模型/实体和仓库/数据访问。每层必须位于自己的目录中。

**数据库后端。** 数据库层是固定的：PostgreSQL 或 SQLite。智能体必须使用特定的数据库引擎持久化数据。对于 PostgreSQL 任务，执行环境中提供预配置的实例；对于 SQLite，无需外部服务。在这两种情况下，模式必须在服务器启动时自动创建。

**ORM 集成。** Ob