TestPrism:重新思考超越单一参考实现的测试评估
LLM 编码智能体生成的测试通常只对照单一参考解评估,会高估测试质量。TestPrism 包含来自 17 个来源的 300 个测试任务和 3000 个候选实现,其 Joint Success Function 指标要求测试在初始程序状态失败、接受所有有效实现并拒绝所有无效实现,14 种基线配置下仅达 28.00%,而单一参考成功率高达 59.67%。
LLM 编码智能体生成的测试通常只对照单一参考解评估,会高估测试质量。TestPrism 包含来自 17 个来源的 300 个测试任务和 3000 个候选实现,其 Joint Success Function 指标要求测试在初始程序状态失败、接受所有有效实现并拒绝所有无效实现,14 种基线配置下仅达 28.00%,而单一参考成功率高达 59.67%。
ParanoiaEval 是首个统一评测编程智能体风险处理能力的基准,基于软件工程风险管理的 Avoidance-Transfer-Mitigation-Acceptance 框架,包含 200 个证据受控的仓库级任务对。在 8 个代表性模型上的实验显示,即便有明确证据,仍有 11.2%-58.7% 的运行出现不必要的风险处理,且更强的任务能力并不保证更恰当的风险处理。
VISTA 是面向编码智能体的端到端基准,可将多页设计稿(Figma 渲染、结构与文本需求)转化为可运行的全栈 Web 和 Android 应用。
研究者推出 SWE-Journey 基准,用于更真实地评测 Claude Code、Codex 等编程助手。该基准通过弱到强合成流程自动构建长周期编程任务,并从真实交互数据中挖掘四类用户画像、构建用户模拟智能体来复现多轮交互。结果显示,面对软件架构师角色模型平均通过超 75% 的功能测试,而面对非程序员角色时通过率不足 25%。
首个聚焦 LLM 辅助二进制到源代码恢复的 SoK 研究发布,提出以设计为中心的分类体系,并在 45,000 个测试样本上系统评估现有方法。样本覆盖四种标准架构与五种嵌入式架构、五种优化级别及符号剥离,从六个评估维度、七项关键指标展开。研究还消融了输入表示、上下文增强、模型规模、迭代与审查角色等设计选择的影响,并测试了四种成熟语言与两种遗留语言的同语言及跨语言恢复能力。
针对 LLM 生成 Three.js 体素世界缺乏可靠自动评分的问题,研究者提出 WorldBench 基准与评判器,它同时探索运行中的世界并读取代码,且不单独信任任一通道。
针对 LLM 编码智能体测试评估仅依赖单一参考解的问题,研究者推出 TestPrism,包含来自 17 个来源的 300 个测试任务和 3000 个候选实现,有效与无效解各占一半。
论文提出 Cadence,一个根据编码智能体实时执行状态自适应安排检查并给出指导的动态监控框架,包含两级干预模块和检查调度器。
研究者提出一个仅凭源码和输入预测程序最终输出与检查点状态的基准,包含来自 371 个 Python 和 C++ 程序的 400 个案例,在四个模型系列的七种设置下评估。
一项研究将 LLM 生成的回归测试应用于 SciPy、Qiskit 和 pandas 的 145 个已合并 PR,发现 8%-17% 的生成测试属于固化缺陷的 fault-enforcing 测试,而只有 2.4%-4.8% 能揭示缺陷。
研究者发布 PolyCodeEval,一个覆盖函数到仓库粒度的多语言代码生成基准,包含来自 5 种编程语言、58 个真实可执行开源仓库的 2,590 个任务,并采用统一执行协议评测。评测显示现有方法生成正确函数、文件、仓库的比例最高仅为 71.7%、76.7% 和 31.0%,且性能随语言差异明显。配对实验还表明,同文件相关函数的实现上下文能提升函数生成的可执行正确率。
论文提出 RucTangle,首个在拆分编程智能体生成的大型混合补丁时保证每次提交后代码仍可运行的智能体方法,并配套 TangleEval 评估框架量化拆分后的提交历史对智能体修 bug 的帮助。
Chronos 是一个测试时框架,将已合并的 pull request 蒸馏为结构化经验卡片,并通过代码层、开发者意图和组织关系的类型化图连接起来,供基于 LLM 的代码智能体使用。
研究者提出一套面向嵌入式编码智能体的闭环评测基准,包含五个嵌入式控制任务和四种反馈场景(一次性生成、真实自验证、CI 式红绿反馈、oracle 式详细反馈),实现目标为可复现的模拟 ESP32 固件。团队评测了 GPT 系列与 Qwen 系列的七种配置,共 420 次运行,gpt-5.4 通过率最高但未饱和基准,qwen3.5-27B 是表现最强的本地模型,较小的本地模型通过率与搜索效率明显下降。
一项覆盖 31 个国家 239 名代码评审者的问卷调查研究了 AI 生成 Pull Request(AIPR)如何被评审者治理。受访者表示 AI 署名并非一刀切的拒绝信号,评审投入取决于该贡献是否具备可问责性:范围有界、有项目依据的说明、CI 之外的验证、贡献者响应性以及可识别的合并后归属。
Google Developers Blog 发文介绍智能体编码系统的 harness engineering,主张用行为评估补充 Terminal-Bench、DeepSWE 等端到端基准,断言智能体的中间执行步骤而非最终输出。
推荐理由:Google 团队给出行为评估的写法与三步测试循环,可作为智能体编码系统迭代时的可迁移方法。