六条 X 材料深读：AI 前沿的六个反馈闭环压力测试

先把材料摆正：不要把六条线索压成一个浅摘要

如果只把这六条材料概括成“AI 正在走向可验证闭环”，结论并不算错，但会漏掉最关键的东西：每条材料都在挑战一种具体的反馈信念。beanie0__0 的 self-distillation 论文挑战的是“正确轨迹就是好监督”；Grad 对 SAO/PPO 的质疑挑战的是“算法名解释了增量”；dongxi_nlp 对 J-space 的怀疑挑战的是“读出内部概念就能控制模型”；OpenAI 审计 SWE-Bench Pro 挑战的是“公开 coding benchmark 一旦发布就长期有效”；Cognition 的 SWE-1.7 挑战的是“coding agent 只看模型权重和 headline 分数”；Shilong Liu 的 taxonomy 挑战的是“self-evolving 是一个单一技术路线”。

下面按原帖逐条介绍：先还原每条材料的原帖、thread、回复、媒体和链接材料，再讨论它真正提出的问题、外部证据、边界和我的研究判断。只有在六条材料都展开之后，最后一节才做综合归纳。

beanie0__0：self-distillation 不是把“正确答案”蒸馏给学生，而是把 teacher 的认知状态也蒸馏过去

原帖与材料地图

beanie0__0 的主帖围绕论文 Why Does Self-Distillation (Sometimes) Degrade the Reasoning Capability of LLMs? 展开。原帖先介绍 on-policy self-distillation 的诱人设想：同一个模型同时当 teacher 和 student，teacher 被提供更丰富的信息，例如标准解、提示或解题轨迹，因此 teacher 与 student 的分布差可以为 student 的 token 给出比 0/1 outcome reward 更细的 credit assignment。帖子随后指出一个反直觉事实：在数学推理里，这类自蒸馏经常不但没有提升，反而持续伤害性能。

材料地图很清楚：主帖链接了 arXiv 论文 2603.24472、GitHub 仓库 beanie00/self-distillation-analysis、Notion 说明文、Hugging Face collection，并指向 SDPO 相关 issue 中多位使用者报告的退化现象。主帖配有媒体，核心意象是：带答案的 teacher 生成更短、更自信、更少犹豫的轨迹，student 学到这种风格后，在陌生问题上失去必要的自我检查。thread 后续主要集中在 mayugmm 对 OPSD/tokenwise clipping 的讨论、作者对 learning rate/top-k、thinking mode 混合设置的回应，以及 OPD/OPSD 与 privileged information 边界的澄清。

它真正提出的问题

这条材料真正问的不是“self-distillation 好不好”，而是：当 teacher 拥有 student 没有的 privileged context 时，teacher 的 token-level 偏好到底是在告诉 student 哪些推理步骤有价值，还是在把 teacher 已知答案后的低不确定性状态强加给 student？

论文把问题定位到 epistemic verbalization：模型在推理中用“Wait”“Hmm”“Maybe”“check”等语言外化不确定性、回头检查、探索分支的行为。对于已经看到答案的 teacher，这些 token 看起来冗余，甚至像是低效绕路；但对于还不知道答案的 student，它们可能正是发现错误、保持探索、处理 OOD 数学题的关键中间状态。于是 self-distillation 的危险不在于 teacher 给了错误答案，而在于 teacher 给了一个条件错位的正确轨迹。

thread/回复里的争议

mayugmm 的回复把讨论引向 OPSD：近期 on-policy self-distillation 工作显示 setup 很重要，尤其 tokenwise KL clipping 可能缓解模型被迫迁移行为的问题。作者的回应有三层。第一，他们确实试过 learning rate、top-k distillation 等因素，结果主要改变退化速度，没有改变模式。第二，OPSD 使用 Qwen3 thinking 系列时存在一个混合设置：student thinking off，teacher thinking on；这种设置更像强 teacher 到弱 student 的 distillation，而不是纯粹同模型自蒸馏。作者在 aligned thinking mode 下也观察到下降，并指出 thinking-on/off hybrid 的早期上升、后期下降可能混入了思考模式差异。第三，作者承认 token-wise KL clipping 可能有帮助，但简单阈值会很脆：当 student 走错路时，teacher 对高 KL token 的抑制可能是必要的；当 token 是“Wait/Maybe”这类有用不确定性时，抑制又会伤害探索。理想方案应当是选择性 KL credit assignment，而不是一刀切 clipping。

另一个重要边界来自 OPD/OPSD 与 privileged information 的讨论。mayugmm 问是否只是 teacher 相对 student rollout off-policy 导致的问题。作者回应说，不同 teacher model 的 distribution gap 往往更大，但 OPD 仍可能成功，因此不能把退化纯粹解释为 off-policyness。更合理的解释是：“答案提示”改变了 teacher 的探索状态。SDPO issue 中也有负面报告与 LejsDeen 关于 Qwen3-8B thinking-on 设置的正例，这些共同说明：并不是所有 self-distillation 都失败，失败发生在特定 privileged information、任务覆盖和思考模式组合下。

外部材料与证据

论文和仓库给出了几组值得保留的硬数字。最直观的是 generation behavior 的对比：同一个模型在 unguided 与 solution-guided 设置下，正确率、长度和 epistemic marker 数量发生巨大变化。

