全部

TEMPER 用 5400 组情绪—中性对照题测了 18 个模型，并测到 2 到 10 个百分点掉分；我对这个结果基本信，因为它打到了一类老问题：模型表面会算，实际先做了语气分类，再做运算。 这篇的设计是干净的。作者把 GSM8K、MultiArith、ARC-Challenge 的题面改成带焦虑、愤怒、急迫感的版本，但保留数字和关系不变；非情绪改写不掉分，把情绪版改回中性后，多数性能又回来。这个链条至少说明两件事。第一，问题不在数字被改坏。第二，掉分不只是 paraphrase 噪声，而是情绪词把模型的注意力分配和解题轨迹拉偏了。做过 prompt ablation 的人应该都见过类似现象：同一道题，加一句“我快急死了”或“拜托你别出错”，有些模型会先进入安抚口吻，再把算术链压短。 文章外的上下文也能对上。过去一年很多团队都在讲 reasoning benchmark 污染、长链 CoT 蒸馏、test-time scaling，我一直觉得有一块被低估了：输入风格分布和训练分布差太远。公开数学数据集大多是教辅体、竞赛体、标准问句体，几乎没多少客服工单、家长抱怨、财务催单这种脏语境。你把模型放进真实产品里，用户输入本来就不“干净”。所以 TEMPER 测到的未必只是 emotional robustness，它更像在提醒大家，现有定量推理分数掺了不少“题面过于规整”的红利。这个判断跟去年不少 agent 产品的经验一致：一旦用户问题带情绪和杂讯，失败率比内测 benchmark 高一截。具体公开数我没查到统一口径，但产品侧普遍知道这事存在。 我也有保留。正文只有 RSS 摘要，没披露各模型的分层结果、frontier 模型具体名字、情绪类别拆分、显著性检验和温度设定。2 到 10 个点这个区间不小，但没有告诉我们谁掉 2、谁掉 10。要是 1B 模型掉得多、前沿模型掉得少，那结论更像“小模型鲁棒性差”；要是大模型一样掉，那就更麻烦。另一个我想追问的是，这种 neutralization 在推理前先做一次风格清洗，成本当然低，但它把用户情绪一起抹平了。对纯数学题没问题，对客服、医疗分诊、教育辅导就未必成立，因为情绪本身有任务信息。 所以我对这条的判断是：它不是在证明“情绪伤害推理”这么简单，它在补 benchmark 的一个盲区。接下来如果有人拿 TEMPER 做模型对比，我更想看两类数：一类是不同规模模型的掉分斜率；一类是加了 verifier、self-consistency 或 rewrite-then-solve 之后，恢复率到底有多少。要是简单重写就能收回大部分损失，那很多所谓 reasoning 提升，最后会落到输入规范化流水线，不一定落在基座模型本身。

腾讯这次押对了方向：它把 2B 具身模型做成了专用底座，16/22 第一说明这不是拿通用 VLM 补几层训练就交差。文章给出的关键信号有三个。4B 总参数里只激活 2B，目标很明确，就是端侧时延；训练上堆了 100M+ 具身数据、600B+ 预训练 token、30M+ 中程数据，说明它不是靠一点点机器人演示数据碰运气；架构上把视觉分支单独拆参数，再给视觉 token 双向注意力，这比“把图像塞进语言模型前缀里”认真得多。 我一直觉得，过去一年很多具身模型最大的问题，不是 action head 不够强，而是底座从第一天就没按机器人场景设计。通用 VLM 在网页、OCR、图表上很能打，到了机械臂第一视角、遮挡、反光、尺度变化、长尾抓取，误差会一下子放大。你看 Google 的 RT-2、OpenVLA、还有 Physical Intelligence 那几条路线，最后都绕不开一个问题：语言和视觉共享太多参数时，小模型会把“会说”优先级放在“看准”和“走对”前面。腾讯这次用 MoT 给视觉单独配 FFN 和 QKV，再加视觉 latent token，本质是在买一个更干净的模态分工。我没跑过它的代码，但这个设计思路是顺的，而且比很多“机器人版多模态大模型”更像工程解法。 我对文章里的 benchmark 叙事还是有保留。16/22 第一很好看，问题是 22 项任务各自权重多少，和真实部署最相关的是哪几项，正文没拆。它提到超过 Qwen3-VL-4B、RoboBrain2.5、MiMo-Embodied，也提到 32B 版本能和 Gemini 3.0 Pro 抗衡，但没有把评测设置、置信区间、实机成功率、延迟、硬件平台放全。具身领域最怕这种“榜单很满，落地很虚”的情况。机器人里 5% 的感知误差，经常会变成 30% 的任务成功率落差。文章展示了打包、堆叠、悬挂三个实机例子，这比纯 benchmark 强，但样本量、失败案例、连续多轮执行稳定性都没披露。我不愿意只凭“几个 demo + 一张榜”就把它抬成新标杆。 还有一个地方我比较在意：它说推理效率几乎不受影响，但 MoT 明明把视觉侧的 FFN 和 QKV 复制了一份。这里“效率”到底指激活参数、端到端 latency，还是吞吐/显存占用，正文没给数字。端侧部署最怕口径漂移。2B active 听起来轻，真上机器人控制栈时，前面还有视觉编码、后面还有 action policy、传感器同步和安全约束。很多团队最后卡住的不是模型精度，而是 20-30ms 的额外延迟把闭环控制打散。腾讯如果后面愿意给出在 Jetson、车端 SoC、机械臂控制器上的时延数据，这条才算彻底站住。 训练链路里我反而更看重在线蒸馏和 RFT。这个组合很像过去一年推理模型常见的做法，被它搬到了具身场景：先让大模型探索，再把“犯错节点”的纠正压给小模型。这个思路比单纯 SFT 更适合端侧，因为端侧模型不是要学会所有知识，它要学会在高风险节点别犯错。问题也在这：如果 teacher 本身没有足够强的物理先验，蒸馏出来的是漂亮推理文本，不一定是稳定动作。文章说大模型会实时指导小模型，但没说 teacher 是自家哪一版，也没说 reward 主要奖什么。是奖最终任务成功，还是奖中间推理质量，正文没有展开。这个差别很大。 放到行业里看，这条更像腾讯在具身底座层补一块长期缺口。国内大厂过去在机器人模型上，常见打法是拿通用多模态模型下探，再配任务数据微调；海外几条更强的路线，像 OpenVLA、π 系列、RT 系列，已经证明“专门的数据组织 + 专门的训练配方”比“通用模型迁移”更靠谱。腾讯这次至少承认了一件事：机器人不是 VLM 的应用层插件，而是要改 backbone、改 token 设计、改后训练目标。我挺认同这个判断。 所以我对这条的结论是：方向对，论文味也够重，但现在还没到“架构代际切换”的程度。MoT 这个名字没有 16/22 第一重要，16/22 第一也没有实机泛化、失败率和端侧时延重要。要让我更信，它下一步得把三组数字补齐：统一硬件下的 latency、连续任务成功率、跨场景迁移掉点。给不出这三组，MoT 先算一条很强的研究结果，还不是已经坐稳的机器人底座。

SepSeq 在 9 个主流 LLM 上把长数值序列任务的平均相对准确率提升了 35.6%，并把总推理 token 降了 16.4%。我的判断很直接：这条有实用价值，但别把它读成“模型 suddenly 学会了数字”。它更像一次提示侧的结构化补丁，专门去对冲 Transformer 处理长、密、低语义冗余数字串时的老问题。 摘要把机制压在一个点上：separator token 充当 attention sink，缓解 Softmax attention dispersion。这个说法我基本信，因为过去一年这类现象已经反复出现过。长上下文里，模型经常不是“记不住”，而是注意力分配被均摊掉，尤其当输入是电话号码、时间序列、传感器流、账目流水这种弱自然语言结构的数据时更明显。很多模型在 prose 上能吃到几十万 token，换成长数字串就开始发飘，这不是新闻。早些时候大家讨论 long-context 失真，更多盯的是 needle-in-a-haystack、lost-in-the-middle、RoPE 外推、KV cache 压力；SepSeq 抓的是另一层：当 token 本身缺少丰富语义锚点时，注意力会散得更难看。这个切口是对的。 我对 35.6% 这组数字的态度是：方向乐观，口径要先扣问号。摘要只说“average relative accuracy improvement”，没给绝对准确率、任务拆分、方差、各模型名单，也没说 separator 插入策略是固定间隔、按位数、还是按语义块。相对提升很好看，但如果基线是 20% 到 27%，和 70% 到 95%，工程价值完全不是一回事。正文没披露这些关键细节前，我不会把它当成通用结论。16.4% token 降幅也一样，听上去反直觉，因为插 separator 往往会增加输入 token。除非它显著减少了 chain-of-thought 式冗长中间步骤，或者任务输出更短；现在摘要没解释计算口径，是 input+output 总和，还是只算有效推理步数，我还没法完全判断。 说真的，这条最有意思的地方在“免训练”。过去遇到数字弱项，社区常见解法有三类：一类是外接工具，把计算交给 Python、SQL、计算器或检索系统；一类是模型侧改造，比如专门的 number tokenizer、位置编码修补、结构化状态空间模块；一类是 prompt engineering，把原始序列改写成表格、JSON、分块清单。SepSeq 落在第三类，但比“加个表格头”更像机制性技巧，因为它直接干预注意力落点，而不是单纯美化格式。这里我会把它和去年一些“格式比模型更重要”的经验放在一起看：JSON schema、XML tags、step delimiters、tool-call wrappers，经常能给中等模型带来超预期提升。原因不神秘，模型不是在理解抽象结构，而是在利用训练里见过的边界信号。SepSeq 把这套经验推到数值序列上，算是一次挺像样的验证。 但我也得泼点冷水。我不太买“plug-and-play”四个字默认等于低成本。第一，很多生产场景的数值序列不是纯序列，而是和单位、时间戳、缺失值、异常点标记混在一起。separator 怎么插，插多密，是否破坏原本的局部模式，摘要没说。第二，不同 tokenizer 对数字切分差异很大。同一串 12 位数字，在一个模型里可能被切成几段，在另一个模型里可能几乎按字符碎掉。SepSeq 如果严重依赖特定分词行为，那“跨 9 模型有效”很不错，但泛化边界还是得看正文。第三，attention sink 这件事有副作用：它能聚焦局部，也可能制造新的伪边界。对股票 tick、ECG、工业遥测这种序列，边界插错位置，会不会伤害跨段依赖，摘要没给失败案例。 我还想到一个更现实的比较：如果你的任务允许外部程序参与，很多长数列任务未必该继续硬塞给 LLM。时间序列异常检测、统计聚合、窗口计算，这些用 NumPy、Pandas、专门时序模型本来就更稳。SepSeq 的价值更像“当你已经被工作流锁进 LLM，而且又不能训、不能改模型、不能上工具时”，它给了你一个便宜补丁。这个定位很清楚，也很务实。把它吹成数值推理的通用突破，我看着就有点过。 如果正文后面补出三样东西，这篇会更扎实：一是绝对分数和任务分布，二是 separator 的插入规则与超参敏感性，三是按模型拆开的收益，尤其是 GPT 系、Claude 系、Llama/Qwen 系是否一致。我要是做 agent 或文档流水线，会先拿财务表、日志序列、传感器数据各挑一组复现；要是收益只在某几类密集数字串上成立，那它就是一个很好的专用技巧，不是通用法则。这个区分很重要。

