公开论文雷达

公开 arXiv 研究简报 · 2026-08-28T01:05:59.076321+00:00

先看结论和关键数字,再决定要不要读原文。候选只在首次出现时展示;旧候选若后来通过深读门槛,仍会进入重点。

AI产物别直接用:七篇都在讲验证与分层

七篇讲的其实是同一件事:AI写的规格、记忆、重构、评审都不能直接采信。SPECMINE和AI互审教你怎么把证据分层交叉核验;MemGuard和双层记忆把过滤做进记忆系统;REFINE和需求检查提醒输出只是待审候选、初级人还会被拖累;FHA把风险识别前移到需求阶段。按你的角色挑读,别照单全收。

推荐阅读顺序

  1. 2608.21298:结论最反直觉且决定要不要用:LLM辅助反而拉低初级检查员的异味检出准确率,先读它划清适用边界
  2. 2608.21311:读任何GitHub评审证据前先看:AI互审已24.8万PR,评审口径随产品配置变,别当均质人工信号
  3. 2608.25202:打底的数据与方法:81.2%规格PR同时改代码,示范共变加引用两条路径交叉验证
  4. 2608.21867:记忆治理主张最完整:验证信号持久化贯穿全生命周期,16组全最优,仅验证器对照隔离增益
  5. 2608.22215:换个闸门位置对照读:把过滤前移到写入侧,裁68%冗余仍保98%,与MemGuard互补
  6. 2608.23611:落到具体流水线:异味降68-73%但输出只是待审候选,保留检查抓到断言改动与公有方法删除
  7. 2608.22978:把验证前移到需求阶段:安全危害分析迁到公平性,招聘流程最多27%环节存在公平危害
共性方法
七张卡都不把AI产出当成品直接采信:SPECMINE和AI互审讲证据要交叉核验、分层看;MemGuard和双层记忆讲写入或检索侧要持续过滤;REFINE和需求检查讲输出只是待审候选;FHA讲风险要在需求阶段前置识别。共同动作是给AI产出装一道可测的验证或治理闸门。
关键分歧
分歧在验证放在哪一环:双层记忆押写入侧、MemGuard押记忆全生命周期、REFINE押生成后闸门、需求检查押人先独立训练。角色也不同:SPECMINE和AI互审是给证据分层的实证与数据,其余是可落地机制,FHA则把安全工程危害分析迁到公平性。
选择准则
先看你要干什么:拿AI或GitHub数据当证据,先读21298、21311防误信;搭智能体记忆或重构流水线,读21867、22215、23611定闸门位置;高风险决策流程加读22978。

重点深读(7 / 7 篇)

形式化与程序验证(0 篇)

本轮没有通过深读证据门的重点论文。

软件工程与仓库智能(4 篇)

软件工程与仓库智能 7/30

SPECMINE: A Large-Scale Corpus of Spec-Driven Development Artifacts

SDD制品首次有了可追溯语料库:81.2%的规格变更PR同时修改代码:如果你在用或评估AI规格驱动开发工具,你之前没有任何规模化数据可查——规格文件长什么样、怎么连到代码,全是黑盒。SPECMINE收录470,795份规格文件(73,030个仓库)、5,992份触及规格的PR和2,421,323条有类型引用,首次把规格到代码的路径变成可查证据。

两句看懂

SDD工具自2025年涌现,但其制品从未被规模化研究,规格如何驱动代码实现至今无数据可查;SPECMINE通过双重普查与PR扫描首次捕获这一缺失层。对30份规格手动核验工具归属正确率100%,PR扫描发现81.2%的触及规格PR同时修改代码,两条独立路径均验证规格与实现共变。

核心判断

SDD制品从未被规模化研究;SPECMINE首次建立双路径可追溯语料库,81.2%的规格变更PR同时修改代码,470,795份文件与2,421,323条有类型引用构成两条独立的规格到代码验证路径。

关键要点

1. 旧有缺口:以往数据集只研究AI对话和AI生成PR,规格层从未被收录,规格到代码的路径未知,且不同工具的目录结构不同,通用文件名普查无法覆盖全部工具。 2. 方法与校验:四层采集——路径指纹普查470,795份文件、独立布局专项普查98,574份、PR扫描5,992份(81.2%同时改代码)、引用索引2,421,323条;归属经30份手动校验正确率100%。 3. 决定性结果:81.2%的触及规格PR同时变更代码,确认规格与实现共变是主流模式;做评估基准时应用共变与引用两条路径交叉验证,不要用合成规格。

证据与结果

广义普查:470,795份文件,73,030个仓库,44,521个所有者,17个命名工具,780,335次提交,468,307份含39项解析结构特征(EARS和Gherkin需求模板标记、代码表统计、质量信号)。独立布局工具普查:98,574份文件,12,910个仓库。PR扫描:11个工具,949个星数≥10仓库,5,992份触及规格的PR,81.2%同时修改代码,348,141行差异记录。可追溯索引:2,421,323条有类型引用(1.28M指向代码文件、863k指向同级文档、152k指向PR、62k指向ref、43k指向分支、22k指向issue),任务到代码映射435,401条,266,230份变更制品。归属校验:30份跨10工具手动检查,正确率100%。

打开论文原文
它要解决什么
AI规格驱动开发工具到底产出哪些制品?规格文件如何与代码实现建立关联?此前数据集只研究AI对话和AI生成PR,规格这一层从未被收录,导致规格到代码的路径完全无数据可查。
研究路径
工具归属靠路径指纹:每个SDD工具在仓库中生成固定目录结构,与该结构比对即完成归属,30份手动校验正确率100%。可追溯索引从四个来源提取引用:规格文本内嵌链接、提交信息、工具生成的任务文件、规格目录git树。采用任务文件列出代码路径的工具在锚定提交处解析引用,记录文件存在性及任务完成状态,共435,401条映射。任务指向但从未出现在git树中的文件,是规格未落实的独立证据信号。
这对工程意味着什么
第一步:构建SDD评估基准时,用共变PR与引用索引两条路径交叉验证规格到代码的映射。要避开的捷径:不要用合成规格替代真实仓库数据——真实数据包含规格演化历史、任务完成状态和39项解析结构特征,合成数据还原不了这些维度。
证据定位
广义普查470,795份文件(73,030个仓库,17个工具);独立布局工具98,574份(12,910个仓库);PR扫描得5,992份PR,其中81.2%同时修改代码,348,141行差异记录;可追溯索引2,421,323条有类型引用(1.28M指向代码文件);30份规格跨10个工具手动校验归属,正确率100%。(筛选维度:形式化验证、软件工程方法)
适用边界
语料库只覆盖公开代码托管平台仓库,私有仓库的SDD实践未纳入;PR扫描限于星数≥10的仓库,低活跃度仓库被系统性排除;自动批量生成的应用和无归属临时规格已剔除,其模式不代表刻意的SDD流程。
方法与英文摘要

