惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Tailwind CSS Blog
大猫的无限游戏
大猫的无限游戏
L
LINUX DO - 热门话题
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
雷峰网
雷峰网
aimingoo的专栏
aimingoo的专栏
博客园_首页
MongoDB | Blog
MongoDB | Blog
V
V2EX
GbyAI
GbyAI
量子位
Microsoft Azure Blog
Microsoft Azure Blog
有赞技术团队
有赞技术团队
G
Google Developers Blog
云风的 BLOG
云风的 BLOG
B
Blog
Microsoft Security Blog
Microsoft Security Blog
S
SegmentFault 最新的问题
O
OpenAI News
N
News and Events Feed by Topic
博客园 - Franky
爱范儿
爱范儿
Forbes - Security
Forbes - Security
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
V2EX - 技术
V2EX - 技术
Application and Cybersecurity Blog
Application and Cybersecurity Blog
N
News and Events Feed by Topic
N
News | PayPal Newsroom
Schneier on Security
Schneier on Security
Cloudbric
Cloudbric
Security Archives - TechRepublic
Security Archives - TechRepublic
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Recent Commits to openclaw:main
Recent Commits to openclaw:main
人人都是产品经理
人人都是产品经理
P
Privacy International News Feed
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
B
Blog RSS Feed
阮一峰的网络日志
阮一峰的网络日志
D
DataBreaches.Net
Last Week in AI
Last Week in AI
罗磊的独立博客
Spread Privacy
Spread Privacy
Recent Announcements
Recent Announcements
The Cloudflare Blog
Google DeepMind News
Google DeepMind News
AWS News Blog
AWS News Blog
The Register - Security
The Register - Security
Y
Y Combinator Blog
J
Java Code Geeks
I
Intezer

Agili 的 Hacker Podcast

Agili 的 Hacker Podcast 2026-07-25 Agili 的 Hacker Podcast 2026-07-24 Agili 的 Hacker Podcast 2026-07-23 Agili 的 Hacker Podcast 2026-07-22 Agili 的 Hacker Podcast 2026-07-21 Agili 的 Hacker Podcast 2026-07-20 Agili 的 Hacker Podcast 2026-07-19 Agili 的 Hacker Podcast 2026-07-18 Agili 的 Hacker Podcast 2026-07-17 Agili 的 Hacker Podcast 2026-07-16 Agili 的 Hacker Podcast 2026-07-15 Agili 的 Hacker Podcast 2026-07-14 Agili 的 Hacker Podcast 2026-07-13 Agili 的 Hacker Podcast 2026-07-12 Agili 的 Hacker Podcast 2026-07-11 Agili 的 Hacker Podcast 2026-07-10 Agili 的 Hacker Podcast 2026-07-08 Agili 的 Hacker Podcast 2026-07-07 Agili 的 Hacker Podcast 2026-07-04 Agili 的 Hacker Podcast 2026-07-06 Agili 的 Hacker Podcast 2026-07-05 Agili 的 Hacker Podcast 2026-07-03 Agili 的 Hacker Podcast 2026-07-02 Agili 的 Hacker Podcast 2026-07-01 Agili 的 Hacker Podcast 2026-06-30 Agili 的 Hacker Podcast 2026-06-29 Agili 的 Hacker Podcast 2026-06-28 Agili 的 Hacker Podcast 2026-06-27 Agili 的 Hacker Podcast 2026-06-26 Agili 的 Hacker Podcast 2026-06-25 Agili 的 Hacker Podcast 2026-06-24 Agili 的 Hacker Podcast 2026-06-23 Agili 的 Hacker Podcast 2026-06-22 Agili 的 Hacker Podcast 2026-06-21 Agili 的 Hacker Podcast 2026-06-20 Agili 的 Hacker Podcast 2026-06-19 Agili 的 Hacker Podcast 2026-06-18 Agili 的 Hacker Podcast 2026-06-17 Agili 的 Hacker Podcast 2026-06-16 Agili 的 Hacker Podcast 2026-06-15 Agili 的 Hacker Podcast 2026-06-14 Agili 的 Hacker Podcast 2026-06-13 Agili 的 Hacker Podcast 2026-06-12 Agili 的 Hacker Podcast 2026-06-11 Agili 的 Hacker Podcast 2026-06-10 Agili 的 Hacker Podcast 2026-06-09 Agili 的 Hacker Podcast 2026-06-08 Agili 的 Hacker Podcast 2026-06-07 Agili 的 Hacker Podcast 2026-06-06 Agili 的 Hacker Podcast 2026-06-05 Agili 的 Hacker Podcast 2026-06-04 Agili 的 Hacker Podcast 2026-06-03 Agili 的 Hacker Podcast 2026-06-02 Agili 的 Hacker Podcast 2026-06-01 Agili 的 Hacker Podcast 2026-05-31 Agili 的 Hacker Podcast 2026-05-30 Agili 的 Hacker Podcast 2026-05-29 Agili 的 Hacker Podcast 2026-05-28 Agili 的 Hacker Podcast 2026-05-27 Agili 的 Hacker Podcast 2026-05-26 Agili 的 Hacker Podcast 2026-05-25 Agili 的 Hacker Podcast 2026-05-24 Agili 的 Hacker Podcast 2026-05-23 Agili 的 Hacker Podcast 2026-05-22 Agili 的 Hacker Podcast 2026-05-21 Agili 的 Hacker Podcast 2026-05-20 Agili 的 Hacker Podcast 2026-05-19 Agili 的 Hacker Podcast 2026-05-18 Agili 的 Hacker Podcast 2026-05-17 Agili 的 Hacker Podcast 2026-05-16 Agili 的 Hacker Podcast 2026-05-15 Agili 的 Hacker Podcast 2026-05-14 Agili 的 Hacker Podcast 2026-05-13 Agili 的 Hacker Podcast 2026-05-12 Agili 的 Hacker Podcast 2026-05-11 Agili 的 Hacker Podcast 2026-05-10 Agili 的 Hacker Podcast 2026-05-09 Agili 的 Hacker Podcast 2026-05-08 Agili 的 Hacker Podcast 2026-05-07 Agili 的 Hacker Podcast 2026-05-06 Agili 的 Hacker Podcast 2026-05-05 Agili 的 Hacker Podcast 2026-05-04 Agili 的 Hacker Podcast 2026-05-03 Agili 的 Hacker Podcast 2026-05-02 Agili 的 Hacker Podcast 2026-05-01 Agili 的 Hacker Podcast 2026-04-30 Agili 的 Hacker Podcast 2026-04-29 Agili 的 Hacker Podcast 2026-04-28 Agili 的 Hacker Podcast 2026-04-27 Agili 的 Hacker Podcast 2026-04-26 Agili 的 Hacker Podcast 2026-04-25 Agili 的 Hacker Podcast 2026-04-24 Agili 的 Hacker Podcast 2026-04-23 Agili 的 Hacker Podcast 2026-04-22
Agili 的 Hacker Podcast 2026-07-09
Agili 的 Hack · 2026-07-10 · via Agili 的 Hacker Podcast

