锐Owl 雷达 · 2026-10-05：Hinton 等 22 人联署 RSI 白皮书；Aleph Alpha 开源 78B-A3B 的 Kolibri；决策模型被 Red Hat 第三方实测回火

本期覆盖 2026-10-02 18:00 → 10-05 18:00（含周末 10-03 / 10-04，按规范周末动态并入周一）。三条线：第一条是「AI 造 AI」从论文词汇变成有作者名单的政策文件——Hinton、Bengio、Pachocki、Jack Clark 等 22 人联署的工作论文，把"AI 已在写自家 80% 的代码"这类厂商自报数字摆上台面，并承认证据只是初步的。第二条是新品类被第三方回火——决策模型（Jev / Clef）上线不到一个月，Red Hat 就拿出一份同题对照说它"没有更准也没有更快"，同期两篇 arXiv 给出互补证据。第三条是 agent 时代的成本手刹——Simon Willison 的 HN 热帖加上 AWS、Google Cloud 各自刚上线的硬预算上限。另外一条开源大模型（Aleph Alpha Kolibri，78B-A3B 英德双语）和一条 agent 安全评测（15 个注入检测器的榜单分数不可迁移）。本期 5 条。

① Hinton、Bengio、Pachocki、Jack Clark 等 22 人联署：AI 已在写自家 80% 以上的代码，「软件驱动的智能爆炸」值得提前准备（arXiv 2026-09-28）

2026-09-28 提交到 arXiv 的工作论文《What if automating AI R&D triggers an intelligence explosion?》，共 22 位作者：图灵奖得主 Geoffrey Hinton、Yoshua Bengio、Andrew Barto，OpenAI 首席科学家 Jakub Pachocki，微软首席科学官 Eric Horvitz，Anthropic 联创 Jack Clark，以及 Dawn Song、Jeff Clune、Philip H. S. Torr、Sheila A. McIlraith、Anton Korinek 等。论文的关键证据全部来自厂商自报，论文原文写明：Anthropic 报告"AI 系统占已批准代码的比例，从 2025 年 1 月的低个位数升到 2026 年 5 月的 80% 以上"，"仅需高层人类监督即可自主完成的 R&D 工作量，从 2026 年 3 月的 1% 升到 8 月的 26%"；OpenAI 称"代码执行 agent 已用于训练、评测与保护未来模型，AI 辅助几乎覆盖公司所有部门"，Google 称"几乎所有涉及写代码或配置、技术设计、研究构思的工作都在用 AI"。论文区分硬件与软件两条爆炸路径，聚焦"软件驱动的智能爆炸"——理由是算法、训练方法、agent 工作流、合成数据策略一旦被验证即可快速重新部署进下一轮研发，不像芯片要流片建厂，因此反馈周期可以很短。结论是审慎的：现有证据是"初步的、有时是混杂的"，不足以证明爆炸一定发生（论文也点到算力约束、难以自动化的任务与收益递减），但"一旦智能爆炸开始，可供行动的时间窗口可能关闭"；政策上给出三条优先级——让 AI 研发自动化变得可见（透明的进展报告，含在企业内嵌入独立审计方）、找到引导与约束爆炸的办法、准备社会去适应。The Guardian 于 2026-09-28 同日报道。

认知价值：① 这份论文最好的用法是把它当「待核清单」，而不是当既成事实。 它最硬的数字——80%、26%——全部是 Anthropic 自报，OpenAI/Google 那两句同样是自述，论文自己也承认证据 preliminary 且 mixed。这跟我们坚持的证据纪律一致：报告的价值在于它把"要测什么"列清楚了（AI 在 R&D 各环节的占比、自主完成比例、反馈周期），而不在于它给出的数字能不能直接引用。② 对我们的主线有直接含义。 如果"AI 造 AI"的回路成立，被压缩的不是某个模型的分数，而是我们做评测、做内容、做产线迭代的周转时间——"效率是衡量标准"会从"用 AI 提效"升级成"AI 在替 AI 提效"。该盯的问题很具体：我们自己的产线里，哪些环节已经能被 agent 接管、哪些还不能，以及接管之后质量关怎么设。③ 它提的"可见性"和评测界的"证据链"是同一件事。 论文要的是可复算的测量基础设施；这正是我们做横评的固定动作——不引单一总分、标注自报、每条给得出处。这条也是本期的隐性主题：下面 ③④ 两条，都是"没有可复算的第三方测量，厂商口径就会自己长成事实"的活例。

