arXiv 每日速递 2026-05-25

今日总结

今天的论文池跟过去两天部分重叠（VPO / FAME / MOSS / DeltaBox 都已经在 05-23、05-24 写过），所以这期主动避开那些"大新闻"，挑了 4 篇被前两天忽略但很值得收藏的"工程精修类"论文。共同特征是：都不是新框架，而是把一条早就 work 的链条上的某个被低估的环节做精确改善——HarnessAPI 把 HTTP 端点和 MCP tool 合并成单一来源；NSR 把 RLVR 的硬剪裁改成边界随机化；Kairos 把预训练数据从 shuffle 改成时间有序；GPT-2 SAE Audit 把"可解释性"从因果叙事还原成一个跑在 M3 Max 笔记本上的相关性审计 pipeline。今天没有传世神作，但这 4 篇是那种真要做工程时会回头查的论文。

今日全览

论文	方向	核心贡献	与我们的相关度
HarnessAPI	cs.SE / MCP tooling	一份 typed skill folder 同时长出 HTTP+SSE 端点和 MCP tool，重复 boilerplate 削 74%	⭐⭐⭐
Understanding Data Temporality Impact on LLM Pre-training	continued pretraining	6B 模型对照实验：把 Common Crawl 按时间顺序训练 vs shuffled，发布 7000+ 时序问答 benchmark	⭐⭐⭐
Clipping Bottleneck (NSR)	RLVR post-training	GRPO/DAPO 的 hard clipping 会丢掉边界处的信息梯度；改成随机保留即可 plug-and-play 提升	⭐⭐
Sparse-Feature Audit of GPT-2 Small	small-model audit / methodology	一个 M3 Max 笔记本能跑完的 SAE audit pipeline，"相关 ≠ 因果"做了三层 control	⭐⭐

今日主题：四篇"被低估的小修小补"

如果说前两天的论文是大新闻——VPO 重写 GRPO、MOSS 改动 agent 源码、Erdős agent 解出未解问题——那今天这 4 篇属于另一类，它们都在做已 work pipeline 上的具体一行替换：

• HarnessAPI：把 @app.post(...) 和 @mcp.tool(...) 合并成一份 handler.py，不是 agent 新范式，是工程债清理；
• Kairos：预训练的 dataloader 把 shuffle=True 改成 shuffle=False 加时间排序，不是新架构，是数据 ordering 一个开关；
• NSR：GRPO 的硬剪裁改成边界随机化，不是新算法，是 clipping 函数里一行 if-else；
• SAE Audit：mechanistic interp 不再写"我们发现了一个 X 神经元控制 Y 行为"的因果故事，而是做 ablation + 表示基线 + seed robustness 三层 control，不是新发现，是审计协议。

这种风格特别适合做边际价值研究的人收藏：它们告诉你的是 ablation 应该怎么设计，而不是 ablation 该跑什么 baseline。

---

HarnessAPI: A Skill-First Framework for Unified Streaming APIs and MCP Tools

推荐理由：你正在维护 HomeCheck 这种"既要被 IDE 调用、又要被 agent 调用"的开源工具；这篇把 HTTP/SSE 端点和 MCP tool registration 合并到一份 source-of-truth 的做法直接对应到"DevEco Studio 集成 + MCP agent 调用"的双重需求

📌 论文信息：Edwin Jose | arXiv:2605.22733 | cs.AI, cs.SE

TL;DR

每个用 Python 写的"既可以被人调用、又可以被 LLM agent 调用"的 tool，今天都要维护 FastAPI 端点 + FastMCP registration 两套代码，长期下来 schema 漂移。HarnessAPI 用一份 typed skill folder（一个 handler.py + Pydantic schemas）同时长出 streaming HTTP endpoint、OpenAPI/Swagger UI 和零配置 MCP tool，重复样板代码削 74%。

问题是什么？

今天写一个 Python 函数想同时给 Cursor agent 和 CI pipeline 用，你得做两件事：

1. 在 FastAPI 里写 @app.post("/transcribe")，拿 Pydantic 校验输入；
2. 在 FastMCP 里再写一个 @mcp.tool() 装饰过的函数，再写一份 schema。

