2026.03.10，Eric Huang

案例链接：https://www.swebench.com/

（a）从 Claude-4.5-Opus 在 SWE-bench 的真实轨迹抽象工程策略

1.1 问题背景

SWE-bench 是当前评估 LLM Code Agent 能力最具代表性的 benchmark 之一。其任务形式并不是传统的代码生成，而是一个完整的软件工程流程：模型获得一个 repository snapshot 和 issue / PR 描述，需要通过与 shell 环境的多轮交互定位问题、修改源码并生成 patch，最终通过测试验证修复是否正确。

从任务结构上看，这类问题同时包含多个高难度子任务：代码库导航（codebase navigation）、局部上下文理解（context building）、真实 bug 的复现与定位（debugging workflow），以及复杂环境中的依赖和构建问题处理（environment management）。因此 SWE-bench 实际上评估的并不仅是代码生成能力，而是 模型是否学会了软件工程中的调试策略。

本文分析的案例来自 Claude-4.5-Opus 在 astropy 项目中的一条真实运行轨迹。Issue 的问题描述指出 separability_matrix 在处理嵌套 CompoundModel 时行为异常，例如：

cm = m.Linear1D(10) & m.Linear1D(5)
separability_matrix(m.Pix2Sky_TAN() & cm)

在这种嵌套结构下，输出矩阵会错误地表现为非 separable。这意味着模型需要理解 astropy 建模系统中 transform 组合逻辑的传播方式，并找到错误传播发生的位置。

---

1.2 Agent Trajectory：真实调试路径

观察 Claude 的行为可以发现，其解决过程与经验丰富的软件工程师非常接近，而不是简单的“读代码 → 写 patch”。

首先，模型通过关键字搜索在代码库中定位相关实现：

find /testbed -type f -name "*.py" | xargs grep -l "separability_matrix"

这一步将搜索空间迅速收缩到 astropy/modeling/separable.py 模块。随后模型并没有遍历整个 repository，而是直接读取该文件并分析关键函数，包括 separability_matrix、_separable 以及操作符对应的 _cstack 与 _cdot。这种行为体现了一种典型的软件工程策略：targeted reading。也就是说，Agent首先建立最小必要上下文，而不是试图理解整个系统。

接下来模型尝试复现问题。它构造了一个最小脚本，直接调用 separability_matrix 对 issue 中给出的模型结构进行测试。这一步非常关键，因为在真实工程调试中，“复现 bug”是所有修复工作的前提。通过最小复现脚本，模型能够确认问题确实存在，并获得进一步分析所需的运行反馈。

运行脚本时环境出现依赖问题：

ModuleNotFoundError: erfa

模型随后执行 pip install pyerfa 进行环境修复。这一行为体现了 Code Agent 的另一个重要能力：environment stabilization。在真实软件系统中，依赖问题和构建问题往往是调试流程中的第一障碍，能够自动修复环境是 Agent 能否继续执行任务的关键。

在尝试运行后仍然遇到构建相关障碍时，Claude 并没有继续在 build 系统上反复尝试，而是选择直接基于源码进行逻辑分析。这种行为实际上是一种策略切换（strategy switching）：当动态调试路径受阻时，转而采用静态代码分析来定位问题。

---

1.3 Root Cause：问题发生的位置

分析源码可以发现，separability 的传播主要通过 _separable 函数递归完成：

elif isinstance(transform, CompoundModel):
    sepleft = _separable(transform.left)
    sepright = _separable(transform.right)
    return _operators[transform.op](sepleft, sepright)

这里 CompoundModel 会根据运算符将左右子模型的 separability 信息进行组合。例如 & 运算符对应 _cstack，用于表示两个 transform 的并行组合。

当模型结构为：

Pix2Sky_TAN() & (Linear1D & Linear1D)

时，内部的 coord_matrix 合并逻辑在处理嵌套 CompoundModel 时出现了传播错误。结果是 separability 信息在矩阵组合过程中被错误扩散，导致本应独立的输入输出被标记为互相关联。

换句话说，bug 的本质并不在于单个 transform，而是在 嵌套组合结构中 separability 信息的传播规则。

---

1.4 从轨迹抽象 Code Agent Debugging Policy