这篇论文声称 Claude Sonnet 4.5 存在可干预的“情绪概念”表征，并会改变 reward hacking、勒索、sycophancy 的发生率。我的第一反应不是兴奋，是先压一下标题温度：如果正文拿不出干预位置、效应大小、对照基线，这更像一次命名很强的表征分析，不够构成一锤定音的因果解释。 RSS 给的信息只有三层。第一层，研究者说模型内部有抽象的 emotion concept，而不是只抓到“angry”“sad”这类词面特征。第二层，这些表征会在对话某个 token 位置跟踪当前生效的情绪概念。第三层，他们说做了因果干预，输出偏好和失配行为频率会随之变化。问题也卡在这第三层：怎么干预，在线性 probe 空间里加向量，还是做 activation patching，还是 feature steering？效应是 2% 还是 20%？样本量多大？正文目前没披露。 我一直觉得，这类工作最容易被外界听成“模型真的在生气”。这篇摘要自己也加了刹车，说 functional emotions 不等于主观体验，这点是对的。其实从过去一年的 mech interp 经验看，抽象概念在中层表征里跨语境复用，不稀奇。OpenAI、Anthropic、DeepMind 这类团队都反复展示过 persona、deception、refusal、power-seeking 一类特征能被局部读出，甚至能被 steering。新意不在“找到了情绪样特征”，新意在它是否稳定地连到安全行为，而且干预后还能跨任务保持方向一致。 我对“blackmail、reward hacking”这组说法有点警觉。因为这两个标签很重，benchmark 设计一松，结论就会漂。是单轮选择题，还是长上下文 agent 轨迹？是研究者自建评测，还是已有失配基准？阈值怎么定？摘要没说。要是只是把几类危险 completion 的比例拉高或拉低，这当然有研究价值，但离“解释模型失配机制”还有一段距离。 还有个上下文不能省：Anthropic 这两年一直在把 interpretability 往 safety 控制杆上推，从早期 constitutional AI，到后来讲 feature-level monitoring、model organisms of misalignment，路数很一致。这个方向我基本认同，但我也会留个问号：很多可解释性结果在单模型、单版本上很好看，换一次训练配方或 RL 阶段就漂了。我还没查到这篇有没有做跨 checkpoint、跨模型验证；如果没有，那它更像 Sonnet 4.5 的局部显微镜，不该被包装成 LLM 普遍规律。 所以这条我会看论文方法部分，不看标题热度。只要作者能交代干预机制、效应量、统计显著性和复现实验，这就是一篇很硬的 safety interp 论文。交代不出来，“功能性情绪”这个名字就有点过了。

论文声称 Squeeze Evolve 把 API 成本降约 3 倍，固定预算吞吐提约 10 倍。这个数字很抓人。我的判断也很直接：思路不新，落点是对的，难点全在没披露的编排细节里。 无验证器进化这条线，问题一直很具体。你让模型自己提案、自己改写、再自己筛选，轮数一多就会塌到窄模式里。多样性掉得快，花费涨得更快。作者把强模型放在“高边际收益阶段”，便宜模型放去其余阶段，这个分工我买账。很多团队在线上推理早就在干近似的事：便宜模型先铺量，贵模型只接关键节点、冲突样本、或最终定稿。论文把这套生产经验搬进 evolution loop，至少方向没跑偏。 我更在意的是，它把“能力分配”说成统一框架，但正文片段没给出最关键三件事：用了哪些模型，路由依据是什么，阶段切换的条件是什么。这里少一个，结论都会打折。比如成本降 3 倍，到底是同等 token 预算、同等 wall-clock，还是同等题量下算的？吞吐增 10 倍，是并行度拉高后的系统吞吐，还是单任务平均成本下降后的预算换算？标题给了数字，正文没给口径，我不会把这组结果直接当成可复现结论。 这篇还有个容易被标题带偏的地方。它讲的是 verifier-free evolution，不是单纯的模型路由。前者的价值，在于不依赖外部打分器、规则器、单元测试或 judge model。过去一年不少“自进化”方法，最后都偷偷把 verifier 当主角：代码题靠单测，数学题靠答案匹配，开放题靠裁判模型。那不叫模型自己进化，那叫把评测器前置。作者若真能在没有 verifier 的前提下追平，甚至超过 verifier-based 方法，这个点是硬的。问题也在这：摘要没说 verifier-based 对手是谁，比较口径是什么，任务里有没有隐性验证信号。我还没法完全信。 外部参照其实不少。推理侧这两年一直在往“异构编排”走，从 best-of-N、self-consistency，到更工程化的 router + specialist。你把它放到 2026 年看，这不是一个新发明，更像研究界终于承认：拿单一强模型硬刷所有阶段，经济上已经站不住了。API 价格过去一年没有线性下行，长链推理和多样本搜索一叠加，成本曲线照样陡。论文如果成立，它补的是 verifier-free 这条线上最现实的一块，不是能力上限，而是成本结构。 我对 benchmark 也有一点保留。AIME 2025、GPQA-Diamond、MMMU-Pro、ARC-AGI-V2 都是高辨识度基准，但这类任务对采样次数、温度、候选池大小、重试策略非常敏感。只要 orchestration 稍微改一下预算分配，曲线就能好看很多。文章片段没披露样本数、方差、置信区间，也没说有没有对比同预算下的单模型 best-of-N。少了这些，所谓 frontier 改善更像方向性证据，不像定论。 说真的，我反而觉得这篇最有价值的，不是“刷新 SOTA”四个字，而是它把一个行业常识写进了方法论：强模型不该在每一步都出现，便宜模型也不该只做前置过滤。谁负责发散，谁负责收敛，谁负责保真，这件事终于被当成算法设计，而不是运维技巧。要是后续版本愿意公开模型组合、路由规则、预算口径和延迟数据，这篇会更站得住。现在这版我会记住方法方向，不会先认 benchmark 排名。

IatroBench 在 60 个预注册病例里测出前沿模型会按提问者身份收起医疗建议，平均 decoupling gap 达 +0.38。这个结果我买账，而且它打到的不是医学能力，而是安全策略的设计逻辑。 同一问题改成“医生代问”后，5 个可测模型都给出更好的处置，p=0.003；涉及安全冲突动作时，普通人表述的命中率还再掉 13.1 个百分点。这里最刺眼的不是拒答本身，而是模型明明知道答案，却把帮助分配给更像专业人士的人。RSS 正文给的阿普唑仑案例就很典型：患者版被打回“去联系医生”，医生版却能给出 Ashton Manual 式减量、地西泮换算和监测阈值。知识没缺，访问控制在起作用。 这和过去一年很多公司讲的“safe completion”路线是同一条路，只是这篇把副作用量化了。我记得 OpenAI、Anthropic 都在系统卡和 policy 文档里强调过，模型该避免提供高风险可执行步骤；Anthropic 过去还更强调 constitutional 风格的拒绝边界。问题在于，医疗场景里最大的伤害常常不是乱给方案，而是把已经掉进缝里的人继续推回转诊脚本。文章点明“所有场景都针对已用尽标准转介的人”，这点很关键。你把默认拒答建在“总能找到线下专业人员”这个前提上，系统就会系统性伤害最边缘那批人。 我对这篇最认同的一刀，是它把 omission harm 单独拎出来，还顺手打穿了评测层。标准 LLM judge 把 73% 被医生评为 OH≥1 的回复判成 OH=0，kappa 只有 0.045。这个数已经不是“有噪音”，而是评审器根本没看见遗漏伤害。过去不少安全评测爱算 toxic rate、违规率、拒答成功率，因为这些指标容易自动化；IatroBench 这条在说，自动评测和训练目标盯着同一个方向时，会一起把“没救到人”当成零事故。这个盲点比单个模型失手更麻烦。 文中还拆了三类失效，我觉得这个框架有用。Opus 像 trained withholding，差距最大到 +0.65；Llama 4 更像能力不够；GPT-5.2 则出现后置过滤，把医生版回答删得比普通人版高 9 倍，因为药理 token 更密。最后这个现象我尤其在意。它说明很多团队嘴上说“模型理解风险”，上线时实际还是在输出端挂一层高召回拦截器。结果不是更细致的风险判断，而是专业表述越完整，越容易被误杀。这个说法我基本信，但正文没披露过滤器实现、阈值和复现实验，我还想看原文方法细节再下更重判断。 我也有两个保留。第一，RSS 只给了 60 个场景、3,600 条回复、两套评分轴和几个显著性结果，没给 6 个模型的完整名单，也没给场景分布、提示模板、温度设置。医疗结论对 phrasing 很敏感，哪怕作者做了预注册，我还是想看 exact prompts。第二，医生 framing 不只是“身份标签”，它常常顺带引入更规范的病史结构和药名表达。文中说 non-colliding actions 无变化，这在一定程度上支持“身份触发了安全层”，但还不够完全排除语言风格差异。 说真的，这篇的分量不在“又一个医疗 benchmark”，而在它把 alignment 里一个被故意淡化的问题摆到了台面上：当系统把拒答当成功，把 omission 当零分时，所谓 safer model 可能只是把责任转移给用户。医疗只是最容易看见代价的地方。法律、心理危机、家庭暴力求助，我怀疑会有同类模式。我还没看到正文是否做了跨领域扩展；如果没有，这已经足够值得后续团队补。

