HN 热点简报 · 2026-11-12
整理：henri
本期关注智能体在考古发现与机票预订中的不同处境、谷歌的决策 API，以及开源项目如何应对人工智能生成的贡献。工程话题包括 Tim Peters 对 Python 的贡献、AWS 官方本地模拟器、机房消防事故和 SSH 密钥保护。智能电视隐私、苹果支持社区关闭，以及生产率增长为何没有带来更多闲暇，也引出了关于数字生活与工作的讨论。
AI 应用与开源
AI 智能体在 72 小时内「再发现」一处玛雅遗址
Pietro Miotti 在秘鲁旅行时想到：若宾汉发现马丘比丘时拥有今天的工具，会怎么做。智能体建议用激光雷达穿透林冠。他让约 48 个智能体按一份指南审看约 1200 平方公里的公开激光雷达图像，寻找金字塔、台地和广场，再检索文献与档案。其中一个山顶遗址有平整广场、高约 8 至 12 米的椭圆形金字塔，以及可能的蓄水坑；墨西哥国家人类学与历史研究所（INAH）回复称，该坐标尚无登记遗址。作者在 11 月 11 日补充更正：该地点其实已出现在 Estrada-Belli 等人 2025 年的测绘中，智能体漏查了文献，因此是「再发现」而非首次发现。全过程从灵感到 INAH 回复不足 72 小时。作者自称并非考古学家。
HN 讨论既有「这才是人工智能的好用法」和「vibe archaeology」之类的称赞，也有人呼吁先等专业考古学家核实。质疑者担心智能体常把听起来轰动的结论编得很圆，而对方未必敢质疑一名带着几十个智能体的工程师所提交的报告。作者自己的更正，正好印证了这种谨慎：登记缺位并不等于文献里是空白。也有人半开玩笑，建议各大模型公司把全球激光雷达再扫一遍。该帖以约 912 分成为当日最高分之一，评论数超过三百。
pietromiotti.comMy AI Agents (Re)discovered a Maya Site in 72 Hours
美联航禁止第三方 AI 智能体代客订票
CBS 报道，美联航周三宣布禁止第三方人工智能智能体（报道提及 Meta 的 Muse、OpenAI 的 dots 等）代旅客预订机票，理由是安全风险，并可能违反联邦规定。航司称，把账户凭证和支付信息交给个人第三方助手，可能泄露敏感信息，也可能造成误购、改账户或动用 MileagePlus 里程；用智能体办理值机等操作，还可能触及旅客须当面确认行李不含违禁品等规则。美联航将在自有数字平台以及旅行社、聚合商一侧，限制未授权的个人智能体。航空分析师 Henry Harteveldt 认为，公司不想再多一个比比价网站更强的中间层，也担心机器人查询推高成本。西南航空则已让 ChatGPT 用户查看其航班库存。Kayak、Hopper、Google Flights 等聚合渠道仍可预订美联航机票。
讨论普遍不买账「安全与合规」的说辞，认为更像是防止旅客找到更优价格，并提起美联航曾起诉 Skiplagged 的旧事。有人反问查询成本究竟有多高，以及会缓存结果的中间层难道不是更便宜；也有人指出航司自己也在使用人工智能，这是「行业智能体对抗消费者智能体」的军备竞赛。还有评论怀疑，技术上很难真正拦住本地大模型，最多只能让几个主流产品配合限制，并不能解决全部问题。
cbsnews.comUnited Airlines bans AI agents from booking flights on behalf of travelers
谷歌发布 Gemini Decisions API
谷歌 DeepMind 于 11 月 11 日发布 Gemini Decisions API，由新模型 Gemini Decision 1（gemini-decision-1）驱动，面向是非判断、选择题和量规打分等封闭式决策。一次请求可在文本、图像、音频、视频和 PDF 上并行评估最多 1000 个彼此独立的问题，输入最长约 256K token。模型在单次前向中给候选项打分，而不是逐个 token 生成答案；官方称端到端时延约 150 至 250 毫秒，输入每百万 token 收费 0.10 美元，输出 token 不计费。三种题型为 noul（是或否）、choice（2 至 255 个选项）和 score（有序量规），每项都带 0 到 1 的置信度，便于把模糊案例交给后备模型或人工。谷歌称内部已用于 Gemini Notebook 的模型路由、Stitch 的快速画布、CC 的表情选择，以及搜索里 MCP 工具的安全层。文档与演示已在 Google AI Studio 提供。
讨论把这次发布放进最近升温的「决策模型」赛道，有人认为它明显受到 Jev 一类产品启发，只是来得比 OpenAI 更晚。有评论称它比同赛道其他决策模型稍贵，但原生支持音频和视频，在这类输入上更有价值。也有人感慨「原来大家一直需要的是概率，而不只是语法约束的 JSON」，并追问这些概率究竟如何计算。另一些人则联想到谷歌关掉 Jules、迁移指引含糊，担心新接口同样短命，或者问大厂入场之后，独立的决策模型产品还剩多少空间。
blog.googleGemini Decisions API: Fast, calibrated multimodal decisions
开源项目集体限制人工智能生成的贡献
网站 osssaysno.com（Open Source Says No）汇集禁止或限制使用大模型、智能体等工具提交贡献的开源项目。页面显示最近刷新于 11 月 11 日，当时列出 23 个项目。示例包括 yt-dlp（严格禁止在任何贡献中使用 LLM、智能体或其他人工智能工具）、Immich（要求不要提交由 LLM 生成的拉取请求）、Meilisearch、Servo、stb 以及 Redox OS 等，限制范围常常覆盖代码、文档和议题。站点允许提交 GitHub 仓库链接，经自动政策检查后加入列表。
讨论并不一边倒支持「开源说不」。有人指出，点开分类后，多数项目其实标成 restricted（限制）而非全面禁止，标题因此有些夸张；Immich 一边限制外部由大模型生成的拉取请求，自己仓库里却有 agents 文件和 Claude 共同署名的提交。反对者担心，这会把本就缺少贡献者的项目进一步关在门外，关键应是披露并自负其责，而不是禁用工具。也有人同情维护者：真正的负担是难以分辨「理解问题的人」和「被模型壮了胆的人」，再叠加上议题和拉取请求暴增，禁止也许只是为了先撑过这一波。还有人觉得，公开贴标签会给仓库树靶子，却没有明显好处。
osssaysno.comOpen Source Says No软件工程与可靠性
Tim Peters 逝世
Guido van Rossum 于 11 月 11 日在 Python 官方论坛宣布，Tim Peters 已于 2026 年 7 月 15 日逝世（1952–2026）。Guido 写道，Tim 对 Python 的影响难以估量：他最为人知的是写下《Zen of Python》（PEP 20，可用 import this 查看），但在此之前早已是导师和语言共同设计者。Tim 在 Python 发布后不久就参与进来，首先说服 Guido 支持整数与浮点数的混合运算；他在邮件列表里耐心答题，常带上 <wink> 一类标记，有「Timbot」之称，并以数学和编译器经验参与深度设计讨论，为早期核心开发定下温和而严谨的语气。2002 年，他为 Python 列表设计了 Timsort，后来被 Java 和 Android 采用。同事补充，他曾在 Cray 编写超级计算机编译器，也参与过语音识别，并长期担任 Python 软件基金会董事。
HN 上许多老用户回忆，自己曾在 Usenet 和缺陷跟踪器里读他的帖子，学习数值方法和编程品味，并称他为 “Uncle Timmy”。有人直接贴出整篇 Zen of Python，也有人认为这条消息配得上首页黑栏。讨论的气氛以悼念和致谢为主，较少争论，核心是缅怀一位以幽默、耐心和工程判断力深刻塑造了 Python 文化的人。
discuss.python.orgIn Memoriam: Tim Peters 1952–2026
AWS 发布官方本地模拟器
AWS 在 GitHub 开源了 AWS Emulator：一个在本地模拟 AWS 接口的程序，用于在开发机、开发服务器或持续集成中测试软件，无需 AWS 账号，请求不会打到真实云上，也没有额外服务费。它没有图形界面，启动后通过环境变量把命令行或软件开发工具包指到模拟端点；在 Rust 测试中还可以把模拟器嵌入同一进程。Linux 可安装软件包直接运行，Windows 与 macOS 建议使用容器。文档提醒不要用于生产环境或安全测试，并按服务公布保真度分数，缺口记录在仓库的 issues 目录中。从源码完整编译需要大量磁盘（官方提到 target 目录可能要至少 100 GB）和多核机器。遥测默认开启，官方称做了最小化处理、不含请求内容和凭证，可用命令行参数、环境变量或配置文件关闭。
HN 立刻把它和 LocalStack、Floci、Ministack 等现有方案对比：有人期待终于出现免费的官方替代，也有人怀疑这只是一次演习、未必会长期维护，还有人觉得来得太晚，现在用人工智能给接口写模拟可能更快。有评论提醒，标题应写明「来自 AWS」，以免被当成又一个民间模拟器。也有人开始讨论，谁会在它上面做一套控制台界面。
github.comAWS Emulator
误报烟雾警报险些淹没 Jane Street 在纽约的唯一机房
前 Jane Street 系统工程师 Michael Bacarella 写了一则机房故事。公司长期坚持把机房放在交易楼层近旁，既担心服务器被偷走后泄露交易策略，也想保留冲过走廊拔掉电源的最后手段——这种思路部分来自有核潜艇经历的合伙人。机房位于纽约 1 New York Plaza 办公楼中段，配有在线不间断电源、精密空调、柴油备用电源和约十排机柜。一次承包商在隔壁预备室施工扬起灰尘，触发了烟雾报警：喷淋管网开始充压，同时空调被切断。喷头本身靠热熔塞开启，机柜失去冷却后温度会迅速升高，一旦超过约 150°F，喷淋就可能毁掉整室设备。当时住在步行约九分钟处的作者接到香港办公室电话后跑回 33 楼，逐柜拔掉电源，眼看温度升到约 143.6°F 后停下。当日市场已收盘，次日恢复运行。事后公司决定喷淋仍保留、程序收紧，并继续把服务器放在办公楼里。作者后来用 OCaml 写了按机群平均温度告警的监控。
讨论集中在机房消防常识：有人对为何不用卤代烷一类气体灭火、为何没有紧急断电按钮与烟感联动感到惊讶。也有人联想到飓风桑迪时期，纽约机房进水、工作人员往楼上扛油桶的旧事，并追问「唯一机房」这一说法是否精确。整体上，读者把它当成一篇紧张但结局还好的运维故事来读，也有人感慨：当初把机房放在走廊对面、以便「拔电源」的设计，并不是为了躲避喷淋。
michael.bacarella.comHow a false smoke alarm almost drowned Jane Street’s only NYC datacenter
用 macOS 安全隔区保护 SSH 私钥
Serge Gatezh 介绍如何把 SSH 私钥放进 Mac 的 Secure Enclave：私钥在与主处理器隔离的安全子系统中生成且不可导出，认证时由隔区完成签名，并可要求每次使用都经过 Touch ID 确认，磁盘上只留下无法单独使用的句柄。文章演示用 sc_auth 建立 P-256 非导出密钥，再以系统自带的 ssh-keychain 动态库作为提供者导出句柄，并把公钥写入服务器的授权文件。他记录了需要重新录入指纹、过时的 ssh-add 参数、以及默认不会自动发现特殊文件名等坑，并更正了公钥注释与 FIDO2 应用标识的说明。作者在 11 月 11 日更新：原生流程能够工作，但体验「难看」，自己已改用第三方工具 Secretive，后续还有第二篇文章。
讨论认可「密钥不落地」的方向，同时提醒这并非苹果重点宣传的稳定接口，系统更新后有可能改掉；密钥无法备份，必须另备登录途径。不少人已经或打算改用 Secretive、YubiKey 或 1Password 代理，并比较跨系统、容器和代理转发时的麻烦。也有人只用隔区密钥向虚拟机转发代理，让对远程仓库的操作必须经过指纹，以降低恶意软件偷走密钥的风险。另有评论以 WireGuard 把私钥放进钥匙串、升级后配置丢失为例，强调安全功能一旦失效，破坏性可能更大。
gatezh.comProtecting SSH Keys with macOS Secure Enclave (Native Approach)数字生活与工作
《The Verge》向电视厂商提出 17 个隐私问题
John Higgins 在 LG 被指通过电视监视之后，向亚马逊、苹果、谷歌、Hisense、LG、松下、Roku、三星、索尼、TCL 以及沃尔玛旗下 Vizio 等 11 家公司发出 17 道尽量只能回答「是」或「否」的问题，涵盖麦克风是否常开、是否存储或上传录音和转写、是否用自动内容识别截屏或采集观看记录、位置与账号信息、能否彻底退出、断网后是否缓存待传数据，以及加密和删除权等。一个月后，前三大电视品牌和主要流媒体盒子厂商给出了答复；Hisense 经五次联系均未回应，松下、索尼、Vizio 对许多问题未作答。LG 被不少读者视为答得最直接：语音和自动内容识别默认关闭，后者使用音频指纹而非截屏。苹果则多次不直接回答是或否。文中还提到东北大学的研究：Vizio 在用户退出后仍发送数据，三星和 Roku 的流量也只是减少，并非完全停止。作者提醒，自动内容识别通常仍可在设置里关闭。
HN 对监管罚款过轻、厂商说一套做一套并不感到意外。有人赞赏 LG 回答得直截了当，批评苹果用公关腔回避，连「能否清除数据」都不肯说一句「恢复出厂设置即可」。也有读者发现东芝等品牌不在名单里，或追问文章开头说「很多电视使用自动内容识别」，但表格里部分厂商又称自己不用，真正的部署落在哪些机型和软件上，写得还不够清楚。还有人抱怨网页体验差，并分享了存档链接。
theverge.comI asked every TV manufacturer 17 questions about how they spy on you
苹果支持社区将于 11 月 20 日关闭
苹果在官方讨论站发布横幅：Apple Support Community 将于 2026 年 11 月 20 日永久关闭；即日起不再接受新帖，进入只读状态。公司引导用户前往官方支持网站，并感谢曾经贡献时间和经验的社区成员。该论坛可追溯到 1998 年的 Apple Tech Exchange，中间经历过多次更名。The Verge 援引苹果对 MacRumors 的说明称，关闭是在评估战略和顾客需求之后做出的；苹果尚未说明数十年来积累的帖子在关闭之后是否保留，报道推测它们可能随之消失。
HN 讨论相当两极。一边觉得，这个论坛相对苹果的利润不过是九牛一毛，关站是进一步疏远社区，横幅里的感谢也显得空洞，许多老用户把身份和签名都押在这上面。另一边则说，这里早就信噪比很差，常见回复只是「苹果不看这里，去提反馈吧」，希望连站点一起关掉，以免搜索引擎继续指向过时偏方。也有人打听，除了 Reddit 之外还有没有替代社区，以及关闭的真实原因究竟是什么。
theverge.comApple is killing its Support Community forum next week
我们为什么还在这么拼命工作？
作者根据美国经济分析局投入产出表写道：1973 年四十小时能生产的东西，今天大约十六小时就能生产，也就是每小时产出约为当时的 2.5 倍；但 1938 年写入法律的四十小时工作周从未改变，按人口平均，2024 年美国企业部门的工作时间反而比 1973 年高出约 10%。凯恩斯在 1930 年预言，百年后生活水平将提高四到八倍，工作或可减至每周十五小时——按产出看，十五小时周似乎已经到来，按工时则没有。作者把「省下的二十四小时」拆开：约十八小时从未变成普通薪资，约六小时变成了收入，却没有变成闲暇。根子在于，工资同时承担「价格」和「领取社会产出的门票」两种功能。1973 年后，普通时薪购买力只上升约 19%，与产出分道扬镳；自动化先替代了常规岗位。文章提出的出路是：让工资只做价格，另外再发一张门票，例如投资即年抵税，使公共部门事实上持有新机器的一部分，并区别对待不可再生的土地。配套论文仍在审稿中。
评论迅速给出更短的答案：决策者把生产力变成自身权力，最拼命的人设定了高薪职位的竞争节奏，住房和相对地位竞赛吃掉了增益，生产率提高的好处流向了投资者。也有人说，远程办公再加上人工智能之后，不少知识工人其实在悄悄缩短工时，只是没有人愿意承认。讨论还回到分配问题：如果机器能够大规模生产，凭什么仍要求人靠出卖劳动才能消费。整体上，读者认同「进步没有变成闲暇」这一观察，对具体处方则未必一致。
wilsoniumite.comWhy Are We Still Working This Hard?