通过代码托管平台搜索与REST API执行四部分采集:(1)广义普查:按文件名抓规格文件,用目录路径指纹归属到17个命名工具;(2)对采用独立三文件目录布局、无法被文件名搜索覆盖的工具做专项普查;(3)PR扫描:对11个工具中星数≥10的949个仓库抓取所有触及规格的PR及变更集;(4)可追溯索引:从规格文本、提交信息、工具生成文件和git树中提取有类型引用,部分工具进一步解析任务到代码路径并记录完成状态。

Spec-Driven Development (SDD) is a fast-emerging practice in which a structured natural-language specification, written by a developer, or (more often) drafted by an AI tool and then curated by the developer, drives an AI coding agent's implementation. A wave of tooling (GitHub Spec Kit [3], OpenSpec [4], AWS Kiro [5], and dozens of others) has appeared since 2025, yet the artifacts these tools produce have never been studied at scale. We present SPECMINE, a corpus that captures SDD in public GitHub repositories through two censuses: a broad census of spec.md/specs.md files covering most tools (470,795 files across 73,030 repositories, attributed to 17 named tools), and a Kiro census of its distinct requirements/design/tasks layout (98,574 files across 12,910 repositories). Each spec is enriched with full repository metadata, complete commit history, and parsed document structure. How a spec becomes code is itself an open question, so for 11 tools we sweep every pull request that touches a spec in their repositories with at least ten stars, capturing 5,992 such PRs across 581 repositories with their changesets. That makes the simplest workflow, spec and implementation changing together in one PR, directly observable, and a census-wide index of 2,421,323 typed references (1.28M to code files, 863k to sibling documents, 152k to PRs, 62k refs, 43k branches, 22k issues) gives a second, independent link from spec to code. SPECMINE lets the community study, for the first time, how software is specified in the age of AI agents.

软件工程与仓库智能 7/30

Human-AI Collaboration in Requirements Engineering: Evidence of the Negative Effect of LLMs on Requirements Inspection

LLM辅助需求检查反而拉低初级检查员的异味检出准确率:如果你正打算用ChatGPT代替资深工程师带新人做需求评审,请先停下。34名初级检查员的受控交叉实验显示:有ChatGPT支持时,需求异味检出准确率显著低于独立检查;而且先用LLM的人,跨期学习效应比先独立操作的人更弱。结论很明确:对初级检查员,LLM替代了认知投入,而不是增强能力。

两句看懂

LLM能否改善初级工程师的需求检查效果,此前缺乏受控证据;实验让34名参与者在有/无ChatGPT两种条件下交叉执行需求异味识别与分类任务。贝叶斯回归显示:LLM支持显著降低异味检出准确率,且先接触LLM者的跨期学习效应弱于先独立操作者。

核心判断

对初级检查员,LLM协作支持不能改善需求异味检出,反而使检出准确率显著低于对照组;先用LLM训练还会削弱跨期学习效应。证据来自34人受控交叉实验的贝叶斯回归分析。

关键要点

1. 旧假设是LLM协作能辅助人工需求检查,但缺乏其作为检查助手时影响的受控实证,初级检查员在AI辅助入职中的过度依赖风险未被量化。 2. 34名学生交叉参加两期实验,ChatGPT(GPT-4o/GPT-4.1)与无LLM条件随机分配,对检出准确率、有害/无害分类、任务时长各建独立贝叶斯回归模型,控制顺序与期次效应。 3. LLM组检出准确率显著更低,分类和时长无显著差异,先用LLM者学习效应更弱;行动:先让新人独立检查打基础,再引入LLM。

证据与结果

34名学生,受控交叉设计,两期各检查一份文本需求规格说明;LLM条件使用ChatGPT(GPT-4o/GPT-4.1)。结果变量:异味检出准确率、严重性分类(有害/无害)、任务时长,各建一个贝叶斯回归模型,控制顺序效应、期次效应、协变量和中介变量。主要发现:LLM支持显著降低检出准确率;分类和时长无显著差异;学习效应存在但先LLM组弱于先独立组;时长较长者检出更差;检出与分类准确率正相关。

打开论文原文
它要解决什么
LLM作为协作助手介入人工需求检查时,能不能提升异味检出准确率、严重性分类质量和检查效率?这是AI辅助入职培训场景下此前缺乏受控证据的问题。
研究路径
参与者用ChatGPT识别需求规格中的异味,LLM给出建议,参与者决定采纳与否。研究者推断:LLM支持降低了主动认知投入,即过度依赖,导致检出准确率下降。任务时长较长者表现反而更差,说明时间花在认知委托上而非深入分析。异味识别准确率与分类准确率正相关,两者共享底层认知能力,所以依赖LLM同时损害两条能力线。
这对工程意味着什么
第一个行动:给初级工程师配LLM辅助前,先安排若干轮独立检查训练,确认基础能力后再引入工具。要避免的捷径:直接把LLM当作资深专家带教的替代品——这会弱化学习效应,还会让你把产出质量错误归因于工具而非个人能力。
证据定位
LLM支持组的异味检出准确率显著低于无LLM组;严重性分类和任务时长没有显著差异。跨期存在学习效应,但先使用LLM的参与者效应弱于先独立操作者。任务时长较长者检出表现反而更差。检出准确率与分类准确率正相关。(筛选维度:形式化验证、软件工程方法)
适用边界
参与者是学生,只代表初级检查员,结论不直接适用于有经验的专业需求工程师;实验只用了ChatGPT(GPT-4o/GPT-4.1),不能推广到其他LLM;需求规格说明的具体来源和规模在摘录中未完整披露。
方法与英文摘要

受控交叉实验。34名学生充当初级需求分析师,分两期检查文本需求规格说明:一期有ChatGPT(GPT-4o/GPT-4.1)支持,一期无LLM支持,顺序随机分配。任务是识别需求异味并分类为有害或无害,同时记录检查时长。研究者对检出准确率、分类、时长三个结果变量各建一个贝叶斯回归模型,控制交叉设计带来的顺序效应、期次效应、协变量和中介变量。

