Agili 的 Hacker Podcast 2026-11-11

今天 Agili 的 Hacker Podcast 从 AI 智能体在丛林里找遗址，到一位工程师在自家 Mac 上藏好 SSH 私钥；从 8 位时代的堆栈技巧，到 Python 社区送别一位传奇。

AI 智能体重新发现一座玛雅遗址

72 小时从旅行到政府回信

Pietro Miotti 是 Google 的软件工程师。10 月 18 日他在秘鲁旅行，用 Gemini 聊当地历史，知道了 Hiram Bingham 1911 年“发现”马丘比丘的故事。他问：如果 Bingham 有今天的工具，会怎么做？几个智能体给出的答案一致：激光雷达（lidar，用激光脉冲穿过树冠缝隙测绘地面的技术）。

他把约 1200 平方公里的玛雅丛林激光雷达条带转成图像，让 48 个智能体像极有耐心的考古学家一样逐张看图，寻找金字塔、平台和广场，同时排除自然山丘、天坑和道路。一夜之间，它们标出多个疑似村落。其中一个位于悬崖顶、被森林完全覆盖，边缘笔直、拐角分明。放大看，那里有平整的广场、至少 8 到 12 米高的椭圆形金字塔、抬升的庭院，以及一个可能是雨水蓄水池的平底凹坑。智能体还检查了原始点云，确认形状来自地面而不是树冠。

10 月 20 日他把报告翻译成西班牙语发给墨西哥国家人类学与历史研究所（INAH），21 日收到回复：该位置没有登记在册的考古遗址。

“发现”还是“重新发现”

文章在 X 上传播后，有人指出 Tulane 大学的 Francisco Estrada-Belli 等人 2025 年的论文已经测绘过这个遗址，发表于 Journal of Archaeological Science: Reports，开放获取。作者 11 月 11 日更新了文章：智能体查文献时漏了这篇，所以这是“重新发现”，不是“发现”，它只是还没进 INAH 的登记册。作者本人在 HN 上也确认了这一点。

评论区认为仍有意义：独立复现验证了原发现，也证明这套方法可以走到发现。做历史研究的 benbreen 说，他用智能体研究历史时，它们常常只读了约 80% 的已有研究就声称“新颖”，而要真正支撑新颖性至少得接近 100%。评论者 nerevarthelame 补充，Estrada-Belli 的研究是一个更大的人类学评估的副产物，其主要结论是精英与平民的居住地非常接近、关系比此前认为的更复杂，和作者用 Gemini 生成想象图后猜测的“地方精英市中心”相反。

数据、盗掘与归功

技术讨论集中在成本和方法上：为什么用 48 个智能体、能否用单个 LLM 搭流水线做图像分类。有人提醒，这个故事更应归功于 NASA 的激光雷达数据、长期公开的数据，以及英国等地早已由业余爱好者用同样数据发现大量遗址。hanoz 建了全英第一个在线激光雷达地图 lidarmap.uk，靠它发现的罗马别墅、堡垒、环形土墙几乎每周都有人报告。

一个反复出现的担忧是：如果真把全球扫一遍、让智能体标出所有异常结构，盗掘者拿到同样的坐标只会更快。考古发掘本身具有破坏性，最好的保护常常是暂时不动。有人反驳说，数据已经放在那里，盗掘者迟早会自己用。有现场经验者指出，该遗址距一条路只有约 250 米，当地村民很可能早就知道。

作者留下的结论是 “You can just do things”：“我不是考古学家，所以不知道这事本该有多难。”

用 macOS Secure Enclave 保护 SSH 私钥

文件权限之外没有保护

作者的私钥就躺在 ~/.ssh/ 目录里，除了文件权限外没有任何保护。任何拿到文件系统的恶意脚本都能把它复制走，进而登上他所有的服务器。他提到网上有不少假面试作业的案例，要求你克隆仓库并在本地运行，这也是他全面转向 devcontainer（开发容器）的原因，但光靠 devcontainer 还不够。