从维修权官司落地到欧盟加密扫描争议,再到 GPT-5.6 和多个开源模型的密集发布,今天的科技新闻充满了权力、隐私与性能的角力。欢迎阅读 Agili 的 Hacker Podcast 每日博客。

约翰迪尔被迫放开农机维修权,罚款仅占两天利润

和解内容与十年合规期

美国联邦贸易委员会(FTC)与五个州的总检察长,同约翰迪尔(Deere & Co.)就农机维修权达成和解。迪尔必须向设备所有者和独立修理店提供与授权经销商一样的完整诊断与维修软件,经销商不得报复自行维修的车主。迪尔还需向五州支付 100 万美元用于反垄断执法费用,并在未来十年接受严格合规监督。这是迪尔今年第二次维修权和解,此前 4 月已有 9900 万美元的集体诉讼和解。

处罚力度与排放作弊的顾虑

迪尔 2025 年净利润约 50 亿美元,100 万美元罚款只相当于不到两天的利润。评论区普遍认为真正的惩罚是强制放开维修软件,而非这笔罚款。维修权一旦放开,另一个担忧浮出水面:农民很可能拆除高故障率的柴油颗粒捕集器(DPF)和选择性催化还原(SCR)系统。一位拖拉机车主讲述,他的 2022 年机器因 DPF/SCR 软件故障停工一周,直接损失约 2 万美元。支持维修权的一方主张通过定期检查和实质性罚款来管控排放,而不是通过技术锁定。

为什么农民还是买迪尔

品牌忠诚、完备的经销商网络和跨代使用的文化惯性,使得迪尔在短期内地位稳固。一名迪尔员工表示,迪尔备件全、老型号也能找到配件,是“最容易维修的”。小规模种植者则在慢慢转向 Mahindra 等品牌。这次和解仅针对农用设备,许多评论希望类似的维修权法案能延伸至消费电子产品、打印机和智能家居设备。

欧盟议会通过 Chat Control 1.0,允许无搜查令扫描私信

逆向表决下的程序争议

7 月 9 日,欧洲议会通过了一项临时法规“Chat Control 1.0”,允许美国科技公司在无搜查令或事先怀疑的情况下扫描用户私信。当天 314 人反对、276 人赞成、17 人弃权,但根据程序,否决需要议会全部 719 席位的绝对多数(361 票),反对票不足就让法规自动生效。投票被安排在暑假前的最后一天,112 名议员缺席,其缺席在程序上等同于不支持否决。民间社会和部分议员将这一过程称为“程序把戏”,严重损害欧盟民主可信度。

