「让 AI 帮我连续写代码」——这是 vibe coding 最诱人的承诺，也是 2025-2026 年开发者工具赛道最热的叙事。打开 Cursor、Claude Code、Codex CLI，用自然语言描述需求，看着代码一行行生成，然后说「再改一下这里」「再加一个功能」，如此往复。许多开发者的日常已经变成了这样：在一个会话里连续追问几十轮，让 AI 不断修改同一个代码库。
但这种工作方式到底靠不靠谱？Amazon Science 的一组研究者给出了一个冷峻的答案：不靠谱。所有模型在缺乏测试的情况下，5 到 6 轮就会翻车。
StaminaBench 是什么
AWS Agentic AI 团队（Vlad Sobal、Shuo Yang 等）在 2026 年 6 月发布了 StaminaBench——一个专门测量编程 Agent「耐力」的基准测试。与 SWE-Bench 等「单次任务成功率」指标不同，StaminaBench 模拟的是真实 vibe coding 场景：Agent 需要在一个持续进化的代码库中，连续处理 100 轮修改请求，看它能撑多久才出错。
具体来说，StaminaBench 让 Agent 实现一个 REST API 服务器，然后通过程序化生成的变更序列（添加实体、重命名字段、修改约束条件、增加分析端点等）不断提出新的修改需求。每轮修改后，Agent 的代码必须通过一套自动生成的 pytest 测试套件。Agent 运行在隔离的 Docker 容器中，基准测试仅通过 HTTP 端口与它通信——完全黑盒、语言无关。
测试规模相当可观：20 个独立场景 × 100 轮修改 = 最多 2,020 个用户-Agent 交互轮次，代码库最终膨胀到约 6,000 行。所有测试用例和规格说明均由程序化生成，不依赖 LLM，确保可重复性和可靠性。
核心发现一：没有测试，5-6 轮必死
研究者首先在「无反馈循环」模式下测试了所有组合——Agent 写出代码后直接运行测试，如果失败，场景终止，没有重试机会。这模拟的是开发者让 AI 写代码但自己不跑测试的「纯 vibe coding」场景。
结果令人震惊：**6 个 Agent harness × 7 个开源模型，在 20 个场景 × 100 轮任务中，没有任何一个组合能撑过 7 轮。**表现最好的 GLM-5（智谱，744B/40B MoE）配合最佳 harness，平均也仅通过了 6.2 轮。注意，这是在规格说明极其清晰、测试完全覆盖的理想条件下——现实中的模糊需求只会更糟。
这 7 个被测模型跨越了从 24B 到 744B 总参数的广泛范围：Devstral 2（Mistral，123B）、Devstral Small 2（24B）、GLM-5（744B/40B MoE）、Kimi K2.5（Moonshot，1T/32B MoE）、Nemotron Super（NVIDIA，120B/12B 混合架构）、Qwen3-Coder-Next（阿里，80B/3B MoE）和 Qwen3.5-122B（阿里，122B/10B MoE）。六个 harness 则包括三大开源框架（OpenCode、Mini-SWE、OpenHands）以及三个模型厂商自研 harness（Mistral Vibe、Kimi CLI、QwenCode）。
论文直言不讳地指出：**即使指令清晰到「照着做就能全对」的程度，vibe coding 风格编程仍然会产生 bug。**随着对话上下文不断膨胀，Agent 越来越倾向于忽略或遗忘早期指令中的关键约束——这是「上下文压缩」的固有问题。
核心发现二：测试反馈是救命稻草，可提升 12 倍
但 StaminaBench 并不只是揭短。研究者随后开启了「重试循环」：当测试失败时，将失败信息反馈给 Agent，允许它在当前轮次内重试（最多 2 次）。结果发生了戏剧性变化。
所有 26 个 model × harness 组合均显著改善（Wilcoxon 符号秩检验，Holm 校正后 p < 0.05）。最强的 GLM-5 + OpenCode 组合从 6.2 轮跃升至平均 57.0 轮——提升约 9 倍。而如果将重试预算从 2 次扩展到 10 次，所有强模型（GLM-5、Kimi K2.5、Qwen3.5-122B）在前 5 次重试中持续改善，之后趋于平台期。
研究者进一步做了反馈粒度的消融实验。结果极具启发性：
- 详细反馈（具体断言失败信息）：GLM-5 + OpenCode 达到 57.0 轮
- 中等反馈（仅告知每个测试通过/失败，无错误细节）：大幅下降
- 最小反馈（仅告知「测试失败」，无任何细节）：GLM-5 跌至 10.7 轮，Qwen3.5-122B 从 39.4 轮暴跌至 2.8 轮
所有模型在最小反馈下都收敛到不到 11 轮。 详细反馈与最小反馈之间的差距在 6/7 的模型上达到了统计显著性（p < 0.05）。论文的结论直截了当：编程 Agent 需要精确的错误信息才能纠正自己的错误。
核心发现三：Harness 比模型更重要
StaminaBench 最反直觉的发现也许是：你的 Agent 框架（harness）选得对不对，比模型本身强不强更关键。
以 GLM-5 为例：在 OpenCode harness 下，它平均通过 57.0 轮；换到 Mini-SWE，骤降至 15.1 轮；换到 OpenHands，更惨——差距接近 4 倍。而如果看所有模型在各 harness 间的最大差距，强模型可达 6 倍。弱模型（如 Devstral Small 2、Nemotron Super）在任何 harness 下都表现不佳——好 harness 也救不了弱模型，但差 harness 可以毁掉强模型。
更值得注意的是，模型厂商自研的 harness 并不一定能带来优势。QwenCode（阿里为 Qwen 系列提供的 harness）在两个 Qwen 模型上的表现显著劣于 OpenCode（Qwen3-Coder-Next p=0.014，Qwen3.5-122B p=0.011）。OpenHands 则是 6/7 模型的最差 harness。
OpenCode 对所有 7 个模型都是最佳或统计上无法区分于最佳的选择。Mini-SWE 虽然只暴露了单个 bash 工具接口，但表现依然有竞争力。这表明 harness 的设计质量——包括上下文压缩策略、工具调用协议、错误处理逻辑——在长周期任务中可能比模型能力更决定成败。
失败模式：Agent 到底怎么死的
StaminaBench 不仅给出分数，还深入分析了失败类型。研究团队让一个 Agent 分析实验日志，将每次失败分类到预定义的类别中。
无重试模式下，最常见的失败是「实现偏差」——Agent 没有严格遵循指令，数据验证规则要么过严要么过松。例如，一个常见错误是接受 null 值，而字段明确标记为非空。尽管指令文件（README.md）始终在 Agent 的工作目录中可供查阅，Agent 仍然倾向于在上下文膨胀后忽略其中的约束。论文将此归因于多轮上下文压缩的副作用——每次压缩都可能丢失关键信息。
有重试模式下（R=10），基础设施问题变得更加突出：Agent 使用错误的工具调用格式、调用过于宽泛的 pkill 误杀自己的 harness 进程、在上下文压缩期间调用工具导致 OpenCode 报错。OpenHands 的严格循环检测逻辑在 Agent 连续四次发送相同消息时触发，错误状态污染整个会话，导致场景彻底死亡（GLM-5 + OpenHands 有 13/20 场景因此被杀死）。
这些失败模式揭示了一个深层问题：**长周期编程不仅考验模型的代码能力，还考验模型与 harness 之间的协同——包括工具调用规范、错误恢复机制、上下文管理策略。**StaminaBench 因此成为一个不仅可以评估模型，还可以评估整个 Agent 系统的工具。
成本：一场完整评测有多贵
多轮评估的代价不菲。论文披露，GLM-5 + OpenCode 一个 20 场景的 sweep 消耗了 45 亿输入 token 和 750 万输出 token。如果在闭源前沿模型上复制同样的实验，Claude Sonnet 4.6 每个配置约需 $13,600，GPT-5.5 约需 $22,700——这也解释了为什么研究者选择全部使用开源模型。
这意味着什么
StaminaBench 的发现对当前 vibe coding 热潮提出了三个严肃的挑战：
第一，无测试的 vibe coding 是走钢丝。 即使是当前最强的开源编程模型，在没有测试反馈的情况下也只能撑 5-6 轮。开发者如果只是让 AI 连续改代码而从不运行测试，累积的 bug 会在很短时间内让代码库不可用。
第二，测试反馈是 Agent 编程的刚需，不是可选项。 详细反馈和最小反馈之间 6-12 倍的差距说明，Agent 的自我纠错能力高度依赖于精确的错误定位信息。仅告诉 Agent「测试失败了」基本没用；告诉它「哪个测试、哪一行、期望什么、实际得到什么」才有用。这对 CI/CD 流水线中集成 AI Agent 有直接启示。
第三，选对 harness 可能比追最新模型更重要。 在模型能力趋于同质化的当下，harness 的工程质量——上下文压缩、工具调用规范、错误恢复——正成为差异化竞争的主战场。6 倍的 harness 差距意味着，与其花时间切换更强的模型，不如花时间优化 Agent 框架。
StaminaBench 的代码和预生成场景数据已在 GitHub 上开源（amazon-science/StaminaBench），研究者希望它能成为推动多轮编程 Agent 可靠性的基础设施。毕竟，一个只能撑 6 轮对话的编程 Agent，离真正的「AI 程序员」还有很长的路要走。