他真正想要的是硬件方案：私钥从物理上无法导出，哪怕 Mac 完全沦陷也拿不到。YubiKey 5C 他手头有，但还是想先试试原生方案：不用多带一个硬件，也不用维护第三方软件。

六步配置

macOS 从 Sequoia 开始支持 Secure Enclave 托管的 SSH 密钥。Secure Enclave 是 Mac 芯片上与主处理器隔离的安全子系统，私钥在里面生成，永远不会离开。第一步用 sc_auth 创建身份：

sc_auth create-ctk-identity -l "ssh-MacBook" -k p-256-ne -t bio

-k p-256-ne 指定 NIST P-256 曲线、密钥不可导出，-t bio 要求每次使用都走 Touch ID。作者最初报错 Failed to get bio catacomb UUID，发现是 Touch ID 录入被重置了，重新录入指纹后解决。

第二步导出一个 key handle，这个文件不是私钥，只是让 SSH 去请求 Secure Enclave 签名的引用：

ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N ""

第三步在 shell 配置里设置 SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib。第四步拿到公钥。作者特别提醒，网上很多教程让你用 ssh-add -K，这个参数已经废弃，替代它的新参数只适用于传统 macOS Keychain，对 Secure Enclave 密钥无效。第五步把公钥复制到服务器的 authorized_keys。

第六步改 ~/.ssh/config。这里有个坑：SSH 不会自动发现 id_ecdsa_sk_rk 这种文件名，只认 id_rsa、id_ed25519、id_ecdsa 这些标准名，需要在 config 里显式写出 IdentityFile ~/.ssh/id_ecdsa_sk_rk。如果同时用 1Password 的 SSH agent，可能会冲突。

Touch ID 弹窗与替代方案

让作者最不满的是弹窗文案。Touch ID 对话框写的是 “ctccardtoken needs to authenticate to continue”，而不是“SSH 想使用你的密钥”之类的人话。这个弹窗来自 CryptoTokenKit，一个没为终端用户打磨过的底层框架。他建议所有密钥都用 -t bio：不启用的话恶意软件可以静默使用密钥，启用后至少每次使用你都知道。

Secure Enclave 密钥和具体的 Mac 绑定，机器坏了密钥就没了，这是设计的必然结果。他建议在服务器的 authorized_keys 里同时放 Secure Enclave 密钥和一把备份密钥。文章结尾说他转向了 Secretive，同样把密钥放在 Secure Enclave，但提示框更好看，还支持按密钥单独设置。

评论区：指纹疲劳与无头场景

一位用户讲了 WireGuard 在 macOS 上的翻车经历：某次系统升级后 app 启动崩溃，日志显示 Unable to open config from keychain: -25300，然后 app 把所有配置当成“孤儿”删掉了，理由是“keychain 一致性”。这个 bug 至今还在。

有人质疑作者的威胁模型：如果恶意脚本已经能读你的文件系统，它为什么不直接趁你下次 ssh 时下手？回应是，Secure Enclave 加 Touch ID 挡住的是“静默使用”，每次签名都会弹窗。指纹疲劳是反复出现的话题，一位用户说每天 20 次指纹请求之后，看到弹窗就按，根本不看是谁在请求。

无头场景也是个坎。mavam 指出，agentic 开发需要密钥时人往往不在电脑前，Secretive 在你没登录时访问不了 enclave。jon-wood 反驳说，人不在时访问不了 enclave 是特性不是 bug。jwr 顺着这个思路说，他用 YubiKey 十年了，AI 时代物理在场反而成了优点：没有他插着 key、按一下，任何 AI agent 都碰不到生产服务器。

一次 8 位时代的性能 hack：把两个堆栈指针变成图形搬运工

卡在背景重绘

Tom Moertel 在 2013 年回忆大学时帮朋友优化一款 8 位 PC 横版游戏。画面已经塞进机器，循环展开、去掉多余绘制都做了。瓶颈在背景重绘：每个 28×28 像素图块，每像素 4 位，图块每行 14 字节，屏幕缓冲区每行 160 字节。朴素例程每行 157 个周期，动作卡顿。

