用于多文件更改本地化的 LLM 代理中的探索结构

软件工程工具越来越依赖基于 LLM 的代理来本地化要更改的文件以解决软件问题。大多数人工智能代理线性地探索存储库，即每一步访问一个目录或文件。我们假设这是跨越多个子系统的变化的结构性不匹配。我们将线性顺序探索与非线性、领域范围内的并行代理探索进行比较。使用 SWE Bench Pro 作为初始基准，我们重点关注 ansible 作为范例。我们构建了一种对基于单个基本提交的 GitHub 问题进行持久会话评估的方法。我们将非线性域代理文件遍历系统与没有直接存储库访问的基本 LLM、具有持久 Python REPL 的单代理递归语言模型 (RLM) 基线以及使用 Codex 5.5 High 的外部 CLI 基线进行比较。使用小型俳句类模型生成的域范围并行智能体在俳句类模型中大幅实现了最高的微 F1。在我们自己的扩展基准上，域代理排名第二，仅次于更大的 Codex 5.5 High，包括 2025 年和 2026 年的最新 PR。在原始的、策划的 2020 SWE-bench Pro 基准上，更大的 Sonnet plain LLM 基线通过预测很少的文件来获得更高的微 F1，从而获得更高的精度，但所有标准目标文件召回率显着降低。我们还提出了另外三项发现。首先，文档演变是任何方法都无法解决的潜在依赖关系。其次，由于测试文件过度预测，原始文件系统访问可能会降低本地化性能。最后，强制的多代理协商并没有显着的帮助，并且会大幅提高词元成本。