2 相关工作
本研究位于多条研究脉络的交汇处。以下各小节依次讨论每条脉络：LLM 智能体的概念性分类法（Section 2.1）、编码智能体行为的实证研究（Section 2.2）、单个系统的架构描述（Section 2.3）以及基准测试驱动的评估（Section 2.4）。每条脉络从不同的视角审视编码智能体，但没有任何一条在源代码层面对其脚手架架构进行了比较性考察。
2.1 LLM 智能体架构综述
一批日益增长的综述工作按照抽象能力来组织基于 LLM 的智能体。[^35] 提出了一个五组件参考模型（推理、规划、工具使用、记忆、反思），并对单智能体和多智能体设计中的交互模式进行了分类。[^37] 提出了一种基于能力的分类法（使用工具、记忆增强、规划、多智能体、具身），立足于经典智能体理论，认为可靠性是一种架构属性而非仅仅是模型质量的函数。这一论断与本研究的前提相呼应；本文所提供的源代码分析为 Nowaczyk 等人概念性论证所隐含但未提供的内容补充了实现层面的证据，将架构与可靠性之间的关系扎根于具体的脚手架设计选择而非抽象的能力类别中。更广泛的 LLM 软件工程应用综述将编码智能体作为诸多类别之一加以涵盖 [^61]。这些分类法提供了有用的概念词汇，但它们所运作的抽象层次无法区分不同的生产级编码智能体。本研究语料库中的每一个智能体在这些方案下都符合"使用工具、记忆增强、具备规划"的分类，然而它们的脚手架架构在影响成本、可靠性和失败模式的层面上存在差异。一个使用蒙特卡洛树搜索来探索候选补丁的编码智能体与一个使用简单 while 循环配合测试驱动重试的编码智能体，在基于能力的分类下无法区分，尽管二者在控制流、状态管理和资源消耗方面存在根本性差异。一条相关的研究线索考察 LLM 如何在模型层面学习使用工具（工具调用训练、函数调用微调）[^47] [^42]；这与本研究所探讨的问题互补，因为本研究考察的是脚手架代码如何暴露和编排工具，而非模型如何学习调用工具。
许多概念类别所依赖的提示范式已被独立形式化。[^58] 提出了 ReAct 范式，其中 LLM 在思考-动作-观察循环中交替生成推理轨迹和任务特定的动作；本研究中 13 个智能体中有 7 个使用顺序 ReAct 循环作为主要控制结构（Table 2），还有若干智能体在更大工作流的各阶段中嵌入了类 ReAct 的迭代。[^48] 形式化了 Reflexion，一种言语强化学习框架，其中智能体对失败的尝试进行反思并将反思结果存储在情景记忆缓冲区中以供后续重试；这一模式是本语料库中观察到的生成-测试-修复循环原语的基础（Section 4.1.1）。然而，ReAct 和 Reflexion 描述的都是算法范式，而非脚手架架构。从"交替思考与动作"到一个包含工具注册、上下文压缩、多模型路由和持久化状态的生产实现之间的鸿沟，正是本研究所记录的内容。
2.2 编码智能体轨迹与行为研究
一条互补的研究线索通过分析编码智能体在运行时的执行轨迹来研究其行为。[^14] 收集了五个智能体在 SWE-bench Verified 上运行的完整执行轨迹，将其归一化为统一的动作模式，并提取出"决策路径"分类法：反复出现的行为模式，如探索优先、补丁优先和测试驱动策略。他们发现缺陷定位是主要瓶颈，早期测试生成与成功率存在强相关性。[^34] 分析了 OpenHands、SWE-agent 和 Prometheus [^41] 的轨迹日志，报告了失败轨迹比成功轨迹长 12–82%，且代码仓库导航在智能体活动中的占比超过补丁编写。[^9] 研究了三个智能体（RepairAgent [^8]、AutoCodeRover、OpenHands）的思考-动作-结果轨迹，发现即便罕见的思考-动作错位（占步骤的 0.5–4.8%）也与失败强相关，且失败轨迹表现出重复的、非适应性的动作循环。
这些研究建立了重要的实证规律，但存在两个局限性，本研究对此进行了回应。第一，这些研究将智能体视为黑箱：它们观察智能体做了什么，但无法解释为什么。诸如"轨迹较短的智能体更频繁地成功"这样的发现无法区分以下情形：一个脚手架强制提前终止，一个实现了高效的搜索启发式方法，还是一个仅仅设置了较低的迭代预算。第二，此前的轨迹研究为不同的智能体使用了不同的 LLM [^34] [^9]，将脚手架效应与模型效应混淆在一起；例如，Majgaonkar 等人将基于 Claude 3.5 Sonnet 的 OpenHands 轨迹与基于 DeepSeek-V3 的 Prometheus 轨迹进行比较，导致无法判断行为差异究竟源于脚手架还是模型。本文提出的架构分类法提供了缺失的解释层：通过检视产生那些轨迹的脚手架源代码，可以将行为差异归因于具体的设计选择，而非不透明的系统级差异。
[^18] 从行为分析转向资源导向的分析，测量了五个脚手架在三个 LLM 上的 Token 消耗、成本和计算时间。他们发现的"Token 雪球效应"（由于朴素的对话历史累积，输入 Token 随 API 调用线性增长）和"昂贵的失败"（失败尝试消耗的资源高达成功尝试的 4 ×）是实证现象，本研究可以从架构层面加以解释：Token 雪球效应对应上下文压缩维度（Section 4.3.2），昂贵的失败则与错误恢复和终止策略相关。然而，SWE-Effi 并未检视产生这些成本模式的脚手架代码；其唯一的架构区分是"智能体式"与"程序式"。
2.3 单个系统描述
若干编码智能体已有详细的架构描述，这些描述综合表明脚手架设计选择显著影响智能体行为。一些论文聚焦于工具与环境接口如何塑造智能体能力：[^57] 为 SWE-agent 引入了智能体-计算机接口（ACI）概念，表明设计定制的 shell 命令来组织代码仓库交互本身就是一项影响下游性能的架构决策；[^23] 描述了 Aider 中通过 PageRank 进行的代码仓库映射以及针对特定模型的编辑格式选择；[^13] 描述了一种四层终端智能体架构，包含双智能体设计、多模型路由、延迟工具发现和自适应上下文压缩，并得出结论"工具可靠性比模型能力更重要"。
其他系统论文揭示了智能体自主性的频谱。在一端，[^54] 认为对于许多任务而言，智能体式的脚手架并非必要，证明了由定位、修复和重排序阶段组成的固定流水线可以在 SWE-bench 上与智能体方法持平甚至超越后者；这为本分类法中的流水线到智能体频谱提供了动机。在另一端，[^2] 在 DARS-Agent 中提出了带有基于 LLM 的分支选择的树结构搜索，[^6] 在 MASAI 中将智能体分解为针对不同子任务的专用子智能体。在这两个极端之间，[^62] 描述了 AutoCodeRover 中基于抽象语法树 (AST) 的上下文检索配合基于频谱的故障定位 (SBFL)，[^52] 描述了 OpenHands 底层的事件溯源架构和智能体委托机制。这些论文各自为单个系统提供了架构深度，但设计空间整体仍未被梳理：实践者若不独立阅读十余个代码库，便无法比较控制循环策略、工具接口设计或上下文管理方法。本研究将这种针对单个系统的深度分析扩展到 13 个智能体，实现了单独描述所无法提供的比较分析。
一条相关但正交的研究线索考察开发者如何配置编码智能体。[^21] 分析了 2,926 个 GitHub 仓库以表征五种商业编码工具的配置制品（指令文件、提示模板、Skills 定义、结构化配置），发现配置实践仍然碎片化，Skills 和子智能体配置等高级功能鲜有使用。该工作与本研究互补：配置制品控制智能体接收到的指令，而脚手架架构决定智能体如何处理这些指令。一个指定"提交前务必运行测试"的 CLAUDE.md 文件是面向开发者的配置；实现该指令的脚手架生成-测试-修复循环则是架构特征。本研究分析的是后者。
2.4 编码智能体评估与基准测试
SWE-bench [^27] 已成为编码智能体事实上的评估标准，推动了快速进展并驱动了本研究语料库中许多智能体的设计。然而，其局限性已被越来越多地记录在案：过于详细的问题描述抬高了解决率 [^22]，单一语言偏差限制了泛化能力 [^27] [^55]，脚手架与模型效应的混淆使得将性能归因于架构选择变得困难 [^18]。较新的基准测试部分解决了这些问题：SWE-bench Pro [^17] 引入了更难的多文件任务并具有抗污染能力，SWE-Compass [^55] 将评估扩展到八种编程语言和多种任务类型。[^15] 在最小脚手架下检验了智能体生成的测试是否能提升解决率，发现增加或移除测试的提示干预最多改变 2.6 个百分点的结果；这表明脚手架层面的测试编排（lint-测试循环、测试门控重试、MCTS 奖励信号）——而非模型原生的测试编写行为——可能才是架构层面的相关变量。
本研究刻意不进行智能体性能的基准测试，因为基准测试分数混淆了脚手架架构与模型能力、提示工程以及偶然的配置选择（迭代次数限制、成本上限、默认模型选择）；隔离脚手架的贡献需要的是本文所呈现的这种架构分析，而非额外的基准测试运行。然而，该分类法确实为未来的受控实验提供了条件，通过识别需要保持恒定的具体变量：例如，比较拥有相同工具集但使用不同循环策略的智能体，或相同循环但不同压缩策略的智能体，同时保持模型一致（Section 5.5）。
[^50] 明确呼吁建立架构感知的评估指标，将智能体内部组件（规划器、记忆、工具路由器）与可观察结果关联起来，并提出了一个组件到指标的映射框架。然而，他们的提议是概念性的：尚未在真实系统上进行验证，且依赖于在本研究之前大多数编码智能体所不具备的架构文档。本分类法提供了此类评估框架所需要的架构词汇。