朋友先把内层循环完全展开，用固定偏移代替 3 周期的后自增，把每行降到 98 周期，整块 2893 周期，比朴素版快 60%。还是不够。

PSHS 与 PULS

Tom 去工程图书馆翻《MC6809-MC6809E Microprocessor Programming Manual》，发现 PSHS/PULS 一条指令就能把 D、X、Y 等寄存器压栈或出栈。他让 S 指向图块、U 指向屏幕，把两个堆栈指针当成源和目的指针，再加上 DP 寄存器，一次搬 7 字节。一行 14 字节两次搬完，加指针调整只要 56 周期，整块降到 1689 周期。

这套搬法有副作用：堆栈的压入和弹出方向相反，图块会上下颠倒，每行的两个 7 字节块还会左右互换。他把图块预处理成“按 7 字节块逆序”存放，绘制时的错位正好把图块还原。预处理只需做一次。

中断来敲门

音效带来了新问题。朋友开了硬件定时中断给 DAC（数模转换器）送样本，中断发生时处理器会往系统堆栈压状态，而复制例程已经把 S 抢走并指向参考图块，参考图块被写坏。

两人去全天候餐馆想办法。朋友提出把 S 和 U 对调，让 S 指向屏幕缓冲区，中断要破坏就破坏屏幕。之后他们又把图块绘制顺序改成从右到左、从下到上：中断污染的是当前图块前面的内存，下一块图画过去就会修好，而屏幕缓冲区在画完并等到垂直刷新后才显示，玩家看不到。

HN 上有人把这段和《The Story of Mel》并提，但更偏爱 Tom 这篇，因为它讲的是理解机器的快乐，不是传说。也有人感叹，这种在极慢机器上反复压榨、把想法硬塞进去的过程，正是 AI 时代缺少的。

Tim Peters 去世，Python 失去了它的“Timbot”

从 PEP 20 到混合算术

Guido van Rossum 在 Python 官方论坛宣布，Tim Peters 于 2026 年 7 月 15 日去世。他写道，很难高估 Tim 对 Python 的影响。

Tim 最广为人知的身份是《Python 之禅》（PEP 20）的作者，那段短诗至今可以通过 import this 在解释器里看到。Guido 记得更早的事：Tim 在 Python 最初发布后不久就找到它，做的第一件事是说服 Guido 让 int 和 float 支持混合算术，因为大多数用户会期望它们这样工作。

Timsort 与底层设施

2002 年，Tim 为 Python 列表设计了 Timsort，一种结合归并和插入的混合排序算法，后来被 Java 和 Android 采用。他在 2001 到 2014 年间担任 Python 软件基金会董事。

Neil Schemenauer 在论坛帖子里列了一份清单：Tim 把 Vladimir Marangozov 的 pymalloc 打磨成型；大幅优化了 dict 对象的算法，写了 dictnotes.txt；循环垃圾回收器由 Neil 写了初版，Tim 把它打磨得健壮高效；简单生成器也是 Neil 写了初版，Tim 把 PEP 和实现都放到了坚实基础上。doctest 的初版、difflib、pickletools、tabnanny 都出自他手。float 对象和 math 模块得到他的特别关注，longobject 里的 Karatsuba 大整数乘法算法也有他的工作。

耐心、幽默与“Uncle Timmy”

他在 Python 邮件列表上以“Timbot”的绰号闻名，来自他无数耐心细致的回答，里面总带着温和的幽默，标着或 <0.5 wink>，常说自己是在替 Guido 传话。

Chris McDonough 描述 Tim 没有半点架子。留着灰色长发、浓密胡子，穿着工装风格，要不是早知道他是计算机天才，会以为他是个摩托车手或机械师。Chris Angelico 说 Tim 从不把人当白痴，总是回答和解释。Pablo Galindo 回忆 Tim 审阅他的代码，会以令人难以置信的耐心过他的补丁，解释方式总让你觉得自己聪明而不是迟钝。