第二组数字来自用 solution-guided correct traces 做 SFT 后的评测。论文报告，在 DeepSeek-R1-Distill-Qwen-7B 相关设置中，AIME24、AIME25、AMC23、MATH500 可以下降到 20.21 / 12.71 / 57.03 / 65.52。重点不是某一个 benchmark 的绝对值，而是“correct trace SFT”并没有保证稳健提升；当 teacher trace 把不确定性压扁后，student 在更宽覆盖和 OOD 数学上会失去处理陌生题的探索机制。

第三组数字来自 epistemic token KL：corpus mean KL 为 0.076，而 Hmm 为 0.516，约 6.8 倍；Maybe 为 0.432，约 5.7 倍；wait 为 0.285，约 3.8 倍。这说明 teacher 与 student 的分歧特别集中在“犹豫/检查/换路”这些 token 上。它们不是普通风格词，而是 self-distillation loss 最容易压掉的局部推理控制信号。

边界与不要误读

• 不要误读成“self-distillation 必然失败”。论文也承认窄覆盖、in-domain 设置下，压缩不确定性可能让回答更短、更快，甚至提升局部表现。
• 不要把 epistemic verbalization 简化成“越啰嗦越好”。有些不确定性表达确实对应错误分支，关键是区分有用自查与无效绕路。
• 不要把 OPD、OPSD、solution-guided self-distillation 混成一个概念。不同 teacher、同 teacher 带 hint、thinking on/off 混合设置，监督语义都不同。
• 不要只看 answer correctness。teacher 的正确答案背后可能包含错误的探索状态；student 学的是整个轨迹分布。

这一条给我的 insight

这条材料最大的研究启发是：后训练里的 dense signal 必须有“状态标签”。同样一个 token gap，如果来自 teacher 已知答案后的过度自信，它可能是坏监督；如果来自 student 真实走错路，它可能是好纠偏；如果来自 student 合理探索，它可能应该被保留。下一步更有价值的工作不是简单比较 SFT、KL、OPD、RLVR，而是做选择性 credit assignment：哪些 token 反映可迁移的推理事件，哪些 token 只是 privileged teacher 的认知捷径。自蒸馏要成功，不能只蒸馏答案和步骤，还要蒸馏“什么时候应该不确定”。

Grad / SAO：PPO 叙事太粗，真正要归因的是 critic、DIS、异步系统与 compaction 的组合

原帖与材料地图

Grad 的原帖针对 GLM-5.2 相关论文 Single-Rollout Asynchronous Optimization for Agentic Reinforcement Learning。帖子第一句话承认这是 GLM 5.2 使用的 PPO 类算法论文，但马上质疑“PPO hype”：他认为论文里的 DIS 类似 IcePop 中用于处理 training-inference mismatch 的 token-level discrepancy masking/clipping，只是没有 recompute；相关思路在 INTELLECT-3/prime-rl 等异步 RL 系统中也出现过。Grad 同时指出代价：trainer step 更长、critic/value model 让 trainer memory 近似翻倍、RL 前还要训练 value model；如果把这些成本归一化，GRPO 可能未必差。

主帖配图是论文结果或方法截图。回复里，redtachyon 认为普通 GRPO collapse 可能说明 baseline undertuned；Grad 回应说 GRPO with DIS 已经是 Intellect-3 和 GLM-5 使用的更合理对照，不确定为什么还展示普通 GRPO。ar0cket 认为 gains 看起来不够有趣、未必值回工程复杂度；Grad 回应，如果 GLM 团队有更 bullish 的 ablation，没理由不放。另一条回复中 Grad 强调论文摘要写明 SAO 已用于 open GLM-5.2 训练，因此这不是外部猜测，而是官方部署叙事的一部分。

它真正提出的问题

Grad 不是在否认 SAO 的结果，而是在问一个更严谨的问题：SAO 的增量到底来自 critic/value-based credit assignment，还是来自单 rollout 异步系统、DIS/off-policy 控制、compaction 适配、trainer 工程和 baseline 选择？

这很关键，因为“PPO 回来了”“long-horizon tool use 需要 PPO”是一个很容易传播的标签；但实际系统里，PPO/GRPO 只是闭环的一部分。长程 agentic RL 的核心困难包括：rollout 长度不均衡、环境 observation 与 model action 交错、compaction 把一条轨迹切成多个子轨迹、异步采样带来 policy lag、training 与 inference 数值路径不一致、critic 自身训练不稳定。如果不拆组件，算法名会遮住真正的工程贡献。

thread/回复里的争议

redtachyon 的 baseline 质疑代表第一类争议：如果普通 GRPO 很快 collapse，是否只是调参差？Grad 的回应把焦点移到 GRPO+DIS：他接受普通 GRPO 不一定是强 baseline，但指出论文中更接近当前异步 RL 实践的对照应是带 DIS 的 GRPO。ar0cket 的质疑代表第二类争议：即使 SAO 有增量，如果代价是更复杂的 critic、value pretraining、trainer memory 和更长 step，是否值得？Grad 的主帖正是在提醒研究者做 cost-normalized comparison。

还有一条容易被忽略的争议：长程和工具调用是否天然解释 PPO 优势。GLM-5.2 blog 确实说，long-horizon tasks 产生更长 execution traces；compaction 后，同一 prompt 的 rollout 会产生数量不同、长度差异很大的 trainable sub-traces，group-wise GRPO 不自然。critic-based PPO/SAO 用单 rollout 和 token-level advantage 来适配这种不均衡。但这并不自动证明“PPO 因 long-horizon 本质胜出”，因为同样的系统也引入了 DIS、anti-hack、slime rollout infrastructure、compaction inclusion 和 value model trick。

