<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="zh-CN"><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://unbug.github.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://unbug.github.io/" rel="alternate" type="text/html" hreflang="zh-CN" /><updated>2026-11-15T17:34:45+00:00</updated><id>https://unbug.github.io/feed.xml</id><title type="html">Micropaper 一分钟读论文</title><subtitle>Micropaper 一分钟读论文：每天用一分钟读懂一篇 AI 论文，并提供 AI 范式雷达与 AI 智创简报，覆盖智能体、大模型、AI 安全与专利机会洞察。</subtitle><author><name>unbug</name></author><entry><title type="html">一分钟读论文：《80 行改动，批量推理快 6 倍》</title><link href="https://unbug.github.io/one-minute-read-paper-parallel-prompting-shared-context/" rel="alternate" type="text/html" title="一分钟读论文：《80 行改动，批量推理快 6 倍》" /><published>2026-11-15T00:00:00+00:00</published><updated>2026-11-15T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-parallel-prompting-shared-context</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-parallel-prompting-shared-context/"><![CDATA[<p>UCSC 团队的预印本论文<a href="https://arxiv.org/abs/2611.15130">《Read Once, Answer Many》</a>发现，前缀缓存没有消掉共享长文档的成本：解码每步、每问仍要重读一遍文档 KV cache，往 SGLang 加约 <code class="language-plaintext highlighter-rouge">80</code> 行后 A100 快 <code class="language-plaintext highlighter-rouge">3.7</code> 倍、RTX A6000 快 <code class="language-plaintext highlighter-rouge">5.9</code> 至 <code class="language-plaintext highlighter-rouge">6.0</code> 倍。</p>

<h2 id="每问每步重读一遍-kv">每问每步重读一遍 KV</h2>

<p>论文把这笔账说得很直：decode 阶段被内存带宽卡住，成本随问题数增长。前缀缓存（让同一长文档不重复预处理的机制）只解决了预处理，KV cache（注意力层缓存的键值对）仍按问题数重复读。老路子 batch prompting 把多问拼进同一序列，文档确实只读一次，但答案只能逐个生成，后写的还要注意到先写的，既拖长又互相污染。作者的改法是把 P 个问题变成同一个请求里的 P 条回答流，并行解码，再在注意力 kernel 内加一个按流编号生成的掩码：每条回答只看得见文档和它自己的问题，P 条流共享同一次文档 KV 读取。掩码由两个定长索引张量在现有 Triton kernel 内算出，不构造稠密掩码，每个解码步形状固定，能被 CUDA graph 捕获。全程不删 token，不压缩语义，纯粹是执行层的并行化。</p>

<p><img src="/assets/images/parallel-prompting-decode-kv.svg" alt="传统 batch 每问每步重读文档 KV，Parallel Prompting 每步只读一遍" /></p>

<h2 id="三组数字各管各的口径">三组数字，各管各的口径</h2>

<p><strong>三组加速数字分属不同基线，不能混用</strong>。头条口径：对开启前缀缓存与 CUDA graphs 的 stock SGLang（FlashInfer 后端），CodeLlama-7B 这类 MHA 模型、<code class="language-plaintext highlighter-rouge">8k</code>–<code class="language-plaintext highlighter-rouge">16k</code> token 文档、每文档 <code class="language-plaintext highlighter-rouge">64</code>–<code class="language-plaintext highlighter-rouge">256</code> 问，A100 上 <code class="language-plaintext highlighter-rouge">3.7×</code>，RTX A6000（<code class="language-plaintext highlighter-rouge">48GB</code> 工作站卡）上 <code class="language-plaintext highlighter-rouge">5.9–6.0×</code>，两个 SGLang 版本都成立。第二组：换成与作者共用同一套注意力内核的 stock Triton 作基线，<code class="language-plaintext highlighter-rouge">5.1–7.5×</code>。第三组见下一节，真实基准上只有 <code class="language-plaintext highlighter-rouge">1.81×</code> 和 <code class="language-plaintext highlighter-rouge">1.12×</code>。</p>

<p>统计底气很足：<code class="language-plaintext highlighter-rouge">144</code> 次配对计时全部获胜（<code class="language-plaintext highlighter-rouge">2</code> 款 GPU、<code class="language-plaintext highlighter-rouge">2</code> 个版本、<code class="language-plaintext highlighter-rouge">6</code> 组负载、<code class="language-plaintext highlighter-rouge">6</code> 组输入），最慢的 Parallel Prompting 仍比同负载最快的 stock 快 <code class="language-plaintext highlighter-rouge">2.46–4.76×</code>（单边符号检验 p=<code class="language-plaintext highlighter-rouge">1.5×10⁻¹¹</code>）。最有画面感的那格：对 <code class="language-plaintext highlighter-rouge">16k</code> token 文档回答 <code class="language-plaintext highlighter-rouge">256</code> 问，stock SGLang 花 <code class="language-plaintext highlighter-rouge">60.0</code> 秒，新方法 <code class="language-plaintext highlighter-rouge">12.3</code> 秒。</p>

<p>显存账同样要标清口径：那是 HuggingFace 原型实验（非 SGLang 引擎路径）的结果，每批至多 <code class="language-plaintext highlighter-rouge">8</code> 问时占 <code class="language-plaintext highlighter-rouge">16.9 GiB</code>，不到标准 prompting <code class="language-plaintext highlighter-rouge">53.6 GiB</code> 的三分之一，还快 <code class="language-plaintext highlighter-rouge">2.1×</code>；放到 <code class="language-plaintext highlighter-rouge">32</code> 问则是用 <code class="language-plaintext highlighter-rouge">46%</code> 显存快 <code class="language-plaintext highlighter-rouge">4.3×</code>。站内《跑十轮不如跑一轮》<a href="/one-minute-read-paper-e-means-kmeans-successor/">（站内阅读）</a>同样是把老操作换掉、重新算一笔算力账的路子。</p>

<h2 id="gqa-刹车与长答案软肋">GQA 刹车与长答案软肋</h2>