论坛上有人提到，Tim 在最后阶段被 Python 指导委员会禁言。Steve Holden 写道，Tim 没有让这件事影响他帮助别人的意愿，直到最后都在展现这一点。David Mertz 说，自从得知消息，每个缺少 Tim 评论的帖子下面，他都会叹口气、掉一滴泪。

Tim 的最后一帖在讨论标准库排序数据结构时写道：“这一切都是在啰嗦地说明，现实世界比我们干净的抽象所期望的要复杂得多。”

AWS 发布官方本地模拟器

不用账号，不用付费

AWS 把 AWS Emulator 放上了 GitHub 和官方文档站。它是一个本地模拟 AWS API 的程序，请求发到模拟器而不是 AWS，不需要 AWS 账号，也没有额外服务费。你按平常的方式写代码，只是用环境变量把 AWS CLI 或 SDK 的端点指过去。它没有图形界面，定位是构建和测试，文档写明不要用于生产负载或安全测试。

上手有三条路：给 AI 编码代理装一个 skill，用 aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1；服务器模式在 Linux 上装 RPM 或 Debian 包，Windows 和 macOS 用 Dockerfile 构建容器；嵌入模式面向 Rust 测试，把模拟器作为 dev-dependency 引入，每个测试跑一个隔离实例。从源码构建需要 Rust 工具链、C 编译器、至少 100 GB 空闲磁盘给 target/。

保真度分数

每个 release 的 releases 页会发布保真度分数，仓库的 issues/ 目录跟踪单个差距。社区有人把 v1.0.322 的 scores.json.gz 和评估套件清单对起来，算出通过率：DynamoDB 69%、SQS 68%、S3 62%、Lambda 53%、EC2 40%、CloudFormation 36%、Athena 22%。这些数字衡量的是行为检查的通过率，不是 API 表面覆盖率。

安全是明确的短板。AWS 文档说不要用模拟器测试 IAM 策略和权限边界、基于资源的策略、KMS 密钥策略、跨账号或跨区域访问。模拟器只对在它内部创建的 IAM 用户和角色做部分策略评估，它从不拒绝用自己的密钥签名的请求。

两万九千次提交与 agentic 开发

有 AWS 员工在 HN 上回复说这是会维护的正式产品，并指向发布博客和 CTO 的推文。怀疑没有消失：有人觉得公告谈的是“几千个自主 AI 代理写了每一行代码”，却没有维护承诺和兼容性矩阵，更像一次科学实验。

仓库三周前初始化，已有 29,684 次提交，GitHub 的代码频率图因为提交太多无法生成，contributors 列表为空，提交作者是 IssueFinderAgent 这类代理身份。支持者认为这恰好是 agentic 开发最合适的场景：任务边界清晰，可以用真实 AWS 的请求和响应做验证，属性测试（property testing，用生成的大量输入检查程序是否满足某个性质）和中间人代理能给出明确反馈。反对者说这看起来像 vibe slop，担心没人真正读过代码。

关于 API 变化，有人担心模拟器跟不上 AWS 的更新节奏。回应是 AWS 的服务模型已经用 Smithy 描述，客户端从 Smithy 生成，模拟器也用每个服务的 Smithy 模型驱动线上协议，至少能覆盖每个端点的字段和变体。

和替代品的关系绕不开。LocalStack 从 2026 年起免费版仅限非商业使用；Floci 支持 AWS、GCP、Azure；Ministack 是针对 LocalStack 的 vibe-code 替代品。AWS Emulator 的卖点是官方维护、CC0 许可、嵌入 Rust 模式，以及基于 Smithy 模型的覆盖。

Apple 的 Harbor：把 Mac 变成私有 AI 推理服务器

插上线就能组集群

爆料者 Aaron Perris 发现，Apple 正在开发一款名为 Harbor 的 Mac 应用，目标是把 Mac 变成一台私有的 AI 推理服务器（inference server，指专门运行模型、响应请求的机器）。Harbor 让用户在 Apple 芯片上本地运行开放权重模型（open-weight models，指权重公开、可自行下载部署的模型），数据不离开本机硬件，也不上传云端。用户还可以用 Thunderbolt 5 连接多台 Mac，把统一内存（unified memory，CPU 与 GPU 共享的内存池）汇聚成一份推理资源，运行单台机器放不下的大模型。