扫描范围与加密豁免的未来

法规恢复了对 Instagram、Discord、Snapchat、Skype、Xbox 私信以及 Gmail、iCloud 邮件的扫描。端到端加密通信(如 WhatsApp)此次仍被豁免,但批评者指出这只是阶段性目标。英国互联网观察基金会等机构已开始游说打破端到端加密,未来的“Chat Control 2.0”可能进一步侵蚀加密保护。而且欧盟本土服务商从未实施过这类扫描,法规主要针对美国科技巨头。

幸存者的公开反对

欧盟委员会自身数据显示,2024 年大规模扫描产生的举报中仅 36% 来自私信,且 48% 的警报不具备刑事相关性,约 99% 的已知材料是旧内容。多名性侵幸存者公开反对这一法规:曾依靠私下通信揭发多名性侵者的 Alexander Hanff 说,“我们幸存者需要隐私,没有它我们就失去了声音。”MOGiS 组织副主席 Dorothée Hahne 强调,大规模监控破坏了幸存者赖以生存的安全通信空间。

OpenAI 发布 GPT‑5.6:更强性能、更低成本与新的安全策略

旗舰模型 Sol 的性能与成本控制

GPT‑5.6 家族包含旗舰模型 Sol、均衡模型 Terra 和低成本模型 Luna。在 Agents' Last Exam 中等推理水平下,Sol 比 Claude Fable 5 高出 11.4 分,成本仅为其四分之一。新的 ultra 模式并行协调四个智能体来加速复杂任务,API 端引入 Programmatic Tool Calling,让模型自主编写和运行轻量级程序来处理工具调用,减少了来回传递的 Token 消耗。

安全策略:不过度封锁

OpenAI 声称采用了分层防护,包括模型内嵌防护、实时推理监控和按信任度校准的访问控制。他们特别指出,过度封锁会阻止合法防御者修复漏洞,而攻击者仍可使用其他模型。因此 GPT‑5.6 在保持高检测率的同时,通过“可信访问”程序向验证用户开放更强的网络防御能力。这与 Anthropic Fable 5 因过度过滤而遭到的批评形成对比——Fable 5 甚至拒绝回答带有“DNA”变量的代码问题或植物养护咨询。

开发者体验与 ARC-AGI-3 里程碑

官方提示词建议出现了一个微妙变化:GPT‑5.6 对“保持简洁”这类泛指令敏感,容易过度删减必要信息,推荐改用“先说结论,再附证据”等结构化指令。在 ARC‑AGI‑3 抽象推理基准上,GPT‑5.6 Sol 以 7.78% 成为首个通过至少一个关卡的被验证前沿模型,社区认为这印证了随着推理计算量增加性能可大幅提升的“苦学苦搜”路线。编码方面,许多用户认为 Codex 比 Claude Code 更稳定便宜、Token 消耗减半,但仍有开发者觉得 Claude 写出的代码更优雅。

独立游戏《18 Words》引发计时器机制大讨论

计时器的拥护者与抵触者

18 Words 要求玩家在 30 秒倒计时内从打乱的字母中找出 18 个单词,超时则游戏立即结束。拥护者认为计时器让游戏有明确的结束点,也不会占用太多时间;抵触者多是寻求放松的玩家或英语非母语者,认为固定 30 秒门槛赶走了大量潜在用户。开发者 pompomsheep 在发布一天后更新了游戏:超时后仍可继续玩完 18 个单词,最终得分显示 x/18,并增加每词一次的洗牌按钮。

词库与成绩的透明度

早期小词表导致“EARLS”“REALS”等词不被接受,后来换回了包含 30 万个词的大词表。有玩家深挖代码发现,成绩百分位的判断逻辑是硬编码的,并非基于实时数据。游戏在发布当天获得了超过 13 万玩家。

Rust 版 Postgres 通过全部回归测试,线程模型性能显著提升

AI 辅助的重写方法

pgrust 项目已通过 Postgres 18.3 官方回归测试套件的全部 46,000 余个查询。作者 malisper 先用 c2rust 将 Postgres C 代码自动转译为 Rust,再使用 Claude 逐步将每个 crate 重写为惯用 Rust。他开发了一套识别待移植 crate 和审计代码的“技能”工作流。

线程模型带来的飞跃

开发中的新版本将 Postgres 的“每连接一个进程”改为“每连接一个线程”。线程共享地址空间,避免了跨进程的元组拷贝和重复哈希,这使并行查询可以直接传递指针。在 Percona-TPCC 基准上事务性能提升 50%,在 ClickBench 分析型负载上快约 300 倍。作者确认数据基于标准 benchmark,优化来自批量执行、预取和列式存储。

许可证与可维护性

