SWE-Together: 在交互式用户会话中评估编码智能体

TL;DR 首个基于真实用户会话的多轮交互式代码助理基准，用 LLM 用户模拟器重放意图与反馈，同时评估最终正确性和交互效率，更贴近实际协作体验。

问题

问题背景

Coding agent 的评估长期依赖静态基准（如 SWE-Bench、HumanEval）：智能体接收一次性完整任务描述，在无交互环境下提交代码，仅凭最终执行结果判定能力。

现有方法的局限

静态评估忽视真实用户协作中多轮交互的本质。开发者极少一次说清全部需求，而是逐渐澄清目标、追加约束、指出错误并迭代修正。现有基准的缺陷具体表现为：

• 任务设计脱离实际：静态 prompt 不包含中途方向调整或纠正性反馈，智能体无法展示对用户意图变更的适应性。
• 评估维度单一：仅关注最终代码或补丁的正确性，无法测量交互过程的质量——即使最终结果正确，若需要过多轮纠正或误解用户意图，实际体验仍然低效。

为什么这个问题难/重要

构建可复现的多轮交互编码基准面临双重挑战：

• 用户行为标准化：真实会话非结构化，直接录制无法作为可重放的任务。需要将离散的会话转化为保留原始意图、且能被不同智能体一致重演的交互协议。
• 交互效率量化：除正确性外，还需设计如纠正反馈轮数等过程指标，以区分智能体是“协作伙伴”还是“被动修补者”。

业界正在从“代码生成模型”转向“能协作的工程助手”，Google、OpenAI、Anthropic 的产品中均已深度集成编码智能体。能否用交互基准区分模型在真实协作中的表现，直接影响产品体验与用户采纳。

行业类比

类似对话系统评估从单轮问答（SQuAD）转向多轮任务导向对话（MultiWOZ），不再只看最终答案正确，更要衡量对话过程的简洁与连贯。

核心洞察

• 静态基准无法反映真实协作中的交互动态。传统编码基准（如 SWE-Bench）在开始时给出完整任务描述，仅凭最终提交的代码通过测试用例判断能力，忽略了用户在实际使用中逐步澄清需求、追加约束、纠正错误的多轮交互过程。SWE-Together 从真实用户-代理会话筛选出 109 个仓库级任务，保留了用户中途的意图变化与反馈需求，使得评估从“一次性提交”转变为“持续协作”，更贴近工程实践中人类与 AI 结队编程的真实体验。
• 用户模拟器实现了可重放、可比较的多轮评估，同时维持意图一致性。真实的多轮交互因人而异、不可复现，SWE-Together 构建了一个反应式 LLM 用户模拟器，它根据原会话中用户的显式目标与反馈模式，在代理进展受阻或偏离时给出纠正性反馈，保留了原始用户的意图。这让不同代理在相同交互轨迹下接受公平对比，既解决了真实会话的不可重复问题，也避免了完全人类评估的成本与主观性，为交互式基准的设计提供了新范式。

方法

从真实会话到多轮基准构建

SWE-Together 从 11,260 条真实用户与编程代理的交互记录出发，通过 会话→任务构建 流水线，最终生成 109 个仓库级任务，每个任务均保留原始用户意图和初始仓库快照。

输入与预处理

以录制会话的仓库状态、日志和对话历史为输入，执行三步筛选：

1. 确定性资格过滤：剔除仓库状态不可恢复、操作序列不完整或缺乏可验证输出的会话。
2. 可行性筛选：人工或自动确认用户目标清晰、初始环境可复现、最终结果可客观判断（如通过测试或编译）。
3. 任务构建：将选中的会话转化为标准化任务单元，包含 初始代码补丁、问题描述和可执行的测试用例，但不泄露最终解决方案。

关键模块：反应式用户模拟器

为使同一任务在不同代理间可重播，框架内置一个 基于 LLM 的用户模拟器。它并非简单复读历史消息，而是理解原始用户的意图，并根据代理的进展动态给出反馈：

• 当代理提交的代码离目标有偏差时，模拟器会生成类似真实用户的 纠正性指令、补充约束或澄清问题；
• 当代理行为已满足全部需求时，模拟器停止干预。

这样，每个任务都成为一段多轮协作过程，代理不仅要解决技术问题，还需处理“人类”反馈。

输出与评估指标

评估不在单一维度上打分，而是输出两个核心指标：

• 最终任务正确性：代理最终提交的仓库状态是否通过所有预设测试；
• 纠正反馈轮数：交互全程中代理需要用户介入的次数，越低说明协作越顺畅。

两个指标结合，既衡量“能否做对”，也衡量“需要多少人工干预才能做对”。

与同类方法的差异

传统基准（如 SWE-Bench）采用静态一次性评判：给代理完整任务描述，仅检查最终代码。SWE-Together 则在动态多轮交互中评估，不仅检验结果，还量化协作效率，更贴近现实开发中人与代理的迭代协作模式。