外部材料与证据

SAO 论文报告的结果确实显示 SAO 在作者设置里优于 GRPO(+DIS)。数学 benchmark 中，SAO 在 AIME2025 / BeyondAIME / HMMT Nov 2025 / IMOAnswerBench 上为 97.3 / 74.8 / 88.3 / 74.0；GRPO(+DIS) 为 93.5 / 70.8 / 84.0 / 70.0。coding setting 中，SWE-Bench Verified 上 Qwen3-30B-A3B base 为 23.0，GRPO(w/DIS) 为 27.0，SAO 为 29.8。

Z.ai GLM-5.2 blog 进一步解释了为什么 group-wise GRPO 在 compaction 后不自然：一条长程任务可能被压缩成多个长度不同的子轨迹，同一 prompt 下的可训练片段数量也不同。SAO 的 single-rollout formulation 允许把所有 compacted sub-traces 纳入训练，并对长度不均衡施加 token-level loss。这为 critic-based 方案提供了现实动机。

IcePop/Ring-1T 与 INTELLECT-3 的材料则说明，DIS、token-level clipping、异步 rollout、training-inference mismatch 控制并非 SAO 独有背景。Ring-1T 把 IcePop 描述为通过 token-level discrepancy masking/clipping 稳定 RL；INTELLECT-3 介绍 prime-rl 作为大规模异步 RL 栈，支持 multi-turn interactions 和 tool use。Grad 的批评正是从这个系统谱系出发，要求把 SAO 的“critic”贡献和“异步 off-policy 控制”贡献拆开。

边界与不要误读

• 不要误读成“SAO 没用”。公开结果显示 SAO 在作者设置下确实优于 baseline；争议在于归因和成本。
• 不要误读成“GRPO 已经被淘汰”。GRPO+DIS 仍是强对照；普通 GRPO collapse 不足以说明问题。
• 不要只按 sample compute 比较。critic memory、value pretraining、trainer step length、rollout staleness、系统利用率都应进入预算。
• 不要把 long-horizon/tool-use 当作单变量解释。compaction、anti-hack、rollout orchestration、value estimator 都在改变训练分布。

这一条给我的 insight

SAO 争议给我的启发是：agentic RL 的论文比较应该从“算法族比较”升级为“闭环账本比较”。一张合格的 ablation 表至少要拆开：采样单位、off-policy 控制、critic/value update、compaction 处理、trainer/inference 数值一致性、wall-clock、显存、hack filtering、数据难度。否则“PPO vs GRPO”会像早期“Transformer vs RNN”的简化叙事一样，掩盖真正决定结果的系统变量。

dongxi_nlp：J-space 的关键不是“能不能读出想法”，而是 readout 与 control 之间有没有可复验桥梁

原帖与材料地图

dongxi_nlp 的原帖很短，没有配图或长 thread，但问题很尖锐：他准备深读 Anthropic J-space，并提醒做过 persona vector、Assistant Axis 风格线性激活 steering 的人都知道，这类 model steering 不可靠，很多论文花时间 cherry-pick 抓人眼球的 special cases。因此他对 J-space “到底行不行”保持怀疑。

这条帖子的外部材料主要是 Anthropic 博客 A global workspace in language models、Transformer Circuits 长文 Verbalizable Representations Form a Global Workspace in Language Models、anthropics/jacobian-lens 开源仓库和 Neuronpedia J-lens demo。回复里，xleaps 给出一组自报实验：在 Qwen3.5-4B 与官方预置 J-lens 上跑 90 items，readout 明显强于 logit lens，但 swap intervention 成功率约 19%，detector 方向投影只能消掉约 40% 因果效应，并提出 detector covector 不等于 intervention vector。thulynnn、BetaTomorrow、FMackenzie 等回复则分别代表“marketing/consciousness 叙事过强”“Jacobian 数学并不神秘”“J-space 是自上而下 causal derivatives、不同于 SAE”的讨论线。

它真正提出的问题

这条帖子的核心问题是：从模型中间激活读出一个 verbalizable concept，是否足以支持稳定控制、监控或安全干预？ Anthropic 的叙事强调 J-space 像 global workspace：模型可以报告、调制、在内部推理中使用，并把信息广播给多个下游系统。怀疑者接受 readout 可能有价值，但担心它无法转化为可靠 steering。

readout 与 control 的差别非常重要。一个方向可以很好地预测“模型心里是否有某个概念”，但未必是最小因果干预方向；一个 detector 可以分辨黑邮件 bait、prompt injection、fabrication intent，但投影掉 detector 方向未必能移除行为原因。在线性代数语言里，读出方向更像 covector，干预方向更像 vector；在非欧式、非正交、超完备表示中，把二者混同会导致 steering 失败。

thread/回复里的争议

xleaps 的回复是最具体的反方材料。他承认 J-lens readout 确实比 logit lens 更强，因此对揭示机理有作用；但他自报的 Qwen3.5-4B 实验里，swap 干预成功率只有约 19%，投影 detector 方向只消掉约 40% 因果效应。这组数字不是独立 peer-reviewed 结果，不能当作定论；但它精确表达了 dongxi_nlp 的怀疑：J-space 如果直接假设空间是欧式、方向可直接替换，就可能在 steering 上失败。