Background. Requirements inspection (RI) is a well-established practice for detecting potential defects in requirements artifacts early in the software lifecycle. Recent advances in large language models (LLMs) have stimulated interest in their potential to support requirements engineering (RE) tasks. However, empirical evidence on the effects of LLMs when used as collaborative assistants in human-performed RI remains scarce. Aims. We aim to investigate the impact of LLM support on human-performed RI, considering inspection effectiveness in terms of smell identification and severity classification (i.e., nocuous vs innocuous), as well as inspection duration. Method. We conducted a controlled crossover design experiment with 34 participants, who inspected textual specifications with and without LLM support, identifying and classifying requirements smells while recording inspection time. We analyzed the data using one Bayesian regression model per outcome variable, accounting for validity threats induced by the crossover design as well as covariates and mediators. Results. Results show that LLM support negatively affects smell detection accuracy but has no significant effect on smell classification or task duration. A learning effect is present across experimental periods, but reduced when RI is first performed with LLM support. Conclusions. Our findings provide empirical evidence that LLM support does not necessarily improve performance and may, instead, hinder it for novice inspectors. Moreover, the results suggest that learning RI with LLM-support from the beginning may slow down the skill acquisition process, implying threats for LLM-supported learning.

软件工程与仓库智能 6/30

Fairness Hazard Analysis for Socio-Technical Processes: A Multiple-Case Study in Bias-sensitive Organisational Settings

公平危害分析在招聘流程需求工程中的多案例验证:FHA将安全工程危害分析方法迁移至社会技术系统,在需求工程阶段系统识别并缓解公平性风险。经两个焦点组概念验证后,在两家组织的真实招聘流程中落地评估,发现最多27%的流程环节存在公平危害。

两句看懂

公平性风险在社会技术流程中常被推迟至模型评估阶段处理,FHA将安全工程危害分析框架迁移至需求工程阶段,提供建模→识别→传播分析→缓解的系统方法。研究在两家组织真实招聘流程中进行多案例验证,从业者确认最多27%的流程环节存在公平危害,大部分缓解措施适当,但情境因素可能阻碍实施落地。

核心判断

FHA能在需求工程阶段系统定位社会技术流程的公平危害;多案例研究中危害覆盖最多27%的流程环节,从业者确认大部分缓解措施适当,支持公平性由设计阶段主动介入。

关键要点

1. 现有方法主要在算法或数据集层面处理公平性,缺乏在需求工程阶段系统识别社会技术流程公平危害并导出缓解措施的操作框架,导致公平性债务在流程中积累并演变为系统性偏见。 2. FHA借鉴安全工程危害分析,分建模、识别、后果与传播分析、需求层缓解四步迭代执行;验证分两阶段——TRL 3的两个焦点组(基于构造招聘场景,多学科专家参与)和TRL 5的两家组织真实招聘流程多案例研究(从业者评估相关性与可行性)。 3. 多案例研究中公平危害覆盖最多27%的流程环节,从业者总体认可缓解措施适当性;情境因素被指可能阻碍实施;提炼出独立审查与集体决策两类可跨组织迁移的缓解模式。

证据与结果

验证分两阶段。第一阶段(TRL 3):以构造但真实的AI辅助招聘流程为材料,组织两个焦点组,多学科专家参与结构化讨论,结果表明结构化方法有益,并指出需引入领域专家的迭代对话。第二阶段(TRL 5):在两家组织真实招聘流程中实施多案例研究,从业者评估危害相关性与缓解措施适当性;识别的公平危害最多覆盖27%的流程环节,大部分缓解措施获认可,但情境因素被指可能阻碍实施;提炼出独立审查和集体决策两类可跨组织迁移的缓解模式。

打开论文原文
它要解决什么
在需求工程阶段能否系统识别社会技术流程中的公平危害,并导出可操作的需求层缓解措施?
研究路径
FHA执行顺序:①对目标流程的参与者、活动、信息流建模;②逐环节识别可能产生不公平结果的危害状态;③分析每个危害的后果、传播链、影响范围和发生可能性;④定义需求层缓解措施,在流程中引入或修改控制机制;⑤随流程或情境变化迭代修订分析。
这对工程意味着什么
在高风险决策流程的需求工程阶段引入FHA逐环节分析公平危害,可在设计期发现并控制偏见传播路径;避免将公平性评估推迟到AI模型层面——流程性公平危害在模型评估中不可见。
证据定位
多案例研究中,从业者确认公平危害覆盖最多27%的流程环节,大部分缓解措施被认为适当;提炼出独立审查、集体决策两类可跨组织迁移的缓解模式。(筛选维度:可复核评测、软件工程方法)
适用边界
案例研究仅涉及两家组织的招聘场景,样本量有限,可推广性受特定行业与情境制约;定性研究依赖从业者主观评估,未提供缓解效果的量化对照基线。
方法与英文摘要

FHA分四步迭代执行:对目标流程的参与者、活动、信息流建模;逐环节识别公平危害;分析危害的传播链、后果与发生可能性;定义需求层缓解措施。验证分两阶段:概念验证(TRL 3)以构造的AI辅助招聘场景为材料,通过两个焦点组由多学科专家结构化讨论;多案例研究(TRL 5)在两家组织的真实招聘流程中应用FHA,由从业者评估危害相关性与缓解措施可行性。

Fairness is increasingly recognised as a first-class requirement in socio-technical processes, where interactions among human actors, software systems, and AI technologies may lead to unfair outcomes in decision-making workflows. If left unaddressed, fairness hazards may accumulate and reinforce systemic bias, highlighting the need to engineer fairness proactively. Despite growing interest in fairness-aware systems, systematic methods for identifying fairness hazards in socio-technical processes and deriving requirements-level mitigations remain limited. To support fairness-by-design during requirements engineering (RE), Fairness Hazard Analysis (FHA) is introduced as a methodology for systematically identifying, analysing, and mitigating fairness hazards. FHA is first assessed through a proof-of-concept validation conducted via two focus groups. Then, a qualitative multiple-case study involving two organisations examines its applicability in real-world settings. The proof-of-concept validation highlighted the benefits derived from the structured nature of the method, and suggested the need to include iterative, dialogic reflection with domain experts. In the multiple case-study where FHA was applied, the practitioners involved were positively impressed by the results and confirmed the relevance of the identified fairness hazards (spanning up to 27% of the process elements), as well as the appropriateness of most of the proposed mitigations, while noting that contextual factors might hinder their implementation. The evaluation also highlighted mitigation patterns, such as independent review and collective decision-making, which can be transferred to different organisations. This paper contributes a structured and empirically validated methodology for integrating fairness considerations in RE and preventing systemic bias in socio-technical processes.

软件工程与仓库智能 6/30

AI-to-AI Code Reviews of GitHub Pull Requests

AI互审已可测但仍属少数,且评审口径随产品配置而变:工程师若把GitHub评审记录当作人工决策证据,会被AI代理互相评审的数据混入影响判断。该数据关联CodAGE中2024–2026年AI归因事件,得到248,641条互审PR;跨产品仅占约1.6%,但2025年Q1至Q3增长逾百倍,同产品组评论量均值高58–65%。

两句看懂

