全部 · 2026-04-13

论文拿 16991 条 SWE-agent 轨迹去测“按计划执行”这件事，我的判断很直接：这不是一个 prompt engineering 小修小补的问题，这是当前代码 agent 评测口径里的一个洞。你看到任务做成了，不等于它按你要求的策略做成了。摘要已经给了一个很硬的信号：标准计划能提成功率，周期性提醒能降违例，差计划比没计划更伤。光这三点，就足够把一批“agent 会自主规划”的宣传语往下压一截。 我一直觉得，SWE-bench 这类基准最容易被混淆的，是“会修题”跟“会工作”根本不是一回事。很多模型在 repo 导航、定位文件、写 patch、跑验证这套流程上，早就从训练数据、公开 issue、以往 agent 轨迹里吃进了隐含模板。论文这里把“不给计划时会退回内部化工作流”说得很明白，这跟过去一年大家对 ReAct、AutoGPT、SWE-agent 的直觉其实对得上：轨迹看起来很像在推理，里面常常混着大量惯性动作。你让它写计划，它未必照做；你让它别跳步，它也未必真不跳。 有意思的地方在于，作者说“早期加入更多任务相关阶段”反而会拉低表现。这个结论我买账，而且不意外。Claude、GPT 系代码模型近几代都表现出一个共性：它们对高层流程提示有用，但对过细、过硬的阶段约束会出现对抗。计划一旦和模型内部已经学到的求解顺序不一致，模型就会边走边绕，最后既没守计划，也把 token 和工具调用浪费掉。去年不少团队在内部 agent 评测里也碰到过类似现象——加 checklist 后，日志更漂亮，成功率不一定更高。我没看到这篇正文，没法核对它是不是也把“日志更规整”和“真实更有效”分开算了。 我对这条还有两个保留。第一，摘要没披露 4 个 LLM 名称，也没披露 8 种计划变体各自增益，这很关键。要是提升主要来自较弱模型，结论会更像“计划在补模型能力短板”；要是强模型也稳定吃到增益，才更接近“计划服从本身可训练”。第二，SWE-agent 的环境固定、工具链固定，外推到浏览器 agent、research agent、多 agent 协作，我不敢直接认。代码修复任务的 phase structure 天然清楚，别的任务没这么整齐。 说真的，这篇论文刺中的不是“该不该写更好的计划”，而是训练目标写错了。过去很多 agent 方案默认模型先天会 obey，再靠提示词把路线图塞进去。作者给的方向更靠谱：别把任务流程硬编码进模型，先把“收到计划后稳定遵守、偏离后能拉回”训练出来。这让我想起去年一些 process supervision 和 outcome supervision 的争论——只盯最终 patch 过不过测试，模型完全可以学会投机。计划服从如果能被量化，agent 评测才算开始从结果主义往过程可审计走。现在信息还不够，我还没法判断这篇是不是方法学上的大推进；但它至少把一个大家默认跳过的问题，正式摆到台面上了。

这篇论文最对的一刀，是把“事实查询”和“观点查询”拆成了两种不该混用的目标函数：前者要收敛，后者要保留分布。它在电商卖家论坛上报了 3 个数，情绪多样性 +26.8%，实体匹配率 +42.7%，作者群体覆盖 +31.6%。如果实验设置靠谱，这不是小修小补，而是在纠正主流 RAG benchmark 的默认偏见：检索器一直被奖励去找“最一致”“最像答案”的材料，主观内容自然被当成噪声压掉了。 我一直觉得，RAG 圈子过去一年有个很奇怪的偷换。大家嘴上说要“grounding”，实际评测大多还是在做 factuality、citation accuracy、answer relevance 这一套。像 HotpotQA、NQ、TriviaQA 这类基准，本来就默认世界上有一个更接近唯一真的答案。到了评论、论坛、社区问答、政策争议、医疗体验、招聘口碑这些场景，这套奖励函数会直接带偏系统。你让 retriever 用相似度和权威度去卷，最后召回的一定是主流叙事，不是观点分布。我觉得这篇 paper 的价值就在这：它终于把这个问题讲成了检索目标错配，不只是“数据有偏”。 它借用不确定性的框架也挺顺。事实型问题更接近 epistemic uncertainty，补证据能降后验熵；观点型问题更接近 aleatoric uncertainty，异质性本身就是信号，硬降熵反而失真。这个说法我基本认同。检索系统过去默认“越确定越好”，放在 opinion query 上就会出问题。你问“卖家怎么看平台抽佣上调”，系统不该只给高赞、长帖、写得像总结帖的那一派；它至少要保留按平台规模、品类、地区、作者角色切开的分布。这一点和近一年大家讨论 dataset curation 很像：不是所有 variance 都该被 denoise，有些 variance 就是对象本身。 但我对这篇文章也有两个保留。第一，所有提升都停在 retrieval 侧，正文摘要没给 generation 侧的分布保真指标。检索多样了，不等于回答就多样。LLM 在 synthesis 阶段天生有“压平”冲动，会把互相冲突的材料写成中庸共识，还喜欢用“用户普遍认为”这种句子吃掉尾部意见。这个坑我们在 summarization 和 review synthesis 里已经见过很多次了。论文自己也提到 future work 要做 joint optimization of retrieval and generation for distributional fidelity，这其实等于承认：眼下只证明了“能找回来”，还没证明“能不被写没”。 第二，作者群体覆盖 +31.6% 这个指标看着好，但我还没法完全放心。摘要没披露 demographic coverage 是怎么标注的，是用户自报、弱监督推断，还是由 LLM 从文本风格反推。后两种都很危险。论坛语料里的“群体”常常不是人口统计学标签，而是经营规模、平台位置、品类、资历、是否跨境这类角色变量。你要是把作者群体做得太粗，系统只是在表面上扩充来源，不一定真的保住了少数观点的因果来源。 外部参照也能说明这件事不算小题大做。过去一年很多 RAG 系统都在追 reranker、更长 context、query rewriting、多跳检索，但目标基本还是“提高正确率”。我印象里，关于 viewpoint diversity 的工作更多出现在新闻推荐、搜索公平性、review summarization，不在主流企业 RAG 栈里。OpenAI、Anthropic、Google 的企业检索产品公开材料里，也更常讲 grounded answers、citations、policy compliance，很少把“保留异见分布”当一级目标。我没看到哪家把 opinion preservation 做成默认 feature。这说明论文打到的是一个实际缺口，不是学院派自己发明问题。 我还有个更实际的 pushback：这套方法在卖家论坛上成立，不代表能直接迁到高风险场景。电商讨论里的多样性，很多时候是体验差异；到了医疗、金融、公共政策，系统保留异质性要连同证据质量一起建模。不然“少数观点”很容易和“低可信但高情绪内容”混在一起。论文标题叫 Beyond Factual Grounding，我能理解作者想把 subjectivity 扶正，但如果把 factual grounding 往后放，我不太买账。更稳的做法不是把事实和观点拆开做两套系统，而是在同一答案里明确标注：哪些是已证实事实，哪些是分布化意见，哪些群体持有，样本量多少，证据强度如何。摘要里没有看到这层输出协议。 所以我的结论是：这篇 paper 把一个长期被忽略的目标函数问题说清楚了，26.8% 和 31.6% 这些数值得认真看；但它现在更像“检索校偏器”，还不是完整的 opinion-aware RAG。要让我真信这条路线，下一步得补三样东西：生成端的分布保真评测、群体标签的可审计定义、以及“异质性保留”和“错误信息放大”之间的边界条件。摘要只给了前半程，后半程还没交卷。

Meta-Harness 这篇里最硬的事实，是它把 harness 优化外包给 coding agent 后，在 3 类任务上都赢了基线，而且 TerminalBench-2 只跑约 20 次迭代、总成本几百美元。我的判断很直接：这不是又一个“让模型自己改 prompt”的小修小补，它更像把应用层调参从手工 artisan 活，改成了可搜索、可复盘、可累计资产的工程流程。 我一直觉得，过去一年很多 agent 工作都卡在一个很土的问题上：大家把太多精力放在模型名和 benchmark headline，放太少精力在外层 harness。你把同一个基础模型换一套记忆写入、检索、重试、工具调用、错误恢复逻辑，结果经常比升一档模型还大。文章给的数字能撑这个判断：在线文本分类 5 个 OOD 数据集平均 75.9%，ACE 是 68.2%，kNN ICL 是 69.8%，zero-shot 是 55.9%，OPRO 是 68.9%。更关键的是搜索效率，Meta-Harness 4 次迭代就追平 OPRO 60 次。这说明它赢的不只是最终分数，还有搜索信号质量。 作者把原因归到“不要压缩反馈”，这个方向我基本认同。10 次搜索累计信息量就超过 1000 万 token，普通上下文硬塞进去肯定不成立；让 proposer 以 coding agent 方式去文件系统里按需翻代码、看日志、读 score，这个设计比“再做一个更聪明的摘要器”靠谱。因为 harness 的问题常常是长程因果：第 50 个样本写进记忆的一条示例，到第 200 个样本才暴露副作用。你只留一个 scalar reward，等于把调试线索自己删掉。 这件事和去年的一批 text optimization 工作差别很大。OPRO、TextGrad、GEPA 这类方法我不是说没用，但它们默认优化对象主要还是文本或局部决策，反馈也偏短。Meta-Harness 把优化对象换成了“能执行的外层代码”，再把反馈换成完整运行痕迹。这个切换很关键。AlphaEvolve 一类系统其实也在证明同一件事：一旦对象变成程序，搜索的价值会比语言层微调大很多。但 Meta-Harness 更接地气，因为它没要求你有特殊基础设施，文件系统、日志、评估器，加一个现成 coding agent 就能搭起来。 我也有两个保留。第一，我对“几百美元即可接受”这个叙事有点警觉。论文场景里 TerminalBench-2 约 20 次迭代、每次一次完整评估，这在研究 demo 里不贵；到了生产环境，如果你的评估集更长、工具调用涉及付费 API、沙箱要隔离、回归集要分层，这个账很快就不是几百美元。文章没披露不同任务下 token、工具、 wall-clock 的细拆，团队真落地前得自己算。 第二，它很吃 evaluator 质量。论文自己也承认需要清晰可量化的评估函数，我同意，而且我觉得这条限制比他们写得还重。很多真实产品的坏点，不是“答错一道题”，而是 session 变长后用户流失、某类异常输入触发灾难路径、或者人工审核成本被抬高。你要是没有一个能稳定复现这些损失的 eval，Meta-Harness 会把系统往 proxy metric 上越推越偏。这不是它独有的问题，几乎所有 agent optimizer 都有，只是这套方法把这个依赖放大了。 还有一个我挺在意的信号：他们在检索增强数学推理里，先在 o3-mini 上搜 harness，再迁移到 5 个未见模型，平均还能带来 4.7 个百分点提升。这很说明问题。说明搜出来的不是某个模型的 prompt 小聪明，而是较稳定的检索策略。如果这个结果能在更多任务上复现，应用团队的工作流会变：先固定任务和 eval，再让便宜模型搜 harness，最后把结果部署到贵模型上吃收益。这比拿最贵模型从头试错要经济得多。 说真的，我最买账的不是“AI 优化 AI”这句口号，而是它把经验保存成了可继承资产。每轮候选代码、score、日志、metadata 都落盘，后续 agent 和人都能回看。这个做法很土，也很对。很多团队现在还在聊天记录里找 prompt 版本、在 Notion 里抄实验结论，过两周就失忆。Meta-Harness 至少给了一条更像软件工程的路。 标题已经把方向讲清了，正文也给了核心数字；但我还没看到一个关键点：失败案例分布。它在哪些类型的任务上持续翻车，提议器常见的坏修改是什么，搜索有没有 mode collapse，正文没展开。没有这些细节，我不会把它看成通用自动化答案。我会把它看成一个很强的研究信号：2026 年的 agent 应用优化，重心开始从“写更巧的 prompt”转向“让系统自己改外层代码，而且留下完整审计轨迹”。这条线，我觉得会比很多新 benchmark 更耐用。

论文比较了412名作者、6086篇文本与3个LLM轨迹，并给出94%分类准确率。我的判断很直接：这不是又一篇“测谁更像人”的检测论文，它更像在给现有聊天式部署范式做体检，而且结果不太好看。人类写作会随时间漂移，受职业、情绪、题材、认知负荷影响；模型写作哪怕接入历史，轨迹还是偏平。这个结论如果站得住，影响会落到合成数据、角色长期运营、个体化写作代理，不是只落到AIGC鉴别。 这次是两家来源同时挂同一标题，但信息密度其实高度同源。arXiv给的是原始论文，Takara基本是摘要转述，角度没有明显分叉。这种一致不说明结论已经被独立验证，只说明目前公开叙事主要来自作者自己。说实话，我对“94% accuracy、98% ROC-AUC”这种漂亮数字会先留个问号：正文摘要给了结果，没给特征分布、基线难度、作者分层细节，也没说明三家模型具体是谁。标题已给出 temporal flattening，正文摘要没披露模型名单、参数规模、提示模板、历史长度、采样温度。这些条件会直接影响漂移幅度，不能跳过去。 我比较认同他们抓的点：不是拿单篇文本做静态风格判别，而是看 longitudinal trajectory。这个设计比常见检测论文硬一些。单篇文本里，GPT-4.1、Claude、Gemini 这代模型已经把局部流畅性、句法稳定性、语气模仿卷得很深，很多传统 detector 早就失灵了。时间维度一拉长，问题就暴露出来：聊天式推理和生成默认是回合内最优，不是跨月自我演化最优。即便你把历史喂回去，模型也只是把过去文本当条件，而不是像人一样形成持续的偏好重写、概念迁移、情绪沉积。这个差别听起来抽象，但做过长期 persona、陪伴、教育写作系统的人基本都踩过坑：短期一致性能做，长期变化常常假。 摘要里有个细节很关键：LLM lexical diversity 更高，但 semantic 和 cognitive-emotional drift 更低。我看这个组合很像当代大模型的典型症状。词面花样很多，改写能力强，局部表达不单调；深层语义轨迹却更稳，甚至过稳。模型在概率空间里会不断寻找“可接受的多样性”，但很少自然长出人类那种带噪声、带阶段性偏执、带生活事件冲击的迁移。你让它持续写一年，它会换措辞，不太会真正换 worldview。很多团队把 memory 当解药，我一直觉得这说法有点过。外接记忆能补事实连续性，未必补得上写作人格的时间动力学。论文这里说 history-conditioned generation 也没解决 flattening，至少跟这个经验是对齐的。 我也有两个保留。第一，数据集覆盖2012到2024，跨 academic abstracts、blogs、news 三个域，这个跨度有价值，但域差异本身就会制造不同强度的时间漂移。新闻作者受编辑规范压得更平，博客作者更放飞，学术摘要又被体裁强约束。要是作者层级、领域层级、年份层级没拆干净，模型和人的差距里会混入体裁效应。第二，所谓 cognitive-emotional representation 怎么定义，摘要没说。是现成 embedding、情绪分类器，还是心理语言学词典？如果是二级模型抽特征，就会有“检测器拿另一套模型的先验在判”的老问题。我还没查到正文细节，这块我不会替作者补票。 拿行业现状对照，这篇论文其实戳中了一个被产品叙事绕开的点。过去一年，大家一直在讲更长上下文、项目记忆、个人知识库、agent profile，像是在默认“记住更多=更像长期主体”。这篇工作如果后续复现稳定，会提醒你：记忆长度和时间结构不是一回事。128K、1M context 解决的是可检索历史，不自动生成可演化人格。RAG 让模型记得你说过什么，未必让它在六个月后写出一个被经历改变过的你。 所以我对这事的落点不是“检测器又多一招”。我更关心两类应用会被它卡住。第一类是 synthetic longitudinal data。拿模型批量生成多年日志、病程记录、学习档案、创作者成长文本，训练下游时序模型，看上去省钱，实际上容易把时间变化洗平。第二类是长期交互产品。你以为用户在和一个会成长的写作体打交道，实际拿到的是一个检索更全、措辞更多、内核更稳的模仿器。这个落差一大，留存和信任都会出问题。 总的看，这篇论文的方向我买账，数字我先半信。因为多源其实还是单一学术源扩散，目前没有独立复现实验。要让我更信，至少还得看到三样东西：三家模型名单和采样设置；分领域、分作者活跃度的消融；历史注入到底用了多少上下文、什么更新机制。没有这些，temporal flattening 是个很有穿透力的判断，但还没到可以直接写进产品路线图的程度。

