Dialogue-SWEBench解读Coding Agent真正缺的不是代码能力而是会提问摘要Coding Agent 的主流评测通常给出一份相对完整的问题描述让系统独立探索仓库、修改代码并提交补丁。但真实研发并不是这样的Issue 经常缺少复现条件、边界行为和验收标准工程师必须在对话中逐步澄清需求。2026 年 6 月发布的 Dialogue-SWEBench 将 SWE-Bench Verified 的 500 个任务改造成多轮对话评测并引入带用户画像、自我修正机制的模拟用户。论文结果显示结构化引导 Agent 维护“已知、未知、待确认”的需求状态平均任务解决率可达 46.9%高于通用 OpenHands 的 32.9% 和交互基线的 44.1%。这项工作提醒研发团队Coding Agent 的工业化评估不能只看补丁通过率还要衡量它是否知道什么时候应该停下来问一个好问题。背景完整需求其实是评测中的理想条件传统 SWE-Bench 类评测的流程很直接给 Agent 仓库和完整问题说明允许它读文件、编辑代码、运行测试最后用执行测试判断补丁是否解决问题。这种设计适合稳定比较系统能力却隐含了一个很强的前提任务描述已经完整、正确且足以直接编码。真实项目恰好相反。论文引用的研究指出构成 SWE-Bench 的真实 GitHub Issues 中76% 至少存在一定程度的信息不足39% 模糊到难以判断成功方案应该是什么。另一项真实 Agent 使用研究则发现用户有 44% 的对话是在纠正或拒绝 Agent 的输出而 Agent 主动寻求澄清的比例仅为 1% 至 2%。这意味着当前系统常见的失败并不只是“不会写”还包括过早假设、没有识别未知条件以及在错误需求上高效实现。模型越强如果越自信地补全缺失信息损失反而可能越大。技术要点一把仓库任务改造成真正的多轮协作Dialogue-SWEBench 基于 SWE-Bench Verified 的 500 个任务构建。每个任务不再把完整 Issue 一次性交给 Agent而是只提供一个忠于原始意图、但刻意省略关键细节的初始请求。Agent 的动作空间除了文件编辑、终端执行和结束任务还增加了 message_user用于向用户追问。模拟用户掌握完整 Issue 中的信息但不掌握标准补丁和测试答案也不能假装自己运行了代码。系统先根据当前对话和用户画像生成回复再执行一次自我检查与修正过滤幻觉、越权能力声明和不符合长度要求的回答。人工评估显示加入自我修正后97.5% 的完整对话在忠实性、目标一致性和环境约束三个维度上均无缺陷移除该步骤时只有 82.5%。这种设计的价值不只是节省真人评测成本更重要的是让“是否正确利用用户信息”变成可重复实验的变量。技术要点二用需求 Schema 管理未知信息论文提出的 Schema-guided Agent 不依赖预定义的固定表单而是先判断问题类型再动态生成解决该问题所需的字段。例如一个缺陷任务可能包含实际行为与预期行为最小复现步骤输入、输出和异常语义兼容性要求不允许改变的既有行为验收方式与测试范围。尚未获得的信息被显式标记为 UNKNOWN。Agent 在阅读代码、修改实现和验证结果的过程中持续更新这份状态只对会改变实现方向的信息发问。在四种模型的平均结果上通用 OpenHands 的解决率为 32.9%面向歧义消解的交互基线为 44.1%Schema-guided Agent 达到 46.9%同时平均成本最低。对 GPT-5-mini解决率从通用框架的 34.3% 提升至 58.8%对 GPT-5则从 47.5% 提升至 58.0%。这说明 Agent 外层的对话状态管理可以带来与更换模型同等级别的收益。技术要点三会提问不等于不停提问论文发现表现最好的 Agent 通常会产生更多“信息寻求型”对话动作通用 Agent 很少主动索取信息也解决了最少的任务。但相关性不能简单解释为“问题越多越好”。一个案例中较大的模型针对简单问题提出了很长的问题清单用户只回答其中两项。Agent 随后没有继续追踪真正影响异常语义的未答问题而是直接实现了错误行为。相反较小模型只问两个清晰问题完成了更有效的闭环。实验中 GPT-5-mini 的对话自然度与连贯性也优于 GPT-5且以更低成本取得相近结果。工程上更合理的策略是给问题设置价值函数如果不同答案会导致不同 API、数据结构、错误处理或兼容方案就应先问如果可以从代码、测试或文档直接验证就应自己查如果只是偏好差异且可逆则采用保守默认值并明确记录。研发视角评测对象应从模型变成协作系统对于企业内部 Coding Agent单一的“测试是否全绿”不足以判断可用性。至少应同时观察以下指标任务解决率最终补丁是否通过执行测试。澄清收益加入用户回复后解决率相对单轮模式提升多少。有效问题率问题是否针对实现分叉点而不是重复索取已有信息。未知项闭环率关键 UNKNOWN 是否在编码前得到确认或验证。用户负担每个任务的提问轮次、问题长度和重复率。对话质量交流是否自然、局部连贯并能在完成后正确收尾。成本与时延多轮交互增加的 Token、工具调用和等待时间。论文的消融实验尤其值得注意只保留首轮请求、禁止后续用户回复后四种模型的解决率分别下降 10 至 28 个百分点。这直接说明对话不是界面层装饰而是任务成功所依赖的工程能力。实践建议如何改造现有 Coding Agent第一在 Agent 状态中增加需求账本。将事实、假设、约束、未知项、验收条件分开保存并要求每次重大实现决策引用对应依据。第二为追问设置触发器。遇到不可逆迁移、公开 API 变化、安全边界、异常语义或多个同样合理的产品行为时必须澄清普通实现细节优先通过仓库搜索和测试获取。第三采用“一轮少量高价值问题”。把问题按阻塞程度排序每轮只问一到三个并解释为什么答案会影响方案。长问卷看似全面实际会增加用户跳答和 Agent 漏追问的概率。第四把对话纳入回归集。保存初始请求、用户回答、Agent 的需求状态、最终补丁与测试结果。版本升级时不仅比较通过率还检查问题数量、澄清后的增益和用户负担是否退化。第五允许 Agent 明确表达不确定性。一个能够说“这里存在两种兼容语义需要你确认”的系统通常比默默选择一种实现的系统更可靠。风险与限制Dialogue-SWEBench 仍有明显边界。它继承了 SWE-Bench Verified 的数据分布任务偏向 Python 仓库和特定 Issue 类型不能代表移动端、嵌入式、数据工程或大型跨服务变更。模拟用户虽然经过人工验证但仍不是拥有组织背景、隐性偏好和时间压力的真实工程师。此外论文中的自然度与连贯性主要由 LLM-as-a-Judge 自动评估。其与人工标注在自然度上的一致性较高但连贯性的一致性仅为中等水平。因此这些分数适合比较系统趋势不应直接当作用户满意度。最后更多对话会引入等待、成本和上下文污染。生产系统需要在自主探索与请求人工输入之间设定清晰边界而不是把每个未知项都升级为中断。结语Coding Agent 的下一阶段竞争不只是让模型生成更大的补丁而是让整个系统理解哪些信息已经确定哪些可以通过工具验证哪些必须由人做决定。Dialogue-SWEBench 给出了一个重要方向——把澄清、协商和闭环纳入软件工程评测。对研发团队而言最现实的起点并非更换模型而是给现有 Agent 加上一份可审计的需求状态以及一套克制但有效的提问策略。参考来源Dialogue-SWEBench 论文摘要https://arxiv.org/abs/2606.13995Dialogue-SWEBench HTML 全文https://arxiv.org/html/2606.13995