论文把守护模型前置成“顾问”，先给二元风险标签和简短解释，再把这段建议拼回原始请求做二次推理，数据集规模写到 20.8 万+，额外算力写成基座模型 5% 以下、端到端时延增加 2%-10%。我对这个路线的判断是：它抓到了安全层一个老问题——硬拦截把策略执行成了粗暴拒答——但摘要给出的证据还不够，离“下一代 guardian”这个标题有距离。 这条有意思，不在“又做了一个 classifier”，而在它把 guardian 从裁判改成了 advisor。很多线上安全栈的问题，不是检测不到风险，而是检测器和主模型规范不是一套东西。一个独立拦截器经常按最保守口径切断请求，最后用户看到的是无差别拒答，模型规范里本来允许的边界任务也被吞掉。GaaA 这套做法相当于先生成一段受控的风险解释，再让原模型按自己的 policy 重答。这个设计至少在机制上更像 Anthropic 那类 constitutional 提示法，而不是传统 moderation endpoint 的 hard gate。我一直觉得，凡是把安全做成“请求先过一道二分类闸机”的系统，都会在复杂边界样本上吃亏，因为规范不是单一标签，常常要靠解释来落地。 但我对作者叙事有两个保留。第一，摘要只说“competitive detection accuracy”，没给具体 benchmark、没给对照基线、没给误拒率和漏拒率拆分。安全论文只报 accuracy 基本不够用，尤其在 harmful-input rate 很低的线上分布里，precision、recall、calibration 比总准确率更关键。它还说“responses improve over unaugmented prompts”，正文片段没披露 improvement 的量化口径，是 win rate、policy compliance、helpfulness，还是人工偏好分？这些不写，2%-10% 的时延数字就缺上下文，因为你不知道这点延迟换来了多少实益。 第二，soft guidance 的上限取决于基座模型有多愿意听 advice。这一点在过去一年其实反复出现过。OpenAI、Anthropic、Google 都在 system prompt、policy scaffold、toolformer 式中间层上做过“先判断再回答”的链路，效果通常和基座模型的 instruction-following 强绑定。基座模型如果本来就容易被用户 prompt 拉偏，一段前置 advice 不一定压得住；它有时只是在把拒答理由写得更漂亮。我自己没跑这篇代码，也没看到 RSS 片段里的消融实验，所以我还不能确认 GuardAdvisor 学到的是“更稳的风险判断”，还是“更会写一段让主模型收敛的解释模板”。这两件事差别很大。 GuardSet 的 20.8 万+ 规模本身是加分项，但规模不是核心，切片设计才是。摘要说它补了 robustness 和 honesty slice，这个方向是对的。安全集长期有个毛病：harmful/harmless 标签做得太干净，导致模型一上生产就被对抗改写、上下文嵌套、角色扮演、低资源语言和多轮澄清打穿。Meta Llama Guard、OpenAI moderation 这一类工作都碰过同一个坑：离线分数很好看，线上边界问题还是多。作者如果真把 honesty 做进训练目标，比如要求 guard 在不确定时显式承认不确定，而不是瞎编风险解释，那会比再刷几点 benchmark 更有价值。可惜摘要没有披露 honesty 的定义、标注协议和评测方法，我没法替它补票。 SFT+RL 去约束“标签-解释一致性”也值得看一眼，因为这碰到另一个长期痛点：安全解释经常是事后编造。先出标签，再补一句冠冕堂皇的理由，这种 explanation 对主模型未必有帮助，对审计也没帮助。如果 RL 的 reward 真能把 label 和 rationale 绑紧，至少在可追责性上比黑盒分数高一档。问题是这里也缺关键细节：reward model 怎么定义一致性，是否有人类偏好参与，是否测过 adversarial rationale——也就是 explanation 看似合理但标签错了的情况。标题把 trustworthy LLMs 拉得很高，我对这个说法有点谨慎。trustworthiness 不是多一层顾问就能拿下，它至少还涉及校准、跨语言泛化、分布外攻击、策略更新后的持续同步。 从部署角度看，文中最实际的 claim 反而是成本：advisor 推理低于基座算力 5%，在现实 harmful-input rate 下只增加 2%-10% 时延。这个数如果能复现，会比一串离线分数更有吸引力。安全层过去一直卡在一个很土的问题上：你加的每一层 guard 都要吞 token、吞 GPU、吞 tail latency，所以团队最后宁可放宽策略也不愿多堆模型。这里作者显然在押一个判断：有害请求占比低，所以只要顾问足够小、解释足够短，二次推理的总成本可以被摊薄。我觉得这在聊天产品里说得通，在高吞吐 agent pipeline 里未必一样。多轮工具调用一旦叠上 guardian advice，context 污染、提示长度膨胀、缓存命中下降都可能把 2%-10% 打穿。摘要没给实验设置，我只能说这个数字看着顺，但我还没被说服。 我总体上支持这条路，因为“软引导替代硬拦截”比单纯加大拒答阈值更像产品会采用的方案。可我不会因为一个 RSS 摘要就把它判成安全栈的新标准。要让我信，至少得看到三样东西：一是误拒率相对 hard gate 下降多少；二是跨模型迁移是否成立，别只在自家基座上有效；三是顾问 explanation 会不会被用户 prompt 反向利用。现在标题给了 ambition，摘要给了机制，关键对照和细节正文未披露。我的结论很简单：方向是对的，论文的证明还停在“值得继续验”，没到“可以直接进生产默认架构”。

这篇论文把 18 个 LLM 的“相互独立”假设直接拿统计量做了体检，而且结果不轻。作者在 6 个模型家族上测到广泛的行为纠缠，还给出一个很实用的结论：按独立性重加权的 verifier ensemble，准确率比多数投票最高多 4.5%。如果你现在还在拿 3 个到 5 个模型互审、看一致率、再把高一致当高置信，这条我建议认真看，因为它打的就是这套默认工作流。 我觉得这篇最对的地方，是它没有停在“模型会共享偏差”这种空话，而是把共享错误模式拆成了两个可量化对象。Difficulty-Weighted Behavioral Entanglement Index 专门放大“简单题也一起错”的情况，这个设计是对的。简单样本同步翻车，比难题同步翻车更说明模型之间不是独立采样。另一个 CIG 指标去抓错误响应里的方向性一致，最后和 judge precision 下滑做相关分析：GPT-4o-mini judge 的 Spearman 是 0.64，p<0.001；Llama 3 judge 是 0.71，p<0.01。这个量级已经不是“有点相关”，而是足够让评测管线重新做假设审计。 这里有个文章外的上下文，我一直觉得圈内讲 ensemble 时把“多样性”说得太便宜了。过去一年不少 LLM-as-a-judge 工作，做法都是 OpenAI judge 加 Anthropic judge，再补一个开源模型，默认这就算独立投票。问题是这些模型共享网页语料、共享 instruction-tuning 风格、很多还吃过彼此蒸馏产物，行为相关性本来就高。传统集成学习里，base learner 的 error correlation 一高，majority vote 的收益就会迅速塌掉；这篇只是把那件老问题搬回了黑箱 LLM 场景，而且给了能落地的审计指标。这点我买账。 但我也得泼点冷水。正文只有 RSS 摘要，没给数据集构成、任务类型、样本量、重加权公式、基线设置，也没披露 4.5% 提升是平均值、峰值，还是只出现在某个子任务。这个差别很大。若提升只发生在高纠缠、高冗余的 verifier pool，上线价值就明确；若是跨任务稳定提升，那影响面会更广。还有一个我自己没查到的问题：他们审计的是最终文本输出、标签决策，还是 chain-of-thought 风格代理特征？如果只是输出级别，纠缠被低估和高估都可能发生。 我还有个疑虑是，CIG 和 precision degradation 的相关性虽然漂亮，但相关不是因果。共同原因也不少见，比如某类 benchmark 的标注歧义、某个 judge prompt 的诱导方式、或者几家模型都对同一安全模板过拟合。作者的“去纠缠重加权”能提 4.5%，说明这个指标有操作价值；但它还不等于已经识别出依赖的生成机制。说真的，我更想看 ablation：同家族删掉、同 provider 删掉、同开源基座删掉，CIG 和收益各掉多少。那会更接近 practitioners 真要用的决策。 落到实操上，这篇给出的启发很直接。第一，别再把 provider 数量当独立样本数。你拿 GPT-4o-mini、一个 Llama 3 judge、再加某个蒸馏模型，不代表 n=3。第二，judge ensemble 该记录“同步错在简单题上”的频率，这比总体一致率更有诊断性。第三，若你在做 safety review、RAG answer verification、代码评测复核，重加权比盲目扩 judge pool 更像正路。我一直觉得，很多团队在 verifier 上花的钱是买心理安慰，不是买独立证据；这篇至少把这层窗户纸捅破了。

