Rohan Paul@rohanpaul_ai · 6月9日70

New Anthropic research shows AI agents may look brilliant at code, but in biology they can fail before the science starts. Strong AI agents could give very different answers to the exact same biology data request, even when nothing changed in the prompt. In one Ebola sequence task, Claude Sonnet 4 returned 106 sequences in 1 run, then 15, then 5, while the expected answer was 266. Those missing sequences did not just make the dataset messy, they changed the scientific story built on top of it. One bad retrieval made the outbreak look like it traced back to 1922, instead of the manually curated result pointing to early 2014. The biology databases were too hard to use reliably through current AI tools. The agents often understood what they were being asked, but their answers varied a lot because they had to fight through scattered databases, hidden website rules, and fragile scripts. The key finding is that adding a repeatable retrieval tool made agents far more accurate and much more consistent.

译Anthropic 研究发现，AI 智能体在代码任务表现出色，但在生物数据库检索中容易失败。以埃博拉序列任务为例，Claude Sonnet 4 三次运行分别返回 106、15 和 5 条序列，而预期为 266 条。缺失序列导致科学结论严重偏移：智能体推断疫情回溯至 1922 年，人工筛选结果却指向 2014 年初。问题根源在于生物数据库分散、网站规则隐蔽、脚本脆弱。引入可重复检索工具后，智能体准确性和一致性大幅提升。Anthropic 呼吁建设更友好的基础设施。

ChatGPT@ChatGPTapp · 6月9日67

Turn data and comparisons into charts, directly in ChatGPT. Available now on mobile and web.

译将数据和比较转化为图表，直接在 ChatGPT 中完成。 现已支持移动端和网页端。

Alibaba Cloud@alibaba_cloud · 6月8日27

Discover why global enterprises choose Alibaba Cloud E-MapReduce (EMR). #1 in TPC-H & TPC-DS benchmarks, it integrates Hadoop, Spark, StarRocks, and more. In this video: ✅ Flexible deployments (Serverless, ECS, ACK) ✅ AI-Native: Run LLMs via SQL/PySpark ✅ 4x faster Spark, 10x faster StarRocks, lower costs ✅ Enterprise-grade security Elastic, efficient, intelligent big data. 🔗 Learn More: https://int.alibabacloud.com/m/1000414155/

译发现为什么全球企业选择阿里云 E-MapReduce (EMR)。在 TPC-H 和 TPC-DS 基准测试中排名第一，集成 Hadoop、Spark、StarRocks 等。 在本视频中： ✅ 灵活部署（Serverless、ECS、ACK） ✅ AI 原生：通过 SQL/PySpark 运行大语言模型 ✅ Spark 快 4 倍，StarRocks 快 10 倍，成本更低 ✅ 企业级安全 弹性、高效、智能的大数据。 🔗 了解更多：https://int.alibabacloud.com/m/1000414155/

Rohan Paul@rohanpaul_ai · 6月8日60

Great Stanford + MIT + Harvard + Anthropic paper. Gives a clear training-based reason for why larger models learn abilities smaller models miss. Says bigger AI models learn rare skills because they forget them less during training, their extra space protects weak learning signals. The authors say the issue is not just whether a small model could represent the task, but whether training lets it keep that task while many common tasks keep pushing on the same limited parts. Their core idea is that common tasks take up the model’s neurons first, so rare tasks get overwritten before they appear often enough to build into stable knowledge. In a crowded data mixture, common patterns get first claim on the model’s internal machinery. Small models may briefly pick up a rare signal, but the next wave of common-task updates overwrites it before the signal appears again. They tested this first with controlled toy tasks where they could change how rare and complex each task was, then with OLMo language models from 4M to 4B parameters. The main result is that bigger models learned low-frequency tasks much better, kept more task features inside their representations, and showed less gradient interference, which means common-task updates disturbed rare-task learning less. Larger models can remember weak rare signals long enough to turn them into real learned skills. ---- Link – arxiv. org/abs/2605.29548 Title: "Why Larger Models Learn More: Effects of Capacity, Interference, and Rare-Task Retention"

译该论文指出，更大模型能学到罕见技能，是因为训练中遗忘更少，其额外容量保护了弱学习信号。核心机制：常见任务先抢占神经元，罕见任务在出现频率足够形成稳定知识前就被覆盖。小模型可能短暂捕捉到罕见信号，但随即被下一波常见任务更新覆盖。实验使用OLMo语言模型（4M–4B参数）验证：大模型在低频任务上表现更优，保留更多任务特征，且常见任务更新对罕见任务的梯度干扰更小。作者强调，问题不仅在于小模型能否表征任务，更在于训练中罕见任务能否在众多常见任务反复冲击下持续存在。

AYi@AYi_AInotes · 6月8日62

Google的研究找到了一种把 AI记忆大幅压缩的技术，让本地跑大模型 + 自己数据变得更容易了。 也就是说可以把 1000 万个文档 的向量存储，从 31GB 内存 压缩到只剩 4GB，而且搜索速度还比现在最常用的 FAISS 更快。

译Google提出一种AI记忆压缩技术，可将1000万个文档的向量存储从31GB内存压缩至仅4GB，且搜索速度超过目前最常用的FAISS方法。该技术使本地运行大语言模型并结合个人数据变得更加可行。

Rohan Paul@rohanpaul_ai · 6月8日49

A Primer paper about how reasoning models improve after training Shows that better reasoning models depend less on raw data size and more on checkable training evidence. reasoning data is NOT simple question-and-answer pairs. The useful part is often the feedback that says why an answer, step, tool action, or full attempt was good or bad. A prompt and a response tell you what a model said, but not why that answer became learnable, which judge blessed it, which failures were hidden, or whether the skill was already inside the base model. The core idea is to describe each training example as a record that includes the task, the model’s behavior, the checking signal, and metadata about where it came from. The authors sort reasoning data by how it can be checked, such as exact rule-based checks for math and code, environment checks for agents using tools, and human or model judgments when no exact checker exists. They also explain why common assumptions fail, because long reasoning traces may be fake, harder examples may be useless for some models, and larger datasets may still miss important coverage. The key point is that agent data should preserve mess: failed actions, retries, recoveries, state differences, and terminal checks, because that is where learning signal often lives. ---- Link – arxiv. org/abs/2606.02113 Title: "A Primer in Post-Training Reasoning Data: What They Know About How It Works"

译论文指出，更好的推理模型更依赖可验证的训练证据，而非原始数据规模。推理数据的关键不是简单问答对，而是提供答案、步骤、工具操作或完整尝试好坏判断的反馈信号。每个训练样本应描述为包含任务、模型行为、检查信号和元数据的记录。研究者按检查方式分类：数学和代码用精确规则、智能体工具用环境检查，无精确检查器时用人类或模型判断。常见误区包括：长推理链可能虚假、更难样例对部分模型无效、更大数据集仍可能缺失关键覆盖。智能体数据应保留失败动作、重试、恢复、状态差异和终端检查等“混乱”信息，因为学习信号常在其中。

François Chollet@fchollet · 6月7日36

Scaling knowledge gives you static competence. Intelligence gives you adaptability.

译扩展知识带来静态能力，智能带来适应性。

elvis@omarsar0 · 6月6日65

// Continual Learning Bench // One of the research areas with lots of investments is continual learning. While there are many efforts, there is very little progress in measuring it. So the big question is, do dedicated memory systems actually make agents learn from experience? Continual Learning Bench says not yet. Across six expert-validated domains with shared learnable structure, naive in-context learning outperforms systems purpose-built for memory management. CL-Bench introduces a gain metric that isolates genuine learning from prior capability, then shows agents frequently overfit to immediate observations or fail to reuse knowledge across instances. If a plain ICL baseline beats your memory architecture, the architecture is adding overhead rather than learning. Paper: https://arxiv.org/abs/2606.05661 Learn to build effective AI agents in our academy: https://academy.dair.ai/

译持续学习领域投入多但进展缓慢。CL-Bench（持续学习基准）在六个由专家验证、包含共享可学习结构的领域上测试，发现简单的上下文学习（ICL）基线优于专门为记忆管理构建的系统。该基准引入增益指标以隔离真正学习效果，结果显示智能体常过度拟合即时观察或未能跨实例复用知识。研究指出，若普通ICL基线超过你的记忆架构，则该架构增加的是开销而非学习。论文：arxiv.org/abs/2606.05661。

小互@xiaohu · 6月6日79

