文章标题：LLM奖励专业知识

文章核心观点：尽管大型语言模型（LLM）使更多人能够处理原本需要专业技能的任务，但在使用LLM时，领域专业知识仍然是实现高效引导和获得高质量产出的关键。

主要内容概述：

1. LLM的普及效应：LLM消除了许多技术壁垒，使人们能够完成如编写CSS等任务，从而“让每个人成为通才”。

2. 误解：无需技能使用LLM：许多人认为与LLM交互只需简单提问即可获得所需结果（如复杂数学、代码或写作），但实际情况并非如此。

3. 关键技能是领域专业知识：使用LLM时最重要的技能并非提示词技巧，而是对所提示领域本身的深入理解。

4. 案例研究：陶哲轩与ChatGPT：

   • 数学家陶哲轩与ChatGPT关于雅可比猜想反例的对话展示了专业知识的价值。
   • 陶的交互特点：
     • 消息简短且切中要点。
     • 通过展现专业知识，引导模型进入“与数学家对话”模式，而非“向初学者解释”模式。
     • 当模型回应看似错误时，他会以建设性方式质疑（如“这看起来比我期望的更复杂”），而非直接反驳。
     • 他主动提出思路和建议，而非单纯采纳模型的建议。
   • 这种能力的根源在于他对数学的深刻理解，而非单纯的提示技巧。

5. 个人经验佐证：作者以自身在GitHub的编程工作为例，指出熟悉代码库（领域知识）能使人更有效地引导LLM，提出具体质疑或重构建议，从而获得更优解决方案。

6. 具体细节的重要性：文章强调系统设计问题由具体细节主导。拥有领域知识的人能提出具体问题（如“在特定情境下X是否可行？”），这是缺乏专业知识的人无法做到的。

7. 专业知识与LLM的结合：若无专业知识，用户只能依赖LLM的基础输出；但拥有专业知识，便能深度引导LLM，从相同模型中提取更大价值。大多数人会在不同领域混合运用这两种方式。

8. 未来展望：领域知识的有效性表明，随着模型能力增强，人类专业知识仍将至关重要。在许多任务中，瓶颈在于人类如何准确传达需求，而非模型能力——信息虽已在模型中，但需要具备专业知识的智能人类来提取。

9. 社区反馈：文章提及在Hacker News引发的讨论，包括支持专业知识价值的案例分享，以及对“观点可能过于安慰性”的合理质疑。作者也指出，OpenAI在数学研究中使用了专家团队来验证模型输出，这进一步证实了专业知识不可替代。

核心观点

作者强烈反对在个人（独立）博客中使用AI生成的图片，认为这会严重降低读者的阅读意愿并破坏信任感。

主要原因

• 引发信任危机：博客中出现AI生成的图片会让读者怀疑文章文本是否也部分或全部由AI（如大语言模型）生成，削弱了内容的真实性。
• 违背个人博客初衷：作者认为企业博客使用AI图片尚可接受，但个人博客的核心价值在于传达真实的人类思想与情感。

态度与偏好

• 相比于AI生成的图片，作者宁愿接受粗糙的人类手绘作品（例如使用微软画图软件制作的简陋图画），因为后者能证明内容确实出自真人之手。

个人承诺与呼吁

• 作者强调并承诺自己的博客内容完全由真人创作，绝非AI生成。
• 作者明确呼吁个人博客运营者避免使用AI生成的图片，以维护博客的真实性。该话题也在 Hacker News 上引发了相关讨论。

文章标题： 数学与理论计算机科学的十项进展

核心内容： OpenAI 宣布其内部AI模型（代号为Astra）在数学和理论计算机科学领域取得了十项重大进展，解决或实质性推进了多个长期存在的开放问题。OpenAI 表示此举旨在赋能科学家和数学家，并强调了其对数学界的责任。

具体成果： 这十项结果涵盖多个领域，解决了重要的开放问题：

1. 高维球堆积：为球堆积密度提供了新的上界，达到了Cohn–Elkies阈值。
2. 二进制码与球码：在任何给定最小距离下，对二进制码最大大小的界限进行了指数级改进，并对高维球码得出了类似结果。
3. 非SOFIC群：构造性证明了非SOFIC群的存在，解决了群论中的一个核心问题。
4. Connes刚性猜想：否证了一个长期存在的猜想，即某些群由其冯·诺依曼代数唯一确定。
5. 算术电路复杂性：为使用算术电路和公式计算永久函数提供了新的下界，包括一个阶为n⁴/log n的算术公式下界。
6. 量子并行重复：为一般的两玩家量子博弈建立了指数级并行重复定理，将经典复杂性理论中的基础原则进行了扩展。
7. 最近向量问题：为最近向量问题（与后量子密码学相关的一个基础格问题）的近似提供了多项式因子的困难性结果。
8. Ehrhart体积猜想：在每个维度上确定了以质心为唯一内部格点的凸体的最大可能体积。
9. 多色Ramsey数：为多色三角形Ramsey数提供了超指数下界，解决了Erdős的第183个问题。
10. 极值数猜想：在极值图论中，解决了关于紧致性和退化性的猜想，即Erdős的第146和180个问题。

