当前位置：首页 > news >正文

Dialogue-SWEBench解读：Coding Agent真正缺的不是代码能力，而是会提问

news 2026/6/29 19:34:31

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 加上一份可审计的需求状态，以及一套克制但有效的提问策略。