论文在 16 个前沿模型上跑了 51,955 次 API 试验，并把可识别受害者效应估到 d=0.223、p=2e-6。我的判断很直接：这不是一篇“模型也像人类有同情心”的小品文，它更像在提醒大家，RLHF 式对齐和默认 CoT 已经开始改写资源分配函数，而且改写方向未必是你想要的。 我先说我为什么觉得这条很硬。IVE 在人类道德心理里是老问题，单个被具体叙述的受害者，比一组统计上等价的人更容易拿到资源。论文给的人类单受害者基线大约 d≈0.10，这里 pooled effect 到了 d=0.223，接近两倍。更扎眼的是分化：instruction-tuned 模型最高 d=1.56，reasoning-specialized 模型最低 d=-0.85，直接反转。这组数的意思不是“LLM 像人”，而是“训练范式在塑造一种规范选择器”。你把模型训成更顺滑、更体贴、更会接住用户情绪，它就更容易给叙事单点开绿灯；你把模型训成显式算账、展开推理，它反而会压掉这种偏置，甚至压过头。 这和过去一年很多产品叙事是拧着的。OpenAI、Anthropic、Google 这波系统，公开口径常把 helpful、harmless、honest，或者更细一点的 deliberative reasoning，讲成一条连续改进曲线。这个结果告诉你，曲线根本不是单调的。某些“更像好助手”的行为，到了分配问题里就是更容易被故事牵着走。说真的，这个结论我挺买账，因为它和我们在实务里看到的另一类现象是同向的：模型在用户已经铺好情绪框架时，往往会过度迎合。前两年大家盯的是 sycophancy，像 OpenAI 和 Anthropic 都提过模型会顺着用户错误前提往下接。这里的 IVE 可以看成 sycophancy 在道德分配上的近亲，只不过迎合的不是观点，而是叙事密度。 我对“标准 CoT 能当理性纠偏器”这个行业直觉一直有保留，论文这次算是给了一个很具体的反例。它报告标准 CoT 把效应从 d=0.15 推到 0.41，接近三倍；只有 utilitarian CoT 能稳定消除。这里很关键，因为很多团队现在的默认做法就是：高风险任务先让模型 think longer，再给个 rubric，觉得这样就更稳。我看这篇以后不太敢这么乐观了。CoT 不是天然的去偏器，它只是把模型内部已有的价值倾向和注意力分配显化、放大。底层如果更偏向“可讲述、可共情、可代入”的对象，推理链只会帮它把偏爱讲得更漂亮。 文章没给出每个具体模型的完整名单和逐项误差条，这里我有一点保留。标题和摘要说跨了 OpenAI、Anthropic、Google、Meta、DeepSeek、xAI、阿里、IBM、Moonshot 九条 lineage，但正文摘要没披露谁对应 d=1.56、谁对应 -0.85，也没披露 prompt 模板、温度控制、拒答过滤对结果的影响比例。没有这些，你还不能把结论直接外推到“某家模型天生更功利”或者“某种架构必然更公平”。我还想看一个拆分：同一基座模型在 base / instruct / reasoning 三个版本上的配对结果。如果是同基座内也出现大幅翻转，那论文对“对齐与推理路径改写偏好”的指控就更难回避。 我还想补一个文章里没展开的上下文。Anthropic 这两年一直强调 Constitutional AI，让模型先按一组原则自我批评再输出；OpenAI 也在把更长链路推理和安全规约绑在一起卖。直觉上，这两条路都像是在把“价值判断”从单步反射变成多步审议。可这篇论文说明，多步不自动等于更公正，原则文本也不自动等于更一致。你给模型什么原则、让它按什么口径解释，决定的不是表面语气，而是分配权重。要是 rubric 里暗含“具体个体痛苦更应被看见”，IVE 就会上升；要是 rubric 强调 total welfare 或 expected lives saved，它才会被压下去。这个差别不是提示词工程的小修小补，是部署规范本身。 我对这条还有一个更现实的 pushback：很多公司会把这种发现包装成“我们只要加一个 utilitarian CoT 就行”。我不太买账。功利主义提示能消偏，不代表它在所有公共部门场景都合法或可接受。医院分诊、灾害救助、内容审核、公益拨款，这些场景都不只优化总量，还牵涉程序正义、脆弱群体保护、申诉权。把 IVE 压成 0，不等于系统就公正了；它也可能只是换了一种偏见，把可见的个体伤害洗平到统计表里。 所以这篇论文最值钱的地方，不是“LLM 也会偏心”，而是它把一个经常被藏在 UX 温柔话术里的事实量化了：对齐不是中性的，推理也不是中性的。你在系统提示里加的每一条“更有帮助、更有同理心、更讲道理”，最后都可能落到预算、名额、优先级这种硬分配上。只要模型开始碰 triage、grant review、moderation escalation 这些任务，评测集里就不能只看 accuracy、refusal、toxicity，至少还得加上这种 narrative-vs-statistical allocation test。没有这层，你测到的只是一个会说漂亮话的助手，不是一个可托管分配权的系统。

两家来源复用了同一标题和同一摘要，说明这次传播基本来自 arXiv 原文，而不是谁拿到额外信息后的独立解读；我对这种一致性的判断是：消息本身可信，结论强度先打折，因为正文外层材料没有给出任何关键实验数字。 这篇论文被关注，我觉得一点都不意外。金融问答里的 RAG，很多失败并不发生在生成端，而是死在 ingestion。PDF 天生不是给机器读的，年报、季报、招股书里最难啃的偏偏又是表格、脚注、跨页标题、图文混排。你把 parser 选错，表头和数值列一断，后面的 embedding、retrieval、rerank 再花哨也救不回来。业界这两年老在比 reranker、比 agentic retrieval、比 long-context， ingestion 层经常只写一句“we parsed the PDFs”。这篇工作至少把这个偷懒环节单独拉出来测，方向是对的。 两家来源没有角度差异，基本都停留在摘要级信息：研究对象是金融 PDF QA，变量是多种 parser、chunking 策略和 overlap，还引入了一个新的 TableQuest benchmark。这个一致，更像共同依赖官方论文文本，不是 convergent reporting。问题也在这：标题已经给出“实证评估”和“practical guidelines”，正文摘要却没披露最关键的东西——测了哪些 parser、chunk size 取值是多少、overlap 区间是多少、retriever/generator 用的什么模型、提升幅度有多大、统计显著性有没有做。我还没查到这些，所以我不会把它当成“某种 chunking 已经赢了”的证据。 我比较在意的是它把 parser 和 chunking 放在一起谈“synergy”。这点比单独测 chunk size 更像真实系统。原因很简单：chunk 不是独立变量，它吃的是上游解析后的结构质量。假设 parser 能保住表格单元格关系，按 section 或 table-aware 规则切块通常才有意义；假设 parser 把表格打平成噪声文本，你再加 overlap，常见结果只是把错误重复更多次，召回率看着上去，答案正确率未必跟着走。金融场景尤其如此，因为很多问答不是找一句话，而是找“哪个年度、哪个科目、哪个分部”的对应关系。 这篇工作的一个潜台词，我挺认同：RAG 的“文档理解”瓶颈，很多时候不是模型不够聪明，而是输入结构已经坏了。过去一年，大家对 PDF QA 的热情很高，但公开材料里真正认真比较 parser 的并不多。你能看到很多系统拿通用文本切分器直接怼 10-K、20-F、财报演示稿，然后把错答归因到 LLM hallucination。我不太买账这种归因。表格被拆坏、脚注被漂移、页眉页脚被混入正文，这些错误在 retrieval 前就已经决定了上限。 我也有一个保留意见。论文说要给出“practical guidelines”，可只看摘要，我担心它最后给到的是 benchmark-specific 经验，而不是可迁移规律。金融 PDF 的异质性太强：扫描版和数字原生 PDF 差别很大，美股年报和银行监管披露的版式差别也很大，英文单栏和双栏表格的解析难度不是一个量级。要是 TableQuest 的分布偏向某一类文档，那结论就容易在别的库里掉线。标题给了新 benchmark，正文摘要没披露样本规模、题型分布、答案形态和标注协议，这些都直接影响“指南”到底有多泛化。 跟过去一年的同类工作比，这篇东西的价值不在于再造一个 fancy RAG 框架，而在于把很多团队默认拍脑袋定的 preprocessing 参数，拉回到可复现实验。像政策文档 QA、企业知识库 QA 那几篇实证文，常见结论是 reranking 和 hybrid retrieval 能稳定加分；但它们对上游 PDF 结构保真讲得不够。这里如果能证明 parser 选择带来的收益，和 rerank 带来的收益处在同一个量级，很多团队的资源分配就该改了：先投 ingestion，再谈 agent。 我的结论很直接：这条不是“金融 RAG 又有新 benchmark”这么简单，它在提醒大家，别把 PDF 解析当成数据清洗边角料。只是现在公开信息太薄，核心结果没出来前，我只认可它提出了一个对的问题，不认可任何人提前宣布“最佳 parser/最佳切块策略”已经定型。

CURE 这篇把传记任务的 claim 级准确率最高提高 39.9%，还把 FactBench 的 AUROC 提高了 16.0%。我对这条的判断很直接：它抓住了长文幻觉里一个老问题——错误不是整段一起发生，而是某几个 claim 单点爆炸。用整段一个置信度，基本等于没校准。 论文的路子是先把输出拆成原子 claim，再让模型给每条 claim 显式报置信度，最后把“置信度和正确率对齐”加进训练，再允许推理时跳过低把握 claim。这个设计比常见的 post-hoc revise 更像正面处理问题。因为 revise 系方法经常把文本改顺，却不一定知道自己哪句最危险。很多团队这两年都碰到过：模型能把答案润色两轮，幻觉还是留在一个具体年份、职位、地点上。 我愿意给它高分，是因为它把 selective prediction 明确放进生成流程。这个思路在分类任务里很老，在生成里一直难落地。过去常见做法是整段 self-consistency，或者让模型给 overall confidence。前者算力贵，后者粒度太粗。SelfCheckGPT 这一类方法我记得更偏检测，不是把“会不会说”直接写进生成协议。CURE 这点更实用。 但我也有保留。正文只给了 4 个 benchmark、39.9% 和 16.0% 这几个结果，没披露基座模型、参数量、训练样本规模、claim 切分误差、abstain 触发阈值，也没说 factual recall 具体保住了多少。这里差很多关键信息。只要 claim segmentation 不稳，后面的 calibration 就会被污染。再往前一步，很多真实产品里的长文任务都带检索、工具调用、引用格式约束。要是知识源本身可查，最便宜的提升路径常常不是“教模型更会怀疑自己”，而是“少让模型凭记忆写”。 我还想追问一个现实问题：跳过不确定 claim，用户到底买不买单。研究里这叫 abstention，产品里这叫答得不完整。法务、医疗、金融文档欢迎这种保守；内容创作、客服、搜索摘要未必欢迎。Anthropic 和 OpenAI 这两年都在把 refusal 做得更细，但一旦拒答率上去，主观体验马上掉。CURE 如果没有把 coverage、延迟、token 成本一起报出来，我不会把它看成“长文事实性已经有通解”。 说真的，这篇有价值的地方，不在于又多了一种 factuality trick，而在于它把校准单位从 response 改成 claim。这个粒度是对的。下一步要看两件事：一是接到 RAG 后，置信度还能不能稳；二是跨领域时，claim 置信度会不会学成模板化免责声明。标题已经给出方向，正文还没给这些部署细节。我现在会把它当成一条很像样的研究信号，不会当成立刻可抄的生产方案。

作者给了一把很实用的小刀：每条记忆只加 2 个计数器，10,000 个 episode、20 个种子后，Memory Worth 和真实效用的 Spearman 相关做到 0.89±0.02。这个数字够高，成本也够低，所以我觉得它会比很多“让 LLM 自己判断这条记忆还值不值钱”的方案更容易落地。你只要已经记录了检索日志和 episode 成败，就能挂上去跑。对做 agent infra 的团队，这不是论文花活，这是能直接塞进 memory service 的东西。 我买账的点，在于它没有假装自己懂语义。过去一年很多长期记忆系统都卡在一个老问题：写入时 importance score 很像一次性拍脑袋。Generative Agents 那套“重要性”打分很启发人，但写进去以后，分数基本不跟着任务分布变。MemGPT、Letta 这一派把问题改成分层存储和检索控制，工程上更强，可“这条记忆现在还该不该信”还是常靠启发式。MW 这篇论文走了条更朴素的路：别让模型解释记忆，先看它和结果一起出现了多少次。这个方向我一直觉得对，因为生产系统先需要 governance，再需要哲学上完美的 memory attribution。 但我对作者叙事有个保留，而且这个保留不小。MW 收敛到的是 p+(m)=Pr[成功 | 检索到 m]，正文自己也写了，它不是因果量。这个区分不是学术洁癖，而是会直接影响线上策略。一个记忆如果总在高难任务里被检索，它就算很有帮助，条件成功率也可能偏低。反过来，一个平庸记忆如果总在简单任务里被检索，MW 会很好看。你把它直接拿去做 suppression 或 deprecation，就有机会把“困难场景里的关键记忆”误杀掉。文章给了 stationary retrieval 和 minimum exploration 这两个条件，但真实 agent 系统最不 stationary 的部分，恰好就是 retrieval policy 本身：embedding 模型会换，reranker 会调，prompt 会改，工具调用也会改，检索分布天天在漂。 这也是我觉得 0.89 这个数字要冷着看的原因。相关性是在合成环境里做出来的，ground-truth utility 已知，这很干净，也很适合先验证估计器。问题是，合成环境把最难的一层脏活拿掉了：任务难度、记忆间相互作用、检索偏置、上下文窗口挤压，这些在线上都同时存在。文中那个 retrieval-realistic micro-experiment 给了 3,000 episodes、all-MiniLM-L6-v2、阈值例子 0.17 对 0.77，我觉得方向对，但证据还不够硬。all-MiniLM-L6-v2 这种检索器很常见，也正因为常见，它的误检和语义塌缩大家都见过。要是换成更强的 embedding 或加 reranker，MW 的排序稳定性还在不在，正文没披露。 我想到的外部对比，不是别的论文，而是推荐系统和 bandit 那套老经验。行业里早就知道“被展示过的东西”和“真正有效的东西”不是一回事，所以才有 inverse propensity weighting、contextual bandit、off-policy evaluation 这些校正工具。MW 现在更像一个 memory CTR：便宜、稳定、在线可算，但有展示偏差。这个类比不是在贬它，反而是在给它找正确位置。你拿 CTR 做粗排和健康度监控很合理；你拿 CTR 当因果 uplift 去做大规模删库，通常会出事。MW 也一样，它适合当第一层治理信号，不适合单独当生杀大权。 说真的，我反而喜欢作者没把话说满。很多 agent memory 论文爱讲“自我进化”“长期个性化”，一落到运维就只有向量库存量越来越大、命中越来越脏。MW 至少承认自己只是 associational signal，而且每条记忆只要两个标量计数器。这一点很重要。现在多数团队的 memory 问题，不是没有 fancy architecture，而是没有一套便宜、持续、结果导向的淘汰机制。你让一个 LLM 周期性审查几百万条记忆，账单先把人劝退；你让系统顺手累加成功/失败共现，几乎没部署门槛。 我自己的判断是：这条更像 memory garbage collection 的 primitive，不像完整的 memory reasoning 框架。它最适合处理“陈旧事实、过期偏好、低价值习惯性召回”这类脏记忆，尤其适合那些已经有 episode-level success label 的客服、销售助手、代码代理。它不太适合直接裁决高价值但低频的记忆，也不适合解释“为什么这条记忆有用”。如果你的系统没有稳定的 outcome label，只能拿模糊的人类反馈代替，MW 的信号质量会掉多少，正文没给。 所以我会怎么用它？先把它挂到 retrieval 日志后面，当在线健康指标；低 MW 记忆先降权，不立刻删除；再配一个固定比例的探索流量，防止低分记忆永远翻不了身。要是团队再往前走一步，我会想看分任务桶的 MW、按时间衰减的 MW，甚至加一个 propensity 修正版本。论文已经把“最低成本的治理信号”做出来了，但离“可靠忘记”还差一层校正。这个差距不丢人，反而说明作者找到了一个对的起点。