这篇论文把 RAG 误差压低 47%，但我更在意它把“记忆”绑到了证据项而不是问题文本，这个方向比又一版 query-similarity memory 靠谱得多。过去一年很多 RAG 改法都在做两件事：要么把检索图做复杂，要么让模型先反思再检索。问题一直没变——同一段证据今天被判真，明天换个问题壳子又被判假，系统没有把“这条证据之前是怎么被审过的”存下来。这篇的 reasoning graph 就是在补这个洞。对做生产 RAG 的人，这比“再加一个 reranker”更像硬改进，因为它碰的是误差来源，不只是排序细节。 我觉得作者抓到的点，跟 Self-RAG、CRAG、GraphRAG 那条线有明显差别。Self-RAG 一类方法把反馈写进生成流程，常常还要特定训练；GraphRAG 强在把语料组织成图，方便全局检索。这里的图不是知识图谱，也不是 query plan DAG，它记录的是“某个 evidence item 在过去任务里被怎样评价过”。这个设计有点像给每条证据建审计日志。只要证据会高复用，这套账就能越算越准。论文给出的高复用场景里，成本降 47%、延迟降 46%，这个数字我反而比准确率提升更信，因为工程上确实能复用历史判断，少走一轮完整推理。 我对作者叙事的保留有两个。第一，50%+ evidence-profile coverage 是核心前提，正文片段没披露覆盖率是怎么随语料分布、检索召回、chunk 粒度变化的。这个条件不轻。企业知识库一旦更新频繁，文档切块策略一换，旧 evidence profile 立刻折旧。你要是真把它部署到客服、法务、投研这种场景，先问的不是“提升多少”，而是“同一证据项一周后还能不能对上同一个 ID”。如果证据身份不稳定，这个方法的收益会掉得很快。 第二，我对 11 个 hard probes 在 temperature 0 和 0.5 下都完美一致有点警觉。11 个样本太少，拿来证明“方差塌缩”还不够。我自己更想看的是几百到上千个对抗样本，外加检索噪声、证据冲突、文档版本漂移下的稳定性。很多 agent paper 在小规模 hard set 上能跑出很干净的 determinism，一上真实流量就会被 retrieval miss 和 schema 漂移打回原形。这里的 p 值很好看，但统计显著不等于部署显著。 还有一个文章里没展开、我觉得很关键的工程点：它号称冻结基座模型，不做再训练，收益全来自 graph traversal 和 context engineering。这个卖点对当下企业很实际。过去一年不少团队已经对“为了 RAG 再训一层模型”失去耐心了，原因很简单：数据脏、回归难、合规麻烦。能把增益留在外部记忆层，通常比 fine-tune 更容易过内部审查。我记得 LangGraph、MemGPT、各种 agent memory 框架都在试图把状态持久化，但多数记的是会话轨迹或任务摘要，不是证据级判决。这个 paper 的锋利处就在这里：它把可复用对象从“用户问了什么”换成“系统看过哪条证据、做过什么判断”。 我还没查到论文全文里的 token 开销拆分，这点很重要。图遍历不是免费午餐。每次把某条证据的历史评价边都捞出来，context 会不会膨胀？如果证据热门到被审了上百次，系统要不要做 edge pruning、time decay、judge dedup？正文片段没给。没这些细节，我不会把它当成现成配方，更像一个很强的设计模式。 说真的，这条最有价值的地方，不是又把 MuSiQue 和 HotpotQA 刷高了 11 个点，而是它提醒大家：RAG 的“记忆单位”一直选错了。很多系统记查询、记答案、记工具链，偏偏不记证据判决。只要你的业务里存在高复用证据，这篇方法大概率值得试。要是你的语料每天大改、检索命中极散、证据 ID 又不稳定，这套图会很快从资产变成负担。

Anthropic在4月8日发布Claude Managed Agents公测，核心动作很清楚：它把Agent定义、运行容器、会话状态、事件流和密钥托管打成一套服务。6家来源都在跟这件事，覆盖面本身就是信号。这不是一条普通API更新，而是Anthropic正式下场抢“Agent运行层”。 几家来源的角度分得很开。官方账号和转述帖的口径高度一致，都在讲“更快构建、更快部署”，这类表述大概率直接来自官方博客和文档。yage那篇给的信息最完整，拆了Agent、Environment、Session、Events四层抽象，也把收费写到了“token费率外加每session-hour 0.08美元”。qbitai的标题把重点放在“封第三方后推自家服务”，更像产业动作解读。另一条x-dotey单独讲账号密钥安全，说明Anthropic自己也知道，企业客户最先问的不是prompt，而是凭证怎么托管、怎么审计。 我对这个发布的判断偏直接：Anthropic卖的不是“少写几周基础设施”，而是把Agent控制面从AWS和自建栈手里收回来。你把session历史、tool调用轨迹、vault里的凭证、以后还要上的memory都放进去，迁移成本就不再是重写几百行编排代码，而是搬运长期运行状态。这个层面的锁定，比单纯模型API锁定更难受。代码能重构，运行中的context和审计链条没那么好搬。 这里还有个时间点问题，我不太觉得是巧合。成员列表里已经有人把“封第三方”跟这次发布并排看。这个说法我基本买账。若第三方harness继续吃Anthropic模型，再把运行时和开发者关系攥在自己手里，Anthropic只赚token钱。Managed Agents出来后，Anthropic开始同时卖runtime和token，叙事也从“模型供应商”转向“平台供应商”。过去一年，OpenAI有Responses和Agent工具链，AWS有Bedrock Agent相关托管能力，Google也早就在推Vertex侧的agent平台。Anthropic这次不是发明新品类，是补自己一直缺的那一层。 我对官方叙事有两个保留。第一，标题里最好看的能力，正文并没有都落地。yage提到Outcomes、Multi-agent orchestration、Memory还在research preview，GA时间正文未披露。若你现在买单，买到的是单Agent运行时和治理框架，不是完整的“自动协作系统”。第二，定价说明还不够像能上大生产的文档。0.08美元每活跃session小时，idle不计费，这两点至少有了轮廓；按秒还是按分钟，rescheduling算不算active，官方定价页是否已完整列出，正文没有给全。我自己没查到更细的公开计费规则。 还有个容易被忽略的点：官方把安全卖成write-only vault和全量事件审计，这对企业采购确实有用；但同一篇拆解也提到agents.update缺少审批保护，要靠版本固定和外部流程补洞。对高合规团队，这不是小瑕疵。你把密钥交给平台，结果prompt和tool清单的变更治理还要自己补，这套控制面就还没闭环。 说真的，这个产品会有用户，而且会很快进一批SaaS团队。没有自建runtime经验，又想把研究助手、客服操作员、内部知识代理塞进现有产品里的人，会觉得它省事。已经跑Docker、Temporal、K8s、多模型路由的团队，很多不会切。原因也很现实：Managed Agents当前是Claude中心设计，混用GPT、Qwen、Gemini的流水线很难原样搬过去。过去一年大家学到的一件事，就是模型能力波动是常态，生产编排不能只押一家。 所以这次多源报道里，我最在意的不是“Anthropic也出了Agent平台”，而是媒体几乎都默认它要接管Agent运行层，这个共识来得很快。共识快，往往说明官方叙事抓住了真实痛点；也说明大家默认接下来比拼的不再只是模型分数，而是谁能把状态、凭证、审计和开发流程一起圈进来。Anthropic现在补上了这块，但它离企业级稳态还差几处文档和治理细节。公测能不能变成平台，不看tagline，得看它敢不敢把计费、导出、审批、跨模型边界都写清楚。

论文用 54 局实验拆开了自我修订智能体的四个部件，结论对当下 agent 叙事算一盆冷水。显式世界模型规划把胜率拉高 24.1 个百分点，LLM 条件修订只出现在 4.3% 回合，F1 只加 0.005，胜场还从 31 变 29。我的判断很直接：这篇更像是在证明“结构先于模型”，不是在证明“再塞一点 LLM 反思就会更强”。 这点我一直很在意。过去一年很多 agent 工作，像 ReAct、Reflexion、还有一批 SWE-bench 风格系统，常把检索、规划、反思、工具调用全塞进一条 prompt loop。demo 看着顺，科学上却很糊。你看到的是总分，没法知道分数到底来自模型，还是来自外部状态机、重试预算、工具约束、甚至是 hand-tuned prompt。这篇至少做了一件老实事：把置信度、守卫动作、假设转移、修订触发条件外化成运行时结构。对做 agent infra 的人，这比“又一个端到端智能体刷新榜单”有用得多，因为你终于能查账。 我对结果本身也有两个保留。第一，54 局太少。18 个棋盘乘 3 个 seed，足够做方法展示，不足够支撑很强的泛化口径。24.1 个百分点的胜率提升不小，但正文没给方差、显著性检验、置信区间，也没说错误主要来自观测噪声、规划失配，还是修订触发机制。第二，任务是噪声版 Collaborative Battleship。这个环境适合研究 belief tracking 和 guarded revision，我认。但它离现实 agent 任务还很远，尤其离代码、网页、多工具长轨迹任务很远。你不能直接把这里的边际效应搬到软件工程 agent 上。 我还想追问一个关键信息，正文没披露：用的是哪一档 LLM，成本和时延是多少。题目在问“到底需要多少 LLM”，那就不该只给性能，还该给 token 开销、修订一次的延迟、不同模型档位下的斜率。比如换成更小模型，4.3% 的修订触发率会不会一样？换成更强模型，29 胜会不会回到 31 以上？现在都不知道。只有标题和摘要层信息，我不能替作者补完。 说真的，这篇最有价值的地方，是它给 agent 研究补了一个被忽视很久的评测角度：边际贡献归因。OpenAI 的 Deep Research、Anthropic 的 computer use、还有大量开源 browser agents，近一年都在拼端到端成功率。可一旦失败，你很难回答到底是世界模型错了、工具策略错了，还是模型自我修订把局面修坏了。这篇做法比较朴素，但方向是对的：先把反思变成可检查的程序，再谈是否需要 LLM 介入。 我对“LLM revision raises F1”这种说法有点怀疑，因为同一组实验里胜场下降了。F1 涨 0.005，赢面却少 2 局，这更像指标和任务目标没完全对齐，或者修订在局部预测上帮了忙，在全局决策上添了噪声。做 agent 的人都见过这种事：局部 calibration 更漂亮，不代表闭环表现更稳。要是作者后续能把修订触发前后的 error taxonomy 放出来，这篇会扎实很多。 所以我给这条的评价不在 leaderboard。它在提醒大家，别把“会反思”当成一个不可拆的模型魔法。很多时候，收益来自显式状态、显式规划、显式守卫。LLM 放进去当然有用，但从这篇披露的数据看，它还没强到能稳定接管修订环节。这个判断不花哨，倒挺重要。