AI代码代理同时充当PR作者与评审者,形成可观测闭环互审,但其规模与配置依赖行为此前缺少大规模实证。研究关联CodAGE 2024–2026年AI归因事件,构建248,641条互审PR,发现跨产品占比约1.6%、2025年Q1至Q3增长逾百倍,同产品组评论量均值高58–65%。

核心判断

闭环AI互审已达24.8万PR的可测规模,但仍只占少数;评审输出随作者-评审配置变化,不能视为统一过程,拿它当人工决策证据会有混淆风险。

关键要点

1. 旧假设把GitHub评审事件当均质人工信号,未区分AI同时担任作者和评审者,闭环互审规模与行为长期未量化。 2. 方法是从CodAGE提取AI归因事件并关联PR作者与评审者,分45,269条跨产品与208,145条同产品,用评论类别、每PR评论数、首次延迟做受控分组对比。 3. 决定性结果是跨产品互审2025年Q1至Q3增长逾百倍但占比约1.6%,同产品评论量高58–65%且偏上尾;使用前应分层并避免均值口径。

证据与结果

评估基于248,641条AI互审PR,其中45,269条跨产品、208,145条同产品、4,773条两者均有;跨产品约占所有AI归因PR的1.6%,2025-Q1至Q3增长逾百倍。行为差异有三处:重构评论比例35.0%对10.5%且可能源于PR特征;同产品组三/四组评论量均值高58–65%但效应量小、集中上尾;延迟中位数跨产品1.2分钟、同产品4.7分钟,受时间戳可用性不均等限制。

打开论文原文
它要解决什么
GitHub上AI代码代理既写PR又评PR的闭环互审规模有多大?评审行为是否随作者-评审工具配置系统性变化?
研究路径
数据管线从CodAGE提取2024–2026年GitHub事件,用产品归因标签区分AI作者与AI评审者,再关联同一PR两侧记录。评论类别来自评审工具内置分类;延迟只计算含完整非负时间戳的子集;所有指标分别在跨产品组与同产品组内汇总并比较分布。
这对工程意味着什么
第一步先把历史评审数据按作者-评审产品配置分层,再看评论量分布而不是只看均值;要避免的捷径是把全部AI评审事件当作可互换的均质基准信号。
证据定位
同产品组四组中三组每PR评论量均值高58–65%,但效应量小且集中在分布上尾;一款评审工具对两类作者PR的重构类评论比例为35.0%对10.5%,差异可能来自PR特征;完整时间戳子集中首次评审延迟中位数跨产品1.2分钟、同产品4.7分钟。(筛选维度:可复核评测、软件工程方法)
适用边界
数据只覆盖CodAGE可归因代理,私有或无标识代理不在内;跨/同产品组时间戳可用性不均等,削弱延迟直接比较;评论类别差异中PR来源混淆未通过控制实验排除。
方法与英文摘要

用CodAGE公开数据集(2024–2026年GitHub事件),把AI归因PR与AI归因评审事件关联,构建248,641条互审记录:45,269条跨产品、208,145条同产品。按跨产品/同产品分层,用三项指标对比:评审工具内置评论类别占比、每PR评论数分布、首次评审延迟中位数。

AI coding agents are increasingly integrated into software development workflows, operating on both sides of the pull-request (PR) process: AI authoring agents create or modify PRs, while AI reviewers evaluate them. This creates a closed loop in which one AI coding agent reviews a contribution attributed to another. We construct a large-scale dataset of AI-to-AI code review by linking AI-attributed PRs with AI-attributed review events from CodAGE, a public dataset of coding-agent-generated GitHub events. Our dataset contains 248,641 unique AI-attributed PRs that received at least one AI-attributed review. Of these, 45,269 received cross-product review and 208,145 received same-product review; 4,773 PRs received both. Cross-product AI-to-AI review occurred in approximately 1.6% of identified agent-authored PRs but was substantial in absolute terms, and its volume increased by more than two orders of magnitude from 2025-Q1 to 2025-Q3. Reviewer output varied across author-reviewer configurations. CodeRabbit labeled 35.0% of its comments on Claude Code-authored PRs as refactor comments, compared with 10.5% on Copilot-authored PRs, although this difference may reflect characteristics of the PRs rather than the reviewer. For three of four dual-role reviewers, mean comments per PR were 58-65% higher in the same-product group, although effect sizes were small or negligible and the difference was concentrated in the upper tail. Among pairs with complete, nonnegative timestamps, the observed median latency was 1.2 minutes for cross-product pairs and 4.7 minutes for same-product pairs; differential timestamp availability and reviewer composition limit this comparison. Overall, closed-loop AI-to-AI review is increasing but remains a minority of identified agent activity, with review output varying across authoring-agent groups and product configurations.

代码质量与优化(1 篇)

代码质量与优化 6/30

REFINE: A Multi-Agent LLM Approach for Evidence-Guided Code Refactoring

代码异味能降68–73%,但REFINE输出仍只能算需人工审查的重构候选:你在批量做Java重构时,最怕异味下去了、断言和公有方法却被悄悄改掉。REFINE用静态分析引导的多智能体流水线先检测异味、再生成变换、再做保留检查;在15个开源Java系统的450文件上,三种LLM配置异味减少68.26%、72.79%、68.49%,但更广泛质量改善不一致,保留检查仍发现断言/fail调用修改和公有方法删除。

两句看懂

直接提示LLM重构缺少验证,可能在异味下降时改断言、删公有方法;REFINE把静态分析、异味规划、LLM变换和保留检查串成多智能体流水线。450个Java文件、三种配置各450个候选的评测显示异味减少68–73%,但保留检查仍暴露断言修改和公有方法删除,更广泛质量指标也不一致。

核心判断

REFINE在文件级异味减少上优于直接提示:68–73%,主要异味最强,且编辑量和公有方法删除更少;但质量指标改善不一致,保留检查仍抓到断言修改和公有方法删除,所以结果不是可直接应用的补丁。

关键要点

1. 旧假设失效:只看异味减少率,会漏掉断言调用、公有方法、异常处理逻辑等行为风险。 2. 方法与受控检查:450文件、三种配置各450候选,对照同来源150文件直接提示,检查异味、质量指标、保留结果。 3. 结果与动作:异味降68.26%/72.79%/68.49%,主要异味最强;输出按候选处理,必须审查后入库。

证据与结果

数据边界是15个开源Java系统、每系统30文件、共450文件;三种LLM配置合计1,350个候选。对照为同来源150文件直接提示。结果要并排看:异味总体减少68.26%/72.79%/68.49%;主要异味削减在三种配置中都最强;更广泛质量指标有改善、持平或恶化;保留检查列出断言/fail调用变更和公有方法删除;REFINE编辑量与公有方法删除频率低于基线。

