[论文阅读] 人工智能 + 软件工程 | 探秘LLM软件代理：从黑箱决策到透明轨迹分析

探秘LLM软件代理：从黑箱决策到透明轨迹分析

论文信息

@article{bouzenia2025understanding,
  title={Understanding Software Engineering Agents: A Study of Thought-Action-Result Trajectories},
  author={Bouzenia, Islem and Pradel, Michael},
  journal={arXiv preprint arXiv:2506.18824},
  year={2025}
}

一段话总结

本文聚焦基于大语言模型（LLM）的软件工程师代理，对REPAIRAGENT、AUTOCODEROVER和OPENHANDS这三个前沿代理的120条“思维-行动-结果”轨迹及2822次LLM交互展开大规模实证研究。研究结合定量分析（结构特性、行动模式、token使用）与定性评估（推理连贯性、反馈整合），发现成功轨迹具备迭代次数与token消耗合理、行动序列多样且语义连贯等特征，失败轨迹则存在重复行动、缺乏适应性等反模式。该研究为改进代理设计（提示策略、故障诊断等）提供可行见解，并发布数据集与注释框架以支持后续研究。

研究背景：当AI修代码时，我们却看不懂它的"脑回路"

想象一下：你让一个AI代理修复代码中的bug，它忙活了半天却没修好。你想知道哪里出了问题，却发现它像个黑箱——只知道它调用了编译器、修改了代码，但不知道它为什么这么做，为什么失败。这就是当前LLM（大语言模型）驱动的软件代理面临的核心困境：决策过程不透明。

在软件工程领域，这类代理已能完成程序修复、问题解决等复杂任务。比如，RepairAgent能自动修复Defects4J中的835个bug，AutoCodeRover可处理SWEbench Lite的300个问题案例。但它们的内部推理就像人类大脑的潜意识——我们能看到结果，却难以追溯思维过程。

这种不透明性带来了实际问题：

• 故障诊断困难：代理反复尝试同一种无效修复时，我们无法判断是提示策略问题还是工具调用逻辑错误
• 设计优化受阻：不知道成功案例中"探索-测试-修复"的最佳迭代节奏
• 信任危机：当代理在关键系统中失败时，无法向开发者解释决策依据

就像医生需要通过医学影像理解人体内部状况，软件工程师也需要"影像工具"来解析代理的决策轨迹。这正是本文研究的起点：通过分析"思维-行动-结果"轨迹，揭开LLM代理的决策黑箱。

创新点：给AI代理装上"行车记录仪"

以往研究要么聚焦于LLM的单次预测解释（如突出代码关键位置），要么关注多代理系统的交互可视化。而本文的突破性创新在于：

1. 首次系统构建代理轨迹分析框架
   将RepairAgent、AutoCodeRover、OpenHands三个前沿代理的交互日志，统一转化为"思维-行动-结果"三元组序列。就像给代理装上"行车记录仪"，完整记录每一步推理、操作及反馈。

2. 混合方法揭示行为密码
   既用定量手段统计迭代次数、token消耗等指标，又通过定性分析标注思维连贯性。例如发现：

   • 成功轨迹中"探索-修复-测试"的平衡模式
   • 失败轨迹里"重复生成修复却不测试"的反模式

3. 跨代理对比发现设计奥秘
   Test-driven代理（如RepairAgent）虽更严谨但轨迹更长（平均34次迭代），而AutoCodeRover的"检索-定位-修复"流程更高效（仅6次迭代），揭示不同架构的适用场景。

研究方法和思路：拆解AI修代码的"心理活动"

1. 数据收集：打捞AI的"思考碎片"

从三个代理中随机抽取40条轨迹（总计120条），覆盖程序修复和问题解决任务。每条轨迹包含完整的迭代过程，如RepairAgent在修复Compress_13 bug时的38次尝试。

2. 轨迹解析：统一格式的"思维日记"

将不同代理的日志（JSON、半结构化文本）转换为标准格式：

迭代1:
- 思维："我需要检查foo函数的调用"
- 行动：搜索代码中foo的出现
- 结果：找到5处调用，其中3处在循环中

这种标准化让跨代理对比成为可能。

3. 定量分析：数清AI的"工作量"

• 轨迹长度：统计迭代次数，发现失败轨迹往往更长（如RepairAgent失败时平均40次迭代）
• token消耗：计算LLM调用成本，OpenHands成功轨迹消耗120万token，是AutoCodeRover的52倍

4. 行动分类：给AI的"动作"贴标签

将所有动作归为8大类，例如：

• 探索：浏览文件收集上下文
• 生成修复：提出代码修改方案
• 运行测试：验证修复有效性

5. 序列挖掘：寻找AI的"行为习惯"

分析4-gram动作序列，发现：

• 成功轨迹如"探索-解释-生成修复-测试"的循环
• 失败轨迹常见"生成修复-生成修复-生成修复"的重复模式

6. 语义标注：判断AI的"思路是否跑偏"

标注思维与行动的关系，如：

• 对齐：思维"需要测试修复"后执行测试动作
• 错位：思维要修复bug，却执行了文档阅读动作

主要贡献：让AI修代码更聪明的"操作手册"

1. 方法论突破：提供代理分析的"标准流程"

建立了"数据收集-轨迹解析-统计分析-模式挖掘-语义标注"的完整研究框架，就像给研究者提供了一套"代理解剖工具包"。