应用强调三点：插上线就能用，自动通过 Thunderbolt 5 发现设备并组建集群；应用内可以浏览、下载、加载模型；两台以上支持 Thunderbolt 5 的 Mac 可以组成集群。Harbor 目前挂在 Apple 旗下 Claris 品牌下做私有预览，公开发布的时间还没确定。

Apple 是赢家还是输家

HN 上一条讨论线是 Apple 在 AI 时代的位置。有用户认为 Apple 会是这一章的赢家：模型蒸馏（distillation，把大模型的能力压缩到更小模型里）在持续奏效，同等能力需要的参数越来越少，Apple 显然押注这条路。

用户 aurareturn 认为 Apple 是输家：iPhone 和 App Store 的主导地位会被 ChatGPT、Claude 这类助手削弱，很多生产力应用正被生成式 AI 取代，服务商也在让 AI agent 直接接入，不必经过 App。反驳角度是生意本身：App Store 收入约占 Apple 总营收的 6 到 7%，利润率约 75%，折算到总利润的 15 到 20%。Apple 也能从别处赚钱，卖最适合本地推理的硬件、卖 AI 集成更好的手机、卖服务。

本地推理与云端的账

另一条线是成本与能力之争。有评论认为 LLM 推理有巨大的规模经济，本地模型在可预见的未来都打不过云端价格，隐私是它唯一的角度。反方举出的账是：按 Sonnet 的 API 价格，一台 128GB 的 M5 Max 几个月就能回本，本地跑的 Qwen 级别模型在日常使用上已经够用。也有用户说自己用 128GB Mac 跑 Laguna 2.1，在编码任务上做到 800 tokens/s，水平接近 Sonnet 4.5 或 Opus 4。

容量和价格是绕不开的现实。当前 Mac Studio 最高 512GB，有传闻称 M7 可能支持 1.5TB，但评论普遍认为这不是架构上限，而是成本和供应问题：512GB 版本售价超过 2 万美元。另有用户提醒，在笔记本上跑大模型会发热、风扇狂转、电池迅速耗尽，真正合适的形态可能是一台插电放在角落、类似路由器的设备。

企业侧的诉求更直接：不想把公司私有数据发给模型供应商，希望一次买断硬件后不再为 token 付费，只承担电费。

电压故障注入：把 8GB 矿卡变成比 A100 还快的 A100

一枚被分级到极致的芯片

作者 Kate 在 GA100 芯片上发现了一个电压故障注入漏洞，可以烧写任意熔丝，把 CMP 170HX 8GB 矿卡变成等效的 A100-80G。更意外的是，解锁后的卡比零售 A100 还快约 1.2 倍：她启用了芯片上全部可用的 SM（流式多处理器，约 120 到 126 个），而 NVIDIA 为控制良率，所有量产 A100 都只开 108 个。

GA100 被用于近 20 种 SKU。晶圆上切下来的 GA100 有 128 个 SM、12 个 FBP、5 个 NVDEC、一个 PCIe Gen4 x16 控制器，以及 4 到 6 堆 HBM。NVIDIA 用 eFuse 做良率控制和产品分级。CMP 170HX 是分级最极端的一例：8GB 版本名义上只暴露 8GB 显存，实际板载约 80GB HBM。

卡住所有人的 SBFE

熔丝控制器包含 16,384 个 eFuse，负责读取和烧写熔丝，并把结果转换成选项字。512 行分成四类，其中 FF 区最有意思：它像一条 JTAG 链，写入新的 FF 行可以清除之前设置的选项位，不需要物理上“反烧”熔丝。

真正卡住所有人的是一个叫 OPT_SECURED_BURN_FEATURE_ENABLE 的选项字。量产卡上它恒为 1，此时只允许烧写 FPF 区域；要烧 FF 区，必须让它变 0。