打开论文原文
它要解决什么
工程师真正要问的不是“异味降没降”,而是:文件级异味减少之外,行为相关结构是否保住,更广泛质量指标是否同向变好。
研究路径
静态分析先扫Java文件,给出异味和规则级证据。智能体按异味定计划。LLM只生成候选变换。系统对候选自动重分析,量异味变化。保留检查核对断言调用、公有方法、异常处理逻辑。报告把每个候选的异味来源、通过/失败检查、质量风险串起来。
这对工程意味着什么
第一个动作:把保留检查接进生成流水线,并让候选过编译、测试、依赖分析和人工审查。要避开的捷径:看到68–73%异味下降就合并;质量指标和行为保留并不同步。
证据定位
异味减少对应三种配置为68.26%、72.79%68.49%,主要异味削减幅度最强;相对150文件直接提示基线,REFINE中位数异味减少更高、编辑量更小、公有方法删除更少;但保留检查仍确认断言/fail调用变更和公有方法删除是主要残余风险。(筛选维度:可复核评测、软件工程方法)
适用边界
只覆盖Java文件级场景,每系统抽30文件,跨系统和跨语言泛化未验证。保留检查靠静态代理指标,不等同完整测试套件。也不能排除特定异味类型受提示配置影响。
方法与英文摘要

从15个开源Java系统各抽30文件,共450文件。三种LLM配置各生成450个候选,共1,350个模型通过输出。流程固定为:静态分析检测异味→按异味规划→LLM生成候选→自动重分析→保留检查→结构化报告。对照组是同来源系统的150文件直接提示。

Large Language Models (LLMs) offer new opportunities for automated code refactoring. However, generated changes must reduce targeted quality problems without introducing new issues or altering behaviour-relevant code structures. We introduce REFINE (Refactoring with Evidence-aware Flow for Integrated ageNtic Execution), a tool-agnostic, evidence-aware multi-agent approach for generating Java file-level refactoring candidates. REFINE combines static-analysis-guided smell identification, smell-informed planning, LLM-based transformation, automated re-analysis, preservation checks, and structured reporting. We evaluate REFINE on 450 Java files from 15 open-source systems, producing 1,350 model-pass outputs using OpenAI GPT-5.5, Google Gemini 3.1 Pro Preview, and Anthropic Claude Opus 4.8. REFINE reduces detected code smells by 68.26%, 72.79%, and 68.49% across the three configurations, respectively, with the strongest reductions observed for major smells. A matched 150-file direct-prompt baseline shows that REFINE achieves a higher median code-smell reduction with smaller edits and fewer public-method removals. However, broader quality improvements are inconsistent, and preservation checks reveal residual risks, including assert/fail-call changes and public-method removal. Therefore, REFINE outputs should be treated as refactoring candidates requiring compilation, testing, dependency analysis, and human review before adoption in repository- or system-level settings.

UI 与 GUI Agent(0 篇)

本轮没有通过深读证据门的重点论文。

个人知识与本体(2 篇)

个人知识与本体 6/30

Dual-Layer Agentic Memory with Fast Write Routing and Slow Consolidation

智能体记忆该在写入时过滤:双层记忆裁剪68%冗余,问答精度仍超98%:如果你在做长期运行的智能体,外部记忆无限膨胀会直接拖慢检索、抬高噪声,这是绕不开的工程问题。这套双层记忆框架给出的答案是:别等读取时再筛选,写入时就该过滤。它用1.7B/8B级联路由在写入侧裁剪最多68%冗余存储,同时把下游问答精确匹配率保留在98%以上。

两句看懂

现有智能体把所有输入无条件追加进外部记忆,导致检索退化;双层框架在写入阶段用1.7B/8B级联路由过滤冗余,再通过有监督微调周期性内化高价值记忆。在升级大模型比例低于50%的约束下,级联裁剪68%冗余外部记忆,下游QA精确匹配率保留超98%(对比穷举保留基线)。

核心判断

外部记忆应当作暂时缓冲,不是永久仓库。写入路由级联加周期微调,在裁剪68%冗余、升级比例低于50%的条件下保留超98%精确匹配,说明写入侧主动管理优于读取侧被动过滤。

关键要点

1. 旧做法把过滤推迟到读取侧,写入时不拒绝任何输入,存储单调增长,检索噪声和计算成本随时间上升。 2. 方法是写入路由加周期写回:输入分non-write/write-new/write-update三类,1.7B初判、低置信样本升8B复判,做write/discard二值准入;高价值条目定期经SFT写回参数,关键控制变量是路由阈值和整合频率。 3. 结果:升级比例低于50%时裁剪68%冗余存储,QA精确匹配率保留>98%(对比穷举保留);工程上应把外部记忆当缓冲而不是仓库,优先在写入侧加过滤。

证据与结果

评估指标是问答精确匹配(EM),主对比基线是穷举保留(所有输入都写入外部记忆)。结果:1.7B/8B级联最多裁剪68%冗余外部记忆,升级比例低于50%,QA EM保留超98%。整合实验显示参数更新后路由器自适应抑制重复写入。摘录没有给出数据集名称和规模的完整信息,跨领域泛化能力尚待验证。

打开论文原文
它要解决什么
外部记忆只增不减、检索越来越差时,能不能在写入阶段就拒绝冗余,并把稳定知识定期内化进模型参数?
研究路径
输入到达时,1.7B小模型先做write/discard二值判断;低置信样本升级到8B大模型复判。准入的条目按non-write/write-new/write-update分类存进外部记忆。周期性写回阶段从外部记忆选高价值条目,用有监督微调更新模型参数;此后路由器对已内化知识自动输出discard,抑制重复写入,模型的知识边界随整合迭代动态收缩。
这对工程意味着什么
第一步:给长期运行的智能体在写入侧加路由过滤层,用小→大模型级联控制成本,而不是靠读取侧排序补救。要避免的捷径:把外部记忆当成无限日志,写入期不做冗余检测。
证据定位
1.7B/8B级联最多裁剪68%冗余外部记忆,升级到大模型的输入比例低于50%,下游QA精确匹配率保留超98%,基线是所有输入都写入的穷举保留方案。整合实验还显示:参数写回后,路由器会自适应抑制已内化知识的重复写入请求。(筛选维度:可复核评测、软件工程方法)
适用边界
摘录未说明评估数据集来源、规模和领域覆盖;未提供写回频率、整合数据量或不同知识类型分布的消融分析;现有证据不足以判断框架在高噪声或分布偏移场景下的鲁棒性。
方法与英文摘要

记忆分两层:参数记忆存稳定知识,外部记忆暂存新事实和冲突事实。写入时,路由把输入分成non-write、write-new、write-update三类,实际只做write/discard二值准入:1.7B小模型先判,低置信的样本升级给8B模型复判。准入的条目写进外部记忆;之后周期性选取高价值条目,用有监督微调写回模型参数。参数更新后,路由器对已内化的知识会自动输出discard,不再重复写入。