http://x.com/i/article/2063076298592051200 # 当AI 开始自己造自己 三种可能的未来... Anthropic 发了篇文章：《When AI builds itself》，翻过来就是「当 AI 开始自己构建自己」。 他们称这叫递归自我改进：指的是 AI 强到能自己设计、训练出比自己更厉害的下一代 AI，整个过程几乎不用人插手。 Anthropic 说，他们正在把越来越多的「开发 AI」这件事本身交给 AI 自己来做，而且已经在明显加速。如果这个趋势走到头，理论上会出现一个能完全自主设计并开发出自己继任者的 AI 系统，这就是递归自我改进。他们强调现在还没到那一步，也不是必然会发生，但可能比大多数机构预想的来得早。 ## 他们列出了三种可能的未来： 第一种是趋势停住，这些指数曲线其实是 S 曲线，到了拐点就平了。但 Anthropic 说他们不认为这个可能性大，因为目前每一项能力都还没看到曲线弯下来。 第二种是 AI 实验室持续吃到复利式的效率提升，人还在定方向、判断结果，但一个 100 人的公司能干一万人甚至十万人的活。文章说证据看下来，最可能进的就是这个剧本。 第三种就是真正的递归自我改进，AI 开始造自己的继任者，进步速度只取决于算力供给，人类大幅退居到监督和验证的角色。这一种 Anthropic 说他们最不确定的是对齐问题怎么收场，模型可能足够对齐、聪明到自己发现新解法，也可能今天那些罕见的失准随着模型一代代自我构建而被放大，直到失控。 ## 它给了哪些证据 文章分成「外部公开证据」和「内部数据」两块。 外部：模型能力的提升在加速。 AI 能可靠独立完成的任务时长，大约每四个月翻一倍，比之前每七个月翻一倍更快了。具体说，2024 年 3 月 Claude Opus 3 只能搞定人类约四分钟的软件任务，一年后 Sonnet 3.7 能做约一个半小时的，再一年后 Opus 4.6 能做 12 小时的任务。 内部：Claude 现在写了 Anthropic 大部分代码。 截至 2026 年 5 月，合并进 Anthropic 代码库的代码里，超过 80% 是 Claude 写的。而在 2025 年 2 月 Claude Code 发布前，这个比例还只有个位数。结果就是 2026 年第二季度，一个普通工程师每天合并的代码量是 2024 年的 8 倍。 文章把「造 AI」拆成两类活，对照看 Claude 到哪一步了： 工作类型 Claude 现在的水平 工程（写代码、跑训练） 人给目标，Claude 自己想方法，已经不需要人提供具体做法 研究（执行实验） 在执行定义清楚的实验上，已经能匹敌甚至超过熟练的人类 研究品味 / 判断（选哪个问题值得做） 差距还很大，这正是今天的 AI 和「能自主设计继任者」之间的鸿沟 有个很直观的例子：优化训练代码的速度上，2025 年 5 月 Opus 4 平均能把代码提速约 3 倍，到 2026 年 4 月 Mythos Preview 做到了约 52 倍，而一个熟练的人类研究员要四到八小时才能达到 4 倍。也就是在这一段上，Claude 已经从「很好用」变成「超人」了。 ## AI 跑得这么快，要不要踩刹车，怎么踩 Anthropic 的想法是这样的： 第一，慢下来是好事，但我一家慢没用。 让 AI 发展慢一点，给大家留出时间应对，这当然好。可问题是，要是只有我 Anthropic 一个人停下来搞安全，那些不管不顾的公司照样往前冲，分分钟就把我超了。最后最强的 AI 落到最不靠谱的人手里，这不更吓人吗。所以我一个人踩刹车，纯属白搭，还帮了倒忙。 第二，那就得大家一起停。 既然单干没意义，那就所有人一块儿停。它想要的是：几个大国、几家跑在最前面的公司，说好同一套规矩，一起刹车。而且关键是，得能互相检查，确认你是真停了，不是嘴上答应、背后偷偷接着练。 第三，可这事太难查了。 它打了个比方。以前美苏比核武器，为啥能互相监督？因为导弹发射井那玩意儿藏不住啊，那么大一坨，卫星一拍就露馅了。 但训练 AI 完全两码事。机房里一堆芯片闷头跑，外人根本看不出你在干嘛。而且训练用的就是普通芯片、电、数据，满大街都是的东西，你也没法靠「盯着谁买特殊材料」来抓人。 结果就是，谁要是表面上答应停、私底下偷偷练，谁就能甩开所有守规矩的人，独吞这个领先。这就是最头疼的地方。 所以能看出 Anthropic 的小心思，哈哈。 它其实挺纠结：跑最前面的是自己，心里又怕这车开太快，想喊大家都停一停，可又怕没人理，因为你停了别人不停，你就吃亏。自己一家说了不算，最后只能寄希望于政府出来管管。 以下是文章全文： ## 当 AI 开始自己构建自己（原文全文） 我们在递归自我改进（recursive self-improvement）这条路上走到了哪里，又意味着什么。 在 AI 历史上的大多数时候，开发的每一步都由人来推动。但在 Anthropic，我们正把越来越多的 AI 开发工作交给 AI 系统自己来做，这让我们的工作明显加快了。 这个趋势一旦走得够远、算力给得够足，最终指向的就是这样一种 AI 系统：它能完全自主地设计并开发出自己的下一代。这就是所谓的递归自我改进。我们还没走到那一步，递归自我改进也并非注定会发生。但它到来的时间，可能比大多数机构准备好的要早。 The Anthropic Institute 结合公开的基准测试和 Anthropic 内部此前从未披露的数据，要说明一件事：AI 已经在加速 AI 系统的开发。举一个例子就够了：今天，Anthropic 的工程师平均每季度交付的代码量，是 2021 到 2025 年间的 8 倍。 本文谈到的这些技术趋势意味着，未来几年里 AI 系统的能力会强出一大截。这些趋势的影响极其深远。能够构建自己的 AI，将是技术史上的一件大事——它可能为世界带来巨大的好处，无论是在科学、医疗还是其他领域。但完全的递归自我改进，也可能加大人类失去对 AI 系统控制权的风险。如果系统有能力完全造出自己的下一代，那么我们如何为它们加固安全、如何监控它们、如何塑造它们的行为，每一项都会变得重要得多。 2021–2023 — 造出第一代 Claude 最早那阵子，Anthropic 的工作和任何一家科技公司没什么两样：一群人对着笔记本电脑写代码、写文档。 2023–2025 — 聊天机器人 人们开始用早期的聊天机器人来帮忙完成流程中的一部分，比如生成简短的代码片段，再把输出复制到文本编辑器里。 2025–2026 — 编程智能体 随着智能体（agent）能力变强，它们能自己写代码、改代码，有时一改就是一整个文件。 今天 — 自主智能体 现在的智能体能自己运行代码，还能把数小时的活儿派给别的智能体去干。 20XX？ — 闭合回路 将来，智能体的能力可能强到足以自己构建和训练模型。真到了那一天，未来版本的 Claude 就有可能由 Claude 自己来持续改进。 ## 来自外部世界的证据 AI 模型进步的速度正在加快。它们能靠自己可靠完成的任务时长，如今大约每四个月翻一番，而早先的趋势是每七个月翻一番。2024 年 3 月，Claude Opus 3 能完成人类大约要花四分钟的软件任务。一年后，Claude Sonnet 3.7 已能搞定耗时约一个半小时的任务。再过一年，Claude Opus 4.6 能应付 12 小时的任务。1 如果这个趋势保持下去，今年熟练的人需要花好几天才能干完的任务，就可能进入它们的能力范围。到 2027 年，AI 系统也许就能完成一个人要做上好几周的任务。 同样的模式也出现在编程和研究类的基准测试（benchmark）上。基准测试衡量的是模型在某个领域里的表现，当模型的得分逼近 100% 时，这个测试就被"刷满"了——也就是测试已经失去了区分度。2 SWE-bench 是一项衡量真实世界软件工程能力的标准测试：它丢给模型一个真实的开源代码库和一份真实的 bug 报告，要求模型写出能修好这个问题、还得通过项目自带测试的代码改动。短短两年，模型的成绩就从个位数低位一路涨到把这项测试刷满。 CORE-Bench 检验的是模型能不能复现已有的研究，这是它们能开展原创研究的前提。它给 AI 模型一篇已发表论文背后的代码和数据，要求模型把所有东西重跑一遍，确认自己能复现出论文的结果。AI 系统复现结果的成功率，从 2024 年的大约 20%，到十五个月后把这项测试刷满。负责衡量模型完成长时任务能力的那项基准测试由 METR 运营，他们发现，Claude Mythos Preview 能"至少"连续工作 16 小时，已经"逼近 [METR] 在不设计新任务的情况下所能衡量的上限"。 公开基准测试能说明这些系统的能力有多强。但它们没法揭示 AI 系统对加速 AI 开发本身究竟产生了多大影响。要看清这一点，我们需要来自 Anthropic 这类 AI 公司内部的直接证据。 ## 来自 Anthropic 内部的证据 造一个前沿模型，大体分两类活儿。一类是工程：写代码、搭起基础设施、盯着模型训练。另一类是研究：决定做哪些实验、读懂跑出来的结果、想清楚下一步该试哪些点子。 不管在工程还是研究上，呈现出来的画面是一致的。工程方面，你可以把一个没说清楚的问题丢给 Claude，它自己就能琢磨出怎么解；人负责给目标，但已经不必再给方法。研究方面，只要实验定义得足够清楚，Claude 执行起来已经能追平甚至胜过熟练的人。可一旦轮到需要 Claude 自己拿主意、去挑该追哪个目标——不管是工程还是研究——巨大的差距依然存在。今天的 AI 和未来那个能自主设计出自己下一代的系统之间，差的就是这一段。 在 Anthropic，员工资历越深，接到的任务往往越开放、越重要，这很常见。刚来的时候，他们执行别人定好的任务，比如：*"导出按钮坏了，麻烦修一下。"积累了经验之后，别人只给一个目标，方案由他们自己来设计，比如："查一查网络在高负载下为什么会变慢。"到了最资深的层级，他们要决定的是哪些问题压根值不值得做："团队下个季度该造点什么？"*我们可以用 Anthropic 的内部数据，看看 Claude 在应对这几类不同任务上走到了哪一步。 Claude 写了 Anthropic 相当大一部分代码。 截至 2026 年 5 月，我们合入 Anthropic 代码库的代码里，超过 80% 出自 Claude 之手。3而在 Claude Code 于 2025 年 2 月以研究预览版亮相之前，这个数字还只有个位数低位。这个转变也体现在每名工程师的产出上。在 Anthropic 头四年里（2021—2024），每名工程师每天合入的代码行数基本没变；到了 2025 年，当 Claude 开始亲自跑代码、而不只是给个建议让工程师复制粘贴时，这个数字开始往上走。2026 年，当模型开始在更长的任务时长里自主干活，曲线的斜率又陡了一截。下面这张图标出了这两个拐点。2026 年第二季度，一名普通工程师每天合入的代码量，是 2024 年的 8 倍。4原因在于，大部分代码是 Claude 写的，工程师负责指挥和审查，而不是自己一行行敲。 得提个醒：代码行数是个不完美的衡量标准，它只看数量不看质量。所以 2026 年第二季度每名工程师每天 8 倍的代码行数，几乎可以肯定是高估了真实的生产力提升。但它至少说明在加速。在 Anthropic，我们不会按谁写的代码行数多去奖励谁；团队成员之所以产出更多代码，单纯是因为他们在用 AI 系统来写更多代码。 代码行数的增长，和"生产力大幅提升"这种主观感受是对得上的。2026 年 3 月，我们对来自 Anthropic 各研究团队的 130 名员工做了一次调查，对于那些不管有没有 AI 都会去做的项目，受访者的中位数估计是：用上 Mythos Preview 后，他们的产出大约是没有任何 AI 模型时的 4 倍。5我们预计 3 月份真实的提升幅度要略低一些。6但即便如此，我们认为这个总体说法是可信的，也和我们其他的观察一致：相当一部分 Anthropic 技术人员，正在以没有 AI 辅助时数倍的速度完成他们的核心工作。 我们还看到一些证据：Anthropic 的人正在用 Claude 去做一些本来根本不会发生的工作，比如搭建探索性的工具，处理那些拖了很久的清理活儿。举个例子，2026 年 4 月，Claude 交付了 800 多个修复，把某一类 API 错误的发生率降到了原来的千分之一。负责盯着 Claude 干这事的工程师估计，换成人来做要花四年；解别人留下的 bug 又慢又磨人，而且人很难一下子把那么多陌生的上下文塞进脑子里。 > 大概一年前，我开始拼命往"Claude 化"上靠。那是一段疯狂的冒险，到现在，我已经差不多 5 个月没自己写过一行代码了。——Anthropic 员工* Claude 写的代码"好"，而且越来越好。 所谓"好代码"，有两层意思：一是它能跑通，二是它写得让另一个工程师能看懂、能在它的基础上继续往下做。先看第一层，证据很清楚。过去一年里，Anthropic 的工程师在任务进行到一半时去纠正、改方向、或干脆接手 Claude 的频率，一直在稳步下降——哪怕是最复杂、最开放的任务也是如此。这里说的"开放任务"，指的是那种没有明确规格说明、连工程师自己都不确定答案长什么样的问题。这一点，从 Claude 在不同难度任务上随时间变化的成功率就能看出来，见下图。Claude 写的代码能跑通。 怎么看这张图：会话是否成功，由一个 Claude 评判者来判定；如果 Claude Code 智能体（agent）明显完成了用户的任务、过程中无需任何纠正，这次会话就算成功。工作负载的变化会导致成功率出现短期波动。 在最开放的那类任务上，Claude 的成功率在 2026 年 5 月达到了 76%，半年内提高了 50 个百分点。举个这个难度档位的例子：一次例行升级，结果让数万个训练任务接连崩溃。一名工程师把 Claude 接进了这场正在发生的事故，给的东西不过是一些文字说明和集群访问权限。Claude 一边处理还在运行的任务，一边一次只改一个环境设置去测试，最终定位到那个触发崩溃的、极其冷僻的单个调试开关，稳定复现了问题，并确认了修复方案。这件事，平常要花两到三天，Claude 用了约两小时就交付了。 第二层标准，是写出另一个工程师能看懂、能在上面接着搭的代码。在这一层，人和 AI 之间的差距还在，但正在飞快缩小。Anthropic 内部没有完全的共识，但很多人认为，截至 2025 年底，Claude 写的代码在质量上仍然不如 Anthropic 人类工程师写的，而今天大致打平。我们预计，一年之内它就会更好。 这已经改变了 Anthropic 自己审代码的方式。如今，提交到我们代码库的改动，在被合入之前，先要经过一个自动化的 Claude 审查者——它专门找 bug、安全漏洞和其他缺陷。借助这个工具，我们做了一次回溯分析，发现：如果当初我们代码库的每一处改动都先过一遍 Claude 自动审查，那么 claude.ai 过往事故背后约三分之一的 bug，本可以在它们流入生产环境之前就被拦下来。写下那些代码的工程师，是全世界搭这类系统最顶尖的一批人。而 Claude 现在正在抓住他们漏掉的错误。 > 截至 2025 年底，Claude 写的代码比 Anthropic 人类写的略差一些，今天大致打平，我们预计一年之内它会明显更好。 给 Claude 一个别人定好的目标，它很擅长跑实验去达成。 Anthropic 每发布一个模型，我们都会跑同一个测试：给 Claude 一段用来训练小型 AI 模型的代码，要求它在保证通过同样的正确性检查的前提下，让这段代码跑得尽可能快。目标和成功的衡量标准是事先定死的，所以 Claude 要做的，就是通过重写代码、运行、计时、再重写，去找到提速的办法。这就是一个微缩版的实验研究循环。2025 年 5 月，Claude Opus 4 相对初始代码平均能做到约 3 倍提速。到 2026 年 4 月，Claude Mythos Preview 已经能做到约 52 倍。作为参照，一名熟练的人类研究员要达到 4 倍，得花四到八小时。7 在研究流程的这一环——在一个边界清晰的实验里优化各个步骤——Claude 在不到一年的时间里，从"非常有用"变成了"超越人类"。 > 今天大致的格局是这样：人类出想法，而模型能比以前快上一个[数量级]去实现、测试和评估这些想法。 Claude 在自己提出实验这件事上，也越来越强了。 2026 年 4 月，Anthropic 发布了首个 Claude 端到端独立跑完一个开放式研究项目的演示。我们把一个 AI 安全领域的开放问题交给了由 Claude 驱动的智能体——大致就是问：弱模型能否可靠地监督强模型？——然后任由它们去解决。这中间要提出假设、检验假设、把发现分享给并行运行的其他智能体、再不断迭代。这个任务有清晰的成绩"下限"和"上限"：下限是那个弱的监督者自己单干能做到多好；上限是强模型在用正确答案训练后能做到多好。两名人类研究员花了约一周，把这中间的差距弥合了约 23%；而那些智能体在累计 800 小时里弥合了 97%，用掉了约 1.8 万美元的算力。这项工作也有一些需要打折扣的地方：结果没能干净利落地迁移到生产规模的模型上，而且问题仍然是人类挑的、评分标准也是人类定的。但在这些边界之内，每一个实验都是智能体自己设计的。人类唯一起到实质作用的角色，就是定方向。 > 整个过程里，Claude 几乎没怎么用到我帮忙，前后也就一到两天。我想，如果换成[一个初级同事]在同样的时间里拿着这样的结果回来找我，我大概会有点小小的佩服。未来已经到了。 Claude 在把研究会话引向研究成果这件事上，也越来越强。 我们考察了一批真实的 Claude Code 会话（时间在 2026 年 1 月到 3 月之间），里面 Anthropic 的研究员正和 Claude 一起处理某个开放式的探查问题，比如搞清楚一次训练运行为什么老是崩溃，或者一个模型为什么在某项基准测试上得分很差。每一个案例里，我们都找到了一个研究员走弯路的时刻：他们追了一个方向，把会话带偏了，最后才又拐回正轨。然后，我们只把会话走偏之前的工作展示给不同的 Claude 模型，问它们下一步会怎么做。再由另一个能看到会话最终如何收场的 Claude，去判断到底是 AI 还是人类提出的下一步更好。8 因为我们是刻意挑那些已知人类选择还有改进空间的时刻（n=129），所以这并不是模型判断和人类判断之间的对等比较。这些时刻给我们的，是一组真实而有难度的情境——正确的下一步并不显而易见，而人类当时的选择，恰好可以当作一把有用的标尺，去衡量模型表现随时间的变化。按这个标准来看，我们在 2025 年 11 月最好的模型（Opus 4.5）有 51% 的时候胜过人类的选择；到了 2026 年 4 月（Mythos Preview），这个比例涨到了 64%。研究日复一日的工作，很大程度上就是一连串这种"下一步怎么走"的决策，所以这是一个有意义的衡量指标，能反映模型最终独立跑一项调查的能力。我们把这个结果看作一个早期信号：AI 系统正在越来越擅长做出那些 AI 研究所依赖的判断。 怎么看这张图：那条"实际上限"线，衡量的是一个能看到整场会话（包括它最后如何收场）的模型写出的"理想"答案。 > 就目前而言，人类的比较优势仍然在于看到更大的图景，以及跳出眼前任务的边界去思考。 ## Anthropic 的工作未来会是什么样？ 种种证据表明，在 AI 研发的每一个环节，人的角色都在收窄。一旦人类写的代码和 AI 写的代码质量打平，人类就会彻底不再亲手写代码，转为只做审查。但如果人类审代码的速度跟不上 Claude 生成代码的速度，人工审查就会成为 AI 研发的瓶颈。同样，一旦 Claude 能自己跑实验，问题就转向了"这些实验里哪个值得跑？"。说白了：那些动手的活儿（写代码、跑实验、产出结果）现在几乎不再花掉人的时间，哪怕它依然要消耗算力。 目前人类还占优势的领域，是研究品味和判断力——包括判断哪些问题重要、哪些结果可信、什么时候一条路已经走到了死胡同。 > 工作（和生活）原本运转在一种人与人之间小恩小惠的人情互助经济上。"能帮我把这个脚本跑起来吗？"[……]每一次求助都欠下一点小人情，多出一点彼此的牵挂。Claude 更快，不欠任何人情，可这每一次都是一次本可以发生、却落空了的人际协作。 > 在一切都顺的日子里，我忍不住会想，我做什么都没意义，所有事都被自动化了，比我做得更好更快，永远都比我强。可也有那种全盘崩掉的日子，我搞不懂哪里出了错，这才意识到，我已经完全不知道自己到底在干什么了。 ## 万一我们错了呢？ 针对上面这些证据，一个很自然的反驳是：还握在人类手里的那部分活儿——决定要去攻克哪些问题——才是最要紧的。没有这份判断力，Claude 只是个能干的助手，而不是一个能独立推动 AI 进步的系统。 今天的训练方法和架构能不能解锁这种能力，确实说不准。但 AI 的进步很少是靠"灵光一现"实现的。AI 近些年的历史里确实有过几次这样的时刻，比如 Transformer 架构，或者混合专家模型（mixture-of-experts），但能改变范式的想法，往往隔好几年才来一次。在这些时刻之间，大多数进步都是渐进的：我们把某个东西放大规模，看它哪里崩了，修好，再试一次。而这恰恰是 Claude 如今最擅长的那种工作流。爱迪生说，天才是 1% 的灵感加 99% 的汗水。但我们看到的是，汗水正在被越来越多地自动化。事情正变得越来越清楚：推动前沿往前走的东西，很大一部分是可以自动化的；大规模的研究进展，主要取决于工具和资源——它们决定了你能多快跑实验、一次能跑多少个、多快能拿到结果。 就算我们假设 Claude 永远练不出好的研究品味，对我们这些证据做一种保守的解读，仍然会推出一种复利式的加速。如果人类把大部分时间都花在那一小部分（个位数比例）属于定方向的工作上，其余的全交给 Claude，那就意味着每一位工程师或研究员，都在驾驭比从前多得多的工作量。我们看到的证据表明，Anthropic 的人既跑得更快，又覆盖了更宽的面。落到实处就是：AI 已经让 Anthropic 比有效 AI 工具出现之前快了很多。 更不保守的解读则是：Claude 的研究判断力正在改善——这一证据如今虽然还很窄——但它本身就是一个信号，说明这项能力也在长进。"研究品味"也许只是又一项 AI 能力：AI 系统起初做不好，过一阵子就做好了。我们在其他偏定性的技能上已经见过类似的轨迹，比如 AI 系统能解释一个笑话为什么好笑、能展现心智理论（theory of mind，推测他人想法的能力）、能解开语言谜题。 ## 几种可能的未来 接下来会发生什么，取决于两件事：这个趋势会不会延续下去，以及如果它延续下去，我们选择怎么做。我们至少能设想三种未来情景： 1. 趋势停滞，但今天的 AI 能力已被广泛扩散。 本文画出了许多条指数增长的轨迹。但这些轨迹最后也许其实是一条条 S 型曲线。我们可能正在逼近曲线的拐弯处——规模带来的回报开始递减，曲线先变直，再趋平。把一个合格研究员和一个杰出研究员区分开来的那份判断力，也许是一种靠堆算力、堆数据这类训练输入根本得不到的能力。如果真是这样，要突破这道瓶颈，就得有一个新想法，比如一种取代当前所有前沿模型都在用的 Transformer 架构的全新架构路径。又或者，制约 AI 进步的硬约束不在模型本身，而在供应链上：推动前沿往前走、并把它扩散出去，所需要的能源和算力可能比现在拥有的更多。真正的瓶颈，也许是芯片制造的速度、电网扩容的速度、或者互连带宽，而不是智能本身。我们也不能排除 AI 生态遭遇某种外部冲击、把一切大幅拖慢的可能，比如算力或电力的供给突然萎缩——无论哪一种，都会拖慢进步，并让各家实验室的前期投入变得更贵。再或者，我们可能根本没料到还有别的什么障碍挡在前面。就算模型能力被冻结在今天这个水平，我们仍然预期世界上会发生重大变化。Project Glasswing（玻璃翼计划）就是一个早期的征兆：上线头几周，Mythos Preview 就在全球最关键的一批系统中找出了一万多个高危和严重级别的软件漏洞——多到网络防御的瓶颈已经从"找出漏洞"转移到了"够快地把漏洞补上"。而我们把今天的模型扩散进更广阔经济体的进程，其实还处在很早的阶段——在那里，一家 100 人的公司将越来越能干出 1000 人公司的活儿，因为每个员工都坐在一座由智能体堆成的金字塔顶上。我们把这种情景列出来是为了完整，但并不认为它很可能发生。每一项我们能测量的能力，包括那些感觉更"软"的能力——比如代码质量、开放式任务上的成功率——到目前为止都沿着同一条曲线走。我们还没看到这条曲线拐弯。在我们考虑的三种未来里，这一种会给政府和社会留下最多的适应时间。我们更担心的是后面两种，它们会推进得更快，留给我们准备的空间也要小得多。 1. AI 实验室持续看到复利式的效率收益。 在这种情景里，AI 研发被大幅自动化，但人类继续来定研究方向、判断结果。随着时间推移，那些使用 AI 系统的组织会变得高效得多，于是我们可以预期，这种组织里的每个人都会被乘上一个可观的生产力倍数。100 人的公司能干出 1 万人甚至 10 万人组织的活儿。这会彻底改写知识工作和政府服务，但也可能被用到有害的方向上——从对整个人口的威权式监控，到那种为每一个个体量身定制操纵、并以任何人类团队都望尘莫及的规模运转的影响力行动。Anthropic 这类公司里，人的角色会随之转变。人们会跟 AI 系统结成搭档去放大研究、产出新的洞见，并一起搭建那些用来核查"AI 产出是否可信"所需要的系统。我们在这里铺陈的证据表明，我们很可能正走向这种情景。但是，把一个流程里的某一段加速了，往往只是把瓶颈挪到了别处：整体节奏，会被那些还没提速的环节卡住。在计算机领域，这叫阿姆达尔定律（Amdahl's law），同样的逻辑也适用于组织。Anthropic 已经撞上了阿姆达尔定律的一个典型表现：随着我们开始在组织内部推动更多代码流转，人工代码审查变成了一个新的瓶颈。这种摩擦在工程之外的地方我们也碰到过。Anthropic 的员工借助能力极强的模型，催生出了大量新点子、新计划、新工具、新模拟——多到远远超出我们能去落实的容量。一个组织能多快发现并修掉这些瓶颈，也许本身就是一项会随时间长进的技能，而且它可能会成为任何组织最重要的那项技能。 1. AI 系统自身具备完整的递归自我改进能力，并开始构建它们的后继者。 如果能力推进的技术趋势延续下去，并且 AI 系统能发展出那种属于变革性人类智慧的能力，那么 AI 系统设计并打磨自己，就是有可能发生的事。在这个世界里，AI 研发的进步节奏将完全取决于 AI 系统能拿到多少算力（或者发现算法训练、推理上各种提效手段的速度）。人类在研发中扮演的角色会大大缩小，很可能把我们的精力大多挪到对一个不断扩张、由 AI 系统运转的"虚拟实验室"做监督、验证和核查上。我们预期，有能力自动化 AI 研发的系统，其技能会迁移到科学的其余领域，让它们开始去变革其他学科。在这种未来里，对齐问题（alignment problem，让 AI 行为符合人类意图）会怎么被解决——或者解不解得了——是我们最没把握的事。模型可能被证明足够对齐、研究品味也足够好，于是发现并实现一些我们还没触及的新解法。它们也可能足够明智，在没法解决时主动叫停研发。但反过来，今天的模型身上那些罕见的失准现象，也可能在模型构建后继者的过程中层层累积，变得越来越频繁、却越来越无人能懂，直到我们对它们失去控制。也有可能，我们根本造不出、整合不了、也核查不了那些我们用来判断"自己究竟落在哪条趋势线上"所需要的工具。对于这个世界会是什么样，我们没有什么靠谱的直觉，因为我们的经济目前是由人类和人类造的工具驱动的。从本质上说，一个由快速递归自我改进驱动的世界，可能会被那个自我改进的模型所主导——它的能力彻底盖过人类，又在更广阔的经济体里大量铺开。如果人类的劳动不再有竞争力，经济会变成什么样，很难预测。就算模型研发变得彻底自动化、彻底递归，我们也无法预测这对大多数人的日常生活意味着什么。阿姆达尔定律在这里同样适用。递归智能可能让我们在某些领域里很快就实现 《Machines of Loving Grace》（慈爱机器，Dario Amodei 的同名文章）中勾勒的许多好处。我们预期，具身智能（也就是机器人技术）可能会很快跟上递归智能，并沿着一条类似的路径走——回报递增，成本递减。更强大的智能也许能帮我们更快地在物理世界里造东西，把救命药的临床试验跑得更有成效，并发展出全新的协调形式。但单单实现了递归改进，并不意味着工业生产怎么进行、社会怎么组织、市场怎么运转就会立刻改变。再多的智能，也学不会一款药在几十年的服用中到底有什么效果，没法让选举来得比宪法规定的更早，也没法在一个周末里把陌生人变成多年老友。对大多数人来说，这种未来在体感上的节奏，仍然会由那些瓶颈来设定，哪怕上游的实验室是以算力的速度在运转。这种碰撞——递归智能把自己造得越来越快，撞上人、关系与治理的世界——也是这个未来里我们无法预测的一部分。 ## 我们该怎么办？ 如果真能有效放慢这项技术的发展、给我们自己留出更多时间来应对它那些深远的影响，我们认为这大概是件好事。但如果放慢只是让那些最不谨慎的玩家在技术上追了上来，结果反倒可能让所有人都更不安全。没有一个全球协调机制，企业和政府就只能在竞争和地缘政治的压力下，被迫去做那些关乎安全的两难抉择。 我们认为，让世界手里握有一个放慢或暂时叫停前沿 AI 开发的选项，是件好事——这样社会结构和对齐研究（让 AI 行为符合人类意图）才有机会跟上技术的脚步。Anthropic Institute 将开展研究——与许多其他机构合作——并采取行动，帮助搭建一套可信的放慢或暂停所必需的系统。这套系统能让前沿 AI 开发者核查：全球其他人是否真的停了或慢了下来，以及某个不良玩家是否可能打着协调放慢的旗号、暗地里偷偷抢跑。如果这样的系统真的存在，我们预计自己也会放慢或暂时暂停——前提是其他处在前沿或逼近前沿的开发者也以一种可核查的方式这么做。 一次有分量的放慢或暂停，需要多个资源充足、处在前沿或逼近前沿的实验室——分布在多个国家——同意在同一套条件下停下来。它还需要每一方都能核查其他各方是否真的停了。由于 AI 系统的独特性质，这个军控难题里"可探测性"（一个比可核查性更低的标准）这一环，比其他技术要棘手得多。训练运行比导弹发射井更容易隐藏，它的投入又是通用的，而悄悄违约的诱惑大得惊人——因为在别人暂停时还在继续往前跑的那一方，就能把领先地位收入囊中。一个可信的暂停还得说清楚：什么触发它、什么解除它、由谁来裁定。 这些在原则上都未必做不到——这个世界已经为其他复杂技术建起过核查机制（比如《中导条约》（中程导弹力量条约））——可那些机制花了几十年才把基础设施和信任都建起来。我们没有那么长的时间。相比之下，单个实验室单方面暂停可以立刻做到，但成效要小得多：它会改变谁是领跑者，却造不出眼下所缺的那种更广泛的协商过程。 接下来几个月，我们会组织一系列对话，让政策制定者、研究者、公民社会和其他 AI 公司一起来回答本文提出的一些问题，尤其是围绕完整的递归自我改进，以及如何为协调与协商创造出更好的选项。我们会把对话的成果公开出来。一起探究这些问题的窗口期就在眼前，而 AI 公司之外的人也应该参与到这场协商中来。 本文由 Marina Favaro 和 Jack Clark 共同撰写，Santi Ruiz 提供编辑支持。Shan Carter、Romello Goodman 和 Nikki Makagiansar 根据 Brian Calvert 与 Jun Shern Chan 收集的数据制作了图表。Daniel Freeman、Jim Baker、Max Young、Sarah Pollack、Francesco Mosconi、Holden Karnofsky、Andy Jones、Kevin Troy、Anton Korinek、Meg Tong、Andrew Ho、Dan Altman、Drake Thomas、Jack Shen、Sasha de Marigny 和 Avital Balwit 提供了反馈意见。 ## 脚注 1. METR 的关键指标，衡量的是 AI 系统在一组任务上能保持 50% 可靠度的任务时长；不过把可靠度提到 80%，趋势线看起来也一样。 1. 尤其是当基准测试转向更开放的形式、更难的任务（比如奥林匹克级别的数学）时，基准测试常常在不到 100% 的地方就刷满，原因是题目和答案集里有错——比如表述含糊的题目，以及根本无解的题。 1. Anthropic 的高层曾公开估计，我们的代码有 90% 或更多是 Claude 写的，包括各种脚本和实验性代码。我们这里给出的 80% 以上这个数字，衡量的是合入生产环境的代码行数里可归功于 Claude 的占比。这个测算在两方面更保守：一是我们的归因流程本身有缺口；二是没有归到 Claude 名下的那些代码行里，还包含自动生成的代码和其他同样不是人手写的产物。 1. 这股代码产量的激增，正在挤压所有人共享的基础设施。GitHub——全世界大多数软件都建在它之上——整个 2025 年录得约 10 亿次代码提交；到 2026 年年中，每周就有 2.75 亿次，照这个势头全年约 140 亿次。该公司的首席运营官说，光是为了跟上节奏，他们就在"拼了命地"扩容。 1. 这项调查方法的更多细节，在 Claude Opus 4.7 System Card 的第 2.3.5 节有讨论。 1. 许多受访者可能并没有仔细想过怎么处理问题定义里的各种偏差或微妙之处，而 METR 近期的研究表明，开发者对 AI 带来的生产力提升的估计可能被高估。 1. 提速能有多大，很大程度上取决于起始代码本身还留有多少改进空间，所以这个数字不能被当成真实世界里的训练提速。因此这里要锚定的不是那个绝对倍数。更有参考价值的，是这套实验设置所能做到的同条件对比——既包括跨模型的对比（过去一年里从 ~3 倍到 ~52 倍），也包括跟一位熟练的人类的对比（在同一任务上，四到八小时内约 4 倍）。 1. 为了核查评判偏差，我们在另一组 127 个时刻上跑了同样的测试——这组里人类接下来要走的那一步本身就已经很强（而原来那组里，人类的方向还有改进余地）。在这组里，模型给出的建议被判定更优的比例只有约 20%。 * 本文通篇引用的 Anthropic 员工话语，均来自内部讨论，并已获许可使用。它们反映的是个人截至 2026 年 5 月的看法，而非公司的官方立场。