Kate 的办法是电压故障注入：在芯片启动时施加短暂的欠压脉冲，干扰熔丝控制器的感应过程。她用一块 STM32G4 板卡拦截 GA100 发给 MP2888B 电压调节器驱动芯片的 PWMVID 信号，用自己的波形替换。硬件上只需要两根接线和移除一个 0402 零欧电阻。一次毛刺实验的流程是：断电、上电、NVVDD 越过 225mV 时启动计时器、按计时发射 PWMVID 波形、观察卡的状态。解锁一张卡大概需要 1 到 48 小时的毛刺时间。

她在这个状态卡了很久，直到尝试发送一条此前没试过的 SENSE_CTRL 命令。结果所有控制熔丝派生的选项字都回到熔丝值，唯独 DSOV 保持 0。于是她可以把 SBFE 遮蔽为 0，再通过 DSOV=0 打开 FUSEWDATA 的主机访问权限，按芯片实际情况烧写 FF 行。

解锁之后

显存方面，8GB 卡中约九成板载 80GB HBM 完好，解锁后全部可用。计算方面，170HX 出厂只开 70 个 SM，实际芯片上几乎总有超过 120 个非缺陷 SM，全部启用后 FP16 FMA 吞吐达到 85.858 TFLOP/s，是零售 A100 的 1.18 倍。PCIe 方面，清掉相关 FF 位后 Gen3/Gen4 能正常训练。NVLink 还需要在 PCB 上短接 U11 芯片 footprint 的两个引脚，以及绕过固件里的 ROM 检查。

HN 上有人感叹，不久前还把 80GB HBM 焊上去然后关掉九成。也有人怀疑这些熔丝本来就是因制造缺陷才锁的。多位评论者指出，CPU 和 GPU 的分级既包含缺陷屏蔽，也包含产品细分，生产后期良率变好之后，人为分级的成分更大。Kate 的数据侧面支持这一点：8GB 卡大多有完整的 80GB HBM，SM 也大多超过 120 个。

散热是现实问题：卡本身不带散热器，设计上用服务器散热器，噪音像喷气发动机。有买家说不需要降频，限制功耗不会牺牲太多性能，正用一台 200 美元的 Octominer 矿机架调模型。

Kate 把部分研究代码放在了 GA100VFI 仓库。她更感兴趣的是更深层的毛刺状态：许多默认烧断的安全相关熔丝被感应为未烧断，可能打开调试级 HS 执行等入口。

破解 Meta Ray-Ban 智能眼镜：无屏设备上的蜂鸣调试

从 OTA 包里挖出完整固件

作者在 2026 年 7 月查看 Pwn2Own 的目标列表，拿去年的类别做参考，结果在 Meta Ray-Ban 智能眼镜上拿到了任意代码执行。他装上控制眼镜的 Meta AI 应用，没拆机，走 OTA（over-the-air，空中升级）提取固件。

用 JADX 反编译应用后，他找到 OtaArtifactFetcher 和 OTAArtifactInfo，用 Frida 挂钩构造函数打印 downloadUri，拿到了 CDN 更新地址。下载下来是约 156 MB 的增量包。继续反编译，他发现 GraphQL 字段 device_firmware_full_update_only，于是挂钩负责添加 GraphQL 字段的通用方法，只在字段名完全匹配时把 false 改成 true，拿到了完整固件 zip。解压后是 Android 更新，包含 payload.bin，用 payload-dumper-go 导出镜像，挂载成文件系统。

用蜂鸣声当终端

眼镜上有开发者模式 DAT SDK，Meta AI 应用会实时下载 DAT APK 并装到眼镜上。固件 126 及之前不校验 DAT APK 是否由 Meta 签名，理论上可以装任意应用。他用 Frida 替换 $localFile、$appName 和包字段，把自己的自签名 APK 换进去。

眼镜没有屏幕，也没有日志。他用 android.media.ToneGenerator 让代码“叫”出来：3 声表示监听启动、正在找 Wi-Fi Direct 地址；5 声表示找到了，地址在 192.168.49.x 网段；4 声表示 TCP 31337 绑定成功；6 声表示出错。