Large language model (LLM) agents operate in dynamic environments where knowledge continuously evolves. Existing memory systems typically treat external memory as a monotonically growing repository, inevitably leading to retrieval degradation and increasing computational costs over time. We argue that the core challenge is not retrieval alone, but managing the knowledge lifecycle: deciding what to externalize, update, or ultimately internalize. Inspired by Complementary Learning Systems (CLS) theory in neuroscience, we propose Dual-Layer Agentic Memory, a framework that shifts memory management to the write phase through cost-aware epistemic routing and periodic parametric consolidation. Incoming information is categorized as non-write, write-new, or write-update, and routed through a small-to-large model cascade that minimizes routing overhead while filtering redundant memories. A subsequent write-back phase selectively consolidates high-value external memories into model parameters via supervised fine-tuning. Experiments demonstrate the dual efficiency of our approach: a 1.7B/8B cascade prunes up to 68% of redundant external memory while escalating fewer than 50% of inputs, yet retains over 98% of the downstream QA Exact Match (EM) achieved by an exhaustive retention baseline. We further show that periodic consolidation successfully internalizes external knowledge, allowing the router to adaptively suppress redundant writes as the model's epistemic boundaries evolve. Overall, our framework presents a unified paradigm for agent memory: selective externalization followed by selective internalization. Code and dataset will be released upon acceptance.

个人知识与本体 6/30

MemGuard: Persisting Verifier Signals for LLM-Agent Memory Governance

验证信号只在入库时用一次不够:持久化描述符让智能体记忆在16组测试中全部最优:如果你在做长任务流的智能体记忆系统,最大的隐患不是记忆太少,而是无效轨迹和过期记录越积越多,行为慢慢变得不可预测。MemGuard的办法是把验证器的输出变成奖励、置信度、标签、不确定性四类描述符,永久贴在每条记忆上,让检索、冲突解决、归档都能直接读取质量信号。结果:4个骨干模型×4个基准共16组设置,全部拿到最优成功率和最低平均步骤。

两句看懂

现有记忆系统只在准入时调用验证器,失效轨迹和漂移冗余记录随任务积累持续混入检索池;MemGuard把多准则验证输出持久化为奖励、置信度、标签和不确定性描述符,贯穿准入、检索、冲突解决和归档全流程。在4骨干×4基准共16组受控对比中MemGuard全部最优,WebArena较最强基线提升7.9个成功率点;仅验证器控制组劣于MemGuard,证明增益来自持久化信号而非一次性过滤。

核心判断

验证描述符持久化贯穿记忆生命周期,优于一次性过滤。MemGuard在全部16组骨干-基准设置中成功率最优;仅验证器控制组优于强基线但劣于MemGuard,这组对照直接隔离了增益来源。

关键要点

1. 旧假设认为验证器单次过滤足以保证记忆库质量,但两类失效打破它:相关性检索把无效轨迹(含错误操作和偶然成功)拉进上下文,过期记录没有权重衰减机制一直占着top-k池,比如旧API版本的工具用法在每次相似查询时重复注入,智能体行为随任务积累不可预测地劣化。 2. MemGuard把轨迹验证拆成成功性、证据支持、可执行性、可推广性四个准则,输出奖励、置信度、标签、不确定性四类描述符并持久附加到候选记忆;在四基准、四骨干上对比五条基线(含仅验证器控制组),控制任务顺序、步骤预算、检索预算和解码设置,5随机种子均值;失败轨迹以失败约束形式入库,而不是行动配方。 3. 全部16组设置中MemGuard成功率最优、步骤最低:WebArena +7.9 SR点,Mind2Web +5.6 SSR点,终端/软件工程 +2.4-3.5点;仅验证器控制组优于ReasoningBank但全面劣于MemGuard,说明该做:把验证描述符随条目持久存储,治理上限取决于验证证据能否在检索和归档阶段持续生效。

证据与结果

四个基准:Terminal-Bench 2.0(终端命令任务)、SWE-Bench Verified(软件工程补丁)、WebArena(网页导航)、Mind2Web(网页操作)。四个骨干:Qwen-3.5-Flash、Qwen-3.5-Plus、Gemini-3-Flash、Gemini-3.1-Pro。五条基线:No Memory、Synapse、AWM、ReasoningBank、仅验证器控制组。控制变量:任务顺序、步骤预算、检索预算、解码设置。指标:成功率SR、步骤成功率SSR、平均步骤数,5随机种子均值。结果:16组全部最优;WebArena较ReasoningBank +7.9 SR点,Mind2Web +5.6 SSR点,终端/软件工程 +2.4-3.5点;仅验证器控制组优于ReasoningBank但劣于MemGuard,把增益来源隔离到持久化信号。

打开论文原文
它要解决什么
验证器只在准入时做一次过滤,能不能维持长任务流记忆库的可靠性?把治理信号持久化,能不能带来可以单独测量的增益?
研究路径
轨迹提交时,MemGuard跑多准则验证,把成功性、证据支持、可执行性、可推广性分数转成奖励、置信度、标签、不确定性四类描述符。不合格候选被拒,或者以失败约束形式入库而不是行动配方。激活后,描述符随记忆条目持续存储:检索时按质量描述符加权排序,不确定记录标记为暂定,弱记录降权,冗余记录合并,过期记录在有限活跃预算下摘要化或归档。
这对工程意味着什么
第一个动作:在你的记忆系统里把验证器输出序列化成持久描述符,随条目存储,让检索和归档直接读质量信号。要避开的捷径:只在准入阶段过滤不持久化,仅验证器控制组实验表明这条路的增益上限明显低于持久化方案。
证据定位
MemGuard在全部16个骨干-基准组合中成功率最优、平均步骤最低。相对最强基线ReasoningBank:WebArena提升7.9个成功率点,Mind2Web提升5.6个步骤成功率点,终端和软件工程任务提升2.4到3.5点。关键对照:仅验证器控制组优于ReasoningBank,但劣于MemGuard。这把增益来源隔离到持久化信号,而不是一次性过滤。(筛选维度:置信度与不确定性、可复核评测)
适用边界
摘录未说明多准则验证器各准则的权重配置方式;活跃记忆预算的具体上限和触发归档的阈值未披露;骨干模型限于四个商业闭源模型,开源模型和更长任务流下的泛化性未在摘录中涵盖。
方法与英文摘要

在Terminal-Bench 2.0、SWE-Bench Verified、WebArena、Mind2Web四个基准上,用Qwen-3.5-Flash、Qwen-3.5-Plus、Gemini-3-Flash、Gemini-3.1-Pro四个骨干模型做测试。对比No Memory、Synapse、AWM、ReasoningBank四个基线,外加一个“仅验证器”控制组。控制任务顺序、步骤预算、检索预算和解码设置,报5个随机种子的均值。MemGuard把轨迹拆成多准则验证,输出奖励、置信度、标签、不确定性描述符,持久附加到候选记忆上。