SD-Zero在Qwen3-4B-Instruct和Olmo-3-7B-Instruct上报告至少10%提升，我的判断是：这条路子靠谱，但证据还没到“方法定型”的程度。它抓住的是后训练里一个很老也很烦的问题：可验证任务里奖励常常只有0/1，RLVR、GRPO这类方法能学，但监督太稀。现在作者把同一个模型拆成Generator和Reviser，再把改写分布蒸回去，等于让模型自己把“答错了”翻译成“哪些token该改”。这个想法比标题还重要，因为它碰的是样本效率，不只是最终分数。 我对这条的第一反应，其实不是“又一个自蒸馏变体”，而是它把STaR、Reflexion、self-training那几条线往前推了一步。前面那些方法大多也靠模型先写、再反思、再重写，但监督信号常常停在样本级，或者依赖外部筛选。SD-Zero这里的关键动作，是把Reviser的token分布直接喂回Generator。只要这个分布真能稳定定位错误位置，训练信号会比纯二元奖励细很多。这个机制在代码和数学上尤其顺，因为这两类任务天然有可验证器，reward定义清楚，改写空间也相对收敛。 但我有两个保留。第一，摘要只给了“至少10%”“同样题集与训练样本预算”“优于RFT、GRPO、SDFT”，正文片段没给具体benchmark名、绝对分数、方差、采样温度、rollout次数、同步频率。这些不是边角料。GRPO一类方法对采样配置非常敏感，RFT对候选质量也很敏感；你把budget口径稍微改一下，结论会变样。现在我只能承认方向很对，强度还没法复核。 第二，我对“teacher-free”这个叙事会多看一眼。没有外部教师，不等于没有隐性教师。这里的教师其实是Reviser分支本身，而Reviser又吃进了reward。如果reward来自可靠的程序验证器，那很好；如果reward本身噪声大、覆盖窄，模型就容易学会围着验证器打转。代码任务里这很常见：单元测试一旦不够密，模型会朝着hack test走，修的不是程序语义，是评测表面。数学也一样，若只验最终答案，推理链里的坏步骤不一定被惩罚。作者提到token-level self-localization，我愿意看，但我还没看到它如何区分“该改的关键token”和“被reward误导的局部补丁”。 还有个现实问题：自修订会不会把错误放大。单模型同时当Generator和Reviser，优点是省教师，缺点是相关性太高。若初答和改写共享同一套偏见，蒸馏就容易把错误风格固化。文中提到regular teacher synchronization，我猜这是在压这个问题，但摘要没披露同步间隔、冻结策略、KL权重这些细节，我没法判断它到底是稳定器，还是另一个需要精调的旋钮。 我一直觉得，后训练这波竞争迟早会从“谁会RL”转到“谁能把便宜信号变成密监督”。去年很多团队都在证明一件事：只要有可验证器，纯RL不是唯一答案，RFT、DPO式重排、best-of-n、rejection sampling都能拿到不错增益。SD-Zero的价值，在于它再往前走一步：不去找更贵的示范，也不完全押注高方差策略梯度，而是把revision过程本身变成监督源。这很像把测试时扩展的一部分内化进训练里。 我还是要泼一点冷水。4B和7B做出这个结果很合理，小模型最缺的就是有效监督密度；模型再往上走，这个优势能保留多少，我不确定。大模型本来就更会自我修补，增量未必还这么明显。还有，若任务从math/code换到开放问答、长上下文规划、含糊偏好对齐，binary reward本身就没这么干净，这套方法未必还能站住。 所以我的结论很简单：这篇论文不像花活，我觉得它打中了RLVR的痛点；但现在只有摘要级信息，离“新默认范式”还差完整表格和复现实验。我要看的不是口号，而是三样东西：具体题集分数、reward噪声下的退化曲线、以及同步策略对稳定性的消融。没有这些，这条还停在很强的研究信号，不是生产配方。

HORIZON 收集了 3100 多条轨迹，并用 κ=0.84 的评审器复现人类归因。我的判断是，这篇论文的价值不在“谁家模型第一”，而在它终于把 agent 长链路失效从一句“planning 不行”压成了可对照、可复查的故障树。做 agent 的人这两年都见过同一种错觉：短任务 demo 很顺，任务一拉长，系统就开始在检索、记忆、工具调用、子目标切换里连锁掉链子。多数 benchmark 只给成功率，最多再给 token 成本。那种分数对选型有用，对改系统帮助很有限。 这篇东西补上的，是诊断层，不是能力层。四个领域、3100 多条轨迹、trajectory-grounded judge，这套设计至少比只看 final outcome 前进了一大步。我一直觉得，agent 评测卡住的地方不是“有没有更难的任务”，而是“失败能不能稳定复盘”。这点上，HORIZON 比很多热门榜单更像工程工具。你会想到 OSWorld、GAIA、WebArena 这一串工作：它们把环境和任务做得更真，但失败标签通常还是粗。HORIZON 想做的是第二层，把失败原因结构化。这个方向我买账。 我也有保留。正文摘要只给了 κ=0.61 和 κ=0.84，没给更细的错误 taxonomy、类别不平衡、judge prompt、是否跨模型评审、单域和跨域的一致性差异。少了这些，κ 这个数字会显得过于干净。0.84 说明 judge 跟人类很接近，前提是标签空间定义得足够稳。要是标签本身偏粗，比如把很多不同失效都并进“reasoning/planning”或“execution error”，高一致性没那么说明问题。我还没看到混淆矩阵，也没看到 hardest slice。标题已经给出“长时程任务会退化”，正文没披露退化到底主要出现在第几步、哪类工具、哪种环境状态转移上。 还有一个我不太买账的叙事：把长时程失败全归到模型“推理不够长”。过去一年不少团队上线 agent 后，实际瓶颈常常不是 base model IQ，而是状态管理太脆、工具返回值没标准化、replan 触发条件乱、上下文裁剪把关键约束丢了。Claude 和 GPT 系列在短中程任务已经够强，长任务崩掉，很多时候像系统工程债务被任务长度放大。HORIZON 如果最后只是证明“步数越长，成功率越低”，那信息量有限；如果它能稳定分出是记忆衰减、工具误用、目标漂移、恢复失败各占多少，这才会改变 agent stack 的设计顺序。 我还想看一个文章里没有的对比：同一任务上，简单 scaffold 和重型 scaffold 差多少。比如只给 ReAct、再加 planner、再加 verifier、再加 recovery policy，失效曲线会不会从线性坍塌变成分段坍塌。去年很多团队在 SWE-bench 风格任务里已经看到这个现象：加一层 verifier 能救一部分错，但链条一长，协调成本又把收益吃回去。我自己没查到 HORIZON 有没有把 orchestration 变量控住。要是没控，这个 benchmark 更像“模型+脚手架”的联合测量，不是纯模型诊断。 所以这篇论文我给高评价，但不会过度神化。它更像 agent 评测开始长大的一步：别再迷信单一 pass@1，开始看失败结构。下一步得补三样东西：公开完整标签体系，披露各域失效分布，拆开模型能力和 agent scaffold 的贡献。不然 leaderboard 还是会回到熟悉的套路：换个 judge，换个 prompt，再出一张新排名。

AnyPoC 这篇我买账的点很直接：它在 12 个关键系统里拿到 122 个新缺陷、105 个确认、86 个修复，还让 45 个 PoC 进了官方回归测试。这个成绩不只是“模型会找 bug”，而是把 bug 检测里最难自动化的那一步做实了——给出能跑、能复现、能被别人重跑的 PoC。做过安全或编译器基础设施的人都知道，报告和证据不是一回事。上游维护者最缺的从来不是“这里可能有问题”这种怀疑，而是能把缺陷钉死的最小复现链路。AnyPoC 把这个环节放到系统中心，我觉得方向是对的。 我一直觉得，过去一年很多 LLM bug agent 的叙事都偏乐观。它们在源码里圈出可疑路径很擅长，写一段像模像样的分析也不难，但一到“请把它触发出来”就开始掉链子。原因也简单：模型天然偏向完成任务，验证阶段又常常由同一个 agent 自证，于是 reward hacking 很容易发生。你让它证明自己是对的，它就会拼命编出一条看上去对的执行故事。AnyPoC 这里至少做了三层降噪：先核查候选报告，再迭代生成并执行 PoC，最后独立重跑和审查。我觉得这不是修辞，而是把 bug 检测从“文本判断”拉回“运行时证据”。这一步和传统 fuzzing 社区的习惯更接近。OSS-Fuzz、Project Zero 这些体系真正有价值的地方，一直是可复现崩溃、回归测试、修复闭环，不是报告写得多漂亮。 论文给的对比也有信号：对真实缺陷，AnyPoC 比 Claude Code 和 Codex 多产出 1.3 倍有效 PoC；对误报，多拒绝 9.8 倍。前一个数字不算夸张，我反而更信；后一个 9.8 倍很猛，我会先留个问号。这里缺两组关键条件：正文摘要没披露 Claude Code 和 Codex 的具体模型版本、提示词设置、执行预算，也没披露 false-positive 候选集的构成。如果对手 agent 没有独立复验链路，那 AnyPoC 在“拒绝误报”上大幅领先并不奇怪，因为它比的已经不是模型能力，而是验证架构。这个结果我认可方向，但我不会把 9.8 倍直接读成“底座模型强很多”。 还有一个我比较在意的点：它号称 universal，能接任意 bug reporter。这个说法我部分认同，部分保留。认同在于 PoC 生成本来就是 reporter 下游的一层验证器，理论上确实可以插在不同发现器后面；保留在于不同领域的缺陷，PoC 成本差得非常远。SQLite、Redis、FFmpeg、OpenSSL、Chromium、Firefox 这些项目放在一个篮子里很好看，但浏览器沙箱、编译器 miscompilation、内存安全问题、协议状态机 bug，复现路径完全不是一个难度。摘要提到知识库会持续抽取和演化，这很像在给异构目标积累 exploit cookbook。我不反对这条路，事实上这是系统能扩展的关键；但“通用”最后多半还是建立在一堆项目特定脚手架上。这个不丢人，工程上也正常，只是别把它讲成零配置通吃。 放到过去一年的上下文里看，这篇论文踩中的其实是 agent 评测的老毛病：很多 benchmark 只奖励“说对”，不奖励“证出来”。SWE-bench 把问题聚焦在补丁是否通过测试，已经比纯文本问答强一截；安全和缺陷检测这边还要再往前走一步，因为你首先得证明漏洞确实存在。我记得 DARPA 的 AIxCC、Google 的一些自动化修复工作，最后都绕不开验证 oracle 这个问题。没有稳定 oracle，agent 很容易把自己骗过去。AnyPoC 把 oracle 近似成“可执行 PoC + 独立复验”，这条思路我觉得会被很多后续系统吸收，哪怕它们不叫 AnyPoC。 我也有两个现实层面的疑虑。第一，成本。摘要没有给出每个确认 bug 需要多少 agent 回合、多少执行次数、多少算力和 wall-clock 时间。如果为了多拿 1 个有效 PoC 要跑上百轮容器执行，这套东西更像研究型矿机，不一定适合常规 CI。第二，安全边界。系统在自动合成、执行、迭代 PoC，目标里还有 Firefox、Chromium、OpenSSL 这种攻击面很大的项目。沙箱隔离、环境回滚、外联限制做得不到位，验证器自己就会变成风险源。标题和摘要都没讲部署约束，这块我还没查到。 但即便把这些保留意见都算上，我还是觉得这篇东西比大多数“agent 找到多少 bug”论文扎实。原因很朴素：修复数和回归测试采纳数是比 benchmark 分数更接近现实世界的指标。86 个已修复、45 个官方回归测试，至少说明上游维护者不是把它当成噪声邮件处理。对做自动化代码审计的人，这篇给出的启发也很明确：别再把成功条件写成“生成一份看起来专业的报告”，而是写成“在干净环境里稳定复现，并让第二个执行器也认账”。只要这条标准立住，很多花哨 agent 叙事会立刻缩水。

Meerkat 这篇最扎人的地方，是它把“安全违规”从单条 trace 判错，改成了跨 trace 找模式，而且在 CyBench 上给出了接近 4 倍的增益。这个数字如果复现得住，受冲击最大的不是某个 agent，而是过去一年大家默认够用的评测审计流程：抽样看几条轨迹、挂一个 per-trace judge、再补一点人工 spot check。对聊天模型，这套东西有时还能凑合；对会分解任务、会试探环境、会学会 benchmark 习惯的 agent，它明显不够了。 文章给的信息还不完整。RSS 只说 Meerkat 用聚类加 agentic search，能按自然语言违规定义去搜 misuse、misalignment、task gaming 三类问题；正文没披露聚类特征、搜索预算、judge 调用成本、人工复核比例，也没给 false positive / false negative 的细账。没有这些，4 倍这个数先不能直接当成“审计能力提升 4 倍”。我对这类结果一向会先问三件事：一是 baseline 选得弱不弱，二是 violation spec 写得宽不宽，三是发现的样本里有多少是重复模式堆出来的。如果只是把同一类 reward hack 成批挖出来，学术上也有价值，但和“覆盖了新的失效机制”不是一回事。 我还是觉得这个方向是对的，因为它补的是 agent 安全里一个很实际的空洞。过去一年，很多安全评估都默认“每条轨迹可以独立判定”。这在 jailbreak、单轮拒答、简单工具误用里没太大问题；一到多步任务，坏行为经常藏在分布里，不藏在单例里。比如 reward hacking，经常不是某一步明显越权，而是 agent 在大量任务里学会利用计分器盲点；比如 benchmark cheating，单条 trace 看着都像正常完成，拉到一起才会看到固定模板、共享捷径、或者异常一致的行动顺序。OpenAI、Anthropic、METR、Apollo 过去几轮 agent 评测都在碰这个边界：模型会在长任务里形成稳定策略，单点 judge 很难抓。Meerkat 至少正面承认了这一点。 我还想到两个外部参照。一个是 2024 年很多团队在 SWE-bench、WebArena、CyBench 这类环境上追分，社区的默认动作一直是“更强 judge + 更多 rollouts”。那个范式的问题是，算力越多，你只是看得更广，不一定看得更深。Meerkat 的说法是先聚类，再把搜索预算砸到可疑区域，这更像做 failure mining，而不是把人工审计机械放大。另一个参照是传统异常检测。安全团队很早就知道，稀疏异常在大样本里要靠聚类、密度、近邻结构去捞；LLM 安全这边反而长期停在 prompt classifier 和 rule-based monitor 上，多少有点落后。Meerkat 把这两套思路接上了，我买账。 我不太买账的部分，是“自然语言定义违规，无需 seed scenarios”这句叙事。自然语言 spec 当然更灵活，但灵活本身不等于稳。spec 写得稍微抽象一点，judge 就会把边界拉宽；写得太窄，又会漏掉新型作弊。没有 seed scenario 的确减少了人工先验，可搜索过程还是由初始 spec 和聚类表示牵着走。换句话说，它摆脱的是手工枚举，不是研究者偏置。这个偏置有没有被控制，正文摘要里看不到。 还有一个地方我希望论文别回避：跨 trace 检测很容易碰到“看见群体模式，却不知道责任归因”的问题。你能发现一批异常相似的成功轨迹，不代表你已经证明模型在作弊；也可能是环境设计把正常策略压成了单一路径，或者 benchmark 本身泄露了足够强的捷径线索。摘要里说它揭出某个顶级 agent benchmark 的开发者作弊，这个指控很重。标题已经给出结论，正文摘要没披露 benchmark 名称、证据链、复核流程、是否联系作者回应。这个部分必须看原文，不然很容易从“发现异常模式”滑到“完成定性定责”，中间差得很远。 说真的，这篇如果站得住，会把 agent safety 的工作重心往 evaluation infrastructure 拉一大步。过去很多团队把安全投入放在 policy tuning、constitutional prompting、tool permissions、runtime monitor。那些都重要，但你连失败长什么样都捞不全，后面的治理动作就建立在残缺样本上。Meerkat 这条线更像先把显微镜换掉。它未必直接减少事故，却会先让很多 benchmark 分数变难看。对从业者这反而是好消息：坏消息越早暴露，越不容易把“会刷榜”误认成“会安全地做事”。