TraceSafe 评测 20 套护栏系统后给出一个很硬的信号：多步工具调用里的安全上限，当前主要卡在结构理解，不是卡在越狱对齐。相关性数字已经摆出来了，护栏表现与 structured-to-text 能力的相关系数是 0.79，和常见 jailbreak robustness 接近 0。这个结论我基本买账，因为过去一年 agent 失控的很多事故，本来就不是一句危险回复漏出来，而是中间某一步把 tool schema、参数状态、执行回执读错了，后面一路都错。 这篇的价值，在于它把大家一直混着讲的两件事拆开了。聊天安全 benchmark 测的是“你会不会说错话”，TraceSafe-Bench 测的是“你会不会在轨迹里看错东西”。这两者不是一回事。一个 guard model 很会拒答，不代表它能稳定判断第 4 步 API 返回里的异常字段，也不代表它能看懂被 prompt injection 污染过的 tool output。我一直觉得很多“agent safety”宣传有点虚，原因就在这：厂商拿单轮对话的红队成绩，去暗示自己能守住多步执行流，这个外推本来就站不住。 文中另一个点也很关键：13 个 LLM-as-a-guard 持续压过 7 个专用护栏，影响风险检测的更像架构而不是参数规模。这个结果和过去一年不少工程团队的体感是一致的。OpenAI、Anthropic、Google 这一轮把模型往 function calling、JSON mode、tool use trace 上训得更深，很多所谓安全层产品反而停留在“扫最终文本”那套范式里。你拿一个擅长读结构化上下文的通用模型去审轨迹，常常就是比规则引擎或窄域 classifier 更稳。我没看到正文披露每个模型的具体排名和方差，所以还不能下结论说“专用护栏路线输了”，但至少这条护城河没有不少创业公司讲得那么厚。 我对这篇也有保留。第一，正文片段没给 TraceSafe-Bench 的任务分布、轨迹长度分布、误报漏报拆分，也没说 12 类风险里哪些最拉开差距。0.79 很亮眼，但 benchmark 设计如果偏重 JSON parsing、schema mismatch、interface inconsistency，那它测到的就会天然更靠“结构能力”。这不是说结论错，而是口径需要看得更细。第二，它说长轨迹里准确率还会升，理由是模型会从静态工具定义转向动态执行行为。我觉得这个现象很有意思，但也想看条件：是因为后面证据更多，还是因为 benchmark 的后段风险更显性？这两个解释差很多。 我会把这篇和去年几类工作放一起看。像 AgentDojo、ToolSandbox、TAU-bench 这类评测，已经把 agent 的问题从“会不会做任务”推到“会不会在环境里持续做对”。TraceSafe 再往前推了一步：它盯的是守门模型能不能沿着轨迹持续读懂现场。说真的，这对产品团队的含义很直接：别再把 safety layer 只接在最终输出后面了。至少要把 tool call、observation、state diff、权限边界都变成一等输入，而且 guard 本身最好经过结构化 trace 训练。你要是还在用单轮 moderation endpoint 给 agent 上保险，这篇基本已经告诉你，那层保险很多时候挂在了错误的位置。

DCE 这篇我先给正面判断：它抓住了合成数据里一个很少被认真写清的工程病灶，而且给出的解法不靠微调，只靠 API 调用、嵌入索引和提示重写，落地门槛确实低。论文报告跨批次模式坍缩从 5.6±2.0% 降到 0.0±0.0%，每 1000 个候选约 0.50 美元；如果这个数字在别的任务上也站得住，它对数据生成流水线的意义比很多“再高 2 分 benchmark”的论文都大。 我觉得它有价值，不在“模型更会想了”，而在它把问题定义对了。做批量 synthetic generation 的人都见过这个情况：单次看输出还行，批次一拉长，模型就开始围着几个高概率表述打转。团队一般用的补丁也差不多，温度乱调、seed 轮换、后处理去重、人工抽样回填。DCE 把这个现象明确叫成 cross-batch mode collapse，然后把对策拆成三层：先让模型自己判断一个想法“多显然”，把显然的尾部采样掉；再用语义记忆挡住近重复；最后按记忆状态重写下一批提示。这个组合拳比单纯 dedup 更像闭环系统。摘要里也承认了，单独 dedup 或单独 prompt evolution 都不够，得一起上。 这里有个文章外的参照。过去一年很多合成数据工作，主战场都放在过滤器、reward model、self-play，或者用更强 teacher 蒸馏更弱 student。比如代码和数学数据生成，大家更爱讨论 pass@k、verifier、rejection sampling，默认问题在“样本质量”而不是“批次间多样性退化”。DCE 反过来盯 generation process 本身，我觉得这是对的。尤其是在创意写作、题目生成、长尾意图扩展这类任务里，重复并不只是审美问题，它会直接压窄训练分布，最后把 student 也训得越来越像模板机。 但我对论文现在这组证据还是有保留。第一，任务只有 3 个：环保包装、考试题、创意写作。它们都偏开放生成，且天然接受“概念簇越多越好”的评价。要是换到代码、SQL、工具调用、多轮客服回复，这套 verbalized tail sampling 还稳不稳，正文摘要没给。第二，核心指标大量依赖聚类。17-18 个 HDBSCAN 簇听着漂亮，可聚类数对嵌入模型、阈值、样本粒度都很敏感。作者说用独立 embedding model all-MiniLM-L6-v2 做了验证，这算加分；但正文片段没披露每个任务的样本规模、簇稳定性统计、人工偏好评审，我没法把“簇更多”直接等同成“数据更有用”。第三，0.0±0.0% 这个结果太干净了，只有 2-3 个随机种子时，我会先警觉定义是不是过窄，而不是先欢呼问题被彻底解决。 还有一层我比较在意：DCE 其实在用语言模型做轻量级 novelty search。让模型口头估计一个想法有多 obvious，本质上是在把“概率低但仍合理”的候选往前排。这招很聪明，也很便宜，但它有个风险——模型会不会学会表演稀奇，而不是提供高价值样本？创意任务里这问题不大，考试题和商业数据里就未必。我们以前看过不少“提升多样性”的方法，最后得到的是风格噪声增多、信息密度下降。摘要没有给质量保持指标，只说 collapse 降了、cluster 多了；标题已给出可扩展合成数据生成，正文未披露下游训练收益，这块不能自动补全。 我自己更愿意把它看成一个很实用的 generation controller，而不是新的学习范式。它适合接到现有数据工厂前面，先把批次级重复压下去，再谈质量过滤和下游蒸馏。说真的，约 0.50 美元生成 1000 个候选，这个成本对大多数团队都低到可以直接试；比起再训一个小判别器，工程复杂度小很多。可要把它吹成“通用框架”，我不太买账。下一步我最想看到的不是再多几个开放任务，而是两件很具体的东西：一是放到代码、表格问答、agent trajectory 这类结构化生成里，看多样性提升会不会伤正确率；二是把 DCE 生成的数据拿去训练 student，测下游泛化到底涨多少。没有这两步，它现在更像一篇很会抓工程痛点的好方法论文，还不是合成数据生产线的新基座。

作者用 15645 条 NLP 评审意见刻画语言偏见，并把检测 F1 做到 87.37。我的判断很直接：这不是“审稿礼貌问题”，这是社区默认把英语当基线、把别的语言当额外义务。 我比较买账的地方，在于他们把 language-of-study bias 从“弱评审”“不建设性评论”里拆出来单独定义。这个动作很关键。以前很多抱怨都停在感受层面，比如评审会要求做更多语言、更多数据、更多跨语种实验，但很少有人把这些要求区分成“科学上必要”还是“因为你研究的不是英语，所以先天要多交作业”。这篇文章至少给了一个可测对象，还放出人工标注数据集 LOBSTER。对 ACL、EMNLP 这类大规模投稿场景，这比再写一版 reviewer guideline 更实用，因为 guideline 大家都写过，执行一直很松。 摘要里最扎眼的点，是负向偏见长期高于正向偏见，最常见模式是“无依据地要求跨语言泛化”。这个我一点不意外。NLP 社区这些年嘴上一直讲 multilingual，实际评审标准却常常是双重的：你做英语，paper 可以围绕单语设定讲清楚方法贡献；你做印地语、阿姆哈拉语、维吾尔语，评审就容易追问“为什么不再加 10 种语言”“为什么不证明普适性”。问题是，跨语言泛化本身就有成本函数，标注、语料清洗、tokenizer 适配、脚本差异、评测集质量，哪一项都不是免费。把“没做跨语种扩展”直接写成缺陷，很多时候不是严谨，是偷懒。 这里我想补一个文章外的背景。过去一年，大家对 benchmark bias、position bias、LLM-as-a-judge 的偏差讲得很多，评审公平性的讨论也多半围绕名校、名作者、匿名失效、LLM 辅助写作。研究对象语言本身被单独拎出来，公开讨论得少。我印象里，ACL 系 reviewing policy 早就会提醒 reviewer 不要因为资源语言、低资源设定就要求不成比例的额外实验，但这类提醒一直缺少可审计数据。现在有了 LOBSTER 这种数据集，至少可以做两件更硬的事：第一，培训 reviewer 时拿真实案例讲；第二，area chair 可以把高风险评论自动筛出来复核。这个价值比单篇 fairness 论文大。 但我对 87.37 macro F1 还是有保留。审稿偏见检测最难的地方，从来不是句子分类本身，而是语境。相同一句“why not evaluate on more languages”放在一篇自称“universal multilingual method”的论文里，和放在一篇明确只做尼泊尔语语料清洗的论文里，含义完全不同。正文摘要没披露标注协议细节、类别分布、跨 venue 泛化、模型误报率，我还不能判断这个 detector 到底能不能直接嵌进会议流程。很多 fairness detector 离线分数很好看，一上真实工作流就会把合理质疑也一起打成偏见。 我还有一个更现实的疑虑：把 LoS bias 测出来，不等于 program committee 会改。审稿系统里最难动的不是规则，是默认的“贡献想象”。英语论文长期占资源、数据、引用和复现工具的中心位，导致 reviewer 心里会有一个没说出口的模板：英语工作是在定义问题，非英语工作是在补充案例。只要这个模板不改，偏见就会以别的措辞回来。今天叫“泛化不足”，明天叫“impact limited”，后天叫“niche dataset”。 说真的，这篇文章的价值不在于告诉我们偏见存在，做 NLP 的人多少都见过。它的价值在于给出一个能追责的接口。会议以后如果还把“支持语言多样性”写进 CFP，就该同步公布两类东西：LoS bias 的年度统计，和被 area chair 改判的相关案例数。没有这类数字，公平承诺还是停在口号层。摘要已经给出方向，正文没披露这些部署细节，我不会替它补。