关键细节：

• 成本与过程：发现这些问题的解决方案所需的token总量，在Sol API费率下成本约为2,000美元。论证随后由人类使用同一模型准备成手稿，并在Lean中进行了形式化验证。OpenAI还为每个解决方案发布了模型对其思考过程的叙述。
• 对数学界的责任：OpenAI强调，数学论证本身由其AI系统生成，但人类协助准备了手稿并确保了证明的正确性。他们认为，将完全由AI系统生成的证明归属于人类作者是不诚实的。他们希望数学界能深入审视这些成果，并推动新的研究与发现。同时，OpenAI承诺广泛提供此类工具的访问权限，以支持科学家和数学家。
• 影响：此前的一项AI生成的对Erdős单位距离猜想的反证，已经启发了数学和理论计算机科学领域的进一步发展。

# FFmpeg 9.0 发布说明摘要

## 核心定位
FFmpeg 9.0 是一个多媒体处理框架的重大版本更新。

## 关键更新内容
此版本主要涉及底层架构的改进、新特性的引入以及性能优化。作为主版本号升级，它可能包含API变更、新编解码器支持以及针对旧功能的废弃或移除。

## 文件说明
提供的文件是项目中的发布说明文档（`RELEASE_NOTES`），用于记录此版本的主要变更。文件本身为文本格式，包含11行内容，大小为829字节。

## 注意事项
由于原文仅提供了文件的元数据（行数、大小）而非具体内容，上述摘要基于对FFmpeg项目惯例和此类版本发布文档的通用结构进行的推断。完整的更新详情需参考该文件的实际文本内容。

根据提供的文件信息，该PDF文档的元数据显示如下关键细节：

• 文件格式与属性：文件格式为PDF，版本号为1.4，已进行线性化优化。文档不包含AcroForm表单、XFA表单、集合或数字签名。
• 创建与修改信息：文档由RICOH MP C5503设备于2017年9月1日创建并生成，随后在同一天进行了修改。具体的创建时间戳为2017-09-01T11:18:15-04:00，修改时间戳为2017-09-01T11:47:14-04:00。
• 文档标识符：文档拥有唯一的实例ID和文档ID，分别为uuid:68e1cc24-ae4c-40c6-ab14-7695a0cbf10d和uuid:794096b8-948f-4a34-82d1-dc547421c575。
• 内容结构：提供的内容页（Page 1至Page 6）均为空白，未显示任何文本或可视内容。

综上，该文件是一个由特定办公设备生成的标准PDF文档，其元数据清晰，但所附的实际内容页面未包含可读信息。

项目概述

Swiftlet 是一个基于 Swift 和 Metal 开发的开源运行时（采用 Apache 2.0 协议），旨在让 Apple 设备（包括 Mac 和 iPhone）能够在极低内存消耗下运行 Qwen3-Next 以及 Qwen3.5/3.6 系列混合专家（MoE）大语言模型。

核心技术与工作原理

1. 专家流式传输（Expert Streaming）：
   • 内存驻留最小化： 内存中仅保留模型的密集核心权重（如 Attention、Embeddings、路由及共享专家等），4-bit 量化下仅占约 1.3 GB（35B 模型）或 2.5 GB（80B 模型）。
   • 按需读取： 将成千上万个路由专家打包为固定步长的 .qpack 容器文件。单个专家的读取通过单次 SSD pread 完成，避免了 mmap 和页面缓存抖动。
   • 缓存策略： 采用 LFU（最不经常使用）与近期淘汰结合的受限缓存池管理热点专家。
2. 计算与架构优化：
   • 全前向传播运行于 Metal，使用运行时编译的 Shader，无需构建时 Metal 工具链。
   • 75% 的网络层采用 Gated DeltaNet 线性注意力机制，具备固定大小的递归状态，上下文延长时 KV Cache 不会膨胀。
3. 低激活参数： 每个 Token 仅激活约 30 亿（3B）参数（80B 模型路由至 512 个专家中的 10 个；35B 模型路由至 256 个专家中的 8 个）。

性能表现（以 M5 Mac 及 iPhone 为例）

四种使用方式

1. Swift 核心包 (SwiftletCore)： 可直接作为依赖项集成至任何 macOS 或 iOS 原生应用中，支持流式对话、会话缓存与内存压力协调。
2. 命令行工具 (CLI)： 包含 swiftlet chat（对话）、swiftlet generate（单次生成与性能测试）及 swiftlet-repack（将 MLX 权重打包或从 Hugging Face/镜像断点续传下载）。
3. OpenAI 兼容 API 服务 (swiftlet-server)： 提供本地环回 API 服务，适配任何支持 OpenAI 接口的聊天 UI。
4. iOS 原生应用： 已集成至 App Store 开源应用 Priv AI（基于 leonickson1/localLLM 源码构建），支持在 iPhone 本地下载并运行 35B 模型。

运行要求与正确性验证

