论文信息

  • 论文：Requirement-Driven LLM Agents for Software Issue Resolution
  • 作者：Shiqi Kuang 等
  • 链接：https://arxiv.org/abs/2604.06861

核心问题：为什么现有 Coding Agent 做不好 issue resolution？

Issue resolution（基于 issue 描述自动生成 patch）是 Coding Agent 最核心的任务之一。但当前的 SOTA 方法（SWE-bench 上的那些）普遍面临一个尴尬：即使模型能力越来越强，resolve rate 始终上不去。

这篇论文指出一个被严重忽视的根因：issue 描述的质量问题。在真实项目中，issue 描述往往是残缺的——缺少关键上下文、包含模糊表述、甚至有误导性信息。直接把这种 raw input 喂给 LLM，就像让一个程序员看一份烂需求文档去改代码，产出质量可想而知。

REAgent 的核心方法：三阶段需求驱动框架

REAgent 的核心洞察是：在生成 patch 之前，先做一层需求工程。具体分三步：

阶段一：构建 Issue-Oriented Requirements

不是直接把 issue 描述丢给 LLM，而是先把它转化为结构化的「issue-oriented requirements」——一个包含目标、约束、上下文、预期行为等维度的 spec 文档。这和软件工程中「需求分析」阶段异曲同工：先搞清楚要解决什么，再动手写代码。

阶段二：低质量需求识别

自动检测 spec 中的低质量问题——比如关键上下文缺失、表述歧义、自相矛盾等。这不是一个简单的 checklist，而是需要对代码库和 issue 都有深入理解才能做出判断。REAgent 用 LLM 做这个判断，效果远好于规则系统。

阶段三：迭代修正 + Patch 生成

发现低质量问题后，REAgent 会自动从代码库中检索补充信息，迭代修正 spec，直到质量达标。然后用最终的 spec 指导 patch 生成。这个「先质量把关再执行」的模式，正是 Harness Engineering 中「环境设计」理念的具体落地。

关键数据

  • 3 个 benchmark 上测试，比 5 个 SOTA baseline 平均提升 17.4% resolve rate
  • 使用 2 个先进 LLM（Claude 和 GPT 系列）验证，效果一致——说明方法论本身有效，不依赖特定模型
  • 低质量需求识别准确率显著高于规则 baseline——LLM 做需求质量评审比人工规则靠谱

🔑 与 Harness Engineering 的关联

环境设计 vs 需求工程：同一种思维的不同表述

Harness Engineering 的核心原则之一是「环境设计」——不要给 Agent 原始的、未经处理的输入，而是精心设计输入的质量和结构。REAgent 做的事情完全一致：把粗糙的 issue 描述转化为结构化的 spec，等同于为 Agent 设计了一个更好的「工作环境」。

渐进式披露的需求质量把关

Harness Engineering 的「渐进式披露」强调分层次、有节奏地向 Agent 提供信息。REAgent 的「低质量需求识别 + 迭代修正」机制，本质上就是一种有质量门槛的渐进式披露——不合格的 spec 不会让 Agent 继续执行，必须先修正。

Golden Rule：结构化 spec 即 golden principle 的载体

Harness Engineering 强调将好的实践编码为 golden principle（黄金原则）。REAgent 的 structured spec 正是这种原则的具体载体——它不是模型学到的隐式知识，而是可以被审查、修改、传递的显式规则。

引发思考：需求工程会成为 Agent 的标准前置环节吗？

REAgent 的成功暗示了一个更深层的趋势：Coding Agent 的下一个工程化瓶颈可能不在 code generation，而在 input engineering。就像传统软件开发中「需求质量决定软件质量」一样，Agent 时代的「需求质量决定 patch 质量」。

如果这个趋势成立，我们可以预期：1) 更多 Agent 框架会内置「输入质量审查」模块；2) issue 模板的设计会成为一门显学（类似于 API design）；3) 传统的 SRS（软件需求规格说明）方法论可能以 Agent-friendly 的形式复兴。

逍遥云初 | 2026.04.09