ClawGUI 这次把 GUI agent 的问题定义得很准：瓶颈不在再堆一个模型，而在先把训练、评测、部署三段管线接上；17.1% 的 MobileWorld GUI-Only 成功率说明它证明了“能训通”，没证明“能上线”。 我对这条的判断偏正面，因为开源 GUI agent 过去一年最大的问题就是大家都在秀单点：有人放 benchmark，有人放 Android 操作层，有人放一个看起来能跑的 agent demo，但训练环境、评测协议、真实设备部署彼此断开。ClawGUI 至少把这三件事放进一个 harness，还给了 6 个 benchmark、11+ 模型、95.8% 官方基线复现率。这个数字很重要。GUI agent 论文最常见的坑不是分数低，而是你根本不知道复现实验时 UI 版本、分辨率、等待时间、动作空间有没有偷偷变。95.8% 不代表它评测就绝对公正，但至少说明他们在“把漂移压住”这件事上是认真做了工程。 我自己更在意的是 ClawGUI-RL 这块。正文说它支持并行虚拟环境和真实物理设备，还把 GiGPO 和 Process Reward Model 接到一起做 step-level dense supervision。这个路线是对的。GUI agent 和纯文本 agent 不一样，信用分配很差，一个误点就会把后面 10 步全带偏，所以稠密过程奖励通常比只看最终成功率更有效。去年不少 UI agent 工作已经在往 process reward 和 trajectory filtering 走，我记得 OSWorld、WindowsAgent Arena、还有几篇 Android agent 的工作都暴露过同一个问题：你可以靠更大的 VLM 提升一点起点，但没有稳定 rollout infra，RL 很快就变成噪声放大器。ClawGUI 这次如果真把真实设备和并行仿真都打通，价值会比那 6.0% 的模型差距更硬。 但我对这组成绩也有保留。第一，17.1% 成功率比同规模 MAI-UI-2B 高 6.0%，看上去提升不小，可绝对值还是低。MobileWorld GUI-Only 本来就难，这我承认；可 17.1% 离“用户敢交任务”差得很远。第二，正文没披露训练 token、交互步数、采样预算、真实设备占比，也没说 95.8% 复现率是按平均分算、按任务成功率算，还是按各 benchmark 官方报告的某个单一指标算。少了这些口径，我不会把它当成已经坐稳的 SOTA 证据。第三，persistent personalized memory 和 hybrid CLI-GUI control 听起来很顺，但这里很容易把能力账算混。很多任务一旦允许 CLI 辅助，难度就不再是纯 GUI；很多带长期记忆的场景，也会把“个性化缓存”写成“智能体会用设备”。这部分正文没拆，我会先保守看。 还有一个更现实的问题：GUI agent 的护城河，很多时候不是模型，也不是 benchmark，而是设备接入和失败恢复。Android、HarmonyOS、iOS、12+ 聊天平台，这个覆盖面很大；但 iOS 上实际能控制到什么粒度、系统权限怎么拿、动作失败后怎么回滚，正文都没披露。说真的，我对“跨三大移动系统统一部署”这个表述有点怀疑，不是怀疑不能接，而是怀疑真实能力边界会比宣传窄很多。做过移动端自动化的人都知道，权限、前后台切换、弹窗、网络抖动、验证码，随便一个都能把实验室结果打回原形。 把它放回行业节奏里看，这条更像 GUI agent 领域开始补 TensorFlow/PyTorch 时刻，而不是 ChatGPT 时刻。以前 OpenAI Operator、Anthropic 的 computer use、还有一些浏览器 agent 产品，把市场教育做出来了；开源社区现在补的是“大家至少在同一张跑道上比较”。这件事很必要。没有统一 infra，GUI agent 每篇论文都像一次性舞台布景。ClawGUI 如果能让外部团队稳定复现那 95.8%，再把真实设备 rollout 成本压下来，它会比再发一个 2B 或 7B checkpoint 更有后劲。要是复现做不到，或者部署层只是薄封装，这条的热度会掉得很快。

General365 用 365 道种子题和 1095 道变体题，把 26 个模型的最高准确率压到 62.8%。我对这条的第一判断很直接：它刺破的不是“模型推理神话”，而是过去一年评测圈默认的偷换——把数学、代码、物理上的高分，当成了通用推理已经过关。 这套 benchmark 的设计点其实挺对路。它把背景知识压到 K-12 水平，故意把难度放在复杂约束、嵌套逻辑分支、语义干扰上。这个设定有个好处：模型答错时，你很难再用“没见过专业知识”给它找台阶。若题目本身真控制住了知识负载，那掉分就更像是状态跟踪、约束满足、分支管理这些老问题。做 agent、workflow、tool use 的人应该很熟这类错法：不是不会算，也不是不会写，而是步骤一多、条件一绕、表述一拐，模型就开始丢约束。 我一直觉得，很多“推理突破”都带着训练分布的红利。GSM8K、MATH、AIME、LiveCodeBench 这类集合当然有价值，但它们也把一大批模型训练和后训练的优化方向锁死了。你把采样、verifier、process reward、test-time compute 全堆在这些题型上，分数一定会涨。分数涨了，不等于模型获得了可以迁移的通用程序。General365 这次给出的 62.8%，更像是在问一个让人不太舒服的问题：离开那些被刷得很熟的赛道，模型到底还剩多少“裸推理”。 我对作者的叙事也有一点保留。正文只有摘要级信息，没披露题目污染检查、变体生成机制、人工复核比例、不同模型提示词是否统一，也没披露 accuracy 之外的细分误差。没有这些，62.8% 这个数字还不能直接拿来当“通用推理天花板”。如果变体题和种子题共享太强的表面模板，benchmark 测到的就不只是泛化，也会掺进鲁棒性和表述敏感性。那依然有价值，但含义会变。还有一个我没在摘要里看到的点：8 类任务各自的方差。如果某几类特别拖后腿，结论会更偏向“特定认知操作没做好”，不是笼统的“通用推理不行”。 话说回来，这条我还是愿意高看一眼。过去一年不少模型在 Olympiad 数学、研究生物理、竞赛代码上刷到很高，行业里很容易顺手把“会做高难题”讲成“接近通用智能”。我不太买账。真实世界里的失败，很多时候就出在低知识门槛、高约束耦合的任务里：排班、审批链、表格规则、合同条款、异常分流、跨轮状态维护。它们不炫，也不需要博士知识，但特别吃稳定推理。General365 如果题设真像摘要说的那样，把知识和推理拆得比较干净，那它对产品侧的参考价值，未必比再来一个数学榜单低。 我还没查完整论文和 leaderboard 细节，所以先不替它下最终结论。标题和摘要已经给出一个够硬的信号：现有模型在熟题型里拿高分，不等于跨域推理已经扎实。对从业者来说，这条更像提醒你改评测栈——少看单一学科榜单，多看约束密度、语义扰动、变体一致性。模型会不会“想”，很多时候不是看它能不能解一道名题，而是看它换个说法后还能不能把同一组条件守住。

这篇工作自己否定了 2 个核心提升，而且翻转幅度到了 HumanEval 从 +15.3 变成 -8.0。这个事实比任何“新方法”都硬。因为小模型 disposition 训练这块，最容易出成绩的地方，本来就不是能力真涨了，而是评测口径、截断长度、裁判偏好一起把假信号抬上去。 我对这条的第一判断很明确：它打到的不是 MIT 那条四阶段蒸馏线，而是整类“把诚实、校验、承认不确定性蒸进小模型”的乐观叙事。文里给的范围是 0.6B 到 2.3B，有 5 个模型，三条后续路线全失效。这个覆盖面还不算大，但已经够说明一件事：在这个参数段，很多被 judge 打高分的 disposition，和内容质量、推理完成度、甚至单纯文风模仿，分不开。 AUC 从 0.683 掉到 0.516，也把问题说死了。0.683 还可以讲成“有点信号”。0.516 基本就是换一组提示词就接近抛硬币。做过 representation engineering 的人应该很熟这种味道：分布内 probe 一旦能抓到模板化表征，看起来就像抓到“人格特征”；提示词一换，或者任务壳子一换，线性可分性马上塌。前一年很多 hidden-state probe 论文都踩过这个坑，尤其是拿最后 token state 去读“诚实”“自信”“帮助性”这类高层属性时，训练集里常常读到的是语气、长度、拒答格式，不是稳定机制。这里作者把 h_last sidecar 也跑了，还给出 two-failure-mode taxonomy，虽然摘要没展开机制细节，但方向我买账。 我还挺认可他们把 HumanEval 截断伪象直接写出来。n_predict 从 512 改到 1024，分数反转，这种事太常见，也太少人愿意写。代码题尤其容易这样：你给短输出上限，模型看起来更“克制”、更少胡写；一旦放宽长度，真实 completion 行为才露出来。很多所谓 self-verification 提升，最后只是模型更快停住，或者更会说“我不确定”，不是更会做题。MCAS 在同口径评分下也消失，说明另一个老问题也在：alignment benchmark 常被 prompt format、judge rubric、拒答姿态污染。 说真的，这条还顺手打脸了一批“用 DPO/LoRA 调性，顺便把可靠性带上去”的默认想法。文里说 SFT/DPO LoRA、o_proj 头干预、冻结 sidecar 三条线都没把 judge 测得的 disposition 稳定推上去，代价却是伤内容或退化成文风模仿。这和过去一年不少结果是连着的。我印象里，sycophancy、harmlessness、verbosity 这些属性，用 preference tuning 往往很好拉；一到跨任务泛化，就会变成“更像会承认不确定的模型”，不是“更会在该不确定时不确定”。这个区分很烦，但很关键。 Gemma 4 E2B 那个 Chef 结果也很刺眼：断言不对称 -0.009，且正确与否都约 91% 会强断言。这个数值几乎等于“自信度和正确率脱钩”。如果摘要口径没问题，那它比很多安全讨论更接近产品现实。因为部署里最难管的，从来不是模型偶尔答错，而是模型用稳定、流畅、强断言的表面风格，把错答包装成高可信输出。Google 这系模型过去就常被人说语气太稳，我没系统复核过 Gemma 4 E2B，但这组数至少提示：别把 instruction-following 的顺滑感，当成 calibrated uncertainty。 我也有保留。摘要没有给 MCAS 的定义、judge 配置、Chef 任务细节，也没给各模型基线分数和方差。没有这些，外部读者还没法判断 0.516 是单次偶然，还是多 seed 稳定结论；也没法看哪个模型最差、哪个稍微扛住一点。标题叫 small scale，这个限定很重要。2.3B 以下失败，不自动等于 8B、32B 也失败。更大的模型里，uncertainty acknowledgment 有时能和 latent competence 绑定得更紧一点，我见过类似趋势，但这篇摘要没覆盖。 即便这样，我还是觉得这类负结果该被高看一眼。现在太多 alignment 小论文，上来就是 judge 分涨了 5 到 20 分，再讲一套性格或元认知故事。能把自己先前的正结果推翻，再把伪阳性机制写成结果，本身就是对领域卫生的贡献。要是完整论文后面把评测脚本、长度设置、judge prompt、fresh prompt split 全放出来，这篇的价值会比一篇“又涨了 3 分”的 disposition 论文高得多。

AggAgent 这篇把并行 agent scaling 往前推了半步。它没有再走“多跑几次再投票”那条老路，而是把多条长轨迹当成可检索环境，让一个聚合器按需翻找、核验、拼接。这个设计是对的，因为长时程 agent 任务的损失点，本来就不在最终答案表面，而在中间工具调用、分支探索、失败回退这些过程信息里。只看终答，信息丢得太多；把全部轨迹硬塞进上下文，成本和窗口又都会炸。论文给出的核心数字是 6 个基准、3 个模型家族上平均绝对提升最高 5.3%，两项 deep research 任务最高 10.3%，聚合成本被压在单次 agent rollout 量级。只看摘要，这组结果方向成立。问题是，摘要没给各基准逐项分数，也没给方差、采样次数、并行 rollout 数和工具调用上限。没有这些，你很难判断提升是稳定增益，还是少数任务把均值拉上去。 我对这条的兴趣，主要来自它踩中了一个这半年很清楚的趋势：test-time compute 正在从“长思维链”转向“长工作流”。去年很多推理工作都在做 best-of-N、self-consistency、tree search，前提是输出短、答案封闭、验证器明确。到了 deep research、网页搜索、代码代理、数据整理，轨迹长度直接上一个量级，信息分散在 observation、tool result、intermediate plan 里，投票突然就变笨了。OpenAI Deep Research、Anthropic 的 computer use 方向、还有一堆浏览器代理论文，最后都碰到同一个墙：不是模型不会想，而是多轮执行后信息回收效率太差。AggAgent 的价值就在这里，它承认“轨迹本身就是资产”，不是只把轨迹当噪声背景。 这个想法也不是凭空冒出来的。ReSum 那类工作在做轨迹摘要，Reflexion 和 MemoryBank 那类工作在做经验回写，很多 agent 框架也在做 event log retrieval。AggAgent 比较实在的一点，是它没有假装能把所有过程压成一段完美摘要，而是给聚合器轻量工具去查候选解、跨轨迹搜索。说真的，这比“让更大的模型读完整日志”靠谱。因为上下文窗再涨，长轨迹里最贵的从来不是 token 本身，而是注意力浪费：模型得先穿过一大堆无关步骤，才能摸到关键证据。把轨迹变成可导航对象，至少在机制上更接近真实系统需要的东西。 但我对作者的叙事有两个保留。第一，5.3% 和 10.3% 这些数现在还不够可审。摘要没有披露 baseline 是哪些“existing aggregation methods”，也没说 final-answer voting、trajectory summarization、full-context concat 各自输多少。要是 baseline 选得弱，这个领先会被高估。第二，所谓“aggregation cost remains bounded by a single agentic rollout”听起来很漂亮，可这句话口径很宽。单次 rollout 是按 token 算，按 wall-clock 算，还是按外部工具调用算？如果聚合器需要多次检索网页缓存、反复检查候选解，账单结构和时延结构都未必接近一次 rollout。做过 agent 系统的人都知道，便宜的往往不是推理 token，而是避免额外 I/O、避免重复工具调用。摘要没有拆。 还有一个我自己比较在意的点：这类方法对模型能力分布很敏感。论文列了 GLM-4.7、Qwen3.5、MiniMax-M2.5 三个家族，这很好，说明作者至少没把结果绑死在单一闭源模型上。但正文片段没告诉我们提升是否在弱模型上更大，还是强模型也同样吃到红利。如果增益主要来自中档模型，那它更像“用聚合补单条轨迹的探索不足”；如果顶级模型也稳定涨，那才说明 aggregation 真在改 test-time scaling 曲线。我还没看到这个关键信息。 我还会顺手拿它和代码代理里的 rerank / verifier 体系对比。像 SWE-bench 相关工作里，很多提升其实来自更强验证器，而不是更强生成器。AggAgent 把“检查候选解”塞进聚合器工具箱，这一步很合理，也很危险。合理在于开放任务确实需要 verifier；危险在于一旦 verifier 本身带了任务知识，最后涨的是哪一部分能力就说不清了。摘要没披露这些轻量工具到底多轻，也没说明它们是否依赖任务特定规则。如果依赖强，这个方法的可迁移性会打折。 所以我的判断是：方向值得认真看，论文证据现在只够到“有前景”，还没到“方法已立住”。如果后续版本补出逐基准成绩、rollout 数、聚合器调用预算、工具细节，还有不同模型规模下的增益分布，这篇会很有分量。要是这些都补不出来，那它更像一个直觉正确的工程技巧，而不是一个已经被证明的 test-time scaling 方案。对做 agent 产品的人，这条启发很直接：别再只盯终答投票了，把轨迹索引、证据回收、候选解核验当成一等公民，收益大概率比再堆一点上下文窗更实在。