这两份代码共享业务逻辑，但周边机械（routing / validation / serialisation / streaming / schema 维护）完全分离，而且随着代码演化两边会漂移。问题不是"agent 调用比 HTTP 慢一点"或"MCP 限制太多"，而是非常朴素的工程债——两个调用入口，两份配置，两套 schema，没有 single source of truth。

更隐蔽的痛点：FastMCP 注册时基于函数闭包做反射，闭包内部丢失类型注解，导致 Pydantic 类型不能正确传递到 MCP 的 inspection 层。所以"我直接用同一个函数注册两次"这种朴素思路在框架层面就跑不通。

他们怎么做的？

核心 Insight：把"工具"建模成一个目录（typed skill folder），而不是一个函数。框架在加载时动态生成代码（dynamic code generation），把 Pydantic 类型注解显式重写到一个具名 wrapper 上，绕开 FastMCP 闭包反射的限制。

具体方法流程：

1. 统一抽象：每个 skill 一个目录，含 handler.py（业务逻辑） + Pydantic input/output schemas，框架视其为 single source of truth；
2. 代码生成：加载时把 handler 动态包装成具名函数，把 Pydantic 字段重写到 wrapper 签名上，让 FastMCP 的反射能拿到完整 schema；
3. 双模内容协商（Dual-mode content negotiation）：同一个 handler，根据请求的 Accept header 决定流式（SSE）还是一次返回（JSON），handler 代码零改动；
4. 继承 FastAPI：HarnessAPI 是 FastAPI 的子类，所以 middleware、依赖注入、部署生态全部继承。

跟之前方法的本质区别：以前的 MCP-FastAPI 桥接方案是"我在 FastAPI 上再加一个 MCP 转发层"——这是 wrapping。HarnessAPI 是反过来：以 skill 为根，再投射出 HTTP 端点和 MCP tool——是 source-of-truth 倒置。

关键结果

指标	手写双栈实现	HarnessAPI	削减
Framework-facing boilerplate（6 个典型 skill 用 cloc 量）	基准 100%	26%	-74%
HTTP endpoint	需独立维护	自动派生	—
MCP tool registration	需独立维护	自动派生	—
OpenAPI/Swagger UI	需独立维护	自动派生	—

结果解读：74% 不是"算力"或"准确率"的提升，而是人时的削减。这种数字对你判断 OpenHarmony 工具链的 MCP integration 路径很有意义——HomeCheck 如果要走"既有 CLI、又被 IDE 调用、又被 agent 调用"的三栈路线，HarnessAPI 的 source-of-truth 倒置模式比"再加一层桥"更可持续。

局限性与开放问题

• 局限 1：6 个 skill 是 cloc 样本，不是 production scale。74% 的削减在 ToyExample 类 skill 上特别显著；在已有大量 middleware / custom auth / batched-mode 的真实 production endpoint 上，省下的可能远没那么多；
• 局限 2：只解决 Python 生态。HarnessAPI 继承 FastAPI 走 Pydantic 路线；如果你的 skill 用 Rust / Go / TypeScript 写，这个方案不直接适用；
• 开放问题：source-of-truth 倒置之后，版本演化怎么管？比如 handler 改了 input schema，HTTP 客户端和 MCP 客户端的 breaking change 警告应该走同一份还是分别走？论文没讨论 versioning 问题，但这是任何 single source of truth 抽象都会撞上的墙。

💡 对我们的启发

1. 直接可用的技术点：HomeCheck 后续如果想接 Claude/Cursor 的 MCP，可以直接照着 HarnessAPI 的"skill folder = source of truth + dynamic code gen 把 Pydantic 重写到 wrapper"模式做，避免维护"CLI / IDE plugin / MCP tool"三栈。注意：DevEco Studio 集成的工具不是纯 Python，所以更可能是借鉴模式而不是直接用框架；
2. 具体实验想法：拿你已经发布的某个 ArkTS 静态检查规则，按 HarnessAPI 的范式做一个 minimal demo：一份 typed handler 同时长出 CLI + HTTP + MCP tool，量一下三栈写法下需要多少行 boilerplate、合并后能省多少。这是个 1-2 天就能跑出来的工程实验，结论可以直接放到 HomeCheck 的设计文档里；
3. 研究趋势判断：MCP 已经不再是"agent 框架里的一个 sub-protocol"，而是开始反向逼着传统 HTTP service 重构。未来 1-2 年，"如何让一个 service 同时为人和 agent 服务"会成为工程问题的主流，类似当年 REST → GraphQL 的 single-query 倒置。