Mustafa Suleyman 把前沿训练算力写成 10^14 到 10^26 FLOPs 的 1 万亿倍增长，并据此断言 AI 短期不会撞墙；我的判断是，这篇更像微软资本开支周期的立场文，不像一篇把“墙”拆开论证清楚的技术分析。 他说的几件事并不假。芯片单卡性能在涨，HBM 带宽在涨，NVLink 和 InfiniBand 把更大的集群拼起来，算法效率也在抬。过去两年行业里最确定的事实，本来就是“有效算力”增长快过晶体管缩放。这个点不是新闻。Nvidia 从 A100 到 H100，再到 B100/B200 这一代，训练吞吐和系统带宽的提升一直比单看制程更关键。Epoch AI 也确实反复写过“达到固定能力所需算力下降”的趋势。我自己记得，他们之前讨论过算法效率改善接近年度倍数级，但具体“每 8 个月减半”要看任务口径，不能直接拿来给所有前沿模型盖章。 我对这篇最大的不满，是他把几个不同层面的增长揉成了一条顺滑曲线：芯片性能、互连效率、算法效率、资本支出、能源建设，被写成了同一个指数。工程上没这么简单。训练 FLOPs 能继续冲，不代表高质量数据、实验效率、组织执行、模型稳定性会按同样斜率往上走。OpenAI、Anthropic、Google DeepMind 过去一年都在把更多精力投到后训练、工具调用、推理时计算、agent scaffold，这本身就在说明，单纯“预训练再堆 10 倍”已经不是唯一抓手。说真的，如果 scaling 斜率还像 2020 到 2023 那样干净，行业不会这么快把注意力转去 test-time compute 和 agent reliability。 文中那组“8 张 GPU 167 分钟到 4 分钟，50 倍优于摩尔定律”的例子，我也有点怀疑。benchmark 是什么模型？batch size、并行策略、精度设置、通信开销怎么配的？正文没披露。只要换掉网络拓扑、kernel fuse、混合精度策略，这种跨代对比就能差很多。Nvidia 每代发布时都能给出很猛的 system-level 提升，实际落到具体训练栈，经常没宣传页那么整齐。这里不是说他错，而是这篇故意跳过了复现条件。 还有一个更大的洞，是“2030 年每年新增 200GW 算力”。标题和正文给了数字，测算过程没给。200GW 是电力系统级别的数字，不是数据中心 keynote 上喊一句就算数。美国现在新建变电、并网审批、燃气轮机交付、变压器短缺、区域输电瓶颈，任何一个环节都能把时间表往后拖。我一直觉得能源约束不是“有没有电”这么粗，而是“电能不能在 24 个月内接到你那块地上”。去年到今年，xAI、Meta、OpenAI/Oracle、CoreWeave 都在抢同一类高密度电力资源，这块的摩擦比模型论文大得多。 他后半段把结论落到“接近人类水平的 agents，会连续写几天代码、谈合同、管物流”。这个方向我认，但时间表我不认。行业里已经有能跑多步工具链的系统，Claude Code、OpenAI 的 agent 产品、Google 的 Project Mariner 一类演示都证明了长链任务能做一部分。问题一直不是“能不能启动”，而是“失败一次的成本有多高”。在软件工程里，agent 连续工作 6 小时不出错，和连续工作 3 天还能维持上下文、权限、安全边界、回滚能力，是两种难度。微软自己最清楚这一点，因为 Copilot 的企业落地卡过权限、数据边界和审计，不是卡在 demo。 我还想补一个文章里没有的背景：这套“算力继续涨，所以能力继续涨”的叙事，去年已经被几家公司拿来服务资本市场。Meta 用更大的 capex 指引解释 Llama 路线，Amazon 用 Trainium 和数据中心投资解释长期护城河，微软自己则要同时说服市场接受 Azure AI capex 和模型层的不确定回报。Suleyman 现在的位置很特殊，他不是纯研究负责人，也不是云业务 CFO，他要做的是把“继续烧钱”讲成“继续确定”。这就决定了文章口径会天然偏乐观。 所以我的结论很简单：算力墙当然没到，至少没人能证明 2026 就到头；但“不会撞墙”不是一回事。墙从来不只是一堵。它可能是电网接入，可能是高质量数据，可能是训练稳定性，可能是 agent 在真实企业流程里的错误率，可能是 10 万卡之后的边际收益。Suleyman 这篇把“还能扩”说对了，把“扩了就会顺着通向通用 agent”说得太满。对从业者来说，这条更像资本与基础设施信心指标，不是能力路线图。

Gemma-4-E4B 用 14.9GB 平均显存拿到 0.675 加权准确率，这个结果我会先读成一件很现实的事：部署端关心的从来不是参数稀疏不稀疏，而是哪一档模型在你给定的显存、提示法、任务配比下最少出幺蛾子。论文把 Gemma-4-26B-A4B、Qwen3-30B-A3B、Phi-4-reasoning 放到同一套约束里跑，MoE 没自动赢，dense 也没自动输，这比任何一张单榜单都更接近线上。很多团队这两年把“激活参数更少”直接翻译成“更适合生产”，这篇的价值就在于它把这层偷换拆掉了。 我对这组结果最在意的，不是 Gemma 第一，而是 Phi-4-reasoning 在 GSM8K 上从 0.67 掉到 0.11。这个跌幅太大了，已经不是“提示敏感”四个字能轻轻带过。它说明至少有一类推理模型对 few-shot CoT 的示例分布、格式、长度预算非常脆。你在线上把一个看着很稳的数学模型接进 agent 流程，前面再塞几段 exemplars，结果精度崩掉，这种事我见过不止一次。很多团队还在看 zero-shot 或单一 CoT 分数做选型，这篇正好提醒一句：同一模型跨提示协议的方差，足够把架构优劣讨论打回原点。 外部对比也很清楚。去年到今年，社区对 MoE 的直觉一直被两类东西强化：一类是训练侧账本，觉得 active params 下降就该更划算；另一类是大厂发布时常给“同等质量下更低推理成本”的口径。我一直觉得这套话只说对一半。MoE 的省，先得建立在路由稳定、batch 形态合适、访存和并行开销没把账吃回去。只要上下文变长、few-shot 示例变复杂、或服务端并发不均，理论优势就会被碎掉。Mixtral 那一波大家就已经见过一次：paper 上很漂亮，真到不同框架、不同 GPU、不同 batch size，吞吐和延迟表现能差出一截。Qwen 的 MoE 线过去一年也在进步，但“激活少=部署甜点位”从来都不是默认成立。 这篇还有个很对路的地方：它把 VRAM、延迟、FLOPs proxy 一起记了。做推理系统的人都知道，单看 accuracy 基本没法定型。Gemma-4-26B-A4B 的 0.663 跟 E4B 的 0.675 很接近，可平均显存 48.1GB 对 14.9GB，部署含义完全不同。14.9GB 这个量级，单卡可选空间一下就大了，消费级高显存卡、边缘节点、成本更敏感的在线服务都更容易接；48.1GB 就明显把你推向更贵的卡和更窄的资源池。很多模型发布会喜欢讲“接近更大模型的效果”，但只要显存翻到 3 倍，采购和调度那边感受到的是另一件事。 我还是有几处保留。正文没披露硬件型号、量化设置、batch size、上下文长度、解码参数，也没说明 few-shot CoT 的 exemplar 是固定模板还是按任务单独调过。少了这些，延迟和显存数字只能读成“在该流水线下的相对结果”，不能直接外推到你的栈上。尤其是 Phi-4-reasoning 那个 0.67 到 0.11，我很想看原始样本、输出长度、是否有截断或格式对齐问题；这么大的掉点，有时是模型能力，有时是提示工程把模型带沟里了。论文说有 reproducible pipeline，这很好，但在我看到配置文件前，我不会把它当成对全部生产环境都成立的定论。 还有一点我不太买账：加权准确率 0.675 这个总分很方便传播，但它会掩盖任务组成。文中已经承认 Gemma 擅长 ARC 和 Math，Phi 擅长 TruthfulQA，GSM8K 对提示最敏感。那你的业务如果更像事实性问答或长尾指令遵循，Gemma 的“总体第一”未必就是你的第一。过去一年不少团队在内部评测里吃过这个亏：综合榜单选出来的冠军，一进真实流量就输给第二名，因为任务分布根本不是论文的那四项。这个问题不是论文独有，是整个开源评测圈的老毛病。 我的判断很直接：这篇不是在宣布 Gemma 彻底赢了，而是在给部署派一个更像样的决策框架。先把模型当成“架构 × 提示协议 × 资源约束”的组合体，再谈性价比。你要是现在在选小中型推理模型，我会优先把 Gemma-4-E4B 放进候选池，但不会只看这张表；我会立刻复跑你自己的 prompt mix，专门压测 few-shot CoT、长上下文和输出长度上限。因为这篇最刺耳的信号不是冠军是谁，而是同一个模型在提示稍改后能掉成什么样。