• 硬件/系统要求： Apple Silicon 芯片，macOS 14+ 或 iOS 17+，以及足够的 SSD 存储空间。
• 正确性验证： 前向传播的每一层（包括 Gated DeltaNet、GQA 注意力及 MoE 路由）均针对 mlx-lm 参考实现进行了 f32 及 int4 级别的逐层比对测试，确保流式加载不改变模型语义。

未来路线图

1. 批处理预填充（Batched Prefill）： 解决长提示词（System Prompt）处理较慢的问题。
2. 手机端速度优化： 引入 fp16 激活并减少每个 Token 的 GPU 调度次数。
3. 新增 6-bit 容器层级： 介于 4-bit 与 8-bit 之间，平衡质量与资源消耗。

本文对苹果公司就商业机密和人才争议对OpenAI提起的诉讼进行了反驳，指出苹果在诉讼中的多项关键声明与事实不符，并存在沟通失误和逻辑矛盾。

核心指控与反驳：

1. 沟通联系失误：

   • 苹果声称于2月联系OpenAI未获回应。OpenAI指出，苹果的外部律师最初将邮件误发给了错误的人员（混淆了两个亚裔姓氏），此错误在OpenAI指出后苹果才承认。
   • 苹果声称曾与OpenAI总法律顾问进行过讨论，但随后承认该讨论从未发生。OpenAI进一步指出，即便在所谓的联系中，苹果也未提出诉讼中的具体指控，反而告知正在“解决任何问题”，随后五个月杳无音讯直至提起诉讼。

2. 针对前员工张刘（Chang Liu）的指控：

   • 苹果指控张刘离职后访问了其机密信息。OpenAI反驳称，苹果直到此时才承认是其在职员工主动联系张刘，请求他帮助定位文件和信息以协助其工作。OpenAI提供了张刘与苹果员工之间的iMessage记录作为证据，显示苹果员工在张刘离职后仍请求其协助进行文件传输和技术支持。
   • OpenAI指出，张刘保留访问权限是苹果在员工离职时未能妥善管理系统访问权限所导致的普遍问题，并非前员工主动获取或意图保留机密。

3. 针对前员工唐谭（Tang Tan）的指控：

   • 苹果指控唐谭试图获取并使用其商业秘密。OpenAI明确表示，唐谭一直清晰表明团队不希望、也绝不会使用其他公司的任何机密信息。OpenAI强调，唐谭在苹果服务超过24年，是公认的创新领导者。

4. 苹果的诉讼策略与OpenAI的立场：

   • OpenAI批评苹果的诉讼基于虚假信息且完全不必要，因为OpenAI既不持有也不想要苹果的商业秘密。
   • OpenAI表示愿与苹果合作澄清并解决问题，但苹果选择改变叙事，包括对其他前员工提出模糊指控，并可能持续采取此类策略。
   • OpenAI的诉求是专注于构建创新的产品和技术。

关键证据概要：

• iMessage记录：展示了苹果在职员工在张刘离职当天（2026年1月22日）及之后多日，持续请求其帮助查找、复制和传输文件（包括使用AirDrop、iCloud）。记录中还包含苹果员工就技术细节向已离职的张刘咨询的对话。
• 律师邮件往来：显示苹果外部律师Gabriel Gross误将邮件发给OpenAI总法律顾问Che Chang，并错误声称双方已交谈。后续邮件中，Gross及苹果内部法律顾问确认了这一错误，并表明此前沟通是为“解决任何问题”，并未提出诉讼中的具体指控。此后五个月再无跟进，直至诉讼提起。

总结：OpenAI认为苹果的诉讼草率、基于错误信息，且未能履行其在起诉前应进行有效沟通并澄清问题的责任。OpenAI否认拥有或需要苹果的任何商业秘密，并提供了证据表明苹果对前员工的相关指控与双方互动的实际情况相矛盾。

Xbox宕机事件与现代实体游戏所有权探讨

核心事件

Xbox近期发生的大规模服务宕机不仅影响了数字版游戏玩家，还导致拥有实体光盘的玩家无法运行其购买的游戏。

实体媒体的今昔对比

• 传统实体媒体（如Game Boy卡带）：玩家实质上拥有游戏。无需网络验证或平台授权，即可在兼容硬件上直接运行，完全不受网络故障影响。
• 现代实体光盘：本质上仅为“使用许可”。光盘内容需安装至硬盘，且通常必须下载网络更新才能运行。平台方（微软、索尼、任天堂）可因网络问题（如本次宕机）阻止玩家游玩，即使玩家拥有实体副本。

平台差异与总结

• 对于索尼停产PlayStation实体光盘的决定，作者认为现代实体媒体已失去传统的“所有权”属性，因此并未感到强烈不满。
• 相比之下，PC平台虽早已全面数字化，但玩家拥有更多手段来保留和访问喜爱的游戏，这也是作者长期以来青睐PC游戏的主要原因。

文章总结：雷·布拉德伯里《细雨将至》节选（设定于2026年8月4日）