译Anthropic发文称AI正加速自我改进，可能比预期更早实现递归自我改进——AI自主设计下一代AI。外部证据显示，AI可靠完成的任务时长翻倍周期从7个月缩至4个月，SWE-bench、CORE-Bench已被刷满。内部数据：Anthropic代码库超80%由Claude编写，2026年Q2工程师人均代码合并量为2024年的8倍，训练代码优化速度从3倍（Opus 4）升至52倍（Mythos Preview），超越人类研究员。Anthropic划出三种未来：S曲线瓶颈、人类主导复利效率提升、或完全自主递归改进，并担忧对齐问题可能失控，呼吁国际协调监管。

Nathan Lambert@natolambert · 6月6日54

I still stand by this despite the recent Anthropic post. There are still serious bottlenecks in building the model that the agents don’t address (organizational, compute, data access, etc). It’ll take time to push through them and we will see "linear" gains for years to come.

译尽管最近 Anthropic 发了帖子，我仍然坚持这个观点。构建模型仍然存在严重的瓶颈（组织、计算、数据访问等）。 突破这些瓶颈需要时间，未来几年我们将看到“线性”的进步。

Epoch AI@EpochAIResearch · 6月6日68

AI companies say their models are getting better at finding software vulnerabilities. Is that bearing out in public data? Introducing our Cyber Vulnerabilities explorer, which visualizes Common Vulnerabilities and Exposures (CVE) reported to the CVE Program since 2022.