实验

实验设计

SWE-Together 基准从 11,260 个真实用户–代理编码会话中重构 109 个仓库级任务，每个任务都包含可恢复的仓库状态、清晰的用户目标和可观察的结果。为跨不同代理回放这些交互，构建了基于 LLM 的反应式用户模拟器，保留原始用户意图并在编码代理进展需要时提供反馈。评估指标包括：

• 最终仓库正确性（任务是否完成）
• 纠正性反馈轮次（交互效率）

实验涵盖了多个前沿编码代理。

关键发现

结果表明，更强的代理在 最终成功率 上更高，同时所需的 干预轮次 更少，这一趋势表明 协作体验 的提升。此外，对用户模拟器的 一致性分析 和 质量研究 验证了模拟器在复现用户意图和提供合理反馈方面的可靠性。

与静态基准的对比

传统静态基准（如 SWE-bench）仅评估最终代码正确性，忽略了交互过程中澄清、约束补充和错误纠正等真实协作场景。SWE-Together 通过多轮设置和纠错轮次指标，更深入地揭示了代理在实际工作流中的表现差异：即使最终成功率相近，代理的交互效率可能大相径庭。这为未来编码代理的研发提供了新的优化方向——不仅要“完成任务”，更要“减少用户负担”。

行业影响

落地场景

SWE-Together 的多轮交互评估范式可嵌入主流 AI 编码助手（如 GitHub Copilot、Amazon Q Developer、Cursor）的迭代管道，用于衡量助手在真实用户会话中的协作能力。此外，云 IDE 平台（如 Replit、Codespaces）可借此评估其内建 agent 处理仓库级多步任务的表现，而非仅凭单轮补全或一次性生成。DevOps 工具链中，代码审查 agent 和 自动修复 bot 也可采用该基准，检验其在持续对话中正确响应用户反馈的能力。

商业价值

该基准解决了静态评估无法反映的用户摩擦——反复修改和纠正的隐性成本。通过量化 每任务所需纠正轮次，企业可直接衡量用户体验的提升：更少的干预意味着更流畅的人机协作，有助于 降低开发者流失率 和 提高付费转化。对模型供应商而言，SWE-Together 提供了区分模型协作效率的细粒度指标，帮助在营销中突出“低摩擦交互”特性，支撑差异化定价。据论文，更强模型成功率更高且干预更少，直接关联用户感知的助理智能度，可转化为 净推荐值提升。

与现有产品/工作流接口

SWE-Together 作为开源基准（GitHub），可置于现有 CI 管道中，与 SWE-bench、BigCodeBench 等静态测试并列运行。其用户模拟器采用 LLM 回放真实意图，可集成到自动化回归测试，每当模型服务更新时触发，产出“交互效率”报告。实践中，工程团队可将该基准作为 模型选型的补充维度：例如在评估候选编码模型时，不仅看次数通过率，还看对话成本分数 (success_rate / avg_corrective_turns)，以平衡准确性与交互开销。

具体落地用例：

• 企业级 DevSecOps 平台（如 GitLab）可在其 CI/CD 管线的 Merge Request 环节，用 SWE-Together 评估内置的代码补全 agent 是否能在开发者给出“请修复 SQL 注入”等反馈后，一步到位修改代码，降少人工审查介入的轮数。
• 在线编程教育产品（如 Codecademy 的 AI 导师）需评估若学生反复指出“输出不对”“解释不清楚”，Agent 能否在有限步骤内给出正确解答。采用 SWE-Together 模拟多轮提问，可优化反馈策略，确保 AI 导师在真实辅导场景中不掉链子。

局限

• **任务规模与领域覆盖有限**：从 11,260 条真实会话中仅筛选出 109 个任务，数量较少，且源于特定工具记录的会话，可能偏向某些编程语言、项目类型或用户群体。这会影响基准的多样性，导致代理的评估结果未必能泛化到更广泛的开发生态。与 SWE-bench 等大规模静态基准相比，SWE-Together 的任务集较小，统计显著性可能不足。
• **用户模拟器的保真度瓶颈**：反应式 LLM 模拟器虽保留了原始用户意图，但基于 LLM 的反馈生成可能引入幻觉、风格偏差或对特定代理行为的非典型反应。模拟器本身的性能上限决定了代理评估的上限，若模拟器无法复现真实用户的中断、澄清或纠错模式，衡量出的“交互效率”指标会失真，且当前缺乏对模拟器行为的充分人类验证。
• **评估维度仅关注可量化的纠错轮次与最终正确性**：真实的交互体验还包括用户满意度、认知负荷、代理产物的可解释性等，但这些软性指标均未纳入。即使代理在较少轮次内完成任务，也可能因生成难以理解的代码或忽略用户隐含需求而导致不良体验。该基准无法评估代理作为协作伙伴的沟通质量，只捕捉了最粗粒度的交互成本。