研究背景与文献综述

研究问题的核心定位

现代软件工程正在经历一场根本性转变：大型语言模型（LLM）Agent 能够自主生成代码，这一能力正在重塑开发流程。现有 Agent 在”浅层”生成任务中表现卓越——当目标宽泛、需求松散定义时，它们能够快速产出原型、演示应用、前端界面或概念验证实现。这种灵活性在结构决策可由 Agent 自主决定的场景中极具价值。

然而，当目标是生产级后端系统时，这种许可性转变为一种负担。生产级系统必须同时满足功能需求和非功能需求：暴露符合 API 规约的端点、遵循架构模式、集成数据库、通过指定的 ORM 层运行。这些结构约束对 Agent 性能的影响在现有研究中几乎未被探索。

问题的重要性

这一问题具有三层实践意义：

工业部署的现实挑战: 企业在采用 Agent 辅助开发时，往往期望其能够产出符合团队架构规范、数据库选型和技术栈约定的代码。当前 Agent 的”约束衰减”现象意味着人工干预成本并未被有效降低——Agent 生成的代码可能需要大量重构才能融入现有技术栈。

基准测试的盲区效应: 现有基准测试奖励”功能正确但结构任意”的解决方案，这使得 Agent 开发者可能在错误的优化方向上投入资源——提升无约束生成能力而非结构遵循能力。

Agent 架构设计的误导: 当基准测试不考察结构约束时，Agent 的规划模块、工具接口、终止策略可能被设计为”快速产出功能代码”而非”系统性满足多维度约束”。

文献综述：基准测试的演进轨迹

Greenfield 应用生成基准

近期基准开始评估 LLM Agent 从零生成完整应用的能力，但无一充分捕获受约束多文件后端开发的挑战。

RPG (Luo et al., 2026) 采用仓库规划图测量输出是否符合现有测试套件，但其奖励来自未充分指定提示的自由生成。Prompt 仅包含模糊的功能描述，Agent 可自由决定架构、数据层、组织结构——这恰恰规避了本文研究的问题。

Paper2Code (Seo et al., 2026) 针对复现研究论文的仓库生成，Commit0 (Zhao et al., 2025) 提供骨架库供 Agent 完成。两者均未针对后端系统，也未系统性变化结构约束的程度。

NL2Repo-bench (Ding et al., 2025) 从逆向工程的自然语言规约评估 Agent 的仓库生成能力，但其规约来源是现有 Python 代码库的描述，而非结构化约束的系统性叠加。

BaxBench (Vero et al., 2024) 最接近本文设置：要求 LLM 从 OpenAPI 规约生成后端服务，跨多框架和语言，通过端到端功能和安全测试评估。但其针对单文件解决方案，通过直接提示而非多文件仓库的 Agent 交互生成，且未研究架构约束叠加如何影响生成质量。

本文的设计固定单一 API 规约，系统性叠加结构约束跨 8 个框架，使用完全解耦于内部代码结构的端到端行为测试套件评估——这实现了跨框架、跨约束级别的公平比较。

flowchart LR
    subgraph Existing["现有基准测试"]
        A1["RPG: 自由生成奖励"]
        A2["BaxBench: 单文件目标"]
        A3["SWE-bench: Issue Resolution"]
    end
    
    subgraph Gap["研究空白"]
        B1["多文件后端生成"]
        B2["结构约束系统性变化"]
        B3["跨框架公平比较"]
    end
    
    subgraph ThisWork["本研究"]
        C1["固定 API 规约"]
        C2["四维约束叠加"]
        C3["行为测试解耦结构"]
    end
    
    Existing --> Gap
    Gap --> ThisWork
    
    style Gap fill:#f96
    style ThisWork fill:#9f6

Issue Resolution 基准

SWE-bench (Jimenez et al., 2024) 提供真实软件工程环境，但当前 Agent 已接近饱和。扩展版本通过多语言支持、改进过拟合抵抗、可扩展环境构建扩大范围（Deng et al., 2025; Rashid et al., 2025; Zan et al., 2025），补充基准评估 Agent 添加新功能的能力（Li et al., 2025; Chen et al., 2025）。