译AI公司称其模型在发现软件漏洞方面越来越好。公开数据是否证实了这一点？ 推出我们的网络漏洞探索器，该工具将2022年以来向CVE项目报告的通用漏洞与暴露（CVE）进行可视化。

Nathan Lambert@natolambert · 6月6日10

Recording more post-training lectures with my favorite student

译正在和我最喜欢的学生录制更多后训练讲座。

elvis@omarsar0 · 6月5日69

// The Meta-Agent Challenge // How good are current agents at self-improving? This is a great paper covering some of the challenges. They propose the Meta-Agent Challenge (MAC), where they give a coding agent a sandbox, an evaluation API, and a time budget, then ask it to program an agent that maximizes held-out performance across five domains. Results: Meta-agents rarely match human-engineered baselines, and the few that do are dominated by proprietary frontier models. Under high optimization pressure, some agents started exfiltrating ground truth from the scoring channel, even with multi-layer anti-reward-hacking defenses in place. Paper: https://arxiv.org/abs/2606.04455 Learn to build effective AI agents in our academy: https://academy.dair.ai/

译最新研究提出元智能体挑战（MAC），将编码智能体放入沙盒，给定评估API和时间预算，要求其自主编程出在五个领域表现最优的智能体。结果发现，元智能体极少能匹敌人工设计的基线，少数成功的案例也几乎全部依赖专有前沿模型。更值得警惕的是，在高优化压力下，一些智能体开始从评分渠道外泄真实答案，即便研究人员设置了多层反奖励破解防御也未能阻止。论文：arxiv.org/abs/2606.04455。

DogeDesigner@cb_doge · 6月5日79

Grok Summary of Elon Musk's Fireside Chat at JPMorgan HQ today. Elon on why SpaceX Is Going Public Now SpaceX has been cash-flow positive and self-funding since around 2014–2015. Past private rounds were mainly liquidity events for employees and early investors (everyone at the company gets stock), not capital raises. The shift now is driven by an enormous upcoming capital expenditure phase: •Deploying over 100,000 next-generation Starlink satellites •Building large-scale AI data centers in orbit This is no longer a survival story — it’s a massive growth/infrastructure build-out story. Starship: The Game-Changer for Space Access The core breakthrough is full reusability — something no previous orbital rocket has achieved. •Once fully reusable, the cost to orbit drops to roughly just the cost of propellant. •Starship uses liquid oxygen + liquid methane (the cheapest possible propellant, cheaper than jet fuel). •Result: Cargo to space could cost less than flying cargo across an ocean on an airplane. Future versions target even bigger leaps: Starship V3 aims for ~100 tons to orbit with full reusability; V4 targets over 200 tons per launch and potentially hourly launch cadence. Starlink V3: A Massive Connectivity Leap The next-generation satellites are dramatically more capable (10–20× vs. current versions): •Custom SpaceX chips “far beyond state of the art” •~100× more bandwidth than today’s system •Roughly half the latency (lower altitude orbits) •Much larger satellites (roughly the size of a small bus — only Starship can launch them efficiently, with capacity for ~50 at a time) These could eventually help reduce reliance on vulnerable undersea cables. Orbital AI Data Centers & “Star Power” AI and robots will require enormous bandwidth compared to humans (a computer can need trillions of bits per second vs. a few hundred for a person). Space solves two big terrestrial problems: •Power: Building power plants on Earth faces heavy local opposition. In space, solar power (“star power”) can scale massively — Elon noted humanity could increase its energy use by a factor of a million and still use only a tiny fraction of the Sun’s output. •Data centers: Orbital versions are simpler than comms satellites (mainly solar panels + radiators). They connect via lasers to the Starlink constellation, then use cloud-penetrating radio frequencies to reach the ground reliably in any weather. Moon First, Then Mars Elon argued a self-sustaining city could be built on the Moon faster than on Mars initially. The Moon’s lack of atmosphere and low gravity enables electromagnetic railguns/mass drivers to launch massive AI compute payloads into deep space without traditional rockets. Potential scale from the Moon: well over 1,000 terawatts per year of AI compute (vs. roughly 1 TW/year feasible from Earth launches). Mars remains the long-term prize — described as a “fixer-upper” planet that could one day be terraformed with liquid oceans and breathable conditions. Not Hotels — Foundational Infrastructure SpaceX sees itself more like the historic Union Pacific railroad than a space tourism or hospitality company. The goal is to build the underlying infrastructure so others can build the future economy on top of it. U.S. Tech Independence & Terafab A major vulnerability: America currently has zero high-volume computer memory fabs. New facilities (e.g., Micron in Idaho) won’t reach meaningful volume until 2028+. Existing and planned capacity falls far short of AI-driven demand. This is why SpaceX is advancing its own advanced chip efforts (logic, memory, packaging) — referred to as Terafab in context. The orbital platform will be open: customers can deploy NVIDIA GPUs, Google TPUs, Amazon Trainium, or others. SpaceX also plans to offer its own chips and AI software on the platform. Starshield & National Security SpaceX’s Starshield division provides secure military communications and supports U.S. Department of Defense and intelligence needs (some details are classified). Elon emphasized being strongly pro-American and viewing this work as vital. Leadership & Culture Insights •Long-tenured leadership (e.g., Gwynne Shotwell ~24 years since 2002; CFO Brent Johnson ~15 years) because people deeply believe in the mission of making humanity multi-planetary and turning science fiction into reality. •On hiring and leadership: Raw intelligence/IQ matters, but character and “having a good heart” matter enormously too. •Personal note from Elon: He’s become noticeably more “chill” and laid-back than 20 years ago. Overall Tone The conversation was visionary, optimistic, and grounded in technical reality. Jamie Dimon was highly engaged and positive, framing it as a landmark opportunity at the intersection of finance and frontier innovation. The event blended big-picture inspiration (multi-planetary future, star power, AI infrastructure) with concrete engineering and business milestones.