---

Understanding Data Temporality Impact on Large Language Models Pre-training

推荐理由：你做 Cangjie continued pretraining 的时候，dataloader 的 ordering 是个被几乎所有人省略的设计变量；这篇直接做了 6B 模型的对照实验，结论值得作为你 ablation 的 baseline 参考

📌 论文信息：Pilchen Hippolyte 等 (Kyutai) | arXiv:2605.22769 | cs.CL, cs.AI

TL;DR

预训练默认 shuffle 整个语料，但这意味着模型对"什么时候发生的"无 grounding。这篇把 Common Crawl 按 snapshot 时间顺序排好再训，预训练一个 6B 模型，发现 sequential 训练在 general LU/common knowledge 上和 shuffled baseline 持平，但在时序敏感知识上系统性更强，更"时间准确"。同时发布 7000+ 时序问答 benchmark Kairos。

问题是什么？

LLM 预训练的标准做法是把全部语料 shuffle 一遍喂进去。这意味着 2020 年的新闻和 2024 年的新闻在 SGD 看来没有先后——模型最终的"时间常识"完全 ungrounded：

• 你问它"今天的总统是谁"，它给你一个所有训练数据时间窗口内总统的混合先验；
• 更糟的是，旧数据在语料中重复次数往往更多（因为后人引用、维基条目积累），所以 shuffled 模型反而对旧时间点更准。

这个问题之所以重要：continued pretraining 几乎总有一个隐含的时间方向——你的新语料一定比旧 base 模型的数据新，所以你需要知道"模型的时间敏感性"对 data ordering 是否敏感。但没人做过 6B 规模的 controlled experiment。

他们怎么做的？

核心 Insight：data ordering 不是 dataloader 的实现细节，而是一个会改变最终模型"时间表示"的训练超参。

具体方法流程：

1. Benchmark：构建 7000+ 时序问答（"在 X 时间，Y 是什么"），且明确区分时间窗口；
2. 对照实验：用 6B 模型，相同的数据、相同的 token budget、相同的超参，只改 dataloader——一组 shuffled（标准做法），一组按 Common Crawl snapshot 时间顺序；
3. 多维评估：除了 Kairos 时序问答，还跑 general language understanding + common knowledge 作为对照，证明 sequential 不是"以牺牲通用能力换时序准确"。

跟之前方法的本质区别：以前讨论 LLM 时间知识时，大家研究的是有了模型之后怎么 patch（continual learning / RAG / temporal calibration）；这篇是去问预训练阶段一个 dataloader switch 能不能从源头解决。

关键结果

评估维度	Shuffled baseline	Sequentially trained	差异
General language understanding	持平	持平	≈ 0
Common knowledge	持平	持平	≈ 0
时序问答（fresh facts）	较弱	更强	+
时序问答（old facts）	峰值在旧数据	较弱	shuffled 占优（因重复）

结果解读：两条 takeaway：

• Sequential 训练在通用能力上不付出代价，这是个无成本可换的改进；
• Sequential 的胜场集中在"新事实"，shuffled 反而在"旧事实"上更稳——这意味着取决于你的下游目标，data ordering 的方向不一定是单选。如果你只关心当前年份的事实，sequential 是免费午餐；如果你的目标是历史问答，shuffled 反而有利。

局限性与开放问题

• 局限 1：6B 不是 frontier scale。这个量级足够说明趋势，但 70B+ 上是不是依然 hold 是开放问题；尤其 sequential 会不会触发 catastrophic forgetting 在更大模型上没验证；
• 局限 2：Common Crawl 的 snapshot 时间≠语料内容时间。一篇 2024 年抓的网页可能在写 2010 年的事，所以"时间排序"是 noisy proxy；
• 开放问题：sequential 训练对 continued pretraining 是否依然成立？你拿一个 base 模型再喂 1B token 新数据，按时间顺序训 vs shuffle 的差异是不是依然这么明显？论文是 from-scratch 训练，对你做 Cangjie continued pretraining 的场景还不是直接证据。

💡 对我们的启发