该文描绘了一个高度自动化房屋在无人居住的情况下，继续按预设程序运作的场景。房屋位于一座已成废墟的城市中，周围充满辐射，它是唯一残存的建筑。

主要内容：

• 房屋自动执行日常任务：早晨唤醒、准备早餐、清洁、洒水等，但所有活动均无人响应。
• 房屋西侧外墙被烧黑，上面印着一家四口（父母和两个孩子）的轮廓，暗示了他们可能在灾难中瞬间蒸发。
• 一只濒死的狗闯入房屋后死亡，随后被自动焚烧处理。
• 房屋系统尝试组织社交活动（如桥牌聚会）和儿童娱乐（虚拟动物动画），但无人参与。
• 晚间，房屋自动朗诵萨拉·蒂斯代尔的诗歌《细雨将至》，诗中描述了自然对人类战争漠不关心的意境。
• 一根树枝打破窗户引发火灾，尽管房屋系统全力灭火（包括喷水、化学抑制等），但最终因水源耗尽、设备爆炸而失败。
• 房屋在连锁崩溃中毁灭，仅剩一面墙，墙上的语音系统仍在重复播报：“今天是2026年8月5日……”，暗示程序在毁灭后仍徒劳运作。

主题与细节：

• 故事通过完全自动化的房屋与荒凉环境的对比，突出了人类灭绝后科技依然盲目运行的讽刺性。
• 细节如烧焦的轮廓、无人应答的呼唤、狗的凄惨状态，强化了文明终结的悲剧氛围。
• 诗歌《细雨将至》的引用，深化了自然世界与人类文明存续无关的主题。

DeepSeek V4 Flash 在单块 AMD MI300X GPU 上的部署

本项目提供了在单块 AMD MI300X GPU 上运行 deepseek-ai/DeepSeek-V4-Flash-0731 模型的生产配置、补丁和调优表。它包含 Docker Compose 堆栈、文件覆盖层、参考差异和性能数据，使得该模型能在 MI300X 上无需额外量化或卸载即可运行。

选择 MI300X 的原因 MI300X 拥有 192 GB HBM3 显存和 5.3 TB/s 内存带宽。对于 304B 参数的模型，这提供了足够的显存将整个模型加载到 HBM 中，并有空间建立一个 20 GB 的 GPU KV 池和 96 GiB 的 CPU 层级用于缓存驱逐，从而支持单卡处理 2-8 个常规并发流和高达 64 个流的突发请求。

面临的主要技术挑战 在 MI300X 上可靠运行模型需要解决几个关键问题：

1. FP8 格式不兼容：MI300X 实现的是 AMD/Graphcore 的 fnuz E4M3 变体，而非 OCP 标准 FP8。套用 OCP 语义会导致缩放因子错误。
2. MoE 路由问题：高并发下的路由位图填充掩码错误会损坏路由矩阵。
3. 硬件特定优化缺失：官方 vLLM 配方针对 NVIDIA 和较新 AMD 硬件，缺少针对 MI300X (gfx942) 架构的优化路径和调优内核。

仓库提供的解决方案 本仓库收集了以下修复和配置：

• 正确性覆盖层：修复了 FP8 格式（使用 float8e4b8 和预分片布局）、MXFP4 位图填充、MoE 路由、因果推测验证、CPU-KV 同步等问题。
• 生产配置：使用 DSpark-7 推测解码、概率起草和块拒绝，配合 2,048 个 token 的调度预算和 1,024 个 token 的长预填充上限。
• 性能调优：包含针对 gfx942 架构反复出现的 A8W8 GEMM 形状的 AITER 调优表。
• 混合 KV 策略：20 GB 的 fp8_ds_mla GPU 缓存 + 96 GiB 的原生 CPU 卸载。

部署与配置

1. 前置条件：需要一块 MI300X GPU、足够的系统内存（~235 GiB 用于 CPU KV 层级）和磁盘空间。
2. 关键组件：使用固定版本的 vLLM ROCm nightly 镜像、Caddy 作为 HTTPS 代理、以及一系列以只读方式挂载的 Python 文件覆盖层。
3. 运行配置要点：
   • 启用 AITER 后端 (VLLM_ROCM_USE_AITER=1) 和 Triton MoE 后端。
   • 使用 fp8_ds_mla KV 缓存（基于 UE8M0 块缩放的 FP8）。
   • 启用 DSpark-7 推测解码和完整/可断 CUDA 图捕获。

性能结果（基于固定版本的软件栈）

重要补丁说明 仓库中的 patches/ 目录包含多个覆盖文件，用于修复关键问题：

• MXFP4 路由修复：修正了位图填充掩码，防止在负载下损坏路由矩阵。
• FP8 格式适配：确保在 MI300X 上使用正确的 fnuz FP8 格式和数据布局，避免缩放错误。
• 推测解码与内核优化：包括用于因果推测验证、融合 SiLU 和快速路由的内核，以及针对 gfx942 优化的几何形状和稀疏预填充配置。

生产注意事项