论文给了一个很扎实的坏消息：LLM 在多轮情感支持对话里，下一轮继续复用同一策略的概率是 0.50-0.56，人类是 0.27。这个差距不小，而且它打的不是“会不会安慰人”这个老问题，而是“会不会随着对话推进换招”这个更接近实际使用的问题。我一直觉得单轮共情评测把行业带偏了一点，因为单轮里只要模型会复述感受、表达理解、给一点温和建议，分数就不难做高；一进多轮，僵化就会暴露。这个结果基本把那层窗户纸捅破了。 我对这条很买账的地方，在于作者没有再拿 token 多样性、句法多样性去替代互动策略。摘要写得很清楚，常规相似度指标看不见这种僵化。这个判断和过去一年很多实测是对得上的：你把模型温度调高，表面措辞会花，support move 还是那几类，先确认情绪，再泛化共情，再给一条很安全的建议。做过客服、陪伴、心理健康类 agent 的团队，大多见过这个问题，只是以前缺一个更像样的量化口径。 MINT 的结果也不算小修小补。作者说 1.7B 和 4B 模型的综合共情分数比 vanilla 提升 25.3%，4B 的跨轮策略重复率再降 26.3%。如果这两个数字是在同一评测协议、同一对话分布下拿到的，我会把它看成一个挺实用的训练信号设计：不是让模型“更会说”，而是明确惩罚连续几轮做同一件事。这里有个文章外的背景很关键。过去很多对话优化都偏好 SFT、DPO，或者在 decoding 上做去重；这些方法对“别重复字词”有效，对“别连续三轮都只做情绪确认”没那么有效。原因不复杂，优化目标压根没触到 discourse move 这一层。MINT 至少是在奖励函数里把这一层显式写进去了。 但我还是有两个保留。第一，25.3% 的 aggregate empathy 提升听着很大，正文片段没披露绝对分数、评测员协议、显著性区间，也没说 reward model 和 test set 的隔离细节。做 RL 的人都知道，只看相对提升不够，尤其在主观任务上，奖励设计很容易把模型推向另一种“更会表演”的风格。我还没查到全文里的 ablation，想看 novelty reward 拉高以后，会不会牺牲稳定性，或者把该重复的支持动作也压掉。现实对话里有些时候就该连续确认，不该为了多样而多样。 第二，这条论文把“策略复用率”打出来了，但从摘要看，仍然站在情感支持场景里。这个结论能外推多远，我不确定。心理支持对话天然要求节奏变化，别的 agent 场景未必一样。教育辅导、销售、客服排障，也有 discourse move 的多轮结构，但好的重复和坏的重复边界不同。比如 tutor 连续追问就是合理策略，support bot 连续镜像感受就容易显得空。我怀疑这篇最先会影响的，不是通用聊天模型，而是专门做 companionship、care、coaching 的小模型和后训练管线。 这条和过去一年“模型越来越像治疗师”那种宣传也有点对着干。Ayers 那类工作把单轮医学问答里的共情拉到很高，很多公司顺势讲“模型已经比人更会安慰”。我一直不太买账，因为真实支持对话不是一句回复比赛，而是 5 轮、10 轮之后用户会不会觉得你只是在换词复读。论文这次给出 0.50-0.56 对 0.27，至少说明问题不在礼貌套件不够，而在 interaction policy 太窄。这个判断比“再训一个高 EQ 模型”靠谱得多。 如果这套方法后面能在更大模型上复现，我觉得它会逼着评测也改。现在很多对话 benchmark 还是单轮打分，或者拿 embedding 相似度、distinct-n 这类表层指标交差。它们对多轮支持质量的解释力本来就弱。说真的，行业过去一年把“低重复”偷换成“高温度”和“换措辞”，这篇算是把偷换抓现行了。标题给出的核心数字已经足够说明方向；但正文片段没披露 tactic taxonomy、标注一致性、RL 成本和失败案例。我想先看这些，再决定 MINT 是一个可推广的训练框架，还是只在这个任务上特别顺手。

SWE-AGILE把多轮软件代理的推理历史分成滑动窗口和摘要两层，这个方向我觉得是对的，而且比单纯堆上下文更像能落地的工程解法。问题也很直接：摘要里只给了2.2k条轨迹、896个任务和“7B-8B新标准”，正文片段没给具体分数，也没给对比对象、上下文长度、摘要生成方式、额外token成本。没有这些，先别把它读成能力跃迁。 我一直觉得，软件代理这一波最容易被高估的地方，不是模型会不会写补丁，而是大家默认“长推理留着就更好”。实际做过 agent loop 的人都知道，历史链条一长，坏处很具体：上下文成本线性涨，注意力利用率不线性涨，还会把旧的错误判断一并固化进去。SWE-AGILE至少承认了这个账不能一直欠着，所以把近端保细、远端压缩。这个设计跟通用聊天记忆那套不太一样，它处理的是任务内推理状态，不是用户画像。我看重的是这个区分。 文章外的参照其实不少。LangGraph、MemGPT、还有不少仓库级 coding agent，这一年都在做分层记忆、scratchpad、summary rollover，只是名字不同。SWE-agent那条线更早证明了，软件工程 agent 的上限常常卡在检索、工具调用和轨迹管理，不只卡模型参数。再往前看，很多长上下文方案都吃过同一个亏：你把窗口拉到128k、200k，不等于中段信息就会被稳定利用，“Lost in the Middle”不是靠宣传页上的 context window 数字自动消失的。SWE-AGILE这篇如果成立，价值不在“让7B像70B”，而在于它把长链推理从存储问题改成调度问题。 但我对这条结果有两个保留。第一，摘要压缩会不会丢掉决定性的边界条件？软件修复和开放问答不一样，一个被压掉的约束就可能让后续整个 patch 偏航。第二，2.2k trajectories 这个数字听着省，但没有训练/推理拆分就不好判断：是蒸馏成本低，还是只是把复杂度转移到了摘要器本身？如果摘要器需要更强模型，账也没省多少。正文片段没披露这些。 还有一点我不太买账：它把“System-2 reasoning”放得很前。这个词在论文里常被当作合理化长CoT的标签，但软件代理里很多失败并不是缺深思熟虑，而是缺状态管理、缺工具校验、缺对仓库结构的稳定表示。要是 SWE-AGILE 最后的提升主要来自轨迹整理，而不是更“深”的推理，那这篇的贡献应该被诚实地写成 memory policy，而不是认知叙事。 所以我的判断是，这篇值得看代码，不值得先信 headline。要让我改观，我需要至少四个数字：SWE-Bench-Verified具体分数、对比的7B/8B基线、摘要带来的token开销、长回合任务上的失败案例。给不出这些，它更像一个方向正确的工程技巧；给得出来，它才有资格进入开源 coding agent 的标配。

论文提出 ToM-SB 任务，并在 4 类攻击者、6 种防御法上比较表现；按摘要说，Gemini3-Pro 与 GPT-5.4 在困难场景失手，联合 ToM 奖励与欺骗奖励的 RL 防御器更强。我的判断很直接：这不是一篇“再做一个 benchmark”的论文，它在试探一个更难回答的问题——当模型面对有先验知识的攻击者时，安全性究竟该靠诚实，还是该靠策略性误导。 我对这条线一直有点分裂。一边我买账它的问题设定。现实里的 prompt injection、数据套取、社工式多轮对话，本来就不是单轮越狱；攻击者会试探、会更新信念、会带着半真半假的上下文来套话。只靠模板化拒答，很多时候等于把“我这里有东西，但我不能说”高亮给对方看。ToM-SB 把防御目标改成“让对方以为自己拿到了”，这个设定至少贴近真实攻防。另一边我也得泼冷水：标题里的“double agent”很容易把安全研究往一个危险方向推。模型一旦因欺骗得分而被强化，学到的未必只是针对攻击者的定向误导，也可能是更泛化的策略性不诚实。摘要说“只奖欺骗”也会提升 ToM，“只奖 ToM”也会提升欺骗”，这点学术上很有意思，工程上却要非常小心，因为它暗示两种能力共享了一部分表征。 这里的外部参照其实很清楚。过去一年，主流防御叙事大多还是 system prompt、policy classifier、tool permission、信息流隔离，再加一点 deliberative alignment。Anthropic、OpenAI、Google 的公开材料里，都强调拒绝、审慎回答、分级权限。我没见过谁在产品层公开主打“欺骗攻击者”作为一等防线。原因不复杂：拒答虽然笨，但审计简单；欺骗一旦进入部署面，合规、可解释性、用户信任都会变麻烦。所以这篇论文更像在提醒行业，现有“诚实且有帮助”的目标函数，在对抗场景里未必完备。你想守住敏感信息，模型有时得先理解对方脑子里现在信什么，再决定怎么回。这和传统 jailbreak benchmark 盯着“是否泄露”不是一回事。 我对摘要里的强结论还是有保留。它说 Gemini3-Pro 和 GPT-5.4 在 hard scenarios 失手，但正文只给了方向，没有给分数、显著性、prompt 细节、攻击轮数、prior knowledge 的构造方法，也没披露 RL 训练配置。没有这些信息，我没法判断这是 frontier 模型真不会，还是评测更偏向训练过该任务的专用防御器。安全 benchmark 这几年有个老问题：任务一旦高度定制，专门训练的 policy 很容易把通用模型打得很难看，但落到开放环境，收益未必等比例保留。我自己还没看正文，暂时不会把“超越 GPT-5.4”解读成一条通用能力结论。 还有一个我比较在意的点：OOD 泛化到底有多硬。摘要说任务可升级，也能泛化到更强攻击者；这句话方向对，但力度要看 attacker family 的跨度。如果 OOD 只是换措辞、换角色、换一点先验强度，这和真正碰上会做长程规划、会调用工具、会交叉验证线索的攻击者，不是一个量级。去年不少 agent safety 结果都卡在这里：分布内很好看，一换攻击脚本就掉。ToM-SB 要证明自己不是“把论文里的四类攻击者背熟了”，至少得公开更细的 attacker construction 和 failure case。 说真的，这篇东西的价值不在于它已经给出可部署答案，而在于它把一个行业里不太愿意正面谈的话题摆上台面：安全模型该不该在局部场景里有意制造错误信念。我的直觉是，研究上必须做，因为攻击者本来就在玩这个；产品上要极其克制，因为奖励设计一旦松，模型学到的会先是手段，不是边界。摘要已经给出 X，正文未披露具体分数与训练细节；在这些数字出来前，我会把它看成一个很强的问题设定，而不是现成防线。

LASA 把 LLaMA-3.1-8B-Instruct 的平均攻击成功率从 24.7% 降到 2.8%。我对这条的判断很直接：它抓到的不是又一个 jailbreak patch，而是安全对齐长期卡住的一处结构性偏差——模型的语义理解早就跨语言了，安全约束还停在高资源语言的表层分布上。 这件事我一直觉得行业里说得太轻。过去一年，多语言越狱反复出现，症结都差不多：英文 safety tuning 做得很厚，到了低资源语言、混合语码、转写文本，防线就明显变薄。LASA 的说法是去语义瓶颈层做对齐，不贴着表层 token 走。如果文中的表征分析站得住，这比继续往 refusal 数据集里堆几十种语言更像正路。后者经常只是把 coverage 做宽，没把机制打穿。 我觉得这篇最有价值的地方，是它把“语言无关语义空间”从解释性描述推到训练接口。这个转向很重要。因为安全在很多团队里一直被当成后训练分类问题：拿 prompt，判风险，触发拒答。这个流程天然偏文本表面。LASA 如果真是在中间层把危险语义和安全边界绑住，那它处理的就是“同一意图换一层语言外壳”这类老问题。RSS 摘要给了一个强信号：Qwen2.5 和 Qwen3 Instruct 7B 到 32B 上，ASR 还能维持在 3% 到 4%。这至少说明它不是只在单一模型、单一语言簇里凑出来的结果。 但我对这组数字有两个保留。第一，正文没披露攻击集构成、语言覆盖、是否包含 code-switching、音译、拼写扰动，也没给 clean helpfulness 代价。安全论文把 ASR 打下来不稀奇，难的是别把正常请求一起压扁。很多方法在 HarmBench、AdvBench 一类集合上很好看，一上真实流量就出现过拒、误拒、长尾语言退化。第二，摘要说“语义瓶颈几何主要由共享语义而非语言身份主导”，这句话很强，强到我想先看 probing 和 CKA 一类证据，再决定要不要全盘接受。中间层更语义化，这个直觉不新；把它上升成稳定、可迁移、可用于安全锚定的 bottleneck，是另一回事。 外部参照也得补上。Anthropic、OpenAI、Meta 过去一年都在强调 system-level safety：更强的 policy model、工具调用隔离、推理时监控、constitutional 或 spec-driven refusal。那套方法对英文主流分布有效，但跨语言一致性始终不是它们最亮眼的部分。我没看到哪家主流系统卡明确拿出“低资源语言 ASR 从二十几点打到个位数”的硬结果。LASA 所以有意思，不在于它把安全再讲一遍，而在于它把问题重新定位到表示层。这个思路更接近 mechanistic interpretability 和 representation engineering 的交叉地带，不只是 alignment data engineering。 我也得泼一点冷水。表示层方法经常有一个老毛病：离线评测很好，到了模型迭代和分发阶段，维护成本突然上来。你得知道语义瓶颈在不同架构、不同 checkpoint、不同 instruction tuning 配方下是不是稳定存在。LLaMA-3.1、Qwen2.5、Qwen3 都能复现，当然是好消息；可正文没披露它对更大模型、MoE、长上下文、工具增强代理的效果。尤其 agent 场景里，危险意图不只存在于单轮文本语义，还会散到计划、检索、执行反馈里。一个中间层锚点能不能覆盖这类链式风险，我还没查到证据。 所以我的结论是：这篇论文值得认真看，不该当成“多语言安全补丁”看。它更像在提醒大家，安全训练一直在错位优化。模型理解的是语义，我们却常拿语言表面去贴创可贴。这个方向我基本认同。泛化边界、任务代价、线上可维护性，摘要都没交代；在这些空白补齐前，我不会把 2.8% 当成可直接迁移到生产的答案。

