2026-09-27 19:12:00
这两天，Hacker News 上一个题为《Plan mode is dead》的帖子火了。
它的作者是亲手把「计划」做成产品、又亲自复盘这条路为何走不通的人：Ayman Nadeem，她是 YC 孵化的小型 AI 编程公司 Nuanced 的创始人兼 CEO。
今年早些时候，Nadeem 坚信，计划会成为 AI 编程最重要的环节。于是，她围绕这一判断打造了一款桌面编程应用，希望帮助开发者在代码生成速度大幅提升之后，重新掌握软件构建过程。
几个月后，她改变了看法。
这篇文章真正触及的，是 AI 编程工具里一条正在松动的产品假设：写代码前，人要先把需求、架构和执行步骤整理成一份完整计划，再交给 Agent。
以下为博客原文编译（第一人称）。文中出现 Planning 时翻译为规划，Plan 翻译为计划。
今年早些时候，我相信规划会成为用 AI 构建软件时最重要的环节。
我对这个判断深信不疑，甚至围绕它打造并发布了一整套桌面编程应用。Nuanced 的出发点是：AI 已经大幅提升了代码生成的速度和数量，可支撑这种新工作节奏的界面还没有跟上。
Nuanced 在规划上的方案失败了，但这段经历也让我看到，计划模式整体上已经没有过去那么有用了。
过去，计划模式主要承担两项工作：为 Agent 提供足够精确的指令；帮助人类理解自己正在构建什么。随着模型能力提升，第一项工作正在迅速变得过时。第二项工作比以往更重要，可计划模式并不适合承担这个任务，尤其是在并行运行的 Agent 数量不断增加之后。
我为什么做 Nuanced
就会自行补足空白。它划分抽象边界的方式，可能会在之后给我带来问题。对于预期行为和设计目标的误解，会沿着多个文件向深处传播，隐藏在聊天界面之下，很容易被遗漏。
在这种表层之下摸索那些难以理解的问题，感觉还不如一开始就把设计做好高效。
这段经历让我在精神上与工作脱节，甚至有些像行尸走肉。Conductor、Codex 等编码应用让并行运行多个 Agent 变得更加容易，这种感觉也随之变得明显。
我觉得自己很难像过去那样集中注意力，也很难深入理解正在做的事情。要判断生成结果是否正确，也变得更加困难。
当时没有一条清晰、可解释的轨迹，能够呈现「用户提示词 → Agent 决策 → 代码 → 产品行为」之间的联系。
这并不意味着我想回到过去，重新逐行查看代码或文件。事实上，我觉得用自然语言思考想法更容易，也更高效。我希望自己能够站在代码之上工作，同时继续理解系统是如何运行的。
现有计划模式缺乏协作感
我逐渐意识到，虽然计划模式已经存在，但适合良好规划的抽象方式仍然不存在。
我先后使用了 Claude Code CLI、Conductor，后来又使用了 Codex。期间，我总是在反复塑造、删改计划，却没有一个明确的地方可以持续迭代。
在 Codex 的批注功能出现之前，我通常只能通过聊天推进这件事，再把计划中的部分内容复制到新的消息里修改。这样的复制粘贴流程很笨拙，也让围绕一个想法展开工作、同时掌握当前计划变得十分困难。
我希望给计划一个固定的归属，把它放进整体工作流中，让它从随着对话推进而逐渐淹没在历史记录里的临时文字，变成一份持续存在、可以不断更新的文档。
我希望把计划模式变成指导开发的一等能力，因为我需要：
思考接下来要做什么；
确保自己的描述足够准确；
理解已经完成了什么；
在出现问题时，理解问题发生的时间和原因。
打造理想工作流
我思考了自己理想中的工作方式，决定把它编码成一款产品。
Nuanced 允许用户创建多个线程，每个线程都是一段聊天对话。用户可以在其中讨论想要构建的东西，系统会指出其中的歧义，以及需要用户做决定的事项。双方共同推进，最终在实现开始前形成一份持久化计划。
之后，Nuanced 会按照计划执行，确保生成的代码符合用户要求。
我想建立一条从意图开始，一直延伸到实现、审查和验证的完整流程。
在我看来，Nuanced 更像是人类心智的义肢，也可以说是我这个 ADHD 大脑的义肢。它承担指导工作，也帮助我持续掌握项目正在发生什么。
我错在哪里
我对现有工具缺口和软件开发生命周期变化的判断，大体没有错。真正没有达到预期的，是我们的实现方式。
原因有几个：我把规划和计划混为一谈；模型变得足够强大；没人愿意阅读 AI 生成的文字；我们用一种打断工作连续性的方式，把规划和构建分开了。
规划（Planning） ≠ 计划（Plan）
我们最先发现，自己把规划和计划混为了一谈。两者其实并不是同一件事。
我原本认为，在实现之前留出充分思考的空间很有价值。我也认为，随着项目推进，把这些思考保存在一份大型结构化文档中会很有价值。
但早期用户对这类规格文档的兴趣，出乎意料地低。
模型变得足够强大
随着模型借助上下文和记忆理解大型代码库的能力增强，它们越来越擅长探索代码仓库，并自行做出合理判断。
人类需要明确告诉模型「请产出一个经过充分思考的结果」，这种需求已经减少了。
我原本没有想到，模型能力会和 “为人类思考设计更好的界面” 形成竞争关系。模型每可靠地自行做出一个决定，就少有一个决定需要单独提出来交给人处理。
AI 生成的文字读起来很痛苦
那份规格文档包含了更多信息，却没有带来同等程度的清晰度。
原因之一，是我们的规格文档太长了。它们记录了重要决策，也包含了许多看起来有用的背景信息。问题在于，这些文字是 AI 生成的。
AI 生成文字的节奏和过度结构化的写法，会让阅读变得非常困难。我经常读着读着就走神了。
发现这个问题后，我们没有立即放弃规格文档，而是做了一个 Spec Tour，希望带着用户浏览文档中的重点。
结果，这只是又增加了一层复杂度。屏幕上出现了更多文字，也有更多内容要求我分散注意力。
如果必须再生成一份更短的规格摘要，才能让原来的规格文档变得可用，那么完整文档存在的意义又是什么？
我们把一个本应连续的过程拆开了
我们的工作流过于线性，也过于强调顺序。大致流程是：
聊天 → 通过回答问题消除歧义 → 生成规格文档 → 审查规格文档 → 修改规格文档 → 批准 → 实现 → 审查代码
真实的思考不会这样进行。把这些环节彼此分开，也显得人为和生硬。
通常情况下，你会先理解问题的一部分，再尝试做点什么。第一次生成会带来新的认识，让你改变原来的想法，尝试另一种方案。每一步都会暴露新的问题。
规划和构建往往彼此交织，也会自然展开。计划模式很难容纳这种方式，尤其是 Nuanced 当时的设计。
我们的界面要求用户过早地「结束思考」，这样才能开始构建。实现一旦开始，再回到之前基于聊天的推理过程，就像在工作流中倒退。那条瀑布流无法逆行。
观察 Codex 目前的工作方式，你会发现规划和执行之间的边界正在消失，二者逐渐合为一体。
早期，编码 Agent 更适合这样的流程：
规划 → 批准 → 执行
那时，走错方向的代价高得多。
随着 Agent 更擅长理解系统，它们也越来越能自主行动、测试自己的工作，并在检查结果后调整方案。这使另一种循环成为可能：
理解 → 行动 → 检查 → 澄清 → 调整 → 再次行动
这个循环中依然包含大量规划，只是规划不一定要呈现为一份名为「计划」的文档。
我最大的错误，是把计划做成了一个成果文档，却没有设计出一个能够提升人类理解力的过程。
计划模式与构建模式的分离很奇怪
Nuanced 同时提供计划模式和构建模式，用户可以任选其一开始。
计划模式总会生成一份规格文档。构建模式不会强迫用户先写规格文档，适合那些不值得专门制作规格文档的小任务。但这两种模式之间的分离很尴尬。
用户需要先问自己一个元问题：这个任务是否值得规划？如果值得，还要记得通过按钮或键盘快捷键启用计划模式。
这种区分应该由 AI 根据已有上下文替用户判断。让用户记住自己该处于哪种模式，只会增加认知负担。
意识到这一点后，我有种「midwit 梗图」的感觉：原来，一个简单的聊天界面，按需进行规划，而不是默认进入计划流程，体验可能已经相当不错。
我们仍未解决「理解」问题
思考要构建什么、为什么重要，以及评估各种决策，依然十分重要。人需要建立对系统正在发生什么的连贯理解，但我不认为一大段由 AI 生成的文字适合承担这个任务。在聊天中逐步推进决策，感觉更加直观。随着系统不断变化，如何让这种理解始终保持更新，仍然是一个悬而未决的问题。
当 Agent 数量从五个增加到几百个，这个问题会变得更加困难。
跟上变化，不能意味着阅读每一段对话，再为每一次代码变更单独要求解释。Agent 需要找到少数几个最值得人关注的位置，并提供足够的上下文，让人的注意力真正产生作用。
当数百个能力不断增强的 Agent 同时修改一个系统时，我们仍然没有解决如何帮助人保持方向感的问题。
但在我看来，更深层的问题始终存在：人类如何理解系统，如何穿行于复杂的信息层级，如何使用强大的工具。
界面会随着背后的技术一起变化，让复杂性变得可理解的需求不会消失。
网友热评
对于 Nadeem 的观点，支持、反对的人皆有。
一位自称参与 Claude Code 开发的人基本认同「Plan Mode 过去有用，但现在价值正在下降」的判断。他解释，Claude Code 的 Plan Mode 本质上一直只是一个提示机制，用来提醒模型「先规划，不要立刻写代码」，并没有真正改变模型可调用的工具。随着模型能力提升，他自己已经越来越少使用 Plan Mode：模型对任务意图的理解更好了，而在更复杂的任务中，规划也越来越呈现出交互式、迭代式的特点，很难在执行前一次性完成。
不过，他并不认为「理解代码变化」这个需求已经消失。对于核心系统中的复杂修改，他有时会让 Claude 额外生成说明文档、架构图甚至交互式 Demo，帮助自己和其他开发者理解改动及其备选方案，并把这些材料附在 PR 中，为后续协作和未来继续处理项目的 Claude 保留上下文。
这里帮大家回顾一下，2025年中，Claude Code率先把「规划」和「执行」做成明确的模式区分；此后Cursor、GitHub Copilot快速跟进。2026年初，OpenAI Codex和Google Gemini CLI也先后补齐 Plan Mode。到 2026 年 3 月，Plan Mode已经从 Claude Code 的一个交互设计，变成主流Coding Agent几乎都会提供的一种产品形态。
另一位开发者认为，Plan Mode 的价值仍然很明确，尤其是在大型代码库和复杂任务中。它至少能让开发者先理解 Agent 准备采取的策略，并有机会检查设计和架构。如果缺少这一步，开发者很容易逐渐失去对代码的理解，Code Review 也可能退化成简单的「打勾通过」，最终让代码库变得越来越臃肿、难以维护。他尤其担心，能力较弱的开发者虽然表面产出提高了，却没有真正建立起对系统的理解，团队也可能因此快速积累大量技术债务。
大家怎么看呢？
Hacker News 原贴地址：https://news.ycombinator.com/item?id=49840054
原文链接：https://www.aymannadeem.com/artificial/intelligence,/developer/tools/2026/09/24/plan-mode-is-dead.html
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]
2026-09-27 19:12:00
核心结论：mHC 的四条残差流并未被均匀使用 —— 读写权重集中在约两条流上；深层（22–42 层）残差混合已接近单位矩阵。干预实验显示：去掉最弱读写路径六任务平均分最多下降 0.38 个百分点，深层残差混合矩阵替换为单位矩阵后六任务平均分基本不变（84.22 → 84.26），浅层固定为平均矩阵仅下降 0.25 个百分点。
论文题目：How Does mHC Use Its Residual Streams? Selective Routing and Near-Identity Mixing
论文链接：https://arxiv.org/html/2609.05309v1
DeepSeek-V4-Flash 采用 mHC 结构维护四条残差流，但在实际计算中，它们并没有被均匀使用。mHC 会为每个 token 单独生成读写权重，因此路由可以随输入变化。然而，在训练后的模型中，同一子层的主导流选择对 token 呈现出较强的一致性：对于同一个 Attention 或 FFN 子层，读写权重通常集中在约两条残差流上。残差混合矩阵也呈现出退化形态：虽然浅层仍然存在一定程度的跨流混合，但是到了第 22–42 层，残差混合矩阵已经接近单位矩阵。
我们进一步在推理阶段干预，分别去掉每个 token 读或写权重最小的路径后，PPL 最多上升 2.7%，六个任务的平均分最多下降 0.38 个百分点。将第 22–42 层的残差混合矩阵替换为单位矩阵后，PPL 上升 1.9%，任务平均分则基本保持不变。浅层虽然不能直接用单位矩阵取代（替换后 PPL 上升 41.4%），但是固定为其在 C4 校准集上的 token 平均矩阵（即保留本身的混合结构、去掉逐 token 的变化），PPL 仅上升 0.2%，六个任务的平均分下降 0.25 个百分点。
图 1｜四流 mHC 的读写主要集中在少数残差流上，主导流随深度切换；浅层保留跨流混合，深层则接近各条流独立传递。
从单流残差到多流残差
在标准 Transformer 中，每个 Attention 或 FFN 子层都从同一条残差流读取隐藏状态，并将计算结果加回这条流。Hyper-Connections（HC） 及 Manifold-Constrained Hyper-Connections（mHC） 将单条残差流扩展为多条并行流。
在本文分析的 DeepSeek-V4-Flash 模型中，mHC 维护四条残差流。将第
对单个 token，
mHC 还使用 Sinkhorn–Knopp 迭代对 
mHC 允许模型随输入调整四条残差流的读写和混合方式，但训练后的模型如何使用这些流，又在多大程度上依赖这种动态性，仍不清楚。因此，我们分析了 DeepSeek-V4-Flash 前向计算中的读写权重、残差混合矩阵和各条流的隐藏状态，并通过推理时干预，检验裁剪读写路径或替换残差混合矩阵对模型性能的影响。
分析对象与评测设置
我们使用公开的 DeepSeek-V4-Flash-0731 权重进行分析。我们从 C4 数据集中随机采样 512 个长度为 1,024 的序列，在前向计算中记录各子层为每个 token 生成的读写权重和残差混合矩阵，以观察这些映射随输入和网络深度的变化。另外，我们通过 C4 数据集困惑度（PPL）和六个零样本任务（ARC-Easy、ARC-Challenge、PIQA、HellaSwag、MMLU 和 GSM8K）评估干预后的模型性能。
读写路由的集中程度与主导流选择
读映射 
主导流一致性：在同一个子层，选择最常见主导流的 token 占比。
有效流数量：将读或写权重归一化为 
图 2｜左：主导流一致性；右：有效流数量。每个点合并了同层 Attention 和 FFN 子层的统计结果。
图 2 中，读映射的主导流一致性平均为 0.871，写映射为 0.905。也就是说，在一个给定子层内，大多数 token 往往共享同一条主导流。
与此同时，读映射平均对应 1.998 条有效流，写映射为 1.775 条。这说明尽管架构提供了四条流，一次典型的 Attention 或 FFN 计算实际上只把主要权重放在约两条流上。
上述统计描述了单个子层内的路由模式。图 3 进一步展示各条流在不同子层中的平均读写权重。
图 3｜四类位置上的平均流负载。高负载区域形成连续的深度区间，但主导流会随层、子层类型以及读写映射发生切换。
残差流之间的表示相似度
一个需要进一步检查的问题是：四条流的表示是否已经趋于相似，从而使模型只需集中访问其中少数几条？我们在每个 Attention 或 FFN 子层计算四条流隐藏状态之间的余弦相似度，共得到六组两两比较，结果见图 4。
图 4｜四条残差流两两之间的余弦相似度随深度的变化。左图为六组流对的平均值，右图分别展示各组流对，颜色越深表示余弦相似度越高。
图 4 左图中，四条残差流在模型入口处的余弦相似度为 1，因为它们由同一份输入表示复制而来。经过第一个 Transformer 层后，各条流的表示开始分化；在之后的网络中，六组流对的平均余弦相似度介于 0.235 和 0.564 之间，总体平均为 0.404。也就是说，各条流在前几层就形成了方向上不同的表示，此后也没有重新趋于一致。
右图将六组流对分开展示，每一行对应一组流对，颜色越深表示余弦相似度越高。从各行的颜色变化可以看出，不同流对随深度呈现出不同的变化，也没有哪一对残差流在整个网络中始终保持较高的相似度。
不过，表示方向是否相同，与具体读写路径是否必要，是两个不同的问题。即使某条流的表示方向与其他流不同，当分配给它较小的读写权重时，仍可能对模型输出影响有限。这些较弱的读写路径能否裁剪，需要通过后面的推理时干预检验。
残差混合映射随深度的变化
我们用残差混合矩阵
当
图 5｜Attention 和 FFN 子层的单位矩阵偏离，每个点为校准 token 上的平均值。
图 5 显示，较大的偏离主要出现在模型前半部分。在第 22 层后，残差混合矩阵逐渐接近单位矩阵。在第 23–42 层的 40 个子层中，有 32 个子层的偏离低于 0.01。图 6 分别给出了第 0–21 层和第 22–42 层的平均残差混合矩阵：
图 6｜第 0–21 层和第 22–42 层的平均残差混合矩阵。
这更直观地呈现了这种深度差异：第 0–21 层的平均矩阵中仍能看到非对角权重；第 22–42 层的平均矩阵则已接近单位矩阵。
读写路径裁剪与残差混合映射替换
读写路径裁剪
对每个 token 和每个子层，我们分别在读映射和写映射中保留权重最大的
保留 top-3 时，读写路径裁剪对 PPL 和六个任务平均分的影响都较小。进一步裁剪到 top-2 后，两项指标的变化明显增大，其中写映射裁剪的影响更大。因此，权重最小的一条路径可以近似移除。
残差混合映射替换
我们将指定深度范围内的残差混合矩阵替换为
将深层残差混合矩阵替换为
将浅层固定为各子层的 C4 平均矩阵后，PPL 上升 0.2%，六任务平均分下降 0.25 个百分点。这项干预固定了浅层的跨流混合方式，说明逐 token 变化带来的额外作用有限。
图 7 进一步列出每个任务的得分变化：
图 7｜各项干预相对原始模型的零样本分数变化，单位为百分点。为突出常见变化范围，色阶在 ±7 处截断，格内数字保留真实变化值。
讨论：多流残差结构的简化方向
在读写路由上，部分低权重路径可以移除，但继续提高裁剪强度会带来性能下降。因此，可以探索在保留多流结构的同时，适当降低读写路由的密度。这样的设计能否兼顾模型性能与计算效率，需要在相应的架构中重新训练和评估。
残差混合映射则表现出明显的深度差异：深层替换为恒等映射后，模型性能变化较小；浅层仍需要跨流混合，但同一子层内的逐 token 变化作用有限。因此，可以探索让残差混合映射的动态性随深度变化，而不必在所有层采用相同的机制。近期的两个多流模型已经采用了更简单的残差通路：腾讯 Hy4-preview 的 identity Hyper-Connections（iHC）将 
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]
2026-09-27 17:34:00
导读｜RSI（递归自我改进）不应只发生在模型参数层：类比人类大脑的不是 LLM，而是整个 Agent。EverMind 开源的 Raven V0.2.0 为此提供了两个核心设计：为 RSI 而设计的 Harness 框架，以及统一编排专业 Agent 的 The Harness of Harnesses。在多 Agent 编排、深度研究、编码、设计与持续执行评测中，Raven 的多项结果优于同底座模型下所比较的 Harness。
递归自我改进（Recursive Self-Improvement，RSI），指 AI 系统利用执行结果与反馈，持续改进产生这些结果的机制本身。谈到 RSI，人们往往首先想到模型参数，但人类大脑给出了另一种答案：按照互补学习系统理论（CLS；Kumaran, Hassabis & McClelland, 2016），海马快速记住具体经历，皮层则通过回放与整合，缓慢沉淀出可复用的能力。因此，真正可以类比大脑的不是 LLM，而是整个 Agent：模型参数如同皮层，适合慢速巩固；由记忆、技能、提示、控制代码与决策策略构成的 Harness，则应像海马一样快速适应。RSI 同样可以、而且应当发生在 Harness 层。学术界已有不少工作探索让 AI 改写 Agent 本身，但主流的工程化 Harness 框架仍以人工编写和维护为主：提示靠人调，流程靠人写，出错靠人修。EverMind Raven V0.2.0 正是从这里出发，围绕两个核心设计理念构建。
其一，为 RSI 而设计的 Harness 框架。Raven 把 Harness 中可被 AI 改写的部分分为四类：Modules（如 playbook 与子 Harness 的组合）、Code（如执行前检查等策略代码）、Prompt（如系统提示与上岗手册）和 Policy（如工具开放与闸门配置）。这四类内容共同构成 Harness 的装配方案，每一类都可以独立替换、改写。AI 可以依据任务中积累的知识、经验与反馈修改这些部分，持续改进个体 Harness 与团队协作策略。V0.2.0 迈出了第一步：运行时的 Curator 已作为实验性功能开源，跑通了从反馈、生成代码到校验安装的闭环。
其二，The Harness of Harnesses。Raven 把自身深度优化的四个子 Agent（Raven-Research、Raven-Code、Raven-Design 与 Raven-Oncall）与 Claude Code、Codex 等专业 Agent 统一编排，负责成员选择、任务拆解、依赖调度与结果交接，并由 EverOS 保留跨会话的上下文与经验，支持跨模型、跨框架的能力组合。
围绕 AI 改进 AI，Raven 目前有两条探索：一是 AI 改进 Agent 自身的工作方式，即上述 Curator（见第四部分）；二是 AI 改进 AI 的研发工作，Raven RSI 项目在 nanochat 预训练实验中完成 7 轮、172 次训练，在相同的单次训练预算下使 val_bpb 相对下降 5.8%（见第六部分）。
Raven 自身的发布也是一次实际应用：它完成了浏览器端物理小游戏、16 页产品介绍、中英文海报和项目 README，将多种专业能力用于制作自己的宣传物料。
图 1｜Raven V0.2.0 主视觉。产品界面、案例及评测图由 EverMind 提供。
一 Harness of Harnesses 如何组织专业 Agent
当你把一项复杂任务交给 AI，真正费力的往往不只是得到一个答案。你还要决定先查什么、交给谁做、哪些工作可以并行、结果如何交接，以及出现问题后怎样调整。下一次遇到类似任务时，这些判断和纠正能否继续发挥作用，同样影响着 AI 是否真正成为可靠的工作伙伴。
研究需要检索与证据，编码需要实现与调试，设计需要组织表达与交付，实验任务还需要持续运行、观察结果并推进下一轮。不同专业 Agent 已经形成了各自的工具、技能和工作方式。复杂任务需要把这些能力组织起来，也需要让执行中积累的经验进入后续的工作过程。
Claude Code、Codex 等专业 Agent 可以保留自己的专长与执行机制，Raven 在更上层承担协调工作：谁先做、谁接着做、谁需要读取哪些结果，以及什么时候可以进入下一步。接入一个成员，意味着把它的专业能力纳入一条更完整的任务链。
这也是 Harness of Harnesses 的含义。Harness 是一套把模型能力转化为行动的机制，涵盖上下文管理、规划、工具使用、结果检查与执行循环。Raven 连接的成员可以拥有完整的 Harness，并按自己的方式完成被分配的工作。
由此可以看见两个相互衔接的层次：外层组织成员、任务与依赖，成员内部的 Harness 则决定信息如何被使用、工具如何被调用、行动如何推进。Raven-Research、Raven-Code、Raven-Design 与 Raven-Oncall 分别承担研究、编码、设计和持续执行工作；Raven 也可以通过 ACP、CLI 或 OpenAI 兼容 API 连接第三方成员。
图 2｜跨 Harness 协作示意。不同成员分别完成研究、发布材料与网站开发，并交接产物。
二 从一个目标到一张任务图
给一根悬臂梁逐步加载，观察仿真求解器在不同载荷下的收敛情况，看起来是一项具体的计算任务，实际却包含研究、编码和实验三个环节。Raven 展示了一条接力链：Raven-Research 研究方法，Raven-Code 实现计算，Raven-Oncall 接续运行实验。
Raven 首先把目标拆成任务图，再为每个节点选择成员，并根据前置任务的完成状态决定下一步。研究节点完成后，被引用的上游结论进入代码节点；代码产物就绪，再由实验节点接续。每个成员承担专业工作，Raven 负责组织它们之间的输入、输出和启动条件。
图 3｜悬臂梁仿真任务图。研究、代码与实验节点按依赖关系顺序接力。
这里的关键机制是 DAG，即有向无环图。没有相互依赖的分支可以并行启动，需要前置结果的节点则等待依赖完成。节点启动时，Raven 会把任务目标、角色职责以及明确引用的上游输出或产物入口组织成输入。当前置任务失败时，依赖它的节点可以被跳过，不相关的独立分支仍可继续。
这种组织方式让协作过程变得可观察：任务是否已经启动，依赖是否满足，交接了什么结果，后续节点为什么能够继续。用户也可以把成员、任务与依赖保存为 Playbook，在类似需求中再次使用。一次执行形成的工作链，因此有机会成为可复用的流程。
三 记忆如何连接任务与经验
一项任务完成后，后面的成员需要接到的不只是 “已完成” 的状态，还包括可以继续使用的结论、文件、引用和上下文。对支持本地文件读取的后端，Raven 可以附上依赖节点的记忆记录入口；支持会话续接的后端，则可以沿用连续步骤中的上下文。
跨会话的积累由 EverOS 承接。用户上下文、Agent 经验和世界知识，可以成为后续任务的参考。任务图负责组织这一次的执行顺序，记忆则帮助判断过去哪些信息仍然有用，减少重复交代背景和重新寻找材料的成本。
经验要进一步影响工作效果，还需要进入实际的执行策略。某次任务暴露了什么问题，用户反复强调了什么要求，哪些做法值得继续采用，都需要转化为后续可执行的调整。Raven 的模块化 Harness 为这些变化提供了具体落点。
四 Harness 自进化：让一次任务成为下一次任务的起点
Raven 的 Harness 从设计上就是可以被 AI 改写的。在运行时承担这项工作的是 Curator（V0.2.0 中为实验性功能，随代码仓库提供）：它读取当前实际装配出的 Harness、任务要求、执行留痕与用户反馈，生成具体改动，可以是提示与上岗手册（Prompt）、配置与工具闸门（Policy）、实现策略协议的代码（Code），也可以是 playbook 与子 Harness 的组合方式（Modules）。它可以调整 Raven 原生的根 Harness、子 Harness，以及团队的编排与交接策略。所有改动先经过声明检查、真实装配和预检运行，通过后才安装；安装失败时，触发上一版本 Harness 及受管理内容的恢复流程。生成物全部落在 Raven 原生的扩展点上，无需修改 Raven 的核心源码。
这里的 “为 AI 修改而设计”，可以在代码里直接核对：Memory、Planning、Capability、Action 四个策略面各有一个公共策略协议，Curator 生成实现协议的 Python 类，由适配层绑定到 Raven 已有的回调点；提示、技能包与 playbook 写进 Agent 的 home 目录，新工具与闸门以插件形式注册。AI 通过公开策略协议和扩展接口实施这些改动，每一次改动都可以被检查、回滚和追溯。
设想一位旅行规划师，希望培养一个按自己方法工作的数字伙伴：“按照我的服务流程接待客户，结合我整理的目的地资料，给出适合他们的行程和方案演示。” 图 4 中的旅行规划分身，便从这样的需求开始。
把知识经验与 SOP 变成工作安排
规划师交给它的，是自己过往的经验、工作模式等知识资产，比如以往的路线方案、积累沉淀的各类 SOP。资料提供出行所需的各类信息；经验告诉它怎样安排更舒适、哪些组合容易赶路；SOP 则规定了标准旅行规划场景下个人常用的工作流程。
这些要求经由 Curator 理解后，用于定制当前的 Harness 状态，并落实为一条工作链。一个可能的编排是：主角色与客户沟通并整理需求，研究成员查找和核对目的地信息，设计成员将路线、预算和注意事项整理成方案演示。Curator 既在上层设计 Playbook 的成员分工、任务依赖与产物交接，也在必要时把规划师的工作要求转化为相关 Harness 的策略调整。
四个策略模块承接具体的规划方法
Raven 将自身 Harness 中可调整的策略划分为 Memory、Planning、Capability 和 Action 四个模块。它们通过既定接口参与完整的 Agent Loop，让信息准备、任务规划、工具使用和行动判断都有具体的调整位置。
例如，在旅行规划中，Memory 决定当前轮次能看到哪些客户需求、既往经验；Planning 决定先确认约束、再比较路线、最后组织方案的工作顺序。当涉及接入地图、天气等服务，Capability 可以决定每次模型迭代向模型开放哪些工具；Action 决定在执行前如何并且是否检查相应的待执行动作。
图 4｜从一句需求到可持续塑造的 “数字伙伴”。旅行规划师的知识、经验、SOP 与反馈进入分工和 Harness 策略。图中的演示制作能力由 Raven-Design 承接。
让一次反馈影响后续的行程规划
用户反馈会先由 Curator 判断其对应的策略问题，再转化为 Harness 层面的调整，例如补充 Memory 中需要保留的信息、修改 Planning 的规划方式，或在 Action 中增加检查；用户继续反馈时，这一过程也可以继续迭代。
例如，旅行规划师指出方案 “连续步行太多、跨区往返频繁，还缺少雨天备选”，Curator 就可以让后续规划更多考虑同行人的体力与节奏，优先按区域组织路线，并在交付前检查天气备选。这样，一次反馈改变的不只是当前方案，也能成为后续类似任务采用的工作方法。
类似的过程已在代码库自带的一个模拟案例中跑通：一家虚构旅行社的老板（由模型扮演）只上传店里的资料、扮成客人演练、演练后提意见。入职时，Curator 仅凭资料就生成了流程与检查代码，例如在每条消息发出前数问号，超过两个就打回重写；此后按老板的意见逐轮把问题落实到执行层，第 3 轮评审标准中的 11 条红线全部通过。完整的培养记录、每一轮的代码改动、前后两版方案与复现命令均随代码仓库公开（experimental/simulation/cases/s0925c）。
需要说明的是，这只是一次模拟运行，旅行社是虚构的，老板和客人由模型扮演，Curator 在 V0.2.0 中也仍是实验性功能。目前做到的，是 Curator 能按资料与反馈改写提示、配置、工具闸门与策略代码，校验后安装，并在一个完整场景中跑通多轮闭环；尚未做到的，是跨场景、多次重复的统计验证，以及与模型参数层慢更新的打通。
五 从编排到专业执行看能力表现
团队能否协作，既取决于任务与依赖如何组织，也取决于成员能否完成各自的专业工作。Raven 的评测覆盖这两个层次：编排评测考察任务图的生成，领域评测考察研究、编码、设计和持续执行能力。评测涵盖多项公开基准及 AI4S 内部基准，具体设置见相应图表。这些评测检验的是 Harness of Harnesses 的编排与各成员的专业能力，不涉及 Harness 层自改进的效果。
编排评测关注任务与依赖关系
多 Agent 编排评测包含 Node F1、Edge F1、Partial Order Accuracy 和 Exact Match Rate，分别对应节点、依赖关系、执行偏序与整张任务图的匹配情况。在 Qwen3.8-27B 组中，Raven 的四项结果依次为 0.923、0.812、0.950 和 0.711；在 DS-V4-Flash-0731 组中，依次为 0.963、0.897、0.918 和 0.867。两组均高于图中同模型下的 Hermes 与 Claude Code。
图 5｜多 Agent 编排评测。按底座模型比较节点、依赖关系、执行偏序与整图匹配表现。
研究能力兼顾证据组织与任务完成
Raven-Research 面向深度研究、文献梳理与技术分析。在 DeepResearch Mixed 中，Qwen3.6-35B、Qwen3.5-397B 和 DS-V4-Flash 三组的准确率分别为 56.3%、59.3% 和 76.5%；对应的 DeepSeek-Harness 结果分别为 49.7%、56.0% 和 68.9%。该评测组合了 BrowseComp、FRAMES、HLE 与 xBench-DeepSearch。
图 6｜DeepResearch Mixed 评测。比较准确率、平均每次查询的 Token 用量与费用；输入 Token 包含缓存，自托管组费用未测量。
DS-V4-Flash 组中，Raven-Research 平均每次查询的输入 Token 为 2.380M、输出 Token 为 41.6k，费用为 0.0242 美元。
编码能力覆盖修复重构与数据分析
在 SWE-bench Pro 的 Qwen3.8-27B 组中，Raven-Code 的问题解决率为 54.4%，Claude Code 为 52.4%；该组采用离线生成、在线评分。在 SWE-bench Verified 的 DS-V4-Flash 组中，在线生成的问题解决率为 91.0%，DeepSeek-Harness 与 OpenCode 分别为 90.4% 和 90.2%。
在 SWE-Refactor 的 DS-V4-Flash 组中，Raven-Code 的平均得分为 16.5，Claude Code 为 7.0；GPT5.6-Luna Max 组中，Raven-Code 与 Codex 分别为 13.5 和 10.5。在 WorkBuddy-Code 的 DS-V4-Flash 组中，Raven-Code 的全量集 Reward 为 78.1%，其他模型分组与对照结果见图 7。
图 7｜代码能力评测。指标包括问题解决率、Reward 与平均得分。
在 DataAgentBench 的 2026-08-24 Live 榜单中，Raven-Code 使用 Opus-5 位列榜首，Pass@1 为 0.8762；Permute EQ 使用同一模型，对应结果为 0.8713。
设计能力覆盖演示文稿与视觉交付
Raven-Design 面向演示文稿、网页、图表、SVG 与品牌视觉。在幻灯片生成和视觉设计评测中，Raven-Design 与 Claude Code 在相同模型下的得分见表 1。
表1｜设计评测得分。每格依次为 Raven-Design 与 Claude Code，分数越高越好。
持续执行能力结合质量时间与成本考察
Raven-Oncall 面向实验与持续执行。AI4AI 采用 Nanochat 50M 预训练任务，分配两张 A800 80GB GPU。BPB（每字节比特数）越低越好，运行时长、Token 用量与费用见表 2。
表 2｜AI4AI 评测的训练质量与资源消耗。
在 AI4S 内部自动科研基准中，Raven-Oncall 使用 Opus-5 的任务成功率为 82.35%，Claude Code 使用同一模型为 64.71%。
表 3｜AI4S 内部基准。成功率越高越好，时长、Token 用量与费用越低越好。
这些专业能力进入同一条任务链后，可以共同支撑从研究分析到代码实现、实验运行和视觉交付的完整项目。
六 实际应用案例
Raven RSI：让 AI 改进 AI 的研发工作
Raven RSI 探索让 AI 自主开展研发实验。与第四部分的 Harness 自改进不同，这里被持续改进的是任务中的训练与计算方案，而非 Raven 自身：在给定任务与不可自行修改的评价标准下，Raven 自主规划每一轮，编写代码、运行实验，再根据结果决定后续调整。
在另一组 nanochat 预训练实验中，Raven 持续优化训练方案，共完成 7 轮、172 次训练，没有发生训练崩溃；在每次训练相同的 20 分钟单 GPU 预算下，val_bpb 相对下降 5.8%。完整交付还包括实验结果、可视化、海报、演示文稿和项目网站。
Raven 为自己的发布制作宣传物料
Raven 也将自身发布作为一项完整任务，端到端完成了用于介绍和传播自己的一套物料：浏览器端物理小游戏提供可直接体验的交互内容，16 页产品介绍系统呈现产品信息，中英文海报用于视觉传播，README 则承接开发者了解和使用项目所需的说明。这套物料覆盖了从代码实现、内容组织到视觉制作的完整工作。
Godot 游戏从资产制作走向完整项目
Godot 游戏资产制作展示了更复杂的项目型协作：先进行参考研究和资产审查，形成美术规范，再并行制作武器与 Boss 资产，随后由编码成员集成和验证，最后由设计成员审阅游戏内效果。八个节点构成了一条包含并行分工、产物交接和最终检查的工作链。
图 8｜Godot 游戏资产制作与集成任务图。八个节点串联研究、制作、集成与检查。
在 THRESHOLD 完整游戏项目中，需求文档由人提供，Raven 自主运行约 4 天，经过 42 轮规划、开发与验证，使用 Godot 4 完成以竞技场 Boss 战为核心的第一人称射击游戏。最终交付包括可玩的游戏、海报、演示文稿和网站。
还有更多其他的案例：
七 用 Playbook 培养自己的数字伙伴
“对比三款 AI 编码产品，给我一份带来源的分析，再做成可以交互的看板。” 可以用这项需求说明数字伙伴的分工：市场分析员关注产品定位、用户与使用场景，技术研究员关注架构、集成与部署，两者并行整理带来源的结论，再由设计成员统一比较维度、制作看板并检查交付。
在这一配置示例中，同一个 Raven-Research 后端可以承担不同研究角色，角色差异体现在任务职责与输入要求上。Playbook 组织成员、节点与依赖，成员 Harness 则决定信息怎样进入上下文、模型可以使用哪些工具，以及行动需要通过哪些检查。
用户的知识、经验、SOP、工作习惯和判断标准，可以由此进入成员的工作方式。图 4 描绘的数字伙伴培养过程，也就有了可操作的含义：把要求落实到分工与策略，在实际使用中观察结果，再将反馈交给 Curator 继续调整。
图 9｜Agent 成员列表。统一呈现内置成员、第三方预设与连接状态。
这些积累由不同机制承接。用户可以从自然语言或已有文件生成并保存 Playbook，在 playbook.md 中保留成员、节点任务、依赖和输入安排，审阅后再次使用；EverOS 承接跨会话的上下文与经验；应用后的 Harness 调整，则成为对应 Agent 后续运行时采用的策略。
SkillForge 从本地技能库、EverOS 记忆和 SkillHub 目录中按需检索相关技能，为任务提供专业知识与操作方法。Proactivity 将事件监测与定时执行结合起来，支持在约定条件下发起任务。WebUI 提供统一入口，帮助用户选择成员、跟踪进度并检查交付。
图 10｜Raven WebUI 的任务发起界面，可输入需求并通过侧栏进入成员管理。
八 从一次交付走向持续成长
Raven V0.2.0 将专业协作与工作方式的持续调整连接起来，也迈出了让 RSI 从模型参数层延伸到 Harness 层的第一步：研究、编码、设计和实验成员围绕同一个目标工作，任务留下的上下文、技能与经验继续发挥作用，Curator 则把使用中的要求与反馈转化为具体的策略调整。
对用户来说，这一变化最终体现在具体的工作体验上：任务能否推进，结果能否交接，证据能否追溯，过去纠正过的问题能否影响后续的执行方式。一支有用的 Agent 团队，需要完成眼前的交付，也需要形成可以长期积累的工作方法。
对 Agent 开发者来说，可以从 Raven 直接获得以下能力：
1. 一个能接入现有 Agent 的上层编排器。Claude Code、Codex 等 Agent 可以通过 ACP、CLI 或 OpenAI 兼容 API 接入，保留各自的 Harness 与执行方式，由 Raven 负责成员选择、任务拆解、依赖调度与结果交接。
2. 可复用的任务图与 Playbook。复杂任务被拆成带依赖的 DAG，独立分支并行执行，前置任务失败时下游节点跳过、其他分支继续；跑通的流程可以保存为 playbook.md，经 raven playbook validate 校验后在类似需求中复用。
3. 四个可直接使用的专业 Agent。Raven-Research、Raven-Code、Raven-Design 与 Raven-Oncall 分别面向深度研究、编码与数据分析、设计交付和长时持续执行，既可以单独使用，也可以编入任务图协同工作。
4. 一套为 AI 修改而设计的 Harness 接口。Memory、Planning、Capability、Action 四个策略面，通过 home 文件、配置、钩子、插件与公共策略协议对外开放；开发者可以自己编写策略、工具与闸门，也可以交给 AI 改写，无需改动 Raven 的核心源码。
5. 一个可供研究的 Harness 自改进参考实现（实验性）。experimental/curator 中的 Curator 按理解、选择、设计、实现、修复分阶段生成改动，校验通过才安装；安装失败时，触发上一版本 Harness 及受管理内容的恢复流程。s0925c 案例附有完整的培养记录、每一轮的代码改动与复现命令。
6. 跨会话的记忆与技能。EverOS 保留跨会话的上下文与经验，SkillForge 按需从本地技能库、EverOS 记忆和 SkillHub 目录中检索技能，为任务补充专业知识与操作方法。
7. 可观测、可回放的执行过程。Tracing 默认开启，失败的执行轨迹可以导出、回放，并沉淀为确定性的回归测试。
Raven V0.2.0 已采用 Apache-2.0 许可证完全开源，欢迎大家前往 GitHub 体验、反馈并点亮 Star。10 月份，下一版 Raven 将以云端版本的形式上线 EverMe，届时大家可以直接在 EverMe 中使用 Raven。 欢迎提前注册体验 EverMe。
Raven GitHub：https://github.com/EverMind-AI/Raven
EverMe 注册体验：https://everme.evermind.ai/sign-in
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]
2026-09-27 17:34:00
把一本书放到书架，前面的动作并不复杂：找到空位，对准方向，向前推。真正的困难在接触发生时：书撞到旁边了吗？推的方向偏了吗？推到底了吗？在这种时候，视觉几乎没有任何变化，模型只能靠力来推断任务状态。
想学会力，离不开数据。但是力和真实机器人硬件强绑定，带力数据采集成本太高，也很难通过 UMI、ego 等方式规模化。
还有更棘手的问题：引入新模态会改变模型架构，是否需要重新预训练，又会不会让模型遗忘原有知识？
这些一直是纯视觉预训练 VLA 不得不面对的问题。
上海交通大学卢策吾、汶川团队联合穹彻提出 LIFT（Late Reactive Injection of Force for VLA Post-Training），在保留模型预训练知识的情况下，仅通过在线后训练教模型学会感知力，并通过力高频反应式生成动作。
这项工作被 CoRL 2026 高分收录，其核心贡献是走通了预训练学先验知识，后训练靠力学高频反应式操作的训练范式，为 VLA 解决感知模态稀缺的难题提供新的可行解。甚至不只是 VLA，对任何以 MoT 为基础架构的预训练模型，LIFT 所提出的方法在理论上都可以适用。相关代码已经开源。
论文标题：Never Too Late for Force: Accelerating VLA Post-Training with Reactive Force Injection
arxiv链接：https://arxiv.org/abs/2607.14236
项目主页：https://lift-policy.github.io/
代码链接：https://github.com/y-wng/lift
图1 LIFT方法总览。LIFT复用预训练动作专家参数，通过反应式力注入与在线纠正学习接触行为。
先看结果：力显著提升任务表现
团队在叠毛巾、插书和汉诺塔圆环放置三个任务上进行测试，LIFT 相比纯视觉后训练分数提升为：
叠毛巾：73.3 → 84.2；
插书：36.7 → 58.3；
汉诺塔圆环放置：26.7 → 56.7。
只需要 20~30 条带力的在线数据，就可以达到这样的效果。而且不仅是插书、汉诺塔放圆环这样的密集接触任务，像叠毛巾这类接触状态相对简单的任务，力依然可以提升其表现并加速这一过程。
想要用好力，LIFT 提出了必须解决的三个难点。
用好力，需要解决三个难点
及时响应接触：真正的接触过程中，瞬间的偏差，就有可能导致任务彻底失败。想用好力，模型必须一边感知，一边快速调整。
保留原有能力：力的加入，不能让预训练模型本来的空间理解、物体操作和场景泛化等能力崩溃，否则就是本末倒置，1+1反而小于1。
兼容异构数据：带力的数据采集成本高，数量极少。如果后训练不能兼容不带力的数据，就很难保证数据的多样性，最终过拟合。
围绕这三个难点，LIFT 提出了一套完整且系统的解决办法。
反应式注入力，完成控制闭环
图2 LIFT架构图。
LIFT 复制预训练动作专家参数，得到一个能根据力反馈及时调整动作的「反应式动作专家」。它通过因果交叉注意力感知最新一个时间段内的力，并据此高频反应式地调整动作；视觉和语言信息则提前计算并缓存，将控制闭环频率从 1Hz 显著提高到 10Hz。
对齐动作专家输出，保留预训练先验知识
图3 平移因果注意力掩码。
如图 3 所示，LIFT 使用平移因果注意力掩码。P 为视觉语言前缀，a 为基础动作 token，r 为反应式 token。①为 base 动作专家注意力，保持全自注意力。②确保反应式动作专家注意力因果性。③为平移注意力。通过权重复制，训练起始时 a=r。通过平移注意力，r 获得与 a 数值完全相同的上下文 token，进而对齐两个动作专家的输出。通过这种方式，LIFT 在数值层面保持预训练模型先验知识。
视觉数据和带力纠正混合训练
图4 LIFT训练管线。
LIFT 采用二阶段式训练。第一阶段，团队用 RoboPocket 采集不带力的纯视觉数据，让模型先学会目标任务；第二阶段，再把模型部署到机器人上，通过在线人工纠正，学习真实接触下的动作调整。在第二阶段，模型同时利用视觉数据和带力数据，对于不含力的纯视觉数据通过力掩码截断其梯度。
LIFT 的四个关键结论
图5 LIFT主要实验结果。横轴为在线采集到的10fps数据帧数，只使用人类干预部分数据训练和统计。每次在线实验2~3小时，采集20~30条数据。
仅靠后训练也能学会力
整个实验中，LIFT 没有用任何一条带力数据重新预训练。
团队证明了在后训练中注入力依然可以发挥力的优势，这是一条更加实际却足够吸引人的路线。
接触一变，动作要立马跟上
许多机器人策略会一次预测未来一段动作，形成一个动作块。这样的设计有利于动作连贯，却也带来一个问题：如果机器人在一个动作块执行途中时碰到阻碍，只能等到下一个动作块生成时再尝试调整。而在接触过程中，任务的成败往往是由一瞬间的精细调整决定的。
LIFT 反应式地注入力，使得策略可以在动作块内根据实时的力感知做高频调整。图 5 对比了 LIFT 与没有反应式力注入的基线，团队发现反应式地注入力对密集接触任务尤其重要。而在叠毛巾这类没有复杂接触的任务上，反应式地注入力相比于纯视觉策略，依然显著加速了任务表现的提升。
真实失误中才好学会力
力与视觉不同，轻微的位置变化就可能带来力分布的巨大漂移。而一旦力出现在数据分布外，模型可能就傻眼了。LIFT 在线地采集带力数据，让数据分布随着模型更新，极大地缓解了这一问题。图 5 对比了 LIFT 与离线采集带力数据的基线，证明了这一结论。
学会力，也能保留先验知识
图7 桌布、物体和光照改变的条件。
后训练加入力，有没有让模型忘记预训练知识？团队发现经过后训练，模型同时保留了力的知识和泛化能力，在桌布、光照甚至操作物体变化后任务表现并没有出现显著下降。
结语：学会力，为时不晚
LIFT 展示了一条面向现有预训练模型的后训练路径：先利用大规模预训练建立任务先验知识，积累空间理解能力，再用少量真机带力纠正补上接触细节；在模型侧，通过复制动作专家、平移因果注意力和零初始化交叉注意力，让新增模态从原有能力出发；在数据侧，通过在线后训练，让数据覆盖策略自身真正遇到的接触状态。
正如论文标题所说，对力而言一直都不晚。
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]
2026-09-27 11:03:00
9 月 21 日，OpenAI 扔出一则公告：一款 8 月 28 日才开始训练的内部模型，已经攻克了 100 多道世界级数学难题，范围横跨数学的大部分领域。
可以说，数学圈的情绪，在这半个月里一路往下沉。读博的担心学位贬值，教书的担心期刊崩盘，写了半辈子证明的人开始怀疑，这门手艺还剩几年。
就在这片低气压中间，多伦多大学数学家 Daniel Litt 在个人博客上发了一篇长文，标题叫《A beginning for mathematics》—— 数学的开端。
这个标题多少带点自我纠正的意味。几周前，Litt 刚做过一次名为《The End of Mathematics》的演讲，讨论 AI 可能如何冲击数学研究。新文章里，他给出了一个明显更积极的版本。
Litt 直接接受一个很激进的前提：能够在大部分数学任务上稳定超过人类的 AI，可能很快就会出现。
他真正想讨论的是，到了那一天，数学这门职业该怎么改，学生还该怎么培养，人类数学家又该把精力放在哪里。
他的结论其实很乐观：AI 可以让高质量数学越来越不依赖人类亲手生产，但人类对数学的理解，反而可以变得更深。
如果一只猴子也能「证明定理」，
那我们到底在追求什么？
Litt 在文章开头先摆了一组时间线：三年前，AI 连两个数相加都经常算错；一年前，OpenAI 和 DeepMind 的内部模型拿到了 IMO 金牌水平的成绩；现在，这些系统开始自主解决重要的公开问题。
然后他戳破了一层窗户纸：数学共同体对「我们的目标是什么」根本没有共识。
有人搞数学是为了解题，有人觉得数学是游戏、是诗；有人信奉希尔伯特那句「我们必须知道，我们终将知道」，有人觉得在勘探柏拉图世界的奥秘，还有人认为这份工作的意义在于把对数学的热爱传给下一代。这个群体其实从来没有一个统一答案。
Litt 自己把目标压缩成两条。一是生产并理解高质量的数学；二是培养高质量的数学家。这里的「高质量」并没有固定定义，它一直由数学共同体自己慢慢形成。
问题是，过去很长时间里，数学界用来实现这两个目标的办法都差不多：证明定理。论文要有主定理，博士论文要有主定理，解决一个扛住了多年猛攻的公开猜想更是头等大功。
但 Litt 认为，这个评价方式其实漏掉了关键的一层。
他举了一个很荒诞、却非常直观的例子：假设给一台计算机或一只猴子一套 ZFC 公理，再让它不断机械地应用推理规则，它其实也可以源源不断地产生定理。
猴子当然只是比喻。重点是，只要完全不在意这些定理讲了什么，只追求「逻辑上成立」，整个过程本来就不难自动化。
开放问题也可以这么干。让这只猴子把所有可能的数学命题按顺序枚举出来，再一个个尝试证明，总有一天，它也会撞上一些今天人类正在研究的问题。
这当然荒谬。但整个共同体面对「会证定理的机器」时的警惕，恰恰说明数学真正看重的，从来不只有「这个命题被证明了」。
接着他把实验升级：假设这只猴子极其聪明，理解自己证的东西，阐述写得漂亮，知道我们觉得什么有趣，顺手解决了一批悬案，还能提出更多根本性的新问题。到这一步，人类数学家还有存在的必要吗？
Litt 的答案是有。机器确实能生产我们想要的答案，但它生产不了人对答案的理解。他的判断是：我们可能正站在一次数学大爆炸的前夜。模型会产生比现在多得多的新结果，但只要我们还在意「人类到底理解了多少数学」，数学家就不会因此变得多余，甚至可能更忙。
真正该保住的，
不一定是期刊、论文和今天这套制度
顺着这个判断往下，Litt 开始区分两件事：数学本身的价值，和今天学术数学的制度形态，不是一回事。
他真正希望保留下来的，是学习讨论班，是数学家之间偶然碰出来的新想法，是学生敲开老师办公室讨论一道题，也是很多人花时间一起把一个原本没人弄懂的问题慢慢想明白。
期刊、同行评审、arXiv、论文署名这些今天很重要的东西，则未必要一成不变。
Litt 甚至觉得，数学界现在有点太执着于「怎么保护旧制度」：怎么保住期刊体系，怎么防止 arXiv 被 AI 论文淹没，怎么继续维持数学家作为知识守门人的角色。
如果一个现成模型花几美元，就能产出相当不错的新数学，那么指望现在这套平衡几乎原封不动地延续下去，本身就不现实。
这里还有一个很容易掉进去的坑。既然 AI 现在还不太会搭理论、不太会提出真正好的问题，那数学家是不是应该赶紧把这些能力变成新的评价标准？
Litt 并不赞成。原因很简单：学术制度变化得太慢，模型能力升级得太快。
今天刚决定「以后重点奖励会提问题的人」，几个月后模型可能也已经很会提问题了。与其一直追着模型当前的短板跑，不如直接考虑终局：假设 AI 最后真的把绝大多数数学能力都补齐了，我们还想保留什么？
数学博士最该证明的，
也许不再是「我写出了一篇论文」
接下来，Litt 把问题转向教育。
在他看来，现在最紧迫的事情其实不是教授以后怎么研究，而是：学生还应该做什么？
过去博士论文承担了两个作用。它既贡献新的数学结果，也同时向外界发出一个信号：这个学生确实掌握了这些数学。
然而，AI 让第二个功能开始失效。一个学生现在理论上完全可以交出一篇自己都没有完整读过的博士论文。文本本身可能很漂亮，里面甚至有真正的新结果，但它已经无法可靠说明作者本人到底懂了多少。
所以 Litt 提议，把两件事分开：数学进展是数学进展，数学能力是数学能力。
未来数学博士的目标，可以重新定义成：成为某个重要而深刻问题上的真正专家，并且有能力把自己的理解传达给别人。
论文当然还可以存在，但学位是否授予，可以更多依赖一次真正严格的答辩。你得能把问题讲清楚，能应对专家不断追问，能处理陌生例子，也能把某种方法迁移到新的情况里。研究结果是不是最初由 AI 找到，反而没那么关键。
也就是说，学生完全可以用 AI，但最后必须自己懂。
这也意味着，很多看起来很传统的评价方式可能重新升值。论文越来越容易生成以后，一场报告、一次长时间讨论、一次面对面的数学追问，反而更能判断一个人到底有没有形成真正的理解。
被低估了很久的能力：
知道什么问题值得问
再往下推一步，Litt 发现数学共同体还有一项长期被低估的工作：筛选什么数学值得研究。
今天 AI 之所以能拿各种开放问题练手，是因为前面已经有一群人类数学家替它做过筛选。
某个猜想之所以会成为「开放问题」，通常意味着已经有很多人认为它有价值，也愿意围着它花几年时间。换句话说，这些问题天然带着数学共同体长期积累出来的一层背书。所以，AI 看起来是在自主解题，但它眼前很多「好题」，其实都是人类提前挑出来的。
Litt 觉得，这项能力过去得到的奖励远远不够。未来甚至可以更明确地奖励那些能搭建研究纲领的人：他提出一组好问题，构建一个值得长期推进的方向，还能说服其他研究者「这里值得挖」。
当然，他也没觉得这件事永远只能由人完成。AI 大概率也会越来越会提问题、做猜想、设计研究计划，最后很可能产出海量 PDF。
当 PDF 多到看不完，
数学真正的瓶颈开始浮现
接下来，Litt 提出了另一个问题：怎样继续生产高质量数学。
Litt 的态度其实很激进。他觉得已经没必要幻想阻止人们「按一个按钮生产数学」。你不可能让所有业余爱好者和研究人员都不用 AI，也不可能把一批题圈出来，说这些必须留给博士生手算。更重要的是，他也不觉得应该这么干。
公众现在对数学的兴趣可能比历史上任何时候都更高，这本身就是好事。真正的问题是，当大量新数学出现以后，有没有足够多的人真正理解它。
Litt 用了一个很有意思的说法：如果一个猜想倒在森林里，却没有人听见，那又有什么关系？
模型自己提出了一个漂亮猜想，再自己证明出来，如果世界上没有任何人真正理解它、关心它，那么它在纯数学里的价值其实很有限。所以数学内容越丰富，反而越需要更多数学家。
即使一些结果有直接应用，也仍然需要有人能看懂它们使用了什么假设，结论能推到哪里，在哪些情况下会失效。
数学生产力提升，并没有消灭理解成本，它只是把这个瓶颈暴露得更明显了。
数学第一次可以「氪金」了
数学以前可能是最便宜的科学，因为做数学不需要粒子对撞机，不需要湿实验室。很多时候，一个人、一块黑板就可以开始。
AI 出现以后，一部分数学问题第一次变成了可以通过「注入现金」解决的问题。多买算力，多烧 Token，多跑几轮推理，就可能拿到结果。
有些数学家对此很失落。因为过去，一个难题悬在那里，可能会把一群人聚起来。大家为了绕过它，会发展辅助理论、创造新工具，甚至意外找到比原问题更重要的东西。现在，如果模型直接把答案吐出来，中间很多「绕路」可能不会再发生。
Litt 承认，这种损失是真实的。但他的反应很干脆：如果一道基础数学问题，花一顿不错的晚餐的钱就能解决，那应该高兴。
因为答案出来以后，事情远远没有结束。接下来还得继续问：这个答案解释了什么？它让我们理解了什么？为什么会这样？还能推广到哪里？它又带来了哪些新的问题？
其中一些问题，可能再次被 AI 用一顿晚餐的钱解决；另一些问题则会重新让所有人陷入困惑，然后围绕这种困惑，新的数学共同体又长出来。
最后那一步，AI 真的没法替你走
Litt 最后把镜头拉回了一个很普通的场景。一个学生碰到一个问题，没想明白，于是去敲教授办公室的门。两个人可以问 AI，也可以不问，也许他们会先站在黑板前自己推一阵。模型后来可能给出一个非常漂亮的解释。但事情到这里仍然没有结束，因为 「看到一个解释」和「自己理解它」之间，还有一步。这一步没人能替你完成。
AI 会不会越来越强？Litt 基本默认会。AI 会不会解决大量今天看起来很困难的问题？他也认为会。很多今天的论文、博士培养、人才评价方式会不会因此过时？大概率也会。
但数学不会因此被「做完」。答案越来越容易获得以后，我们还是会追问它意味着什么；一个困惑解决之后，又会冒出更多困惑。
Litt 最后写道：还有太多东西等着我们学习 —— 无穷无尽。
所以，我们其实一直都站在数学的起点。以后也会如此。
参考链接：
https://proofsandprompts.com/2026/09/14/a-beginning-for-mathematics/
© THE END
转载请联系本公众号获得授权
投稿或寻求报道：[email protected]