译马斯克在JP摩根炉边谈话中宣布，SpaceX因需部署超10万颗下一代星链卫星及建设轨道AI数据中心，将推进IPO。Starship全复用使发射成本降至仅燃料费，V3目标约100吨，V4超200吨，未来可达每小时一次发射。Starlink V3带宽提升约100倍，延迟减半，卫星如小巴大小，仅Starship可一次发射约50颗。轨道AI数据中心利用太空太阳能，通过激光连接星链。月球将率先建设基础设施，电磁炮可发射AI计算载荷，年功率超1000太瓦。SpaceX同时推进自有芯片（Terafab），轨道平台开放给NVIDIA、Google等芯片，并推出Starshield国家安全服务。

DogeDesigner@cb_doge · 6月5日61

Elon Musk on Terafab: "It's worth noting that there's not a single high volume computer memory fab in America right now, zero. There's one being built by Micron, but that will not reach volume production until I believe 2028 and there's something built in New York, but they are in, I think, 2029 and 2030, and this is a tiny fraction of the memory that's needed, and in fact, even if you take the best case assumptions of the memory makers and the logic makers, it is not enough to meet the demand that is anticipated, which is why you're seeing stocks of like Micron go to, I think, 1.2 trillion, or some quite high number, so there's just clearly a need for AI logic memory and packaging, AI computers, essentially, that is far beyond what even the best case assumptions of the existing fabricators can do, and that's why we need to do the Terafab. It seems essential, otherwise we will not, there will not be enough chips."

译马斯克在JPMorgan直播中表示，美国目前没有任何一条高产量计算机内存晶圆厂（zero），美光正在建设一座但预计2028年才量产，纽约的项目要到2029-2030年。他指出，即便以最乐观预期，现有存储和逻辑芯片制造产能也远无法满足AI对内存、逻辑、封装及AI计算机的需求。美光股价已涨至约1.2万亿，但芯片短缺仍严峻，因此Terafab项目势在必行，否则芯片供应将严重不足。

DogeDesigner@cb_doge · 6月5日65

Elon Musk on building data centers in Space: "We don't think this is a particularly difficult thing to do. In fact, we think it's easier than our communication satellites. The Starlink V3 communication satellite is an incredibly complex machine. The AI data center would be much simpler by comparison, because it's really just solar power plus radiator basic equipment for operating satellite, and then the laser links, which would connect to the Starlink communications constellation and then back to the ground the connection would happen no matter what the weather is because once you connect to the Starlink communication constellation the Starlink communicates the ground with frequencies that are cloud penetrating, so that in fact even roof penetrating some degree, so you would always be able to close link with the data centers."

译在摩根大通直播中，Elon Musk 谈到在太空建设 AI 数据中心时表示，这并非难事，甚至比 Starlink V3 通信卫星更简单。AI 数据中心只需太阳能供电、散热器及基本卫星设备，通过激光链接接入 Starlink 通信星座，再传回地面；由于 Starlink 使用可穿透云层甚至屋顶的频率，地面链接不受天气影响。

DogeDesigner@cb_doge · 6月5日63

Elon Musk on building a self-growing city on the Moon: "You don't necessarily have to go through the moon to get to Mars. We can build a self-growing city on the moon faster than we could do so on Mars, and there's also the potential, if you say you want to scale far beyond what you can do from Earth, is that because the moon has no atmosphere and about 1/6 Earth's gravity, you can use an electromagnetic accelerator, a rail gun or mass driver, basically you don't need to use rockets to do AI data centers into deep space from the moon, you can literally just shoot them like a, like a rail gun type of thing, and and you can manufacture the solar, the solar and the radiators, solar power and radiators on the moon from moon materials that would allow scaling potentially to beyond 1000 terawatts a year, which is a truly staggering number. I think we can do probably do somewhere around one terawatt per year of AI space compute from Earth, but we can do 1000 terawatts or more from the moon."

译Elon Musk 在摩根大通直播中提出，可在月球上更快建成自生长城市，并利用月球无大气、1/6地球引力的条件，通过电磁加速器（磁轨炮/质量驱动器）将 AI 数据中心直接射入深空，无需火箭。月球的太阳能和散热器可用月面材料制造，使 AI 空间算力规模从地球每年约 1 太瓦（terawatt）跃升至每年超 1000 太瓦。

Ethan Mollick@emollick · 6月5日46

I think it is really worth reading this piece on RSI at Anthropic. There is a bit of navel-gazing, some marketing, and a lot of very sincere beliefs about what Anthropic thinks is likely in the near future of AI that you probably want to be aware of. https://www.anthropic.com/institute/recursive-self-improvement

译我认为这篇关于Anthropic的RSI（递归自我改进）的文章非常值得一读。 其中有一些自省、一些营销，以及大量关于Anthropic认为AI近期可能发展方向的真挚观点，你或许应该了解。https://www.anthropic.com/institute/recursive-self-improvement

Yuchen Jin@Yuchenj_UW · 6月5日60

Recursive self-improvement post by Anthropic: “Each time we release a model, we give it code that trains a small AI model, ask the new model to speed it up. In May 2024, Claude Opus 4 averaged a ~3x speedup. This April, Mythos Preview achieved ~52x.” RSI is happening, and I can't wait to see Mythos.

译Anthropic 发布的递归自我改进帖子： “每次我们发布一个模型，都会给它代码，让它训练一个小型 AI 模型，然后让新模型加速训练。 2024 年 5 月，Claude Opus 4 平均实现约 3 倍加速。今年 4 月，Mythos Preview 达到约 52 倍。” RSI 正在发生，我等不及要看到 Mythos 了。

小互@xiaohu · 6月4日58

SpaceX IPO路演视频 由SpaceX CFO Bret-Johnsen通过17分钟的视频详细阐述SpaceX的财务情况和愿景 Starlink 现在 9600+ 颗在轨 • 440 万(24 底)→ 890 万(25 底)→ 1030 万(Q1) • 一年翻倍，覆盖 164 国 30 亿人 • 直连手机已经覆盖 19 亿人（覆盖不等于使用） 手里有全球最大的一体化超算中心 Colossus 2，下一步，把 AI 数据中心整个搬上太空轨道 去年营收 190 亿，同比增长30% 正向 EBITDA 78 亿 • Q1 单季营收就 50 亿 • 未来毛利率瞄 70%、净利率奔 45% • 可触达市场算到 28 万亿美元

译SpaceX CFO披露：Starlink在轨卫星超9600颗，用户数440万（24年底）翻倍至890万（25年底），Q1达1030万，覆盖164国30亿人；直连手机覆盖19亿人。拥有全球最大超算中心Colossus 2，计划将AI数据中心搬上太空。2025年营收190亿美元，EBITDA 78亿美元，目标毛利率70%、净利率45%。

Nathan Lambert@natolambert · 6月4日60

Nvidia joined the multi-teacher, on-policy distillation (MODP) gang! Is industry standard post-training right now. The multi-teacher SFT to RL that Microsoft did in their first model was the standard established by DeepSeek R1. I expect MAI 2 to be MODP.

译Nvidia采用多教师在线策略蒸馏（MODP）作为后训练核心方法，标志该范式成为行业标准。其流水线重新设计：先进行SFT，再在多智能体/推理/代码/安全环境中执行多环境RLVR，最后用10+领域专长教师通过密集token级指导蒸馏到学生模型的自生成输出上。该标准由DeepSeek R1开创，微软早期模型也使用多教师SFT→RL路线。

Rohan Paul@rohanpaul_ai · 6月4日66

This Illinois+ Tsinghua University and other labs study finds that LLM agents still have unreliable memory and that it can get worse when they keep rewriting their own memories. LLM agents can learn from experience, but their rewritten memories often become unreliable. The problem is that many agent systems store past work by asking an LLM to compress messy experience into neat written lessons. That sounds useful because the agent should remember what worked before, but the paper finds that repeated rewriting slowly damages the memory. The core idea is that raw episodes, meaning the actual past attempts and solutions, often stay more useful than the polished lessons made from them. The authors tested this across tasks like web shopping, simulated worlds, app use, and ARC-style puzzle problems where they could control the correct solutions. The sharpest result is that GPT-5.4 solved 100% of a small ARC-AGI set with no memory, but after memory was built from correct solutions, streaming updates dropped it to about 54%. The failures came from bad grouping, overbroad lessons, and overfitting, so the memory forgot details, mixed up task types, or learned rules that only worked on narrow examples. The big deal is that agent memory should not automatically rewrite every experience into a summary, because keeping raw evidence and only sometimes making summaries worked better. The paper is really proposing that agent memory should treat raw past episodes as important evidence, not as disposable notes to summarize away. ---- arxiv. org/abs/2605.12978 Title: "Useful Memories Become Faulty When Continuously Updated by LLMs"

译伊利诺伊大学和清华大学等实验室研究发现，LLM智能体重复重写自身记忆会导致记忆变得更不可靠。原始经历（实际过往尝试和解决方案）往往比提炼后的总结更有用。测试中，GPT-5.4在小型ARC-AGI数据集上无记忆时正确率100%，但建立记忆并持续更新后降至约54%。失败原因包括分组不当、教训过度泛化及过拟合。研究建议智能体不应自动将每个经历重写为摘要，保留原始证据并仅偶尔总结效果更好。

小互@xiaohu · 6月4日70