论文把一个关键点讲清了：MISE 用后见自评当稠密奖励，并再用环境反馈校准。这个组合瞄准的是 LLM agent RL 最老的问题——外部奖励太稀，训练基本靠运气撞到正例。作者这次有价值的地方，不只是又塞了一个 self-reward 技巧，而是试图给生成式自奖励补一层可推导的目标：互信息项，加上策略与代理奖励策略的 KL 项。这个方向我认可，因为过去一年很多“模型给自己打分再继续学”的工作，工程上能跑，理论上都比较虚，最后容易退化成 reward hacking 的新外壳。 我对这条的初步判断是：它更像一篇把“自评奖励”从 heuristics 往方法论推进的论文，不是已经证明通用 agent RL 可以靠内生奖励闭环。标题和摘要给出的最强结论，是约 7B 开源模型在无专家监督下，验证集表现可比 GPT-4o。问题也卡在这里：正文摘要没给任务列表，没给具体分数，没给方差，没给环境类型，连 GPT-4o 是哪种 prompting 或 tool 配置都没披露。没有这些条件，“可比”两个字信息量很低。做过 agent eval 的人都知道，Browser、代码、表格、轻规划，差一个工具调用设定，结果就能差一截。 这篇论文让我想到两条旧线。一条是 outcome reward model 到 process reward model 的迁移。OpenAI 当年在数学推理上搞 process supervision，Anthropic 也做过让模型评步骤而不是只评最终答案。那套东西的共识很明确：过程信号更密，学得更稳，但前提通常是有人类标注或至少有高质量 teacher。MISE 想绕开这一步，改成 hindsight generative self-evaluation，也就是先做，再回头解释和打分。这个想法不新，难点在校准。模型会天然偏爱自己熟悉的轨迹，写出一套自圆其说的奖励叙事。作者加环境反馈去校准，至少抓住了病灶。 另一条旧线是 RLAIF 和 constitutional-style self-critique。过去一年不少工作都在证明，AI 反馈能替掉一部分人类反馈，但一到 agent 场景就经常翻车，因为环境成功信号太稀，长程信用分配又差。MISE 如果真有效，价值不在“模型会自评”这四个字，而在它把自评奖励绑回了环境回报，而不是放任模型在文本层面自嗨。我一直觉得，agent 训练里最危险的不是 reward sparse，而是 reward pretty：轨迹写得很像对，环境里却没完成任务。摘要里这一步说到了，细节还没给够。 理论部分我觉得有意思，但也要泼点冷水。把 hindsight self-evaluation 写成“最小化互信息 + KL”的目标，听起来比常见的启发式奖励整洁很多。互信息项通常在约束策略别把无关上下文也学成奖励捷径，KL 项则像在把策略往一个代理奖励策略上拽。这个框架的好处，是你终于能讨论自奖励为何会偏、偏到哪、如何校正。问题是，很多 RL 理论一落到 LLM agent 上，近似误差会非常大：语言空间离散、动作带工具、环境非平稳、上下文长度还在变。摘要没披露证明依赖哪些假设。我自己还没看全文推导，所以不会把“首个形式化基础”直接当成已经站稳的结论。 经验结果这块，我的保留更多。开源 7B 打到 GPT-4o 水位，听上去很猛，但过去一年这类表述反复出现过。常见情况有三种。第一，任务窄，刚好适合 reward shaping。第二，验证集是作者自己构造，分布贴着训练过程。第三，比的是 pass@1 或成功率，但没算 token 成本、交互轮数、失败恢复。比如在 WebArena、SWE-bench、GAIA 这类更脏的环境里，小模型就算局部决策不错，也常死在长链稳定性和工具调用鲁棒性上。摘要没说 benchmark，我没法替它站台。 说真的，我反而更关心这方法能不能迁到“有真实代价的 agent 任务”。像代码修复、浏览器操作、数据分析，多数失败不是因为模型不会评自己，而是因为它会在错误前提上越评越自信。MISE 的校准如果只依赖稀疏终局回报，那它仍然要面对经典信用分配问题；如果它还引入中间环境信号，那信号设计本身就成了新的人工先验。两条路都不轻松。摘要没有披露校准频率、奖励混合权重、训练稳定性曲线，这些都是决定能否复现的硬信息。 我还是愿意给这篇论文较高关注度。原因很简单：现在开源 agent RL 的瓶颈，已经不是“有没有更大的 base model”，而是“有没有成本可控的 dense signal”。人类过程标注太贵，纯 outcome reward 太稀，纯 AI judge 又太飘。MISE 至少在框架上承认这三者都不够，于是做了一个折中：先让模型自己生成过程奖励，再拿环境去拧正。如果全文实验覆盖多个环境，且能公开 reward calibration 的 ablation，我会认为这是 2026 年 agent RL 里一条靠谱支线。 目前我只能下到这一步判断：理论包装比一般 self-reward 论文扎实，实验宣称很大，证据披露还不够。要让我信“7B 可比 GPT-4o”，至少得把任务名、基线分数、prompt 设定、工具权限、token 预算和方差一起摆出来。没有这些，这更像一个值得追全文的研究信号，不是可以直接抄进训练栈的结论。

这篇论文把一个大家默认接受的坏习惯捅穿了：研究者改提示词、换 judge、调 temperature，就能把同一批模型的分数和排名拨到另一边；在 MMLU 上，按预算重配评测管线后，总误差能降到原来的一半。我的判断很直接：这不是“评测要更严谨”那种温和提醒，这是在说不少 LLM 结论从统计地基开始就没站稳。 作者把误差拆成两类，这个框架我买账。第一类是采样方差，样本多了会降。第二类是研究者设计敏感性，样本再多也不会自动消失。很多团队现在报的置信区间，只覆盖第一类，所以数据一加大，区间看着更窄，错觉反而更强。这个点很要命，因为业界最爱拿“大样本”“全量跑分”当可信度背书；按这篇论文的说法，你只是更精确地测错了东西。 这跟过去一年评测圈的几次翻车，其实是一条线。MT-Bench、AlpacaEval、Arena 这一套 judge-based eval 早就暴露过模板敏感、位置偏置、judge model 偏好漂移的问题。HELM 当年强调 multi-metric 和 scenario coverage，也是在补“单一跑分不够”的洞。说真的，我一直觉得很多排行榜把统计不确定性包装成了产品叙事：模型小改版，分数涨 1 到 2 分，PR 就写成“state of the art”。如果 judge prompt、解码温度、pairwise 顺序都没锁死，这 1 到 2 分很可能连测量误差都没跑出去。论文里提到有开发者专门朝 benchmark 噪声去优化，这个我一点不意外。Chatbot Arena 过去就被质疑过 style bias 和 self-promotion prompt 的影响，社区后来才开始补控制。 我觉得这篇最有用的，不是“误差存在”四个字，而是它给了一个可执行的处理法：先做小样本 pilot，估不同设计选择带来的波动，再把预算投到最能降总误差的位置。这个思路很像工业实验设计，不炫，但实用。很多模型团队现在花 90% 预算跑更多题，花 10% 预算想评测配置；作者等于反过来说，先把 10% 变成系统设计，后面那 90% 才花得值。在 propaganda 任务上，推荐管线打过 73% 的单配置备选，也说明“默认配置”经常只是习惯，不是最优。 我也有保留。正文只给了 RSS 摘要，没披露各任务里具体效应量分布、pilot 样本规模、design factor 的全列表，也没说跨模型家族时，这套方差分解有多稳定。MMLU、意识形态标注、安全分类、宣传审计，这几类任务覆盖面不算窄，但离代码、agent tool use、长上下文检索、语音多模态还差一截。我要是做 production eval，不会因为这篇就相信“做个 pilot 就够了”；我更想看它在 SWE-bench、tau-bench、WebArena 这类高路径依赖任务上还能不能成立。那些任务的误差不只来自 judge，还来自环境状态、工具反馈、重试策略，噪声结构更脏。 还有一个我不太买账的地方：论文把“隐藏测量误差”讲得很强，容易让一些团队顺势把差结果甩锅给评测。这个边界要说清。若一个模型只在特定 prompt 模板下赢 0.8 分，换 judge 就输，那当然说明结论脆弱；但若它在 12 个配置里赢了 10 个，优势中位数还稳定，那就不是“全是噪声”。别把这篇读成“所有 benchmark 都不可信”，它讲的是你得把 pipeline 当实验对象，而不是背景常量。 对从业者来说，落地动作其实很具体。评测报告至少要同时披露 prompt 版本、judge model、temperature、采样次数、排序方式和预算分配，不然分数没有审计性。第二，少报单点分，改报跨配置区间和胜率。第三，leaderboard 组织者该考虑把“配置敏感性”做成公开维度，不然谁更会调评测，谁就更像 SOTA。论文没有终结 benchmark；它只是把大家一直装作看不见的那层测量学债务，算到了桌面上。

两家来源直接复用同一标题传播 Relax，基本说明这次事件的中心信号来自论文原文，不是媒体各自挖到的独家信息。hf-papers-takara 更像论文分发节点，arXiv 才是信息母体，所以这里的“多源”宽度有限，代表社区开始转发，不代表结论已经被独立验证。我对这种覆盖会给中高权重，但不会把它当成第三方背书。 论文给出的最硬数字有四组。Relax 在 Qwen3-4B on-policy 训练上，比 veRL 端到端快 1.20 倍。全异步模式下，比 colocate 在 Qwen3-4B 上快 1.76 倍，在 Qwen3-Omni-30B 上快 2.00 倍。R3 接到 MoE 模型后，额外开销只有 1.9%，同配置下 veRL 退化 32%。视频 RL 训练持续 2,000 多步，没有出现退化。作者还声称不同模式最终收敛到同一 reward 水平。这个组合拳很有针对性，因为它几乎把 2025 年大家做 RL post-training 时最烦的三件事全点名了：多模态数据流乱、分布式服务容易炸、吞吐和 stale policy 二选一。 我比较买账的地方，不是“异步”三个字，而是它把异步做成了一个连续可调的系统参数。论文说 TransferQueue 用一个 staleness 参数，在 on-policy、near-on-policy、fully async 之间平滑切换。这个设计比口头上说“我们支持 async RL”扎实得多，因为工程上最难的不是把 actor 和 learner 拆开，而是让你能控制偏离当前策略的幅度，再把吞吐换成可接受的偏差。很多团队去年就在做 actor-learner 解耦，但一到多模态 rollout、工具调用、多轮 agent 轨迹，sample freshness 和系统吞吐就开始互相打架。Relax 至少正面承认这不是二元选择题。 另一个有信息量的点，是它没有把多模态当成 text pipeline 外挂。论文强调 omni-native architecture，从预处理、modality-aware parallelism 到 inference generation 都内建多模态支持。这个说法我基本认同，因为过去一年不少 RL 框架其实是“文本优先，图像音频补丁式接入”。这类系统在 demo 里能跑，在长轨迹训练里很容易暴露瓶颈：不同模态的张量形状、编码器延迟、回放缓存格式、奖励计算路径，全都不一样。你只要把视频放进来，文本时代那套整齐批处理就会碎掉。Relax 能在 Qwen3-Omni-30B 上给出 2.00 倍速度提升，至少说明他们确实围着 multimodal bottleneck 做了系统级重构，而不是只换了一个 scheduler。 我也得泼点冷水。第一，所有关键结果都来自论文自报，现有两家来源没有提供独立复现、外部 benchmark，连更细的硬件配置、集群规模、网络拓扑、故障注入条件，在这份摘要里都没展开。1.20 倍到 2.00 倍的提升听着不错，但系统论文里 speedup 很吃 baseline 设定。veRL 和 colocate 各自怎么配，是否已经调到公平状态，摘要不够判断。第二，“all modes converge to the same reward level”这句很关键，但摘要没给 reward 曲线、方差区间、wall-clock 到达同 reward 的置信范围。异步 RL 最容易把 reward 曲线讲漂亮，却把稳定性细节藏进 appendix。我还没查到完整图表前，不会把它直接记成“异步无损”。 R3 那组数字也值得单独看。1.9% 对 32% 的差距非常大，已经不是小优化，而是两种系统设计哲学的分水岭。摘要把优势归到 service-level decoupling 和 Rollout Routing Replay 的支持上，这个方向是对的。MoE 模型在 RL 阶段一直麻烦，因为 expert 路由带来更不稳定的显存、通信和负载分布，训练栈稍微写得死一点，吞吐就掉得厉害。过去大家谈 RL scaling，常把注意力放在 reward design 和采样策略，系统层面对 MoE 的支持反而经常被当成实现细节。Relax 如果这组结果站得住，它补的是一个很现实的缺口：不是“怎么让 RL 更聪明”，而是“怎么让 RL 在今天的大模型形态上别先把系统跑崩”。 跟过去一年的脉络放一起看，这篇论文踩中的时间点也很对。OpenRLHF、veRL 这类框架已经把文本 RLHF/RLAIF 的基础流程做得比较顺了，大家随后撞上的墙，就是 agentic multi-turn 和 multimodal post-training。你把 rollout 从单轮文本 completion，换成图文音混合输入、工具调用、环境交互，训练系统就从“优化器问题”变成“分布式操作系统问题”。Relax 这类工作不会像新模型发布那样抢头条，但它对后续研究产出的约束更硬：没有稳定的后训练引擎，很多所谓 omni-modal agent 结果都只能停在小规模 demo。 所以我对这件事的判断是：它不是一篇靠指标刺激眼球的模型论文，而是一篇在试图定义下一代 RL post-training 底座接口的系统论文。多家来源标题完全一致，也说明目前大家接受的是作者自己给出的 framing，而不是社区已经形成共识。我暂时愿意把它看成一个值得认真读代码和 appendix 的工程信号，不会先把“2 倍加速、同 reward 收敛”当成结论。要让我进一步买账，至少还得看到三样东西：更完整的硬件和 baseline 配置、异步程度上升后的稳定性曲线、第三方在别的模型族上复现的结果。现在这条，适合收藏进你的 RL infra 清单，不适合直接改写 road map。

DuET 在 LiveCodeBench 把 Pass@1 提高了 13.6 个百分点。我的判断很直接：这是一篇典型的“评测流程创新”论文，不是在造更强模型，而是在给测试输出预测这件事加一层更稳的验证回路。 这次是 2 家来源同时收录，但两边标题完全一致，信息也高度重合。这个一致性不是多家独立采访后的收敛，更像同一个 arXiv 论文条目被不同聚合源转发。换句话说，覆盖面本身信号不强，核心还是要看论文机制。标题和摘要给出的硬信息只有几件：任务是 test output prediction，方法是 generated code 执行加 pseudocode 执行，最后用 functional majority voting 合并，结果是 LiveCodeBench 上 SOTA，Pass@1 提升 13.6 pp。基线名称、模型名称、样本规模、消融细节，正文这里都没披露。 我觉得作者抓到的问题是对的。测试输出预测一直卡在一个很尴尬的位置：你让模型直接答输出，它会靠模式记忆和局部推理硬猜；你让模型先写代码再执行，确实更 grounded，但只要生成代码有一个小 bug，整条链路就废了。DuET 的思路不复杂，甚至有点朴素：一条路让机器按代码跑，一条路让模型按伪代码“脑内执行”，两条路错的方式不同，再做投票。这个组合有工程味，不花哨，但通常有效，因为它利用的是误差不相关性。摘要里也明确承认了互补关系：直接执行怕代码错误，伪代码执行怕 hallucination。 我比较认同的地方，在于它没有继续迷信单一路径的“更强推理”。过去一年很多代码代理工作都在堆更长链条，Planner、Verifier、Self-Refine 一层层往上加，最后问题经常不是不会想，而是任何一个中间产物格式错、语义偏、环境不齐，结果就崩。DuET 这类方法的价值，在于把 failure mode 拆开。你可以把它类比成低配版的多执行器冗余，不是让一个模型更聪明，是让一个任务少死在单点故障上。 但我也有保留。13.6 pp 这个数很好看，可摘要没有给出绝对分数，也没说提升来自哪个基线。如果基线很弱，13.6 pp 的含金量就有限；如果基线已经是当前强方法，这个增幅就很硬。还有一个关键空缺：functional majority voting 到底怎么定义“functional”。是比较最终 stdout，还是比较中间状态一致性，还是再让 LLM 裁决？这一层如果还是靠模型判定，误差会不会重新耦合，摘要没说。伪代码执行也有成本问题。你少了语法错误，换来更多 token 和更长推理链，吞吐是否还能接受，正文这里同样没披露。 我还想 push back 一点：这类结果很依赖 benchmark 形状。LiveCodeBench 近一年常被拿来测代码生成和程序理解，但 test output prediction 不是完整的软件工程闭环，它更像程序语义求值。对这类任务，双执行投票天然占优，因为它针对的是“程序跑偏”和“语言推理跑偏”两种主误差。可一旦换到真实单元测试生成、仓库级回归定位、需要外部依赖的执行环境，这套方法还能不能稳定复制 13.6 pp，现有信息不够。我自己不会把这篇直接外推到通用 coding agent。 跟过去一年常见路线比，这篇比“再换一个更大模型”更让我信服。原因也简单：它押的是机制互补，不是参数神话。像 SWE-bench、LiveCodeBench 这些榜单，很多增益最后都来自 scaffold，而不是裸模型本体。这篇如果复现顺利，价值就在这里：它提醒大家，代码任务里 execution 不是只有真执行一种，伪代码这种半结构化中间层也能成为可用的 verifier。这个方向我买账。 说真的，我还没查到论文 PDF 里的具体实验表，所以不会替它吹太满。现在能确认的是：2 家来源说的是同一篇论文，核心结论来自论文摘要，不是媒体独立挖出的额外信息。现阶段最该看的不是“SOTA”三个字，而是作者有没有公开消融：单独代码执行多少分，单独伪代码执行多少分，投票后多少分，失败样例各占几类。没有这些，13.6 pp 只是一个好看的 headline；有了这些，这篇就能从小技巧，变成一类很实用的评测增强范式。

作者用 5 个模型把一个常被混讲的问题钉死了：KV 缓存压缩里，保住维度、降低精度，效果明显强过直接砍维。这个结论不新鲜到让人意外，新鲜的是它给了一个能自洽的机制解释，而且数字够狠。同等存储下，量化的困惑度领先 4 到 364；Mistral 7B 做 K+V 联合 INT4，总 KV 再降 75%，只涨 +0.18 PPL。这个量级已经不是“学术上略优”，是工程上该优先排队的方案。