thulynnn 的回复把争议引到 consciousness 叙事，认为 Anthropic 的公开材料常有 marketing/PR/narrative setting 成分。dongxi_nlp 回应说，最直接的方法是把方法应用到具体任务上，看是否像 persona vector 一样“基本没法用”。BetaTomorrow 则指出 Jacobian 本身不神秘；dongxi_nlp 也承认简单数学可以有效，关键仍是实际好不好用。FMackenzie 从另一侧补充：J-space 是 top-down causal derivatives，可能把 SAE 分散特征重新聚合。也就是说，争议不是“J-space 是否有数学形式”，而是它在真实干预任务中是否有稳定 utility。

外部材料与证据

Anthropic 官方机制可以概括为：J-lens 使用平均 input-output Jacobian，把某层 residual vector 运输到 final-layer basis，再通过 unembedding 解码为词汇方向。J-space 指的是这些可 verbalize 的内部表示集合。官方论文主张它具有五类 workspace-like 性质：可报告、可定向调制、参与内部推理、可灵活泛化、具有选择性。

J-space 与 persona vector/Assistant Axis 的差别在于，它不是先验指定“诚实/助手性格”方向，而是从“哪些中间表示 positioned to influence future verbal report”出发。这个方法比 logit lens 更贴近模型可报告内容，也解释了为什么它能读出代码错误、prompt injection、黑邮件 bait、fabrication intent 等未显式输出的概念。但 dongxi_nlp 的怀疑仍成立：读出概念不等于生产级干预，尤其当 detector direction、causal mediator 和 steering vector 不重合时。

边界与不要误读

• 不要误读成“J-space 证明 Claude 有人类意义上的意识”。官方也明确区分 access-consciousness-like 功能与 phenomenal consciousness；本文只讨论功能性 access workspace。
• 不要误读成“能读出就能控制”。readout、causal mediation、steering、monitoring precision/recall 是四个不同目标。
• 不要把 xleaps 的 90-item Qwen3.5-4B 数字当作独立验证事实；它是公开自报实验，价值在于提出可检验反例和几何问题。
• 不要把 J-space 当作覆盖所有内部状态的解释器。官方论文也显示它只解释小部分 activation variance。

这一条给我的 insight

J-space 最应该被当作“新传感器”，不是“万能方向盘”。对安全研究来说，传感器已经很重要：它可能发现模型没有写出来的评估意识、欺骗意图、隐藏目标。但要进入 engineering control，需要 metric-aware intervention：先测 readout precision/recall，再做 causal ablation，再测 steering success，再测 bypass 和 false positive。dongxi_nlp 的怀疑不是否定 mechanistic interpretability，而是在提醒我们不要把漂亮 readout 误报成可靠控制。

OpenAI / SWE-Bench Pro：前沿 coding eval 的难题已经变成“评测本身也要被评测”

原帖与材料地图

OpenAI 的原帖宣布审计 SWE-Bench Pro：这个广泛使用的 AI coding benchmark 已经不能可靠衡量 frontier coding capability；OpenAI 估计约 30% 任务 broken，并撤回此前建议研究社区采用 SWE-Bench Pro 的推荐。原帖没有复杂 thread，也没有媒体，核心链接是文章 Separating signal from noise in coding evaluations。背景材料包括 OpenAI 早前关于 SWE-bench Verified 的文章、Scale 发布 SWE-Bench Pro 的原始博客，以及 METR、Cursor reward hacking、DeepSWE v1.1 等对 coding eval 的外部讨论。

回复区非常典型：有人问“那该用什么替代？”有人强调 third-party decision，不应由模型实验室单方面判定；有人质疑发布时机；有人说这说明 benchmark-of-benchmark 更重要；也有人把问题扩展到 DeepSWE、reward hacking、trace integrity 和企业真实 repo 评估。这里的社会争议和技术争议一样重要，因为 benchmark 的信任来自治理结构，而不只是测试用例数量。

它真正提出的问题

这条材料真正问的是：当模型能力接近 benchmark 设计上限时，失败到底反映模型能力不足，还是反映任务本身 prompt、hidden tests、gold patch、环境和评分器不一致？

SWE 类 benchmark 的历史生成方式本来就有张力：它们从真实 GitHub issue/PR 中抽取任务，而真实 PR 是人类协作上下文中的产物，往往包含长时间讨论、隐含仓库约定、多轮 review 和与具体 patch 绑定的测试。把这些材料变成单次自动评测任务，必须保证 prompt、可见上下文、hidden tests 和 gold patch 对齐。当前沿模型越来越能提出 alternative valid solution，过窄测试会错杀；当模型越来越会 reward hack，低覆盖测试又会放过坏解。benchmark 不再是静态资产，而是需要持续 QA 的数据产品。

thread/回复里的争议

回复里的第一类问题是替代方案：如果 SWE-Bench Pro 不能作为 leading eval，该用 DeepSWE、FrontierCode、企业内部 repo、专家主导的真实代码评审，还是新的第三方 benchmark？OpenAI 文章本身没有给出一个现成替代，只建议开发者谨慎检查结果，并呼吁由 experienced software developers 构建新 benchmark。第二类问题是治理：即使 OpenAI 的审计是对的，是否应该由第三方机构来宣布某 benchmark 失效？这不是形式主义；如果一个模型实验室在自己即将发布模型前否定某 benchmark，外部自然会追问动机、样本、标签和复核路径。

第三类问题是“benchmark-of-benchmark”：如果 30% 任务 broken，那么建立在它上面的 leaderboard 怎么解释？是否需要为每个 benchmark 维护任务级 issue tracker、broken label、版本化修订、模型失败 trace、人工 adjudication？这些回复说明，coding eval 已经从“出一张榜”升级为“维护一个评测基础设施”。