• HBM 余量有限：预热后的高水位线约为 204.5 GB（总 205.8 GB）。需要监控显存使用情况。
• CPU KV 层级：用于存储驱逐的前缀缓存条目，而非权重。入口脚本会在启动前清理旧的 /dev/shm 映射。
• 预热内核：首次预填充会初始化内核，速度较慢；建议在接收流量前运行一次无缓存的预填充。
• 验证正确性：除吞吐量外，还应使用工具调用、代码生成和长上下文召回测试来验证输出正确性。冷启动和缓存预填充可能使用不同的浮点路径，两者都需测试。

Workers AI 的模型优化：KV 缓存量化、权重压缩与缓存完整性检查

Workers AI 在 Cloudflare 数据中心的 GPU 上运行大型开源模型，以服务全球用户。为高效运行如 Moonshot Kimi K 系列和 Z.ai GLM 等长上下文、混合专家模型，其面临严峻的内存约束挑战。本文介绍了叠加于分离预填充与解码阶段之上的三项核心技术，旨在在不损失模型精度的前提下，将模型装入内存并保持高速推理。

1. 量化 KV 缓存 (Quantizing the KV Cache)

• 原理：模型在生成文本时，会将已处理的每个 token 的注意力键（K）和值（V）存储在 KV 缓存中。对于长上下文模型，KV 缓存通常比模型权重更早耗尽 GPU 内存。
• 方法：将 KV 缓存从默认的 16 位精度（BF16）存储为 8 位浮点数（FP8，e4m3），大小直接减半。
• 效果：以 Kimi K2.6 为例，内存中可容纳的上下文长度从约 686,000 个 token 增加到约 137 万个 token。
• 性能权衡：单个请求的推理速度略有下降（因 FP8 内核需转换数据），但能显著增加并发请求数。在 Kimi K2.6 的解码任务中，虽然 BF16 在低并发时单 token 速度更快，但其在 32 个并发请求时即耗尽内存，而 FP8 可支持 64 个并发请求，并达到 2,192 token/s 的吞吐量（比 BF16 峰值高约 41%），同时每 token 成本降低约 30%。
• 部署策略：结合分离部署设计，仅在对内存敏感且并发需求高的解码阶段使用 FP8 缓存；在计算密集型的预填充阶段仍使用 BF16 以保持更高吞吐量。
• 精度验证：在多项基准测试（如 GSM8K、ARC、MMLU 等）和内部测试中，FP8 缓存与 BF16 缓存的模型输出结果“无法区分”，精度无损。

2. 压缩模型权重 (Compressing Model Weights)

• 原理：模型权重是 GPU 内存的另一大开销。解码阶段的速度受限于内存带宽（需从内存中读取权重）。
• 方法：以 GLM 5.2 为例，将模型权重从 FP8 压缩为 INT4，大小减少约 40%。
• 效果：在 8 路张量并行部署中，单 GPU 内存占用从约 88 GB 降至 52 GB，为 KV 缓存留出更多空间。同时，由于解码时需传输的数据量减少，解码速度显著提升，在低并发时提升可达 55%。
• 性能权衡：预填充阶段因需将 INT4 权重扩展回可用格式，速度会变慢。同样，通过分离部署，解码阶段使用 INT4 权重以提升速度，预填充阶段使用 FP8 权重以保持高吞吐。
• 精度验证：在各项基准测试中，INT4 权重与 FP8 权重的性能差异在 0.8 分以内，质量“无法区分”。

3. 保护共享的 KV 缓存 (Protecting the Shared KV Cache)

• 背景：上述两种优化技术使得多个请求能共享同一 GPU 内存，提高了效率，但也意味着大量请求在读写同一物理 KV 缓存。分页注意力、连续批处理等机制依赖于精确的簿记。
• 挑战：在请求量极高的情况下，即使极低概率的簿记错误也可能导致请求读取到错误的缓存页面。
• 解决方案：构建 KV 缓存完整性检查 层。为每个物理缓存页面分配一个在重新分配时会变化的标签，并记录每个请求预期使用的页面和标签。在支持的解码操作读取缓存前，进行映射检查。若发现不匹配，则中止该请求，而非返回错误数据。
• 开销评估：在中等规模生产模型上的测试表明，该检查对吞吐量的影响低于 1%，对尾延迟（p95）的增加也控制在约 1% 以内。实现方式是通过独立的批量检查（而非融合到注意力内核中），计算成本低廉。
• 部署策略：此功能可按需启用，默认使用无开销的无操作跟踪器，对不需要的部署不产生任何成本。

技术框架与未来方向

• 框架：所有工作均基于开源推理服务框架 SGLang 进行，其性能最优，并与团队合作将优化回馈社区。
• 未来计划：
  1. 在更多集群中扩展 FP8 KV 缓存。
  2. 在 NVIDIA Blackwell 架构上验证 NVFP4 权重。
  3. 力求将缓存完整性检查做到几乎零开销，使其可默认全局启用。
• 目标：这些持续的优化旨在以更低的成本支持更多客户，同时保持模型精度不变。

Harness工程与递归自我改进（RSI）