<p><strong>收益取决于 stock 解码每步重读多少 KV</strong>。CodeLlama-7B 是多头的 MHA 模型；换成现在主流的 GQA（分组查询注意力）模型，每 token 的 KV 变小，stock 本来重读的量就少，加速缩水到 <code class="language-plaintext highlighter-rouge">1.3–1.9×</code>，只写快 6 倍而不交代 MHA 前提就是误导。真实长文本基准更冷：QuALITY 上 <code class="language-plaintext highlighter-rouge">2,086</code> 问共 <code class="language-plaintext highlighter-rouge">73.6</code> 秒，比 stock FlashInfer 快 <code class="language-plaintext highlighter-rouge">1.81×</code>；LooGLE 上只比 Triton 快 <code class="language-plaintext highlighter-rouge">1.12×</code>，反而比 FlashInfer 慢 <code class="language-plaintext highlighter-rouge">1.26×</code>。两边平均答案长度不同是主因：QuALITY 答案短，生成步数少；LooGLE 答案长，解码时长主导，文档 KV 重复读的占比被摊薄，共享读取的便宜也就省不出来，长答案是明确的失效边界。限制还有一串：仅支持 Triton 后端、单 GPU、贪心解码、离线批式（同一文档的问题须提前知道），输出因浮点运算次序改变并非逐位一致。论文自标 Preprint、无同行评审；代码仓 <code class="language-plaintext highlighter-rouge">jlab-nlp/parallel-prompting</code>（Apache-2.0，<code class="language-plaintext highlighter-rouge">2026-11-10</code> 建仓，<code class="language-plaintext highlighter-rouge">stars</code> 仅 <code class="language-plaintext highlighter-rouge">1</code>）自带逐表复现脚本与原始结果，<code class="language-plaintext highlighter-rouge">48GB</code> 工作站卡即可跑到头条场景，但发布四天，第三方独立复现目前为零。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2611.15130">Read Once, Answer Many (arXiv:2611.15130)</a></li>
  <li><a href="https://github.com/jlab-nlp/parallel-prompting">代码仓库 jlab-nlp/parallel-prompting</a></li>
  <li><a href="https://jlab-nlp.github.io/parallel-prompting/">项目页</a></li>
  <li><a href="/one-minute-read-paper-length-is-cheap-attention-context-rot/">站内：长上下文读不准的 context rot</a></li>
  <li><a href="/one-minute-read-paper-e-means-kmeans-successor/">站内：e-means 换掉 k-means</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="OneMinuteRead" /><category term="llm-inference" /><category term="kv-cache" /><category term="serving" /><category term="sglang" /><category term="batch-inference" /><summary type="html"><![CDATA[加州大学圣克鲁兹分校预印本只改 80 行 SGLang：同一长文档多问在解码时共读一遍注意力键值缓存，A100 提速 3.7 倍、最高近 6 倍、144 次配对全胜；GQA 模型缩到 1.3 到 1.9 倍，长答案还会倒退。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/parallel-prompting-decode-kv.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/parallel-prompting-decode-kv.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 范式雷达：《他们把设备搬回局域网》</title><link href="https://unbug.github.io/paradigm-radar-offline-sovereignty/" rel="alternate" type="text/html" title="AI 范式雷达：《他们把设备搬回局域网》" /><published>2026-11-15T00:00:00+00:00</published><updated>2026-11-15T00:00:00+00:00</updated><id>https://unbug.github.io/paradigm-radar-offline-sovereignty</id><content type="html" xml:base="https://unbug.github.io/paradigm-radar-offline-sovereignty/"><![CDATA[<p><code class="language-plaintext highlighter-rouge">2026-11-10</code> 至 <code class="language-plaintext highlighter-rouge">11-15</code> 的 Hacker News 实测到 <code class="language-plaintext highlighter-rouge">5</code> 个同主题独立爆帖（最高 <code class="language-plaintext highlighter-rouge">1199</code> 分，分数与全树评论数截至 <code class="language-plaintext highlighter-rouge">11-15</code>）：三个互不相识的人、一家大厂、一批开源项目，在同五天把矛头指向「云端依赖加订阅制」——设备主权正从抱怨变成有工具链的迁移。</p>

<p>口径先钉死：本文分数与全树评论数经 hn.algolia.com 接口于 <code class="language-plaintext highlighter-rouge">2026-11-15</code> 首采、<code class="language-plaintext highlighter-rouge">2026-11-16</code> 复采，两个时点的差值都会写明；仓库星数为 api.github.com 同日实测；评论区引语为原文摘译，全部附可定位的评论编号；转述与自述另行标注。复采时主锚帖升至 <code class="language-plaintext highlighter-rouge">1200</code> 分 / <code class="language-plaintext highlighter-rouge">443</code> 条，Lovable 泄露帖从 <code class="language-plaintext highlighter-rouge">910</code> 升至 <code class="language-plaintext highlighter-rouge">937</code> 分 / <code class="language-plaintext highlighter-rouge">337</code> 条，其余四帖分数未动。</p>

<p><img src="/assets/images/offline-sovereignty-wave.svg" alt="11-10 至 11-14 五根热度柱的时间线" /></p>

<p><img src="/assets/images/paradigm-radar-offline-recheck-bars.svg" alt="七帖首采与复测双时点对比：主锚 1199 到 1200、Lovable 910 到 937 为唯二变动，其余五帖封顶；底注指出「本地化」四帖已过爆发期" /></p>

<h2 id="三个互不相识的人">三个互不相识的人</h2>

<p>第一位是家居自动化博主 skittleson，帖《Smart home devices should work without the internet》冲到 <code class="language-plaintext highlighter-rouge">1199</code> 分（复采 <code class="language-plaintext highlighter-rouge">1200</code>）/ <code class="language-plaintext highlighter-rouge">443</code> 条评论：作者在评论区自报这是十年家居自动化规则的总结，第一条规则原文为「nothing core should depend on a vendor’s server」，核心栈是树莓派上的 Tasmota、MQTT 与 Node-RED（评论 <code class="language-plaintext highlighter-rouge">50441708</code>）。这条自报还有个插曲：有人当场抓包他的 Alexa 自动化违反了自己的规则，他的回答是核心系统离线仍可控制即可——规则的边界在讨论里被磨出了形状（评论 <code class="language-plaintext highlighter-rouge">50441708</code> 子树）。热度最高的长评来自 mountain_peak（<code class="language-plaintext highlighter-rouge">50443286</code>，子树 <code class="language-plaintext highlighter-rouge">110</code> 条）：他 <code class="language-plaintext highlighter-rouge">20</code> 年前买下一栋前房主经营家庭自动化公司的房子，全屋 X10/Insteon 布线与墙面触控面板原封不动，至今不需要任何订阅——一条来自真实住宅的反证，比任何宣言都硬。</p>

<p>第二位是逆向者 scottjg，帖《Reverse engineering my Coway air purifier to ditch the cloud》<code class="language-plaintext highlighter-rouge">792</code> 分 / <code class="language-plaintext highlighter-rouge">223</code> 条：拆开净化器换固件，只为不经过厂商云。第三位是绣花机机主 simpsoka，一台 <code class="language-plaintext highlighter-rouge">300</code> 美元设备要求订阅才能用，他干脆自研配套 App，Show HN 帖 <code class="language-plaintext highlighter-rouge">740</code> 分 / <code class="language-plaintext highlighter-rouge">256</code> 条，评论区还引出 DMCA 法理争论——买下的设备能不能自己修。</p>

<p>三人不同作者、不同设备、不同厂商，事件互不引用，也没有共同推动方。范式迁移的经典形状，恰是互不相识的人在同一周撞见同一堵墙。</p>

<h2 id="coway-帖里浮出的llm-逆向波">Coway 帖里浮出的「LLM 逆向波」</h2>

<p>净化器帖下最值钱的不是固件本身，而是对这批逆向的方法论定性。Aurornis（评论 <code class="language-plaintext highlighter-rouge">50484284</code>，子树 <code class="language-plaintext highlighter-rouge">37</code> 条）指出该机固件「通过明文 HTTP 下载根证书，从来都可以被中间人攻击」，并称这波 LLM 逆向工程最大的发现，是量产设备里早就躺着多少没人费力去挖的荒唐选择——会做这事的人各忙各的，现在工具让「费力的挖掘」第一次变得可行；tedd4u（<code class="language-plaintext highlighter-rouge">50486455</code>）追问 Coway 或其固件外包方当初为什么敢这么设计，无人能答。deadbabe（<code class="language-plaintext highlighter-rouge">50484045</code>）把模式说成趋势：买一个云端订阅设备、逆向它、接到自己服务器上，「这是 AI 促成的少数好事之一」。</p>

<p>冷水同样在场。jerf（<code class="language-plaintext highlighter-rouge">50484219</code>）警告窗口可能正在关闭：AI 公司已经动手封锁这类逆向用途，「趁还能做赶紧做」；simonsarris（<code class="language-plaintext highlighter-rouge">50485569</code>，自家两台无云 Coway 用户）反问为什么不直接买不联网的型号，「净化器不需要被监控」。评论区还反复给出第三条路：Corsi-Rosenthal 纸箱净化器——纸盒加四片 MERV-13 滤网加一台 <code class="language-plaintext highlighter-rouge">20</code> 寸风扇，完全绕开智能层，被顶了至少三次。</p>

<h2 id="绣花机一个全-ai-建造的应用与被核查的底稿">绣花机：一个「全 AI 建造」的应用与被核查的底稿</h2>

<p>Show HN 帖下最长的高赞子树来自 spdustin（<code class="language-plaintext highlighter-rouge">50472665</code>，子树 <code class="language-plaintext highlighter-rouge">142</code> 条）：他断定这个项目背后是 LLM 在干重活，并顺势写下这批人的共同信念——大模型第一次让用户「挠自己的痒处」变得可复制。作者 simpsoka 没有回避来源：协议是他用 PacketLogger 从零逆向的，实现过程里 agent 参考了开源库 Respira 做交叉验证，而「整个 App 是用 AI 构建的」，此话逐字可查（评论 <code class="language-plaintext highlighter-rouge">50475887</code>）。同一楼层他核了价：机器日常价 <code class="language-plaintext highlighter-rouge">499</code> 美元、事发时亚马逊 <code class="language-plaintext highlighter-rouge">303</code> 美元，并判断厂商是「先靠订阅把机器赔本卖出去，再越卖越便宜」——订阅制定价的反推，出自机主本人。</p>

<p>反方也留了档：nijave（<code class="language-plaintext highlighter-rouge">50474205</code>）担心这种好日子有保质期，OEM 迟早让模型给固件上安全启动、签名与防回滚，Google 系设备已是先例；inanutshellus（<code class="language-plaintext highlighter-rouge">50473697</code>）则把类比推到打印机自带墨盒——「西部时代又回来了」。</p>

<p><img src="/assets/images/paradigm-radar-offline-reverse-flow.svg" alt="两条路径对照：上方红色为厂商云链（设备→厂商云→订阅→停服→DMCA 阴影），下方绿色为机主逆向链（拆机抓包→Respira 交叉验证→AI 构建 App→本地可用→公开仓库），每环标注评论编号" /></p>

<h2 id="迟到的大厂与降本的极客">迟到的大厂与降本的极客</h2>

<p>Apple 宣布新 Mac App 让本地跑 AI 模型变得简单，帖《Apple has new Mac app coming to make running local AI models easy》拿到 <code class="language-plaintext highlighter-rouge">572</code> 分 / <code class="language-plaintext highlighter-rouge">564</code> 条评论——评论比点赞还多，声量全挤在讨论区，这本身就是需求侧证据。线程里最长的子树来自 pen2l（<code class="language-plaintext highlighter-rouge">50447085</code>，子树 <code class="language-plaintext highlighter-rouge">393</code> 条）：蒸馏路线让模型越来越小、本地跑越来越现实，Apple 是「这一章收尾时的赢家」；同线程 jph（<code class="language-plaintext highlighter-rouge">50450531</code>）给出罕见的自报账单：高端 Mac Studio 摊到约每月 <code class="language-plaintext highlighter-rouge">1000</code> 美元（三年期），对照他五个开发者用 Claude Ultra 的同额月支出，「等 API 定价改纯计费那天就切本地」。反方账同样在：gizmodo59（<code class="language-plaintext highlighter-rouge">50447737</code>）说万元预算内跑不动不量化的模型，「我想要但买不起」；tonymet（<code class="language-plaintext highlighter-rouge">50448149</code>）反问远程推理这么便宜为什么投本地，被 t-3 以「便宜的远程不是永远」驳回。同一窗口里，独立开发者的《I’m making LLMs work on small and old devices》<code class="language-plaintext highlighter-rouge">479</code> 分 / <code class="language-plaintext highlighter-rouge">180</code> 条：作者 mrashad74 自述把 <code class="language-plaintext highlighter-rouge">16B</code> 模型跑进可用内存不足 <code class="language-plaintext highlighter-rouge">1GB</code> 的 iPad Air 一代与小米电视盒，内核与改模全部开源，还说清代价——为配对模型与硬件做了 <code class="language-plaintext highlighter-rouge">107+50</code> 次实验（评论 <code class="language-plaintext highlighter-rouge">50468889</code>、<code class="language-plaintext highlighter-rouge">50471287</code>）；sebazzz（<code class="language-plaintext highlighter-rouge">50470839</code>）提醒这类小模型「还笨到没法挂工具」。另有 Edge0-145B 端侧模型帖 <code class="language-plaintext highlighter-rouge">353</code> 分 / <code class="language-plaintext highlighter-rouge">105</code> 条、Unsloth Qwen3.8-27B 量化更新 <code class="language-plaintext highlighter-rouge">252</code> 分 / <code class="language-plaintext highlighter-rouge">83</code> 条（均截至 <code class="language-plaintext highlighter-rouge">11-15</code>），把本地推理从「勉强能跑」推向「日常跑得动」。云端集中化的代价也有现成注脚：<code class="language-plaintext highlighter-rouge">11-14</code> 的 Lovable 应用泄露用户护照信息帖从 <code class="language-plaintext highlighter-rouge">910</code> 升至 <code class="language-plaintext highlighter-rouge">937</code> 分 / <code class="language-plaintext highlighter-rouge">337</code> 条，出事时泄露的是护照号。</p>

<h2 id="从抱怨到购买守则与工具链">从抱怨到购买守则与工具链</h2>

<p>热度正在落成两类可复制的东西。第一类是购买守则：reasonabl_human（评论 <code class="language-plaintext highlighter-rouge">50442644</code>）的规则清单是「买能干活的最便宜硬件、无视软件差评、到手先让 Claude 写本地优先固件」；driverdan（<code class="language-plaintext highlighter-rouge">50446355</code>）只买 Zigbee/Z-Wave 或固件可替换的设备，且非传感器设备必须脱离 App 也能全功能；scosman（<code class="language-plaintext highlighter-rouge">50443914</code>）用 Home Assistant 官方 IoT Class 分级过滤，只装 Local Push 与 Local Polling 档。守则以前只存在于老玩家的肌肉记忆，现在被写成了可检索的条目——这是「迁移」最具体的形状。</p>

<p>第二类是工具：绣花机自研 App 的仓库 zigzag 复采 <code class="language-plaintext highlighter-rouge">783</code> 星（建仓 <code class="language-plaintext highlighter-rouge">10-30</code>，描述直接写着「通过 MCP 用 AI agent 做刺绣设计」）；发布于 <code class="language-plaintext highlighter-rouge">11-04</code> 的 smolmaxxing <code class="language-plaintext highlighter-rouge">728</code> 星；主锚帖讨论的自建替代方案，生态底座 home-assistant/core <code class="language-plaintext highlighter-rouge">92,318</code> 星（复采，仓库描述「local control and privacy first」，建仓 <code class="language-plaintext highlighter-rouge">2013</code> 年）。这与上期《Goodbye Claude, hello Pi》的「执行壳」搬家不同——那期搬的是开发者工具的位置，这期下沉到灯泡、净化器与绣花机。本地计算与云依赖的隐性成本，此前在<a href="/paradigm-radar-agent-hidden-cost/">《AI 范式雷达：Agent 的隐藏成本》</a>已算过一笔账；而在<a href="/paradigm-radar-erc8004-trust-infrastructure/">《AI 范式雷达：ERC-8004 与信任基础设施》</a>里，「去云端化」走的是链上信任这条相反路径。本期这批人选择的路线，是让自己的数据一步都不出家门。</p>

<h2 id="第二线旧硬件回收流">第二线：旧硬件回收流</h2>

<p>同一五天还有第六帖补充底盘：《Why get an expensive Pi when I have an old phone?》<code class="language-plaintext highlighter-rouge">599</code> 分 / <code class="language-plaintext highlighter-rouge">318</code> 条（复采；<code class="language-plaintext highlighter-rouge">11-15</code> 首采 <code class="language-plaintext highlighter-rouge">590</code>/<code class="language-plaintext highlighter-rouge">312</code>），作者把旧安卓机刷机当家庭服务器。顶路子树来自 deng（<code class="language-plaintext highlighter-rouge">50496293</code>，<code class="language-plaintext highlighter-rouge">130</code> 条）：收屏幕碎掉的旧笔记本拆主板，<code class="language-plaintext highlighter-rouge">16GB</code> 内存随手就能给 <code class="language-plaintext highlighter-rouge">x86</code> 派生态，比树莓派快且便宜。Freak_NL（<code class="language-plaintext highlighter-rouge">50495561</code>，<code class="language-plaintext highlighter-rouge">46</code> 条）点出规模化的真瓶颈：买两台旧手机容易，凑几百台同型号、电池健康、摄像头行为一致才是难处——树莓派是「要一百台就有一百台」的通用货。反方口径同样齐：yjftsjthsd-h（<code class="language-plaintext highlighter-rouge">50495586</code>）一句话版——「因为 Pi 有维护良好的内核和不用打架的用户空间」；randomblock1（<code class="language-plaintext highlighter-rouge">50495681</code>）列 GPIO、文档、一致性等清单；shit_game（<code class="language-plaintext highlighter-rouge">50496122</code>）抱怨手机从设计上就防着用户，「我想要到手即用、不跟我较劲的东西」。旧硬件流的成熟度，比固件逆向还早一个身位。</p>

<h2 id="反方同样在场">反方同样在场</h2>

<p>反弹叙事并不缺反驳。其一来自厂商立场：把设备逻辑放上云是成本理性，一台 <code class="language-plaintext highlighter-rouge">40</code> 美元设备不可能附带终身本地固件维护，云推送是最便宜的兼容层。其二，个人逆向的固件没有安全审计与后续维护，变砖责任归用户，厂商一纸律师函就能下架；nijave 的安全启动预言（<code class="language-plaintext highlighter-rouge">50474205</code>）给这条接上了技术路径。其三，「智能家居本就该躺在货架上」——cadamsdotcom（<code class="language-plaintext highlighter-rouge">50448617</code>）算的是总账：去云意味着自己养一个脆弱控制器、买前研究、坏了更常修，付出的生命能量换不来普通人的便利；同线程 thibsrn（<code class="language-plaintext highlighter-rouge">50443406</code>）建议学食品营养标签做隐私分级来矫正市场，c-linkage（<code class="language-plaintext highlighter-rouge">50443592</code>）回他说普通人只想开箱即用，根本不在乎本地优先。其四，便利发明本身在退化为负担：everdrive（<code class="language-plaintext highlighter-rouge">50443875</code>）「它们先是能用，然后一更新就说不清发生了什么」，跟帖援引美海军因触屏改回物理旋钮。其五——来自主锚轴内部的自反：旧手机帖 <code class="language-plaintext highlighter-rouge">599</code> 分提醒，为 <code class="language-plaintext highlighter-rouge">300</code> 美元设备写固件是少数人的特权，本地化本身也有成本门槛，沉默的大多数仍用脚投票选了省心订阅。另有观察轴在跟进，本期不展开。范式是否真的迁移，最终不看谁在写固件，看多数人的账单。</p>

<h2 id="云侧事故注脚lovable-的账">云侧事故注脚：Lovable 的账</h2>

<p><img src="/assets/images/paradigm-radar-offline-lovable-funnel.svg" alt="泄露漏斗：Common Crawl 扫出 159,041 个公开在册项目 → 34,545 个用 Supabase → 抽样约 2.5% 在泄露用户数据；下方并排厂商「RLS 未配置」定性与线程「7,500 运营者无动于衷」反击" /></p>

<p>本地化叙事的对侧，<code class="language-plaintext highlighter-rouge">11-14</code> 冲榜的 Lovable 泄露帖把云端一侧的成本量化到了个数：研究者 neathack（作者自报，评论 <code class="language-plaintext highlighter-rouge">50499563</code>）用 Common Crawl 归档扫出 <code class="language-plaintext highlighter-rouge">159,041</code> 个 Lovable 项目在 <code class="language-plaintext highlighter-rouge">2025-12</code> 至 <code class="language-plaintext highlighter-rouge">2026-09</code> 间公开在册，其中 <code class="language-plaintext highlighter-rouge">34,545</code> 个用 Supabase，抽样里约 <code class="language-plaintext highlighter-rouge">2.5%</code> 的项目在泄露用户数据，护照号在列。Lovable 安全负责人 igorandri（<code class="language-plaintext highlighter-rouge">50502105</code>）到场定性：根因是 Supabase 行级安全（Row-Level Security，数据库按行给用户放行读的规则）没配好，平台发布前自动扫描并提供一键修复；varenc（<code class="language-plaintext highlighter-rouge">50502127</code>）回击：约 <code class="language-plaintext highlighter-rouge">7,500</code> 个站点运营者对平台已发出的告警无动于衷，这本身就是平台的系统性失守——「提示了但没人点」不能豁免分发方。一键修复与自动修复（auto-fix）能否把这条曲线压下去，是本期留下的观察点之一。还有个值得记录的传播学细节：作者自述这份研究两周前首发无人问津，复投才冲上近千分（评论 <code class="language-plaintext highlighter-rouge">50499563</code>）——云侧事故的声量同样靠二次点火，本地化叙事的热度里也有同一种复投机制在起作用。</p>

<h2 id="口径与边界">口径与边界</h2>

<p>三个人的自述均为评论区署名自报，未经独立核验；<code class="language-plaintext highlighter-rouge">92,318</code> 星等大数只说明开源热度，不等于收入；Apple 帖的热度不构成对任何芯片路线的背书；「LLM 逆向波」是线程参与者的定性说法，本文按其原文引用。本期不主张「订阅制已死」，主张的只是：五天、六个帖簇、互不引用的主体，同时把「设备主权」从抱怨做成守则、固件与应用——动作密度本身即证据。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://news.ycombinator.com/item?id=50441707">Smart home devices should work without the internet</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50474959">Reverse engineering my Coway air purifier to ditch the cloud</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50470488">My $300 embroidery machine needed a subscription, so I built my own app</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50446520">Apple has new Mac app coming to make running local AI models easy</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50468888">I’m making LLMs work on small and old devices</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50440709">Why get an expensive Pi when I have an old phone?</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50499017">Lovable apps expose passport details</a></li>
  <li><a href="https://github.com/simpsoka/zigzag">simpsoka/zigzag</a></li>
  <li><a href="https://github.com/hyperionaidev/smolmaxxing">hyperionaidev/smolmaxxing</a></li>
  <li><a href="https://github.com/home-assistant/core">home-assistant/core</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50441708">skittleson 作者自述评论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50443286">mountain_peak 二十年老宅长评</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50484284">Aurornis 论 LLM 逆向波</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50486455">tedd4u 追问明文 HTTP 根证书</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50484045">deadbabe 趋势定性评论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50484219">jerf 封锁警告评论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50485569">simonsarris 无云购买论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50472665">spdustin 高赞长评</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50475887">simpsoka 自述逆向与 AI 构建</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50474205">nijave 安全启动预言</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50473697">inanutshellus 打印机类比</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50447085">pen2l Apple 赢家论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50450531">jph 本地 vs 订阅自报账单</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50447737">gizmodo59 买不起论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50448149">tonymet 远程便宜论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50468889">mrashad74 小设备项目自述</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50470839">sebazzz 小模型无用论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50442644">reasonabl_human 购买守则</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50446355">driverdan 协议守则</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50443914">scosman IoT Class 过滤法</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50496293">deng 旧笔记本主板路线</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50495561">Freak_NL 旧手机规模化瓶颈</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50495586">yjftsjthsd-h 树莓派内核论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50495681">randomblock1 树莓派清单</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50496122">shit_game 手机防用户抱怨</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50448617">cadamsdotcom 货架论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50443406">thibsrn 隐私标签建议</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50443592">c-linkage 普通人开箱论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50443875">everdrive 便利退化论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50499563">neathack 作者自报扫描口径</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50502105">igorandri Lovable 安全负责人回应</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50502127">varenc 系统性失守反击</a></li>
  <li><a href="/paradigm-radar-agent-hidden-cost/">站内：AI 范式雷达《Agent 的隐藏成本》</a></li>
  <li><a href="/paradigm-radar-erc8004-trust-infrastructure/">站内：AI 范式雷达《ERC-8004 与信任基础设施》</a></li>
  <li><a href="https://github.com/jhbruhn/respira">jhbruhn/respira 开源绣花协议库</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="ParadigmRadar" /><category term="local-first" /><category term="smart-home" /><category term="subscription" /><category term="local-ai" /><category term="open-source" /><category term="paradigm-radar" /><summary type="html"><![CDATA[HN 五天事件簇实测（截至 2026-11-15）：五个互不相识的主体同指云端加订阅，离线自主从抱怨变成有工具链的迁移，反方提醒本地化同样有成本门槛。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/offline-sovereignty-wave.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/offline-sovereignty-wave.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《智能体签发授权书热热闹闹，替双方验书的柜台还没开张》</title><link href="https://unbug.github.io/ai-innovation-brief-mandate-verification-gap/" rel="alternate" type="text/html" title="AI 智创简报：《智能体签发授权书热热闹闹，替双方验书的柜台还没开张》" /><published>2026-11-10T00:00:00+00:00</published><updated>2026-11-10T00:00:00+00:00</updated><id>https://unbug.github.io/ai-innovation-brief-mandate-verification-gap</id><content type="html" xml:base="https://unbug.github.io/ai-innovation-brief-mandate-verification-gap/"><![CDATA[<p><code class="language-plaintext highlighter-rouge">2026-11-10</code> Google Patents 精确检索：智能体协议、协商一侧热到 <code class="language-plaintext highlighter-rouge">2297</code>、<code class="language-plaintext highlighter-rouge">1745</code> 件，授权书校验一侧窄查询只有 <code class="language-plaintext highlighter-rouge">8</code>、<code class="language-plaintext highlighter-rouge">33</code> 件——签发端在圈地，替交易双方验授权书的中立校验位还是方向差。</p>

<p><img src="/assets/images/mandate-verification-gap.svg" alt="签发侧协议仓库高星 vs 校验侧个位数星占坑" /></p>

<h2 id="六件终选各有一句判词">六件终选，各有一句判词</h2>

<p>Citibank <code class="language-plaintext highlighter-rouge">US12526244B2</code> 加密智能体验证（<code class="language-plaintext highlighter-rouge">2026-01-13</code> 授权）claim 第一方智能体取得定义第二方操作边界的机器可读结构并哈希入库，判词：边界结构加加密核验都在，核验方却是交易对手第一方，不是中立第三方。Citibank <code class="language-plaintext highlighter-rouge">US12450494B1</code> 用生成式 AI 验证智能体（<code class="language-plaintext highlighter-rouge">2025-10-21</code> 授权），约束集进来、生成式验证器出去，判词：验证器是银行嵌在自家流程里的。Citibank <code class="language-plaintext highlighter-rouge">US12694133B1</code> 智能体监察（<code class="language-plaintext highlighter-rouge">2026-07-28</code> 授权），观测代理盯活动数据流，判词：企业域内管行为，不管授权书条款。Citibank <code class="language-plaintext highlighter-rouge">US12706859B1</code> 交叉验证加密执行（<code class="language-plaintext highlighter-rouge">2026-08-11</code> 授权），判词：与前件同族，圈的是执行侧。清华大学 <code class="language-plaintext highlighter-rouge">CN120915496B</code> 跨域互信多智能体协作（<code class="language-plaintext highlighter-rouge">2026-03-10</code> 授权），去中心化身份加分布式账本锚定交互信息卡，判词：占住互信理论位，做的是身份认证，不是条款级校验。个人发明人 TRAN, ALEX 的 <code class="language-plaintext highlighter-rouge">US11593685B1</code> 全渠道智能协商助手（<code class="language-plaintext highlighter-rouge">2023-02-28</code> 授权），判词：个人早在协商助手位落过子。</p>

<h2 id="检索面签发热核验冷的方向差">检索面：签发热、核验冷的方向差</h2>

<p>mandate（授权书，智能体替人办事时携带的机器可读授权凭证）的签发端人山人海：<code class="language-plaintext highlighter-rouge">"agent protocol"</code> <code class="language-plaintext highlighter-rouge">2297</code> 件、<code class="language-plaintext highlighter-rouge">"negotiation" "large language model"</code> <code class="language-plaintext highlighter-rouge">1745</code> 件、<code class="language-plaintext highlighter-rouge">"smart contract" "large language model"</code> <code class="language-plaintext highlighter-rouge">731</code> 件、<code class="language-plaintext highlighter-rouge">"protocol" "negotiation" "large language model"</code> <code class="language-plaintext highlighter-rouge">691</code> 件且 2025 后占 76%。核验端是另一番量级：<code class="language-plaintext highlighter-rouge">"verifiable credential" "autonomous agents"</code> 仅 <code class="language-plaintext highlighter-rouge">8</code> 件、<code class="language-plaintext highlighter-rouge">"mandate" "autonomous agents"</code> <code class="language-plaintext highlighter-rouge">33</code> 件、托管 <code class="language-plaintext highlighter-rouge">"escrow" "autonomous agents"</code> <code class="language-plaintext highlighter-rouge">51</code> 件、争议 <code class="language-plaintext highlighter-rouge">"dispute" "autonomous agents"</code> <code class="language-plaintext highlighter-rouge">89</code> 件、<code class="language-plaintext highlighter-rouge">"agent payments protocol"</code> 仅 <code class="language-plaintext highlighter-rouge">4</code> 件。核验端里 Citibank 一家在 <code class="language-plaintext highlighter-rouge">"verifiable credential" "autonomous agents"</code> 的 <code class="language-plaintext highlighter-rouge">8</code> 件里占 3 席，盘内逐条已核实，是银行圈地最硬的单一申请人证据。要交代的是：本轮没有任何真零查询，窄处也是个位到两位数，缺口是量级方向差而非空集。仓库侧同构：A2A（agent2agent 开放协议）主仓 <code class="language-plaintext highlighter-rouge">26467</code> 星、x402（HTTP 402 支付的开放协议）npm 近一月下载 <code class="language-plaintext highlighter-rouge">2400334</code>，mandate 一致性校验头名 Praman 却只有 <code class="language-plaintext highlighter-rouge">15</code> 星，Soham109/sutra <code class="language-plaintext highlighter-rouge">9</code> 星，iamonuwa/kanon <code class="language-plaintext highlighter-rouge">4</code> 星——x402 mandate 一致性测试向量加参考校验器，坑位正被一个 4 星仓库精确占住。internet-court-skill <code class="language-plaintext highlighter-rouge">7083</code> 星卖的却是自己当裁判，属另一类，不算校验位繁荣。</p>

<h2 id="反方六条逐条摆开">反方六条，逐条摆开</h2>

<p>需求侧同冷是本期最大口径差异：专利圈地、工具真空、讨论冷三者同向，HN 上 mandate 相关帖最高只有 <code class="language-plaintext highlighter-rouge">10</code> 分；窗口对单人开放与伪赛道两种读法并存，本期只写三者同向，不提需求热度。反方摆六条：其一，Citibank 四件已把第一方核验圈实，切割句要摆正：核验方是交易对手，不是中立方。其二，清华件占住跨域互信的理论位。其三，internet-court <code class="language-plaintext highlighter-rouge">7083</code> 星已占「裁判」位。其四，kanon <code class="language-plaintext highlighter-rouge">4</code> 星精确占了参考校验器，先发优势未必还在。其五，无真零，窄查询也是两位数。其六，需求冷本身就可能是伪赛道信号。上一篇<a href="/ai-innovation-brief-provenance-verification-gap/">内容溯源验真</a>管内容真假，10-30 那期写钱怎么被授权花，本期写授权书谁来替双方验。</p>

<h2 id="单人切口只验不签的校验器">单人切口：只验不签的校验器</h2>

<p>与 kanon 正面相遇的个人形态是 mandate 一致性校验 CLI/CI：对 AP2 mandate、x402 manifest、A2A extension 做字段级校验与越界告警，只验不签不建库。六件为何卡不住这个位：Citibank 四件的核验方都是交易对手第一方且绑加密执行或行为监察；清华件落在身份认证与账本；个人那件是协商助手本体——没有一件 claim「中立第三方对 mandate 做字段级一致性校验」。不建议自建仲裁：裁判位 <code class="language-plaintext highlighter-rouge">7083</code> 星已占，单人做不赢信任。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://patents.google.com/patent/US12526244B2/en">Citibank 加密智能体验证专利</a></li>
  <li><a href="https://patents.google.com/patent/US12450494B1/en">Citibank 生成式 AI 验证智能体专利</a></li>
  <li><a href="https://patents.google.com/patent/US12694133B1/en">Citibank 智能体监察专利</a></li>
  <li><a href="https://patents.google.com/patent/US12706859B1/en">Citibank 交叉验证加密执行专利</a></li>
  <li><a href="https://patents.google.com/patent/CN120915496B/en">清华大学跨域互信多智能体专利</a></li>
  <li><a href="https://patents.google.com/patent/US11593685B1/en">个人发明人全渠道智能协商助手专利</a></li>
  <li><a href="https://github.com/a2aproject/A2A">GitHub：a2aproject/A2A</a></li>
  <li><a href="https://github.com/internet-court/internet-court-skill">GitHub：internet-court/internet-court-skill</a></li>
  <li><a href="https://github.com/iamonuwa/kanon">GitHub：iamonuwa/kanon</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="agent-mandate" /><category term="agent-protocols" /><category term="patents" /><category term="x402" /><category term="solo-dev" /><summary type="html"><![CDATA[智能体协议与协商主题专利检索热到 2297 与 1745 件，授权书校验窄查询仅 8 与 33 件；签发侧头名仓库 26467 星、校验头名仅 15 星，中立验书位暂无权利要求卡住。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/mandate-verification-gap.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/mandate-verification-gap.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《跑十轮不如跑一轮》</title><link href="https://unbug.github.io/one-minute-read-paper-e-means-kmeans-successor/" rel="alternate" type="text/html" title="一分钟读论文：《跑十轮不如跑一轮》" /><published>2026-11-10T00:00:00+00:00</published><updated>2026-11-10T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-e-means-kmeans-successor</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-e-means-kmeans-successor/"><![CDATA[<p>Meta FAIR 的预印本论文<a href="https://arxiv.org/abs/2611.09501">《e-means: outperforming k-means》</a>把 k-means 的更新规则换成 mini-batch 加滑动平均，摘要口径做到 <code class="language-plaintext highlighter-rouge">10-45x</code> 的 GPU 端到端提速，代码已并入 faiss 主干。</p>

<p>k-means 要最小化每个点到其最近质心的平方距离和，聚类、压缩、检索索引、数据清洗都在用它；做向量检索和 RAG 的人几乎人手一份。滑动平均指对历史值平滑跟进的更新。论文另引他人工作补了一句：它近来也被用于大模型栈里压缩 attention cache、给注意力做稀疏化——这是既有用途，并非 e-means 的新功能，站内《KV cache serving 专利简报》<a href="/innovation-brief-kv-cache-serving-patents/">（站内阅读）</a>正是这一方向的延伸。</p>

<h2 id="换掉更新规则顺手消掉扫参">换掉更新规则，顺手消掉扫参</h2>

<p>e-means 的做法有三层：把 mini-batch 的滑动平均更新规则专门化到 k-means；学习率按 cosine 退火，并给中途失去分配点的死簇做复活处理；再对衰减率与 batch size 如何影响最终损失拟合 scaling law，直接给出公式，换数据集不用再扫超参。论文点出老方法的空白：此前没有任何方法告诉使用者给定问题该用多大 batch、多长步长，质心死了也没几个方法管。</p>

<p><img src="/assets/images/e-means-epochs-curve.svg" alt="跑满 25 个 epoch 才达到的 Lloyd 损失，e-means 用 1.4 到 2.6 个 epoch 就碰到" /></p>

<p>速度数字分两个口径。摘要口径：<code class="language-plaintext highlighter-rouge">1.4</code> 到 <code class="language-plaintext highlighter-rouge">2.6</code> 个 epoch 就追平 Lloyd 算法（k-means 的经典迭代法）跑满 <code class="language-plaintext highlighter-rouge">25</code> 个 epoch 的损失，折算 <code class="language-plaintext highlighter-rouge">10-45x</code> GPU 端到端提速，基线是 state-of-the-art 实现（正文指 Faiss-GPU 与 Flash-KMeans）。正文 <code class="language-plaintext highlighter-rouge">4.3</code> 节对 Flash-KMeans 逐档实测更精确：跨 <code class="language-plaintext highlighter-rouge">1M</code> 到 <code class="language-plaintext highlighter-rouge">1B</code> 规模、<code class="language-plaintext highlighter-rouge">10</code> 个 seed 取中位数，提速为 <code class="language-plaintext highlighter-rouge">9.5x</code> 到 <code class="language-plaintext highlighter-rouge">45.5x</code>，且收敛损失更低。结论口径则是 <code class="language-plaintext highlighter-rouge">1</code> 到 <code class="language-plaintext highlighter-rouge">3</code> 个 epoch 达到收敛的 Lloyd 质量，三组数字各管各的，不能互换。</p>

<p>最有画面感的是 DINO10B 演示：约 <code class="language-plaintext highlighter-rouge">10 billion</code>（一百亿）条 DINO 向量切进 <code class="language-plaintext highlighter-rouge">16 million</code>（一千六百万）个簇，只花 <code class="language-plaintext highlighter-rouge">2.5</code> 个 epoch，损失低于 Lloyd 跑 <code class="language-plaintext highlighter-rouge">25</code> 个 epoch 的水位——注意这个 <code class="language-plaintext highlighter-rouge">2.5</code> 只在这一个数据集上成立。</p>

<h2 id="进了-faiss-主干还没上货架">进了 faiss 主干，还没上货架</h2>

<p>代码住在 <code class="language-plaintext highlighter-rouge">facebookresearch/faiss</code> 的 <code class="language-plaintext highlighter-rouge">contrib/e_means</code> 目录；faiss 是 <code class="language-plaintext highlighter-rouge">41288</code> stars、<code class="language-plaintext highlighter-rouge">4588</code> forks 的 MIT 开源库，描述写着“高效稠密向量相似检索与聚类”。用一行 <code class="language-plaintext highlighter-rouge">from faiss.contrib.e_means import NumpyEmeans</code> 就能起步，GPU 路线提供 Triton、CuTe、PyTorch 三套后端，距离计算可转 BF16、FP8、INT8，数据能从 SSD 流式读入，簇超过约 <code class="language-plaintext highlighter-rouge">10^6</code> 个还能套 IVF 索引做近似分配再提速。</p>

<p>时间差也写在同一个仓里：代码 <code class="language-plaintext highlighter-rouge">2026-11-02</code> 就进了 faiss 主干，主 README 至今零提及 e-means，官网 <code class="language-plaintext highlighter-rouge">2026-11-05</code> 才建，第三方独立复现目前为零。作者是 Douze 与 Jégou——正是 faiss 与 product quantization 的本尊，可信度来自这里，但对比基线里的 faiss 也是作者自家库，这笔账得记着。</p>

<h2 id="刹车写在论文自己身上">刹车写在论文自己身上</h2>

<p>低维和小数据集是明确边界：论文的 scaling law 为较高维数据调参，<code class="language-plaintext highlighter-rouge">not optimal on very low-dimensional and tiny datasets</code>；<code class="language-plaintext highlighter-rouge">d ≤ 16</code> 默认改用 quality batch、<code class="language-plaintext highlighter-rouge">d ≤ 2</code> 还要关掉簇复活，相当于一组官方补丁。对手并不服气：Flash-KMeans 换用 k-means++ 初始化后，<code class="language-plaintext highlighter-rouge">8</code> 个配置的平均误差仍全部输给 e-means，但优势收窄到 <code class="language-plaintext highlighter-rouge">0.06%</code> 到 <code class="language-plaintext highlighter-rouge">0.33%</code>。论文自标 Preprint、正在同行评审；DINO10B 基准覆盖 <code class="language-plaintext highlighter-rouge">100k</code> 到 <code class="language-plaintext highlighter-rouge">10B</code> 规模档位，以 CC-by 4.0 许可、约 <code class="language-plaintext highlighter-rouge">10 TB</code> 分批发布，论文给了下载路径，目录直链暂不可列举。站内《循环语言模型的省算力账》<a href="/one-minute-read-paper-halting-head-compute-gap/">（站内阅读）</a>同样是换算力账的路子。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2611.09501">e-means: outperforming k-means (in one-tenth the epochs)</a></li>
  <li><a href="https://github.com/facebookresearch/faiss/tree/main/contrib/e_means">faiss contrib/e_means 代码目录</a></li>
  <li><a href="https://e-means.github.io/">e-means 官网</a></li>
  <li><a href="/one-minute-read-paper-halting-head-compute-gap/">站内：循环语言模型的省算力账</a></li>
  <li><a href="/innovation-brief-kv-cache-serving-patents/">站内：KV cache serving 专利简报</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="OneMinuteRead" /><category term="clustering" /><category term="k-means" /><category term="vector-search" /><category term="faiss" /><summary type="html"><![CDATA[Meta FAIR 预印本把 k-means 的更新规则换成小批量加滑动平均：GPU 端到端提速 10 到 45 倍，100 亿向量分 1600 万簇只用 2.5 个训练轮次，代码已并入 faiss 主干，成为大规模聚类新选项。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/e-means-epochs-curve.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/e-means-epochs-curve.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《贴水印成了行业，拆水印成了生意，验水印还是个爱好》</title><link href="https://unbug.github.io/ai-innovation-brief-provenance-verification-gap/" rel="alternate" type="text/html" title="AI 智创简报：《贴水印成了行业，拆水印成了生意，验水印还是个爱好》" /><published>2026-11-09T00:00:00+00:00</published><updated>2026-11-09T00:00:00+00:00</updated><id>https://unbug.github.io/ai-innovation-brief-provenance-verification-gap</id><content type="html" xml:base="https://unbug.github.io/ai-innovation-brief-provenance-verification-gap/"><![CDATA[<p><code class="language-plaintext highlighter-rouge">2026-11-09</code> 同日 Google Patents 精确检索：水印嵌入 <code class="language-plaintext highlighter-rouge">1062</code> 件、对抗攻击 <code class="language-plaintext highlighter-rouge">1944</code> 件，第三方检测仅 <code class="language-plaintext highlighter-rouge">11</code> 件，凭证校验的双查询两次真零。</p>

<p><img src="/assets/images/provenance-verification-gap.svg" alt="水印嵌入与对抗攻击的专利圈地 vs 第三方验真的空位" /></p>

<h2 id="六件专利没有一件替第三方验凭证">六件专利，没有一件替第三方验凭证</h2>

<p>当日逐字复核的六件详情页各有落点。微软（Microsoft Technology Licensing LLC）<code class="language-plaintext highlighter-rouge">US20250298500A1</code> 溯源内容追踪（<code class="language-plaintext highlighter-rouge">2025-09-25</code> 公开）claim 编辑系统里对模型生成段落挂溯源元数据并给可视化标识，判词：闭环在自家编辑器的显示层里。微软 <code class="language-plaintext highlighter-rouge">US20250356057A1</code> 生成模型内容检测（<code class="language-plaintext highlighter-rouge">2025-11-20</code> 公开）claim 篡改帧验证第一签名后补签第二签名，判词：盖章方自己补签，仍是签发端。个人申请人 Michael Boucher 的 <code class="language-plaintext highlighter-rouge">US20250322156A1</code> AI 文本识别（<code class="language-plaintext highlighter-rouge">2025-10-16</code> 公开，sole inventor）claim 监听剪切板事件抓文本比对 AI 文本库，判词：一个人已在动手，但落点是剪贴板检测，不是凭证校验。公安部第三研究所 <code class="language-plaintext highlighter-rouge">CN122196982A</code> claim 多维向量投影加锦标赛采样的文本水印，合肥工业大学 <code class="language-plaintext highlighter-rouge">CN122433060A</code> claim 采样与优选输出的黑盒水印及检测，判词：两件都在学术嵌入端。</p>

<h2 id="验真位的检索面窄处真零">验真位的检索面：窄处真零</h2>

<p>AI 内容溯源（content provenance，指标明内容来自哪个模型、经谁编辑的凭证链条）的检索面窄得多：”content provenance” “machine learning” 仅 <code class="language-plaintext highlighter-rouge">75</code> 件，”SynthID” “watermark” 仅 <code class="language-plaintext highlighter-rouge">6</code> 件，第三方检测 <code class="language-plaintext highlighter-rouge">11</code> 件。再往精确处查，”provenance graph” “watermark removal” “third-party verifier” 与去掉尾项的重查两次都返回 <code class="language-plaintext highlighter-rouge">0</code>，HTTP 均 <code class="language-plaintext highlighter-rouge">200</code>、返回体为合法 JSON、total_num_results 为零——空位不是检索通道故障。仓库侧同温：GitHub 上去水印工具 wiltodelta/remove-ai-watermarks 头名 <code class="language-plaintext highlighter-rouge">6321</code> 星，aloshdenny/reverse-SynthID <code class="language-plaintext highlighter-rouge">5058</code> 星；唯一自称第三方水印取证的 karthikrshet/ClaudeMark 只有 <code class="language-plaintext highlighter-rouge">10</code> 星。</p>

<h2 id="六条反方逐条摆开">六条反方，逐条摆开</h2>

<p>诚实呈现要有六条。其一，Qomplx Inc 的 <code class="language-plaintext highlighter-rouge">US12602572B2</code> 已授权（<code class="language-plaintext highlighter-rouge">2026-04-14</code>，优先权 <code class="language-plaintext highlighter-rouge">2023-12-23</code>），claim 把外部内容分块哈希后与自家注册内容元素数据库比对判 AI/非 AI——它验的是指纹库，不是签名凭证；本期只把它当内容验真订阅服务看。其二，ClaudeMark 虽仅 <code class="language-plaintext highlighter-rouge">10</code> 星，第三方水印取证这个坑位已被占。其三，微软两件圈住签发与显示端，外部校验器的边缘空间受挤压。其四，”watermark” “verify” “provenance” 命中 <code class="language-plaintext highlighter-rouge">362</code> 件，不是零；多数是签发链路带上 verify 字样，精确到第三方验证才见空位。其五，<code class="language-plaintext highlighter-rouge">1944</code> 件对抗攻击的头部申请人是中国高校与 Digimarc，攻防两头都有正经机构。其六，<code class="language-plaintext highlighter-rouge">6321</code> 星只证明拆标需求热度，推不出灰色产业规模。</p>

<h2 id="单人切口不建库的凭证校验器">单人切口：不建库的凭证校验器</h2>

<p>空位对应一个个人可交付物：C2PA（业内内容凭证标准，把生成模型、编辑记录签进文件）与水印凭证的独立校验 CLI/CI 检查器——凭证可验、链可查、不建内容库。前文六件里，微软两件在签发显示端，Qomplx 的 claim 依赖自家注册哈希库，个人那件落在剪贴板比对；只验凭证、不碰库、不生成内容的形态暂无权利要求卡住。上一篇<a href="/ai-innovation-brief-tool-failure-semantics/">工具调用空结果语义</a>管的是调用返回没人分箱，这一篇管的是内容本身没人验真。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://patents.google.com/patent/US20250298500A1/en">微软溯源内容追踪专利</a></li>
  <li><a href="https://patents.google.com/patent/US20250356057A1/en">微软生成模型内容检测专利</a></li>
  <li><a href="https://patents.google.com/patent/US20250322156A1/en">个人申请人 AI 文本识别专利</a></li>
  <li><a href="https://patents.google.com/patent/CN122196982A/en">公安部三所 LLM 文本水印专利</a></li>
  <li><a href="https://patents.google.com/patent/CN122433060A/en">合肥工业大学黑盒大模型水印专利</a></li>
  <li><a href="https://patents.google.com/patent/US12602572B2/en">Qomplx 内容识别与验真专利</a></li>
  <li><a href="https://github.com/wiltodelta/remove-ai-watermarks">GitHub：remove-ai-watermarks</a></li>
  <li><a href="https://github.com/aloshdenny/reverse-SynthID">GitHub：reverse-SynthID</a></li>
  <li><a href="https://github.com/karthikrshet/ClaudeMark">GitHub：ClaudeMark</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="ai-content-provenance" /><category term="watermarking" /><category term="patents" /><category term="c2pa" /><category term="solo-dev" /><summary type="html"><![CDATA[Google Patents 实测：AI 内容水印嵌入专利 1062 件、对抗攻击 1944 件，第三方检测仅 11 件，凭证校验双查询真零；不建库、只验签的独立校验器尚无权利要求卡住。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/provenance-verification-gap.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/provenance-verification-gap.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《代码会写，接着写不会》</title><link href="https://unbug.github.io/one-minute-read-paper-multi-step-swe-long-horizon/" rel="alternate" type="text/html" title="一分钟读论文：《代码会写，接着写不会》" /><published>2026-11-09T00:00:00+00:00</published><updated>2026-11-09T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-multi-step-swe-long-horizon</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-multi-step-swe-long-horizon/"><![CDATA[<p>Klavis AI（产品公司）的论文<a href="https://arxiv.org/abs/2611.07166">《Multi-step SWE》</a>把「编程智能体能否在自己的代码上接着写」做成可测基准：<code class="language-plaintext highlighter-rouge">69</code> 个任务、共 <code class="language-plaintext highlighter-rouge">574</code> 步相互依赖的连续改动，每任务 <code class="language-plaintext highlighter-rouge">5</code>–<code class="language-plaintext highlighter-rouge">15</code> 步，最强的 Claude Opus 5.5 整任务解决率只有 <code class="language-plaintext highlighter-rouge">18.5%</code>。</p>

<p>这里的「整任务解决率」有严格口径：一条 rollout 必须在任务的每一步都拿满分才算解决；<code class="language-plaintext highlighter-rouge">Pass@4</code> 则是同一任务跑 <code class="language-plaintext highlighter-rouge">4</code> 条 rollout，至少有一条解出整任务的比例。<code class="language-plaintext highlighter-rouge">3</code> 位作者全部来自 Klavis AI，无学术机构混合署名；评测框架 Harbor 由其关联方维护，开源基准仓 <code class="language-plaintext highlighter-rouge">2026-11-04</code> 建立、<code class="language-plaintext highlighter-rouge">stars</code> 仅 <code class="language-plaintext highlighter-rouge">2</code>，社区独立复现目前为零，<code class="language-plaintext highlighter-rouge">18.5%</code> 暂时是单一机构数据。</p>

<h2 id="单步看着都对整链几乎必断">单步看着都对，整链几乎必断</h2>

<p>Claude Opus 5.5 的<code class="language-plaintext highlighter-rouge">单步通过率</code>为 <code class="language-plaintext highlighter-rouge">56.8%</code>，<code class="language-plaintext highlighter-rouge">整任务解决率</code>只有 <code class="language-plaintext highlighter-rouge">18.5%</code>，两者差着 <code class="language-plaintext highlighter-rouge">38.3</code> 个百分点。<code class="language-plaintext highlighter-rouge">Pass@4</code> 多试 <code class="language-plaintext highlighter-rouge">4</code> 次也只到 <code class="language-plaintext highlighter-rouge">31.9%</code>。其余 <code class="language-plaintext highlighter-rouge">8</code> 款模型整任务解决率都不超过 <code class="language-plaintext highlighter-rouge">17.8%</code>：Claude Fable 5.1 为 <code class="language-plaintext highlighter-rouge">17.8%</code>，Gemini 4 Argon 与 GPT-6.1 Sol 同为 <code class="language-plaintext highlighter-rouge">10.1%</code>，GPT-6 Astra 为 <code class="language-plaintext highlighter-rouge">6.9%</code>，DeepSeek V4.1 Flash 为 <code class="language-plaintext highlighter-rouge">6.5%</code>，Qwen 3.8 Max 为 <code class="language-plaintext highlighter-rouge">4.0%</code>，MiMo 2.6 Pro 为 <code class="language-plaintext highlighter-rouge">2.9%</code>，Grok 4.7 只有 <code class="language-plaintext highlighter-rouge">1.4%</code>。</p>

<p>版本升级类任务是重灾区：智能体先把系统搭起来，再一个版本一个版本地改行为，<code class="language-plaintext highlighter-rouge">20</code> 道题里没有一款模型解决率超过 <code class="language-plaintext highlighter-rouge">8.8%</code>，其中 <code class="language-plaintext highlighter-rouge">16</code> 道题无人能解。</p>

<h2 id="错误从第一步就开始复利">错误从第一步就开始复利</h2>

<p>论文追踪「仍在正轨」的比例：截至当前步，每一步都通过的 rollout 占比。把任务按步数切成五段，Claude Opus 5.5 从第一段的 <code class="language-plaintext highlighter-rouge">54.7%</code> 跌到最后一段的 <code class="language-plaintext highlighter-rouge">19.2%</code>；Grok 4.7 从 <code class="language-plaintext highlighter-rouge">13.1%</code> 跌到 <code class="language-plaintext highlighter-rouge">1.4%</code>。<code class="language-plaintext highlighter-rouge">9</code> 款模型的最陡跌幅都出现在第一段到第二段之间，全模型均值从 <code class="language-plaintext highlighter-rouge">34.9%</code> 掉到 <code class="language-plaintext highlighter-rouge">9.0%</code>。与之对照，单步通过率下降得平缓得多，从 <code class="language-plaintext highlighter-rouge">40.7%</code> 到 <code class="language-plaintext highlighter-rouge">27.8%</code>——每一步单独看错误率变化不大，一旦后面每一步都建立在前一步留下的代码上，早期设计失误就会一路滚雪球。</p>

<p><img src="/assets/images/multi-step-swe-long-horizon.svg" alt="仍在正轨比例随任务推进的复利式衰减" /></p>

<h2 id="失败多半不是算力不够">失败多半不是算力不够</h2>

<p>这一点比 <code class="language-plaintext highlighter-rouge">18.5%</code> 更有解释力。基准给每一步 <code class="language-plaintext highlighter-rouge">2</code>–<code class="language-plaintext highlighter-rouge">4</code> 小时、每任务 <code class="language-plaintext highlighter-rouge">10</code>–<code class="language-plaintext highlighter-rouge">60</code> 小时预算（<code class="language-plaintext highlighter-rouge">471</code> 步给 <code class="language-plaintext highlighter-rouge">2</code> 小时，<code class="language-plaintext highlighter-rouge">56</code> 步给 <code class="language-plaintext highlighter-rouge">3</code> 小时，<code class="language-plaintext highlighter-rouge">47</code> 步给 <code class="language-plaintext highlighter-rouge">4</code> 小时）。实测中只有 <code class="language-plaintext highlighter-rouge">12%</code> 的失败步骤跑到距离时限 <code class="language-plaintext highlighter-rouge">5</code> 分钟以内；<code class="language-plaintext highlighter-rouge">6</code> 款模型的中位失败步骤只用掉 <code class="language-plaintext highlighter-rouge">24%</code>–<code class="language-plaintext highlighter-rouge">37%</code> 预算，还剩 <code class="language-plaintext highlighter-rouge">77</code>–<code class="language-plaintext highlighter-rouge">93</code> 分钟没用。只有 <code class="language-plaintext highlighter-rouge">3%</code> 的失败以时间预算为停止理由，<code class="language-plaintext highlighter-rouge">19%</code> 结束时连最终报告都没交。多数失败是方向走错，而不是时间或算力不足。需要说明的是，每步 <code class="language-plaintext highlighter-rouge">2</code>–<code class="language-plaintext highlighter-rouge">4</code> 小时是基准的设计预算，不是模型真实部署成本。</p>

<h2 id="局限误杀的裁判与偏底层的题">局限：误杀的裁判与偏底层的题</h2>

<p>论文自认：尽管经过专家评审并对齐既有事实来源，仍有些任务含有含糊需求，或存在漏判、误杀正确行为的 verifier（自动验证器）。另一个未解之处是能力与脚手架没有分离——把每一步单独执行的 isolated-step 基线被留作 future work，因此 <code class="language-plaintext highlighter-rouge">18.5%</code> 里有多少归因于模型能力、多少归因于任务串联难度，本文无法回答。任务分布也偏向系统底层：<code class="language-plaintext highlighter-rouge">69</code> 题里 C/C++ 占 <code class="language-plaintext highlighter-rouge">38</code> 题，Rust <code class="language-plaintext highlighter-rouge">11</code> 题，Java <code class="language-plaintext highlighter-rouge">6</code> 题，Go、JavaScript 各 <code class="language-plaintext highlighter-rouge">4</code> 题，Python <code class="language-plaintext highlighter-rouge">3</code> 题，PHP <code class="language-plaintext highlighter-rouge">2</code> 题，Ruby <code class="language-plaintext highlighter-rouge">1</code> 题；结论外推到普通业务代码库需要谨慎。起点上 <code class="language-plaintext highlighter-rouge">34</code> 题从空目录或骨架开始、<code class="language-plaintext highlighter-rouge">35</code> 题基于已有开源代码库。因此 <code class="language-plaintext highlighter-rouge">18.5%</code> 是这套任务分布下的结果，不宜当成通用编程能力得分。</p>

<p>与站内<a href="/one-minute-read-paper-agent-pprof-semantic-stack/">《像查性能热点一样查智能体的开销》</a>不同：那篇对已跑完的轨迹做开销归因，这篇测的是编码任务跨步累积的错误，两者不在同一轴上。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2611.07166">Multi-step SWE: Can Coding Agents Keep Building on Their Own Code Over Long Horizons?</a></li>
  <li><a href="https://github.com/Klavis-AI/Multi-step-SWE">Multi-step SWE 开源基准仓库</a></li>
  <li><a href="https://multistepswe.com">Multi-step SWE 项目站与 leaderboard</a></li>
  <li><a href="https://github.com/harbor-framework/harbor">Harbor 评测框架</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="OneMinuteRead" /><category term="ai-agents" /><category term="coding-agent" /><category term="benchmark" /><category term="long-horizon" /><summary type="html"><![CDATA[Klavis AI 自建 69 个任务、574 步相互依赖的长程软件工程基准：最强的 Claude Opus 5.5 整任务解决率也只有 18.5%，单步通过率却有 56.8%，版本升级类任务没有模型超过 8.8%。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/multi-step-swe-long-horizon.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/multi-step-swe-long-horizon.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 范式雷达：《执行壳：有人往外搬，有人往里收》</title><link href="https://unbug.github.io/paradigm-radar-harness-exodus-recall/" rel="alternate" type="text/html" title="AI 范式雷达：《执行壳：有人往外搬，有人往里收》" /><published>2026-11-09T00:00:00+00:00</published><updated>2026-11-09T00:00:00+00:00</updated><id>https://unbug.github.io/paradigm-radar-harness-exodus-recall</id><content type="html" xml:base="https://unbug.github.io/paradigm-radar-harness-exodus-recall/"><![CDATA[<p><code class="language-plaintext highlighter-rouge">2026-11-09</code> 的 Hacker News 首页挂出两件方向相反的事：《Goodbye Claude, hello Pi》<code class="language-plaintext highlighter-rouge">702</code> 分 / <code class="language-plaintext highlighter-rouge">433</code> 条，高盛收权帖 <code class="language-plaintext highlighter-rouge">604</code> 分 / <code class="language-plaintext highlighter-rouge">351</code> 条（首采分数/条数，<code class="language-plaintext highlighter-rouge">11-16</code> 复测 <code class="language-plaintext highlighter-rouge">831</code>、<code class="language-plaintext highlighter-rouge">905</code>）——搬家与收权抢的是同一样东西：对壳的选择权。</p>

<p>口径先钉死：首采为 <code class="language-plaintext highlighter-rouge">2026-11-09</code> 上午的 Algolia 全树实测与 GitHub API 实测；本文 <code class="language-plaintext highlighter-rouge">2026-11-16</code> 对两帖、pi 仓库与涉事评论做了全量复测，两次数值分列不混用；评论区引语为原文摘译并附可定位评论编号；自述、转述、报道级信源分级标注。</p>

<p><img src="/assets/images/paradigm-radar-harness-exodus-recall.svg" alt="个人带订阅离巢与甲方收回执行壳的对冲对照" /></p>

<p><img src="/assets/images/paradigm-radar-harness-exodus-recheck.svg" alt="七天复测对照：Pi 帖 702 到 831、高盛帖 604 到 905 涨幅反超、评论两树齐涨、pi 仓库七天多出 1,269 星；底注指出收权才是未决争议面" /></p>

<h2 id="带着订阅搬走的四百多条评论">带着订阅搬走的四百多条评论</h2>

<p>「执行壳」（harness）指套在大模型外面、替人执行命令与改写文件的那层工具，Claude Code、Pi、OpenCode 都算这一类。模型可以不变，壳可以换。主锚帖 <code class="language-plaintext highlighter-rouge">50410107</code> 在 <code class="language-plaintext highlighter-rouge">11-08</code> 03:11Z 登上首页，<code class="language-plaintext highlighter-rouge">11-09</code> 09:45（Asia/Shanghai）实测为 <code class="language-plaintext highlighter-rouge">702</code> 分 / <code class="language-plaintext highlighter-rouge">433</code> 条，<code class="language-plaintext highlighter-rouge">09:5x</code> 的终采为 <code class="language-plaintext highlighter-rouge">702</code> 分 / <code class="language-plaintext highlighter-rouge">432</code> 条；昨日 <code class="language-plaintext highlighter-rouge">18:4x</code> 终测还只有 <code class="language-plaintext highlighter-rouge">320</code> 分与 <code class="language-plaintext highlighter-rouge">192</code> 条评论。<code class="language-plaintext highlighter-rouge">2026-11-16</code> 复测升至 <code class="language-plaintext highlighter-rouge">831</code> 分 / <code class="language-plaintext highlighter-rouge">491</code> 条——发酵没有停，只是从冲高变成了匀速。</p>

<p>主锚线程的叙事骨架是一批迁移自述，逐条可定位：<code class="language-plaintext highlighter-rouge">50419687</code>（indemnity）自述从 Claude Code 换到 Pi 的分支 OMP 之后精神状态变好；<code class="language-plaintext highlighter-rouge">50419852</code>（alexfortin）自述走过 Claude Code 与 OpenCode，最终停在 Pi，并对闭源模型失去兴趣；<code class="language-plaintext highlighter-rouge">50413684</code>（srid）自述经 agent-distro 换到 Oh My Pi 这个壳；<code class="language-plaintext highlighter-rouge">50412579</code>（gregwebs）自述本年大部分时间用 Pi，并且正考虑再转投他家。口径先写死：以上全为评论区自述的人工遍历，不是统计样本，只能证明搬家动作真实存在，而且当事人愿意在评论区署名。</p>

<p>留下派给出的不是情怀是控制力。gvkhna（评论 <code class="language-plaintext highlighter-rouge">50410985</code>，子树 <code class="language-plaintext highlighter-rouge">27</code> 条）的原话是「Pi 毫无疑问是最好的壳，因为它是你的」，并把体验变化命名为从「驾驶 agent」到「编排 agent」；tonfreed（<code class="language-plaintext highlighter-rouge">50410994</code>）附议：从「Claude Code 整天跟我作对、内部全黑盒」换到「每个 agent 时间花在哪都有细粒度遥测，整套壳完全自定义」。反方同样在场：regexorcist（<code class="language-plaintext highlighter-rouge">50411263</code>）回怼「这事任何壳都能做」，并亮出自己那套 Go 系壳的门户之见。更长的子树（bottlepalm，<code class="language-plaintext highlighter-rouge">50410853</code>，<code class="language-plaintext highlighter-rouge">179</code> 条）说的其实是第三种搬家——出壳：他自述用量爆炸后从终端壳退回桌面 GUI，把 VS Code 降级成 code review 与 git 工具；同楼层 nsingh2（<code class="language-plaintext highlighter-rouge">50410871</code>）自述干脆自制 GUI（起了 <code class="language-plaintext highlighter-rouge">3</code>-<code class="language-plaintext highlighter-rouge">4</code> 天慢慢长成自己的工作方式），vinhnx（<code class="language-plaintext highlighter-rouge">50410983</code>）则用 Rust 自研编码代理 VT Code，点名要管的正是工具执行、沙箱、审批与上下文管理。「换壳」与「造壳」在同一条线程里无缝衔接——这是壳时代才有的谱系。</p>

<p>双栈生活的样本也在线程里：jeena（<code class="language-plaintext highlighter-rouge">50411005</code>，子树 <code class="language-plaintext highlighter-rouge">19</code> 条）自述公司付 <code class="language-plaintext highlighter-rouge">200</code> 美元订阅所以工作用 Claude、家里 Pi 配 GLM 与 DeepSeek 的 flash 档模型，「工作里真的不喜欢 Claude，只是因为 Anthropic 不允许别的壳挂它的订阅」；someothherguyy（<code class="language-plaintext highlighter-rouge">50411012</code>）当场纠正：条款限制的是订阅挂第三方壳，API 不受限。这句纠正是理解整场搬家的钥匙：钱不是障碍，订阅与壳的绑定才是。</p>

<p>开源壳这一侧的供给同步刷新（首采为 <code class="language-plaintext highlighter-rouge">11-09</code> 上午 GitHub API 实测，括注 <code class="language-plaintext highlighter-rouge">11-16</code> 复测）：<code class="language-plaintext highlighter-rouge">earendil-works/pi</code> 仓库 <code class="language-plaintext highlighter-rouge">120,865</code> 星（复测 <code class="language-plaintext highlighter-rouge">122,134</code>，七天 <code class="language-plaintext highlighter-rouge">+1,269</code>，<code class="language-plaintext highlighter-rouge">11-15</code> 仍有提交），一夜再涨 <code class="language-plaintext highlighter-rouge">153</code> 颗只是七天斜率的一个采样点；观察窗内新建的 pi 扩展仓库由 <code class="language-plaintext highlighter-rouge">431</code> 个增至 <code class="language-plaintext highlighter-rouge">436</code> 个。桥接件也在长大：sigttou（评论 <code class="language-plaintext highlighter-rouge">50410645</code>）指路 <code class="language-plaintext highlighter-rouge">pi-claude-code</code>「目前仍是把 Anthropic 订阅挂进 Pi 的那条路」，同一楼层里 Codex 挂 Pi 的提问得到的回答是可以即插即用（评论区自报）。站内 <a href="/paradigm-radar-agent-hidden-cost/">《标价之外，Harness 替你买了什么》</a>核算的是壳的价格，本期记录的是搬家朝向哪里。</p>

<p>搬家人群的另一半动因是账单。leobuskin（评论 <code class="language-plaintext highlighter-rouge">50410950</code>，子树 <code class="language-plaintext highlighter-rouge">49</code> 条）把「别拿订阅在第三方壳上跑 Anthropic 模型」的理由列了四条：违反 ToS 可能被封号；第三方壳不跟进 Anthropic 的私有头、隐藏开关与未记录 API 特性，而这些会直接影响模型行为；缓存机制微妙，连官方壳自己都常写错缓存；扩展生态各写各的。这一楼层把「搬家」从偏好问题变成了工程问题——壳之间差的不只是手感，还有与上游私有协议的适配税。</p>

<h2 id="评论区自己长出来的质检单">评论区自己长出来的质检单</h2>

<p>这批线程最值得存档的，是用户侧先写出了「选壳质检单」，且每一条都挂在评论编号上。安全模式一格：giladd（<code class="language-plaintext highlighter-rouge">50410830</code>，子树 <code class="language-plaintext highlighter-rouge">15</code> 条）问 Pi 有没有挡危险动作的 auto 模式，作者承认当时没有、也没有第三方审查——他自述为此退回 Claude Code。上下文压缩一格：alfiedotwtf（<code class="language-plaintext highlighter-rouge">50410706</code>，子树 <code class="language-plaintext highlighter-rouge">14</code> 条）抱怨长会话「compaction 有一半时候失败」，julianlam 在楼下报自家 pi-vcc 插件补位。透明度一格：siraben（<code class="language-plaintext highlighter-rouge">50410725</code>）自研扩展把每条 bash 改写成纯英文意图再执行，顺手点名「有的壳把这类信息藏着干，不负责任」。评测一格：komali2（<code class="language-plaintext highlighter-rouge">50410485</code>）自报 nightly 跑分里 OpenCode 在本地小模型上反超 oh-my-pi，并吐槽小模型跑编排的决策疲劳；bdemirkir（<code class="language-plaintext highlighter-rouge">50410537</code>）提醒系统提示词尺寸差异会让「小模型在某壳里更笨」的结论失真。可编程性一格反而是最没争议的一格：sausagefeet（<code class="language-plaintext highlighter-rouge">50411096</code>）「Pi 之所以是 Pi 就在于扩展，自己写很容易」。</p>

<p><img src="/assets/images/paradigm-radar-harness-exodus-checklist.svg" alt="六格质检单图：订阅兼容性、护栏模式、上下文压缩、可编程性、透明度、账单形态，每格标注评论编号与出处；底注强调六格无一来自厂商文档" /></p>

<h2 id="高盛那一侧把壳收回到工程师手里">高盛那一侧：把壳收回到工程师手里</h2>

<p><code class="language-plaintext highlighter-rouge">50415628</code>（<code class="language-plaintext highlighter-rouge">11-09</code> 上午 10:0x 实测 <code class="language-plaintext highlighter-rouge">604</code> 分 / <code class="language-plaintext highlighter-rouge">351</code> 条，<code class="language-plaintext highlighter-rouge">2026-11-16</code> 复测 <code class="language-plaintext highlighter-rouge">905</code> 分 / <code class="language-plaintext highlighter-rouge">474</code> 条，涨幅反超首帖）报道高盛把 Claude Code 与 GitHub 的使用范围收缩到「仅工程师」，交易员与银行员被切断，strats 这类量化岗仍保留着访问权限，内部指引于 <code class="language-plaintext highlighter-rouge">10</code> 月更新。这不是把模型搬回自家机房：高盛保留的仍是 Anthropic 云端的 Claude Code，改变的只是谁有资格握着这个壳，推理位置从头到尾都没有动。高盛发言人 Nick Carcaterra 的话属公司自述：评估过生产力与风险管理等因素后，把工具交给「最适合长期运用它们的人」这一群体。信源层级写死：可核的是 Bloomberg 报道（fa-mag 转载全文可查），HN 实际链接的 the-stateofai 被评论 <code class="language-plaintext highlighter-rouge">50415815</code> 指为 AI 生成站转述链，不当原始报道使用。</p>

<p>报道里另一句关键表述：「在高盛把 Anthropic 带上市的前几周」。高盛同时是 Anthropic IPO 的主承销商，这是利益绑定而非决裂，「甲方抛弃供应商」的说法不被证据支持；评论 <code class="language-plaintext highlighter-rouge">50415930</code>（sourdecor）提出的替代解释（是否关乎承销商信息墙）与这句互相咬合，只能并列呈现，动机不替任何一方写死。</p>

<p>线程对「为什么」给出的最热答案既不是合规也不是股价。lukebuehler（评论 <code class="language-plaintext highlighter-rouge">50416595</code>，子树 <code class="language-plaintext highlighter-rouge">161</code> 条）认为报道没有点破的真正理由是「致命三角」：半无人值守的编码代理，跑在能接触客户、交易与内幕信息的工位机上，机器上还挂着邮件客户端——三样同机共存本身就越线，与模型聪明与否无关。enahs-sf（<code class="language-plaintext highlighter-rouge">50416643</code>）在楼下的追问更实际：谁来给这种场景做规模化权限治理？他自报「同类问题在我们公司也一样大」。账单线由 legitster（<code class="language-plaintext highlighter-rouge">50416136</code>，子树 <code class="language-plaintext highlighter-rouge">83</code> 条）提供：自述所在组织正因长期超支回收 Claude 权限，「Anthropic 给不出归一化费率的合同形态」，Gemini 靠固定账单加限流承接非工程岗（自述，未经独立核验）。时机线由 cactca（<code class="language-plaintext highlighter-rouge">50416089</code>）立起、pdpi（<code class="language-plaintext highlighter-rouge">50416143</code>）平衡：「健全组织里这是两个互不汇报的部门做的决定，我们默认往利益输送想，反而可悲」。</p>

<p><img src="/assets/images/paradigm-radar-harness-exodus-goldman-grid.svg" alt="高盛权限矩阵与三条解释线：工程师/strats 保留、交易员/银行员切断，下方三条解释线（致命三角、账单回收、IPO 时机）各标子树热度与评论编号，底注 Barclays 反例" /></p>

<p>「非工程岗该不该拿着壳」吵成了第二战场。doctoboggan（评论 <code class="language-plaintext highlighter-rouge">50415978</code>，子树 <code class="language-plaintext highlighter-rouge">24</code> 条）自述给当医生的太太装了 Claude Code 处理编码周边的杂务，rkuodys（<code class="language-plaintext highlighter-rouge">50416003</code>）立刻警告这类用法一不留神就跨过 HIPAA 线，rckoepke（<code class="language-plaintext highlighter-rouge">50416137</code>）再补一句两家都有 HIPAA 合规的企业协议可用。Ericson2314（<code class="language-plaintext highlighter-rouge">50415824</code>）站在收回令的反面：他对「非技术用户写 slop」的同情远多于对工程师的——真正该做的是把权限与环境设计好，而不是把编程环境收回去；CharlieDigital（<code class="language-plaintext highlighter-rouge">50415820</code>）则朝另一个方向补刀：要求代理写的代码必须由会读代码的人产出是对的，「讽刺的是开发者自己也在失去读代码的能力」。岗位侧的焊点仍来自 <code class="language-plaintext highlighter-rouge">50412499</code>（surgical_fire）：「Pi 很棒，可惜岗位上强制用 Claude Code，体验很挫」——个人往外搬，岗位往里收，收与搬的是同一样东西。这与站内 <a href="/paradigm-radar-toolchain-poisoning/">《官方渠道沦陷之后》</a>讲的分发渠道投毒无关，本文不展开安全事件细节，相邻的 <code class="language-plaintext highlighter-rouge">50407882</code>（<code class="language-plaintext highlighter-rouge">586</code> 分 / <code class="language-plaintext highlighter-rouge">387</code> 条）只当作迁移燃料记上一句。本期与 <code class="language-plaintext highlighter-rouge">2026-09-05</code>《外壳走上台前》的分工也写清楚：那期比较壳与壳之间的选型，本期记录人的搬家与岗位的收回，跑分不入文。</p>

<h2 id="反方六脚刹车">反方：六脚刹车</h2>

<p>第一脚踩在动因上，用来拆掉「银行业集体动手」这个暗示。评论 <code class="language-plaintext highlighter-rouge">50415825</code>（amelius）指出 Barclays 正朝反方向移动（自述年底前半数工程师用 Claude Code）；<code class="language-plaintext highlighter-rouge">50417888</code> 则补充说，原文并未写 Barclays 允许交易员使用，只写了开发者一侧——「银行业集体撤壳」不成立，这只是单家银行的内部规约，不是行业共识。</p>

<p>第二脚踩在信源上，即 the-stateofai 转述链的可信度问题，上一节已经交代。第三脚踩在企业侧：评论 <code class="language-plaintext highlighter-rouge">50416519</code> 自述，企业界担心托管的开源模型被暗中注入缺陷，且自托管成本不划算——离巢浪进不了企业大门。</p>

<p>后三脚来自主锚线程，<code class="language-plaintext highlighter-rouge">2026-11-16</code> 全树复扫未见推翻：<code class="language-plaintext highlighter-rouge">50411310</code>（jpardoe）自述切换之后被迫回流，因为订阅比按 API 计费更划算；<code class="language-plaintext highlighter-rouge">50411155</code>（commandersaki）指出 Anthropic 不允许 Pi 挂载 Pro/Max 订阅套餐，「带着订阅出走」这件事在服务条款层面受阻，leobuskin 的四条理由（<code class="language-plaintext highlighter-rouge">50410950</code>）可作此脚的工程注脚；<code class="language-plaintext highlighter-rouge">50411772</code>（0xbadcafebee）列举 OpenCode 的支持面短板，说明搬家目的地之间同样存在代差。六条反方并排之后，能站住的结论只剩下：壳的持有资格开始被分级，个人与甲方各自算账，方向恰好相反，谁也别说谁。据我们观察未发现同类中文报道。</p>

<h2 id="两帖七天之后">两帖七天之后</h2>

<p>复测数据把两个方向的相对热度改写了：搬家帖涨 <code class="language-plaintext highlighter-rouge">129</code> 分，收权帖涨 <code class="language-plaintext highlighter-rouge">301</code> 分并反超——一周过去，舆论把更多追问压给「谁有资格握壳」而不是「壳换成什么」。供给面同步自证：pi 仓库七天净增 <code class="language-plaintext highlighter-rouge">1,269</code> 星、扩展仓库存量继续爬坡；而线程内部长出的六格质检单没有一格来自厂商文档。壳从选型题变成治理题，正是这两帖并排摆出来的东西。范式表述：<strong>执行壳进入双向流动期——个人用户用脚投票把壳换成可编程、可审计的开源件，机构用户则把壳的持有权按岗位收回；推理没有搬家，搬家的是「谁被允许用壳、用哪个壳」，壳的持有资格开始像权限一样被分级管理。</strong></p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://news.ycombinator.com/item?id=50410107">HN：Goodbye Claude, hello Pi</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50415628">HN：Goldman Sachs is pulling Claude Code from its bankers and traders</a></li>
  <li><a href="https://www.fa-mag.com/news/goldman-restricts-traders-and-bankers-from-using-some-ai-tools-89026.html">Bloomberg 报道（fa-mag 转载）：Goldman restricts traders and bankers from using some AI tools</a></li>
  <li><a href="https://github.com/earendil-works/pi">GitHub：earendil-works/pi</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50410950">leobuskin 订阅挂第三方壳的四条理由</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50410985">gvkhna 从驾驶到编排</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50410853">bottlepalm 出壳论长评</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50411005">jeena 双栈生活自述</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50416595">lukebuehler 致命三角</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50416136">legitster 账单回收自述</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50416089">cactca IPO 时机线</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50416143">pdpi 部门隔离反平衡</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50415978">doctoboggan 医生太太用例</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50415824">Ericson2314 环境设计论</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50410830">giladd 护栏模式之问</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50410706">alfiedotwtf compaction 抱怨</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50410485">komali2 nightly 评测自报</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50410725">siraben bash 透明化扩展</a></li>
  <li><a href="/paradigm-radar-agent-hidden-cost/">站内：AI 范式雷达《标价之外，Harness 替你买了什么》</a></li>
  <li><a href="/paradigm-radar-toolchain-poisoning/">站内：AI 范式雷达《官方渠道沦陷之后》</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="ParadigmRadar" /><category term="paradigm-radar" /><category term="ai-agents" /><category term="developer-tools" /><category term="harness" /><summary type="html"><![CDATA[Hacker News 双帖实测：个人带着订阅把执行壳换成开源 Pi，高盛却把 Claude Code 从交易员与银行员手里收回给工程师——一边搬家一边收权，推理的位置都没挪。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/paradigm-radar-harness-exodus-recall.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/paradigm-radar-harness-exodus-recall.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《工具调用专利三千六，空结果语义无人 claim》</title><link href="https://unbug.github.io/ai-innovation-brief-tool-failure-semantics/" rel="alternate" type="text/html" title="AI 智创简报：《工具调用专利三千六，空结果语义无人 claim》" /><published>2026-11-08T00:00:00+00:00</published><updated>2026-11-08T00:00:00+00:00</updated><id>https://unbug.github.io/ai-innovation-brief-tool-failure-semantics</id><content type="html" xml:base="https://unbug.github.io/ai-innovation-brief-tool-failure-semantics/"><![CDATA[<p>同一个 Google Patents 检索接口、同一天（<code class="language-plaintext highlighter-rouge">2026-11-08</code>）的两次精确短语查询（详情页见<a href="https://patents.google.com/patent/US12430428B2/en">微软异常工具调用判定专利</a>）：”tool execution” 返回 <code class="language-plaintext highlighter-rouge">3638</code> 件专利，”empty tool result” 返回 <code class="language-plaintext highlighter-rouge">0</code> 件：一边人山人海，一边连零件都没有。</p>

<p><img src="/assets/images/tool-failure-semantics-gap.svg" alt="工具调用拦截线专利圈地与空结果语义分流空位" /></p>

<h2 id="大厂圈的是结果进模型之前的拦截线">大厂圈的是结果进模型之前的拦截线</h2>

<p>四件当日二验的详情页给出同一条线。美国运通（American Express Travel Related Services Co Inc）的 <code class="language-plaintext highlighter-rouge">US20260212002A1</code>（LLM 交互安全沙箱，<code class="language-plaintext highlighter-rouge">2026-07-23</code> 公开，优先权日 <code class="language-plaintext highlighter-rouge">2023-11-15</code>，状态 Pending）claim 的是进模型的交互先进沙箱隔离（中译）。微软（Microsoft Technology Licensing LLC）三件：<code class="language-plaintext highlighter-rouge">US12699853B2</code> 语言模型幻觉检测（<code class="language-plaintext highlighter-rouge">2026-08-04</code> 授权公告，优先权日 <code class="language-plaintext highlighter-rouge">2024-01-21</code>）、<code class="language-plaintext highlighter-rouge">US12688403B2</code> 生成式人工智能系统的提示词注入判定（<code class="language-plaintext highlighter-rouge">2026-07-21</code> 授权公告，优先权日 <code class="language-plaintext highlighter-rouge">2023-03-03</code>）、<code class="language-plaintext highlighter-rouge">US12430428B2</code> 异常工具调用判定（<code class="language-plaintext highlighter-rouge">2025-09-30</code> 授权公告，优先权日 <code class="language-plaintext highlighter-rouge">2023-11-15</code>）。输入过滤、调用拦截、输出验真，四件全在「结果进模型之前」动手；没有一件 claim 工具返回空或报错之后，结果语义怎么分流。仓库缺货和收银机坏了，在大厂的权利要求里被当成同一件事。</p>

<h2 id="缺口在结果进门之后">缺口在结果进门之后</h2>

<p>工具调用（tool calling，即大模型按预先约定的 schema 发起外部函数执行）返回失败或空值时，至少混着三种语义：数据库里本来为空、工具服务坏了、参数用错了。分错箱的代价很直接：agent 拿着假空值继续往下推理，把库存查询为空当成商品下架；或者对着临时故障无限重试，烧掉一大截 token 预算。三种情况的正确动作完全不同，如今分流靠的全是开发者手写的临时判断。检索面印证空位：精确短语 “empty tool result” 命中 <code class="language-plaintext highlighter-rouge">0</code> 件；”tool execution” 的 <code class="language-plaintext highlighter-rouge">3638</code> 件里，<code class="language-plaintext highlighter-rouge">2025</code> 至 <code class="language-plaintext highlighter-rouge">2028</code> 分箱 <code class="language-plaintext highlighter-rouge">420</code> 件、<code class="language-plaintext highlighter-rouge">2022</code> 至 <code class="language-plaintext highlighter-rouge">2025</code> 分箱 <code class="language-plaintext highlighter-rouge">136</code> 件，执行侧本身还在加速圈地，结果语义侧仍是零。</p>

<h2 id="痛点有热度供给全在写入侧">痛点有热度，供给全在写入侧</h2>

<p>社区侧同温：Hacker News 近一年五个相关帖。「Google Antigravity exfiltrates data via indirect prompt injection attack」<code class="language-plaintext highlighter-rouge">768</code> 分（<code class="language-plaintext highlighter-rouge">2025-11-25</code>）、「Show HN: Forge – Guardrails take an 8B model from 53% to 99% on agentic tasks」<code class="language-plaintext highlighter-rouge">687</code> 分（<code class="language-plaintext highlighter-rouge">2026-05-19</code>）、「Fixing Tool-Call Accuracy in vLLM」<code class="language-plaintext highlighter-rouge">172</code> 分（<code class="language-plaintext highlighter-rouge">2026-10-26</code>）、「The M×N problem of tool calling and open-source models」<code class="language-plaintext highlighter-rouge">159</code> 分（<code class="language-plaintext highlighter-rouge">2026-04-09</code>）、「Local Indexing to reduce tool calling and token usage」<code class="language-plaintext highlighter-rouge">127</code> 分（<code class="language-plaintext highlighter-rouge">2026-10-12</code>）。工具侧生态同样热闹，但防的全是调用发生之前：npm 上 <code class="language-plaintext highlighter-rouge">@stackone/defender</code>（<code class="language-plaintext highlighter-rouge">0.9.4</code>，<code class="language-plaintext highlighter-rouge">2026-10-21</code> 发布）自述是面向 AI 工具调用的提示词注入防御框架，近一月下载 <code class="language-plaintext highlighter-rouge">57051</code>；评测工具 <code class="language-plaintext highlighter-rouge">promptfoo</code> 近一月下载 <code class="language-plaintext highlighter-rouge">3949597</code>。PyPI 上的 <code class="language-plaintext highlighter-rouge">guardrails-ai</code> 最新 <code class="language-plaintext highlighter-rouge">0.11.0</code>、<code class="language-plaintext highlighter-rouge">llm-guard</code> 最新 <code class="language-plaintext highlighter-rouge">0.3.16</code>，也是写入侧老工具：没有一个做失败结果进门后的分流。需求开了口，供给全堵在上游。</p>

<h2 id="空位是只读的分箱记账">空位是只读的分箱记账</h2>

<p>缺口对应一个个人开发者可交付物：只读的 tool-result（工具返回值）语义审计器。挂在工具调用日志之后，把失败与空返回值分箱成「本来为空、工具故障、参数错误」三类分开记账后出报告，帮开发者算清每类错误烧掉的重试成本；不拦截、不改调用、不碰模型。从公开文本看，四件专利的 claim 停在输入过滤、异常调用检测与输出验真，这种事后、只读、不执行动作的审计暂不落在其文字范围。拦截线上已经站满大厂，收银机后面的小生意还空着。上一篇<a href="/innovation-brief-agent-memory-audit-gap/">智能体记忆坏账审计</a>管的是记进长期记忆的账，这一篇管的是每次工具调用留下的流水。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://patents.google.com/patent/US20260212002A1/en">美国运通 LLM 交互安全沙箱专利</a></li>
  <li><a href="https://patents.google.com/patent/US12699853B2/en">微软幻觉检测专利</a></li>
  <li><a href="https://patents.google.com/patent/US12688403B2/en">微软生成式 AI 系统专利</a></li>
  <li><a href="https://patents.google.com/patent/US12430428B2/en">微软异常工具调用判定专利</a></li>
  <li><a href="https://news.ycombinator.com/item?id=46048996">HN：Antigravity 间接注入数据外泄</a></li>
  <li><a href="https://news.ycombinator.com/item?id=48192383">HN：Forge 护栏把 8B 模型 agentic 任务从 53% 提到 99%</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50242870">HN：修复 vLLM 工具调用准确率</a></li>
  <li><a href="https://news.ycombinator.com/item?id=47704729">HN：工具调用与开源模型的 M×N 问题</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50049508">HN：用本地索引减少工具调用与 token</a></li>
  <li><a href="https://www.npmjs.com/package/@stackone/defender">npm：@stackone/defender</a></li>
  <li><a href="https://www.npmjs.com/package/promptfoo">npm：promptfoo</a></li>
  <li><a href="https://pypi.org/project/guardrails-ai/">PyPI：guardrails-ai</a></li>
  <li><a href="https://pypi.org/project/llm-guard/">PyPI：llm-guard</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="ai-agents" /><category term="patents" /><category term="tool-calling" /><category term="llm-tools" /><category term="solo-dev" /><summary type="html"><![CDATA[四件大厂工具调用专利全部圈在结果进模型之前的拦截线，工具返回失败或空结果之后的语义分流在专利检索面为零；只读的结果语义审计器是尚无权利要求卡住的位置。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/tool-failure-semantics-gap.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/tool-failure-semantics-gap.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《子 agent 别写总结，直接交证据》</title><link href="https://unbug.github.io/one-minute-read-paper-persistent-retrieval-subagent/" rel="alternate" type="text/html" title="一分钟读论文：《子 agent 别写总结，直接交证据》" /><published>2026-11-08T00:00:00+00:00</published><updated>2026-11-08T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-persistent-retrieval-subagent</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-persistent-retrieval-subagent/"><![CDATA[<p>ServiceNow 论文<a href="https://arxiv.org/abs/2611.07899">《Persistent Retrieval for Conversational Agents》</a>实测三种检索架构：检索子 agent 保留跨轮历史、直接交回原始证据，多轮比 skill 内检索省 <code class="language-plaintext highlighter-rouge">43.3%</code> token、<code class="language-plaintext highlighter-rouge">45.0%</code> 成本（牌价估算）。</p>

<p>准确率只降 <code class="language-plaintext highlighter-rouge">1.45</code> 个百分点。三种架构分别是：skill 内检索（<code class="language-plaintext highlighter-rouge">Skill</code>，主 agent 自己查）、无状态检索子代理（每次新历史，返回一段 findings 总结）、持久检索子代理（<code class="language-plaintext highlighter-rouge">Our method</code>，跨轮保留检索历史、把原始证据直接交回主 agent）。数据集是 ServiceNow 的 ITSM 工单 <code class="language-plaintext highlighter-rouge">57</code> 题、HRSD 人事工单 <code class="language-plaintext highlighter-rouge">48</code> 题，以及带多轮依赖的 ITSM Complex <code class="language-plaintext highlighter-rouge">69</code> 题；每组配置跑 <code class="language-plaintext highlighter-rouge">3</code> 次取均值。需要说明的是，作者 <code class="language-plaintext highlighter-rouge">5</code> 人全部来自 ServiceNow，实验跑在自家 agent harness 和自家企业工单集上，结论不宜泛化为所有 agent。</p>

<h2 id="三套架构的账单差在哪">三套架构的账单差在哪</h2>

<p>最贵的是让主 agent 自己把检索结果堆进上下文。在 ITSM Complex 上，<code class="language-plaintext highlighter-rouge">Skill</code> 平均每题 <code class="language-plaintext highlighter-rouge">401.5k</code> token、按公开牌价估算成本 <code class="language-plaintext highlighter-rouge">$0.387</code>；持久子代理是 <code class="language-plaintext highlighter-rouge">210.8k</code> token、<code class="language-plaintext highlighter-rouge">$0.121</code>；无状态子代理是 <code class="language-plaintext highlighter-rouge">148.0k</code> token、<code class="language-plaintext highlighter-rouge">$0.133</code>。持久方案对 <code class="language-plaintext highlighter-rouge">Skill</code> 的成本差为 <code class="language-plaintext highlighter-rouge">3.2</code> 倍，响应时间也从 <code class="language-plaintext highlighter-rouge">58.3</code> 秒降到 <code class="language-plaintext highlighter-rouge">54.3</code> 秒。跨 <code class="language-plaintext highlighter-rouge">5</code> 个多轮设置加权，持久子代理比 <code class="language-plaintext highlighter-rouge">Skill</code> 少 <code class="language-plaintext highlighter-rouge">43.3%</code> token、每题省 <code class="language-plaintext highlighter-rouge">$0.157</code>（<code class="language-plaintext highlighter-rouge">45.0%</code>）、快 <code class="language-plaintext highlighter-rouge">9.1%</code>。</p>

<p>代价也写在同一张表上：ITSM Complex 准确率从 <code class="language-plaintext highlighter-rouge">91.30%</code> 降到 <code class="language-plaintext highlighter-rouge">89.85%</code>，<code class="language-plaintext highlighter-rouge">-1.45</code> 个百分点。这个数字仅在 <code class="language-plaintext highlighter-rouge">69</code> 题多轮依赖集上出现，且是 GPT-5.4-mini 裁判判定的宽松通过率（得分大于 <code class="language-plaintext highlighter-rouge">0</code> 且判为一致即算通过），不是严格准确率。单轮场景反而打平甚至反超：ITSM 上两者同为 <code class="language-plaintext highlighter-rouge">98.25%</code>，每题估算成本从 <code class="language-plaintext highlighter-rouge">$0.113</code> 降到 <code class="language-plaintext highlighter-rouge">$0.068</code>。</p>

<h2 id="省-token-与省钱是两本账">省 token 与省钱是两本账</h2>

<p>把对照系换成无状态子代理，结论会转弯。无状态子代理每次从零开始，持久方案反而比它多用 <code class="language-plaintext highlighter-rouge">41.4%</code> 总 token（ITSM Complex 口径），跨 <code class="language-plaintext highlighter-rouge">5</code> 个多轮设置平均多 <code class="language-plaintext highlighter-rouge">65.1%</code>；两口径属不同统计范围，不能混用。每题估算成本还贵 <code class="language-plaintext highlighter-rouge">$0.043</code>（<code class="language-plaintext highlighter-rouge">29.1%</code>），只是快 <code class="language-plaintext highlighter-rouge">15.6</code> 秒。保留历史把输入变大了，账单却没爆，因为未缓存输入 <code class="language-plaintext highlighter-rouge">$2.50</code>/百万 token、缓存输入只算 <code class="language-plaintext highlighter-rouge">$0.25</code>、输出 <code class="language-plaintext highlighter-rouge">$15</code>（OpenAI 公开的 GPT-5.4 标准牌价）——缓存单价只有未缓存单价的十分之一，存进缓存的那部分历史几乎不要钱，硬生生把账打了下来。所有 <code class="language-plaintext highlighter-rouge">$</code> 数字都是拿录制 token 乘牌价的估算，不是真实账单，也不含检索服务与裁判调用。注意 <code class="language-plaintext highlighter-rouge">43.3%</code>/<code class="language-plaintext highlighter-rouge">45.0%</code> 的省是相对 skill 内检索说的，不能当成「比不优化便宜一半」。</p>

<h2 id="消融别写总结比保留历史更值钱">消融：别写总结比保留历史更值钱</h2>

<p>ITSM Complex 消融把两个机制拆开定价（每题均值）：去掉「直接回传证据」、让子代理改写 findings 总结，成本上浮 <code class="language-plaintext highlighter-rouge">42%</code>、慢 <code class="language-plaintext highlighter-rouge">17.7</code> 秒；去掉「持久历史」只上浮 <code class="language-plaintext highlighter-rouge">8%</code>、慢 <code class="language-plaintext highlighter-rouge">4.3</code> 秒，前者代价是后者的 <code class="language-plaintext highlighter-rouge">5.3</code> 倍；三种配置准确率都停在 <code class="language-plaintext highlighter-rouge">89.85%</code>。真正的大头是不让子代理作文：主 agent 自己读证据、自己写答案，省掉一次中间生成。持久历史的价值则在于复用：同一个子代理跑完 <code class="language-plaintext highlighter-rouge">69</code> 题只做了 <code class="language-plaintext highlighter-rouge">23</code> 次元数据查询和 <code class="language-plaintext highlighter-rouge">59</code> 次 Cypher 查询，而 <code class="language-plaintext highlighter-rouge">Skill</code> 是 <code class="language-plaintext highlighter-rouge">36</code> 次与 <code class="language-plaintext highlighter-rouge">85</code> 次。</p>

<p><img src="/assets/images/persistent-retrieval-subagent.svg" alt="三种检索架构的每题成本与消融代价对比" /></p>

<p>与站内<a href="/one-minute-read-paper-agent-pprof-semantic-stack/}">《像查性能热点一样查智能体的开销》</a>不同：那篇是用 profiler 对已跑轨迹做开销归因，这篇是在架构层面比较三种检索外包姿势的选型，两者不在同一轴上。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2611.07899">Persistent Retrieval for Conversational Agents: A Study of Retrieval Efficiency</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="OneMinuteRead" /><category term="ai-agents" /><category term="retrieval" /><category term="llm-cost" /><category term="agent-architecture" /><summary type="html"><![CDATA[ServiceNow 论文实测三种检索架构：让检索子 agent 保留跨轮历史并直接回传原始证据，多轮场景比 skill 内检索省 43.3% token、省 45.0% 估算 API 成本，准确率仅降 1.45 个百分点。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/persistent-retrieval-subagent.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/persistent-retrieval-subagent.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《智能体开始记长期账，谁来管坏账？》</title><link href="https://unbug.github.io/innovation-brief-agent-memory-audit-gap/" rel="alternate" type="text/html" title="AI 智创简报：《智能体开始记长期账，谁来管坏账？》" /><published>2026-11-07T00:00:00+00:00</published><updated>2026-11-07T00:00:00+00:00</updated><id>https://unbug.github.io/innovation-brief-agent-memory-audit-gap</id><content type="html" xml:base="https://unbug.github.io/innovation-brief-agent-memory-audit-gap/"><![CDATA[<p>2025 年 8 月到 2026 年 6 月，Qomplx、微软、Monday.com 与两家中国公司先后公开或授权 <code class="language-plaintext highlighter-rouge">5</code> 件智能体记忆专利，逐件详情页于 <code class="language-plaintext highlighter-rouge">2026-11-07</code> 二验：权利要求全部圈在「怎么写进去、怎么组起来」，「读出来的记忆还能不能用」无人认领。</p>

<p><img src="/assets/images/agent-memory-governance-gap.svg" alt="智能体记忆治理缺口：写入侧专利圈地与审计侧空位" /></p>

<h2 id="五件专利全在管记账没人管坏账">五件专利全在管记账，没人管坏账</h2>

<p><code class="language-plaintext highlighter-rouge">US20250259042A1</code>（Qomplx Inc，<code class="language-plaintext highlighter-rouge">2025-08-14</code> 公开，优先权日 <code class="language-plaintext highlighter-rouge">2024-02-08</code>）claim 1 保护「任务分解后交给多领域 agent，初步结果嵌入所有 agent 共享的公共 token 空间供后续复用」的编排系统（中译），claim 2 再加跨 agent 分层记忆结构（中译）。<code class="language-plaintext highlighter-rouge">EP4657312A1</code>（Microsoft Technology Licensing LLC，<code class="language-plaintext highlighter-rouge">2025-12-03</code> 公开）claim 1 把上下文数据装入 agent 多层记忆（multi-layer memory），再由此机器学习出「监督等级」配置执行自由度（中译）。<code class="language-plaintext highlighter-rouge">CN121233825B</code>（北京城市网邻信息技术有限公司，<code class="language-plaintext highlighter-rouge">2026-06-26</code> 授权）claim 1 要求先按领域与主题类别从短期记忆存储区召回会话摘要，召不回再转长期记忆存储区（中译）；说明书把上下文工程（context engineering，即对进入模型的记忆与资料做采集、筛选、压缩、排序、更新）就定义为这套流水线。<code class="language-plaintext highlighter-rouge">CN121301536A</code>（上海羚数智能科技有限公司，<code class="language-plaintext highlighter-rouge">2026-01-09</code> 公开）把「基于智能体上下文工程的混合 AI 自适应优化系统」直接写成发明名称（中译），claim 1 的知识库由带来源、时间戳、使用次数、置信度元数据的结构化知识单元组成。<code class="language-plaintext highlighter-rouge">US20260181056A1</code>（Monday.com Ltd，<code class="language-plaintext highlighter-rouge">2026-06-25</code> 公开）最直白，跨 agent 记忆同步子系统直接写进标题：在两个以上 agent 实例间同步记忆完成协作（中译）。</p>

<h2 id="检索面一边拥挤一边近乎空地">检索面一边拥挤，一边近乎空地</h2>

<p>Google Patents 检索接口对精确短语 “context engineering” 的聚合面返回 <code class="language-plaintext highlighter-rouge">185</code> 件，其中 <code class="language-plaintext highlighter-rouge">146</code> 件公开于 <code class="language-plaintext highlighter-rouge">2025</code> 年及以后（分箱来自接口自算 summary，两次命中计数一致）。185 不等于赛道全量，大量同技术专利用 memory store、token space 等词书写，不能作全行业定量结论。反向对比更能说明问题：查 “memory staleness” 仅命中 <code class="language-plaintext highlighter-rouge">4</code> 件，全是硬件内存泄漏与虚拟机状态旧专利（<code class="language-plaintext highlighter-rouge">1987</code> 至 <code class="language-plaintext highlighter-rouge">2021</code> 年），没有一件属于智能体记忆语义。写入装配的术语下七成就在近一年，读取失效的术语下近乎空地。</p>

<h2 id="开发者先不相信工具却只有仓库">开发者先不相信，工具却只有仓库</h2>

<p>社区侧同频，Hacker News 近 12 个月：「Agents don’t need memory, they need documentation」拿到 <code class="language-plaintext highlighter-rouge">392</code> 分，「Don’t trust large context windows」<code class="language-plaintext highlighter-rouge">277</code> 分、「Agent memory as a file format」<code class="language-plaintext highlighter-rouge">191</code> 分；一条 <code class="language-plaintext highlighter-rouge">371</code> 分帖子题为「OpenAI reduces Codex Model Context Size from 372k to 272k」，是社区上报叙述，PR 正文未读，但至少说明上下文预算被当成资源讨论。供给端却是另一个故事：npm 上 mem0ai 最新版 <code class="language-plaintext highlighter-rouge">3.3.1</code>（<code class="language-plaintext highlighter-rouge">2026-09-25</code>）自述就是 The Memory Layer For Your AI Apps，PyPI 上 cognee <code class="language-plaintext highlighter-rouge">1.6.6</code>、memobase <code class="language-plaintext highlighter-rouge">0.0.27</code> 同理都是「存」的库；搜 memory audit、context budget 一类命名，只有 <code class="language-plaintext highlighter-rouge">4</code> 个个人开发者体量的小包（<code class="language-plaintext highlighter-rouge">1</code> 到 <code class="language-plaintext highlighter-rouge">8</code> 个版本），做窗口预算估算或本地日志分析，没有一个审计记忆内容本身。这就是「供大于求、验大于零」的位置差：需求开了口，工具几乎为零。</p>

<h2 id="空位是只读审计不是又一个记忆库">空位是只读审计，不是又一个记忆库</h2>

<p>缺口对应一个可交付物：记忆审计 CLI。指向本地 agent 记忆目录（JSONL、SQLite、Markdown），输出过期条目、矛盾记忆对、从未被召回的死记忆、跨 agent 重复写入；不依赖大模型，不改动记忆，只出报告。从公开文本看，五件 claim 覆盖写入、编排、召回与监督等级配置，只读、离线、不执行任务的审计目前不落在其文字范围；但 Monday.com 的协调层 claim 较宽，产品一旦做成带调度的同步中间件就会贴近，这条边界要守住。上一篇<a href="/innovation-brief-network-agent-testing-patents/">网络排障 Agent 专利</a>解决「上场干活没人监考」，这篇解决「记下来的账没人对账」。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://patents.google.com/patent/US20250259042A1/en">US20250259042A1 - Qomplx</a></li>
  <li><a href="https://patents.google.com/patent/EP4657312A1/en">EP4657312A1 - Microsoft</a></li>
  <li><a href="https://patents.google.com/patent/US20260181056A1/en">US20260181056A1 - Monday.com</a></li>
  <li><a href="https://patents.google.com/patent/CN121233825B/en">CN121233825B - 北京城市网邻</a></li>
  <li><a href="https://patents.google.com/patent/CN121301536A/en">CN121301536A - 上海羚数智能</a></li>
  <li><a href="https://hn.algolia.com/api/v1/search?query=agent+memory&amp;tags=story&amp;numericFilters=points%3E100">HN: Agents don’t need memory</a></li>
  <li><a href="https://hn.algolia.com/api/v1/search?query=context+engineering&amp;tags=story&amp;numericFilters=points%3E150">HN: Codex context size 上报帖</a></li>
  <li><a href="https://pypi.org/pypi/cognee/json">PyPI: cognee</a></li>
  <li><a href="https://registry.npmjs.org/mem0ai">npm: mem0ai</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="patent" /><category term="agent-memory" /><category term="context-engineering" /><category term="dev-tools" /><category term="indie-hacker" /><summary type="html"><![CDATA[2025年8月到2026年6月的五件智能体记忆专利，全部圈在记忆的写入与编排，读取侧的失效审计近乎空白；只读离线审计是尚无权利要求卡住的位置。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/agent-memory-governance-gap.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/agent-memory-governance-gap.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry></feed>