手机同步照片和视频时会建立 Wi-Fi Direct 组，眼镜连上后拿到地址。他植入的应用在该地址监听 TCP 31337，手机用 nc 连过去就得到一个交互 shell。id 显示 uid=10097(u0_a97)，是应用沙箱里的普通应用权限。这份权限维持了大约 5 天。

签名校验与一个字节的开关

固件 127 开始强制校验 DAT APK 签名，开关在 MobileConfig 的 wss_appmanager.signature_verification_enabled。眼镜向手机要配置，手机从 Meta 服务器取回，再通过 Airship 转发给眼镜。设备只检查配置文件结构正确，不检查是否被篡改，所以手机能改其中任何 flag。他把保存值的 0.mctable 里一个字节从 0x80 改成 0x00，把校验从开启改为关闭，重新装回自签名 APK。

作者把整个过程报给了 Meta 的漏洞奖金平台，Meta 批准了这篇博客，他据此认为问题已经修复。

这算漏洞吗

HN 上的讨论很快转向一个更基本的问题：在自己拥有的设备上拿到 shell，算不算漏洞。malicka 说这像 PS3/PSP 时代的破解心态，把任意代码执行报给厂商，等于亲手关上别人自由使用设备的大门。RobMurray 说，在自己设备上拿到 shell 现在被当成漏洞，挺难过。

Aurornis 从防守方角度解释：任意命令执行同样会被攻击者利用，还有大量社会工程骗局会诱导用户打开开发者工具粘贴代码；厂商试过提供开发者模式，结果有人改坏了还找客服要新机。

博客评论里，Henry N. Aung 认为真正值得关注的是信任边界：签名校验本身没问题，问题在于执行校验的开关来自一个只做结构检查、可被手机篡改的配置文件。

美国首次要求筛查合成 DNA 订单

从自愿到验证

2026 年 11 月 5 日，美国白宫发布《国家核酸合成筛查政策》，首次要求联邦政府资助的科学家从美国批准的供应商处购买合成核酸和台式合成设备。供应商必须核实客户身份，并筛查订单中可能编码毒素或病原体的危险序列。政策在 340 天内分阶段实施，取代此前自愿性的行业自律体系。

斯坦福大学合成生物学研究者 Drew Endy 说，筛查从“自愿”变成了“验证”，这是真正的进步。MIT 生物技术专家 Kevin Esvelt 评价：“它做了点什么，而不是什么都不做。”

围栏上的大洞

Esvelt 指出，筛查只覆盖 50 个碱基对（base pair，DNA 双螺旋中两条链上配对碱基的数量单位）或更长的序列。想搞生物恐怖的人可以从多家供应商订购更短的片段，再拼接出危险序列。他已经写出能筛查短至 30 个碱基对风险的算法，并免费公开。“这是这项本来相当不错的政策的主要缺陷。围栏上有个明显的大洞，就别费劲建了。”

约翰斯·霍普金斯大学免疫学家 Gigi Gronvall 提醒，政策只覆盖美国。“我们只在美国处理这个问题。”她担心只盯合成 DNA 会漏掉其他制造危险病原体的路径，政策还只适用于新造的 DNA 合成设备，大量现有台式机器不受约束。

执行责任落在美国国家标准与技术研究院（NIST）头上，却没有配套资金。Endy 说：“NIST 被要求在一段很短的时间内做大量工作，而且只有在有钱的情况下才能做。”

HN 上的争论：生物武器到底难在哪

HN 的讨论从威胁本身是否被高估开始。有评论问：为什么大家怕 AI 驱动的生物恐怖主义？污染供水比开发病毒容易得多。反驳者算了一笔账：一个 50 万人的城市每天用水约 100 升/人，但实际摄入只有 2 到 5 升；若用二甲基汞这类极毒物质，每人至少需 100 毫克，整座城市要往饮用水里投放约 50 公斤。

支持担忧的一方认为，生物武器与供水污染的区别在于后果无法收束。一位评论者说，水污染可以关掉供水、用卡车送水；泄漏的生物武器极难控制，“可能变成我们必须永远应对的东西”。