2. 实证发现：画出AI决策的"红绿灯地图"

• 成功密码：平衡探索（23%）、修复生成（20%）和测试（20%）的动作组合
• 失败陷阱：
  • 重复相同动作（如连续搜索却不利用结果）
  • 生成修复后不测试（OpenHands失败轨迹中常见）
  • 未经验证就终止任务（AutoCodeRover的设计局限）

3. 实践指导：给开发者的"调优指南"

• 提示策略：增加自我反思环节（如"我刚才的修复为什么失败"），减少思维-行动错位
• 架构选择：简单任务用AutoCodeRover的高效流程，复杂修复用RepairAgent的测试驱动模式
• 反模式检测：当出现连续3次相同动作时触发预警

4. 资源共享：开放研究的"基础设施"

发布包含120条轨迹、2822次交互的数据集及注释框架，相当于为领域研究者提供了"训练AI的模拟沙盘"。

思维导图

深入

一、研究背景与目标

1. LLM代理的应用与挑战：基于LLM的代理在代码补全、程序修复、测试用例生成等软件工程项目中应用日益广泛，但决策过程缺乏透明度，限制了对其工作机制和失败模式的理解。
2. 研究目标：通过分析“思维-行动-结果”轨迹，揭示代理的决策过程，为改进代理设计提供依据。

二、研究方法

1. 数据收集：从RepairAgent、AutoCodeRover和OpenHands三个代理获取120条轨迹，包含2822次LLM交互，覆盖程序修复和问题解决任务。
2. 轨迹解析：将原始日志统一为三元组格式，每个迭代包含思维（自然语言推理）、行动（工具调用）和结果（工具响应）。
3. 统计分析：计算轨迹长度、token消耗等指标，分析成功与失败轨迹的差异。
4. 行动分类：将行动分为探索、定位、生成修复等8个类别。
5. 序列模式挖掘：分析4-gram行动序列，识别成功与失败轨迹中的典型模式。
6. 语义关系标注：通过开放编码标注思维、行动和结果间的语义关系，如对齐、跟进、分歧等。

三、研究结果

1. RQ1：轨迹整体属性
   • 迭代次数：RepairAgent（平均34次）和OpenHands（平均29次）的失败轨迹更长，AutoCodeRover（平均6次）更高效。
   • token消耗：OpenHands（平均120万）消耗最多，AutoCodeRover（平均2.3万）最少，RepairAgent（平均22万）居中。
2. RQ2：行动及序列模式
   • 行动分布：生成修复（23%）、运行测试（20%）、解释（20%）和探索（18%）是最常见的行动。
   • 成功模式：平衡探索、解释、修复生成和测试，如RepairAgent的“探索-解释-生成修复-测试”循环。
   • 失败反模式：重复行动（如连续搜索）、生成修复后不测试、未经验证就终止任务。
3. RQ3：语义关系与连贯性
   • 思维-行动对齐：即使罕见的错位也与失败或高计算成本相关，如OpenHands失败轨迹中3.5%存在错位。
   • 结果利用：成功轨迹中结果能有效指导后续思维和行动，失败轨迹常误解结果或忽视其影响。

四、结论与贡献

1. 主要结论：成功轨迹平衡信息收集、假设测试和修复验证，失败轨迹表现出冗余探索或过早修复；不同代理的推理动态不同，如AutoCodeRover侧重“检索-定位-修复”，RepairAgent和OpenHands采用测试驱动方法。
2. 贡献
   • 提出基于轨迹的代理分析方法论。
   • 首次系统研究多个前沿代理的轨迹，揭示典型模式和挑战。
   • 为提示策略、故障诊断和反模式检测提供见解。
3. 数据可用性：数据集和注释框架将在论文发表后发布。

五、关键数据对比表

关键问题

1. 问题一：不同代理的轨迹长度和token消耗有何差异？
   • 答案：RepairAgent和OpenHands的轨迹更长，RepairAgent平均34次，OpenHands平均29次，失败轨迹更长（RepairAgent失败平均40次）；AutoCodeRover更高效，平均6次。token消耗方面，OpenHands最多（平均120万），AutoCodeRover最少（2.3万），RepairAgent居中（22万）。
2. 问题二：成功与失败轨迹的行动模式有何不同？
   • 答案：成功轨迹平衡探索、解释、修复生成和测试，如RepairAgent的“探索-解释-生成修复-测试”循环；失败轨迹表现出反模式，如重复相同行动（如连续搜索）、生成修复后不测试、未经验证就终止任务。
3. 问题三：语义关系对代理性能有何影响？
   • 答案：思维与行动的对齐至关重要，即使罕见的错位也与失败或高计算成本相关，如OpenHands失败轨迹中3.5%存在错位；成功轨迹中结果能有效指导后续思维和行动，失败轨迹常误解结果或忽视其影响。

总结：从黑箱到透明，AI代理进化的关键一步

本文通过大规模实证研究，首次系统剖析了LLM软件代理的决策轨迹。就像人类通过记录和分析驾驶数据来改进自动驾驶算法，该研究通过：

• 统一轨迹表示方法
• 发现成功/失败行为模式
• 建立语义连贯性评估体系

为提升代理可靠性指明了方向。未来，随着更多轨迹数据的积累，我们有望开发出"会反思、能调整"的智能代理，让AI真正成为可信赖的软件工程师伙伴。