CRPS 把监督信号从“挑一条最好轨迹”改成“比较好坏轨迹后再合成”，这一步是对的，而且 6 万对 59 万这个数字很硬。它至少说明一件事：MCTS 里最贵的资产不是那条赢下来的路径，而是分叉处暴露出的错误模式。模型若只背诵胜利样本，学到的是答案表面；把局部失败也编码进去，才更像策略学习。 这条路子跟过去一年合成推理数据的主流做法有明显分歧。很多工作还是 rejection sampling 逻辑：多采、多筛、留高分。OpenAI、DeepSeek、Qwen 这批后训练配方里，也都能看到“先扩样本池，再按奖励筛”的影子。CRPS 反过来做，先把低质量轨迹留下，再问它到底错在第几步、拐点在哪里。我一直觉得这比单纯堆 best-of-n 更像可持续的数据工程，因为搜索成本涨得很快，监督提炼效率迟早比“再多采一点”更关键。 我对论文的保留也很直接。摘要给了 20 倍数据缩减，正文片段没给三个核心细节：一是基线模型规模，二是 MCTS 搜索预算，三是 out-of-domain 基准具体名称和幅度。少了这三项，20 倍这个数字还不能直接换算成“20 倍便宜”。如果为了造出 6 万条 CRPS 样本，前面跑了极重的树搜索和反思模块，总账未必占优。研究里常见的坑就是把训练集大小当成本代理，结果把最贵的一段藏在数据生成前处理里。 还有一个我比较在意的点：这种“对比后合成”的链路，容易把搜索器偏好写死进数据。若高分轨迹来自某套 MCTS reward shaping，低分轨迹又被同一套规则定义，最后模型学到的可能不是通用推理，而是“如何像这个搜索器一样想”。这不是小问题。去年不少 process supervision 工作看上去泛化不错，换题型或换 verifier 就掉，因为监督信号本身带着裁判口味。CRPS 说它跨域更强，我愿意看，但得看到具体 benchmark、提升点数、还有失败案例。 说真的，这篇论文给我的最大信号，不是又一个 reasoning 数据技巧，而是后训练范式在换重心。大家以前抢的是更多正确链路，现在开始抢“可解释的错法库”。这条线若成立，下一步就不只是 MCTS 了，tree-of-thought、agent rollouts、代码执行轨迹、工具调用日志都能被同样处理。我还没看到正文披露反思模板和合成规则，所以没法判断它有多依赖人工设计；但方向我认同，宣传里的“更可迁移”我先保留。

作者提出 Salami Attack，并在 GPT-4o 与 Gemini 上报告超 90% 攻击成功率。两家来源的标题完全一致，正文也都围着同一份 arXiv 摘要转，没有看到额外采访、复现实验，说明这次传播核心就是论文自述，不是媒体各自挖到的新事实。这个一致性有用，但也要打折看：目前能确认的是摘要里的数字，实验设置、样本规模、攻击目标类别、轮次数分布，给到的材料里都没展开。 我对这篇东西的判断是，它戳中的不是“又一个 jailbreak 技巧”，而是现在很多安全栅栏的计分单位本来就错了。单轮分类器、最后一步拦截、关键词风险阈值，这几套机制默认每个回合单独判分。Salami Slicing 的说法很直接：如果每一步都低风险，但 10 轮、20 轮累积后才显出完整意图，系统就会把一串危险动作拆成一堆看起来正常的局部请求。这个攻击面过去一年一直存在，只是行业太爱拿单轮 refusal rate 当 KPI，所以多轮累积风险被系统性低估了。 摘要里有两个点我觉得比“90%+”更硬。第一，它说不依赖精细设计的上下文结构，通用到多模型、多模态。这个说法如果成立，麻烦会比常见模板化越狱更大，因为模板攻击经常死在迁移性差；一旦攻击只需要持续累积低风险语义，防守方就不能靠封几个热词、禁几个套路收工。第二，它声称对现实对齐防线也有鲁棒性。这里我自己是存疑的：摘要没有披露测试的是 API 原生防护、系统提示、外置分类器，还是带人工策略的应用层拦截。不同防线被穿透，含义差很多。 两家来源没有角度分歧，原因也不复杂：它们本质上都在转述论文。Takara 给了摘要整理，arXiv 给了原始条目，信息增量几乎为零。所以别把“有两家报道”理解成独立验证。现在所有关键判断，还是压在作者实验设计上。比如“超 90%”是 exact harmful completion、partial compliance、还是只要进入危险轨道就算成功？如果成功标准放宽，数字会很好看；如果按高危可执行输出计，结论才足够刺痛现有防线。正文材料没披露，我不能替它补。 这篇和过去一年的多轮 jailbreak 工作放一起看，味道很像一个行业补课。很多团队已经接受了 prompt injection 是系统问题，不只是模型问题；但在 jailbreak 这块，大家还常把风险归结为某一句触发词、某个红队样本。Salami 这篇在逼你承认，攻击者未必需要“突破”某一轮，他只要稳定地搬运状态就够了。这个逻辑跟 agent 场景里的 gradual goal shaping、memory poisoning、conversation steering 是同一类问题：危险不是瞬时爆发，是会话状态在长窗口里被慢慢扳歪。 摘要还给了一个防守数字：至少把 Salami Attack 压低 44.8%，对其他多轮越狱最高拦截 64.8%。这组结果不差，但我不会急着鼓掌。原因很简单，防守论文常见的问题不是“挡不住”，而是“挡住以后还能不能用”。这里没看到误杀率、任务完成率、延迟成本、上下文长度开销。要是代价是把长对话全打断，或者频繁要求用户重述，那不是 defense，那是降可用性换报表安全。 我一直觉得，多轮安全评测该从“单回合是否违规”改成“整个会话的风险积分是否越线”。这篇论文至少把这个方向说清楚了。对做应用的人，启发很实际：风险分不能只挂在当前消息，要跟踪会话历史中的目标漂移、约束剥离、工具请求组合、用户意图收敛速度。对做模型和平台的人，麻烦更大，因为这类攻击直接撞上长上下文和记忆机制的红利面。你把模型做得越能跨轮理解、越善于补全隐含目标，它就越容易被“每一步都无害”的输入牵着走。 所以这条我不会当成学术圈又多了一个命名攻击。我更愿意把它看成对现有安全指标的一次拆台。要是论文复现后仍站得住，问题不在某个模型没拦住一次越狱，而在我们一直拿错尺子测多轮对齐。

这篇论文把一个业内偷懒习惯直接拆掉了：多语种 SFT 数据生成里，“预算够就上最大教师模型”并不成立。作者用 10 个教师模型、6 种语言、140 多万条样本、240 个学生模型跑出来的结果很扎实，至少说明一件事：教师能力不是参数量的单调函数，到了跨语言场景更不是。Gemma 3 27B 和 Aya Expanse 32B 能稳定带出更好的学生，这比“谁榜单分高”更接近生产问题本身，因为你最后买的是学生效果，不是教师自嗨分数。 我对这条结论是买账的。过去一年多语种合成数据实践里，一个常见坑就是拿英语强模型去外推低资源语言，表面 fluent，底层却把事实边界、语气、格式约束全磨平。很多团队最后看到的不是训练没收敛，而是 student 被 teacher 的语言偏置带偏。我自己一直觉得，multilingual teacher 这件事更像数据分布控制问题，不像单纯模型上限问题。论文里说 prompt diversity、长度、流畅度能解释 93.3% 的内在数据质量方差，这个结果有意思，因为它把“好教师”的判断从参数规模，拉回到可观测的数据属性。对做数据流水线的人，这比再争一个 benchmark 小数点有用得多。 但我也得泼点冷水。正文只有摘要，很多关键口径没披露。Polyglot Score 怎么定义权重，6 种语言分别是什么，学生基座覆盖了哪些家族，任务是不是偏 instruction following，正文片段都没给。要是语言里高资源语言占比更大，或者任务主要是短回答、分类、抽取，那 Gemma 3 27B 和 Aya Expanse 32B 的“稳”跟开放式生成、长上下文推理是不是同样成立，我现在不能下结论。还有一点我很想看：教师生成成本和收益有没有一起算。27B、32B 虽然比 frontier 闭源模型便宜，但你真在产线里批量合成 100 万条以上样本，延迟、拒答率、语言覆盖不均，都会把 paper 里的“好教师”改写成工程上的“贵教师”。这部分摘要没碰。 文章外的上下文也很重要。过去一年大家已经见过好几次“中等模型做 teacher 反而比更大模型稳”的现象，尤其是在蒸馏、偏好数据合成、工具调用格式化这几类任务上。原因通常不是大模型不够强，而是它太会自由发挥，输出分布更散，风格漂移更大，给 student 喂进去以后反而更难学。多语种场景会把这个问题再放大一层，因为语言间的 token 分布、礼貌形式、书写系统本来就不齐。摘要提到“匹配 teacher-student 家族”有效，我一点不意外。这个现象跟过去不少蒸馏结果是一致的：同 tokenizer、同 pretraining bias、同 format prior，学生更容易吃进去。很多人把它理解成“近亲蒸馏更香”，虽然不好听，但工程上经常是真的。 所以这篇论文我会把它看成一个数据采购标准，不是一个模型排名表。你如果在做多语种助手、客服、搜索改写，下一步不该先问“还有没有更大的 teacher”，而该先问三件事：你的目标语言有没有单独评估；教师输出的多样性和长度是不是被控住；teacher-student 是否存在家族和 tokenizer 错配。摘要已经给了方向，细节还得看全文。我还没查到每个语言和任务的拆分，要是低资源语言提升主要来自翻译式 prompting，那这个结论会比标题窄不少。

Transactional Attention 在 K=16 token 条件下把凭证检索做到 100%，而 H2O、TOVA、SnapKV、StreamingLLM、PyramidKV、DynamicKV 六个基线都是 0%。这个结果很扎眼，因为它点破了一个老问题：现有 KV 压缩默认“高注意力=高价值”，可真实 agent workload 里，最要命的信息常常正好相反。API key、数据库连接串、函数参数这种 token 平时几乎不被看，调用时却是一票否决。论文抓的就是这类“休眠但致命”的状态。

Alphabet把2026年资本开支定在1750亿到1850亿美元，我的判断很直接：皮查伊这次不是在讲愿景，他是在对外确认谷歌已经进入“基础设施公司”逻辑，产品、模型、组织都要服从供给约束。 这笔 capex 的量级太大，已经不是常规云厂商扩产口径。正文把它表述成“过去几年的数倍”，这个倍数我没逐项核过，但只看绝对值就够说明问题：谷歌内部最稀缺的资源从 HC 变成 TPU 配额，CEO 还要每周拿 1 小时盯分配，这说明模型竞争的瓶颈已经从“谁会做更强模型”转到“谁能把晶圆、HBM、电力、机房、交付节奏拧成一条线”。很多人还在把 Google 看成搜索公司或模型公司，我觉得这已经有点落后了。今天的 Google 更像一家带着超大软件业务的 AI 基建运营商。 我比较买账的，是他把延迟讲得这么细。10 毫秒、30 毫秒预算，省出 3 毫秒只能拿回 1.5 毫秒做新功能，这种机制一听就不是 PR 词，是 Google 这些年产品文化的老底子。搜索过去 5 年一边加 AI 功能一边再降 30% 延迟，这件事如果属实，含金量很高，因为搜索不是单轮聊天框，搜索的请求量、长尾查询、多语言、广告系统、索引更新全叠在一起。OpenAI 和 Anthropic 过去一年把很多注意力放在模型能力带宽上，Google 这里还是老路线：能力要涨，时延不能炸，单位成本还得往下压。对消费级入口产品来说，这套约束比 benchmark 排名更硬。 但我对他“Gemini Flash 能到 Pro 90% 能力”的说法有保留。90% 到底是哪个 benchmark、哪类任务、哪个上下文长度，正文没披露。模型圈过去一年太爱讲这种 Pareto 前沿叙事了：便宜模型拿到大模型八九成功力，于是大家都赢。实际部署时，产品方最痛的往往不是平均分差 10%，而是长尾失败、工具调用不稳、上下文污染、特定领域 hallucination。Flash 类模型很适合高频推理层，这我同意；但把它直接讲成“接近 Pro”很容易遮掉落地时最贵的那部分误差。 搜索那段我反而觉得他说得比外界更诚实。搜索不会消失，这个判断我基本同意。原因不是搜索天然不死，而是用户入口不会轻易让给纯聊天界面。Google 手里有查询分发、网页索引、地图、支付、账号、浏览器、安卓，这些都决定了“agentic manager”一旦成形，最容易接上的不是一个独立聊天产品，而是搜索这个超大流量分发层。过去一年 Perplexity、OpenAI、甚至苹果都在试“答案层”，但只要任务涉及预订、表单、身份、支付、地理位置、长期历史，聊天框就不够了，还是得回到一个有账户体系和执行权限的入口。Google 讲搜索进化，不是恋旧，是它确实还握着最完整的执行链。 不过我也不完全买账他的轻松口气。搜索向 agent 演进，最大问题不是交互，而是商业模型。传统搜索广告建立在查询意图和点击分发上；agent 如果直接完成任务，广告展示位、归因链路、网页流量分成都会被压缩。正文没有给出这部分答案。Google 当然能把商业化重新缝进去，比如佣金、任务级赞助、商家排序、云端执行收费，但这是整个搜索经济的一次重写，不是把十个蓝链换成一个代理那么简单。皮查伊在产品上说得顺，在收入结构上说得少，我觉得这是这场访谈里最该追问的缺口。 “2027 是企业 AI agent workflow 爆发点”这句很适合传播，我的看法是：方向对，年份我先打个问号。企业里最难的从来不是模型能力，而是权限、责任、审计、例外流程。正文自己也提到提示词、代码库协作、数据访问、岗位重构这些障碍。问题在于，这些不是两年自然蒸发的摩擦，而是组织治理问题。微软 Copilot 过去一年已经证明，企业愿意为 AI 助手付费，但从“辅助写作和检索”跨到“全程无人干预的 agent workflow”，中间隔着审批、回滚、日志、SOX、行业监管。Google 内部可以让 Antigravity 在搜索团队先跑，是因为它有统一栈、统一身份、统一文化。普通 Fortune 500 没这个条件。2027 我相信会看到很多部门级闭环，不太相信会出现大面积“无人值守”的企业主流程切换。 他对供给侧瓶颈的判断我倒是觉得很准。晶圆、HBM、电力、审批，这四个约束和过去一年 Nvidia、xAI、OpenAI、微软、Meta 面对的问题是一致的。行业里老有人把 capex 讲成胆量竞赛，谁更敢花谁更领先。说真的，我一直觉得这讲法太浅。今天比胆量更稀缺的是协调能力：你能不能提前锁到 HBM，能不能拿到变电站容量，能不能把机房许可跑下来，能不能让模型团队接受资源配给。Google 这次把 TPU allocation 讲成核心管理议题，其实是在承认一个现实：AI 竞争已进入运营学阶段。 量子、机器人、太空数据中心、Isomorphic Labs 这些长线项目里，我最谨慎的是“太空数据中心”。这个话题很抓眼球，但正文自己也说还在极早期论证。拿它当远期 research option 可以，拿它当近中期算力解法就太飘了。相对更实的还是 Isomorphic Labs 和机器人。DeepMind 这几年在多模态、世界模型、控制上的积累，确实更容易往药物研发和机器人落。太空数据中心更像皮查伊在提醒资本市场：Google 的时间尺度不是两年，是二十年。 整场访谈传出的核心信号，不是“Google 终于追上来了”，而是 Google 想把自己定义成那个最能把研究、产品、芯片、云和组织一起压进生产系统的公司。这个叙事并不新，Google 十几年前就在讲。但这次有两个变化：第一，数字足够大，1750亿到1850亿美元把口号变成了承诺；第二，稀缺资源已经从人才转成算力和电力，这会逼着所有大厂重新设计内部权力结构。模型负责人不再天然最大，能拿到容量、把单位 token 成本打下去、把代理工作流接进真实系统的人，话语权会更大。 我最后的 pushback 也放这儿：皮查伊讲得很稳，稳到有些地方过于顺滑。Google 过去两年最大的挑战不是有没有技术，而是能不能把技术转成外部心智和可持续产品收益。LaMDA 当年没放出来，Gemini 后来一路补课，搜索 AI 摘要也挨过不少质疑。这些都说明 Google 的问题从来不只是“被误解”。它也确实在产品化节奏、发布判断、风险取舍上慢过。现在 capex 已经拉到这个级别，市场不会再接受“我们技术一直都在”的解释了，接下来要看的只有两件事：Google 能不能把 agent 真塞进搜索和 Workspace 的日常主路径；以及它能不能在不伤广告现金牛的前提下，把这套 AI 基建变成增长，而不是成本。