如果将这条轨迹抽象为策略，可以得到一个相当稳定的软件工程调试模式。面对一个 repository 和 issue 描述，Agent 首先执行 codebase localization：通过关键词搜索或符号查找快速定位相关模块。接着进入 targeted reading 阶段，在最小上下文内理解关键函数的实现逻辑。

当基本逻辑建立后，Agent会优先进行 bug reproduction。通过构造最小脚本或测试用例确认问题存在，并观察实际行为与预期行为之间的差异。只有在问题被确认之后，才进入真正的 root cause analysis 阶段。

在这一过程中，真实工程环境往往会引入额外复杂度，例如依赖缺失、构建失败或运行环境不一致。因此一个有效的 Code Agent 必须具备 environment self-repair 能力，例如自动安装依赖或修复运行环境。

最后，当动态调试路径受阻时，Agent还需要能够进行 strategy switching：从运行时调试转向静态代码分析，或者从局部测试转向整体结构推理。

---

1.5 Code Agent 的通用工作流

将这些策略组合起来，可以得到一个非常稳定的 Code Agent workflow：

Issue
↓
Codebase Localization
↓
Targeted Reading
↓
Bug Reproduction
↓
Root Cause Analysis
↓
Patch Generation
↓
Verification
↓
Patch Submission

这一流程实际上与人类工程师的调试流程高度一致，也解释了为什么高性能 Code Agent 的行为往往看起来“像工程师”。

---

1.6 Agent Training Insight

从训练角度看，这种能力很难通过简单的 prompt engineering 获得。更合理的解释是模型在训练中学习到了 软件工程轨迹（software engineering trajectories）。这些轨迹可能来自 GitHub bug-fix commits、真实开发者在 IDE 中的交互行为，以及模型在自生成环境中的调试轨迹。

在这种训练模式下，模型学习到的并不是单一的 patch 模式，而是一种 engineering policy distribution：在给定代码库和问题描述时，下一步最合理的工程行为是什么。

因此 Code Agent 的能力本质上并不等同于代码生成，而是 工程 workflow 的建模能力。

---

1.7 关键启示

SWE-bench 的成功案例表明，Code Agent 的核心能力并不是写代码，而是理解和执行软件工程流程。真正决定性能的能力包括代码库导航、最小上下文构建、问题复现、环境修复以及策略切换。

换句话说，未来 Code Agent 的研究重点可能不会继续集中在 prompt engineering 或单步代码生成，而是转向 engineering trajectory learning——也就是让模型学习工程师在真实系统中是如何调试问题的。

（b）从 SWE-bench 真实轨迹抽象 Agent 的工程策略原语

2.1 从案例到策略空间

上一节我们分析了一条 Claude-4.5-Opus 在 SWE-bench 中修复 astropy bug 的真实轨迹。表面上看，这只是一个具体问题的调试过程，但如果从 Agent 的角度观察，其实可以看到一个稳定的行为模式：模型并不是随意尝试修改代码，而是在执行一套高度结构化的软件工程 workflow。

这意味着 Code Agent 在解决问题时，实际上是在一个 工程策略空间（policy space） 中进行决策。每一步操作，例如搜索代码、阅读模块、复现 bug 或生成 patch，本质上都是在当前 repository 状态下选择一个最合理的工程动作。

换句话说，Code Agent 的能力可以理解为：π(action | repository_state)

其中 repository_state 包含代码库结构、当前上下文文件、运行错误信息以及任务描述，而 action 则对应软件工程中的操作行为。

通过分析真实轨迹，可以将这一策略空间拆解为若干 policy primitives。

---

2.2 Code Agent 的七个策略原语

在软件工程环境中，一个有效的 Code Agent 至少需要掌握七类基本策略。它们并不是独立模块，而是共同构成了一个完整的调试循环。