LLM agents are moving from single-prompt use to long task streams in which reusable memory becomes a core capability for terminal, software-engineering, and web tasks. Such memory is useful only when stored experience remains reliable across hundreds of interactions, but two failure modes break that assumption in practice. The first is unreliable admission: failed trajectories,accidental successes, and misleading observations enter memory because they appear relevant, then mislead later decisions. The second is memory drift: long-running banks accumulate duplicate, stale, and conflicting records that retrieval alone cannot repair. MemGuard's key distinction is to treat verifier output not as a one-shot filter, but as persistent lifecycle metadata. It converts multi-criteria score-token verification into reward, confidence, label, and uncertainty descriptors that are attached to every candidate before activation and reused during retrieval, conflict resolution, summarization, and archival. We evaluate MemGuard on Terminal-Bench 2.0, SWE-Bench Verified, WebArena, and Mind2Web across four backbones, comparing against four memory baselines plus a verifier-only control under matched runtime budgets. Averaged over five seeds, MemGuard achieves the best success metric and lowest average steps in all 16 backbone-benchmark settings, improving over ReasoningBank, the strongest prior baseline among the memory methods we evaluate, with a largest gain of 7.9 success-rate points on WebArena, 5.6 step-success-rate points on Mind2Web, and 2.4-3.5 points on terminal and software-engineering benchmarks. Code is available at https://github.com/whyyyyy123/MemGuard.

人机协同与对齐(0 篇)

本轮没有通过深读证据门的重点论文。

本轮分类概览

同一论文只归入一个最先命中的赛道,避免重复计数;“新增候选”只统计首次展示的论文。

赛道新增候选重点
形式化与程序验证30
软件工程与仓库智能14
代码质量与优化01
UI 与 GUI Agent00
个人知识与本体32
人机协同与对齐00

近一个季度监测日历

北京时间。绿色表示有可阅读的新候选,灰蓝表示已监测但无新增,橙色表示部分降级;“无记录”不等于失败。

2026 年 6 月

1无记录2无记录3无记录4无记录5无记录6无记录7无记录8无记录9无记录10无记录11无记录12无记录13无记录14无记录15无记录16无记录17无记录18无记录19无记录20无记录21无记录22无记录23无记录24无记录25无记录26无记录27无记录28无记录29无记录30无记录

2026 年 8 月

近 14 次监测窗口

仅展示公开源的聚合运行状态,不含提示词、全文或个人数据。

本轮新增候选(7 篇)

按赛道、评分和日期展开;中文标签用于导航,英文摘要用于核验。已展示过的旧候选不会每日重复。

形式化与程序验证(3 篇)

形式化与程序验证 · 8/30 · 2026-08-26面向定理证明的数学诊断基准覆盖13个数学领域及Lean 4证明,含选择题、填空与专家改写任务;评测显示形式化仍是主要瓶颈。MathAdv: What Theorem Provers Know, Reason, Formalize, and Generalize

Formal theorem proving enables machine-verifiable evaluation of mathematical reasoning, yet existing benchmarks often emphasize aggregate proof accuracy, concentrate on a narrow range of mathematics, and provide limited evidence of robustness to equivalent reformulations. We introduce MathAdv, a diagnostic benchmark spanning 13 domains across undergraduate- and graduate-level mathematics. Alongside Lean 4 theorem proving, MathAdv provides up to three auxiliary tasks: multiple-choice questions that probe mathematical knowledge, fill-in-the-blank problems that isolate informal reasoning, and expert-crafted transformations that test robustness to problem presentation. Our evaluation of contemporary theorem provers yields four findings: formalization remains a major bottleneck; performance varies substantially across mathematical domains; natural-language guidance helps general-purpose LLMs but can hinder proof-specialized models; and mathematically equivalent reformulations expose substantial robustness limitations. Together, these results show how component-wise evaluation can reveal model capabilities and failure modes that aggregate theorem-proving accuracy obscures. The dataset and evaluation scripts are available at https://github.com/margotyjx/MathAdv.git.

阅读 arXiv 原文
形式化与程序验证 · 8/30 · 2026-08-25LLM与Lean验证MILP重构以构造式MILP重构定义在Lean中机器检验,结合LLM agent评估公式等价性;弥补仅依赖数值验证的局限。FLARE: Verifying MILP Reformulations with LLM-Based Theorem Proving

Mixed-Integer Linear Programming (MILP) is a fundamental tool for combinatorial optimization with extensive real-world applications. A central challenge is designing computationally efficient MILP formulations. Large Language Models (LLMs) offer new opportunities to automate the modeling process, from deriving formulations to strengthening them. Reliable automation requires robust methods for verifying that proposed formulations preserve the underlying optimization problem. However, existing approaches evaluate formulations numerically and fail to reason about general problem instances. We resolve this limitation by introducing a constructive definition of MILP reformulation that can be formalized in Lean and machine-checked. We develop FLARE (Formulation-Level Automated Reformulation Evaluation), a method that uses an LLM-based agent and the Lean proof assistant to verify proposed reformulations against a reference formulation. To evaluate our approach, we introduce FormulationBench, a challenging dataset of 20 problems and 109 formulations. FLARE outperforms existing methods, with 100% accuracy on the NP-hard subset of FormulationBench. Furthermore, FLARE produces a machine-checkable certificate for every reformulation it accepts. For cases where formal guarantees are not necessary, we introduce FLARE-NL, a fast and cheap LLM proxy that matches FLARE's accuracy but produces no certificate. These methods enable reliable verification in automated optimization modeling.

阅读 arXiv 原文
形式化与程序验证 · 6/30 · 2026-08-25LLM-Driven, Datasheet-Aware Automated Hardware Compatibility Verification for Early-Stage, Pre-Schematic Embedded System Design

We present an LLM-driven, datasheet-aware framework for early-stage hardware compatibility verification that identifies documentation-level interface incompatibilities based on hardware datasheets and high-level component connectivity descriptions. It does not require, and can therefore be used, before detailed schematic simulation and implementation. We view trustworthy LLM-assisted design automation not as directly generating answers from documents, but as transforming engineering information through traceable verification stages. Given hardware datasheets and high-level component connectivity descriptions, the framework constructs a design graph that captures device connectivity and shared interaction domains, retrieves only the engineering properties required by explicit, domain-oriented verification criteria , and generates deterministic scripts for compatibility evaluation. By decomposing compatibility analysis into modular stages and preserving intermediate results, the framework reduces context overhead, improves transparency and tractability, enables scaling, and avoids reliance on LLMs for numerical computation. Evaluated on seven embedded-system designs comprising 34 datasheets, our framework achieves 97.5% compatibility-verification accuracy and an 8.6 times reduction in input context size compared with ``upload-and-query'' workflows. These results demonstrate the feasibility of LLM-assisted, specification-based hardware compatibility verification at an early design stage, as well as the need for, and substantial benefits of, modular task decomposition, formalized verification criteria, and task-aware compact context construction.