领域：industry-model ｜ 去向：feeds（喂养「AI 造 AI / RSI」选题：本栏目 9 月已多次写 RSI 与 Harness-RSI 论文，此篇可作政策与证据层的一手支点）｜ 等级：🟡

来源：🟢 一手已核（10-05 直读 arXiv 摘要与作者表）https://arxiv.org/abs/2609.36054 （Submitted on 28 Sep 2026；22 位作者，含 Hinton / Bengio / Barto / Pachocki / Horvitz / Jack Clark / Dawn Song / Jeff Clune / Philip Torr）｜🟢 论文原文明引数字与引文（自 PDF 直读）：Anthropic「AI 占已批准代码从 2025-01 低个位数 → 2026-05 超 80%」、「仅需高层监督自主完成 R&D 工作量 2026-03 的 1% → 2026-08 的 26%」，OpenAI 与 Google 的自述原文 ｜🟡 上述占比与自述均为 Anthropic / OpenAI / Google 自报，论文自标 preliminary 且 mixed → 整条按最保守档取 🟡 ｜🟡 媒体口径：The Guardian 2026-09-28《AI godfathers warn of runaway 'intelligence explosion'》https://theguardian.com/technology/2026/sep/28/ai-godfathers-warn-of-runaway-intelligence-explosion

② Aleph Alpha 开源 Kolibri：78B 总参数 / 3B 激活的英德双语 MoE，1M 上下文，Apache-2.0（官方 2026-10-03）

德国 Aleph Alpha 于 2026-10-03（德国统一日，官方博文自述"在德国统一日发布"）推出 Kolibri：英德双语 MoE Transformer，78B 总参数、3B 激活，支持最长 1M token 上下文（默认 vLLM 配置到 262,144，超 262k 需显式加 --max-model-len 1048576），权重以 Apache-2.0 在 Hugging Face 开放（Aleph-Alpha/Kolibri-1；HF 上该权重创建于 2026-10-02T05:54Z = 北京时间 10-02 13:54——权重先上、次日发文，BF16 版 10-02T08:07Z 跟进）。前身 Kolibri Origin（30B 总 / 3B 激活、65k 上下文）走同一条自建流水线，两版相隔约三个月，官方称这证明"把时间花在训练流水线上"是值得的投资（从数据摄取与清洗、消融、预训练、后训练到最终评测全自动，硬件故障或断连无需人工介入）。官方把它定位为**"主权（sovereign）"模型**：面向公共管理、工业与航空航天等受监管领域的德语、推理、数学、agent 行为做专项化；声明模型在德国构建、在德国与芬兰的基础设施上训练，构建时即考虑 EU AI Act、GPAI Code of Practice 与 GDPR；训练数据里德语 token 占 21.3%、翻译数据仅占 6%（官方理由：译文会带源语言的文化指纹，"是英德双语设计，而不是一个读过些德语的英语模型"）。部署走自研 vLLM 插件（aleph-alpha-inference，fp8 KV cache、自带 reasoning / tool-call parser，推荐温度 1.0 / top_p 0.97 / top_k 128）。官方 benchmark 表给出 AIME 2025 96.9、AIME 2026 96.0、GPQA-diamond 84.3、LiveCodeBench v6 85.9、SWE-Bench Verified 66.4、τ²-bench telecom 94.7、τ³-bench banking 38.1、BFCL v4 61.4 等，官方口径是"在数学、代码、grounding、长上下文上对标最多 4 倍激活参数的模型"。HN 热度 672 分 / 327 评论，官方 tech report 另得 109 分。

