Constraint decay: The Fragility of LLM Agents in Backend Code Generation

原文链接：https://arxiv.org/abs/2605.06445 作者：Francesco Dente、Dario Satriani、Paolo Papotti 机构：EURECOM；University of Basilicata 发布日期：2026-05-07

速查卡

核心 Insight

这篇论文最重要的洞察，不是“agent 会犯错”，而是：

真正把 coding agent 从玩具变成工程资产的，不是会不会写 endpoint，而是能不能同时满足功能约束和结构约束。

以前很多 benchmark 的潜台词是：

• API 通了就算成功；
• 测试过了就算能用；
• 至于目录结构、数据库设计、ORM 约束、框架习惯，能跑就别管。

这篇论文把这个偷懒假设狠狠干碎了。作者固定同一份 OpenAPI contract，不改业务逻辑，只逐步往 prompt 里加三种非功能性约束：

• Clean Architecture 分层
• 指定数据库（SQLite / PostgreSQL）
• 指定 ORM（Python 用 SQLAlchemy，Node 用 Sequelize）

结果非常稳定：约束一叠加，性能就掉。这就是论文命名的 constraint decay。

为什么这个想法 work？

因为它抓住了 coding agent 真正的生产痛点：

1. “功能正确”和“结构正确”不是一回事。

   • 一个 endpoint 返回 200，不代表它可维护、可扩展、可接入现有仓库。

2. 约束累积会制造跨文件一致性压力。

   • 当你同时要求 routes / services / repositories / models 分层，再要求 DB schema 自动初始化，再要求 ORM 语义正确，模型必须在 repo 级别保持长期一致性。

3. 真实后端工程的错误集中在数据层和框架细节，而不是语法层。

   • 也就是“看起来写对了”，但 join/filter/ORM API / framework defaults 全都能暗杀你。

这就是为什么很多 agent 在 demo 视频里看着很猛，一落地到真实服务端仓库就突然笨了：它会写代码，但还不会守工程纪律。

方法详解

整体架构

作者设计了一条非常干净的实验链路：

统一 OpenAPI 规范
  → 生成多份同任务、不同约束级别的 prompt
  → 让 agent 在隔离容器里生成完整后端仓库
  → 用统一行为测试验证功能
  → 用独立 verifier 验证结构约束是否真的满足
  → 汇总 A% / pass@1 / 框架差异 / 失败根因

核心思想是“功能规格固定，结构要求逐步加码”，这样才能把性能下降归因到 constraint accumulation，而不是任务难度变化。

任务设计

论文有两类任务：

1. Greenfield generation tasks

   • 80 个任务
   • 从空仓库开始生成完整 REST API
   • 基于 RealWorld Conduit API 的 OpenAPI 3.0 规范
   • 覆盖 19 个 CRUD endpoint、5 类资源（articles、comments、users、profiles、tags）

2. Feature implementation tasks

   • 20 个任务
   • 从已有真实仓库里删掉某些功能域，让 agent 补回去
   • 目的是验证 constraint decay 不是“从零生成”这个人工设置才会出现

约束维度

作者只选了三类结构约束，原因是它们既常见，又足够强：

组件 1：Architecture

做什么： 强制遵守 Clean Architecture。

怎么做： 仓库必须拆成四层：

• routes/handlers
• services/use cases
• repositories/data access
• models/entities

并且每层只能依赖更底层，目录也必须分开。

直觉解释： 这会逼 agent 不只是“把代码写出来”，还要决定代码该落在哪个层、谁能 import 谁、业务逻辑和 HTTP 层如何分离。

组件 2：Database backend

做什么： 强制使用 PostgreSQL 或 SQLite。

怎么做：

• PostgreSQL 任务里给定预配置实例
• SQLite 任务直接本地文件
• schema 必须在 server startup 自动创建

直觉解释： 一旦真正持久化，agent 不能再用内存假装有状态；创建、查询、迁移、连接初始化都会暴露问题。

组件 3：ORM integration

做什么： 强制通过 ORM 操作数据库。

怎么做：

• Python 侧用 SQLAlchemy
• Node 侧用 Sequelize
• 不允许退回 raw SQL 或框架自带别的 data layer

直觉解释： 这条表面像“小要求”，实际是在要求模型学会框架-ORM-业务逻辑三者耦合的正确姿势。

约束级别 L0-L3

评估管线

论文的评估方式很扎实，重点是双重验证：

1. Behavioral testing

   • 统一 HTTP 测试套件
   • 32 个请求
   • 覆盖全部 19 个 endpoint
   • 共 291 条 assertions
   • 检查 response structure、types、status codes、state transitions

2. Structural verifiers

   • Architecture verifier：检查四层是否存在、import 方向是否正确
   • Database verifier：检查是否真的用到指定数据库，且没偷用别的
   • ORM verifier：检查是否真的用指定 ORM，而不是偷偷 raw SQL

这使得作者能把“功能通过但结构作弊”的情况抓出来。

训练/执行主体

论文评估了两类 agent scaffold：

• Mini-SWE-Agent：约 100 行 Python，只用 bash 命令和最小工具栈
• OpenHands：更完整的 agent 框架，带文件编辑、终端、代码搜索、任务跟踪

并配多种模型，包括 GPT-5-mini、Qwen3-Coder-Next、Qwen3-235B、MiniMax-M2.5、Kimi-K2.5、GPT-5.2 等。

这个设计很重要，因为它表明问题不是单个 agent scaffold 的锅。

与现有方法的关键区别

实验结果

主实验

论文主指标是 assertion pass rate（A%），它比 pass@1 更适合看部分进展；因为 pass@1 只要一条 assertion 失败就全盘归零，噪音太大。