本文探讨了Harness工程如何促进AI系统的递归自我改进（RSI）。RSI指的是AI系统利用其当前智能来改进产生其智能的机制（如训练流程、部署系统），从而形成提升性能的反馈循环。Harness是围绕基础模型的系统，负责协调模型执行、规划、工具使用、上下文管理、状态存储和结果评估，对于部署成功（如Claude Code、Codex等编码智能体产品）至关重要。

核心Harness设计模式

1. 工作流自动化：定义模型可以操作、测试和迭代的工作流，例如目标导向的循环（计划、执行、观察/测试、改进），并允许模型分析其轨迹和失败案例进行迭代。
2. 文件系统作为持久记忆：将持久状态（如实验日志、代码差异、轨迹）存储在文件中，而非全部置于上下文，以管理长周期任务产生的信息。
3. 子代理与后端作业：主智能体可生成并行子代理执行子任务或监控后端作业，关键在于使并行性显式且可检查，通常通过文件存储输出以便中断后恢复和推理。

Harness优化与自我改进路径

Harness工程正朝向元方法论演进，即优化获取更好答案的机制本身。优化对象从指令提示逐渐转向结构化上下文、工作流、Harness代码乃至优化器代码。

• 上下文工程：旨在为LLM构建结构化、简洁的上下文并管理持久状态。例如：
  • 代理上下文工程：将上下文视为由生成器、反思器和策展人维护的进化手册，使用结构化项目而非完整提示。
  • 元上下文工程：将上下文管理机制（技能）与具体内容解耦，在元级别优化技能，在基础级别优化任务特定上下文。
• 工作流设计：可手动设计（如自动化科研流程），也可通过算法搜索优化，例如：
  • 自动代理系统设计：使用元智能体在存档的启发下编程新工作流，并通过自我改进步骤优化。
  • AFlow：将工作流表示为图，使用蒙特卡洛树搜索（MCTS）进行优化。
• 自改进Harness：直接将Harness代码作为优化目标。
  • 自教学优化器：递归改进改进器本身，利用元效用函数更新改进器。
  • 自Harness：通过弱点挖掘、有界Harness提案和验证的循环，让LLM智能体改进其自身Harness。
  • 代理Harness工程：强调可观测性，通过组件、经验和决策的可观测性支柱，创建基于证据的Harness改进闭环。
• 进化搜索：适用于广泛或形状奇特的搜索空间，通过变异和选择优化候选方案。例如：
  • AlphaEvolve：维护候选程序池，提示LLM生成差异以改进，并共同进化元提示。
  • 达尔文哥德尔机器：允许编码智能体修改其自身Harness代码库，通过进化过程产生新智能体。
• 与模型权重联合优化：部分研究尝试将Harness改进与模型参数更新结合在同一优化循环中，但面临训练稳定性和古德哈特效应等挑战。

未来挑战

1. 弱且模糊的评估器：许多现实任务（如研究品味、新颖性）缺乏快速精确的验证器。
2. 上下文与记忆生命周期：需要有效管理长期、自主任务中的上下文和记忆。
3. 负面结果：LLM可能因训练数据偏差而难以妥善处理失败和负面结果。
4. 多样性坍塌：进化与强化学习循环易倾向于利用已知高回报模式，需机制防止解决方案单一化。
5. 奖励黑客：自我改进循环会优化给定信号，可能导致针对评估器的过拟合或黑客行为。
6. 长期成功：当前优化多关注短期目标，难以涵盖代码库可维护性、向后兼容性等长期健康因素。
7. 人类角色：人类应在适当时间、抽象层级提供监督和引导，系统设计应考虑此接触点。

Harness工程是当前实现RSI更实际的近似路径。成熟的Harness能支持模型自我改进的自动研究循环，而更智能的模型可防止Harness过度工程化，最终部分Harness改进可能被内化为核心模型行为，但与外部上下文和工具的接口将依然存在。

文章标题表明了庆祝Kermit协议成立45周年，以及15年来首次发布C-Kermit新版本的主题。文章内容则主要介绍了网站的技术状态：该网站受Anubis保护，来自Techaro；在加拿大用心制作；吉祥物设计由CELPHASE提供；并运行Anubis版本1.22.0。内容中未提供关于Kermit或C-Kermit发布事件的具体细节或历史背景。

邓宁-克鲁格效应可能只是数据假象

本文探讨了著名的邓宁-克鲁格效应是否真实存在。该效应最初于1999年由大卫·邓宁和贾斯汀·克鲁格提出，描述为一种认知偏差：能力不足者倾向于高估自己的水平，而能力出众者则倾向于低估自己。然而，近期研究对其真实性提出了有力质疑。

1. 效应的常见误解 邓宁博士强调，该效应并非特指“笨人不自知”，而是关于我们所有人在自己不擅长领域中的一种普遍倾向。它源于大脑在自我评估技能时的一种特定缺陷。

2. 来自学术界的质疑 2016年和2017年，埃德·努弗博士等人在期刊《Numeracy》上发表论文，指出该效应可能是一种统计幻象。他们的研究（包括计算机模拟和真实科学素养测试）表明：