认知价值：① "主权模型"这条线在 10 月明显加速，权重正在被当产业政策工具用。 10-01 的 Cloudflare 决策模型、10-03 的 Kolibri、同期 Cohere 把旗舰转为开源——这批发布的共同卖点不是"最强"，而是供应链可审计 + 可本地部署 + 合规是继承属性。这套话术本身值得单独拎出来研究：它把"开源"从研究习惯改写成采购理由。② 78B-A3B / 1M 上下文是很实际的工程规格。 3B 激活意味着单机推理成本接近小模型，但注意力要撑到 1M——这正是我们本地/云端选型最常见的岔路口。如果要用一句话概括本季度 MoE 的三个方向：决策模型（10-02 ③）、本机推理引擎（10-01 ⑤）、以及这种"小激活 + 超长上下文"的行业专用模型（本期 ②）。③ 读它的成绩单要守自己的纪律。 整张表是厂商自测，而且官方自己定义了一个"质量 vs 服务成本 Pareto 前沿"来主张领先——这与 10-02 ③ 的 Cloudflare、本期 ③ 的 Red Hat 是同一个坑：别接厂商自选的合成口径，要回到逐项分数和第三方复现。我们的做法是先记下规格（小激活、1M、德语 21.3%），把能力数字标 🟡 待核。

领域：industry-model ｜ 去向：standalone ｜ 等级：🟡

来源：🟢 一手已核（10-05 直读官方博文全文）https://aleph-alpha.com/en/blog/kolibri-has-landed-a-sovereign-open-weight-model/ （2026-10-03；78B 总 / 3B 激活、1M 上下文、Apache-2.0、英德双语、德语 token 21.3% / 翻译 6%、"在德国统一日发布"、EU AI Act / GPAI Code of Practice / GDPR、vLLM 部署命令与推荐采样参数）｜🟢 HF API 直查（10-05，经 hf-mirror）：Aleph-Alpha/Kolibri-1 created 2026-10-02T05:54Z / likes 493 / downloads 2,453 / license apache-2.0 / 32 个 safetensors 分片；Kolibri-1-BF16 created 2026-10-02T08:07Z ｜🟡 能力数字全部为官方自测（AIME 2025 96.9 / AIME 2026 96.0 / GPQA-diamond 84.3 / LiveCodeBench v6 85.9 / SWE-Bench Verified 66.4 / τ²-bench telecom 94.7 / τ³-bench banking 38.1 / BFCL v4 61.4 等），未经第三方复现 ｜🟡 HN 平台数据（10-05 经 Algolia API）：《Kolibri: A Sovereign Open-Weight Model》672 分 / 327 评论（created 2026-10-03T09:36Z）；tech report 109 分

③ 决策模型上线一个月就被第三方顶回来：Red Hat 称 Jev / Clef 在速度与准确率上都不稳定领先（2026-10-02）