1. 直接可用的技术点：你 Cangjie continued pretraining 的 ablation matrix 里，建议加一组 ordering 对比——把你的 Cangjie 语料按 commit/release 时间排序 vs shuffle，看 downstream 的"语言知识 freshness"是否有差异。这是一个几乎零边际成本的 ablation；
2. 具体实验想法：用一个小一些的 base 模型（1B-3B），在你已经收集的 Cangjie 语料上做 continued pretraining，对照 shuffled vs time-ordered，下游评估用一组"Cangjie 早期 API vs 后期 API"的代码补全题。预期：time-ordered 在后期 API 的补全准确率会比 shuffled 高（因为后期数据是 SGD 的"近因")。如果观察不到，反而说明 continued pretraining 对 ordering 不敏感——这本身就是一个值得写出来的负结果；
3. 研究趋势判断：dataloader 是过去 5 年被 ML 系统抽象掉的"小事"，但开始有论文回头把它视为研究对象。结合 Kyutai 发布 code/checkpoints/datasets 全套，这条线接下来会有更多 follow-up——你可以提前在 Cangjie/ArkTS 这种有强时间方向的小语种语料上抢一个 niche。

---

Clipping Bottleneck: Stabilizing RLVR via Stochastic Recovery of Near-Boundary Signals (NSR)

推荐理由：如果你在做"边际价值"量化研究，方法论上有一个有意思的对照——本文展示了"一行 if-else 改动如何带来稳定的 RLVR 提升"，可以作为你做 marginal value 实验设计的参考

📌 论文信息：Shuo Yang 等 | arXiv:2605.22703 | cs.LG

TL;DR

RLVR（Reinforcement Learning with Verifiable Rewards，GRPO/DAPO 这一族）是当下 LLM reasoning post-training 的主流，但训练不稳。本文系统拆解 GRPO 类目标，发现 hard clipping 把刚好超出边界的有用 token 信号丢掉了。NSR 是个 plug-and-play 改动：在边界处随机保留这些 token，从 7B 到 30B 模型、dense 和 MoE 都有稳定提升，且优于 baseline DAPO/GSPO。

问题是什么？

GRPO/DAPO 用 PPO-style clipping 来限制每步 policy update 的幅度——min(ratio · A, clip(ratio, 1±ε) · A)。但这个 clip 是 hard 的：ratio 一旦越过 1+ε，整个梯度直接被砍到 0。

问题在哪？

• 边界外一点点的 token 不是"坏 token"，只是 policy ratio 略大；
• 在 reasoning 任务里，那些 ratio 处于边界附近的 token 往往是 model 在尝试新策略时产生的——正是你最想保留的 exploration signal；
• hard clipping 把它们 100% 砍掉，导致 RLVR 训练对 ε 极度敏感、容易 collapse。

之前的修补思路（DAPO 的 dual-clip、GSPO 的 sequence-level clipping）都是调整 clip 的几何形状，但 hard 的本质没变。

他们怎么做的？

核心 Insight：边界附近的 token 不应该是"全保留 or 全丢"，应该是"以一定概率保留"，把硬决定改成软决定。

具体方法流程：

1. 诊断：作者先通过 ablation 显示 GRPO 类目标的不稳来自 hard clipping 而非 advantage estimator 本身；
2. NSR：在 clip 边界外一个 window 里，token 以某个概率被随机保留进入梯度计算（保留则进梯度，丢弃则像 hard clip 一样为 0）；
3. 理论解读：这个 stochastic perturbation 在期望意义下等价于隐式 gradient decay，但 ablation 证明它比显式 deterministic decay 更有效——说明 stochasticity 本身在帮训练，不只是 magnitude 上的修正；
4. plug-and-play：本质就是在 PPO loss 里的 clip 函数里加一个 if torch.rand() < p: keep else: clip，不改其他任何东西。

跟之前方法的本质区别：DAPO/GSPO 改的是该不该 clip（几何）；NSR 改的是clip 是不是 deterministic（随机性）。这是一个被忽视的设计维度。

关键结果

模型规模 / 架构	Baseline	+ NSR	备注
7B dense	DAPO 基线	稳定提升	训练稳定性显著改善
30B dense	GSPO 基线	稳定提升	同样规模 plug-in 受益
MoE	GSPO 基线	稳定提升	不依赖于 dense 假设