pgrust 采用 AGPL-3.0 许可证,而原始 Postgres 为类 MIT/BSD 许可证。项目包含约 2,600 个 unsafe { 块,主要集中在从 yacc/bison 生成转译而来的解析器中。开发者认为当前阶段尚未生产就绪,且缺乏类似 Jepsen 的测试,后续计划在性能工作完成后重点加强审查和模糊测试。

GLM-5.2 在 25GB RAM 笔记本上运行,纯 C 实现流式加载

专家流式加载与纯 C 推理

开源项目 colibrì 让 744B 参数的混合专家模型(MoE)GLM-5.2 在仅 25GB RAM 的消费级机器上运行。约 9.9 GB 的稠密部分常驻内存,剩余 370 GB 的路由专家按需从 SSD 流式加载,配合 LRU 缓存和操作系统页缓存。引擎用约 2400 行 C 代码写成,包含 MTP(多 token 预测)投机解码,int8 量化 MTP 头接受率 39–59%,每前向可输出 2.2–2.8 个 token 且通过拒绝采样保持无损。

真实世界速度与适用场景

实测数据:苹果 M5 Max(128GB 统一内存)约 1.06 tok/s;Ryzen AI 9 HX 370(128GB RAM)在 66% 专家命中率下达 0.37 tok/s。冷启动时解码低至 0.05–0.1 tok/s,几乎不可用于实时对话,但对于批量填单等非交互任务仍有价值。项目已收获 1.4k stars,GLM-5.2 权重由 Z.ai 以 MIT 协议发布。

Meta 发布 Muse Spark 1.1,低价多模态推理模型引基准争议

基准测试被指超限使用资源

Muse Spark 1.1 是 Meta Superintelligence Labs 的多模态推理模型,支持 100 万 token 上下文窗口,定价为每百万输入 $1.25。社区发现 Meta 在 Terminal-Bench 2.1 测试中使用了 6 CPU 和 8GB RAM,而官方任务限制为 4 CPU、2GB RAM,因此未出现在官方排行榜上。虽然 Anthropic 也被指未严格遵守限制,但目前缺乏独立验证来确认这些基准成绩的真实性。

定价优势与可用性限制

输入缓存仅 $0.15 的定价使其在同级模型中极具竞争力,但部分用户实测后认为“质量低于 Sonnet”。API 目前仅限美国区域,加拿大、越南、阿根廷等地均不可用。Meta 未开放模型权重,这与之前的 Llama 系列形成对比,部分用户对数据隐私和公司信任度表达了担忧。

美军后勤的“玻璃脊梁”:为何军队在下一场战争中会崩溃

从效率至上到生存危机

美国陆军在过去二十年里优化了一套依赖承包商、固定前哨基地和不受威胁补给线的后勤体系。在大规模作战中,现代感知、精确打击和廉价无人机彻底消除了传统后方。乌克兰战争提供了直接教训:基辅北部长达 40 英里的俄罗斯车队因后勤崩溃而瘫痪,乌克兰军队绕开装甲矛头,直接打击燃料和补给车队。保障节点、车队和运输路线持续暴露,任何中央集成的后勤节点都很脆弱。

分散化网络与有机防御

出路在于从中心辐射式模型转变为由更小、更分散、可移动且能管控信号特征的节点构成的网络。保障部队必须像机动营一样频繁转移,并拥有自身的反无人机系统和短程防空能力。装甲后勤车辆即使牺牲载重和油耗也是必须付出的生存代价,同时需要加速列装无人地面车辆和重型货运无人机以执行“最后一英里”补给任务。

文化问题:后勤不是附属品

文章作者、联合参谋部的乔纳森·巴克兰指出,陆军的现代化文化仍然优先投资机动和火力,保障被视作需要最小化的官僚浪费。在现代战争中,尾巴才是主要攻击目标。评论中有人以乌克兰为例,该国建立了自底向上的 e-points 积分兑换体系,各单位击毁目标获得积分后可直接兑换装备,这种分散化保障创新避免了自上而下的僵化供应。

IERS 公告:2026 年底无闰秒,地球自转依然微妙

国际地球自转与参考系统服务(IERS)发布第 72 号公告,确认 2026 年 12 月底不会引入闰秒,协调世界时与国际原子时的差值保持 -37 秒。这份英法混合的公告页面被读者调侃具有“道格拉斯·亚当斯小说”的气质。虽然分布式系统暂时免于闰秒调整的头痛,但这是否意味着此前预测的“负闰秒”被永久取消尚无定论,未来仍取决于地球自转的实际变化。

腾讯发布 295B 开源模型 Hy3,性价比突出但实际体验存分歧

Hy3 是腾讯推出的 295B 参数混合专家模型,采用 Apache 2.0 许可,通过 OpenRouter 提供。其定价与 DeepSeek V4 Flash 持平,在某些基准上接近 DeepSeek V4 Pro,但部分用户认为它存在“benchmaxxed”嫌疑。在 DeepSWE 评测中,Hy3 得分 28%,与 GPT-5.4 xhigh 的 52% 有差距。实际使用中,有用户称赞其长上下文下的指令跟随能力优于 DS4 Flash,也有用户觉得不如 Gemma 4 31B 或 Qwen 3.6 27B 等更小的模型。

模型由于参数规模巨大,本地运行需要多张高显存 GPU,远非消费级硬件能负担。社区讨论认为,Hy3 是性价比突出的开源选手,但用户应根据具体任务自行评估,不宜只看基准排名。

播客全文

女:Hello 大家好,欢迎收听 Agili 的 Hacker Podcast,我是莓莓。

男:大家好,我是阿迪。

女:今天要聊的话题跨度有点大,从拖拉机到聊天隐私,再到用 25GB 内存跑大模型,还有一个让我特别上头的单词游戏。阿迪,你先说说美国农民修拖拉机那事儿?我总觉得这事儿透着一种怪异的熟悉感。

男:行。约翰迪尔和 FTC 以及五个州达成了和解。简单说,就是农民以后能自己修自己的拖拉机了。

女:自己修自己的东西,居然要政府的和解令才能做到,这本身就很离谱。就像你买了辆车,但换机油必须去 4S 店,因为系统不让你自己重置保养灯。

男:对,约翰迪尔过去就是扣住了维修软件。你有硬件、有手艺,但没那串诊断代码,你就没法让拖拉机正常工作。授权经销商才有这套完整软件,车主和独立修理店拿到的都是残缺版本。

女:所以和解令要求迪尔把这套工具交出来,并且禁止经销商报复那些找别人修车的农民。但挨骂最多的,是罚款——只有区区一百万美元。

男:一百万美元。迪尔今年的净利润大概在五十亿美元左右。这个数字,相当于一个年入十万的人,被罚了大概一顿外卖的钱。很多人觉得这不是惩罚,是发放行为许可证。

女:社区里有一种解读挺有意思的,说真正的损失不在于那一百万,而在于迪尔被迫打开了一个口子。这个和解令的有效期是十年,十年后它还能把这扇门关上吗?

男:这是个大问题。这份和解令不是法律,不构成司法判例。它对迪尔的约束只在这十年。十年以后,如果还没有联邦层面的维修权立法,迪尔完全可以恢复原来的封闭策略。

女:十年缓冲期,听起来像是给了各方时间去推动真正的立法。另外,排放也是一个隐形战场。有评论说,农民拿到维修工具后,第一件事可能就是拆掉柴油车上的颗粒捕集器,也就是 DPF,还有 SCR 选择性催化还原系统。

男:农用机械上的 DPF/SCR 系统故障率很高,而且维修起来既费钱又耽误农时。有一个农场主说,他的 2022 年久保田拖拉机,因为排放软件故障,趴窝一周,直接损失差不多两万美金。对农民来说,赶上播种或者收割季,这种损失是实打实的。

女:所以这就陷入了一个两难。支持维修权的人认为,排放的执法应该靠年检和巨额罚款,而不是靠技术手段把车主锁死。你打个比方,就像交警发现你尾气超标,应该给你开罚单,而不是在你发动机里装个程序让你随时可能熄火。

男:但反对的人担心,工具一旦放开,篡改就会变得非常容易。不过话说回来,农民为什么忍受了这么久还要买约翰迪尔?除了经销商网络和零件供应,还有很强的文化惯性,很多家庭几代人都用这一个牌子。

女:这期和解目前仅限于农用设备,但评论区很多人都希望这股风能吹到消费电子领域。你说打印机墨盒锁芯片,笔记本把内存和硬盘焊死在主板上,本质上和迪尔的逻辑是一样的。

男:这就是“锁定效应”。维修权运动的推动者,像 Louis Rossmann,就是从修苹果笔记本开始的。他这次也被多次提起,虽然有人嫌他脾气暴躁视频冗长,但更多人感激他持续多年的举证和呐喊。这种改变,确实需要一点死磕的能量。

女:对的。迪尔被逼着开了一道门,那我们的数字隐私呢?接下来这个话题就让人后背发凉了。

男:你说的是欧盟通过的 Chat Control 1.0。

女:对。这个法规允许科技公司在没有搜查令、没有具体怀疑对象的情况下,直接扫描用户在 Instagram、Gmail 甚至游戏平台 Xbox 上的私聊信息。

男:这事儿最让人震惊的不是内容本身,而是它通过的程序。今年3月,欧洲议会两次把它驳回去了。但到了7月9号,法规却自动生效了,因为规则是“否决”才需要全体议员过半数的赞成票。

女:这很像一个程序把戏。投反对票的议员有314人,赞成的只有276人,但由于那天是暑假前一天,很多议员已经离任了,最终反对票没达到否决的门槛。缺席的议员,他们的沉默被算成了“不支持否决”。

男:这意味着少数派利用程序的精巧设计,强行通过了多数人反对的东西。民间社会和一些议员非常愤怒,认为这严重损害了欧盟的民主公信力。法规限制的扫描范围很大,但端到端加密的消息,像 WhatsApp,暂时被豁免了。

女:但大家普遍认为这只是个阶段性的后退。有组织已经在游说要打破端到端加密,下一个版本 Chat Control 2.0 可能会更深入。最关键的是,欧盟自己的数据都显示,这种无差别的大规模扫描,对实际解救儿童、提高定罪率几乎没有帮助。

男:德国联邦刑警局的数据说,48% 的预警根本不具备刑事相关性,还有大量调查最终指向了未成年人自己。一位经历过侵害的幸存者说得很直白,他说,我们幸存者需要隐私,没有隐私我们就失去了求助的声音。

女:把每一个用户都当成潜在的嫌疑人来监控,却挤压了真正受害者安全的求救空间。这种大而化之的监控手段,逻辑上站不住脚,代价却是所有人的隐私。幸存者组织也在反复强调,真正有用的是从设计上就安全的儿童应用,是暗网的主动执法。

男:但这种努力显然不是风口,因为它不产生海量数据,不显得“大有作为”。

女:说到大有作为,OpenAI 最近倒是静悄悄地发布了新模型 GPT-5.6。这次发布很低调,但信息量不小。它是一个模型家族,有旗舰版 Sol、平衡版 Terra 和低成本版 Luna。

男:从数据看,Sol 在 Agents' Last Exam 这个高难度基准上,中等推理强度下的得分比 Anthropic 的 Fable 5 高出 11.4 分,而调用成本只要后者的四分之一。

女:这个成本优势很实在。而且模型还有一个 ultra 模式,可以同时协调四个智能体并行干活,去解决复杂任务。API 那边还引入了所谓的程序化工具调用,就是模型能自己写点轻量级代码去调用工具,减少了来回传 Token 的消耗。

男:安全策略上,OpenAI 这次有一个提法很有意思,他们说“过度封锁本身也是安全风险”,会阻止防御者修复漏洞。所以他们给合法的防御研究预留了通道。这一点很务实。

女:开发者们观察得更细致,他们发现提示词的规则变了。以前我们习惯说“保持简洁”,现在这套指令会让 GPT-5.6 过度删减信息。推荐的做法是“先说结论,再附证据”。

男:有人开玩笑说,现在的规则是“你可以要求用户简洁,但不能要求模型简洁”。也有人猜这跟按 Token 收费的商业模式有关,说话越啰嗦赚的越多。但主流观点认为,基准测试正在转向“每美元性能”,最终还是会倒逼模型变得高效。

女:相比之下,Anthropic 家的 Fable 5 最近被喷得挺厉害,因为它拒绝回答各种无害问题。你用带有 DNA 这个变量的代码去问它,它会觉得那是安全问题,直接罢工。

男:这种“不工作就是不工作”的倔强,把很多开发者推向了 OpenAI。大家普遍反映,GPT-5.6 的代码产出更干净,冗余注释和防御性代码也少了。虽然和 Claude 写的代码比,在人眼里还是少了点优雅,但胜在稳定、便宜、不给自己加戏。

女:还有一个看起来只有 7.78% 的成绩,但圈子内讨论度很高。GPT-5.6 Sol 在 ARC-AGI-3 这个抽象推理测试上,成了第一个通过至少一个关卡的被验证前沿模型。

男:这个分数虽然低,但它展示了一种趋势:随着推理计算量的增加,性能可以显著跃升。这证明了“苦学苦搜”的暴力美学路线是有效的。这也让关于人工智能的路线之争再次浮出水面——有人觉得这打了那些狂言大模型不通推理的人的脸,但更多人指出,人类小孩并不需要读几千兆数据就能学会类似的推理能力。

女:我觉得大家对模型是不是变笨、变贵、变啰嗦的讨论,最终都会回到一个核心上:我花钱买的服务,能不能稳定地解决我的问题。那你说,如果一个连稳定运行都做不到的软件,我们敢让它重构整个数据库吗?

男:你说的这是 Postgres 的 Rust 重写版,pgrust。它刚刚通过了官方回归测试套件里全部四万六千多个查询,输出的结果和原始 Postgres 一模一样,而且磁盘完全兼容。你可以直接拿你现有的 Postgres 数据目录,用它启动起来。

女:这听起来是一个巨大的工程。但我好奇的是,它是怎么做到的?人工一行行翻译吗?

男:这正是它最反常识的地方。作者 malisper 基本上是用 AI 来重构的。他的起点是用工具把 Postgres 原始的 C 代码自动转成 Rust代码,这个版本里全是各种 unsafe 代码块,但能跑通测试。

女:unsafe,这个词在 Rust 语境里听着就像一个装着怪兽的笼子,你知道里面东西很危险。

男:对。然后他就用大模型,一步步把每个功能模块重写成符合 Rust 规范的安全代码。他自己开发了一套工作流,让 AI 去研究怎么写出地道的代码,起草规则,再不断试错、审计、迭代。整个过程就像一个人指挥着一群不知疲倦的初级程序员在干活。

女:这真是把大模型当生产力工具用到了极致。他这样重构出来的新版本,性能上有提升吗?

男:他在另一个还没发布的新版本里,把 Postgres 传统的多进程模型改成了多线程。Percona-TPCC 基准测试下,事务性能提升了 50%。在分析型负载 ClickBench 上,大概快了 300 倍。这部分提升来自批量执行、预取、列式存储这些底层优化。

女:300倍。这个数字听起来已经跨代了。但我立刻会想,把进程改成线程,当一个线程崩溃时,会不会把整个数据库都带崩?

男:很多人都有这个疑问。实际上,Postgres 用共享内存,哪怕是多进程架构,任何一个子进程异常退出,整个集群都要进入恢复模式。所以进程模型提供的所谓“隔离性”其实很脆弱。线程模型在并行查询里的优势是实打实的,比如并行哈希连接,线程间可以直接传指针,不用像进程那样把数据拷贝来拷贝去。

女:这让我感觉,很多我们习以为常的架构设计,可能只是历史惯性。不过有人说,这项目有两千多个 unsafe 代码块还没有重写,主要集中在解析器部分,这就像大厦盖好了,但地基里还混着一些原来的旧砖头。

男:作者承认这一点,他说解析器是从古老的 yacc/bison 生成的,他只做了机械翻译,打算以后慢慢清理。这个项目目前采用了 AGPL 许可证,比原版 BSD 更严格,尤其对云厂商。不过,说到“上生产”,作者诚实地声明它还没有经过 Jepsen 那种严苛的分布式测试,不算生产就绪状态。

女:诚实是个好品质,就像接下来我们要聊的这个项目,它的名字 colibrì,它干了一件让我觉得特别了不起的事:让一个 7440 亿参数的大模型,在你家只有 25GB 内存的电脑上跑起来。

男:它跑的是 MoE,也就是混合专家模型。这种模型虽然总参数巨大,但一次推理只会激活一小部分。作者把必然要用到的稠密部分压缩到 9.9GB 常驻内存,剩下的大量“专家”存储在普通 SSD 硬盘上,用的时候再预读。

女:这像是一台液压机,需要用的时候才加压,平时安静得像不存在。它是用 2400 行纯 C 写的,零依赖,跑起来不需要 Python,更不需要 GPU。

男:纯手工打造。它用 int8 量化的 MTP 投机解码头,接受率有 39% 到 59%。什么意思呢?就是你一次性预测好几个字,命中率高就能大大加快速度。

女:但速度到底多快?我听说在低配机器上,冷启动时一个字要憋几十秒。

男:在他的 12 核笔记本上,冷启动大概 0.05 到 0.1 tok/s,也就是一秒连一个字都出不来。但如果在苹果 M5 Max 上,利用它 128GB 的超大统一内存和高速固态硬盘,可以跑到每秒一个字以上。更新的版本修复了缓存机制,内存越大,能装下的热门专家就越多,速度也就越快。

女:每秒一个字,看电子书肯定够了,但用来实时对话还是有点折磨。有评论就说这像是一个每小时读 11GB 的阅读器,不适合聊天,但适合让它干点别的。

男:对。比如用来批量填写工单、深夜后台总结新闻简报。这种不要求实时交互、可以扔在后台运行的任务,它就很有价值。

女:大模型从云端挤进你的老旧笔记本,而 Meta 这边正在把更强的推理模型塞进云端应用里。他们新发布的 Muse Spark 1.1,多模态推理模型,上下文窗口高达 100 万 token。

男:这个模型定位是智能体任务,定价非常有冲击力。输入百万 token 一块两毛五,输出四块五。缓存过的输入只要一毛五。

女:这价格比同类低了一大截。但 Meta 没有开源权重,这和以前 Llama 系列的开放策略形成鲜明对比。评论区也有不少人犯嘀咕,一方面觉着便宜大碗能倒逼全行业降价,另一方面又不信任 Meta 的数据隐私保护。

男:对,争议还在于它到底是不是真的那么强。有用户立刻指出,Meta 在一个叫 Terminal-Bench 的测试里,给它分配了官方规则允许的 1.5 倍以上硬件资源,这有“考试作弊”的嫌疑。它甚至根本没登上那个测试的官方排行榜。

女:所以有些用户实际用了之后,感觉它质量不如 Claude Sonnet,但对于需要长上下文处理海量文件的用户,这个性价比确实很难拒绝。看来,冷静先跑个自测比什么都强。

男:模型在争奇斗艳,国内腾讯的 Hy3 也以 MoE 架构和 Apache 2.0 协议跑出来了,295B 参数,在一段时间里登上了 OpenRouter 排行榜前列。但现在它也面临声量和体验的分离,有人说它可靠,长上下文强,有人觉得它基准测试刷得好看,实际创意写作被 27B 的小模型吊打。

女:这又回到那个老生常谈的话题,跑分不能代表一切。数据集污染、强化学习策略的不同,都会导致大模型的纸上功夫和手头感觉完全不同。

男:聊了这么多科技圈对“速率”、“安全”、“效率”的执念,我想在你刚刚提到的这些极致追求之外,插一个更沉重的话题。

女:你是说那篇关于美国陆军后勤的文章吧。我读了之后最大的感受是,现代战争打的不是谁的武器更科幻,而是谁的物流能活下来。

男:作者用了一个很生动的类比:一支致命的机动部队,如果后勤脊梁断了,它不过是一堆停在原地等待燃料耗尽的固定靶。乌克兰战争把这一点彻底放大了。

女:那支在基辅北边长达 64 公里的俄罗斯车队,并不是被正面击溃的,而是因为燃料耗尽、机械故障和路面拥堵自己瘫痪的。乌克兰军队抓住了这个破绽,避开装甲矛头,专门打脆弱的油罐车和补给卡车。

男:这就是消耗战。HIMARS 这些远程精确火力,让乌军能反复打击俄军的弹药库和铁路枢纽,俄军只能把补给节点往后撤,一后撤前线的补给速度就跟不上了。

女:一个现代装甲旅,高强度作战一天要喝掉几万加仑燃料,这需要巨大且笨重的运输车队。这些油罐车又大又脆,热信号散得到处都是,打起仗来就是活靶子。美国陆军现在的痛点是,它习惯了在伊拉克、阿富汗那种后方绝对安全的环境下,承包商式的高效物流。

男:所以出路是分散化。后勤不能再搞豪华大仓库,得像游击队的营地,小包装、多地点、频繁转移,还要能管理好自己的信号特征。后勤兵不能指望步兵来保护,他们自己必须装备反无人机系统和短程防空导弹。

女:文章里有一句让我印象很深,说在军事学院里人们常说“业余谈战术,专业谈后勤”,但真到了预算审批和武器研发上,钱和注意力永远优先给了机动部队和火力单元。后勤被当成一种需要压缩的官僚成本。有一个评论一针见血:“如果尾巴被切掉了,再锋利的牙齿也没用。”

男:乌克兰正在做的事情很能说明问题。他们搞了一个内部无人机采购平台,各个战斗单元只要击毁目标赚了积分,就能直接用积分兑换装备,绕过传统僵硬的供应体系。这是一种自下而上、极速迭代的分散化保障。

女:所以后勤必须成为主角,不只是一个支撑性的配角。这关乎面对同等体量对手时的真正持久力。

男:从拖拉机的代码封锁,到聊天窗口的无差别监控,再到大模型的竞争和数据库的彻底重写,我们似乎一直在讨论限制与突破。

女:对。就像我们刚才说到的那个简单的单词游戏 18 Words 一样,玩家要在 30 秒内拼出 18 个单词,时间一到游戏立刻结束。一部分人觉得这个计时器是精髓,让你顺其自然地结束、不沉迷。

男:但另一部分人,尤其是非英语母语的玩家,觉得这个计时器就像一把总悬在头顶的铡刀,带来了压迫感而非放松。开发者在一天后就更新了规则,超时后可以继续玩,只是得分没那么好看。

女:这正是软件和规则设计里最迷人的地方。当一项限制被移除,用户表面上是获得了自由,但其实也失去了一种被规则所迫的专注感。开发者最终在“挑战”和“放松”之间,找到了一个平衡点。

男:这也是我们今天讨论的很多话题的缩影。约翰迪尔对维修软件的限制、欧盟对隐私的侵入、Meta 对模型权重的保留,以及 GPT 的啰嗦与自我限制,本质上都是规则的制定与打破。

女:在打破边界这件事上,有个小新闻特别有诗意。国际地球自转服务机构发了公告,今年 12 月底不同插入闰秒了。世界将会多出一秒的不完美,而我们装作无事发生。

男:这份公告抬头写着“致负责量度和分发时间的当局”,听起来像是某种宇宙运转法则下达的官方文件。有网友说这是今年最好的一句话开头。

女:分布式系统可以暂时松一口气,不用去处理那多出来或消失的一秒带来的 Bug 了。那么今天我们就聊到这里,不管是代码还是时间,希望我们都能找到适合自己的节奏。

男:我们下次再见。

女:感谢收听今天的节目,欢迎大家在你的泛用型播客客户端上订阅我们,咱们下期接着聊。

参考链接