Red Hat Developer 于 2026-10-02 发布《Benchmarking AI decision models against traditional guardrails》（作者 Dr. Rob Geada / Dr. Mac Misiura / Shelton Cyril），搭了 9 个候选护栏 × 4 类方法：CPU 级预训练分类器（<200M，Red Hat OpenShift AI 3.6 默认护栏目录）、2019 年的 BART-large-mnli、专用安全模型 Shieldstral-1.0-3B 与 Nemotron-3.5-Content-Safety、通用 LLM-as-a-judge（Qwen3.6-35B-A3B），以及三个决策模型路线——开源替代 Laya、vLLM 用 Gemma 文本扩散模型做的 /v1/systemone 端点、TypeSafe 的 Jev-1.13.0；在"提示注入"与"内容安全/毒性"两个护栏任务上同题对照。文章结论原文：决策模型（如 Jev）没有在速度或准确率上可靠地超过 LLM-as-a-judge、预训练分类器或开源决策模型。文章进一步质疑其"新颖性"：zero-shot 文本分类器（如 BART-large-mnli）已存在多年；Laya 作者 Nandakishor Mukkunnoth 在 2026-09 撰文称底层技术并不新；而"Jev 式"能力很快被开源复刻。同期两条 arXiv 给出互补证据：2610.03324 HateDecide（University of Cyprus，6 种决策模型配置 × 4 个 hate-speech 数据集）发现——商业 LLM 只在 4 个数据集中的 1 个上显著超过所有决策模型；给模型补上"数据集自己的定义"会改变最多 28% 的预测却不稳定提升分类；把问题拆成多问只在 20% 的比较里显著提升；但在一个诊断集上，最好的托管决策模型以约 97% 更低的推理成本落后最好的商业 LLM 仅 1.6 个 macro-F1。2610.03387《Benchmarking Candidate Coverage in Typed Decision Models》（Monash）提出"候选覆盖"配对基准：在 TREC 5 候选、自然命名场景下，Laya 能检出 97.2% 的"参考答案不在候选中"，但同时误拒 69.7% 的正常样本；Jev 则是 24.8% / 0.0%（每个模型 23,932 条预测）。

认知价值：① 这是对 10-02 第③条的正面回火，而且发生在同一周。 一个 9-15 才由 TypeSafe 提出、9-30 出货、10-01 被 Cloudflare 加持的新品类，10-02 就被第三方指出"不比既有方法更好"——新品类的最短被质疑周期又刷新了。这就是我们坚持"不引单一总分、要等第三方复现"的现实理由：不是唱衰，而是新品类在头一个月里，厂商叙事和第三方测量往往相差最大。② 两条 arXiv 合起来是一条能直接用的选型规则。 决策模型的真实价值不在"更准"，而在**"够准且便宜约 97%"**；但它对"候选集是否完整"极其敏感——Laya 的 69.7% 误拒说明：缺一个明确的 none 通道，模型会把大量正常请求判成"没有答案"。要用它可以，但必须单独测"参考答案不在候选中"这一路，不能只看普通分类准确率。③ 这三份东西叠在一起，正好是一份"评测该怎么设计"的样本。 Red Hat 用 9 模型 × 4 方法做同题对照；Monash 用 present / absent 配对做诊断；HateDecide 把"给定义 / 拆问题"当独立变量。我们做自己的横评时，这三个设计动作可以直接抄。

领域：eval-evidence ｜ 去向：related（挂钩本栏目 2026-10-02 第③条 Cloudflare Clef / Jev Decision Index，以及 2026-09-25 起的 Jev 相关条目）｜ 等级：🟢

来源：🟢 一手已核（10-05 直读原文全文）Red Hat Developer《Benchmarking AI decision models against traditional guardrails》2026-10-02，作者 Dr. Rob Geada / Dr. Mac Misiura / Shelton Cyril https://developers.redhat.com/articles/2026/10/02/benchmarking-ai-decision-models-against-traditional-guardrails （9 候选护栏 / 4 类方法、结论原句、对 Jev 新颖性的质疑、BART-large-mnli、Laya 作者 9 月撰文、vLLM DiffusionGemma /v1/systemone）｜🟢 arXiv 摘要直读（10-05）：2610.03324《To Jev or Not? Evaluating the Accuracy and Efficiency of Structured Decision Models for Hate-Speech Moderation》https://arxiv.org/abs/2610.03324 ｜🟢 arXiv 摘要直读（10-05）：2610.03387《Benchmarking Candidate Coverage in Typed Decision Models》https://arxiv.org/abs/2610.03387 （Laya 97.2% / 69.7%、Jev 24.8% / 0.0%、每模型 23,932 条预测）｜🟡 HN 平台数据：该文帖 2026-10-02 得 65 分 / 对应评论（热度不高，本文价值来自内容而非热度）