这些基准的核心局限：Agent 任务是修改现有代码库而非从零生成符合约束的系统。现有代码库已嵌入团队约定、架构模式、ORM 使用方式——Agent 需推断并尊重这些隐性约束。本文的 greenfield 设置明确显式约束，允许直接测量约束密度的影响，而非间接推断。

Agent 架构演进

SWE-bench 催化了 Agent 架构发展：

OpenHands 提供 ReAct 风格规划器、文件 I/O、代码执行、版本控制工具，支持多步推理（Wang et al., 2025）。其丰富的工具集导致更大的上下文窗口——本研究测量发现，相比 Mini-SWE-Agent，OpenHands 使用 12.9× 更多 tokens（以 GPT-5-mini 为例）。

SWE-Agent 强调可配置的 Agent-计算机接口，用于与隔离环境交互（Yang et al., 2024）。其变体 Mini-SWE-Agent 将 scaffold 简化至约 100 行 Python，仅通过 bash 命令交互——尽管简单，在 SWE-Bench 上使用前沿 LLM 达到 >70% pass@1。

Agentless (Xia et al., 2024) 放弃自主规划，将 issue resolution 分解为固定管道：定位、补丁生成、验证。

本研究利用两种开源架构（Mini-SWE-Agent 和 OpenHands）测量当前 Agent 如何与结构约束密度交互。研究团队对 scaffold 配置进行系统性调整：向 Mini-SWE-Agent 注入重对齐的系统提示以引导生成式管道；向 OpenHands 引入终止准则以缓解过早停止行为。

研究空白识别

空白一：结构约束效应未量化

现有基准要么不考察结构约束（RPG、NL2Repo），要么仅考察单文件场景（BaxBench），要么让 Agent 推断隐性约定（SWE-bench）。结构约束对 Agent 性能的边际效应未被系统性测量。

空白的表现：

• “指定 PostgreSQL 比 SQLite 多造成多少性能损失？“——无数据支撑
• “Clean Architecture 约束添加多少开发复杂度？“——无量化答案
• “ORM 强制使用导致多少错误？“——仅有定性观察

空白二：框架敏感性未控制比较

不同框架在 API 规约相同的情况下，Agent 表现是否有显著差异？现有基准未控制 API 规约，无法回答这一问题。

空白的表现：

• Flask vs FastAPI——哪个更适合 Agent 生成？无控制实验数据
• Django 的约定驱动结构对 Agent 是否构成障碍？仅有直觉判断
• Hono 的边缘运行时适配对 Agent 是否构成额外挑战？无实证验证

空白三：失败根因未系统分析

当 Agent 在受约束生成中失败时，失败分布在哪些层面？现有研究未提供根因分类体系。

空白的表现：

• “数据库层错误占多少比例？“——无分类数据
• “ORM API 误用 vs 原始 SQL 错误的比例？“——未区分
• “框架特定默认配置导致的错误占比？“——未识别

本文如何填补空白

领域术语解释

OpenAPI Specification

一种机器可读、语言无关的接口描述标准，用于 API-first 开发。定义端点签名、请求体、响应 schema、状态码。本研究采用 OpenAPI 3.0 作为所有任务的功能需求格式，确保规约无歧义。

Clean Architecture

Martin (2017) 提出的架构模式，将代码分为四层：routes/handlers、services/use cases、models/entities、repository/data access。要求严格的自顶向下依赖方向。本研究将其作为架构约束维度。

ORM (Object-Relational Mapper)

将数据库表映射为编程语言对象的框架。本研究强制指定 SQLAlchemy（Python）和 Sequelize（Node）作为 ORM 约束维度，测量 Agent 在指定 ORM 下 vs 原始 SQL 的表现差异。

Behavioral Testing

测试 API 行为而非其实现。通过 HTTP 请求验证响应结构、类型、状态码、状态转换。本研究的行为测试套件完全解耦于内部代码结构，实现跨框架公平评估。