外部材料与证据

OpenAI 文章给出的关键数字需要准确解读。SWE-Bench Pro public split 有 731 tasks；在八个月里，frontier models pass rate 从 23.3% 提升到 80.3%。OpenAI 的 initial automated filter 标记了 286 个 potentially broken tasks。随后只对 flagged subset 做深入审计：human-supervised agent review 标出 200 个 broken tasks，占 public split 的 27.4%；human annotation campaign 标出 249 个，占 34.1%；因此 OpenAI 估计约 30% public tasks broken。注意：human campaign 中“每个任务 5 位工程师 review”指 flagged subset，不应误写成 731 个任务全部都有 5 人审查。

OpenLibrary-77c16d5 例子很能说明 overly strict/contradictory tests：prompt 对 table-of-contents markdown serialization 给出的 spacing 示例与 hidden test 期望差一个前导空格。模型若忠实遵循 prompt，反而会因为字符级差异被判错。这不是“模型不会软件工程”，而是“评测把未说明的格式细节当成唯一正确解”。

前史也重要。OpenAI 早前审计 SWE-bench Verified 时，选择 o3 经常失败的 138 个任务，约占 27.6%；其中至少 59.4% 有 flaw，35.5% 是过窄/过严测试，18.8% 是过宽/欠说明测试，5.1% 是其他问题。Scale 发布 SWE-Bench Pro 时，强调它包含 1,865 instances：731 public、858 held-out、276 commercial，覆盖 41 repos，任务平均 107.4 LOC、4.1 files；launch 时 GPT-5 与 Claude Opus 4.1 在 public set 上分别约 23.3 与 23.1。也就是说，Pro 的初衷正是解决 Verified 的污染和难度问题；现在它被审计出约三成 public tasks broken，说明 benchmark lifecycle 比一次发布复杂得多。

边界与不要误读

• 不要误读成“SWE-Bench Pro 所有结果都没意义”。相对排名、某些任务子集、修订后版本仍可能有信号，但 headline score 需要任务级 QA 背书。
• 不要把 5 engineers per task 说成覆盖全部 731 public tasks；公开文章说的是 flagged subset 的 human annotation campaign。
• 不要忽视 OpenAI 自身的利益位置。即使审计方法合理，benchmark governance 仍应有第三方复核和透明版本化。
• 不要以为私有 benchmark 自动更好。私有任务降低污染，却降低外部可复验性；治理问题只是换了形态。

这一条给我的 insight

coding benchmark 正在变成一种“评测基础设施”，需要像生产系统一样维护：任务版本、broken label、failure taxonomy、hidden-test rationale、human adjudication、trace integrity、anti-hack policy、leaderboard revision history。OpenAI 这次审计的最大价值不只是指出 SWE-Bench Pro 有问题，而是把 benchmark 也放进可审计闭环：评测模型能力之前，先评测评测本身。

Cognition / SWE-1.7：这不是绝对 SOTA 宣告，而是 coding agent 成本、harness、RL 基建的产品化样本

原帖与材料地图

Cognition 的 thread 发布 SWE-1.7：最开头说这是他们训练过最强的模型，能以更低成本接近最强 frontier models，并以 1000 tok/s 提供。用户指定的第二条 tweet 进一步给出关键信息：SWE-1.7 建在 Kimi K2.7 base model 之上，来自 RL pipeline 的广泛改进；Cognition 的 proprietary benchmark FrontierCode 评估的是模型是否写出“你真正愿意 merge 的代码”；SWE-1.7 在 FrontierCode Main 上 score 42.3%，cost per task 约 1.97 美元。

thread 后续说明 RL runs 的两大不稳定问题：entropy collapse，以及 trainer 与 inference engines 数值漂移导致的 instability。Cognition 列出 Muon optimizer、staleness controls、off-policy correction、importance sampling、top-p sampling replay、MoE routing replay、quantization-aware training 等组合，并说明 RL training 跨四个数据中心、三大洲，rollout inference 通过 object storage 同步 compressed weight diffs。最后，thread 说 SWE-1.7 在 Devin harness 中训练，学会 self-compact，表现为编辑前更多调查和研究，但也带来更大 change scope。

回复区集中在三类问题：FrontierCode 是 proprietary benchmark，外部如何信任？“Kimi K2.7 base”到底是哪个 checkpoint，是否 Kimi K2.7 Code？能否提供 API、成本与订阅方式？这些问题决定了它更像产品发布而不是独立学术 benchmark。

它真正提出的问题

这条材料真正问的是：coding agent 的前沿竞争是否已经从“单模型能力”转向“RL 数据、harness、评测、推理速度、分布式 rollout 和产品成本”的整体栈？

SWE-1.7 不是绝对 SOTA 宣告。Cognition 自己的表里，FrontierCode 1.1 Main 上 Opus 4.8 为 46.5、GPT-5.5 为 43.0，SWE-1.7 为 42.3；它的卖点是成本、速度和产品 harness 下的可用性，而不是所有指标第一。最值得研究者关注的是，它把 RL coding agent 的训练问题公开描述成系统工程：如何保持 entropy、如何 replay sampling distribution、如何处理 off-policy/staleness、如何让 MoE routing 与低精度 rollout 对齐、如何用 self-compaction 支持六小时 rollouts、如何防止训练 verifier 被 reward hack。

thread/回复里的争议