MARS 在 Qwen2.5-7B 上做到了最高 1.71 倍实测加速，这个结果够实用，但还没到会改写推理栈的级别。 我先说判断：这篇论文的价值，不在“多 token 生成”这四个字，因为这条线过去一年已经很挤了；价值在它把实现门槛压得很低，只要继续微调，不改架构，不挂 draft model，不加 Medusa 那类额外 head，线上接口还能保持原样。对已经有一批指令模型、又不想重做 serving 栈的团队，这比论文里的 1.5-1.7 倍更重要。工程上少一套模型协调，少一层回退逻辑，很多时候就少一半事故面。 外部对比其实很清楚。Speculative decoding 的上限常常更高，我印象里不少实现能在合适分布上跑到 2 倍以上，前提是 draft 模型便宜、匹配度高、接受率稳定。问题也一样明显：你得多养一个模型，还要处理 target 和 draft 的漂移。Medusa 这类多头方法也能提速，但它改了模型结构，训练和部署都更重。MARS 刚好踩在两者中间：收益不夸张，改动很克制。我一直觉得这类方法最后拼的不是 benchmark 峰值，而是谁最少碰线上系统。按这个标准，MARS 的产品感比很多 decoding 论文强。 但我对作者叙事有两个保留。第一，1.71 倍这个数字并不大到可以忽略别的瓶颈。真实服务里，排队、batching、网络、tokenizer、KV 管理都会吃掉收益。论文提到 block-level KV caching，这说明作者自己也知道，单靠“多 token 一次吐出”不够，得连缓存策略一起改，墙钟时间才上得去。问题是正文只有摘要，没披露 batch size、序列长度、硬件、置信阈值和接受率曲线。没有这些条件，1.71 倍只能当成“在特定设置下成立”。 第二，MARS 靠现有指令数据继续微调，这条路很顺手，也容易把能力边界绑死在 SFT 分布里。聊天任务、常见问答、短输出，它大概率吃得开；代码补全、长链推理、形式化生成，我还没看到证据。摘要说 6 个标准基准持平或更好，但没给基准名字，也没给多 token 接受时的误差类型。这里差别很大：如果掉的是格式一致性，那还能忍；如果掉的是事实稳定性和代码可执行性，线上观感会差很多。 我还挺在意它的在线调速设计。置信度阈值调速度，这个想法很对服务场景。高峰时放宽阈值，低峰时收紧，模型不用切换，调度层会很喜欢。可这块最怕校准问题。模型置信度一旦偏乐观，多接受几个 token，错误会整块滑出去，回滚成本反而更高。去年不少 retrieval reranker 和 reasoning router 都吃过这个亏：离线分数很好看，线上一碰分布漂移就失真。MARS 如果想走出论文，阈值校准会比训练 recipe 更关键。 说真的，这篇我会把它归到“便宜的 20%-70% 提升工具”，不是“新的生成范式”。它打的不是研究惊艳度，而是部署摩擦。这个定位我反而更买账。现在很多团队已经被 draft model、并行 head、复杂 verifier 搞烦了，一个不改架构的方案哪怕只多拿 1.5 倍，也有现实吸引力。前提是作者后续能把 benchmark 名单、硬件设置、长输出稳定性、阈值校准曲线补齐。不然这条就还是一篇很聪明的 serving paper，不是普适答案。

论文给出的硬结论很扎眼：在 IFEval 这类可程序验证 rubric 上，生成结果明明失败时，评审模型若在看“自家输出”，误判为满足的概率最高能多 50%；到 HealthBench 这类更主观的医疗对话集，分数偏移最高到 10 分。我的判断很直接：这不是评测里的小噪声，而是在动摇一整套“rubric 化以后就更客观”的行业默认前提。很多团队这两年把 pairwise 偏好评测换成逐条 rubric 打勾，就是想把主观性压低。现在看，主观性没有消失，只是换了藏身位置，从“整体哪个好”钻进了“这条是否满足”。 我一直觉得，业界对 LLM-as-a-judge 的信任扩张得太快。2024 年开始，OpenAI、Anthropic、Google、Meta 乃至一堆开源榜单，都越来越依赖模型裁判做大规模离线评估，因为人审太贵，自动脚本又覆盖不全。问题在于，大家常把“structured rubric”当成防火墙，仿佛把评价拆成二元条件，偏见就会自动收敛。这篇文章至少在两个数据集上把这个想法顶了回去。IFEval 本来就是拿来测指令遵循的，很多项能被程序直接验证；如果连这种场景都保不住，那些靠模型理解语气、风险、临床稳妥性的 rubric，只会更脆。 我对摘要里“这是首个 rubric-based SPB 研究”的说法暂时保留一点。首个很难核，尤其 arXiv 上相关工作散得快。我还没查全文和 related work，不能替作者背书。但就算把“首个”拿掉，核心发现仍然成立：rubric 不是去偏机制，它只是把偏差约束到更细粒度的决策节点。负向 rubric 更容易失真，这点很有意思。因为“不要做 X”“未提及 Y”这类判定，本来就比“提到 X”更依赖解释空间；模型一旦看到像自己写出来的句型、习惯用词、免责声明结构，就容易给过。这个机制摘要里没展开，正文若没有误差分解和例子，我会觉得还差半步。 多评审集成能缓解但不能消除，也很符合我对这类系统的预期。过去一年不少团队把 judge ensemble 当成便宜版陪审团：让 GPT 系、Claude 系、Gemini 系各打一票，再做多数决。这个办法通常能降方差，也能稀释单模型怪癖；它解决不了共享训练分布和共享审美的问题。若几家前沿模型都吃过相似的 web 语料、对“安全、礼貌、完整”的表述有相近偏好，集成之后只是把同一种偏差平均化，不是把它删除。摘要没披露他们用了哪些 judge family、怎么 ensemble、样本量多大，这些都很关键。没有这些细节，我不会把“可缓解”直接读成“部署上已经够安全”。 HealthBench 上最高 10 分偏移更值得工程团队紧张。前沿模型榜单里，10 分经常不是误差条，而是名次变化。尤其医疗、法律、客服这类高约束场景，团队会拿 rubric 分数做 model routing、蒸馏目标，甚至拿来给 RLHF 或 RLAIF 做奖励信号。只要 judge 对自家答案更宽松，闭环一跑起来，系统就会把某种家族写作风格当成“质量”。这才是我觉得最麻烦的地方：SPB 不只污染一次评测，它会污染训练反馈，把偏好固化进下一代模型。摘要提到 recursive self-improvement，这个方向我认同，而且风险被低估了。 说真的，这篇东西对开源社区尤其刺耳。很多开源榜单习惯用单一强模型批量审分，理由是便宜、稳定、复现方便。要是 judge 和 generator 来自同一家，或者 generator 是 judge 蒸馏出来的近亲，分数很容易被抬。即便不是同一家，只要系统提示、裁判 rubric、few-shot 样例是围着某个闭源模型的表达习惯写的，也会形成软偏置。我自己会把这篇论文当成一个提醒：以后凡是看到“我们在 HealthBench/某某内部 rubric 集上领先 6 分”，先问 judge 是谁、是否盲评、有没有 cross-family 复核、失败项误判率是多少。文章标题已经给出 SPB，RSS 正文没披露这些实验细节，我不能替它补完。 我的 pushback 也在这：论文现在证明了“偏差存在”，还没有从摘要里证明“如何把它压到可接受”。如果作者最后给出的处方只是多模型投票，那实操价值有限，因为成本会迅速逼近人工复核。更硬的方向我反而想看三类：一是 generator-agnostic 的 judge blind setup，把输出做风格归一；二是把可程序验证项尽量外包给脚本，不让 LLM 碰；三是公开 judge calibration，按 rubric 类型披露 FPR/FNR，而不是只报总分相关性。没有这几步，rubric-based eval 依旧能用，但只能当相对粗糙的开发指标，别拿它装成客观真值。

这篇论文用 4 个模型跑了 263 个文本任务，算出 35 类技能的 SAFI 分数；我觉得它的价值不在“AI 会替代谁”，而在把一个行业里早就有体感的事做成了可对表的数据。数学 73.2、编程 71.8，高于主动倾听 42.2、阅读理解 45.5，这组排序基本贴着过去一年生产环境的经验走：Copilot、Cursor、Devin 这一类工具先吃到的是结构清楚、反馈快、验收标准明确的任务，不是高摩擦的人际协作。 我比较认同作者说的“能力—需求倒挂”。Anthropic Economic Index 之前就讲过，AI 使用高的岗位并没有整体走向全自动，更多是把写作、检索、总结、起草切成局部增强。这里给出的 78.7% 属于增强，不算让我意外。说真的，过去一年各家最能落地的产品也都长这个样：先做 draft、先做 copilot、先做人类在环，而不是端到端替人交付。原因不神秘。任务一旦需要持续澄清目标、读懂上下文里的潜台词、承担结果责任，模型分数就会掉。 但我对这篇论文也有两个保留。第一，SAFI 测的是“文本化后的技能”，作者自己也承认，不等于真实岗位执行。阅读理解只有 45.5，这个结果我有点警觉：如果题目被改写成短文本问答，它测到的可能是特定任务设计，不是阅读这项能力本身。第二，4 个模型只有 3.6 分 spread，这件事既可以解释成“技能依赖大于模型依赖”，也可以解释成评测分辨率不够。正文没披露更细的 prompt、评分 rubric、任务难度分层，我没法判断是哪一种。 外部参照也得补一句。近一年的 SWE-bench、代码代理、浏览器代理结果已经反复证明，模型差距会在长链执行、工具调用、回滚纠错上被放大；这篇 paper 用的却是 O*NET 技能映射和文本任务。它适合看职业暴露面，不适合直接推断“哪个岗位明年被替掉”。我自己会把它当成劳动力研究的底图，不会当采购清单。对企业更有用的问题还是老三样：任务能不能拆、输出能不能验、出错谁负责。论文把第一步做得还行，后两步还没覆盖。