结果解读：论文 abstract 没给绝对数字，但定性结论清晰——跨 7B-30B、跨 dense/MoE 都稳定提升。从方法论角度看，这正是边际价值量化研究该有的样子：拎出一个被忽视的设计点（hard vs stochastic clipping），做覆盖多个 scale 的对照实验。

局限性与开放问题

• 局限 1：缺乏代码任务 benchmark。论文重点是 LLM reasoning RLVR；如果你想把 NSR 用到 code RLVR（pass@1 / pass@k 作 reward），它在 verifiable reward 是 sparse 0/1 的代码场景下是不是依然 hold，文中没直接证据；
• 局限 2：window 大小和保留概率是新超参。plug-and-play 听起来美好，但本质增加了两个 hyperparameter，对超参敏感性需要进一步研究；
• 开放问题：NSR 揭示了"边界附近 token 信息被丢失"是通用现象还是 PPO-clip 特有？比如 KL-penalty-based RL 不需要 clip，是不是就不会有这个 bottleneck？

💡 对我们的启发

1. 直接可用的技术点：如果你以后做 code RLVR（不太可能近期做，因为算力贵），可以直接试 NSR——它是一行代码改动，不增加任何模型 size 或训练时长。即使你不做 RL，这篇也提供了一个写论文的范式：拎出方法链里一个看似"已经定了"的设计点（clipping mode），证明它不是 free parameter；
2. 具体实验想法：把"边际价值"量化研究的 framing 套到 NSR 上做一个小实验：你不需要跑 30B 模型，复现 7B 上 PPO-clip 的曲线，加 NSR 后看 reward variance 的 decay 速度。这个实验在单卡 A100 上一天内可做；
3. 研究趋势判断：2026 年 RLVR 的研究正在从"换 reward / 换 advantage estimator"转向"调 RL 优化器细节"，NSR 是这条线的代表。这意味着 GRPO/DAPO 之后没有大改动，剩下的提升空间在边角；这对"判断 RLVR 是不是该投入"是个负面信号——天花板可能比想象的近。

---

Reading Task Failure Off the Activations: A Sparse-Feature Audit of GPT-2 Small on Indirect Object Identification

推荐理由：你做"agent 现象的事后分析"——而不是端到端重跑——这篇展示了一个完美的 audit 范式：拎出一个小现象，做相关性挖掘，再用因果消融 + 表示基线 + seed robustness 三层 control 推翻"我们发现了 X feature"的简单叙事

📌 论文信息：Mahdi Nasermoghadasi | arXiv:2605.22719 | cs.LG

TL;DR

GPT-2 small 在 Indirect Object Identification (IOI) 任务上 79.7% 准确率。作者用 sparse autoencoder feature audit 找到 146 个显著的 failure-correlated features，最显著的 feature 17,491（"cryptographic keys"标签）在 prompt 含 'the keys' 时 fail 率高达 93.3% vs 其他 7.5%。但因果消融发现：把这个 feature 设 0，accuracy 不恢复——它是相关，不是因果。论文真正的贡献不是这个 feature，而是 audit pipeline 本身。

问题是什么？

mechanistic interpretability 这两年最常见的话术是"我们找到了一个控制 X 行为的 Y 神经元"。但绝大多数论文只做相关性分析——用 SAE 找一个高激活的 feature，配一段语言学解释，写成论文。没人系统问：

• 这个 feature 是因还是果？
• SAE 找到的特征比直接在 residual stream 上做线性回归更有 predictive power 吗？
• 同一 audit 跑 5 个 seed，"Top feature"还是同一个吗？

如果这三个问题任何一个 fail，那"我们发现了 X 神经元"的故事就是 overclaim。

他们怎么做的？

核心 Insight：interpretability 论文需要的不是更花哨的可视化，而是一个标准化的 audit pipeline，自带 falsification controls。

具体方法流程：