④ 15 个 agent 注入检测器复评：榜单分数不迁移——BIPIA 冠军在 AgentDojo 上只抓到 2% 注入（arXiv 2026-10-02）

arXiv 2610.03448《Passing the Test You Trained On: Re-evaluating Prompt-Injection Detectors for LLM Agents》（2026-10-02 提交）问了一个很实在的问题：检测器在公开基准上的分数，能不能预测它在 agent 里的行为？方法上做了一个值得抄的设计——不接 LLM，直接重放两个 agent 基准（AgentDojo 与 τ-bench）的 ground-truth 工具调用，得到"构造上良性"的工具输出，再用差分重放给注入输出来打标；在这批输出与 BIPIA 上评测 15 个检测器（含 Meta 的 Prompt Guard 2）与 2 个任务感知 LLM judge。核心结论：检测器排名在基准之间迁移很差——BIPIA 上最好的检测器，在 1% 假阳性率下只能覆盖 AgentDojo 2% 的注入；一个能抓 72% AgentDojo 注入的检测器，在 τ-bench 上只有 15%。而工具输出上的假阳性率反而会迁移（各检测器从 0 到 90% 以上都有），也就是说"误杀"是可预测的、"抓到"不是。作者用训练数据解释了这个现象：BIPIA 的冠军是在完整 BIPIA 输入上训练的，而"见过 InjecAgent 的攻击串（以短提示形式）"并不能帮它在工具输出里找到它们；在两个 agent 基准上都表现最好的那个检测器与任何基准都不共享数据，是在 agent 风格输入上训练的。给出三条部署建议：用该 agent 自己的工具输出评测检测器、在低假阳性率下报检出率、并审计检测器到底是在什么数据上训练的。

认知价值：① 这条直接改我们做 agent 的默认动作。 把"我装了个 prompt-injection 检测器"当成安全证明是不成立的——检测器的公开分数和你实际部署的 agent 几乎没关系。可替代的做法很便宜：拿自己 agent 的真实工具输出造几百条评测集，先在 1% 假阳性率下看检出率，再决定上不上。② "假阳性率可迁移、检出率不可迁移"这个不对称很反直觉，但很有用。 它意味着风险更容易表现为 agent 被自己的护栏卡死（误杀普通工具输出、任务做不完），而不是被注入攻破——这和我们审片与产线里对"机制关"的关注是同一类问题：护栏本身的失效模式要先测，别只看它挡没挡住坏东西。③ 方法层面值得存档。 "不用 LLM 重放工具调用 + 差分重放打标"是一个便宜、可复算的评测构造法，我们自己做 agent 类实测时可以直接借用，不必依赖厂商提供的注入数据集——这也呼应 ① 里那份白皮书要的"可复算的测量基础设施"。

领域：agent-frameworks ｜ 去向：feeds（喂养「Agent 护栏 / 工具输出安全」选题）｜ 等级：🟢

来源：🟢 一手已核（10-05 直读 arXiv 摘要）https://arxiv.org/abs/2610.03448 （2026-10-02 提交；15 个检测器含 Meta Prompt Guard 2 + 2 个任务感知 LLM judge；BIPIA 冠军在 1% FPR 下抓 2% AgentDojo 注入；72% AgentDojo → τ-bench 15%；FPR 0–90%+ 可迁移；训练数据形式解释结果；三条部署建议）｜⚪ 备注：该条目页内"Author"栏与摘要作者串不一致（条目页为 S. Chen / J. Piet / C. Sitawarin / D. Wagner，摘要页首行署 Zhuowen Liu, JAIST），正文只记录方法与结论，不代其确定作者与机构

⑤ 每周 610 分的 HN 帖：agent 时代该把「硬预算上限」做成云服务默认值（2026-10-03）

