Agent为什么会失败？这篇arXiv论文比榜单分数更值得研发看

Agent为什么会失败这篇arXiv论文比榜单分数更值得研发看摘要很多团队评估软件工程 Agent 时第一反应是看榜单SWE-Bench 通过率多少、修了几个 issue、生成 patch 是否通过测试。但 arXiv 论文《Understanding Software Engineering Agents: A Study of Thought-Action-Result Trajectories》提醒我们只看最终分数会漏掉真正影响生产可靠性的东西。这篇论文研究了 RepairAgent、AutoCodeRover 和 OpenHands 三类软件工程 Agent将它们的日志统一成 thought-action-result 轨迹覆盖 120 条执行轨迹和 2822 次 LLM 交互。它关心的不是“哪个模型最强”而是 Agent 在修复程序和解决 issue 时到底如何思考、如何调用工具、如何利用反馈以及为什么失败。背景通过率无法解释失败原因软件工程 Agent 的任务通常很长。它要理解 issue、浏览代码、定位文件、修改实现、运行测试、解释错误再继续迭代。最终结果可以被压缩成成功或失败但中间过程包含大量有价值的信息。如果一个 Agent 失败了仅看最终 patch 不通过很难知道问题在哪里。它可能一开始就找错文件也可能理解对了但测试跑错了还可能收到错误信息后没有调整策略反复执行同一个无效动作。这就是论文选择 trajectory analysis 的原因。所谓 thought-action-result就是把每一步拆成三类信号Agent 的自然语言思考、它执行的动作、动作返回的结果。对研发团队来说这相当于给 Agent 加上可观测性而不是只看最后一次提交。技术要点一失败轨迹通常更长、更耗token论文的第一个观察是失败轨迹往往不只是“没做对”还会消耗更多迭代和 token。尤其是测试驱动的修复 Agent例如 RepairAgent 和 OpenHands在失败任务中可能进入更长、更昂贵的循环。这个现象对工程平台很重要。很多团队把 Agent 成本理解成一次模型调用成本但真实成本来自迭代链路。一次失败可能包含多轮代码读取、命令执行、错误解释、补丁生成和测试重跑。如果没有预算和中止策略Agent 会在低质量循环里持续烧钱。因此生产环境不能只设置总超时还应该监控轨迹形态连续失败测试次数、重复动作比例、无新增信息的观察次数、相同文件反复读取次数。这些指标比总 token 更早暴露问题。技术要点二成功不是多试几次而是会调整策略论文分析了动作序列发现成功轨迹通常能在探索、解释、修复和测试之间保持平衡。Agent 会先收集上下文再形成假设生成修改并用测试反馈验证。失败轨迹则更容易出现反模式。例如重复执行相同动作没有根据结果调整下一步或者直接生成修复却缺少中间测试又或者反复查看无关文件导致上下文越来越噪声化。这说明“让 Agent 多跑几轮”不是可靠性方案。更多迭代只有在反馈被正确吸收时才有价值。否则迭代只是把一次错误扩展成更贵的错误。技术要点三思考、动作、结果必须语义对齐论文特别强调 reasoning coherence也就是 thought、action 和 result 之间的语义连贯性。简单说Agent 想做什么、实际做了什么、看到了什么结果三者必须对得上。例如Agent 在 thought 中说要检查测试失败原因但 action 却去改无关模块或者 result 明确提示某个函数不存在但下一步 thought 没有吸收这个事实。这类错位可能不频繁却会显著增加失败风险和计算成本。这对 Agent 平台设计很有启发。我们不能只记录工具调用日志还要记录“为什么调用这个工具”。更进一步可以在关键步骤加入自检当前动作是否服务于上一条推理目标工具结果是否改变了计划如果没有就应该触发反思或停止。技术要点四不同Agent架构有不同失败模式论文覆盖的三个 Agent 并不是同一种架构。RepairAgent、AutoCodeRover、OpenHands 在工作流、工具使用和状态推进方式上不同因此失败模式也不同。AutoCodeRover 的 retrieve-locate-fix 流程更紧凑token 消耗相对更可控而更灵活的状态机式 Agent 可以回到前面步骤继续探索但也更容易出现长循环。换句话说灵活性和可控性之间存在真实取舍。研发团队在选型时不应该只问“哪个 Agent 更强”而应该问我们的场景更需要严格流程还是需要开放探索如果是企业 CI 修复可能需要更强约束如果是复杂重构或未知问题诊断可能需要更灵活的探索能力。研发视角给Agent加一套轨迹观测系统这篇论文最值得落地的地方是它把 Agent 可靠性问题变成可观测问题。对工程团队来说可以把每次 Agent 执行记录成结构化轨迹。最低限度应记录五类字段当前 thought 摘要、动作类型、动作参数、工具返回、下一步决策。再往上可以加动作类别、涉及文件、测试结果、错误类型、token 消耗和耗时。有了这些数据团队才能做真正的失败分析。例如失败任务是否集中在定位阶段是否有大量重复读取是否经常生成 patch 后不运行测试是否在测试失败后继续改无关文件这些问题比“模型不够强”更具体也更可改。实践建议从反模式检测开始如果你正在建设软件工程 Agent可以先做几个低成本规则连续两次执行相同命令且结果相同触发策略反思。生成补丁后必须运行最小相关测试不能直接继续大改。读取文件超过一定数量但没有形成修复假设要求收敛计划。测试失败信息必须被摘要并引用到下一步 thought 中。相同错误连续出现时禁止只做局部微调要求回到定位阶段。每次工具调用都记录目标便于审查动作是否服务于计划。对长轨迹设置 token 和时间预算并给出中止原因。这些规则不需要新模型却能显著提高 Agent 可诊断性。真正的工程收益往往来自减少无效循环而不是把模型换成更贵版本。风险与限制这篇论文研究的是三类特定软件工程 Agent任务集中在程序修复和 issue resolution。它的结论不能直接等同于所有 Agent 场景例如数据分析、前端生成或运维诊断。但它提供的方法论很有迁移价值把 Agent 执行过程拆成可分析轨迹再比较成功与失败之间的结构差异。另外轨迹记录本身也会带来成本和隐私问题。企业代码、错误日志和推理摘要可能包含敏感信息。落地时要明确日志脱敏、访问权限和留存周期。结语软件工程 Agent 的下一阶段不是只卷榜单分数而是卷可观测、可诊断、可控。通过率告诉你结果轨迹告诉你原因。《Understanding Software Engineering Agents》这篇论文的价值就在这里它让我们看到 Agent 失败并非黑盒魔法而是可以从 thought-action-result 里识别出重复动作、反馈忽略、语义错位和长循环。研发团队要把 Agent 真正放进生产流程就必须先能看清它怎么失败。参考来源arXiv: Understanding Software Engineering Agents: A Study of Thought-Action-Result Trajectorieshttps://arxiv.org/abs/2506.18824