StaminaBench: Stress-Testing Coding Agents over 100 Interaction Turns¶
会议: NeurIPS 2026
arXiv: 2606.19613
OpenReview: https://openreview.net/forum?id=1IMrtjWVBs
代码: https://github.com/vsobal/staminabench
领域: 代码智能
关键词: 代码智能体, 长程多轮评测, 软件演进, REST API, 黑盒测试
一句话总结¶
提出了针对代码智能体的多轮交互长程耐力评测基准 StaminaBench，通过完全程序化生成 REST API 规范演进与黑盒 HTTP 测试套件，对 7 款开源大模型与 6 种智能体框架开展长达 100 轮交互的严苛压力测试，揭示了无测试反馈下所有模型均在 6 轮内崩溃的耐力瓶颈。
研究背景与动机¶
软件工程开发本质上是一个高度迭代演化的过程。真实的“氛围编程（vibe-coding）”或智能体协作场景中，人类工程师很少仅通过单轮交互完成工作，而是先搭建最小原型，再在数十甚至上百轮对话中持续提出新需求、修改数据结构、重构依赖关系并扩充业务逻辑。在这一长程演化过程中，智能体必须实时维护对庞大代码库的心理表征，理解累积的历史上下文并在有限的上下文窗口中做出精准的代码编辑与压缩策略。
然而，以 SWE-Bench、SWE-BenchPro、Commit0 为代表的主流代码评测基准几乎全采用单轮孤立任务设定，仅考察模型修复单个 Issue 或生成单份代码的能力。尽管已有研究尝试引入多轮评测，但真实软件仓库在经历多轮修改后极易与标准参考实现发生路径漂移，导致原本基于源码的单元测试在智能体生成的代码上失效，因而此前多轮评测的轮数往往被限制在 5 到 25 轮之内，且依赖人工提取或存在重度幻觉。评测的核心矛盾在于：如何在无需 LLM 介入生成测试用例且不侵入代码内部实现的前提下，对智能体维护的长达上百轮演化代码库进行客观、可复现、严密且语言无关的自动化正确性验证。
本文的切入点在于利用 REST API 的标准网络接口契约建立黑盒验证闭环：HTTP 端点、状态码与 JSON 数据契约天然与编程语言解耦，其资源操作、约束校验与复杂业务流转又足以支撑高度复杂的软件系统。核心 idea：构建程序化长程代码智能体评测基准 StaminaBench，通过严格的状态转移与动作空间定义，在完全脱离 LLM 介入的前提下程序化生成长达 100 轮演化的 REST API 架构需求与黑盒 HTTP 测试套件，深度压测代码智能体在长周期演进中的连续交付耐力。
方法详解¶
整体框架¶
StaminaBench 将长程多轮评测形式化为一个“参考演化系统”与“智能体系统”之间的状态跟踪游戏。评测环境作为环境策略 \(\pi_{\text{env}}\)，从初始状态分布中采样 OpenAPI 风格的强类型数据模型，随后在每个交互轮次中依据动作空间采样一批架构变更需求（包含实体增删改、字段约束、分析聚合及带有守卫条件和副作用的状态机动作），并通过自然语言规范与说明文档下发给智能体。智能体运行于完全隔离的 Docker 容器中，调用本地工具编写并启动 HTTP 服务器；评测系统随后向暴露的 HTTP 端口发起自动化测试，记录通过状态并提供多档粒度的测试反馈。
%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
A["环境规范生成器<br/>S₀ 初始规范 + π_env 变更采样"] --> B["程序化规格演进与测试生成<br/>更新参考状态 S_t 并合成 HTTP 测试集"]
B --> C["隔离容器交互协议<br/>下发自然语言需求与测试反馈"]
C --> D["代码智能体系统<br/>调用 Shell/编辑工具增量重构 server.py"]
D --> E["黑盒 HTTP 接口测试执行<br/>curl/requests 黑盒验证端点状态码与数据"]
E -->|测试失败且有重试预算| C
E -->|测试通过| F["推进至下一轮变更 (t = t + 1)"]
E -->|重试耗尽未通过| G["评测终止并记录耐力通过轮数"]关键设计¶
1. 无 LLM 介入的强类型规范演进与全程序化测试生成：保障测试集绝对客观与零幻觉 为了彻底解决基于 LLM 生成测试用例可能带来的自相矛盾与评分标准漂移问题，StaminaBench 构建了一套封闭形式化的强类型状态空间 \(\mathcal{S}\) 与转移函数 \(\tau\)。系统状态采用类似 OpenAPI 的结构体建模，包含具名实体、强类型字段（string、int、float、bool、enum、datetime）、数值上下界约束、单引用及列表引用关系、统计分析端点以及带有前置守卫与副作用的状态转换动作。在第 \(t\) 轮交互中，环境策略 \(\pi_{\text{env}}\) 从包含 13 种原子操作的动作空间 \(\mathcal{A}(s_{t-1})\) 中抽样 5 个有效变更组合成复合需求。测试生成函数 \(T\) 完全根据确定性状态定义，程序化生成包含 CRUD 边界用例、级联删除校验、非法参数 400/422 状态码验证、空值聚合返回规范以及状态流转 409 守卫冲突在内的完整 HTTP 单元测试，确保测试用例 100% 具备确定性与可复现性。
2. 基于 HTTP 契约的黑盒语言无关解耦验证：规避代码实现漂移与框架锁定
传统基于单元测试的代码评测要求智能体的函数签名与目录组织与基准答案完全一致，一旦智能体采用不同的架构模式（如分层架构 vs. 单文件脚本、FastAPI vs. Flask），白盒测试就会立即崩溃。StaminaBench 规定所有交互均通过网络层接口进行：智能体必须编写启动脚本 run_server.sh <port>，服务器在 0.0.0.0 上监听对应端口，并通过必须实现的 POST /reset 接口支持测试间的数据重置。评测套件通过黑盒向该端口发送 HTTP 请求，严格按照 HTTP 状态码规范校验结果（例如未找到实体返回 404，枚举非法前置状态返回 400，守卫条件未满足返回 409，成功返回 200/201）。这种设计使得智能体可以自由选择任何 Python Web 框架，甚至支持评估 JavaScript、Rust 等跨语言实现，完全不受实现细节与代码风格漂移的影响。
3. 细粒度反馈与受限重试协议：精准分离代码生成缺陷与自我修复耐力 在长程交互过程中，连续的零容错会导致任何偶然的笔误过早终结评测，而无限重试又会虚高掩盖系统能力的真实差距。StaminaBench 引入了受控的重试预算 \(R\)（默认 \(R=2\)）与反馈生成器 \(\text{desc}_{\text{feedback}}(r_t)\)。在每个轮次中，若智能体初次提交的代码未通过测试，评测系统将截取测试断言信息反馈给智能体，智能体在预算内拥有至多 \(R\) 次查看报错并重新编辑代码的机会。评测系统设置了三档反馈粒度：详细反馈（包含具体的断言失败信息与期望状态码）、中等反馈（仅告知哪些测试通过/失败而无报错正文）与最小反馈（仅提供二元通过/失败信号）。这一协议成功解耦了智能体的零样本单轮交付能力与基于长程上下文的错误定位与修复耐力。
一个完整示例¶
以咖啡烘焙与订阅系统的交互演进为例：
1. 第 0 轮初始状态：智能体接收包含 CoffeeBatch（批次编号、烘焙度枚举、生豆产国等）与 Subscription（客户邮箱、订阅状态等）的初始规范及 2 个分析端点（平均评分、累计支出总额）。智能体安装 FastAPI，编写路由及内存数据库，并暴露出 POST /reset。测试集执行 25 个 HTTP 请求全部通过。
2. 第 1 轮变更注入：环境采样动作注入 5 个修改：在 Subscription 中新增枚举字段 grind_preference；将 CoffeeBatch.weight_kg 重命名为 batch_weight_kg 并要求同步变更聚合分析路由路径为 /analytics/coffeebatch/batch_weight_kg/avg；放宽产国字符串长度上限至 75。智能体读取变更描述后编辑路由与校验逻辑，平滑支持新老数据映射。
3. 第 20 轮复杂长程状态：代码库已演化至 10+ 实体、数十个关联字段及带有状态转移图的订单提交流程。当执行 POST /order/{id}/submit 时，系统必须先校验状态为 pending（否则返回 400），且关联的购物车项总数大于 0（否则返回 409），并在成功后自动触发将购物车中每件商品的库存扣减并向用户发送事件。智能体若在某轮上下文压缩时遗忘了非空默认值规则，测试套件立即通过精准 HTTP 请求捕获断言失败并触发反馈重试。
实验关键数据¶
主实验¶
论文对 7 款主流开源大模型与 6 个智能体框架（通用框架 OpenCode、Mini-SWE、OpenHands，以及厂商专属框架 Mistral Vibe、Kimi CLI、QwenCode）在 20 个独立场景（每场景 100 轮，最多 2,020 个交互轮次）上进行了全面评测。在无反馈设定（@R=0）下，即使最强的模型也会在 6 轮内迅速失败；而在引入测试反馈与重试机制（@R=2）后，所有模型表现均取得显著跃升。
| 模型 | 参数量/架构 | OpenCode 平均通过轮数 (通过率) | Mini-SWE 平均通过轮数 (通过率) | OpenHands 平均通过轮数 (通过率) | 专属 Harness 平均通过轮数 (通过率) |
|---|---|---|---|---|---|
| GLM-5 | 744B/40B MoE | 57.0 ± 8.6 (25%) | 15.1 ± 1.8 (0%) | 8.7 ± 1.3 (0%) | — |
| Qwen3.5-122B | 122B/10B MoE | 39.4 ± 7.1 (10%) | 33.1 ± 9.0 (15%) | 7.3 ± 1.1 (0%) | 19.0 ± 4.8 (0%) |
| Kimi K2.5 | 1T/32B MoE | 26.8 ± 5.5 (0%) | 14.9 ± 2.7 (0%) | 4.9 ± 1.0 (0%) | 33.7 ± 6.4 (0%) |
| Devstral 2 | 123B Dense | 4.8 ± 0.8 (0%) | 5.0 ± 0.7 (0%) | 2.8 ± 0.6 (0%) | 8.9 ± 2.3 (0%) |
| Devstral Small 2 | 24B Dense | 5.5 ± 2.0 (0%) | 2.3 ± 0.6 (0%) | 0.9 ± 0.3 (0%) | 9.2 ± 3.1 (0%) |
| Qwen3-Coder-Next | 80B/3B MoE | 7.6 ± 1.8 (0%) | 6.2 ± 2.3 (0%) | 3.2 ± 0.5 (0%) | 3.0 ± 0.5 (0%) |
| Nemotron Super | 120B/12B Hybrid | 2.9 ± 1.0 (0%) | 1.6 ± 0.6 (0%) | 0.8 ± 0.2 (0%) | — |
无反馈对比实验表明：在 @R=0 下，GLM-5 在 Mini-SWE 和 OpenCode 上的平均通过轮数仅为 6.2 ± 0.7 和 4.5 ± 1.0；Kimi K2.5 仅有 3.8 ± 1.0；其余模型全部低于 1.5 轮。这一结果印证了在缺少严格单元测试反馈的氛围编程下，代码智能体极易迅速产生累积性缺陷。
消融实验¶
论文围绕测试反馈粒度、实现编程语言以及场景采样策略进行了系统的消融分析（基于 OpenCode 框架，@R=2 重试）。
| 消融维度 | 实验配置 | GLM-5 平均通过轮数 (通过率) | Qwen3.5-122B 平均通过轮数 (通过率) | Kimi K2.5 平均通过轮数 (通过率) | Devstral 2 平均通过轮数 (通过率) |
|---|---|---|---|---|---|
| 测试反馈粒度 | 详细反馈 (Detailed) | 57.0 ± 8.6 (25%) | 39.4 ± 7.1 (10%) | 26.8 ± 5.5 (0%) | 4.8 ± 0.8 (0%) |
| 中等反馈 (Medium) | 32.4 ± 6.7 (10%) | 12.1 ± 3.8 (0%) | 18.1 ± 3.6 (0%) | 2.0 ± 0.6 (0%) | |
| 最小反馈 (Minimal) | 10.7 ± 3.2 (0%) | 2.8 ± 0.9 (0%) | 4.6 ± 1.0 (0%) | 0.3 ± 0.1 (0%) | |
| 实现语言 | Python (基线) | 57.0 ± 8.6 (25%) | 39.4 ± 7.1 (10%) | 26.8 ± 5.5 (0%) | 4.8 ± 0.8 (0%) |
| JavaScript | 70.7 ± 7.1 (30%) | 26.8 ± 5.4 (5%) | 43.6 ± 8.1 (15%) | 3.8 ± 1.2 (0%) | |
| Rust | 50.1 ± 8.3 (20%) | 8.6 ± 2.4 (0%) | 13.7 ± 3.3 (0%) | 4.0 ± 1.2 (0%) | |
| 场景采样机制 | LLM 驱动采样 | 57.0 ± 8.6 (25%) | 39.4 ± 7.1 (10%) | 26.8 ± 5.5 (0%) | 4.8 ± 0.8 (0%) |
| 程序化确定性采样 | 74.1 ± 6.9 (45%) | 25.4 ± 3.8 (0%) | 26.9 ± 6.4 (5%) | 4.8 ± 1.0 (0%) |
关键发现¶
- 反馈信息是长程耐力的生命线：详细测试反馈使智能体平均通过轮数相比最小反馈暴增 6 到 12 倍。在最小反馈下，所有模型平均通过轮数均锐减至 11 轮以下，且越强的模型对详细反馈的依赖性与增益弹性越显著（GLM-5 从 57.0 骤降至 10.7；Qwen3.5-122B 从 39.4 骤降至 2.8）。
- 智能体框架决定性能上限：模型能力并不直接等价于智能体表现，Harness 的上下文管理与工具调度存在巨大杠杆。OpenCode 在绝大多数模型上处于领先梯队，而 OpenHands 在 6/7 的模型中垫底（由于过度严格的循环检测机制将相同消息报错直接锁定会话）；专有框架（如 QwenCode）的表现甚至显著差于通用框架 OpenCode。
- 重试收益的快速饱和：将重试预算从 R=0 扩大到 R=2 会带来质的飞跃，但进一步扩至 R=10 时收益迅速衰减并在 3-5 次重试后进入平台期。
- 非代码基础设施故障的累积放大：长程多轮交互暴露了大量非代码生成故障，包括模型在上下文压缩（compaction）时误调用工具、使用宽松正则表达式调用
pkill误杀智能体自身进程、以及陷入工具死循环。
亮点与洞察¶
- 解耦的黑盒评测范式：利用 REST API 作为通用软件工程契约，避免了依赖 AST 或源码级打桩带来的漂移问题，实现了对千行级演化代码的语言无关黑盒自动化验收。
- 完全程序化零幻觉测试集：完全摒弃 LLM 生成用例的做法，通过形式化状态机与确定性约束转移，构建了无限长度、完全可复现且无偏见的长程评测基准。
- 揭示了“氛围编程”的脆弱性：定量证明了在脱离持续集成（CI）与自动化测试反馈时，当前顶尖开源大模型在连续 5 轮需求修改内便会出现不可逆的功能衰退。
局限与展望¶
- 计算与 API 成本极高：长程交互的多轮累积使得单配置评测动辄消耗数十亿 token（例如 GLM-5 + OpenCode 消耗 45 亿输入 token），对闭源顶尖模型（如 Claude Sonnet 4.6 / GPT-5.5）开展全量评测单配置成本高达数万美元，导致闭源模型未能全量纳入。
- 单一任务领域的泛化边界：当前基准仅聚焦于 REST API 服务器实现，尽管该范式覆盖了广泛的数据流与业务逻辑，但尚无法直接迁移至编译器、图形渲染或底层操作系统内核等非服务型软件场景。
- 评测场景规模有限：受限于长程执行时间，主实验仅评测了 20 个独立场景，部分细微消融结论受样本方差影响未达显著性水平，未来可扩展分布式评测节点以提升统计置信度。
相关工作与启发¶
- vs SWE-Bench / SWE-BenchPro: SWE-Bench 聚焦于单轮从真实开源项目 Issue 修复 Bug，关注即时定位与单次补丁生成；StaminaBench 则考察智能体从零构建并在 100 轮连续变更中维护几千行代码库的演化耐力。
- vs SlopCodeBench: SlopCodeBench 同样探索了多轮代码质量衰减与接口黑盒评测，但其交互轮数仅有约 5 轮；StaminaBench 将评测跨度拓展至 100 轮交互，并引入了形式化状态空间与复杂业务流转。
- vs τ-Bench / UserBench: τ-Bench 等基准探索了模拟用户与多轮工具调用，但主要面向客服与通用任务；StaminaBench 将多轮交互与深层软件工程数据依赖、级联删除与并发状态机结合，填补了长程软件演化基准的空白。
评分¶
- 新颖性: ⭐⭐⭐⭐⭐ 首次提出长达 100 轮交互的代码智能体耐力基准，开创了无 LLM 介入的程序化黑盒长程评测范式。
- 实验充分度: ⭐⭐⭐⭐⭐ 评测覆盖 7 款开源大模型与 6 款智能体框架，实验维度横跨反馈粒度、重试预算、编程语言与代码失效归因。
- 写作质量: ⭐⭐⭐⭐⭐ 概念形式化严谨，评测算法设计清晰，失效案例剖析详实透彻。
- 价值: ⭐⭐⭐⭐⭐ 为长周期代码智能体与上下文压缩/管理机制的研究提供了极具挑战性的标准化靶场。