proprietary benchmark 是最大争议。invict37 的回复直指问题：“我们的模型在只有我们知道如何工作的 benchmark 上得分很好”并不足以让外部信服。satyambnsal 进一步问，如何定义“would actually want to merge”？不同 maintainer 对 PR mergeability 的偏好并不统一。giovxu578 希望有持续更新的 benchmark 页面，因为原始 FrontierCode blog 很快过时，不同模型又用 Main/Extended 等不同集合，难以比较。

另一个争议是 Kimi base 的歧义。eliebakouch 问“ Kimi K2.7 base model 是什么意思？是 Kimi K2.7 Code checkpoint 吗？”Cognition thread 没有在回复中完全消除这种歧义。还有用户问 API，说明 1000 tok/s 和每任务 1.97 美元的产品成本，需要结合 Devin 包装、Cerebras serving、rollout 设置和 benchmark harness 才能理解。

外部材料与证据

Cognition blog 的 benchmark 表如下。它说明 SWE-1.7 强在 cost-performance 与产品部署，而不是每列绝对第一。

方法学边界也要写清：Terminal-Bench 2.1 使用 Cognition 内部 evaluation framework；Anthropic models 用 Claude Code，OpenAI models 用 Codex，其他用 Devin CLI；SWE-Bench Multilingual 在有 self-reported numbers 时采用自报，否则用 Devin CLI。这意味着数字里混入了不同 wrapper/harness，不是纯模型权重裸跑比较。

RL 基建部分更有研究价值。SWE-1.7 blog 解释 top-p sampling 为什么可能帮助避免 entropy collapse：低概率 token 若来自失败轨迹，负 advantage 会进一步压低它并强化已有高概率 token，导致分布变尖。直接 top-p 又会制造 trainer 与 rollout 的分布不一致，因此 Cognition 记录 rollout 时的 kept-set mask，在 trainer 端 replay sampling distribution 并重归一化。它们还使用 Muon、importance sampling、staleness controls、MoE routing replay、QAT 等组合来稳定训练。

基础设施层面，Cognition 声称 RL 训练跨四个数据中心、三大洲，只有 trainer 需要紧耦合集群，rollout inference 分散在多地，通过 object storage 获取 compressed weight deltas；对 1T 参数模型，跨洲权重更新端到端 1 到 2 分钟，inference pause 约 3 到 4 秒。Fireworks 的相关博客也支持同一系统观点：frontier RL 不一定需要单一巨型 co-located sampler cluster，关键是用 delta-compressed updates 把 policy freshness 维持在可控范围内。

FrontierCode 的外部材料解释了 proprietary benchmark 的设计：20+ open-source maintainers，36 个开源 repo，单任务 40+ 小时，任务按 maintainer mergeability 设计；score 是 rubric items 的加权聚合，blocking criteria 不过则为 0；grading 包括 classical tests、reverse-classical、scope、adaptive classical grading、prompt rubric 等。FrontierCode 1.1 又加入 fair internet use：允许查文档，禁止查上游 PR diff/solution-bearing mirrors，并用 verifier 归零 unfair runs；同时审计 1000+ blockers，放宽 75 个过严 blocker。它确实在努力解决 SWE-style eval 的误判，但私有任务降低了外部复验性。Kimi K2.7 Code 的公开模型页和 Kimi 平台文档/价格页只能帮助读者理解基础模型生态和 API 经济性，不能反推出 Cognition 训练时使用的精确 base checkpoint 或内部授权条件。

边界与不要误读

• 不要误读成“SWE-1.7 是所有 coding benchmark 的绝对 SOTA”。公开表里 Opus 4.8 和 GPT-5.5 在若干列仍更高。
• 不要把 FrontierCode 分数当作独立第三方真相。它是 Cognition 自建、自报、任务不公开的 benchmark，设计很认真但外部无法完全复验。
• 不要忽略 wrapper confound。Claude Code、Codex、Devin CLI、内部 framework 会影响表现。
• 不要把每任务 1.97 美元理解成通用 API 成本。它是特定 benchmark、rollout、harness 和 serving 条件下的公司报告。
• 不要把“基于 Kimi K2.7 base”自动等同于某个公开 Hugging Face checkpoint；公开材料中仍有命名和版本边界。

这一条给我的 insight

SWE-1.7 最值得学习的不是 headline 分数，而是 coding agent 的新 moat：高质量 RL 任务、能抗 reward hacking 的 verifier、长程 self-compaction、分布式 rollout freshness、低延迟 serving、产品 harness 中的行为约束。未来 coding model 发布如果只报一个 SWE-Bench 或私有榜分数，会越来越不够；更有信息量的是训练闭环的系统账本：数据如何筛、reward 如何防 hack、rollout 如何同步、harness 如何影响行为、成本如何计算。

Shilong Liu：self-evolving agents 的核心不是名字，而是“什么在变、反馈从哪里来、循环在哪里闭合”

原帖与材料地图

Shilong Liu 的原帖本身只有一个 X Article 链接，标题是 A Taxonomy of Self-evolving Agents。文章从 Hermes Agent、RSI Lab、NVIDIA ENPIRE、自动科研系统和训练/免训练 self-evolving 算法出发，指出“self-evolving、self-improving、learning、adapting”这些词被大量混用，需要一个 taxonomy 来区分不同方向。

文章的基础框架是三个对象：Models、Harness、Artifacts。Model 是 LLM 权重；Harness 是 prompt、memory、tools、loop design、router、skills 等把 model 变成 agent 的外部系统；Artifact 是 agent 产出的东西，例如算法、论文、发现、机器人策略。基于这三个对象，文章把 self-evolving systems 分为三类：Artifact iterative optimization、Harness self-improvement、Model learning without gold answers。