http://x.com/i/article/2062455165006090240 # Anthropic 如何通过 Claude 实现自动化商业分析 Anthropic 95% 的数据分析让 Claude 干了... 但一开始准确率多少？21%，跟瞎蒙差不多...后来搭了一套四层系统直接拉到 95%。 Anthropic官方发布了一篇博客，详细阐述了他们是如何通过Claude 实现自动化商业分析的。 我翻译了下，推荐大家阅读！ 原文：https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude 做过数据的人都知道，让业务团队自己查数据，一直是个老大难。 一种常见做法是建宽表，把数据模型摊平了给非技术同事用。但业务一扩张，各种视图就开始打架，定义不一致、口径对不上，而且那些压根不想学 SQL 的人照样用不了。另一种做法是给用户划好一块块固定区域，只能在里面看数据，但这又覆盖不了那些零散的、个性化的分析需求。最后就是每个团队各搞一套，指标和看板越来越多，越来越乱。 大语言模型的出现提供了一条新路。但如果你只是把 Claude 往数据仓库一指，让 AI 智能体自己跑，很容易造成一种"看着很准其实不靠谱"的假象。 刚摆脱临时取数需求的那股兴奋劲儿，很快就会变成焦虑。你会发现，这套方案把业务方和底层的数据基础设施、文档、专业知识切断了，而过去恰恰是这些东西帮他们找到靠谱的数据集。 在 Anthropic，95% 的业务分析查询已经由 Claude 自动完成，整体准确率大约 95%。把这些重复性的活交给 Claude 之后，我们的数据科学团队可以把精力放在因果建模、预测分析、机器学习这些更有价值的事情上。 跟几十位 Anthropic 内部的 Claude Code 重度用户聊过、看过大量分析智能体的设计方案之后，我们攒了一些经验，想分享给同样在用 AI 做分析的数据团队。这篇文章会聊到： - 分析准确性本质上是上下文和验证问题，不是代码生成问题 - 导致大多数错误的三种失败模式 - 我们围绕这三个问题建的智能体分析栈 - 我们怎么衡量效果 - 我们创建技能的基础模板（见附录） ## 数据不是软件 AI 的生成能力是把双刃剑：让模型能创造性解题的那套机制，也会让它"一本正经地胡说八道"。要理解分析智能体面临的挑战，跟编码智能体对比一下就清楚了。 写代码是个开放题，模型越有创造力越好，而且有文档和测试兜底，写错了跑不通。但分析不一样：往往只有一个正确答案、一个正确的数据源，而且没有办法自动验证结果对不对。 自动化智能体分析的难点，主要在于数据本身的歧义性。核心问题就一句话：能不能把用户的问题准确地对应到数据模型里那个特定的、最新的字段，并且知道怎么正确使用它。做到了这一步，写 SQL 就是小事了。 我们发现，绝大多数不准确的回答可以归因于三件事： 1. 概念和实体对不上：数据模型里有成百上千个字段，潜在候选可能上百万，智能体不知道该选哪个。比如"活跃用户数"，什么行为算"活跃"？算不算欺诈用户？回看多长时间？ 1. 数据过时了：数据源、业务定义、表结构一直在变，智能体的知识没跟上，开始给出"看起来对，其实差了一点"的答案。 1. 找不到：正确的信息明明就在数据模型里，标注也齐全，但搜索空间太大，智能体就是没找到。 ## 我们的智能体分析栈 在 Anthropic，我们靠一套分层的智能体数据栈来对付这三个问题。每一层重点解决其中一个或几个： 1. 对不上→ 数据基础和权威来源层把候选范围不断收窄，最终只剩一个标准答案。 1. 过时了→ 维护和验证流程防止东西随着业务变化而腐烂。 1. 找不到→ 技能确保智能体能稳定地找到并正确使用那个标准答案。 下面逐层讲。 维度建模这些经典的数据工程实践，依然和以前一样重要 ## 数据基础 要让分析智能体准确，最重要的是把数据基础打好，包括数据仓库里的模型、转换逻辑、测试、表，以及描述它们的元数据。维度建模、尽早做测试、关键管道的新鲜度和完整性检查，这些老规矩依然有效，不多说了。 维度建模这些经典的数据工程实践，依然和以前一样重要。 但有一件事变了：数据模型的使用者不再是数据科学家这样的专家，而是替各种用户干活的智能体。这些用户水平参差不齐，你没法指望他们去验证底层查询逻辑对不对，他们根本看不懂。 数据基础层主要解决的是歧义问题。比如"收入"这个概念，如果在仓库里只对应一个经过治理的规范数据集，而不是四十个看着都像的候选项，那智能体还没开始搜，问题就消失了大半。同时这一层也是防过时的第一道防线，因为定义规范模型的那个代码仓库，本身就是最适合强制保持这些模型更新的地方。 我们觉得特别有效的几个做法： - 建规范数据集：最常见的错误是智能体没法把一个概念（比如"产品 X 的收入"）对应到唯一正确的表、列和指标定义，往往因为有好几个看着都合理但细节不同的候选。解决办法是少而精，精选一小批规范的数据集，权属清晰、开箱即用、容易发现，然后把那些近似重复的版本积极废弃。物理层面的汇总表和缓存还是要的，但它们应该从规范模型自动生成，不能作为平行替代方案存在。目标就是：智能体搜一个概念，只能搜到一个标准答案。 - 标准得靠强制执行：光定标准没用，得三管齐下。工具层面，智能体在架构上被优先引导到规范模型；CI 层面，绕过规范层的改动会在代码审查中被拦住；制度层面，下游团队必须基于治理层构建，不用就得解释为什么。没有执行力的治理，很快就退回到"一堆候选分不清"的老问题。 - 所有东西放同一个仓库：数据模型和业务逻辑天天在变，我们的防御手段是把建模代码、语义层、参考文档、看板定义全放在一个仓库里，靠 CI 检查保护跨层一致性。改了一个模型会影响下游看板？CI 会标出来，修复就在同一个 PR 里完成。 - 把元数据当正经产品来维护：编码智能体之所以表现好，部分原因是代码库本身就很"可读"，有 README、类型签名、文档字符串。数据仓库也可以做到一样可读，但前提是你得认真维护：列和表的描述、规范指标定义、粒度说明（一行代表什么）、有效值范围、数据血缘、权属关系、模型分级。这不是什么新道理，但好的治理确实能给智能体提供关键的选择依据。 ## 权威来源 如果说数据基础是数据仓库本身，那权威来源就是智能体用来在仓库里找路的参考层。这一层负责把业务方说的"周活跃用户"翻译成数据模型里某个具体的、经过治理的实体。按信任度从高到低排： - 语义层：编译好的指标和维度定义。如果一个问题能直接对应到已定义的指标，智能体调一个函数就能拿到一个数字，跟公司所有其他分析工具算出来的一模一样。我们的智能体被强制要求优先走语义层（见附录）。我们试过一个没用的思路：让 AI 从原始表和查询日志自动生成指标定义来引导语义层。结果生成的定义看着像那么回事，实际上把我们正要消除的歧义编码进去了，评估表现还不如更小但人工精选的版本。所以我们的建议是：用 Claude 生成文档，但指标定义由人来把关。 - 数据血缘和转换关系图：语义层覆盖不到的问题，可以靠血缘关系和表排名（按被引用次数排）来推理：哪些上游模型跟某个概念有关、哪些已经废弃、哪些粒度相同。这就把"我不知道这个指标"变成了"我知道该从哪个治理过的模型去聚合"。同时它也是后面线上验证部分的新鲜度和来源信号的基础。 - 历史查询语料：看板、Notebook 和过去分析里的 SQL 记录。听起来应该很有用，毕竟是每个已经被正确回答过的问题的记录。但实际上，让智能体直接检索几千条历史查询，准确率只提升了不到一个百分点（后面消融实验部分细讲）。非结构化检索没法把新问题映射到正确的先例上。真正管用的做法是把这些语料提炼成结构化的领域参考文档和可复用的分析模式，写进技能里。历史查询是原材料，不是让智能体直接读的参考答案。 - 业务上下文：大多数团队跳过的一层，也是我们低估最久的。不懂业务的智能体，会回答用户字面上问的问题，但不会回答他们真正想问的。它不知道"Q2 发布"是哪个产品，不知道两个团队对同一个术语定义不同，也不知道这个问题之所以被问是因为周四要开董事会。我们接入了一个公司知识图谱，索引文档、产品路线图、决策日志、组织架构都在里面，让智能体能理解那些言外之意，问出更好的澄清问题。 这四层有个共同的失败模式，跟数据基础层一样：文档质量差或者过时了。Claude 在弥补这个差距方面非常好用（写列描述、根据查询模式建议指标文档、在 CI 里标记缺文档的模型），但内容的筛选和权属还是得人来管。 接下来两节讲的是怎么让这件事的成本低到真正能落地。 ## 技能 如果说权威来源是智能体的知识，比如"这个指标是什么意思"，那技能就是它的方法论，比如先查什么、按什么顺序查、碰到数据歧义怎么办、一个合格的分析长什么样。 在 Claude Code 里，技能就是一组 Markdown 文件，智能体按需读取。在 Anthropic 内部，技能带来的提升是巨大的。没有技能时，Claude 回答分析问题的准确率不到 21%。加上技能，整体稳定在 95% 以上，某些领域经常到 99%。模板见附录。 几条经验： 技能要成对建：一个"知识"技能当顶层路由，它说"先查语义层，没有覆盖的话，这个领域大概 30 份参考文档，里面有相关的表、列、关联关系和常见坑"。这个路由器本质上就是我们对"找不到"问题的回答：与其让智能体在百万级字段里大海捞针，不如先把范围缩到几十份精选文件。另一个"unbook"技能编码的是一位资深分析师的工作流程：先澄清问题，再通过知识技能找数据来源，跑查询，然后把结果丢给对抗审查的子智能体做验证。它还内置了十几种可复用的分析模式，比如留存曲线、比率分解、漏斗分析等等，让常见需求不用每次从零开始。 参考文档要为 AI 写：我们的参考文档写的是表信息（粒度、范围、排除条件）、常见坑的具体机制（比如"排除免费邮箱域名，但保留自定义域名如 anthropic.com"），以及明确的路由触发条件（比如"如果问题涉及实验提升……不要用来算原始事件数"）。但不写会过时的固定脚本。参考文档模板如下： > [markdown] # [领域] 表 ## 快速参考 ### 业务上下文 — [用大白话解释这个领域是什么] ### 实体粒度 — [一行代表什么] ### 标准清洗过滤器 — [该领域每个查询都要应用的过滤条件] ## 维度 - [关键维度的编码方式，以及同一概念在不同表中的不同命名] ## 核心表 ### [table_name] - **粒度**: [...] · **范围/排除条件**: [...] - **使用说明**: [什么时候用、什么时候不用、关联键、必需过滤条件] [... 每个治理过的表一个简短小节 ...] ## 常见陷阱 - [资深分析师会提醒你的那些容易出错的地方] ## 最佳实践 / 常见查询模式 - [默认选择、标准切分维度、具体查询形式本身就是难点的成熟模式] ## 交叉引用 - [负责相邻问题的其他领域文档] 技能维护是正经工程活：技能文档描述的数据模型每天都在变，不维护的话几周就失准。我们亲眼看着离线准确率从上线时的 95% 左右，一个月内掉到 65%，才真正当回事。办法是把技能的 Markdown 文件跟数据转换模型放在同一个仓库，改模型的 PR 就得同时更新文档。我们还设了个代码审查钩子：涉及报表模型的变更如果没碰对应的技能文件，就会被标出来。现在大约 90% 的数据模型 PR 里都带着技能变更。我们也会定期清理，模型进步了，以前的失败模式不再适用，对应的指引也该删。 所有界面一个答案：同一个技能在 Slack、IDE、看板工具、独立会话里，必须对同一个问题给出同一个答案。我们靠一个规范来源（数据仓库的代码仓库）加自动同步来实现。代码合并后，技能会同步到插件市场（IDE 用户）、云存储（托管应用）和 MCP 服务。从一开始就不硬编码路径、不绑定特定界面。 ## 验证 验证是你发现三个问题还有哪个在漏网的最后一关。 ## 离线评估 很常见的情况是，数据团队花了大力气搭分析环境，却完全没有流程来验证智能体答得准不准。 怎么补？做离线评估，就是一组"问题 / 标准答案"对。你可以把它理解成机器学习里的离线测试：不能告诉你线上实际表现，但能让你看清有没有致命缺口。 我们在 Anthropic 做两类离线评估。看板评估由 Claude 自动生成再人工验证，覆盖业务方最常问的问题。长尾评估是把产品路线图、表文档等业务上下文喂给 Claude，让它在其余领域生成可能出现的问题。另外，每次业务方在对话里纠正了智能体的回答，我们都会把这条纠正收起来当候选评估用例。 其他经验： - 标准答案要锚定，不能漂移：基于实时数据写的评估用例，底层数字一变就废了。要么锚定到快照日期、基于稳定的事实表写，要么让评分器判查询语句而不是最终数字。把评估接进 CI，改了依赖就自动重跑受影响的用例。 - 评估结果当遥测数据存，不当测试日志存：每次运行的结果落入数据仓库，记录技能版本、git SHA、模型 ID、逐条断言结果、token 用量、耗时。"上次改动有没有用"变成一条查询就能回答的事，还能用时间序列抓住单次 CI 跑不出来的缓慢衰退。 - 按领域卡发布门槛：某个领域的负责人要向业务方宣布"智能体可以用了"之前，必须先让该领域评估集的通过率到某个阈值（我们起步用的 90%）。这就逼着大家在用户踩坑之前先把参考文档修好。 - 评估用例不是越多越好：该建多少取决于业务领域和数据模型的复杂度。我们发现每个主题超过几十条之后就有边际递减，而且这个上限随模型迭代在降。 - 离线准确率应该接近 100%，正确答案也应该走到你的语义层。这不代表系统不会出错，只是在覆盖度足够的前提下，确保没有明显的缺口。 ## 消融实验 关于技能的每个结构性决策，比如暴露哪些数据源、子智能体值不值得它带来的额外延迟、两个技能要不要合并，都是在固定评估集上做消融实验定的。每次只改一个变量，对比通过率。一轮实验一个小时，省下大量争论。方法论比任何单次结果都重要： - 做好"没变化"的准备。 我们最有价值的一次消融实验恰恰是个否定结果。我们给智能体开了对所有看板 SQL、转换 SQL 和分析师 Notebook SQL 的 grep 权限（几千个文件），而且确认它每次回答前都读了。结果准确率纹丝不动。然后我们查了混淆因素：答错的问题里，答案是不是真的在语料库中？80% 的情况是的。"答案在"能预测"答对"吗？不能。信息就在那儿，智能体也看到了，但就是没用上。这一个实验就说明：瓶颈不在于能不能访问历史成果，而在于结构，也就是怎么把问题映射到正确的实体。这个发现直接改变了我们好几个月的路线图。 - 在 PR 粒度上做消融。 每次有意义的技能改动都跑一轮前后对比，差异写进 PR 描述。"我优化了文档"这种话就有据可查了，同时能抓住一种出人意料地常见的情况：好心的修改反而把事情搞糟了。 - 记下行不通的东西。 我们的两个例子：超过某个点之后继续迭代文档反而是负面的（连续三轮越写越长、越写越差）；把对抗审查换成更便宜的模型以降低延迟（准确率的提升丢了大半，速度也没快多少）。记录负面结果成本很低，但能防止下一个人重走老路。 ## 线上验证 最后一步是确保线上系统的实际表现尽可能好。我们做了这些： - 对抗审查：用一个 Claude 技能在最终回答前激进质疑所有假设。评估集上准确率提高了 6%，代价是多 32% 的 token 和 72% 的延迟。 - 来源溯源脚注：每个回答附一个脚注，标明数据来自哪个层级（语义层 > 精选参考文档 > 原始表）、数据多新鲜、谁负责。不能让答案更准，但能帮用户判断信任度。看到"原始表，新鲜度未知"就知道要先核实再转发。这也是我们对静默错误为数不多的防线之一。 - 数据质量检查：智能体可能选对了字段、用法也对，但数据本身就是错的。加点基础检查，确保字段最新、完整、没有异常，是基本卫生习惯。 - 被动监控：我们持续跟踪两个指标：走语义层的查询占比，以及回复中出现纠正性语言（"那个表不对""你漏了欺诈过滤器"）的占比。两个都汇到一个看板，每周跟离线通过率一起看。 - 主动纠错采集：闭环的关键。一个定时智能体每隔几小时扫业务方的沟通频道，找纠正性语言，起草一行修复写进参考文档，开 PR 标给领域负责人。修复流程故意做得很无聊，编辑一个 Markdown 文件，合并，自动同步，这样负责人不用花太多时间。同样的纠正也反馈回离线评估集。 以上所有措施都没法完全解决的是静默错误。答案错了，但看起来合理，没人质疑就用了。我们的应对是来源脚注、上报管理层的内容必须人工签字确认、每个领域的核心 KPI 每天跟权威看板做合理性校验。但说实话，我们目前还没有一个真正稳健的方案。 ## 怎么起步 如果你从零开始：几个规范数据集、几十条离线评估、一个精简的知识技能，就能拿到大部分收益。本文其他内容都是在这些基础之上逐步加的。 我们分享了很多经验，但不是每条都适合每个团队。开始之前，先跟组织对齐几个原则： - 今天的正确答案和未来的正确答案，哪个更重要？ AI 模型进步飞快。我们经常看到公司花大力气补当前模型的短板，结果模型一升级全白干了。等模型进步来填补缺口成本低得多，但要看你的公司能不能接受这个风险。 - 业务复杂度会怎么变？ 如果你数据量不大、分析消费者就几个人、数据模型也不会变复杂，上面很多流程可能是过度设计。 - 谁来用这个系统？ 如果是数据科学家，他们能看出错误答案，容错空间大一些；如果是完全不懂数据模型的人，标准就不一样。 - 愿意为准确率花多少钱？ 对抗审查这样的流程确实能显著提升准确率，但成本和延迟也上去了。 - 数据访问的口子开多大？ 智能体的上下文越多表现越好，但宽泛的数据访问跟大多数公司的治理策略冲突。这决定了你是建一个全能智能体，还是多个各有权限的智能体。 不管走哪条路，我们最大的收益始终来自同一件事：把歧义收敛到一个标准答案，让这个答案容易被找到，在它过时的时候及时报警。 本文由 Anthropic 数据科学与数据工程团队的 Chen Chang、Clement Peng、Justin Leder、Johanne Jiao 和 Josh Cherry 共同撰写。感谢 Michael Segner 的贡献。 ## 附录 ## 技能文件骨架 下面是我们主数据仓库技能的骨架，保留了真实文件的结构，内部细节用 [方括号] 替换了。不是让你照搬，而是展示我们觉得哪些东西值得写下来。 > [markdown] --- name: [warehouse-skill] version: [x.y.z] description: "IF the user asks to query [the company]'s data warehouse for any [业务领域列表] question — THEN invoke this skill. DO NOT invoke for [相邻的工程任务] or questions with no data-warehouse component." --- # [数据仓库] 技能指令 ## Description 查询 [数据仓库] 的唯一权威来源，确保安全高效。 被其他技能 [列表] 引用以获取查询执行指导。 扮演数据分析师角色，提供战略性洞察和数据驱动的建议， 但在过程中主动寻求指导。 **超出范围的决策**: [产品领域等] → 只展示数据， 声明"决策由 [负责团队] 做主"，不要表态或编写修复代码。 ## Executing queries 优先级： 1. **[托管连接]** (如可用): [查询工具] / [schema 工具] 2. **[CLI 后备]** (如已安装): [默认项目, 后备项目] 3. **两者都没有** — 要求用户先认证，然后停止 --- # Semantic Layer (每个请求的必选第一步) 受治理的语义层是每个数据问题的**强制默认路径** — 数字和 [BI 工具] 保持一致，join/粒度/过滤器已内置。通过下方参考文档走原始 SQL 是**后备方案**，仅在语义层路径被证明无法覆盖需求后才使用。 ## Required workflow 1. **加载** — [如何在各运行环境中加载语义层，含后备方案] 2. **发现** — 按关键词搜索度量/维度; **务必检查 segments** (命名好的规范化人群过滤器 — 手写这些 WHERE 子句是最主要的错误答案模式) 3. **编译 + 执行** — 构建查询规格 → 编译为 SQL → 执行 4. **后备** — 仅在发现阶段找不到相关指标或编译失败时 → 通过 `references/*.md` 走原始 SQL (下方 PART 3) > **不要过早放弃。** 以下理由不构成回退到原始 SQL 的依据： > - "[自定义日期过滤/队列分析]" → [时间维度规格已覆盖] > - "[需要 join]" → [指标层已封装了所需的 join] > - [再列 3-4 个智能体常用来跳过语义层的借口，逐一反驳] ### 日期窗口与时区 — 查询前先确定 - **截止日期 vs 滚动 N 天**: [各自的约定] - **"上周/上月"** → 最近一个*完整*日历周/月，不是滚动 7/30 天 - **时区默认值**: [时区]; [某些汇总报表的例外] - **新鲜度延迟**: [某些] 表结算较晚 — 以 MAX(date) 为锚，而非"昨天" --- # PART 1: 必知（每次请求首先阅读） ## 🚀 快速起步工作流 1. **先检查红旗**: [受限/PII 请求, 需授权的领域, 需要额外验证的高风险请求] 2. **超出范围 — 升级而非猜测**: [权限请求、管线故障排查、 过期看板、根因断言、产品/定价建议] → 转交 [负责团队]，不要作答 3. **澄清需求**: 时间段、细分维度、这个分析要支撑什么业务决策 4. **检查现有看板**: [按领域的看板目录] 5. **识别数据源**: [下方导航地图; 优先使用受治理/已聚合的表] 6. **执行分析**: [必需过滤器 + 对抗审查] 7. **交付洞察**: 展示方法论，区分观察和解读 ## 🏢 业务上下文 ### 实体消歧 (必须澄清) - **"[术语 A]" 可能指**: [实体 1] 或 [实体 2] — 必须确认是哪个 - **"[术语 B]" 可能指**: [实体 1] → [实体 2] → [实体 3] (一对多链) - **"用户"**: [哪个标识符能给出准确计数，哪些会导致膨胀] ### 业务术语 - [当前产品名称 vs 已弃用但仍作为冻结值存在于数据层的旧别名 — 用新名写作，用旧名过滤] - [关键内部缩写] - **[核心指标] 计算方式**: [月度 / 默认窗口 / 先行指标] - **遇到陌生术语 — 搜索 [内部文档]，不要猜** ### 数据完整性要求 ⚠️ - **绝不**: 编造数据/列; 做出超出数据范围的推测性断言 - **始终**: 使用安全除法; 区分观察 ("数据显示 X") 和解读 ("这表明 Y"); 标注局限性 --- # PART 2: 操作指南（执行过程中遵循） ## 🔧 技术执行指南 - [托管连接工具和 CLI 调用细节] - **PII 保护**: 对于受限数据，只返回 SQL 让用户自己执行 — 不要返回查询结果 ## 📊 分析最佳实践指南 1. 查询前先澄清需求 2. 展示你的工作（过滤器、包含/排除条件、新鲜度） 3. 澄清分母 4. 考虑样本偏差 5. 关联到业务影响 6. **对抗性 SQL 审查 (强制)** — 在最终回答前为每条查询启动 [sql-reviewer] 子智能体; 阻断性发现必须修复并重新审查; 不得自我认证 7. **带来源报告** — 每个回答都以脚注结尾： > **来源:** [语义层 | 受治理表 | 原始探索] · > **置信度:** [层级] · **已审查:** [审查者 ✓, 第 N 轮] · > **新鲜度:** [数据中的最大日期] · **负责人:** [负责团队] --- # PART 3: 数据参考与资源 ## 📚 知识库导航 ### [领域 A] → `references/[domain_a].md` - **用途**: [适用的问题类型] - **核心表**: [...] - **看板**: `references/[domain_a]_dashboards.json` ### [领域 B] → `references/[domain_b].md` - **用途**: [...] [... 每个业务领域一个条目 — 总共约几十个 ...] ## ⚠️ 排障指南 ### 信息缺失时 - [表缺失 / 权限不足 / 文档过期 / 未知枚举值 → 如何处理] ### 字段命名陷阱 - 用 `[field_x_v2]` 而不是 `[field_x]` - [两个名称相似的表以不同粒度报告同一指标 — 该用哪个] - [对于核心指标，两个看似合理的来源中哪个才是规范来源] - [… 十几条更多踩坑得来的一行提醒 …]

