来自马萨诸塞大学阿默斯特分校（UMass Amherst）、Zoom、埃默里大学（Emory University）和北卡罗来纳大学夏洛特分校（UNC Charlotte）的研究人员在保持 AI 模型不变的前提下，仅调整了模型周边的软件架构，并对 AI 编程智能体进行了 176 组测试。
他们使用了四种模型和两个基准测试集：一个包含来自 GitHub 项目的 500 个实际编程问题，另一个包含 89 个命令行任务。
研究人员将他们修改的这部分组件称为“控制框架”（harness）。
该组件决定了模型如何进行规划、可以使用哪些工具，以及在任务耗时较长时如何在内存中保留信息。
在研究中，内存管理方式引发了最大的性能波动。
模型一次能处理的文本量是有限的，这一限制被称为“上下文窗口”（context window）。
在使用 32k token 的上下文窗口且不进行内存管理的情况下，四种模型在处理 GitHub 任务时的平均失败率高达 78.7%，主要原因是模型可用空间耗尽。
在该配置下，NVIDIA 的 Nemotron-3 550B 模型仅成功解决了 6.4% 的任务。
当控制框架采取措施——如裁剪旧的工具输出、总结早期步骤或同时执行这两项操作——时，同一模型解决任务的比例提升到了 51% 到 58% 之间。
规划机制的影响则取决于模型本身的性能强弱。
在没有规划机制的情况下，最小的模型 Nemotron-3 30B 平均在 5 轮交互后便停止运行，其在 GitHub 任务上的成功率从 25.2% 降至 13.6%。
另外两个性能更强的模型在启用规划机制后，准确率波动保持在 2 个百分点以内，且在处理 GitHub 任务时的成本降低了约 30%，因为它们避免了重复检查已完成的工作。
工具的选择也呈现出类似的差异化结果。
当 550B 模型使用普通终端而非现成的文件操作工具时，它解决了更多的 GitHub 任务，且成本降低了 53%。
相比之下，Mistral Medium 3.5 模型的情况则截然相反，在同一任务集上的成功率从 68.6% 降至 45.4%。作者得出结论：不存在唯一的最佳配置，各项组件的选择应视具体模型、任务及预算而定。
基准测试得分反映的是模型及其配套支撑系统（harness）的综合表现，而本文揭示了该得分中有相当一部分实际上是由支撑系统决定的。