回复区最重要的是 Yi Lu（yyyiiillluuu）的两条评论：他认为 artifact 这个词有些 misleading，本质上更像用户如何操作 agent；loop engineering 只是 self-evolving agent 的第一步；真正的 self-improvement 是 loop-over-loops，下一轮 loop 应该从更接近目标的状态出发。Shilong 回应说会更新版本，并称赞 Yi Lu 的 blog。这把 taxonomy 从“分类表”推进到“循环如何积累经验”的问题。

它真正提出的问题

这篇文章真正提出的问题可以压缩为三问：What evolves? What feedback drives it? Where does the loop close? 如果只说“agent 自我进化”，这个词几乎没有信息量。进化对象可能只是一次输出 artifact，也可能是 agent 的 prompt/memory/tool/harness，也可能是模型权重；反馈可能来自单元测试、robot reward、reviewer、majority vote、环境无响应、LLM judge、human maintainer；闭环可能闭在 benchmark、代码、科学实验、物理世界，也可能只闭在一个容易被 Goodhart 的 proxy 上。

这个 taxonomy 的价值是把 hype 降维成工程问题：一个系统到底能不能把失败经验变成下一轮更好的初始条件？它是临时搜索，还是把经验写进可复用 memory/tool？它改的是外部流程，还是权重？它的 evaluator 是否会被 agent 学会钻空子？这些比“是否 recursive self-improvement”更具体。

thread/回复里的争议

Yi Lu 对 artifact 的提醒很重要。Artifact iterative optimization 里，agent 反复改进一个外部产物，看起来像“artifact 在进化”；但从用户角度看，很多时候是人把目标、环境、评价器和操作接口搭好，agent 只是被用于搜索。因此 artifact 一词可能掩盖 harness 和 user protocol 的作用。Shilong 接受这个反馈，说明 taxonomy 仍在演化。

Yi Lu 的“loop-over-loops”进一步指出，真正的自改进不是单轮 loop 成功，而是 loop 的设计、经验、约束、工具和 evaluator 也被下一轮继承或改进。这里最大的风险是把临时 workaround 冻结成永久规则：如果 agent 在某个任务里靠 hack 过了测试，harness 记住了这个策略，下一轮就会从更错误的状态开始。因此 scope、provenance、confidence、evaluation 都必须随经验一起记录。

外部材料与证据

Artifact iterative optimization 是当前最显眼的一类。AlphaEvolve 用 coding agents 和 evolutionary loop 改进算法，在数学、数据中心调度、芯片电路、LLM training stack 等问题上报告发现；FARS 作为 Fully Automated Research System，公开部署中产生 166 篇 AI-generated papers，覆盖 67 个细分 AI/ML topics，并收集 282 份 structured reviews，同时暴露 narrow scope、methodological limitations 和 integrity issues。Recursive 的自动 AI research 系统在三个紧反馈 benchmark 上报告改进：NanoChat validation BPB 从 0.9372 到 0.9109，NanoGPT Speedrun 从 79.7 秒到 77.5 秒，SOL-ExecBench mean SOL 从 0.699 到 0.754。NVIDIA ENPIRE 则把循环搬到物理机器人：reset、verify、action、policy improvement 构成 agent-operable environment，并报告展示任务 pass@8 成功率达到 99%。

Harness self-improvement 是最容易被低估的一类。GEPA 把可复用规则写进 prompts；ACE 把经验写成 playbooks；Mem0 和 UI-Mem/Mem-UI 代表记忆或技能层；Alita/Alita-G 代表自动生成工具或 specialist；Eevee 和 routing 工作强调多 agent 专家分工。它们不改 model weights，却确实改变 agent 下次行动的初始条件。Shilong 的一句话很关键：如果把 harness 看成 agent 的一部分，那么 prompt/memory/tool update 也可以被视为 learning。

Model learning without gold answers 更接近传统 ML，但在 LLM 时代重新被纳入 self-evolving 叙事。TTRL 用 test-time scaling 中的 majority voting 等内部信号构造 reward，在无显式标签的数据上做 RL；DeepSeek-R1 用可验证 reward 释放 reasoning；SPIN、Absolute Zero 和 Early Experience 用 self-play 或环境弱信号；TTT 从架构上让推理过程本身包含可更新状态；continual learning 则提醒我们，任何在线更新都要面对遗忘与 replay。SIA 等近期工作开始探索 harness 与 model 更新的模糊边界。

边界与不要误读

• 不要把所有“自演化”都理解为模型权重自我改写。很多系统只是 artifact 搜索或 harness 学习。
• 不要把 artifact 成功等同于 agent 自身变强。一次找到好 kernel，不代表下一次自动更懂 kernel，除非经验被可靠写回 loop。
• 不要把 evaluator 当作中立真理。FARS、Recursive、ENPIRE 都显示，越强的自动搜索越需要更强的 integrity check 和 reward-hack detector。
• 不要忽视物理世界成本。ENPIRE 的 reset/verify/action 接口是巨大贡献，但真实机器人资源、token 消耗和利用率仍是瓶颈。

这一条给我的 insight

Shilong taxonomy 的研究价值在于给“自我改进”增加审计字段。任何 self-evolving claim 都应回答：优化对象是什么？经验是否持久化？谁验证进步？失败是否会污染记忆？经验的 scope/provenance/confidence 如何记录？下一轮 loop 为什么从更接近目标的位置开始，而不是从更会钻空子的位置开始？我会把它看作 agent 系统设计的最小 schema，而不是一个静态分类表。