也有人指出这条推理链跳过了太多步骤。一位评论者问：一个没有生物实验室技术背景的疯子，从用 AI 模拟病毒到真正释放，中间缺了多少环节？另一位说，即使 AI 能设计，培养、组装、测试都需要实验室技能和试错经验，“为什么我的质粒不表达”不是语言模型能回答的问题。

一位在家玩微生物的爱好者说，这项政策可能影响他和少数在公寓里养微生物的人。另一位说自己短暂入坑后意识到“这是一把上了膛的枪”，自己不够格安全摆弄，所以整体上支持监管。

为什么写《The BEAM Book》

15 毫秒的暂停

作者在 Klarna 维护核心系统十年，深知 BEAM（Erlang 虚拟机）上 15 毫秒的暂停足以卡住数百万笔峰值购物支付，引发圣诞夜凌晨三点的复盘会。他写《The BEAM Book》，是希望下一位工程师在咖啡凉之前就能修好这类暂停。

项目始于 2012 年 10 月 12 日，一个只有四行文字的 DocBook 文件。2013 年 O'Reilly 签下出版，Atlas 系统却开始藏起主文件、覆盖写到一半的章节。Git 历史像一本挫败日记：“把文件移到顶层以应对 Atlas”“Atlas 似乎在覆盖 book.asciidoc”。字数冲过 12 万，进展却爬得很慢。2015 年 5 月出版社安静地取消了合同。Pragmatic Bookshelf 同年接手，最终也取消了。

一次提交，六百多万个文件

2017 年 1 月 20 日，他把所有内容导入一个新仓库，一次提交：6,622 个文件，超过一百万行。重写停滞，项目也停了。3 月 23 日他用 Asciidoctor 在私有 GitHub 仓库里重新开始。4 月 7 日，在查尔姆斯理工大学讲课前几分钟，他把仓库设为公开。24 小时内，陌生人修了错别字、加了图、合入了 Creative Commons BY-4.0 许可。

2018 年 8 月的 Issue #113 标题是“请继续牛逼下去”，里面夹着表情符号的随手鼓励，至今在他动力低落时冒出来。书里覆盖调度器如何调度、进程内存管理、垃圾回收、BEAM 如何表示数据、编译器与模拟器如何工作，以及用 dbg、erlang:trace 等工具定位真实延迟问题。

坚持、边界与真实截止日期

他总结的经验：坚持胜过完美，两次取消的出版合同在简历上不好看，但一个没完成的想法更糟；边界很重要，他靠固定写作时间、关通知来推进；公开仓库带来了更正、鼓励和偶尔的推动；范围就是一切，他砍掉了 dirty scheduler、新 JIT 和调试器的细节；先发布再迭代，BEAM 每年都在变；真实截止日期有用，今年一月他决定赶在 Code Beam Stockholm 之前印出书，以为截止日期在秋天，结果会议是 6 月 2 日。

BEAM 在 HN 上的口碑

HN 的讨论从 Klarna 的 Erlang 背景展开。有人不知道 Klarna 用 BEAM，觉得这门技术被严重低估。一位开发者说 BEAM 是唯一能让不到 50 人的小团队撑到数百万日活的运行时；另一位说自己所在的不到 20 人团队每月服务 5 亿请求，之前用 Ruby 和 NodeJS/SvelteKit，现在 90% 在 Elixir 上。

讨论还延伸到调度语义。有人说 BEAM 是抢占式调度，进程用完分配的 reduction 就被抢占；有人纠正说 BEAM 在用户空间其实是协作式，函数调用和收发消息是让出点，只是函数式语言不停调用函数，所以感觉像抢占式。在 NIF（原生实现函数）里做重计算而不计数，会卡住调度器线程。

AI 时代的 Elixir 也被反复提到。有人说 Elixir 代码量少、信噪比高，LLM 写出来的质量不错；有人强调不可变值语言对 LLM 友好，模型不用猜传入的值会不会被改掉。也有人泼冷水：差异要等项目跑久了才显现，如果并发和基础设施不是复杂度的主要部分，BEAM 语言未必带来多少好处。

相关链接：