编码智能体评测，不能只盯着最终修复结果

导语

编码智能体的评测，长期以来往往围绕一个清晰的问题展开：它能否根据 issue 修改代码，并通过测试。这样的设置便于比较模型，却未必符合开发者真正使用智能体的方式。Hugging Face Daily Papers 收录的一项研究提出，评测的关键不只是任务答案，还包括任务是如何在对话中展开的。

真实开发会话比单一 issue 更复杂

研究者收集了 4782 次软件工程师在 JetBrains IDE 中使用智能体的会话，并将其称为 Production Sessions。由于研究对象是交互式智能体，研究重点放在至少包含三条用户消息的长会话上，这部分约占样本的三分之一。

这些会话与传统 issue 驱动的基准存在两项明显差异：

• 用户请求类型更丰富，除了直接修改代码，还包括询问项目代码、制定计划、代码审查、重构和执行操作等；
• 用户不会始终围绕同一种任务推进，而是会在不同类型之间切换，例如先了解代码，再要求制定方案，随后进行修改和验证。

研究还比较了三个公开交互语料库中的长会话，发现它们在会话长度、任务类型分布以及任务类型之间的转移关系上都存在明显差异。这意味着不存在一个对所有场景都“真实”的统一交互分布。基准首先需要说明自己要模拟的是哪类用户和工作流，再根据相应测量结果进行校准。

SWE-TaskFlow 如何调整现有基准

为此，论文提出 SWE-TaskFlow。它并不放弃 issue 基准中已经验证过的任务和测试，而是通过拆分用户提示、加入可验证的仓库问答，引导智能体按照目标 Task Flow 展开交互。研究者还提出 TaskFlow Alignment Score，用于从生成的多条交互轨迹中选择更符合目标流程的方案。

这一思路的重点，是把“任务是否解决”和“解决过程是否符合目标使用场景”分开评估。前者仍由代码变更及测试验证，后者则关注会话长度、任务构成和任务切换。

成本本身也是评测结果

在针对 700 个 SWE-Bench Pro 任务的试验中，将一个任务拆成多个连续步骤，大约会使智能体成本翻倍，但解决率没有出现稳定变化。这个结果并不意味着多轮交互没有价值，而是说明交互协议会直接影响资源消耗，却未必自动带来更高的通过率。

对模型开发者而言，这提示评测报告不能只公布 pass rate，也应交代采用了怎样的提示组织方式、交互轮次和成本。对基准设计者而言，未来更值得比较的可能不是单一总分，而是针对明确目标工作流的成功率、成本和轨迹质量。编码智能体最终服务的是开发过程，而不仅是一道孤立的修复题。

来源：Hugging Face Daily Papers