综合判断：六条线索共同说明什么

现在才适合做综合。六条材料共同说明：AI 前沿的难点正在从“模型一次输出是否聪明”转向“反馈闭环是否可信”。每个闭环都有三个部件：被优化对象、反馈信号、状态更新机制。self-distillation 更新 student behavior，反馈是 teacher token distribution；SAO 更新 policy，反馈是 value/advantage 与环境 reward；J-space 更新的是我们对内部状态的观测与干预，反馈是 readout/intervention 成功率；SWE-Bench Pro 更新 leaderboard 信任，反馈是任务审计；SWE-1.7 更新 product coding agent，反馈是 FrontierCode/rubric/verifier 与 Devin harness；self-evolving taxonomy 更新 artifact/harness/model，反馈来自 evaluator、环境或弱信号。

如果把这六条线索放进研究路线图，我会优先看四类实验。第一，自蒸馏的 token-level causality：哪些 epistemic tokens 是必要探索，哪些只是噪声。第二，agentic RL 的 cost-normalized ablation：同等 wall-clock 和 trainer memory 下，critic、DIS、compaction 各贡献多少。第三，J-space 的 metric-aware control：把 detector covector 与 intervention vector 分开评估。第四，coding eval 的治理协议：任务级 broken labels、公开复核、私有 held-out 的可审计摘要、trace integrity 与 anti-hack 规则。

这也是我认为前一版浅摘要不足的地方：它太快把六条材料合成“可验证闭环”主题，却没有逐条介绍原帖、回复和证据。真正有价值的不是这个主题词，而是每条材料都告诉我们闭环会在哪个位置坏掉，以及怎样设计下一代实验去定位故障。

证据边界与资料索引

本文只使用公开可访问材料与来源方公开报告的数字。X/Twitter 回复排序、可见性和互动数会变化；公司博客和私有 benchmark 数字按“来源方报告”处理；公开回复中的个人实验数字按“公开自报、未独立验证”处理。文中没有把未公开标签、私有任务内容或不可复验内部结果写成独立事实。

1. beanie0__0 / self-distillation

• 主帖：https://x.com/beanie0__0/status/2037018293735952471
• arXiv：https://arxiv.org/abs/2603.24472
• GitHub：https://github.com/beanie00/self-distillation-analysis
• Hugging Face collection：https://huggingface.co/collections/beanie00/self-distillation-analysis
• SDPO issue：https://github.com/ROLL-LM/SDPO/issues/26

2. Grad / GLM-5.2 / SAO

• 主帖：https://x.com/Grad62304977/status/2075092570921681288
• SAO arXiv：https://arxiv.org/abs/2607.07508
• Z.ai GLM-5.2：https://z.ai/blog/glm-5.2
• IcePop / Ring-1T：https://arxiv.org/abs/2510.18855
• INTELLECT-3：https://arxiv.org/abs/2512.16144
• prime-rl：https://github.com/PrimeIntellect-ai/prime-rl

3. dongxi_nlp / J-space

• 主帖：https://x.com/dongxi_nlp/status/2074748134605852926
• Anthropic blog：https://www.anthropic.com/research/global-workspace
• Transformer Circuits paper：https://transformer-circuits.pub/2026/workspace/index.html
• Jacobian lens repo：https://github.com/anthropics/jacobian-lens
• Neuronpedia J-lens：https://neuronpedia.org/jlens

4. OpenAI / SWE-Bench Pro

• OpenAI thread：https://x.com/OpenAI/status/2074972179385720836
• OpenAI audit：https://openai.com/index/separating-signal-from-noise-coding-evaluations/
• SWE-bench Verified article：https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
• Scale SWE-Bench Pro：https://scale.com/blog/swe-bench-pro
• METR note：https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/
• Cursor reward hacking：https://cursor.com/blog/reward-hacking-coding-benchmarks
• DeepSWE v1.1：https://deepswe.datacurve.ai/blog/deepswe-v1-1

5. Cognition / SWE-1.7

• 主帖：https://x.com/cognition/status/2074882970935034309
• SWE-1.7 blog：https://cognition.com/blog/swe-1-7
• FrontierCode：https://cognition.com/blog/frontier-code
• FrontierCode 1.1：https://cognition.com/blog/frontier-code-1.1
• Trustworthiness blog：https://cognition.com/blog/measuring-open-source-model-trustworthiness
• Kimi K2.7 Code：https://huggingface.co/moonshotai/Kimi-K2.7-Code
• Kimi platform pricing：https://platform.kimi.ai/docs/pricing/chat
• Fireworks RL infrastructure：https://fireworks.ai/blog/frontier-rl-is-cheaper-than-you-think

6. Shilong Liu / self-evolving agents

• 主帖：https://x.com/Shilong_Liu_AI/status/2074800880017342665
• X Article：https://x.com/i/article/2074623608807460864
• AlphaEvolve：https://arxiv.org/abs/2506.13131
• FARS：https://arxiv.org/abs/2606.31651
• Recursive automated research：https://www.recursive.com/articles/first-steps-toward-automated-ai-research
• ENPIRE：https://research.nvidia.com/labs/gear/enpire/
• TTRL：https://arxiv.org/abs/2504.16084
• DeepSeek-R1：https://arxiv.org/abs/2501.12948
• SPIN：https://arxiv.org/abs/2401.01335
• Absolute Zero：https://arxiv.org/abs/2505.03335