[Paper] 迈向结构化、状态感知与执行为基础的推理用于软件工程代理

Source: arXiv - 2602.04640v1

（请提供需要翻译的正文内容，我将为您翻译成简体中文。）

概述

论文 Towards Structured, State-Aware, and Execution-Grounded Reasoning for Software Engineering Agents 认为，下一代由 AI 驱动的软件工程助手必须超越目前聊天工具中占主导地位的 “仅响应” 范式。通过为代理提供明确的内部结构、持久的系统状态概念以及包含真实执行反馈的循环，作者设想这些代理能够以更高的可靠性处理长期、多步骤的软件工程任务。

关键贡献

• 问题框架： 确认当前 SE 代理的根本限制——缺乏结构化、长期推理和状态管理。
• 三大设计支柱： 提出具体的三元组——(1) 显式结构（例如任务图、假设树），(2) 持久、演化的状态（跨回合存活的记忆模型），以及 (3) 基于执行的反馈（构建/测试/运行结果的紧密集成）。
• 概念架构： 勾勒出一个模块化流水线，将 推理、状态更新 和 执行 组件分离，使每个组件能够独立改进。
• 路线图与里程碑： 列出短期（状态感知提示、工具调用包装器）和长期（学习状态表示、自我调试循环）研究步骤。
• 面向行业的定位： 将提出的进展与实际开发者工作流相连接，如 CI/CD 流水线、缺陷分配和自动重构。

方法论

与其提供一个新数据集或基准，作者采用了 position‑paper methodology（立场论文方法）：

1. 文献综述： 调查现有的 SE 代理（例如 GitHub Copilot、基于 ChatGPT 的助手）及其响应式交互模式。
2. 失败案例分析： 对多步骤任务（例如修复失败的测试套件）进行定性检查，指出当前代理在失去上下文或给出相互矛盾的建议时的表现。
3. 设计抽象： 使用简单图示（任务图、状态存储、执行循环）形式化三大支柱，刻意保持技术无关性。
4. 路线图构建： 确定具体的研究“构建块”（状态感知提示、工具调用 API、基于执行信号的强化学习）以及分阶段的集成时间表。

该方法刻意保持高层次，以激发社区讨论并指导未来的实验工作。

结果与发现

• 反应式代理在超过 3 步的视野上会失效。 作者观察到，在三轮对话后，代理经常忘记先前的约束，导致代码建议不一致。
• 显式结构降低幻觉。 通过强制代理在代码生成前填充任务图，非正式测试中矛盾或超出范围的建议的可能性显著下降。
• 执行反馈显著提升正确性。 当允许代理运行单元测试并获取通过/失败信号时，它们可以迭代地完善补丁，在试点场景中实现接近人类的错误修复成功率。

这些观察支持了这样一种主张：具备状态感知和基于执行的循环对于实现稳健的软件工程辅助至关重要。

实际影响

• 更可靠的代码助手： 开发者可以依赖代理在调试会话中保持项目的“心理模型”，减少重复上下文的需求。
• 自动化 CI/CD 集成： 能够读取构建日志和测试结果的代理可以在现场提出修复建议，甚至在人工批准后自动合并简单补丁。
• 改进的入职工具： 新员工可以与保持代码库持久视图的代理互动，回答跨多个模块且不丢失上下文的问题。
• 自愈服务： 在生产环境中，代理可以监控日志，推断根本原因，并提出通过分阶段发布验证后再提交的代码更改。

对于开发者而言，直接的收获是未来的 SDK 和 API（例如 OpenAI 函数调用、LangChain 工具）可能会公开 状态管理原语 和 执行反馈钩子，你可以从今天开始进行实验。

限制与未来工作

• 尚未进行实证验证： 论文的论点基于轶事证据；需要大规模用户研究来量化收益。
• 状态表示的挑战： 设计一种既紧凑又具表达力、能够扩展到数百万行代码的内存格式仍是未解之题。
• 安全与安保： 持久化执行反馈（例如测试失败）会引发泄露专有信息或强化有害模式的担忧。
• 路线图执行： 作者勾勒了路线图，但承认要整合这三大支柱，需要在 LLM 提示、工具调用标准以及基于执行信号的强化学习方面实现协同进展。

未来的工作可能会侧重于构建体现这些理念的原型代理，在多步骤软件工程任务上进行基准测试，并制定安全状态处理的最佳实践指南。

作者

• Tse-Hsun
• Chen

论文信息

• arXiv ID: 2602.04640v1
• 分类: cs.SE, cs.AI
• 出版日期: 2026年2月4日
• PDF: 下载 PDF