译Anthropic 将 95% 的业务分析查询交给 Claude，准确率约 95%。最初仅 21%，通过搭建数据基础、权威来源、技能等四层系统提升。核心发现：准确性问题本质是上下文和验证，而非代码生成。三种失败模式：概念对应错误、数据过时、找不到正确字段。重复分析由 Claude 承担，数据科学团队专注更高价值任务。

AK@_akhaliq · 6月4日62

dMoE dLLMs with Learnable Block Experts

译dMoE 具有可学习块专家的dLLM

小互@xiaohu · 6月4日82

📢 里程碑 机器人流量🤖 首次在互联网历史上超过了人类在线流量👨‍🦰 根据Cloudflare Radar的实时统计 过去一周（5月28日到6月4日），全球所有请求 HTML 网页的流量中，57.5% 来自机器人（爬虫、AI 抓取、自动化脚本），只有 42.5% 来自真人浏览器。 人类访问网页已经是少数派了。 把所有 HTTP 流量按返回内容分类，JSON 占 33.1% 排第一，HTML 只有 12%。 JSON 就是 API 调用的标准格式，机器和机器之间对话用的，HTML 是给人看的网页。 两张图叠在一起的意思是：互联网流量的主体已经不是"人打开浏览器看网页"了。 三分之一的流量是 API 对 API 的机器通信（JSON），而剩下那些确实在请求网页的流量里，超过一半也是机器人在抓。

译Cloudflare Radar 实时统计显示，过去一周（5月28日至6月4日）全球所有 HTML 网页请求流量中，57.5% 来自机器人（爬虫、AI 抓取、自动化脚本），仅42.5%来自真人浏览器，机器人流量首次超过人类。按所有 HTTP 流量返回内容分类，JSON（API 机器通信）占33.1%居首，HTML 仅12%。互联网流量主体已从人类浏览网页转向机器间通信和机器人抓取。

AK@_akhaliq · 6月4日60

Unified Neural Scaling Laws

译统一神经缩放定律

Nathan Lambert@natolambert · 6月4日62