1. 相关性挖掘：在 IOI 任务上跑 300 prompts，对 24,576 个 SAE features 做 success-vs-failure 的 Cohen's d 比较，Holm 校正后 146 个显著、105 个 d > 0.8；
2. Falsification control 1 — Causal Ablation：对 top feature 17,491 做 zero ablation。如果它真是 IOI 失败的"原因"，ablate 它应该恢复准确率。结果：6.7% → 4.4%，完全没恢复。证明是 correlate，不是 sufficient cause；
3. Falsification control 2 — Representation Baseline：直接在 768 维 residual stream 上跑 logistic regression，5-fold ROC AUC = 0.929，跟用 top-100 SAE features (0.927) 几乎一样。SAE basis 没有比直接做线性分类多任何 predictive power——它只是更易解读；
4. Falsification control 3 — Seed Robustness：5 个 seed 复现。行为现象（'the keys' 失败率高）每次都稳健，但 feature 17,491 只在 5 次里有 1 次成为 top；
5. 开源全部 artifact：代码、300 prompt corpus、300×24,576 activation matrix、ablation scripts、figures。整个 pipeline 在 M3 Max 笔记本能跑完。

跟之前方法的本质区别：以前的 SAE interpretability 论文是"找到一个 feature → 命名 → 讲故事"。这篇是"找到一个 feature → 跑三个 falsification 看故事还成立吗 → 把方法论本身作为贡献"。

关键结果

Falsification check	期望（如果是因果）	实际观测	结论
Zero ablation feature 17,491	accuracy 上升	6.7% → 4.4%	不是因果
SAE features vs residual stream baseline AUC	SAE 显著更高	0.927 vs 0.929	SAE 不增加 predictive power
Top-feature seed robustness (5 seeds)	同一 feature 持续 top	仅 1/5 seeds	命名特征不稳健
行为现象本身（'the keys' fail rate）	—	75-93.3% across seeds	现象稳健，feature 解释不稳健

结果解读：这个表的设计本身就是论文的最大贡献——任何 mechanistic interpretability 论文都应该被要求填这张表。GPT-2 SAE feature audit 在这里只是 case study，pipeline 才是 deliverable。

局限性与开放问题

• 局限 1：只在 GPT-2 small 上。pipeline 是否能 scale 到 70B 模型还未验证——大模型的 SAE 通常需要 GPU，"跑完笔记本"的故事就破了；
• 局限 2：只在 IOI 任务上。IOI 是 mechanistic interpretability 的标准 toy 任务，更复杂的 reasoning 任务下"correlate vs cause"的差距可能更大或更小；
• 开放问题：是否每个 mechanistic interpretability claim 都该被强制要求带 zero ablation control + representation baseline？如果是，那现有文献里有多大比例是 overclaim？这是个会得罪人的开放问题。

💡 对我们的启发

1. 直接可用的技术点：你做"公开 agent trace 的大规模事后分析"时，可以照搬这个 three-control framework——

   • Causal ablation：找到某个"看起来在导致 agent 失败的 trace pattern"后，用 pattern matching 把这些 trace 移除，看 success rate 是否回升；
   • Representation baseline：你的 pattern 分类器比一个朴素的 bag-of-tokens 分类器强多少？
   • Seed robustness：换一组 trace（不同时间窗、不同模型版本），同一个 pattern 还是 top correlate 吗？

   这是一个直接可写成 SE 论文方法论 section 的迁移；

2. 具体实验想法：拿你已经分析过的 SWE-bench trace 数据，挑一个你之前给出"X behavior 与 task failure 相关"的结论，用这三个 control 重新走一遍。如果三个都 pass，结论加强；如果有 fail 的，你就有了一个比正面结果更有意思的负结果叙事；

3. 研究趋势判断：mechanistic interpretability 圈最近开始"自省"——从找 feature 到 audit feature claim。SE 圈关于"agent 行为可解释性"也会经历同样的转折，早点把 audit framework 引入 SE 领域，可以占住方法论的高地。

---

方法对比

维度	HarnessAPI	Kairos (Temporality)	NSR	SAE Audit
改动位置	Web/MCP framework 层	dataloader 层	RL optimizer 层	analysis pipeline 层
改动量	框架级（new lib）	一行 sort	一行 if-else	一套 control protocol
适用对象	想统一 HTTP+MCP 工具的人	continued pretraining 研究者	RLVR 训练者	mechanistic interp 研究者
计算开销	几乎零（运行时）	同量级 token budget	同量级训练	笔记本可跑
主要局限	versioning 未解	continued pretraining 未验证	缺 code RLVR 验证	大模型 scalability 未验证
对林智灏研究主线的可迁移度	OpenHarmony 工具链直接相关	Cangjie continued pretraining 直接相关	远（RLVR 太贵）	agent trace 分析方法论直接相关