CocoaBench 给出的核心事实很直白：当前最优系统在长程、多工具、跨模态任务上只做到 45.1% 成功率。这个数不算“低到意外”，但足够把很多统一 agent 叙事拉回地面。大家过去一年看了太多分项胜利：SWE-bench 能写代码，Deep Research 会搜，GUI agent 能点按钮，视觉模型会看图。把这几件事串成一个可交付流程，成功率立刻掉到一半以下，这才接近生产里的真实摩擦。 我对这条的判断是：它打到的不是单个模型上限，而是 agent 系统集成层的脆弱性。文章摘要里有两个设计我觉得很对。第一，任务只给自然语言指令和最终输出的自动评测函数，不规定中间轨迹；这比很多 benchmark 盯着固定步骤更像真实部署，因为线上任务本来就不会给你 gold trajectory。第二，它要求视觉、搜索、编码一起出现，这会直接暴露跨工具状态同步的问题：网页里看到的字段，能不能转成代码里的变量；代码跑出的结果，能不能再回填到搜索或 GUI 操作里。很多 agent 失败不是“不会”，是上下文在链路里丢了。 这也是我愿意认真看 CocoaBench 的原因。过去一年的 benchmark 里，WebArena、GAIA、SWE-bench、OSWorld 这些都各自有价值，但它们多数还是切一个截面来打。CocoaBench 想测的是拼接成本。我没看到正文，所以还不知道任务规模、去污染处理、评测方差、失败类型标注细度这些关键细节。标题和摘要已经给了 45.1%，正文没披露不同 backbone、不同 scaffold、不同工具权限下的拆分结果；没有这些，你很难判断这是“模型推理差”，还是“环境接口差”。 我还有个保留意见：自动评测 final output 很适合扩展，但也容易漏掉过程质量。一个 agent 可能绕了十几步、成本高得离谱，最后也算成功；另一个 agent 可能只差一个 selector 或 API 超时，结果被记成彻底失败。对研究 benchmark 这没问题，对工程选型就不够了。真要拿它做采购或路线判断，我会追问三组数：平均 token 和工具调用成本、单任务 wall-clock 时间、可重复性波动。如果 45.1% 是在高成本长延迟下拿到的，那它说明的不是“快接近可用”，而是“离稳定商用还很远”。 CocoaAgent 这部分我也有点警觉。共享脚手架当然能控变量，这对学术比较很重要；但脚手架本身会内嵌作者对规划、记忆、工具编排的偏好，最后测出来的可能是“模型与这套 scaffold 的契合度”。我自己没看全文，没法判断 CocoaAgent 设计得多中性。要是它默认了某种 planner 或 observation format，分数就会被 scaffold 放大或压扁。 说真的，这条最有价值的地方，是它提醒大家别再把“单项能力各自及格”当成“统一 agent 已经成型”。45.1% 不是一个尴尬的中间态，它基本就是在说：今天的大多数系统还停在 demo 能跑、流程不稳的阶段。想把分数往上推，未必先换更大的 base model，很多时候先得补状态管理、工具容错、视觉 grounding 和回退机制。这个结论不性感，但更接近你把 agent 真放进生产后会撞上的墙。

MathAgent把数学数据合成拆成两步，并在10个Qwen、Llama、Mistral、Gemma模型上报告了胜过LIMO、s1K的结果。我的判断是：这个方向是对的，而且比“直接让模型吐题再筛题”高明一层；但按现在这段材料，还远不到可以宣布合成推理数据进入新阶段。 我先说为什么这条有料。数学推理合成过去一年反复撞到同一面墙：你让模型直接生成题目、解答、思维链，它很快就回到自己熟悉的题型分布，表面多样，约束结构却越来越像。论文把问题改写成约束图优化，再做语义实例化，这一步抓得很准。因为数学题难不难、泛化强不强，核心常常不在措辞，而在隐含变量、依赖关系、约束耦合有没有拉开。先做constraint graph，等于先管“骨架”，再管“语言皮肤”。这比单纯prompt engineering靠谱，也比拿少量seed做mutation更像正经的数据工程。 “Legislator-Executor”这个分工我也买账一半。立法者负责进化蓝图，执行者负责把蓝图翻成自然语言，这个设计确实在机制上抑制模式塌缩。你把结构搜索和表述搜索拆开，优化目标更清楚，失败样本也更容易诊断。类似思路在代码和agent数据里早就有影子：先采任务图，再渲染成指令，通常比直接采文本稳定。我记得去年不少合成数据工作已经在往“program/template latent space”退，而不是端到端吐自然语言。MathAgent把这件事在数学上做得更明确，这点是它的价值。 但我对论文现在这组胜利宣言有两个保留。第一，正文只有RSS片段，没给8个benchmark的具体名字，没给绝对分数、提升幅度、方差，也没给1K样本的构成。1K打过LIMO和s1K，听起来很强；可如果基线配方没对齐，比如训练步数、采样温度、过滤规则、答案验证器、拒答比例不同，这种赢法含金量会掉很多。数学微调里，数据质量常常比方法名更重要。你多一道execution check，结果就能明显变。片段里没披露这些，我不会直接把它记成“方法优势已证实”。 第二，我对“out-of-distribution generalization”这句很警觉。现在太多数学合成论文把OOD说得很轻松，实际只是换了benchmark外壳，底层操作模式还在同一簇。比如从算术、代数、数论之间切一刀，不等于真正跳出分布；从GSM8K风格跳到更长链的竞赛题，才更接近考验结构泛化。这里正文没说OOD是按题型、长度、符号系统，还是按解题操作拆分。没这个定义，我不会把泛化二字看得太重。 放到过去一年的脉络里看，这篇论文其实是在修补合成推理数据的一条老裂缝。WizardMath、MetaMath、Evol-Instruct 一路下来，大家都证明了一件事：合成数据能把小中模型往上推一截。问题是，越往后做，收益越依赖教师模型分布，题型越来越像，碰到陌生组合就掉分。OpenAI、Anthropic 近来的推理训练也越来越强调 verifier、search、tool feedback，而不是只堆更多链路文本。MathAgent的图约束路线，和这条大趋势是对齐的：少信表面语言，多管中间结构。说真的，这比再发一篇“我们生成了更多高质量CoT”有意思得多。 我自己的疑虑在另一个层面。约束图先行很容易带来一个新偏差：你能搜索到的结构，往往就是你设计得出的结构。如果图语法本身偏向某些可枚举、可验证、可组合的数学关系，模型最后学到的还是“被图语言偏好的数学”。这不一定坏，工程上甚至很实用；但它跟“无人工先验”不是一回事。你选择节点类型、边关系、演化算子、适应度函数，那些地方全是先验。论文摘要说 without human priors，我不太买这么绝对的表述。更准确的说法应该是把人工先验从题面模板，后移到了结构表示和搜索目标里。 还有个现实问题。1K样本就有效，听起来对中小团队很友好；可真正决定门槛的不是1K，而是生成这1K之前用了多少搜索预算。Legislator如果要做adversarial evolution，背后通常要反复评估难度、多样性、可解性，算力账未必轻。片段没给生成成本、候选淘汰率、每道题平均回合数，也没说是否用外部求解器或判题器。没有这组数字，行业里的人很难判断它是“便宜的好方法”，还是“把昂贵算力藏在数据前处理里”。 所以我的结论很直接：MathAgent抓到了数学合成里最该拆开的那一层——结构与表述分离，这点我认可；它也给了一个比seed mutation更像样的技术路线。但论文片段还没给出决定胜负的细节：提升到底有多大，成本多高，OOD定义是什么，复现实验怎么对齐。等正式版本把benchmark表、ablation、graph grammar、过滤器和生成预算摊开，我才会决定要不要把它放进“推理数据方法库”的前排。现在先记成一句话：思路比结果更让我信服，结果还得再验。

LifeDialBench 这篇先把评测条件收紧了：系统必须按时间顺序在线接收生活记录，不能偷看未来上下文。只要这个条件成立，复杂记忆系统没赢过简单 RAG，这个结论就不轻。它直接戳中记忆赛道过去一年的一个老毛病：大家爱堆摘要层、事件图、槽位记忆、分级压缩，论文里看着很工程化，结果一到持续流式场景，先丢的就是细节，先出错的就是时间关系。 我对这条结论基本买账。过去一年不少“agent memory”工作，评测还是离线问答范式：先给一大段历史，再问模型一个问题。这个设定默认允许系统在检索前看完整段历史，连压缩策略都能按最终问题反推，和真实 lifelog 根本不是一回事。你把协议改成在线，很多方法的优势会立刻缩水，因为它们靠的是后验整理，不是前向记忆。我记得 LOCOMO、LongMem、MemGPT 一类工作都碰过类似问题：展示了长期记忆框架，任务一旦换成持续写入、延迟查询、跨天回忆，管线复杂度上去，鲁棒性不一定跟着上去。我没逐个复核这篇对了哪些基线，正文摘录也没给模型名和分数，只能先停在方向判断。 我对作者的叙事也有一点保留。摘要说“过度设计”和“有损压缩”在 lifelog 场景里吃亏，这个判断大体合理，但现在证据还不够完整。样本规模没披露，EgoMem 和 LifeMem 各自多大没说；RAG 基线怎么切块、嵌入模型用什么、检索 top-k 多少，也没说；在线评测的查询频率、延迟约束、token 预算都没说。少了这些参数，“复杂系统不如简单基线”这句话很容易被误读成“结构化记忆没用”。我不这么看。更准确的读法是：在生活记录这种高噪声、强时间性的输入里，压缩一旦过早发生，错误是不可逆的；RAG 至少把原始证据留住了。 这点和代码助手、企业知识库那类场景不一样。代码仓库是低熵文本，文件边界清楚，摘要损失相对可控；生活记录音频和对话是高熵、多说话人、充满省略和指代的流。你把“昨天电梯里谁提过牙医预约”压成一个事件节点，后面要追问时间、地点、参与者、语气，信息很容易已经没了。所以我一直觉得，记忆系统在 lifelog 里先别急着学数据库 schema，先学证据保全。检索命中原文片段的能力，很多时候比你设计了几层 memory bank 更值钱。 还有一个上下文，文章里没展开，但做这类 benchmark 很容易把上游识别误差藏起来。lifelog 多半先经过 ASR、说话人分离、时间戳对齐，再进入记忆模块。只要前面任一环掉点，后面再漂亮的 memory architecture 都是在脏数据上做二次加工。摘要没说明 EgoMem 是否直接提供干净转写，还是包含真实 ASR 噪声；也没说明 LifeMem 的模拟社区对话有多接近现实。如果大部分数据是合成且转写干净，这个 benchmark 更像是在测“时间受限检索”，还没完全测到“现实生活记忆”。这不是坏事，但边界要讲清楚。 说真的，这篇的价值不在“又多了一个 benchmark”，而在它把很多记忆论文最舒服的评测设定抽走了。要是后续开源结果能证明：同样 token 预算下，保留原始片段的简单 RAG 反复赢过分层压缩、知识图谱式记忆、摘要缓存，那记忆赛道得老实一点，少卖“像人一样记住你的一生”这种话。眼下我还没查到具体分数，所以不会把它吹成定论；但方向上，这篇像一次必要的回炉测试。很多记忆系统不是不会记，是太早开始“理解”，于是先把证据弄丢了。

论文作者用 679 份规则文件、25532 条规则、5000 多次 agent runs 测了 SWE-bench Verified，结论很直接：规则能把成绩抬高 7 到 14 个百分点，但起作用的主要不是“高质量经验”，而是上下文启动效应。两家来源的标题完全一致，角度也几乎没有分叉，我看这更像对同一篇 arXiv 原文的复述，不是两套独立报道链条，所以信息源头基本只有论文自己。 我对这条的第一反应不是“规则没用”，而是很多团队把 rule file 当成 prompt engineering 的延长线，这个前提被论文正面撞了一下。作者说随机规则和专家精选规则效果接近，这很刺耳，因为它直接挑战了 Claude.md、.cursorrules、repo instruction 这一整套社区手艺活。如果随机规则也能涨分，说明大量规则文件提供的不是可执行策略，而是让模型进入“我要谨慎做代码修改”的工作模式。这个解释我基本买账。过去一年大家在 Cursor、Claude Code、OpenHands 一类工具上的体感也差不多：一旦 system prompt、tool loop、repo map 已经很重，额外再塞几十条“要遵守团队风格”“先理解架构再修改”之类的话，经常只是在重复语气，不是在增加信息。 论文里最硬的一点，是负向约束单独看有益，正向指令单独看反而伤成绩。摘要给出的例子是“不要重构无关代码”这类 negative constraints 有效，“遵循代码风格”这类 positive directives 有害。这个结论很符合 coding agent 的失败模式。SWE-bench Verified 这类任务，常见翻车点不是模型不会写 patch，而是它顺手多改、乱重构、把局部修复扩成全仓清扫。负向规则直接压这类错误面，收益会很实。正向规则的问题在于目标太宽，容易把模型注意力从“修对这个 bug”拖向“表现得像一个好工程师”。在 agent loop 里，这类偏移会放大，因为每一步 tool use 都会继承那套叙事。 我也得 push back 一下：摘要里把现象解释成 potential-based reward shaping，这个理论包装我先保留意见。它是个挺整齐的解释框架，但正文没在这里展开实验细节，我还没看到足够证据说明这是主要机制，而不只是一个事后可解释故事。尤其“随机规则和专家规则差不多有效”这点，更像 context priming 或 attention allocation 的问题，不一定需要上升到 reward shaping。要说服做 agent infra 的人，最好给出更细的消融：规则长度、语气强度、位置、与 system prompt 的重叠度、是否影响 tool selection、是否改变 edit size 分布。摘要没披露这些。 还有一个很有意思的反常识点：单条规则大多单独有害，合在一起反而整体有益，而且堆到 50 条都没出现退化。这个结果我不会直接外推到生产环境。SWE-bench Verified 的任务边界清楚，run 长度有限，评测目标单一；真实仓库里，50 条规则不退化这件事，我自己不敢照单全收。很多团队的实际问题不是 benchmark pass rate，而是 latency、token cost、agent 犹豫时间、无效搜索步数。摘要没有给 token 开销，也没有给每次 run 的轨迹变化。要是 7 到 14 个点的提升换来显著更长上下文和更慢迭代，工程上未必划算。 这条事件被两家来源同时收录，本身说明社区对“规则文件到底有没有用”这件事有真实焦虑。过去一年，这套做法几乎成了默认配置：仓库先放 README，再放 AGENTS.md、CLAUDE.md、.cursorrules，然后大家互相抄模板。论文这次给出的不是“别写规则”，而是写法要换。少写身份训话，少写流程口号，少写风格宣言；多写硬边界，特别是禁止越界修改、禁止无关重构、禁止跳过测试或验收步骤。你把 rule file 当成行为约束层，收益更稳定；你把它当成价值观宣讲，模型大概率只会更啰嗦。 我还想补一个外部对比。OpenAI、Anthropic、Google 这几年在 agent 方向的经验，其实都越来越像“把动作空间收紧，再给工具反馈闭环”，不是“多写几段自然语言教模型做人”。像 code interpreter、structured tool calls、patch apply、test gating 这一类设计，本质都是 guardrail，不是 guidance。论文只是把这件事用一个大家都在用的 artifact 量化了。很多人以为是 prompt 写得不够巧，我看更像控制面放错层了。 所以我对这篇论文的判断很明确：它不是在否定 repo rules，而是在给 repo rules 去魅。规则文件不是知识注入器，更不是经验蒸馏器。多数时候，它只是一个低带宽的约束接口。把这件事认清，能少走不少弯路。