Simon Willison 于 2026-10-03 发文《We're going to need default hard budget caps on pretty much everything》，主张按用量计费的服务与 API 应把硬上限做成默认：到 \$X/月就切断并返回错误，软上限（只发警告邮件）不够用。理由是 coding agent 与个人 agent 极大降低了"跑起会花钱的代码"的门槛，没人愿意半夜收到一封预算警告，然后发现"睡觉时某个野服务又多花了几百到几千美元"。文中摆出两条已经发生的行业动作：AWS 在 2026-09-16 的 builder 体验更新里加入项目级月度 spend limit（用完即暂停整个项目、停止资源；AWS 官方文档明确标注新版"正在向少数客户限量发布"，最低 \$20，50% / 75% / 90% 三档提醒，可选提前控制项：约提前 7 天停新资源启动、约提前 5 天暂停闲置资源、约提前 4 天暂停最高成本资源；被暂停后若 90 天内不处理会永久删除项目数据）；Google Cloud 则在 2026-07-28 上线 Spend Caps（公开预览，按"单项目 + 单服务"设月度上限，分钟级触发停止继续计费的使用，首批支持 Gemini API / Agent Platform / Cloud Run / Cloud Run Functions，50% / 80% / 100% 提醒，一键解除；注意 Committed Use Discounts 等固定承诺费不在覆盖范围内）。该文在 HN 得 610 分 / 302 评论。

认知价值：① "agent 让云账单风险外溢"第一次有了两手证据。 一边是个人开发者（合理）害怕 runaway 服务把自己搞破产而不敢用 AWS，另一边是两家云在同一个季度各自上线硬上限——成本控制从"给企业看的 FinOps 工具"下沉成了"给 agent 用户的手刹"。这个下沉本身就是一个信号：云厂商开始把"你的 agent 会失控"当成默认假设。② 对我们跑云 GPU / 做实测有直接意义。 我们的实测流程里应该把"每个项目必设硬上限 + 到额熔断"写成脚本的前置检查，而不是靠人盯——与"长等待挂监控"是同一条纪律。同时要记住 AWS 那条副作用：熔断之后得有人来解（90 天不处理即删数据），所以熔断设计里必须带显式的恢复动作。③ 判据层面，这条是个"读二手评论要回一手条款"的小样本。 它的价值不在 Willison 的观点，而在于它把两家厂商的官方条款摆在一处，我们又自己回原页核过：AWS 是限量发布、GCP 是公开预览且只覆盖单项目单服务、固定承诺费不覆盖。这正是我们处理二手来源的固定动作——观点可以引，条款必须回原页。

领域：inference-efficiency ｜ 去向：related（挂钩本栏目成本/推理效率分支，以及云 GPU 实测流程的前置检查项）｜ 等级：🟢

来源：🟢 一手已核（10-05 直读博文）Simon Willison《We're going to need default hard budget caps on pretty much everything》2026-10-03 https://simonwillison.net/2026/Oct/3/default-hard-budget-caps/ ｜🟢 一手已核（10-05 直读官方页）AWS《New AWS experience helps builders get started and ship faster》Posted on Sep 16, 2026 https://aws.amazon.com/about-aws/whats-new/2026/09/New-AWS-Builder-Experience/ ；AWS 官方文档《Create a spend limit in AWS Settings》（"releasing our new experience to a limited number of customers"、最低 \$20、50/75/90% 提醒、提前停新资源 / 暂停闲置 / 暂停最高成本资源、pause 项目、90 天删数据、最多 10 个项目）https://docs.aws.amazon.com/accounts/latest/reference/create-spend-limit.html ｜🟢 一手已核（10-05 直读）Google Cloud《Detect early and enforce firmly with Google Cloud's enhanced cost controls for AI spend》2026-07-28 https://cloud.google.com/blog/topics/cost-management/new-early-anomalies-and-spend-caps-on-google-cloud-budgets （Spend Caps 公开预览、单项目 + 单服务、Gemini API / Agent Platform / Cloud Run / Cloud Run Functions、分钟级触发、固定承诺费不覆盖）｜🟡 HN 平台数据：610 分 / 302 评论（created 2026-10-04T00:20Z）