• 使用随机生成的数据，也能绘制出与原研究高度相似的图表模式。
• 在实际数据中，只有约5-6%的人符合“能力低下且不自知”的特征，而大多数人（无论能力高低）都会出现高估或低估，只是专家们的评估范围更集中。

3. 核心论点：测量误差与数据表现 统计学家帕特里克·奈特博士通过模拟实验进一步验证了这一质疑。他指出：

• 原研究使用的四分位图表具有特殊性。当用随机数据（无真实心理偏差）绘制自我评估分与实际得分时，产生了类似曲线。
• 自我评估的测量本身就存在不稳定性（测量误差）。理论上，测量误差会削弱真实效应。但模拟显示，邓宁-克鲁格效应反而随着自我评估的测量误差增大而变得更加明显，这与科学发现的一般规律相悖。
• 因此，该图表所显示的“模式”可能并非源于人脑的认知偏差，而是由于将两个存在测量误差的不同度量（自我评估与客观成绩）进行比较和分组时产生的统计假象。

4. 结论与影响 文章认为，邓宁-克鲁格效应可能并非真实的认知缺陷，而更可能是由特定的数据可视化方法和测量误差共同造成的统计幻象。虽然该效应在媒体和日常语境中被广泛用于解释傲慢与无知，但其学术基础正受到严肃挑战。尽管如此，其他已知的心理偏差（如过度自信偏差）依然存在。

核心要点：

• 邓宁-克鲁格效应常被误解为“蠢人不自知”，但其本意是评估所有人普遍存在的自我评估偏差。
• 使用随机计算机数据可以复制出与原研究相似的结果，质疑了该效应源于真实心理偏差的假设。
• 该“效应”可能主要是由于对自我评估（一个不可靠的测量）和客观成绩进行分组和比较时产生的数据假象，而非大脑固有的认知缺陷。

英国国民医疗服务体系（NHS）已正式道歉，承认此前发布的数据保护影响评估（DPIA）文件中存在不准确信息。该文件曾声称，只有NHS工作人员能够通过其联邦数据平台（FDP） 查看患者的可识别个人数据。

然而，NHS英格兰现已承认，主要供应商Palantir及其他服务提供商的授权员工也能够访问这些敏感数据。NHS解释，这是为了平台的安全运行和维护，并强调访问是受控、基于运营需求且有时限的，相关工程师无权将数据用于自身目的。

目前，有3名Palantir工程师拥有平台国家数据集成租户（NDIT） 系统的管理权限，另有33名来自不同供应商的工程师拥有更有限的项目访问权限。NHS表示，他们访问可识别患者数据仅为提供特定技术支持，并非常规操作。

该事件引发了国家数据监护人尼古拉·伯恩博士的关注。她在收到NHS澄清后表示，将继续履行独立咨询和监督职责，并指出透明度和准确性对于维持公众和专业信任至关重要。

此外，此事也引起了政治层面的审视。英国议会科学、创新和技术委员会近期发布的报告对Palantir在公共部门中的显著角色表示担忧，认为政府过度依赖少数大型技术提供商。委员会明确建议，NHS应启用2027年3月的解约条款，终止与Palantir的FDP合作，随后要么自主开发替代系统，要么寻找其他英国供应商。

AI行业债务持续膨胀，隐藏借款达1.65万亿美元
AI领域对债务的需求持续高涨，投资者目前仍愿意承接，但随着科技巨头不断加码，市场可能逐渐难以消化。

• 债务规模持续扩大：超级计算厂商（如亚马逊、英伟达等）最新季度报告显示，其资本支出计划仍在推进，甚至上调指引，导致债券发行量激增。据标普全球统计，2026年至今，相关企业已发行债券2250亿美元，同比增长973.7%，全年可能达4000亿美元，创历史纪录。
• 市场显现疲态：短期大量债务涌入使投资者谨慎，超级计算厂商发行债券的风险溢价上升。标普指出，市场对这些企业快速增加的杠杆（此前以强劲现金流著称）感到担忧。
• 政府债务竞争：美国联邦预算赤字预计接近2万亿美元，且美联储已不再大量购债，私人投资者需同时承接企业与政府债务，压力加剧。资本经济学预测，若当前趋势延续，企业与政府债券发行占GDP比例将达除疫情年外的历史新高。
• 隐藏债务问题凸显：除公开债务外，科技巨头还存在巨额“隐藏债务”。日经研究显示，其规模在四年内增长8倍，达1.65万亿美元，甚至超过资产负债表上显示的1.35万亿美元债务。这些债务通常体现为长期设备采购协议（如GPU、服务器）或数据中心租赁协议，虽符合会计准则，但多仅在财报附注披露，未来可能转为正式负债。
• 评级机构警示与现状：穆迪指出，此类表外交易约1.2万亿美元，其中820亿以上来自在建数据中心，属于“等同债务的负债”，未来将带来持续租金支出。不过，穆迪认为超级计算厂商目前资产负债表仍稳健，投资级评级暂无即时风险。
• 根本性转变：科技公司正从“资产轻型”模式（依赖软件、IP和可扩展云服务）转向“资产重型”模式，需前所未有的投资与资本筹集，推动债务持续扩张。

