在相同预算下,CQ2-CARE 胜过测试过的检索器和压缩器,但同文件压缩与之持平或更优
Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files
论文指出,仓库级修复需要同时具备两项条件:找到必须修改的文件,并准确呈现其中原样编写的代码。论文认为,常见上下文策略有两种失效模式:检索器可能把相似代码排在前面,而不是找到必须修改的文件;压缩器则可能删去或改动模型需要复现的文本。因此,研究问题具有明确的操作性:对于相同的单个问题 token 预算,智能体应选择少量文件并逐字呈现,而不是检索代码块或删减 token 吗?
CQ2-CARE 通过两次独立询问待测模型哪些文件必须修改来实现这一选择。它选择两次定位采样都指出的文件;如果交集为空,则回退到第三次采样;还可以加入简短的 grep 派生证据片段,并在大小上限内完整、逐字呈现选中的代码文件。基线方法按照 CQ2-CARE 实际达到的单个问题 token 预算进行调整,因此比较关注的是预算分配,而非名义上的上下文长度。
在 300 个符合条件的近期 Python SWE-rebench 问题上,每个上下文只调用一次补丁,并由官方基准测试框架评分。CQ2-CARE 使用 GPT-5.6 时解决了 43.7% 的问题,使用 Claude Opus 5 时解决了 46.7%。与测试过的最强压缩器相比,它在两种模型上都高出 6.3 个百分点;与测试过的最强检索器相比,使用 GPT-5.6 时高出 9.3 个百分点,使用 Claude Opus 5 时高出 12.7 个百分点。在一项 GPT-5.6 诊断中,代码块检索器所提供的上下文行中,至多约五分之一属于黄金补丁编辑过的文件;CQ2-CARE 提供的此类行约占一半。
两项对照实验进一步厘清了作用机制。在固定文件选择的情况下,删减 token 会降低补丁适用率和问题解决率,这与代码文本被改动后更难应用编辑的解释相符。但当 LongCodeZip 从 CQ2-CARE 的候选文件开始压缩时,其观测到的问题解决率与 CQ2-CARE 持平或略高;报告的差异并不显著。因此,主要比较并不能证明,对同一批候选文件进行压缩,不如精确选择文件。
外部效度有限:该实验没有测试能够重新打开文件、运行测试或通过多轮交互找回信息的交互式智能体。一项有价值的后续研究是进行匹配的 2×2 实验:固定候选文件集合,比较逐字呈现代码与代码感知压缩,然后在可交互地重新打开文件的条件下重复测试。关键问题在于,控制文件召回后,忠实呈现是否仍然重要;而不是选择文件是否胜过从不同候选上下文开始的压缩器。
读这篇论文,可以了解如何在匹配预算的修复实验中区分文件召回、代码忠实度和压缩;也可以看到,为什么针对同一批候选文件的压缩对照会改变标题所表达的结论。
来源位置
AOS-Bench 在限时、共享资源的任务流中评测代码智能体
AOS-Bench: Can LLM Agents Manage Dynamic Workloads?
论文指出了代码智能体评估中的一个测量缺口:现有基准逐个孤立评估任务,而持久运行的助手必须在共享 CPU 和内存限制下,接收随时间到来的工作。AOS-Bench 将评估单位改为工作负载管理器:经过验证的 CLI 任务随时间到达,在共享 CPU 和内存限制下交付;同时,以相同任务逐个运行时的表现作为每个系统的参照。
AOS-Bench 通过结合定时到达的任务、共享资源预算和逐任务验证,将工作负载管理转化为可操作的评估;由智能体系统决定何时领取并组织已释放的任务。每项任务都有指令、释放时间和验证器,工作负载则指定共享 CPU 和内存;流式任务通过调度器接口随时间逐步开放。相同任务逐个运行时的表现作为每个系统的参照。对研究者而言,一种有用的设计做法是保留这一匹配参照,同时记录交付在哪个环节失败:接收、执行还是最终验证。
测得的差距很大。所有五个受测系统在高负载流式执行中的验证通过任务成功率,都低于其匹配的单任务参照,降幅为 13.0–22.7 个百分点。在中等负载下,受测系统的流式成功率彼此差异大于各自单任务基线之间的差异;两个系统的单任务 SR 只相差 0.6 个百分点,但流式执行得分分别为 53.9% 和 68.1%。在 GLM-5.3/Claude Code 策略干预中,串行 FIFO 严重限制了任务接收:在高负载下,近四分之三的已释放任务无人领取。简单地固定并发数为二,在这项干预中就接近测试过的最佳智能体管理策略,而无需根据工作负载调整调度决策。每种受测策略都至少让四个已配置核心中的 70% 处于空闲状态,同时仍有任务等待。
后续实验应在固定模型—框架组合、提示词、工作区和资源分配的同时改变任务接收和并发度,并分别报告已领取、已完成和通过验证器的任务数。这样可以检验观察到的流式执行差距究竟来自调度、共享环境干扰,还是两者兼有。
流式执行与单任务执行之间的差异,并不是对调度单一因素的干净因果估计:流式运行还引入了共享文件系统、任务池接口、调度前导指令和共享资源分配,而单任务运行获得的总体资源机会更多。评估的五组模型—框架组合也不是只控制模型变量的比较:框架设置、工具可用性、路由方式和输出 token 上限因系统而异。结果描述的是受测的模型—框架配置。由于独立工作负载集群数量较少,不确定性有限,尤其是高负载层级的估计。大多数高负载试验也达到了墙钟时间限制,因此高负载层级的交付表现是一个下界。应将 AOS-Bench 视为一种基准设计和对受测策略的诊断,而不是简单提高并发通常就足够的证据。
读这篇论文,可以了解一种适用于持久运行代码智能体的评估范式:将经过验证的任务流交付表现与匹配的孤立任务表现进行比较,再在明确说明受测设置的前提下,对任务接收和并发度进行干预。
来源位置
匹配的 MCP 与 CLI 接口会在共享执行环境下改变智能体行为
此前关于 MCP 与 CLI 的证据存在一个具体的归因难题:配对比较 MCP 与 CLI 的成本时,结果波动很大,两个方向的差异都出现过,因此论文将其视为尚无定论。MICA 针对这一更具体的问题,依据共享的语义动作契约生成匹配的 MCP 和 CLI 接口,并将解码后的动作通过同一运行时路由。比较还固定了任务状态、语义动作契约、验证与执行路径、生成设置和交互预算。
除了配对的自然交互轨迹(可呈现早期分歧如何逐步扩散),MICA 还加入匹配状态探测,分别改变能力呈现、动作实现和反馈。在六个模型和三个交互环境中,匹配接口改变了任务结果和交互成本;其影响因模型—环境组合而异,并未始终偏向 MCP 或 CLI。影响也不限于表面有效性:接口差异还改变了语义动作选择,包括那些能够解码为类型化提案的响应。在固定决策上下文中,呈现方式、实现方式和反馈可能相互作用。配对轨迹显示,在 2,004 个回合中,94.3% 出现了有结构的分歧。
DART 将这一分解转化为一项干预:保留经过验证的语义承诺,只修复接口特有的动作实现。在六种 Gemini-2.5-Flash 基准—接口设置中,与协议匹配的 Base 相比,DART 提高了报告的基准分数,最高提升 9.0 个百分点。在 MCP 下,它在三个环境中都降低了 token 成本,每项任务最多减少 27.1k 个 token;而在 CLI 下,token 成本的变化则不一致。
干预证据仅适用于一个模型,因此不能据此证明结果可推广到基线比较中的其他五个模型。保留并修正的分支也只有四次机会作为依据。更广泛地说,这一受控比较只在构造的契约和三个基准测试中隔离了这些维度;它不能证明相同的效应量适用于其他接口或环境。一项有价值的复现实验操作是分别记录语义选择、表面动作实现和反馈,然后在更改底层工具运行时之前,重新运行匹配状态的因子探测。
读这篇论文,可以了解一种具体的实验分解方式——语义选择、接口实现和反馈;也可以了解一种修复策略:在不改变已验证语义承诺的前提下,改变表面动作。
来源位置
SABench 将工具智能体的任务完成与未经授权的写入行为分开评测
Task Success Is Not Enough: Side-effect-Aware Evaluation of Tool-Using Language Model Agents
即使智能体执行了未经授权的状态变更操作,工具智能体评估也可能将该回合判为成功。SABench 的作者将这种失效模式称为 附带损害(CD)。这针对的是以结果为中心的评估中的一个具体缺口:较早的 τ-bench 评估最终数据库状态和用户所需信息;但其作者提醒,该奖励机制可能漏掉不改变这些输出、却违反策略的行为,例如未经明确确认就采取行动(τ-bench,第 3 节)。
SABench 改变的是测量目标,而不是智能体。每项任务都规定初始状态、目标,以及电子邮件、日历和工单工具中明确授权的写入操作集合。其确定性预言机从轨迹中提取成功的状态变更调用,在初始状态上重放这些调用,评估目标是否实现,并单独检查实际写入是否超出授权范围(SABench,第 4 节)。该基准包含来自 47 个模板的 201 项任务,涵盖四种状态结构和四类陷阱。对于含糊任务,澄清前发生的任何成功写入都算作违规(第 3 节)。
决定性结果是,在这种评分方式下,任务完成与授权合规并不一致。对来自 11 个模型的 2,211 个单次运行模型—任务配对进行评估后,15.2% 出现了附带损害;在目标已实现的运行中,仍有 12.8% 存在附带损害(第 6.1 节)。DeepSeek V3.2 和 GPT-5.4 的目标达成率几乎相同,分别为 87.6% 和 88.1%,但两者的 CD 相差 16.4 个百分点;报告的按模板聚类的 95% 区间为 +8.9 至 +24.8 个百分点(第 6.2 节)。因此,在这个基准中,目标达成率并不能决定授权合规性。
一种可迁移的研究做法是,在运行智能体之前先定义授权集合,然后在任务成功率之外,再报告一个轨迹层面的结果:每次成功的状态变更是否都获得许可。随后改变任务结构,例如依赖关系、跨工具影响和歧义,就可以揭示这两项指标在哪些情况下出现分离。边界条件很重要:实验涵盖的是办公类工作流,授权判断部分依赖策略,每个模型—任务配对只运行一次;作者指出,不应将这些比率和排名外推到其他领域(第 9 节;附录 A.6)。
读这篇论文,可以了解一种具体的评估设计:重放智能体成功执行的写入操作,并将授权合规性与任务完成情况分开评分。
来源位置
科学智能体的记忆需要决策有效性测试,而不只是检索评估
The Right Fact, the Wrong Decision: SciValidityBench for Scientific Agent Memory
论文针对一个具体缺口:大多数智能体记忆基准将长期记忆视为检索问题,即智能体能否从漫长且不断演变的历史中找回相关记录。SciValidityBench 则评估科学使用的有效性:在决定如何解释证据的状态条件下,记忆中的证据是否符合影响决策的资格。两者的区别很具体:同一项报告的测试结果,如果结果指标和停止规则事先已经确定,可能支持确认性结论;但如果研究者是在查看了二十项结果后才选定结果指标,它就只能支持探索性结论。
SciValidityBench 是一个可执行的基准生成框架,包含 64 个 TaskSpec,覆盖五个有效性模块和六个科学领域。每个 TaskSpec 将生成的实验历史与科学状态定义、程序化决策预言机、受控干预和自动评分结合起来。其 SciStateForge 编译器—读取器框架将分散的历史转化为明确的决策支配状态。反事实配对和针对性的损坏—修复对照,随后用于检验模型是否使用这些依赖关系,以及能否定位失败。内容相同的扁平视图和类型化视图有助于区分:改进是来自显式呈现支配决策的状态,还是来自某种特定的图序列化方式。
主要实验矩阵使用了四个开放权重读取器、64 个 TaskSpec、十个未见过的种子和五种记忆视图。在四个受测开放权重模型系列中,类型化编译状态的有效动作率比通用事件图高 9.2–18.8 个百分点。传统 BM25 检索并未在不同模型系列中重现编译状态带来的提升:对大多数读取器而言,其效果很小或为负,对 Mistral 则有适度的正向结果。作者将表征对照解释为:主要改进与明确呈现支配决策的状态有关,不过最有效的呈现方式因读取器而异。
该基准使用程序生成的历史和虚构的临床情境。因此,论文报告的覆盖范围仅限于刻意生成的任务目录和四个开放权重模型系列;论文并未证明同样的效果适用于已部署的科学智能体或自然发生的研究历史。修复对照的结论也有条件:针对性修复只对三个读取器选择性地恢复了有效决策,而 Phi 相较于匹配的无关修复并未出现相应的恢复。
一种可迁移的评估方法是固定被记忆的事实,改变历史中授权使用该事实的条件,并对动作而不只是检索进行评分。将反事实配对与精确恢复、编辑匹配的无关修复结合起来,可以区分正确答案究竟只是碰巧出现,还是确实依赖支配决策的状态。
读这篇论文,可以了解一种具体的评估模式:保持事实真实且不变,改变使其可被采纳的隐含条件,并通过反事实与匹配修复对照,检验智能体是否遵循状态条件,而非仅仅检索内容。