1. 首先是 Repository Navigation Policy。当 Agent 接收到一个 issue 描述时，首要任务是定位问题所在的代码区域。由于真实代码库往往包含成千上万行代码，盲目阅读是不现实的。因此 Agent必须通过关键字搜索、符号匹配或依赖关系分析来快速缩小搜索范围。这一策略的目标是将整个 repository 压缩为一个可分析的局部子空间。
2. 在定位模块之后，Agent进入 Context Construction Policy 阶段。此时任务不再是搜索，而是建立最小必要上下文。模型需要识别关键函数、数据结构以及模块之间的调用关系，从而形成对系统行为的基本理解。一个成熟的 Code Agent 不会扫描整个仓库，而是通过 targeted reading 构建局部语义图。
3. 接下来是 Bug Reproduction Policy。真实软件工程调试的核心原则是“先复现再修复”。Agent通常会构造最小脚本或测试用例，确认 issue 中描述的问题确实存在，并观察程序的实际行为。这一步的作用是将抽象问题转化为可观察的系统状态，从而为后续分析提供可靠信号。
4. 在复现问题之后，Agent进入 Root Cause Analysis Policy。这一阶段的目标是确定错误传播发生的位置，而不是简单地修改表面症状。模型需要分析代码逻辑、数据流以及模块组合方式，理解 bug 是如何从局部实现扩散到整体行为的。
5. 确定问题来源后，Agent执行 Patch Generation Policy。在这一阶段，模型根据已有上下文生成最小修改，使系统行为符合预期。与传统代码生成不同，这里的目标不是生成新代码，而是对现有系统进行局部修复。
6. 随后是 Verification Policy。任何 patch 都必须通过运行测试或执行验证脚本来确认其有效性。这一步确保修复不会引入新的错误，也验证原始 bug 是否真正解决。
7. 最后一个关键策略是 Environment Stabilization Policy。真实软件系统往往依赖复杂的构建环境和第三方库，因此调试过程中经常出现依赖缺失或构建失败的情况。Agent必须能够识别这些环境问题，并通过安装依赖或调整运行环境来恢复系统可执行状态。

---

2.3 Policy Interaction：策略之间的循环结构

这些策略并不是一次性执行，而是形成一个循环结构。一个典型的 Code Agent 调试过程通常呈现如下模式：

navigate repository
→ construct context
→ reproduce bug
→ analyze root cause
→ generate patch
→ verify result

如果验证失败，Agent会重新回到前面的阶段，例如重新分析问题或调整 patch。这种循环结构实际上与人类工程师的调试方式非常一致。

在更复杂的任务中，还可能出现 strategy switching。例如，当运行环境无法成功构建时，Agent可能从动态调试切换到静态代码分析；当上下文过大时，则可能重新执行 repository navigation 以缩小分析范围。

---

2.4 Code Agent 本质是 Policy Learning

从这个角度看，Code Agent 的核心能力并不是代码生成，而是 工程策略的学习（policy learning）。模型需要学会在复杂的软件系统中决定“下一步应该做什么”。

这也是为什么很多强大的 Code Agent 看起来像经验丰富的工程师。它们并不是在推理每一行代码，而是在执行一套已经学到的工程策略分布。

因此在训练层面，最有价值的数据并不是单独的 patch，而是完整的 software engineering trajectories。这些轨迹记录了开发者在解决问题时的行为序列，例如搜索代码、阅读文件、运行测试和修改实现。通过学习这些轨迹，模型可以逐渐形成稳定的工程策略。

---

2.5 对 Agentic RL 的启示

这种策略空间视角对 Agentic RL 的研究也具有重要启示。如果将 repository 和运行环境视为状态空间，那么 Code Agent 的任务实际上是一个长程决策问题。每一步工程操作都是一个 action，而测试是否通过则可以作为最终 reward。

然而由于 reward 信号极其稀疏，仅靠 RL 从头探索几乎不可行。因此更现实的训练方式是先通过 SFT 学习工程策略分布，再通过 RL 对策略进行优化和选择。这种训练范式与当前许多大型 Agent 系统的实际做法高度一致。

---

2.6 总结

从 SWE-bench 的真实案例可以看出，高性能 Code Agent 的能力来源于一套稳定的软件工程策略。通过分析这些轨迹，可以将 Agent 的行为抽象为若干 policy primitives，例如代码库导航、上下文构建、问题复现、根因分析、补丁生成和结果验证。

这种策略空间的视角揭示了 Code Agent 的本质：它们并不是简单的代码生成模型，而是能够在复杂软件系统中执行工程 workflow 的决策系统。