阅读 arXiv 原文

软件工程与仓库智能(1 篇)

软件工程与仓库智能 · 7/30 · 2026-08-25规范驱动开发制品大规模语料库基于GitHub公开仓库构建大型SDD制品语料:47万+规范文件、7万余仓库,附提交历史等元数据;可用于规模化SPECMINE: A Large-Scale Corpus of Spec-Driven Development Artifacts

Spec-Driven Development (SDD) is a fast-emerging practice in which a structured natural-language specification, written by a developer, or (more often) drafted by an AI tool and then curated by the developer, drives an AI coding agent's implementation. A wave of tooling (GitHub Spec Kit [3], OpenSpec [4], AWS Kiro [5], and dozens of others) has appeared since 2025, yet the artifacts these tools produce have never been studied at scale. We present SPECMINE, a corpus that captures SDD in public GitHub repositories through two censuses: a broad census of spec.md/specs.md files covering most tools (470,795 files across 73,030 repositories, attributed to 17 named tools), and a Kiro census of its distinct requirements/design/tasks layout (98,574 files across 12,910 repositories). Each spec is enriched with full repository metadata, complete commit history, and parsed document structure. How a spec becomes code is itself an open question, so for 11 tools we sweep every pull request that touches a spec in their repositories with at least ten stars, capturing 5,992 such PRs across 581 repositories with their changesets. That makes the simplest workflow, spec and implementation changing together in one PR, directly observable, and a census-wide index of 2,421,323 typed references (1.28M to code files, 863k to sibling documents, 152k to PRs, 62k refs, 43k branches, 22k issues) gives a second, independent link from spec to code. SPECMINE lets the community study, for the first time, how software is specified in the age of AI agents.

阅读 arXiv 原文

代码质量与优化(0 篇)

本轮该赛道没有候选论文。

UI 与 GUI Agent(0 篇)

本轮该赛道没有候选论文。

个人知识与本体(3 篇)

个人知识与本体 · 0/30 · 2026-08-26多范式存储的AI记忆管理数据库为智能体长期记忆设计,混合图/向量/概率/时空存储,以概率推理减少事实冲突与幻觉;尚属演示,证据有限。PolyMemDB: A Polyglot Database System for AI Memory Management

With the widespread adoption of personal intelligent agents, users generate massive, heterogeneous data during long-term interactions. Leveraging this data as long-term memory helps reduce token overhead and deliver personalized experiences. However, existing memory systems face two primary limitations: they rely on single-storage paradigms that fragment multi-dimensional data, and they lack fine-grained data provenance to resolve long-term factual conflicts, thereby worsening LLM hallucinations. In this demonstration, we introduce PolyMemDB, a novel system tailored for managing agent memory. PolyMemDB has a polyglot storage architecture designed to track and manage various memory types, including graph, vector, probability and spatial-temporal data. To ensure factual consistency and reduce hallucinations, it features a probabilistic inference engine that integrates temporal decay with semiring aggregation, resolving long-term factual conflicts, providing detailed data provenance, and enabling users to trace reasoning chains transparently.

阅读 arXiv 原文
个人知识与本体 · 0/30 · 2026-08-26继承记忆中的过期约束核查研究有限核查预算下智能体能否发现已被取代的记忆约束;实验显示多数情形仍做出过时一致决策,证据受场景限制。When Stale Constraints Go Unchecked: Budgeted Verification Failures in Inherited Agent Memory

An agent that inherits a consolidated memory may inherit a constraint that was true when written and has since been withdrawn by a newer authoritative record. Under a scarce verification budget, does the agent recover the withdrawal, and if not, is the error avoidable without spending more? We model supersession explicitly -- historical provenance is immutable; what changes is which record is current -- and assign by design the memory's form, the world's state (source current or superseded), and the verification policy at a fixed budget of two records: the agent's own allocation, or the same budget with one slot re-assigned to the critical provenance path or to a random record. With a constraint stated, agents inspected its provenance path in about one episode in five; when that constraint had been superseded, native allocation produced stale-consistent decisions in 77.3%, 74.7% and 74.7% of episodes across a primary run, a fresh-wording replication and a held-out domain. Re-assigning one slot to the critical path raised current-record-consistent decisions by +74.0, +72.7 and +61.3 points, positive in six of six models in each of those runs, and changed nothing when the record agreed with the memory. The held-out scenario was later found to contain a temporal inconsistency; a robustness replication with one sentence corrected, deposited externally before execution, gave +73.3 points and is reported alongside the original. The intervention uses knowledge of the critical path and is not a scheduler; it identifies that the share of stale-memory error attributable to verification allocation is close to its structural ceiling. Memory systems may need freshness or supersession signals separate from relevance.

阅读 arXiv 原文
个人知识与本体 · 0/30 · 2026-08-26分层个性化的智能体记忆策略将记忆管理分为全局共享与用户自适应两层,使策略动态协同进化;尚属框架提出,效果证据有限。Learning What to Share and What to Personalize: Hierarchical Strategy Co-Evolution for Agent Memory

Memory-augmented agents maintain compact user profiles throughout extended conversations, enabling personalized and consistent responses without the need to process the entire dialogue history. The quality of these user profiles relies on the underlying memory management strategy: at each step, the agent must determine what to retain, compress, or discard. However, existing methods typically employ a static, one-size-fits-all strategy established before training. In practice, the optimal memory decision is inherently user-specific and dynamically evolves alongside policy optimization. To address this, we propose \textbf{HiPS} (\textbf{Hi}erarchical \textbf{P}ersonalized \textbf{S}trategy), a framework that decouples memory management into a globally shared foundation and a user-specific adaptive tier. Specifically, HiPS employs \textbf{Universal Strategy} to extract shared principles from cross-persona trajectories, alongside \textbf{Persona Delta Distillation} to generate tailored rules for users whose behaviors diverge from general patterns. \textbf{Cross-Level Rule Flow} dynamically calibrates their boundary by promoting broadly validated personal rules and demoting contradicted global ones. The architecture establishes a co-evolution loop where a mechanism guarantees that all strategy refinements are anchored to task outcomes. Extensive experiments demonstrate consistent improvements over memory-augmented baselines.

阅读 arXiv 原文

人机协同与对齐(0 篇)

本轮该赛道没有候选论文。