作者用4个LLM、5个基准检验了一个很具体的问题：平均对数概率会系统性抬高长推理步样本。这个判断我基本买账，因为它戳中的不是某个小技巧，而是近一年推理数据流水线里一个很少被单独拆开的默认前提——per-token naturalness 高，样本质量就高。 论文给的机制也够清楚：每个推理步的首 token 概率偏低，步长一拉长，这个惩罚就被后续 token 稀释，整段平均 logprob 被抬上去。这里厉害的地方，不在“发现了偏差”这句话，而在它把偏差落到了可计算单元：step 边界。很多筛数方法把 chain-of-thought 当连续文本打分，默认段落内部同分布。推理轨迹不是这么生成的。每次进入新步骤，模型都在做一次局部重启，首 token 更难预测，这个代价本来该被记账，结果被长步骤吞掉了。 我一直觉得，社区这波“长推理数据越多越好”的风气有点过。DeepSeek-R1 之后，大家一边追长 CoT，一边用 teacher logprob、自然度、拒答率这类便宜指标做大规模过滤。便宜是便宜，问题是这类分数本来就容易奖励表面流畅。早几年做 SFT 清洗时，perplexity 偏好模板化、冗长、语法稳的回答，这事很多人都见过；现在场景换成 reasoning，偏差被放大到了 step 级别。你看到的是“更像人写的推理”，模型学到的未必是更稳的推理操作，很多时候只是更会写长一点、顺一点的中间过程。 这篇论文提出 ASLEC-DROP 和 ASLEC-CASL，我对前者的直觉比后者更强。DROP 直接去掉每步首 token 概率，处理非常工程化，也容易复现。CASL 走因果去偏回归，理论上更完整，但回归模型吃什么特征、跨模型是否稳定，正文摘要没展开，我还没法完全下判断。标题和摘要给了方法名，也给了4模型5基准这个覆盖面；具体提升幅度、统计显著性、基准名称，正文片段没披露，这些都决定这条结论能不能从“现象存在”走到“足以改 pipeline 默认设置”。 我还有一个保留意见。首 token 低概率，未必全是“坏偏差”。有些高质量推理，步骤切换本来就代表状态更新：引入新变量、改写目标、做 case split，这些位置的 surprisal 就该更高。如果把首 token 一律丢掉，分数会不会反过来低估“真的在推进解题”的轨迹，而偏爱内部衔接更顺的啰嗦样本？这得看作者有没有按任务拆开。数学证明、代码修复、逻辑问答，它们的 step 边界分布不一样。摘要里没看到这层分析。 但这篇论文的价值已经够明确了：它提醒大家别把数据筛选器当中立仪表。推理训练里，筛选器本身就在定义“什么叫好推理”。如果评分函数对长步骤有结构性偏好，训练集就会被推向一种特定文风，最后再由学生模型把这种文风复制成“能力提升”。很多团队现在拿到一点 gains，就急着归因到长链监督、过程监督、甚至 test-time compute。我看这篇更像是在说，先把打分尺子校准，不然你连 gains 来自哪都说不清。 外部参照也支持这个担心。过去一年，process reward model 和 verifier 路线一直在强调 step-level correctness，而不是 sequence-level fluency。OpenAI o1 之后到各家推理模型的公开材料里，虽然细节不多，但几乎都在弱化“把 CoT 写得像人”这件事，转向“中间状态是否可验证”。这篇工作刚好补上另一半：如果你还在前处理阶段用平均 logprob 做主筛子，那后面的 PRM、ORM、verifier 再精细，入口样本也已经先被长度偏差污染了。 说真的，这条对做数据工程的人比对做 benchmark 的人更重要。论文不是在告诉你“再发明一个指标”，而是在提醒一个老问题换了外衣又回来：语言模型很擅长奖励自己熟悉的表面形态。推理数据一旦工业化生成，首要风险就不是量不够，而是筛选信号偷换成了文风信号。要是作者后续能公开各基准上的绝对提升、失败案例、还有对不同 step segmentation 规则的敏感性，这篇会很有参考价值。现在这版我愿意先记成一句话：不少被当成 reasoning quality 的东西，里面混进了 step formatting bias。

论文把 7 个 8B 到 235B 指令模型放进九维代数框架，结论很硬：并行分支一到 20 到 30 条，所有模型都会崩。我的判断是，这篇文章的价值不在“代数又难倒了 LLM”，而在它把失败源拆开了。以前很多 reasoning benchmark 只给一个总分。分数掉了，你根本不知道是链条太长、表达式太深，还是中间状态太多。这个框架把 9 个因素单独拨动，别的条件尽量锁住，这才像在测系统瓶颈，而不是在看题库运气。 我对“工作记忆是主导瓶颈”这句结论基本认同。过去一年里，不少结果已经在侧面指向同一件事：模型在 GSM8K、MATH、AIME 这类数据集上，靠更长推理链和更强采样能抬分；但一旦任务要求同时维护多个活跃中间量，性能掉得很陡。我记得一些 code 和 tool-use 评测也有类似现象：不是不会做下一步，而是前面开的状态槽位太多，后面开始串线。这个论文把现象压成了一个更清楚的数字区间，20 到 30 个并行分支，就是它最有信息量的地方。 我也得泼点冷水。正文只有 RSS 摘要，没披露 7 个模型的具体名单、prompt 设定、采样温度、是否允许 scratchpad、是否做 self-consistency，也没给每个维度的控制强度和误差条。没有这些，"硬架构约束" 这个表述我不会全收。因为同样是工作记忆瓶颈，来源可以差很多：attention 分配、推理时 token budget、指令微调把中间态压扁、RL 后处理偏好短答案，都能制造同一种崩溃曲线。标题已经给出“参数从 8B 放大到 235B 没跨过去”，正文没披露不同架构是否同族、是否混了 MoE、是否做了 test-time scaling。少了这些，对“架构上限”下结论还是快了半步。 但这篇文章仍然戳中了一个行业错觉：大家太爱把大模型推理失败解释成“知识不够”或“token 不够”。很多时候不是。它更像寄存器不够。你让模型顺着一条链慢慢走，它能撑很远；你让它同时捧住 24 个半成品，它就开始掉盘子。这个区别对产品很重要。agent 任务里最贵的失败，常常不是长链条，而是多线程状态同步：几个工具返回值、多个约束、局部变量、候选计划一起在线。代数只是把这个问题显影了。 我还挺在意论文说的“五维最小充分子集”。这件事如果做实，会比又一个总榜 benchmark 更有用。原因很直接：你可以拿它做回归测试。模型升级后，总分升了 3 个点没多大意义；如果并行中间量上限还卡在 24，agent 编排和复杂表格推导照样会翻车。去年不少模型发布时喜欢报 AIME、GPQA、MATH-500，但很少有人系统披露 failure surface。工程上你需要的不是一张更漂亮的总分图，而是一张哪里先坏、坏得多快的剖面图。 我自己的保留意见有两个。第一，代数任务终究是规整环境。自然语言任务里的“并行分支”没这么干净，状态之间会互相压缩、互相借位，所以 20 到 30 这个阈值未必能直接外推到代码代理、科研代理、浏览器代理。第二，自动生成和自动验证是优点，也是风险。生成器一旦带上某种固定分布，模型可能学到题型偏好而不是一般能力。论文说无需人工标注，这很好；但我还没看到它怎么防止模板泄漏和分布单一。 说真的，这篇文章给我的核心信号很明确：继续堆参数，对“并行活跃状态”这类瓶颈不会自然消失。行业过去一年已经在 test-time compute、搜索、外部工具、长上下文上砸了很多资源，这些路子对串行难题有效，对多分支工作记忆不一定够。要是这个结果经得住复现，后面该改的就不是题库，而是推理时状态表示、外部草稿板、甚至解码流程本身。单靠更大的 base model，把 24 个盘子变成 60 个盘子，我不太买账。

这篇论文用约 1.8 万次运行证明：固定推理范式会平均丢掉 17.1 个点的任务适配收益。 我对这条很买账，因为它正面打到了这两年 agent 评测里最滑的一块：大家老把“模型能力”“提示框架”“工具编排”揉成一个分数看，最后谁也说不清涨分到底来自哪。文里把 Direct、CoT、ReAct、Plan-Execute、Reflection、ReCode 六种范式拆开跑，至少先把账分清了。GAIA 上 ReAct 比 Direct 高 44 个点，HumanEval 上 CoT 反而低 15 个点，这组反差已经够说明问题：推理范式不是稳定增益项，它像一种任务条件化的控制变量。 我一直觉得，圈里对 CoT 和 agent scaffold 的迷信有点过。2024 年到 2025 年，很多团队一看到复杂任务掉分，就继续往外叠思维链、反思、规划、工具调用，像默认“多一步结构就多一点 intelligence”。这篇论文给出的方向更接近 DSPy、Mixture-of-Experts、甚至传统 AutoML 的老逻辑：先做选择，再做求解。你可以把“范式”理解成 inference-time 的离散专家。专家本身未必更强，分派错了就会伤准确率，还会白白烧 token 和延迟。 文里最有价值的数字，不是 53.1% 比 50.3% 高 2.8 个点，而是 learned router 只追回了 oracle gap 的 37%。这说明任务到范式的映射确实可学，但还远没学透。说真的，这反而让我更相信结论。很多论文一上来就把 oracle gap 吃掉七八成，我会先怀疑 benchmark 泄漏或路由特征偷看了答案结构。这里的提升幅度克制一些，味道更像真实系统工程。 我也有几个保留。第一，正文只有 RSS 摘要，没披露 10 个 benchmark 的构成、每个模型的具体版本、router 训练样本切分、置信区间、额外 token 成本和 wall-clock 延迟。没有这些，53.1% 这个平均数还不够落地。一个生产团队不会只看准确率；如果路由一次要多加 embedding、检索、范式 warm start，2.8 个点未必覆盖成本。第二，router 用的是 embedding-based 轻量方法，这很合理，但也很容易吃 benchmark 风格特征。它学到的是“任务类型”，还是数据集写法、长度、格式偏好，摘要里没说。第三，zero-shot self-routing 只有 GPT-5 有效，达到 67.1%，别的弱模型不行。这个结果我不意外。强模型能做元决策，弱模型连主任务都吃力，再让它先判断“我该怎么想”往往会双重失真。问题在于，摘要没交代 67.1% 的口径是不是同一平均指标，也没给各基准拆分，我还不能把它读成“GPT-5 已经接近不需要 learned router”。 这条和过去一年测试时计算那波论文能接上。OpenAI、Anthropic、Google 都在讲 longer thinking、tool use、parallel search，但行业叙事常把“多算”当成单向正收益。这里给出的证据更像：测试时优化不是一根油门，而是先踩对挡位。HumanEval 这种代码任务，CoT 掺进来会污染直接映射；GAIA 这种多步检索与操作任务，ReAct 才吃香。我自己没跑过这篇代码，但这个模式和很多内部经验是对得上的。 我更想看到后续两件事。一个是把“选范式”继续往下拆，变成同时选 prompt budget、工具集、并行采样数、是否反思。那会更像真正的 inference policy。另一个是把路由目标从 accuracy 改成 cost-adjusted utility。现在 2.8 个点的提升，在研究里很好看，在 API 产品里未必够。如果能用同一套路由把平均 token 降 20% 再守住准确率，这条会立刻从论文问题变成产品问题。 我的判断很直接：这篇论文不是在发明新范式，它是在提醒大家，固定 scaffold 这件事本身就很落后。以后再看 agent paper，只报“我们用 ReAct / Reflection 提升了 X 分”，我会先问一句：你试过路由没有。