为什么 AI 编码代理在“外部循环”中频频失败？

随着 Claude Code 和 Devin 等工具的普及，现代 AI 编码代理已不再依赖单次提示执行，而是普遍采用了外部循环 架构。在这种架构中，系统被拆分为两个核心角色：负责具体代码编辑和测试执行的 Worker，以及负责解析任务、检查进度并做出决策的 Controller。

近期，阿里巴巴的 DreamX 团队与 UNSW 研究人员联合发布了新的基准测试框架 LoopArena（arXiv:2608.28281），旨在专门评估语言模型作为运行时控制器的表现。本文将基于该测试结果，探讨 AI 编码代理在复杂任务中的失败原因及优化方向。

LoopArena 如何评估代理性能？

传统的 SWE-bench 等基准测试往往将整个运行过程视为一个“黑盒”。当代理失败时，最终的错误日志往往无法定位问题源头——是底层模型写出了无效语法？还是控制器盲目接受了错误的测试通过信号？

LoopArena 通过将系统解耦，清晰地隔离了失败面：

• Worker（工作器）： 固定的编码代理，负责编辑文件、运行终端命令、生成代码差异（diff）并输出日志。
• Controller（控制器）： 待测试的模型，接收结构化的运行摘要，验证退出条件，并决定下一步是继续、回滚还是终止。

为了全面评估，LoopArena 设定了三个测试层级：

1. Type I（静态问题）： 基于历史执行轨迹测试控制器是否能选出正确的下一步，无需启动实时环境。
2. Type II（交互式控制）： 针对开发任务中的特定切片进行多步恢复测试。
3. Type III（全任务）： 从初始仓库状态开始执行完整的长期任务。

关键发现：成功率低、Token 节省显著

实验数据揭示了当前 AI 编码代理在实际应用中的脆弱性：

• 低完成天花板： 在最复杂的 Type III 全任务测试中，所有控制器中最高严格成功率仅为 24.69%。这意味着，即便底层的代码生成模型能力强大，控制器也难以有效引导多文件变更直至完成。
• Token 节省潜力巨大： 有效的控制器能通过智能剪枝，将总推理成本平均降低 64.4%。优秀的循环路由可以避免冗余的测试循环、防止冲突编辑，并在浪费 Token 之前终止注定失败的任务轨迹。
• 切片评估可预测全量表现： Type II（切片评估）与 Type III（全量运行）的 Spearman 相关系数高达 0.9747。开发者可以在短执行片段上测试控制策略，从而避免为每次全仓库运行花费数百美元的成本。

实战经验：如何修复运行时控制策略？

LoopArena 的研究指出，当任务变长时，运行时控制策略 往往比上下文窗口大小或模型升级更早成为瓶颈。开发者在构建 Agent 框架时，应重点关注以下两个常见失败模式及其解决方案：

1. 盲目接受过时的进度报告

现象： Worker 可能声称修复了文档字符串中的 Bug，但 Controller 在未运行测试套件的情况下就终止了任务。 解决： 必须实施严格的验证门控，要求显式、可执行的测试通过信号，才能标记子任务完成。

2. 循环震荡

现象： Worker 在两个相互冲突的代码编辑之间反复切换，而 Controller 却盲目报告“正在取得进展”。 解决： 加强控制器与工作器之间的契约执行，确保在检测到循环依赖或无效状态时强制终止或回滚。

总结： 提升编码代理能力，不应仅盯着升级基础模型，优化运行时的“指挥官”策略同样至关重要。