*带星的模型跑的是 16-task subset，作者用相关性验证证明和 full set 排序高度一致（Pearson r=0.98，Spearman ρ=0.95）。

解读：

• 在 L0 无结构约束时，强模型确实能生成像样后端，Qwen3-Coder-Next / MiniMax-M2.5 / Kimi-K2.5 都能到 85%+ A%。
• 但一进 L3，连强配置也明显掉血；平均对 8 个可用配置来说，L0→L3 掉 30 个点，约等于基线性能损失 40%。
• 最要命的是，即便 OpenHands + MiniMax-M2.5 在 L3 还能有 78.6% A%，其 pass@1 也只有 8.3%。说明“差一点点”在真实交付里仍然等于失败。

为什么数据库约束杀伤力最大

论文的 matched-pair 分析指出：三种结构约束里，指定数据库的边际伤害最大；Clean Architecture 次之；ORM 单独加上的额外伤害相对更小。

这个结果很合理：

• 真正难的是“代码要跟数据层说对话”；
• ORM 只是把这层难度显式化；
• 一旦数据层出错，整个 API 状态机都会连环崩。

框架敏感性分析

解读：

• 轻量、显式、少魔法的框架明显更适合今天的 agent。
• Django / FastAPI 这类“约定多、隐含默认多”的框架，对 agent 仍然不友好。
• 这说明模型不是不会写 CRUD，而是还不擅长处理框架的隐式规则系统。

Feature implementation sanity check

为了防止别人说“这只是你们从零造 repo 的人工 benchmark”，作者又做了 20 个 feature implementation 任务：

• 从真实 RealWorld 仓库删掉 comments、profiles、articles+tags 等功能域
• 任务规模覆盖 161–2604 行、2–46 个文件
• agent 必须读现有代码，理解 convention，再把功能补回去

结果仍然不乐观：只有 GPT-5.2 的 pass@1 超过 50%。

这说明 constraint decay 不是 greenfield 幻觉，而是 repo 级工程现实。

失败根因分析

论文对 Qwen3-Coder-Next 和 MiniMax-M2.5 的失败轨迹做了 LLM-as-judge + 人工验证，Cohen’s κ=0.975，说明分类还算靠谱。

粗粒度看：

• 约 71% 的失败属于 logic errors
• server startup failures 排第二（12–21%）
• 其他类别加起来不到 17%

逻辑错误进一步拆后，最关键的两类是数据层缺陷：

关键发现：

1. 数据层相关错误合计约占逻辑失败的 45% 左右，这正是论文摘要反复强调的核心结论。
2. 这类错误最危险，因为它们往往不是 syntax fail，而是“服务起了、路由对了、行为却悄悄错了”。
3. 也因此，纯 pass/fail benchmark 很容易低估问题严重性。

复现评估

复现建议： 先别妄想全量复现 80+20 任务。更实际的路径是：

1. 在你最关心的 2-3 个框架上做一个缩小版 L0-L3；
2. 接上行为测试 + 结构 verifier；
3. 先测自己 agent 在“数据库 + ORM + 分层”三条线上会怎么掉。

批判性分析

局限性

论文自述和隐含局限包括：

1. API contract 固定为 RealWorld Conduit，虽然利于控制变量，但领域仍偏 CRUD 后端。
2. 只覆盖 8 个 Web 框架，企业常见的 Java/Spring、Rails、ASP.NET 不在内。
3. 约束类型只选了架构/数据库/ORM，还没覆盖缓存、队列、迁移、权限系统、CI/CD 等真实工程约束。

我们额外看到的问题

1. Prompt 已经很强约束化，和真实开发中的“半结构化需求”仍有差距。

   • 现实里任务通常更脏、更模糊，agent 只会更难，不会更容易。

2. A% 作为主指标很合理，但对业务方不够直观。

   • 真实团队更关心“最终能不能 merge / 上线”，那又会把 pass@1 的悲观现实拉回来。

3. 论文仍主要评价单 agent repo 生成。

   • 多 agent 协作、先设计再实现、planner/executor 分离等策略，也许能缓解一部分 constraint decay，但本文没有覆盖。

改进方向

1. 加入数据库迁移与 schema evolution： 当前只要求自动建表，没逼 agent 处理 migration 历史与兼容性，这才是生产真难点。

2. 把 verifier 从静态模式匹配升级到更强语义验证： 例如更细地判断依赖方向、事务边界、ORM 使用质量。

3. 引入“长期可维护性”维度： constraint compliance 不只看这次生成过没过，还要看半年后别人能不能接着改。

独立观察

• 这篇论文最值钱的地方，是给了整个 coding agent 行业一个不太好听但很必要的提醒：repo 级工程的核心瓶颈，已经从“写不写得出代码”切换到“能不能守住结构”。
• 它和最近那些讨论 dependency risk、maintainability、repo legibility 的论文其实构成了一条完整线索：agent 的问题开始从“智力不足”转向“工程纪律不足”。
• 如果未来 benchmark 还继续只看功能测试，不把结构约束和数据层正确性拉进来，行业会持续高估 coding agent 的生产可用度。

对领域的影响

短期看，这篇论文会推动更多团队给 coding agent 增加：

• repo 级 verifier
• framework-aware scaffold
• DB/ORM 专项工具
• behavior + structure 双轨评测

中期看，它会改变“好 agent”的定义：

• 不是能一把写出 CRUD demo 的 agent
• 而是能在复杂约束下稳定保形的 agent

长期看，如果这类评测被行业吸收，下一代 coding agent 的护城河将不再只是模型参数和 benchmark 分数，而是“对真实软件工程约束的服从能力”。