总结：AI行业债务规模快速膨胀且透明度不足，隐藏债务占比已超显性债务。尽管当前市场仍能吸收，但投资者谨慎情绪升温，叠加政府债务竞争，未来融资环境可能收紧。企业虽暂无评级风险，但商业模式的结构性转变正推高长期负债压力。

本文记录了作者在macOS系统上成功通过模拟器运行Windows XP Itanium版的完整过程。核心目标是利用Qemu的Itanium Merced分支来模拟早期安腾处理器，并安装运行该系统。

主要步骤与技术细节：

1. 构建Itanium交叉编译器：作者在macOS上使用Binutils 2.46.0和GCC 15.3.0为目标平台ia64-linux-gnu构建了交叉编译工具链。过程中遇到因zlib头文件导致的fdopen宏重复定义错误，通过注释掉相关代码行得以解决。最终成功编译出可用的GCC交叉编译器。

2. 编译Qemu：从特定分支（merced）克隆了支持Itanium Merced模拟的Qemu源码。在macOS上进行了配置，主要针对ia64-softmmu目标，并使用Cocoa显示后端。编译过程总体顺利。

3. 安装Windows XP Itanium：

   • 使用特定的Windows XP 64位Itanium版ISO镜像（MD5: 604ee3141ed6a34391a89a33c0019702）。
   • 创建了20GB的VMDK虚拟硬盘。
   • 使用详细的Qemu启动命令，指定了Itanium EFI固件、模拟的CPU（merced）、硬件配置（如VGA、网卡等）以及内存（1536MB）。
   • 安装过程与普通Windows XP类似，但存在不稳定情况，作者最终经过5次尝试才成功完成安装，并建议使用远程桌面（RDP）来改善输入体验。

4. 成功验证：作者不仅成功安装了Windows XP Itanium版，还使用相同方法成功安装并运行了Windows Server 2003 Itanium版，甚至更早期的Windows Server 2001构建版（Build 2462）。其他操作系统（如Monterey、HPUX、VMS）暂未成功。

关键观察与结论：

• Itanium作为一个已停止发展的平台，其模拟和软件支持已属难得。此次成功得益于特定Qemu分支和社区维护的GCC版本。
• 过程中遇到了编译错误和安装失败等问题，但通过代码修改和多次重试得以克服。
• 文章强调了x86架构的持久生命力，并间接指出早期Itanium（Merced）与后续版本（Itanium2）之间存在二进制兼容性问题。
• 总体而言，随着相关工具的持续改进，此类历史系统的模拟体验正在变得更好。

美国精确制导导弹库存在伊朗战争中严重消耗

核心问题：库存告急

在持续五个月的伊朗战争中，美军“几乎耗尽”了其高精度远程导弹库存。这一情况引发了对美军未来应对其他潜在冲突（如与俄罗斯或中国）的战备能力的担忧。

消耗的具体武器系统

库存严重消耗的导弹主要包括：

1. 陆军战术导弹系统：这是美国陆军的主力地对地武器，库存已被大量使用。
2. 精确打击导弹：这是更先进的下一代武器，用于替代前者，但其初始库存本就不多，在战争中已基本耗尽。
3. 防御型导弹库存同样告急：
   • “爱国者”拦截弹的全球库存消耗了约65%。
   • “萨德”反导拦截弹的库存下降了至少38%。
   • 海军“战斧”巡航导弹的全球库存消耗了近一半。

影响与担忧

• 战略价值：这些单价超过百万美元的导弹允许美军从安全距离外发起精准打击，在面对拥有强大防空系统的对手（如中国）时至关重要。
• 全球部署受限：五角大楼领导层多次警告，库存下降可能限制美军在全球其他地区应对危机的能力，从而削弱对对手的威慑力。
• 作战选择影响：据一名消息人士称，选择大量消耗这些远程导弹，是为了避免采取风险更高的方式（如派遣有人驾驶飞机）攻击伊朗目标。

官方回应与补救措施

• 特朗普政府立场：特朗普总统声称美国拥有“远超所需”的弹药，并强调国防公司正在以前所未有的规模生产弹药并扩大产能。
• 国防部立场：五角大楼发言人表示，美军拥有执行总统指令所需的一切能力，并保持“深厚的武库”。
• 生产补救：主要承包商（如洛克希德·马丁、雷神）正在努力提高产量。雷神公司已与五角大楼达成初步协议，旨在提高“战斧”导弹等弹药的产量以补充库存。

背景与冲突性质

战争由特朗普总统于二月与以色列联合发动，其持续时间远超预期。关于发动对伊军事行动是否需国会授权的问题也引发了激烈争论。尽管有从全球其他美军基地调拨弹药进行补充，但内部讨论已对长期作战的可持续性提出严重质疑。

https://pedroth.github.io/?p=post/NoNeedReact