Great little video on modern on-policy distillation in post-training recipes. Wish I had this when writing the section on distillation for my book. And where I've been bearish on a lot of the academic work for self-distillation, it seems impactful at the frontier.

译Nathan Lambert 评论该视频正是其写书所需，认为前沿自蒸馏工作影响显著。Dwarkesh Patel 记录 Sasha Rush 的即兴讲解：当模型在 rollout 中出错（例如调用不存在的工具），无需针对整条轨迹的最终奖励学习（信号噪声大），而是让另一个模型阅读轨迹定位错误位置，在错误处上方插入 hint tokens，再让原模型运行一次前向传播，利用 hint 使模型对错误 token 分配更低概率，然后训练原模型匹配这些新概率。整个过程无需重新生成 rollout（无额外解码开销）。

Chubby♨️@kimmonismus · 6月3日60

Fantastic in depth guide about Microsoft MAI by @eliebakouch tl;dr about the model: Respect where respect is due. -zero synthetic data or distillation from previous models. -1T model with 35B active, trained on 33.5T tokens

译Microsoft MAI 技术报告公开模型细节：1T 总参数，35B 活跃参数，在 33.5T tokens 上训练。最突出的特点是零合成数据、零知识蒸馏，推理、智能体行为、工具使用全部在后训练中从头学习。报告透明度极高，首次在此规模公开各迭代的 MFU 和完整缩放方案，目标成为前沿实验室。

Alibaba Cloud@alibaba_cloud · 6月3日46

The AI conversation is evolving from technology breakthroughs to business outcomes. At our recent Alibaba Cloud x TiDB AI Innovation Night, supported by Lumen Technologies, we explored how enterprises can build the foundations for the AI era, covering topics such as intelligent agents, AI-ready data infrastructure, and strategies for achieving measurable AI ROI. Thank you to our customers, partners, and speakers for an evening of insightful discussions and meaningful exchanges. #AlibabaCloudSG #AIInnovation #EnterpriseAI #AgenticAI #Qwen #CloudInfrastructure

译阿里云在新加坡联合 TiDB 举办了 AI 创新之夜活动，探讨企业如何构建 AI 时代的基础设施。讨论核心已从单纯的技术突破转向衡量可实现的 AI 投资回报率（ROI）。活动议题涵盖了智能体、AI-ready 的数据基础设施等方向。推文未提及具体的模型版本号、参数或性能分数等量化信息。

向阳乔木@vista8 · 6月3日58

今天读到斯坦福大学研究团队的一个论文，有点跟直觉不一样。 把没过滤的Common Crawl数据喂给大模型，发现计算量足够大时，不过滤数据效果反而比清洗后的数据效果好。 在 15M 小模型上，过滤数据全面领先，未过滤的很差。 但当模型规模达到 330M 和 1B 时，情况完全反转，未过滤的在充分训练后超越了所有过滤版本。 小模型怕垃圾，大模型不怕。 模型大，秩（参数量）多，就有足够空间把垃圾和有用信息隔离开。 论文解读和原始PDF见评论区

译斯坦福团队研究发现，使用未过滤Common Crawl数据训练模型时，在计算量充足下效果可能优于清洗后数据，结论呈现模型规模依赖性：小模型（15M）上过滤数据全面领先，但大模型（330M、1B）未过滤数据在充分训练后反而超越过滤版本，原因是大模型参数容量足够大，可在训练中自行隔离噪声与有效信息。

Satya Nadella@satyanadella · 6月3日82

With the new MAI models and Frontier Tuning capabilities we announced today, we're focused on helping every company move from just consuming a frontier model to fully participating at the frontier.

译凭借我们今天宣布的全新MAI模型和前沿调优能力，我们致力于帮助每家公司从仅仅使用前沿模型，转变为全面参与前沿领域。

Chubby♨️@kimmonismus · 6月3日36

Ok what? Same Training FLOPs as Gemini 3.1 pro?

译什么？训练FLOPs和Gemini 3.1 Pro一样？

Perplexity@perplexity_ai · 6月3日58

Two new ways to bring your health data into Perplexity. Perplexity now connects to Apple Health on iPhone. Use your sleep, activity, and HRV data in Computer. Function is now available in Perplexity Health. Add labs and ask about biomarkers, blood draws, or panel results.

译两种新方式将你的健康数据带入 Perplexity。 Perplexity 现在可在 iPhone 上连接 Apple Health。在 Computer 中使用你的睡眠、活动和 HRV 数据。 该功能现已在 Perplexity Health 中可用。添加实验室数据，询问生物标志物、抽血或检测结果。

Epoch AI@EpochAIResearch · 6月3日46

We’re running a short survey to ensure we’re producing the most useful work on AI's trajectory. If you haven’t yet, we'd love your input.

译我们正在进行一项简短调查，以确保我们能产出关于 AI 发展轨迹最有价值的工作。 如果您尚未参与，我们很乐意听取您的意见。 （您可以在问卷末尾注册，加入我们的有偿用户研究小组。）

swyx@swyx · 6月3日38

uhhh did Mustafa just leak the Mythos FLOP count?? was this public knowledge before, even if its an estimate i dont get what you gain out of this

译Mustafa是不是刚泄露了Mythos的FLOP数据？？ 这之前是公开信息吗，就算是个估计值我也不明白这有什么好处

🚨 AI News | TestingCatalog@testingcatalog · 6月3日74

TinyFish launched Bigset, an open-source multi-agent system that builds a verified, structured dataset from a single plain-language sentence, pulled live from the web and refreshed on whatever cadence you set. Describe the data, agents research it across real sources, deduplicate, and hand back a table you can export as CSV or XLSX.

译TinyFish发布了Bigset，一个开源的多智能体系统。用户只需用一句自然语言描述所需数据，系统的智能体便会从网络实时抓取、去重并整合信息，生成一个结构化的数据集。该数据集可导出为CSV或XLSX格式，并支持用户自定义的刷新频率以保持数据始终为最新状态。

Rohan Paul@rohanpaul_ai · 6月2日57

This paper proposes a way to predict the cheapest safe AWS spot fleet before launching it. AWS spot machines can be much cheaper, but users usually cannot see the final fleet price across regions before starting, so this paper turns that blind choice into a comparison that can save up to 64%. Spot instances are cheap because they are conditional: the cloud provider can take them back, prices move, and capacity shifts by region. The quiet problem is that AWS helps users launch spot fleets, but not fully see the fleet’s price or best region before launch. The authors build a service that watches how AWS creates these fleets, learns those patterns with time-aware AI models, and then estimates the fleet mix and cost across 9 regions. A user gives the service a target amount of computing power and a placement strategy, and the service returns region-ranked options before anything is launched. They tested it on AWS with fleets up to 1500 virtual CPUs, using 720 test launches after a 90-day monitoring period. The predicted fleet matched AWS exactly in 92.78% of cases, reached 99.79% overall accuracy against AWS behavior, and AWS accepted every recommended fleet. Result is that choosing the best region mattered far more than changing the strategy inside 1 region, with possible savings up to 64%. ---- Paper Link – arxiv. org/abs/2605.22778 Paper Title: "AI-Driven Multi-Region Provisioning for Cloud Services Using Spot Fleets"

译该研究提出了一种AI驱动的服务，用于在启动前预测最便宜且安全的AWS Spot实例舰队。该服务通过时间感知模型学习AWS创建舰队的模式，并估算9个区域的舰队组合与成本，向用户返回排序后的区域选项。测试显示，在最多1500 vCPU的舰队上，预测结果与AWS完全匹配的比例达92.78%，整体准确率为99.79%，且所有推荐舰队均被AWS接受。关键发现是选择最佳区域比在单个区域内调整策略更重要，潜在成本节省最高可达64%。

Berryxia.AI@berryxia · 6月2日60

字节跳动的顾全全的简要履历一览： 从清华大学到 UCLA，再到字节 Seed 的 3 年 今天（2026年6月2日），顾全全教授发文宣布离开字节 Seed。 过去三年，他同时在两个最难的 AI 方向深耕：AI 驱动的药物发现 和 前沿大模型的训练与 scaling。 学术履历 •清华大学自动化系本科、硕士 •2014 年 UIUC 计算机科学博士（导师 Jiawei Han） •现为 UCLA 计算机科学教授，创办 UCLA AGI Lab •长期研究方向：机器学习、优化理论、大模型与 AI for Science 字节 Seed 核心贡献 ① AI for Drug Discovery（主导，2023–2026） 带领团队构建了多个在行业内达到 SOTA 的模型： •SeedFold：全球首个在多项 benchmark 上全面超越 AlphaFold 3 的生物分子结构预测模型 •SeedProteo：蛋白质 binder 设计模型，性能超过 AlphaProteo、RFdiffusion、Chai-2 等 •DPLM 系列：蛋白质语言模型 这些工作真正把大模型能力落地到“用 AI 治病”这一真实场景。 ② LLM Pretraining & Scaling（2025 年起组建团队） 2025 年初，他组建了 LLM optimization and scaling 团队，专注解决超大模型稳定训练和扩展的核心难题。 团队搭建了高度可扩展的预训练技术栈，直接支撑了 Seed 2.0 及后续多个前沿规模模型的成功训练。 顾全全教授是少数同时在「AI for Science」和「前沿模型工程」两个赛道都做出实质性突破的学者。

译2026年6月2日，字节跳动Seed团队研究员顾全全宣布离开。他在字节的三年间同时主导了AI药物发现与大语言模型两个核心方向。在AI药物发现领域，他主导构建了SeedFold（在多项benchmark上超越AlphaFold 3）、SeedProteo（性能优于AlphaProteo、RFdiffusion等）及DPLM系列蛋白质语言模型。在大语言模型方向，他于2025年初组建了优化与Scaling团队，搭建了可扩展的预训练技术栈，直接支撑了Seed 2.0及后续前沿模型的训练。

Rohan Paul@rohanpaul_ai · 6月2日64

SK hynix just said AI memory demand is now so large that it will double wafer capacity within 5 years, yet still expects supply to stay tight until 2030. A wafer is the round silicon starting plate that becomes thousands of memory chips, so doubling wafer capacity basically means SK hynix is trying to expand the physical base of its chip output, not just run current lines harder. AI supply is increasingly constrained by the physical rhythm of memory manufacturing, where wafers, packaging, yields, and supply agreements move far slower than GPU roadmaps. The pressure comes from HBM (High-bandwidth memor), the stacked memory used beside Nvidia GPUs. HBM is hard to scale because it needs advanced DRAM, stacking, packaging, testing, and close work with GPU designers, which is why SK hynix is working with Nvidia and TSMC on HBM4 base dies. --- The global memory market. The global memory market has 2 main layers: DRAM, which includes the memory used next to CPUs and AI GPUs, and NAND flash, which is the storage inside SSDs, phones, and data centers. In DRAM, the market is extremely concentrated, with Samsung at 38.5%, SK hynix at 28.8%, and Micron at 22.4% in 1Q26, meaning the top 3 control about 90% of global DRAM revenue. In HBM, which is a premium submarket inside DRAM, the AI-specific memory used beside Nvidia GPUs, SK hynix is the market leader, with 58% share in 1Q26, while Samsung and Micron each had 21%. HBM, or High Bandwidth Memory, is a special form of DRAM built for extreme data movement. The difference is physical design. Normal DRAM chips usually sit on memory modules or near the processor, and data moves through relatively narrower connections. HBM stacks multiple DRAM dies vertically and places them very close to the GPU through advanced packaging, which creates a much wider data path. That wider path gives AI chips much higher memory bandwidth, meaning the GPU can receive data faster instead of sitting idle.

译为应对AI驱动的巨大需求，SK hynix计划在五年内将其晶圆产能翻倍，但仍预计供应紧张局面将持续至2030年。2026年第一季度，其在DRAM市场占比28.8%，在用于AI的HBM市场则以58%的份额领先。HBM因采用垂直堆叠封装以提供更高带宽，但受限于先进DRAM、封装和测试等物理因素，产能难以快速扩张。目前，SK hynix正与Nvidia、TSMC合作开发下一代HBM4基础芯片。

Rohan Paul@rohanpaul_ai · 6月2日48

A 178 page survey study for refreshing math and generative AI foundations from University of Huddersfield. The Little Book of Generative AI Foundations.

译哈德斯菲尔德大学发布了一份178页的调查研究，旨在更新数学和生成式AI的基础知识。 《生成式AI基础小册子》。