Prime Intellect 推出了 **Prime Agent**，这是一个开源的自我提升型编码工具框架，旨在突破静态、人工设计智能体架构的局限。与传统框架不同，Prime Agent 将模型视为一个递归、自适应的系统，构建在两个核心抽象之上：
* **递归语言模型（RLM）：** 将上下文视为变量，并将子智能体委托视为持久化 IPython REPL 中的程序函数调用。这实现了深度嵌套的编排和高效的内存管理。
* **持续进化工具（Continual Harness）：** 允许智能体将其自身的提示词、技能、记忆和子智能体视为可创建、读取、更新或删除（CRUD）的对象。通过 `/refine` 流水线，智能体能根据过去的成功与失败自主提升自身性能。
Prime Agent 具备后台守护进程，支持持久会话、智能体间通信以及长周期任务的自主执行。在评估中，Prime Agent 在 ARC-AGI-3 和复杂编码任务等既有模型及基准测试中，表现出与顶尖水平相当甚至更优的性能，且通常以更少的 Token 用量获得更高的分数。通过实现模型与工具的协同学习，Prime Agent 旨在推动行业向直接的程序化控制转变，以不断演进的自主架构取代僵化且依赖提示词的设计。
每日HackerNews RSS
```json
{
"promptFeedback": {
"blockReason": "内容违规"
},
"usageMetadata": {
"promptTokenCount": 5375,
"totalTokenCount": 5375,
"promptTokensDetails": [
{
"modality": "文本",
"tokenCount": 5375
}
],
"serviceTier": "标准"
},
"modelVersion": "gemini-3.1-flash-lite",
"responseId": "WMl1apa7JYOmjuMPrtbc4As"
}
```
这篇 Hacker News 的讨论围绕着一篇分析电影《银翼杀手》片头字幕的博文展开。虽然作者称赞其排版和设计选择“令人惊叹”，但社区反应两极分化，引发了关于美学、电影史和现代技术的广泛争论。
**讨论要点包括：**
* **设计与排版：** 爱好者欣赏其独特的排版选择及序列中体现的“深思熟虑”；而批评者则认为布局平淡无奇，质疑这种赞誉是否言过其实，或仅仅是主观偏好。
* **音频的作用：** 许多参与者指出，片头字幕的效果离不开范吉利斯（Vangelis）沉浸式的配乐与音效设计；相比文字本身，正是这些声音构建了紧张感并定义了世界观。
* **人工智能与现代内容：** 讨论中很大一部分内容集中在文章本身是否由大语言模型（LLM）撰写。这引发了对当前时代精神的更广泛担忧，即那种戏剧化的“银翼杀手风格”文风正成为内容创作中无处不在的套路。
* **音乐与专业素养：** 讨论串中还提到了一些关于标志性音乐人（如范吉利斯和汉斯·季默）的趣闻，他们无需正式乐谱就能创作出杰作，强调了直觉胜过学院派训练。
NVIDIA 的新款 88 核“Vera”服务器 CPU 采用“Olympus”Arm v9.2 架构，是一款高性能单体芯片，具备先进的数值预测、图形预取器以及高达 1.2 TB/s 的 LPDDR5X 内存子系统。早期有限的测试表明，该架构确实实力雄厚，在某些指标上很可能超越了当前的 x86 竞争对手。
然而，随发布会一同公布的 45 页白皮书因其误导性的营销手法而受到猛烈抨击。该白皮书将 x86 SMT（同步多线程）和芯粒（Chiplet）架构等常见的行业做法刻画为固有缺陷，以此人为地提升 Vera 的形象。文中频繁歪曲竞争对手的配置，使用模糊或非标准的“智能体”（agentic）基准测试，并依赖非科学的象形图而非可复现的数据。
尽管该硬件本身似乎是 Arm 服务器技术的一次重大飞跃，但 NVIDIA 试图强行构建超越 x86 的叙事，却缺乏自身数据的支持。归根结底，该芯片令人印象深刻的技术规格足以自证实力；而这种激进且往往站不住脚的营销，反而可能分散人们的注意力，甚至损害这款本应非常出色的硅片声誉。要验证 Vera 对阵现代 EPYC 和至强处理器的真实性能，仍需进行独立的、不受限制的测试。
Hacker News 上关于英伟达“Vera”白皮书的讨论提出了几个核心担忧：
* **安全漏洞：** 批评者指出，英伟达对“值预测”（投机执行）的关注，可能会重蹈 Spectre 和 Meltdown 等硬件级安全缺陷的覆辙。虽然 ARM 的 DIT 模式提供了一定程度的缓解，但用户担心现代架构在优先级上会忽视安全性。
* **基准测试存疑：** 许多用户批评了该白皮书中的“智能体”性能基准测试。由于其主要集中在编译器任务（GCC、LLVM）上，数据被认为过于局限且存在挑选倾向，无法代表多样化的实际工作负载。
* **企业信任度：** 讨论中提到了英伟达过往存在争议的营销行为，从具有误导性的显存规格到操纵基准测试。评论者对此持怀疑态度，认为该白皮书更像是“大企业的营销手段”，而非客观的技术概述。
* **行业趋势：** 关于技术周期性存在广泛争论，一些参与者指出，业界往往会遗忘过去的安全教训。尽管存在怀疑，但许多人承认英伟达与 AMD 之间的竞争是推动创新的良性动力，即便对营销材料中的性能声明应持谨慎态度。
由于对谷歌日益严格的限制、侵入式追踪以及 AOSP 的衰落感到失望，作者决定将手中的 Fairphone 4 从 Android 系统迁移到 Linux。 在尝试了多个移动端 Linux 发行版后，作者最终选择了 SailfishOS，并对其基于手势的导航、纯正的 Linux 使用体验以及通过 SSH 管理设备的能力表示赞赏。然而，这次迁移并非一帆风顺。SailfishOS 在 Fairphone 上存在库版本过旧以及 Waydroid 支持失效的问题；而作为主要替代方案的 Ubuntu Touch，则缺乏必要的易用性功能和成熟的原生应用。 由于某些关键服务（如银行、政府验证和打车软件）仍依赖 Android，作者保留了一台备用手机作为“热点”设备来处理这些特定任务。尽管面临技术障碍且需要携带备用机，作者依然致力于 Linux 生态，甚至考虑未来更换为 Jolla 官方设备。作者将此次迁移视为一个持续的过程，旨在减少对 Android 的依赖，并推动实现更大的数字主权。
这篇 Hacker News 讨论探讨了从 Android/iOS 转向移动 Linux 所面临的挑战，反映了人们对“双头垄断”以及谷歌对 Android 生态系统日益加强的控制所产生的普遍不满。
**主要观点包括：**
* **Google Play 服务是主要障碍：** 用户认为 Android 的核心操作系统本身性能尚可，但 Google Play 服务已成为一种无法避开的“闭源”层，强制进行追踪并阻碍了用户对设备的真正掌控。
* **“围墙花园”问题：** 许多核心服务（如银行、政府电子证件和交通应用）依赖于特定的专有应用程序，这些应用利用 SafetyNet 或 Play Integrity 检测并拦截非标准设备或已获取 Root 权限的设备。这使得许多人难以将 Linux 手机作为“主力机”使用。
* **硬件与用户体验差距：** 除了软件之外，Linux 手机在相机优化、电源管理和专有键盘“黑科技”（如预测文本）方面仍落后于主流设备。
* **拟议解决方案：** 建议包括在处理日常任务时使用“功能机”，同时保留一台 Android 设备处理受限应用；或是向政府施压，强制推行开放的、基于 Web 标准的银行服务。
* **“折腾者”的视角：** 尽管一些发烧友在 postmarketOS 或 Librem 5 等项目中取得了成功，但大多数人认为，对于普通消费者而言，目前仍无法获得真正可替代移动双头垄断的方案。
现代软件开发在 AI 智能体的推动下，已从线性的任务完成方式转变为并行工作流。这种演变使得传统的标签页界面因频繁的上下文切换而变得低效且令人疲惫。
为了解决这一问题，FlutterFlow 团队开发了 **Campus**，这是一个面向 macOS 的协作式无限二维画布。与仅能展示静态截图的白板工具不同，Campus 直接在画布上承载“实时”应用程序，例如功能终端、浏览器和代码编辑器。这种空间化的处理方式利用了人类的“记忆宫殿”原理，允许用户按功能而非类型来组织工作，从而显著降低切换任务时的认知负荷。
Campus 专为协作式多用户环境而设计。它采用“本地优先”、注重隐私的架构，使工作内容留存在您的设备上，并支持可选的点对点共享以实现实时协作。它甚至还具备“茶水间”风格的阅后即焚聊天功能，以促进远程团队成员之间的人际交流。
Campus 可免费使用，代表了一种向更具整体性、沙盒式工作空间转变的趋势。未来的更新将引入基于 WASM 的扩展、移动端支持以及 3D 功能。现可通过 [campus.flutterflow.io](https://campus.flutterflow.io) 获取。
本网站正在使用安全服务来保护自身免受网络攻击。您刚才的操作触发了安全防御机制。触发此拦截的原因可能有多种，包括提交了特定的词汇或短语、SQL 命令或格式错误的数据。
ACM 最近发表的文章《古德哈特定律适用于你所信任的每一个基准测试》（Goodhart's Law Comes for Every Benchmark You Trust）在 Hacker News 上引发了一波批评。人们不满的并非其内容，而是其被认为带有“人工智能生成”的写作风格。用户迅速指出了大语言模型常见的“破绽”，例如过度的辞藻堆砌以及像“honestly ranked”（诚实排名）这类特定短语，最终导致该文章因违反编辑方针而被删除。
随后的讨论聚焦于古德哈特定律的必然性：一旦指标成为目标，它就不再是可靠的衡量标准。评论者指出，大语言模型的公开基准测试正日益受到操纵，无论是通过数据污染，还是通过优化模型以优先考虑“审美”清晰度而非实际效用。许多用户对标准的 AI 排行榜表示怀疑，认为最有意义的评估是私有的、特定任务的或个人化的衡量。
归根结底，这一讨论反映了人们对人工智能生成的“垃圾内容”日益感到厌倦，并意识到随着大语言模型变得无处不在，区分人类洞察力与模型生成的模仿变得至关重要，尽管这已是一项艰巨的技能。共识在于：当信任被商品化，指标就会失去价值，迫使用户必须依赖自己定制的测试来确定实际性能。
Sula：一个用 Scryer Prolog 编写的 Gemini 协议服务器 Sula: A Gemini protocol server written in Scryer Prolog
3 天前
请启用 JavaScript 和 Cookie 以继续。
这篇 Hacker News 讨论介绍了由 Scryer Prolog 实现的 Gemini 协议服务器 **Sula**。该项目推动了 Scryer Prolog 语言近期的一系列改进，贡献者 `triska` 也鼓励社区参与相关的合并请求（pull requests）。
讨论帖的很大一部分聚焦于 Prolog 相比命令式语言的实用性。支持者认为，Prolog 在“正交”领域表现出色，特别是在系统需要推理、适应并解释自身逻辑的场景中。与标准语言不同，Prolog 允许程序以多种模式运行，从而实现验证协议合规性、枚举边缘情况或补全部分已知数据集等任务。通过将代码视为数据，Prolog 为结果的分析、优化和自动生成解释提供了独特的能力。
对话还提到了定于 2026 年 10 月在维也纳举行的 Scryer Prolog 聚会，并谈及了 Gemini 协议的命名，幽默地将这一网络标准与同名的神话星座进行了对比。
Meta 推出了 **Muse Code (beta)**，这是一款基于终端的编程智能体，由其最新的 **Muse Spark 1.2** 模型驱动。Muse Code 专为复杂的软件工程而设计，通过一套协调一致的持久化异步子智能体系统，实现对整个代码库的规划、编写和验证。 主要功能包括： * **弹性运行时：** 本地事件日志确保操作支持断点续传，使智能体能够在崩溃后准确恢复执行长期任务。 * **高级规划：** 内置工具（如 `/plan`、用于压力测试的 `/grill` 以及 `/goal`）有助于管理复杂的多步骤项目。 * **性能优化：** Muse Spark 1.2 与 Muse Code 联合训练，特别增强了处理长周期任务的能力，例如全代码库生成和迭代调试。 在近期的一项内核优化案例研究中，该智能体通过超过 1000 次工具调用，自主提升了 NVIDIA GPU 内核的性能。Muse Code 现已在 macOS 和 Linux 上可用，Muse Spark 1.2 模型也可通过 Meta Model API 获取。
Meta 发布了 **Muse Spark 1.2** 和 **Muse Code**，这是一款专注于编程的全新 AI 模型及开发工具。此次发布最引人注目的是其极具侵略性的定价策略：对于选择加入“贡献者（contributor）”模式的开发者，Meta 提供了大幅折扣（10 倍至 20 倍），该模式允许 Meta 使用用户输入的数据来训练其模型。
Hacker News 社区对此反应两极分化，主要集中在以下三个方面：
* **信任与隐私：** 许多开发者对 Meta 持怀疑态度，理由是该公司在用户数据和隐私方面劣迹斑斑。批评者警告称，无论合同如何承诺，“贡献者”模式都可能成为搜集专有代码库的手段。然而，支持者则认为，Meta 明确的定价策略比其他实验室更为透明。
* **性能与定价：** 虽然 Muse Spark 1.2 被宣传为具有竞争力的编程模型，但早期的基准测试和用户反馈显示，它在与 Claude 或顶尖模型竞争时表现吃力。许多人将其视为一种中端产品，依靠低价来与 DeepSeek 等对手竞争。
* **市场策略：** 用户质疑 Meta 进入开发者代理市场的举动，推测该公司意在通过此举获取用户关系和遥测数据；另一些人则认为，强制要求使用 Meta/Facebook 账号登录是企业采用该工具的一大障碍。
Proxmox Virtual Environment (VE) 9.2 已正式将其支持范围从 x86-64 扩展至 64 位 ARM (arm64/aarch64)。该版本基于 Debian 13.5 构建，并采用了与 x86-64 版本相同的技术栈（包括 QEMU 11.0 和 ZFS 2.4），是一个完全支持的生产版本，而非技术预览版。 **主要亮点：** * **硬件支持：** 正式支持 NVIDIA Grace Hopper 和 Vera 平台。其他基于 UEFI 的 ARMv9-A（及大多数 ARMv8-A）硬件在“尽力而为”的基础上提供支持。不支持仅使用设备树（Device-tree）的系统，例如树莓派（Raspberry Pi）。 * **统一生态：** 与 x86-64 版本共享相同的代码库、发布周期和企业存储库。 * **架构说明：** 客户机必须在架构匹配的节点上运行；x86-64 与 arm64 之间无法进行在线迁移。所有 arm64 上的虚拟机必须通过 UEFI (AAVMF) 引导。 * **许可授权：** 可通过 Proxmox 销售团队获取 arm64 版本的企业支持和订阅服务。 这一里程碑版本是与 NVIDIA 紧密合作开发的，使 Proxmox 能够在不同 CPU 架构间提供一致的管理体验，并计划根据企业需求扩展平台支持。
Proxmox VE 现已正式支持 ARM64 架构，但开发人员强调，这要求环境必须符合 ACPI 标准并通过 UEFI 启动。因此，仅支持“设备树（device-tree-only）”的单板计算机（SBC）（例如树莓派）不在官方支持范围内，且若无自定义的 UEFI 引导程序，将无法运行。
这一公告在 Hacker News 社区引发了热议：
* **硬件兼容性：** 尽管 Proxmox 不为消费级单板计算机提供企业级支持，但爱好者们指出，如果用户自行提供基于 UEFI 的引导解决方案，该软件在技术上可以在树莓派 4 或 5 等设备上运行。
* **性能与目的：** 一些用户质疑在低功耗单板计算机上运行虚拟机管理程序的价值，并指出陈旧的二手企业级硬件在虚拟化任务中通常具有更高的性价比。
* **技术栈争论：** 讨论还涉及了 Proxmox 对 Perl 语言的持续使用。一位 Proxmox 开发人员在捍卫该语言实用性的同时，强调公司正积极向 Rust 转型以进行新项目的开发。
* **替代方案：** 寻求 Proxmox 替代方案的用户（特别是那些对不同架构或语言方案感兴趣的用户）推荐了 Incus 等平台。