富士通提出Kozuchi Agent：用27B开源模型跨语言修Bug，SWE-bench达74.8%
Kozuchi Agent: A Language-Agnostic Open-Weight Agent for Software Repair
工业界对“AI程序员”的期望已经从单纯的代码补全，升级到了能够直接读取Bug报告、克隆仓库并独立提交正确补丁的端到端修复。在这个背景下，SWE-bench 成为了衡量大模型软件工程能力的试金石。然而，要在真实的基准测试中跑通长周期的修复任务，单纯依赖模型本身的上下文窗口和推理能力往往会撞墙：上下文丢失、工具调用格式崩溃、异构集群部署困难以及高昂的评估成本，都是横亘在实验室演示与工业级部署之间的鸿沟。
ArXiv URL：https://arxiv.org/abs/2608.15579v1
针对这些痛点，富士通（Fujitsu）的研究团队提出了一种全新的解决方案：Kozuchi Agent。这并非一个经过大规模微调的专用模型，而是一个语言无关（Language-Agnostic）、开源权重（Open-Weight）的软件修复智能体框架。该框架最值得记住的结论是：无需依赖昂贵的闭源专有模型，也无需任何针对性的微调，仅仅通过给本地托管的 Qwen3.5-27B 模型加上一层极其严谨的工程约束（Harness）和跨Agent的测试时选择机制，Kozuchi Agent 在 SWE-bench Verified 数据集上就解决了 374/500 个实例（成功率达 74.8%）。更为难得的是，在不修改任何配置的情况下直接迁移到 Multi-SWE-bench Java 数据集，它同样拿下了 32.03% 的修复率，在严格开源权重提交中排名第一。
这项研究证明了一个关键判断：在复杂软件修复任务中，填平“开源模型与专有闭源模型”之间差距的核心，不再仅仅是参数规模或微调数据，而是如何设计一套能够让模型行为可审计、状态可持久化、且能在测试时进行自我交叉验证的外部运行机制。
工业级软件修复面临的四大工程阻碍
在真实的代码库中修复Bug，远比解答一道算法题复杂。一次典型的修复需要经历：复现Bug、编写回归测试、定位根因、跨文件编辑代码以及最终验证结果。这一系列操作往往需要数十轮甚至上百轮的 LLM 对话交互。研究团队在开发早期发现，如果任由模型自由发挥，会遭遇四个致命的工程阻碍。
其一是长周期执行导致的决策退化。当修复轨迹耗费数小时并积累了大量对话历史时，未经约束的Agent往往会开始“胡言乱语”。它们可能会跳过复现步骤，重复调查已经排除的错误位置，甚至去修改那些自己完全没有理解的无关代码。自由形态的规划在超长上下文中极易失效。
其二是模型家族之间的工具语法漂移。不同的 LLM 在调用工具和输出结构化动作时，往往带有各自的格式偏好。哪怕只是一个微小的语法不匹配，都可能导致合理的动作被解析器拦截，进而引发连续的无效尝试。如果为了适配新模型就要重写一套Agent代码，系统的维护成本将不可估量。
其三是异构集群带来的运行环境割裂。工业界的研究任务通常分散在不同的计算集群中：GPU负责推理和训练，VM虚拟机负责运行测试，基于 Docker 的环境用于执行官方基准打分。缺乏统一的运行时环境，会导致研究人员把大量时间浪费在编写和适配各种胶水脚本上。
其四是难以承受的评估成本。在 SWE-bench 上进行端到端的容器化打分极其昂贵。如果为了验证一个微小的代码改动就要重新跑完整个流水线，迭代速度将被严重拖慢。评估成本成为了限制大规模实验的物理瓶颈。
将自由对话转变为严谨的状态机：Kozuchi Agent 核心架构
为了解决上述问题，Kozuchi Agent 并没有选择去“教”模型怎么做得更好，而是为模型打造了一个名为 $\mathcal{R}$ 的运行时契约（Runtime Contract）。这个契约通过显式的阶段划分和持久化状态，硬性规定了模型在每一步可以做什么、必须产出什么。
在 Kozuchi 的设计中，修复过程不再是一场从头到尾的长对话，而是被切分成了 8 个有向图节点构成的明确阶段（Phase）。每个阶段都代表一个局部的具体任务（如定位、编辑、测试），并且只有两种退出可能：成功完成并移交结果，或者明确声明放弃。
当一个阶段结束时，系统不会简单地把前面对话的历史堆砌给下一个阶段，而是通过一个被称为“上下文压缩与移交”的机制，强制提取当前阶段生成的脚本、错误追踪信息、测试用例和补丁差异，并写成一份简明的移交备忘录（Handover memo）。这意味着，系统的持久化记忆落在了真实的文件系统和状态快照上，而不是脆弱的 LLM 上下文窗口里。这种设计极大地降低了模型在长程任务中遗忘关键线索的概率。
为了应对不同模型间的格式漂移，Kozuchi 引入了将“语义意图”与“执行语法”解耦的格式化机制。具体来说，当前回合会由一个规划角色（Planner）用自然语言起草修复步骤，然后由一个格式化角色（Formatter）专门将核心动作转换为符合系统沙盒要求的严谨语法。这相当于在模型和执行环境之间加入了一层兼容层，使得底层可以直接插拔各种开源模型，而无需担心解析崩溃。
此外，Kozuchi 限制了工具的泛滥。系统只提供最小但高度确定性的软件工程工具集：动态行级追踪、调用者发现以及带保护机制的代码编辑。并且，这些工具是严格按阶段开放的（Phase-gated）。模型只有在确实需要编辑代码的阶段，才会看到代码编辑工具的提示词。这有效缩小了模型的动作搜索空间，防止其在不恰当的阶段滥用工具。
跨Agent测试时选择：不用“法官”也能优中选优
如果说严谨的阶段划分保证了单次修复的下限，那么 Kozuchi Agent 的上限则来自于其极具创意的测试时选择机制（Cross-Agent Test-Time Selection，简称 TTS@8）。
在模型性能有限的情况下，让模型对同一个 Bug 尝试修复多次（例如 $K=8$ 次）并从中挑选最佳结果，是一种常规策略。但痛点在于：在真实的业务环境中，或者在严格的基准测试中，你并没有上帝视角（隐藏的测试用例）来告诉你哪一次尝试是真正对的。如果引入另一个 LLM 作为“法官”来打分，又往往会因为模型自身的偏见而产生误判。
Kozuchi 的解法是让这 8 次独立运行的实例进行“交叉验证”。
在生成候选补丁的过程中，每次独立运行都必须依靠自己的力量生成两类测试：旨在暴露当前 Bug 的复现测试，以及旨在防止破坏已有功能的回归测试。
当 8 次运行都结束后，系统会收集这 8 个补丁以及它们各自生成的测试用例。接下来，系统会构建一个 $8 \times 8$ 的交叉验证矩阵：用实例 A 生成的测试，去跑实例 B 写的补丁。
在这个矩阵中，如果一个候选补丁能够通过自身生成的回归测试，并且还能通过其他实例生成的、用来暴露 Bug 的测试，那么这个补丁的置信度就会大幅提升。这种做法巧妙地将轨迹生成的多样性转化为了一种纯粹基于执行结果的选择信号。整个选择过程没有任何隐藏数据的泄露，也没有引入任何容易产生幻觉的 LLM 裁判。
研究数据显示，这种跨Agent的选择机制使得 Kozuchi 从单一的候选生成跃升到了极高的最终胜率。在 500 个实例中，所有 8 次运行的完美并集（即只要有一次对就算对）能解决 408 个问题。而纯靠这套不需要人类干预、也不需要官方测试集的交叉验证策略，系统成功挑出了其中正确的 374 个补丁，达到了理想并集上限的 92.2%。这说明大部分的算力预算被有效地转化为了可靠的交付结果，而不是盲目的盲盒抽取。
跨语言验证与工业落地启示
实验结果的含金量往往在于其泛化能力。为了证明 Kozuchi Agent 不是针对 Python 或特定基准“过拟合”的产物，研究团队将其原封不动地搬到了 Multi-SWE-bench Java 数据集上。
在不改变 27B 模型权重、不调整 8 个执行阶段、甚至不修改工具集交互逻辑的前提下，Kozuchi Agent 在 Java 任务上依然取得了 32.03% 的修复率。这个成绩在所有严格限制必须使用开源权重的提交中位列第一。数据表明，模型在跨语言时的阶段行为表现（Per-phase behavior）波动保持在 $\pm 5$ 个百分点以内。系统剩下的失败案例，主要集中在深度的语义正确性理解、Java 特有的构建环境（Harness）适配问题以及少数极具迷惑性的补丁选择错误上，而不是因为代码编辑格式崩溃或缺乏专有大模型 API。
从工程落地的角度来看，Kozuchi Agent 将冗长的修复流程固化为可复用的 CI（持续集成）流水线。在过去，跑完一次完整的基准测试需要在不同的机器和脚本之间切换，涉及多达五个手动触点；而现在，通过声明式的 CI 阶段复用，只需触发一次流程即可自动完成从候选生成、交叉打分到生成报告的全套动作。这种基础设施的降本增效，是让 TTS@8 这种多次采样策略能够在实际开发中被常态化使用的前置条件。
Kozuchi Agent 的成功给我们提供了一个非常有价值的技术切面：大模型在软件工程领域的落地，已经过了那个仅仅比拼“谁的模型更大、谁在代码预训练上堆了更多 Token”的粗放阶段。通过注入确定的软件工程工具、强制的状态快照流转，以及基于真实测试执行的交叉选择网络，我们完全可以让百亿参数级别的开源模型，在复杂的长程任务中爆发出比肩甚至超越千亿闭源模型的稳定性与工程价值。这正是 AI 走向实用化与工业化最务实的路径。