<?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-10-31T05:22:04+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">一分钟读论文：《智能体学会主动清空记忆》</title><link href="https://unbug.github.io/one-minute-read-paper-coral-context-reset/" rel="alternate" type="text/html" title="一分钟读论文：《智能体学会主动清空记忆》" /><published>2026-10-31T00:00:00+00:00</published><updated>2026-10-31T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-coral-context-reset</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-coral-context-reset/"><![CDATA[<p>本文是香港中文大学、腾讯与香港科技大学发在 COLM 2026 的论文<a href="https://arxiv.org/abs/2610.40350">《Don’t Lose the Thread》</a>：智能体学会存档进度、清空脏上下文开新回合，<code class="language-plaintext highlighter-rouge">8B</code> 模型在 GAIA 基准平均准确率 <code class="language-plaintext highlighter-rouge">42.8%</code>，输入 token 比 ReAct 智能体少 <code class="language-plaintext highlighter-rouge">6-7</code> 倍。</p>

<p>论文 <code class="language-plaintext highlighter-rouge">2026</code> 年 <code class="language-plaintext highlighter-rouge">10</code> 月 <code class="language-plaintext highlighter-rouge">29</code> 日提交，已被 COLM 2026 录用，PDF 页眉标注 Published as a conference paper at COLM 2026，作者为 Zheng Zhu、Xiaozhuan Liang、Xi Chen、Bei Yu、Jiaya Jia。方法名 CORAL，取 COgnitive Resource Self-ALlocation（认知资源自我分配）首字母缩写。</p>

<p><img src="/assets/images/coral-context-checkpoint.svg" alt="checkpoint 后重置上下文开新回合" /></p>

<h2 id="上下文越滚越长注意力被稀释">上下文越滚越长，注意力被稀释</h2>

<p>长周期任务（多步搜索、跨文件改代码、持续数小时的调查）里，智能体的工作记忆会被不断膨胀的无关信息塞满：失败的尝试、读过就没用的网页、重复的工具输出，全都堆在上下文窗口里越滚越长。认知过载（工作记忆被无关信息占满）的直接后果是注意力稀释，规划与推理随之受阻：模型不是不会做下一步，而是被噪声盖住了下一步。站内<a href="/one-minute-read-paper-infradev-ai-infrastructure/">《谁来验收AI基建的代码》</a>同样研究过长期跑任务的 Agent：那篇看任务书与验收口径，这篇看上下文负担——窗口塞满之前，谁来丢垃圾。</p>

<h2 id="存档清空开新回合">存档、清空、开新回合</h2>

<p>CORAL 给智能体一个主动动作：在关键节点 checkpoint（存档任务进度与已验证事实），重置被污染的上下文，只留 checkpoint 信息开一个新 episode（回合），从干净状态接着做。这与被动截断或滑动窗口有本质区别：何时清、留什么由模型自己决定，不是由框架按固定长度硬切。乱清反而丢关键事实，预训练模型并不天生善用这个动作。配套 MERPO（Multi-episode Agentic Reinforced Policy Optimization，多回合智能体强化策略优化）算法把 checkpoint 能力训进策略，让模型学会在污染开始前动手，而不是等撑爆窗口才被动裁剪。</p>

<h2 id="428-与-6-7-倍的-token-差距">42.8% 与 6-7 倍的 token 差距</h2>

<p>GAIA 基准（分三档难度、考多步工具调用与网页检索的通用助手基准）上，CORAL 训练出的 <code class="language-plaintext highlighter-rouge">8B</code> 模型平均准确率 <code class="language-plaintext highlighter-rouge">42.8%</code>，提升集中在长周期最难的 Level 2 与 Level 3 两档，这两档正是长周期能力的分水岭。成本侧同样占优：同样的任务用更少 token 换更高准确率，干净上下文本身就是性能来源。能力可泛化到多跳 Knowledge QA（串联多个事实才能作答的问答题）；在更难的 BrowseComp 上，CORAL 让一个强的专有智能体提升 <code class="language-plaintext highlighter-rouge">8.0</code> 分，这条路对前沿模型同样有增量。论文页标注了代码仓库地址，实测访问返回 <code class="language-plaintext highlighter-rouge">404</code>，开源可用性以作者后续发布为准。</p>

<h2 id="把清上下文做成一等动作">把清上下文做成一等动作</h2>

<p>对开发者与独立工作者，启示落在工程习惯上：跑长任务时，与其指望模型在几十万 token 的噪声里保持清醒，不如在框架或提示词里显式提供存档加开新回合的动作，并给出 checkpoint 模板——已验证事实、未决问题、下一步计划各写一段。CORAL 的实验说明，模型要经强化学习才学会何时按下清空动作；没有训练条件的团队，可以用模板强制模型在每个阶段交一次答卷再轻装上阵。把上下文当成需要主动管理的资源，而不只是一个长度上限：主动清空比被动撑爆便宜得多。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2610.40350">Don’t Lose the Thread: Empowering Long-Horizon LLM Agents with Cognitive Resource Self-Allocation（arXiv:2610.40350）</a></li>
  <li><a href="https://colmweb.org/">COLM 2026</a></li>
  <li><a href="/one-minute-read-paper-infradev-ai-infrastructure/">谁来验收AI基建的代码（站内解读）</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="OneMinuteRead" /><category term="llm" /><category term="ai-agents" /><category term="reinforcement-learning" /><category term="context-management" /><summary type="html"><![CDATA[港中文、腾讯与港科大在 COLM 2026 提出 CORAL：长周期任务中智能体主动存档进度并清空脏上下文开新回合，8B 模型在 GAIA 平均准确率 42.8%，输入 token 比 ReAct 智能体少 6 到 7 倍，比被动截断更省更准。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/coral-context-checkpoint.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/coral-context-checkpoint.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《AI 下单的支付路，卡组织先装了两道闸》</title><link href="https://unbug.github.io/innovation-brief-agentic-payment-patents/" rel="alternate" type="text/html" title="AI 智创简报：《AI 下单的支付路，卡组织先装了两道闸》" /><published>2026-10-30T00:00:00+00:00</published><updated>2026-10-30T00:00:00+00:00</updated><id>https://unbug.github.io/innovation-brief-agentic-payment-patents</id><content type="html" xml:base="https://unbug.github.io/innovation-brief-agentic-payment-patents/"><![CDATA[<p>2026 年 8 月单月，支付卡组织在智能体支付（让 AI 智能体替用户办事的 agentic commerce）上连落三子：万事达拿下一件授权，Visa 同日公开两件 PCT。</p>

<p>具体是：万事达国际公司于 <code class="language-plaintext highlighter-rouge">2026-08-11</code> 获授权 US12705604B2，权利要求写的就是「由用户设备上的大语言模型（LLM）custom agent 接收订行程的请求，并对多笔订单执行安全支付」；<code class="language-plaintext highlighter-rouge">2026-08-20</code> 同一天，Visa 国际服务协会两件 PCT 公开——WO2026173611A1《Infrastructure for authenticated agentic commerce》与 WO2026173648A1《Agentic payments and commerce》，优先权均落在 2025 年 2 月 13 日的美国临时申请。公开不等于授权，两件 PCT 尚在路上，授权文本才是既成事实。</p>

<p><img src="/assets/images/innovation-brief-agentic-payment-patents.svg" alt="智能体支付专利时间轴与开源生态对照" /></p>

<h2 id="两道闸凭证怎么发合同怎么管">两道闸：凭证怎么发、合同怎么管</h2>

<p>把三件文本摆在一起，卡组织圈的是同一条路的两道闸。凭证闸：万事达的授权件让 LLM 智能体拿一次性访问令牌收款单，Visa 的基础设施件把令牌再收紧一档——「tokenization process that restricts payment tokens to a particular agent and contract」，令牌绑定到具体智能体与具体合同，换人换单即失效。合同闸：Visa 文本写明支付网络「monitor contracts and their state, ensuring transactions remain within budget」，智能体能花多少钱、买什么东西，以用户签署的合同为准，网络逐笔核对。为此 Visa 还配了一套 PKI：智能体服务商要过审查才拿得到支付网络证书权威签发的数字证书，轻量商户则用动态交易校验值 dTVV 免接口接入。个人 inventor 也已在合规控制面抢跑——澳大利亚临时申请 AU2026906209A0《Bounded Execution Compliance Control Plane for Agentic Payment》公开于 2026-07-23，临时申请未实审，只算风向标。</p>

<h2 id="协议战开打适配层还是空的">协议战开打，适配层还是空的</h2>

<p>专利之外，协议生态同期铺开（均实测 2026-10-30）：Stripe 的 ACP 文档写明「Shared Payment Tokens——给智能体发起的购物发放限定作用域的支付凭证」，配套 Catalog feed 让商户把商品数据喂给 AI 发现；Google 的 AP2 开源仓库 3,254 星（2025-05-30 创建，Apache-2.0）；ACP 规范仓 1,591 星，Anthropic 的 commerce-agents 仓库 2026-09-01 新建已聚到 3,378 星，GitHub 上 agentic commerce 相关仓库共 6,862 个。规范热闹，落地端却缺胶水：中小商户要把存量商品库、库存、结账接口改造成协议兼容，目前基本靠外包手写。</p>

<h2 id="三段能接的活">三段能接的活</h2>

<p>一是合同授权对账器：商户与用户都需要一把独立尺——把 ACP/AP2 的授权书、预算、有效期字段做成校验与越界告警台账，纯软件、订阅制、不碰卡号即可绕开 PCI 重负。二是商户侧协议适配网关：照着 Stripe Catalog feed 与 AP2 规范做批量转换器，按商户数收费，四周能出 MVP。三是智能体支付审计回放：每笔智能体发起的支付请求、令牌作用域、拒付证据链本地留痕可验证——凭证层专利被卡组织圈走，对凭证层做审计这层目前没有专利圈地，且与 agent 成本取证（本栏目雷达第 20 期）同构起量。</p>

<h2 id="门槛与风险">门槛与风险</h2>

<p>两条路径：工具站形态（合同校验+审计台账打包 SaaS，VPS 千元级月成本起步，首批客户找已接 ACP 的跨境电商服务商）；或咨询+适配一体（帮商户接协议、顺手沉淀转换器，客单高但难规模化）。硬门槛有三个：不碰主账号 PAN、全部停留在令牌与合同字段层，否则 PCI 合规压垮个人；规范仍在快改，ACP 与 AP2 字段半年一换，抽象层要做薄；最长期风险是卡组织把对账能力直接内建——但 PCT 尚在早期，留给独立开发者的窗口以年计。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://patents.google.com/patent/US12705604B2/en">US12705604B2 — Mastercard：Secure payment flow using an LLM agent with a single use access token</a></li>
  <li><a href="https://patents.google.com/patent/WO2026173611A1/en">WO2026173611A1 — Visa：Infrastructure for authenticated agentic commerce</a></li>
  <li><a href="https://patents.google.com/patent/WO2026173648A1/en">WO2026173648A1 — Visa：Agentic payments and commerce</a></li>
  <li><a href="https://patents.google.com/patent/AU2026906209A0/en">AU2026906209A0 — Bounded Execution Compliance Control Plane for Agentic Payment</a></li>
  <li><a href="https://docs.stripe.com/agentic-commerce">Stripe Agentic Commerce 文档</a></li>
  <li><a href="https://github.com/google-agentic-commerce/AP2">Google AP2 开源仓库</a></li>
  <li><a href="https://github.com/agentic-commerce-protocol/agentic-commerce-protocol">ACP 规范仓库</a></li>
  <li><a href="/paradigm-radar-agent-hidden-cost/">站内：范式雷达第 20 期——标价之外，Harness 替你买了什么</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="Patent" /><category term="AIAgent" /><category term="Payment" /><category term="AgenticCommerce" /><category term="IndieHacker" /><summary type="html"><![CDATA[2026 年 8 月一个月内，万事达授权一件 LLM 智能体支付专利，Visa 同日公开两件 agentic commerce PCT。凭证发放与合同监控两层被卡组织圈走，授权对账、商户协议适配与支付审计回放是个人开发者能接的三段活。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/innovation-brief-agentic-payment-patents.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/innovation-brief-agentic-payment-patents.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《服务商省钱的缓存手段，被专利圈起来了》</title><link href="https://unbug.github.io/innovation-brief-kv-cache-serving-patents/" rel="alternate" type="text/html" title="AI 智创简报：《服务商省钱的缓存手段，被专利圈起来了》" /><published>2026-10-30T00:00:00+00:00</published><updated>2026-10-30T00:00:00+00:00</updated><id>https://unbug.github.io/innovation-brief-kv-cache-serving-patents</id><content type="html" xml:base="https://unbug.github.io/innovation-brief-kv-cache-serving-patents/"><![CDATA[<p>7 月 2 日到 8 月 13 日的六周里，大模型推理的 KV 缓存（key-value cache，生成时复用历史注意力计算、省去重复预填充的显存缓存）层落了六件专利：六家申请人互不重叠，已授权 <code class="language-plaintext highlighter-rouge">1</code> 件、公开申请 <code class="language-plaintext highlighter-rouge">5</code> 件，逐件详情页于 <code class="language-plaintext highlighter-rouge">2026-10-31</code> 逐一核验。</p>

<p>节奏是：支付宝与火山引擎两件在 7 月初公开，Google 与微软两件欧洲申请 7 月末 8 月初公开，记忆张量一件 8 月 11 日在中国获授权，AtomBeam 一件 8 月 13 日公开。</p>

<p><img src="/assets/images/innovation-brief-kv-cache-serving-patents.svg" alt="KV 缓存专利时间轴与圈层地图" /></p>

<h2 id="六件专利圈的全是服务端">六件专利圈的全是服务端</h2>

<p>按公开日排开：<code class="language-plaintext highlighter-rouge">WO2026138159A1</code>（支付宝，<code class="language-plaintext highlighter-rouge">2026-07-02</code> 公开，优先权为中国申请 <code class="language-plaintext highlighter-rouge">2024-12-25</code>）做推理缓存优化；<code class="language-plaintext highlighter-rouge">US20260195309A1</code>（火山引擎，<code class="language-plaintext highlighter-rouge">2026-07-09</code> 公开，权利要求 1 写「sending, upon determining that there is first key-value data in a graphics memory of a graphics processing unit, a data storage request…」（中译：确定图形处理单元显存中存在第一键值数据时，向其发起存储请求）——显存到 KV 数据库的分层调度）；<code class="language-plaintext highlighter-rouge">EP4781281A1</code>（Google，<code class="language-plaintext highlighter-rouge">2026-07-29</code> 公开，优先权日 <code class="language-plaintext highlighter-rouge">2023-10-26</code>）做序列处理的并行化提效；<code class="language-plaintext highlighter-rouge">EP4785219A1</code>（微软，<code class="language-plaintext highlighter-rouge">2026-08-05</code> 公开，优先权日 <code class="language-plaintext highlighter-rouge">2023-09-28</code>）标题直书「Kv-cache streaming for improved performance and fault tolerance」，把 KV 缓存当流式管道在模型服务系统里搬运；<code class="language-plaintext highlighter-rouge">CN122019408B</code>（记忆张量，<code class="language-plaintext highlighter-rouge">2026-08-11</code> 授权）最激进——语义段哈希索引、前缀哈希表底层指针覆写实现「零拷贝跨上下文复用」、原子引用计数管显存生命周期，说明书明写目标是多智能体共享工作记忆、降首字延迟；<code class="language-plaintext highlighter-rouge">US20260236476A1</code>（AtomBeam，<code class="language-plaintext highlighter-rouge">2026-08-13</code> 公开）把缓存对象从 KV 再往前推一层，直接缓存多阶段系统的隐式思维（latent thought）。值得留意的是微软与 Google 两件优先权分别落在 <code class="language-plaintext highlighter-rouge">2023-09-28</code> 与 <code class="language-plaintext highlighter-rouge">2023-10-26</code>——公开潮滞后于圈地近两年。</p>

<h2 id="空位在客户端那一侧">空位在客户端那一侧</h2>

<p>把六件权利要求叠起来看，圈地全部发生在推理服务商的基础设施层：显存分层、流式搬运、并行调度、缓存复用引擎。但硬币另一面没人圈：怎么让请求天然命中这些缓存，是调用方的事。缓存按前缀匹配计费打折已是各家 API 的公开卖点，命中率却取决于提示词结构——系统提示放最前、可变内容放最后、会话历史别插队改写，这些排列纪律散落在工程博客里，没有一个工具把它做成可执行的审查。专利检索里，「面向缓存命中的提示词自动重排」这类客户端侧方案未见大厂落子。</p>

<h2 id="三段能接的活">三段能接的活</h2>

<p>一是缓存命中审查器：接用户的提示词模板与调用日志，离线给出重排建议与预期命中率、按前缀计费折扣折算月省金额——纯客户端软件，不碰服务商调度层，绕开六件专利的正面。二是前缀折扣审计：各家 API 的缓存折扣口径不一（折扣比例、最短前缀长度、TTL 各不相同），做独立第三方对账面板，验证账单上每一次折扣是否真给足——与之前写过的 agent 成本取证同族，客户重叠。三是多智能体缓存一致性测试：记忆张量那件授权件把「多智能体共享工作记忆」写进了说明书，共享缓存引发的串话、越权读到别人上下文这类缺陷，正是测试工具该盯的靶子——做验证不做实现，专利风险最低。</p>

<h2 id="门槛与风险">门槛与风险</h2>

<p>三段活都不需要自建推理集群：审查器与审计面板是纯文本处理加账单解析，VPS 级成本可起步；一致性测试需会编排多 agent 的测试框架，门槛稍高但客单也高。两条风险：一是缓存命中优化直接省服务商 GPU 成本，长期看服务商有动力内建成产品功能，窗口以年计；二是记忆张量授权件保护面较宽（语义段级复用），做第三段活时把工具钉死在「测试与验证」，别碰「实现复用」。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://patents.google.com/patent/WO2026138159A1/en">WO2026138159A1 — 支付宝：大模型推理中的缓存优化方法及装置</a></li>
  <li><a href="https://patents.google.com/patent/US20260195309A1/en">US20260195309A1 — 火山引擎：基于键值数据库的数据处理方法</a></li>
  <li><a href="https://patents.google.com/patent/EP4781281A1/en">EP4781281A1 — Google：Efficiently serving machine-learned model computations</a></li>
  <li><a href="https://patents.google.com/patent/EP4785219A1/en">EP4785219A1 — Microsoft：Kv-cache streaming for improved performance and fault tolerance</a></li>
  <li><a href="https://patents.google.com/patent/CN122019408B/en">CN122019408B — 记忆张量：一种用于语言模型推理的键值缓存调度方法及系统</a></li>
  <li><a href="https://patents.google.com/patent/US20260236476A1/en">US20260236476A1 — AtomBeam：Latent Thought Caching for Multi-Stage Language Model Systems</a></li>
  <li><a href="/paradigm-radar-agent-hidden-cost/">站内：AI 范式雷达第 20 期——标价之外，Harness 替你买了什么</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="patent" /><category term="llm-inference" /><category term="kv-cache" /><category term="cost-optimization" /><category term="indie-hacker" /><summary type="html"><![CDATA[7月初到8月中旬六周内，微软、谷歌、支付宝、火山引擎、AtomBeam与记忆张量各自公开或授权一件KV缓存专利，六件全部圈在推理服务商侧；提示词按缓存重排与命中率审计仍是空位。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/innovation-brief-kv-cache-serving-patents.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/innovation-brief-kv-cache-serving-patents.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《谁来验收AI基建的代码》</title><link href="https://unbug.github.io/one-minute-read-paper-infradev-ai-infrastructure/" rel="alternate" type="text/html" title="一分钟读论文：《谁来验收AI基建的代码》" /><published>2026-10-30T00:00:00+00:00</published><updated>2026-10-30T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-infradev-ai-infrastructure</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-infradev-ai-infrastructure/"><![CDATA[<p>爱丁堡大学联合腾讯混元的论文<a href="https://arxiv.org/abs/2610.36589">《InfraDev》</a>（arXiv:2610.36589）测了编码 Agent 开发 AI 基建（训练、推理、强化学习框架的代码）的水位：<code class="language-plaintext highlighter-rouge">36</code> 个真实任务上，最强模型 <code class="language-plaintext highlighter-rouge">GPT-6 Sol</code> 只解决 <code class="language-plaintext highlighter-rouge">38.9%</code>，隐藏探针还毙掉 <code class="language-plaintext highlighter-rouge">32%</code> 通过官方测试的提交。</p>

<p>论文全称 InfraDev: Can Coding Agents Develop AI Infrastructure, and How Can We Tell?，是 <code class="language-plaintext highlighter-rouge">2026</code> 年 <code class="language-plaintext highlighter-rouge">10</code> 月 <code class="language-plaintext highlighter-rouge">27</code> 日提交的预印本。</p>

<p><img src="/assets/images/infradev-coding-agents-ai-infra.svg" alt="提交漏斗与解决率水位" />任务取自 <code class="language-plaintext highlighter-rouge">Megatron-LM</code>、<code class="language-plaintext highlighter-rouge">vLLM</code>、<code class="language-plaintext highlighter-rouge">verl</code> 三个生产仓库在 2025 年 1 月至 2026 年 9 月合并的 <code class="language-plaintext highlighter-rouge">21,389</code> 个 pull request，只保留跨多文件、必须多 GPU 跑对的真改动，最终 <code class="language-plaintext highlighter-rouge">36</code> 个：训练 <code class="language-plaintext highlighter-rouge">19</code>、推理 <code class="language-plaintext highlighter-rouge">10</code>、强化学习 <code class="language-plaintext highlighter-rouge">7</code>。六个前沿模型在每个任务上各跑一次，独占一台 <code class="language-plaintext highlighter-rouge">8</code> 卡 NVIDIA H800/H20 节点，限时 <code class="language-plaintext highlighter-rouge">2.5</code> 小时。</p>

<h2 id="官方测试本身在放水">官方测试本身在放水</h2>

<p>论文最锋利的一刀砍向打分器：现有基准拿 PR 自带的官方测试判卷，而这些测试对 AI 基建并不完整。<code class="language-plaintext highlighter-rouge">36</code> 个 PR 里 <code class="language-plaintext highlighter-rouge">24</code> 个没有任何测试检查数值结果；<code class="language-plaintext highlighter-rouge">15</code> 个性能优化 PR 里 <code class="language-plaintext highlighter-rouge">13</code> 个没有任何测试检查承诺的提速，跳过优化的补丁照样通过。作者的对策是联合合成 hidden probes（隐藏探针：新写的验收测试，只要求通过合并时的正确补丁，不泄露解法，接口写进 prompt），两头堵住蒙混过关的路。</p>

<p>结果：<code class="language-plaintext highlighter-rouge">216</code> 份提交中 <code class="language-plaintext highlighter-rouge">102</code> 份全过官方测试，只有 <code class="language-plaintext highlighter-rouge">69</code> 份同时过得了探针，探针毙掉这 <code class="language-plaintext highlighter-rouge">102</code> 份里的 <code class="language-plaintext highlighter-rouge">32%</code>；加上探针后，六个模型的解决率全部下降 <code class="language-plaintext highlighter-rouge">11</code> 到 <code class="language-plaintext highlighter-rouge">19</code> 个百分点。站内<a href="/one-minute-read-paper-rag-defense-benchmark-shortcut/">《删掉一个前缀，近满分的投毒防御当场裸奔》</a>同样提醒过评估口径的分量。</p>

<h2 id="389-就是当前天花板">38.9% 就是当前天花板</h2>

<p>以官方测试加探针联合打分，<code class="language-plaintext highlighter-rouge">GPT-6 Sol</code> 的解决率 <code class="language-plaintext highlighter-rouge">38.9%</code>，是六机之首；它每任务平均耗时 <code class="language-plaintext highlighter-rouge">43.9</code> 分钟、估算 API 成本 <code class="language-plaintext highlighter-rouge">5.37</code> 美元、消耗 <code class="language-plaintext highlighter-rouge">20.86M</code> tokens（按牌价估算，每任务只跑一次，无方差），口径是全部测试通过的解决率，不是通用编程能力分。分类别看，推理任务最难：每个模型在 <code class="language-plaintext highlighter-rouge">10</code> 个推理任务里都只解决 <code class="language-plaintext highlighter-rouge">1</code> 个。更扎手的对照来自 prompt：直接拿 PR 原始的 GitHub 描述当任务书，没有任何模型解决哪怕一个任务，缺失接口说明的提示词，杀伤力比测试更大。</p>

<p>对 <code class="language-plaintext highlighter-rouge">1,754</code> 个失败测试用例的归因显示，结构性错误与状态性错误占主导，Agent 自写的测试几乎从不检查 memory、time、traffic（显存占用、运行耗时、通信流量），且三分之二的错误被多数模型共享，不同厂商的模型在栽同样的跟头。工程侧的副产品是共享执行环境：跨任务复用依赖与产物，在 Megatron-LM 和 vLLM 上省 <code class="language-plaintext highlighter-rouge">52–57%</code> 存储、<code class="language-plaintext highlighter-rouge">13–14%</code> 构建时间。论文同时提醒，<code class="language-plaintext highlighter-rouge">32%</code> 的假阳性是探针互证口径，由论文自建探针裁决，不是独立的 ground truth。</p>

<h2 id="一份规范文档值-105-个百分点">一份规范文档值 10.5 个百分点</h2>

<p>把失败模式整理成 AI 基建开发规范的 agent skill（给 Agent 的说明文档）后，<code class="language-plaintext highlighter-rouge">GPT-5.6 Sol</code> 的解决率在 <code class="language-plaintext highlighter-rouge">19</code> 个任务的 Megatron-LM 子集上从 <code class="language-plaintext highlighter-rouge">42.1%</code> 升到 <code class="language-plaintext highlighter-rouge">52.6%</code>，提升 <code class="language-plaintext highlighter-rouge">10.5</code> 个百分点；干预对象不是榜单冠军 <code class="language-plaintext highlighter-rouge">GPT-6 Sol</code>。论文称将开源 InfraDev，但尚未上线；全文为未经同行评审的预印本，数字均为论文自测口径。对做 agent 工程的人来说，这个实验的提示很朴素：先把领域验收规范写进交接文档，再谈模型能力天花板。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2610.36589">InfraDev: Can Coding Agents Develop AI Infrastructure, and How Can We Tell?（arXiv:2610.36589）</a></li>
  <li><a href="/one-minute-read-paper-rag-defense-benchmark-shortcut/">删掉一个前缀，近满分的投毒防御当场裸奔（站内解读）</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="Engineering" /><category term="llm" /><category term="agent" /><category term="agentic-coding" /><category term="benchmark" /><summary type="html"><![CDATA[爱丁堡大学联合腾讯混元发布InfraDev基准，用36个多GPU真实任务测编码Agent开发训练与推理框架的水位：最强模型仅解决38.9%，隐藏探针还毙掉通过官方测试提交的32%，失败模式写成规范文档能补10.5个百分点。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/infradev-coding-agents-ai-infra.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/infradev-coding-agents-ai-infra.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 范式雷达：《标价之外，Harness 替你买了什么》</title><link href="https://unbug.github.io/paradigm-radar-agent-hidden-cost/" rel="alternate" type="text/html" title="AI 范式雷达：《标价之外，Harness 替你买了什么》" /><published>2026-10-30T00:00:00+00:00</published><updated>2026-10-30T00:00:00+00:00</updated><id>https://unbug.github.io/paradigm-radar-agent-hidden-cost</id><content type="html" xml:base="https://unbug.github.io/paradigm-radar-agent-hidden-cost/"><![CDATA[<p>独立取证帖实测出 Claude Code 的后台 agent 状态摘要请求占其周消耗 <code class="language-plaintext highlighter-rouge">16.4%</code>，且不写入本地会话记录，普通成本工具看不见这笔钱（取证方自述样本；HN <code class="language-plaintext highlighter-rouge">50284255</code> 实测 <code class="language-plaintext highlighter-rouge">518</code> 分，<code class="language-plaintext highlighter-rouge">2026-10-29</code>）。</p>

<p>机制细节：Claude Code 每隔约 <code class="language-plaintext highlighter-rouge">30</code> 秒把每个后台 agent（background agent，指在主会话之外持续干活的子任务）的完整 transcript（会话记录）发给其模型（<code class="language-plaintext highlighter-rouge">96%</code> 走 Opus），只为生成状态栏里 3-5 个词的摘要，该类请求占其 API 请求总数 <code class="language-plaintext highlighter-rouge">19.7%</code>。三向证据同日摆开：厂方 Claude Code 成员 edwinarbus 在评论 <code class="language-plaintext highlighter-rouge">50284699</code> 承认机制并给出厂方自述口径——上周全量遥测用户中 <code class="language-plaintext highlighter-rouge">agent_summary</code> 约占 API 标价成本 <code class="language-plaintext highlighter-rouge">2%</code>、请求数不到 <code class="language-plaintext highlighter-rouge">4%</code>，终端场景约 <code class="language-plaintext highlighter-rouge">6%</code>，并称已在 <code class="language-plaintext highlighter-rouge">2.1.311+</code> 上线修复（均为厂方自述）；供给端窗口内新建的独立计量仓至少五个（microsoft/TokenEconomizer <code class="language-plaintext highlighter-rouge">492</code> 星等，实测 <code class="language-plaintext highlighter-rouge">2026-10-29</code>）；宏观侧 OpenRouter 官方榜单帖《Token-maxxing is dead》（HN <code class="language-plaintext highlighter-rouge">50159464</code>，<code class="language-plaintext highlighter-rouge">45</code> 分）给出用量见顶的旁证。</p>

<p>范式表述：<strong>agent 隐性开销显形化——开发者对 agent 的成本假设正从「标价 × 我看得见的调用」切换为「必须实测 harness（包裹大模型、管理工具调用与会话的执行框架）在标价之外替你买了什么」；计量单位从 token 单价下沉到请求来源（Claude Code 的 OpenTelemetry 字段 <code class="language-plaintext highlighter-rouge">query_source</code>）级，账单第一次需要像安全事件一样被取证。</strong>本文全部数字为 <code class="language-plaintext highlighter-rouge">2026-10-29</code> 晚经 HN Algolia API 全树遍历与 GitHub API 复测，转述与自述均已标注。据我们观察未发现同类中文报道（本检索通道未覆盖中文媒体）。</p>

<p><img src="/assets/images/paradigm-radar-agent-hidden-cost-cover.svg" alt="封面：状态栏之下，看不见的摘要请求正把完整会话记录反复送回模型" /></p>

<h2 id="一笔没有账单的请求机制与取证">一笔没有账单的请求：机制与取证</h2>

<p>按 gist 原文（实测创建于 <code class="language-plaintext highlighter-rouge">2026-10-26T22:27Z</code>），该摘要请求自 <code class="language-plaintext highlighter-rouge">2.1.232</code>（2026 年 8 月）起默认开启、无官方关闭开关；回答只更新 agents 面板的状态行，「never reaches the model or your conversation」。异常由 Flamerix 的 DRIM 工具在 Claude Code 自身的 OpenTelemetry 导出里发现：把 <code class="language-plaintext highlighter-rouge">claude_code.api_request</code> 事件按 <code class="language-plaintext highlighter-rouge">query_source</code> 分组后，<code class="language-plaintext highlighter-rouge">agent_summary</code> 的花费「more than the main conversation itself」——占全部花费 <code class="language-plaintext highlighter-rouge">16.4%</code>（主对话本身 <code class="language-plaintext highlighter-rouge">15.7%</code>）、占请求数约五分之一，其中 <code class="language-plaintext highlighter-rouge">96%</code> 走 Opus，input:output 约 <code class="language-plaintext highlighter-rouge">9,000:1</code>。三项口径必须写清：<code class="language-plaintext highlighter-rouge">16.4%</code> 系取证方自述样本，且花费是 Claude Code 自己的 <code class="language-plaintext highlighter-rouge">cost_usd</code> 估算而非发票，订阅制下损失的是限速额度而非现金；gist 转述 issue <code class="language-plaintext highlighter-rouge">#86879</code>「collects four independent measurements of 18-26%」，属转述、未经逐一核验；<code class="language-plaintext highlighter-rouge">#86879</code> 本体实测 open、<code class="language-plaintext highlighter-rouge">22</code> 个 reactions、<code class="language-plaintext highlighter-rouge">7</code> 条评论，标题原文「Feature request: a supported way to disable the agent_summary spinner (22.7% of requests, ~18% of weighted tokens in a subagent-heavy session)」。gist 声明独立于 Anthropic（原文标注非关联方），但 Flamerix 自身售卖 DRIM 工具，动机需计入。盲区正是范式支点：「These requests are not written to the transcript… the OpenTelemetry export shows them」——读本地 transcript 的成本工具天然看不见这笔钱。</p>

<h2 id="供给端独立计量工具簇成排出现">供给端：独立计量工具簇成排出现</h2>

<p>独立计量（用开发者自己运行的工具核对 harness 实际发出的请求与花费）不是新行当，新在窗口内的密度。窗口内新建或活跃的独立仓（全部 GitHub API 实测 <code class="language-plaintext highlighter-rouge">2026-10-29</code>）：<code class="language-plaintext highlighter-rouge">microsoft/TokenEconomizer</code> <code class="language-plaintext highlighter-rouge">492</code> 星、创建于 <code class="language-plaintext highlighter-rouge">2026-10-13</code>，微软官方组织，描述「Experience-Driven Black-Box Cost Control for Coding Agents」，是供给端最重信号；<code class="language-plaintext highlighter-rouge">kelviq/tare</code> <code class="language-plaintext highlighter-rouge">301</code> 星（「Ask Claude Code where your usage went」）；<code class="language-plaintext highlighter-rouge">splunk/token-meter</code> <code class="language-plaintext highlighter-rouge">139</code> 星（Splunk 官方组织，本地优先仪表盘）；<code class="language-plaintext highlighter-rouge">rbartoli/agent-usage-guard</code> <code class="language-plaintext highlighter-rouge">83</code> 星（拦截 subagent fan-out 与重试循环）；<code class="language-plaintext highlighter-rouge">aashish254/burn</code> <code class="language-plaintext highlighter-rouge">43</code> 星（本地零依赖成本台账）。存量头部 <code class="language-plaintext highlighter-rouge">getagentseal/codeburn</code> <code class="language-plaintext highlighter-rouge">11,612</code> 星（2026-04 创建）说明赛道有 prior art，新意在三个官方组织（微软、Splunk、阿里 loongsuite-pilot <code class="language-plaintext highlighter-rouge">231</code> 星）同窗入场做 harness 侧计量。搜索面同样实测：<code class="language-plaintext highlighter-rouge">"token usage"</code> 存量 <code class="language-plaintext highlighter-rouge">5,676</code> 库、其中 <code class="language-plaintext highlighter-rouge">2026-06</code> 以来新建 <code class="language-plaintext highlighter-rouge">3,296</code>，近五个月新建占存量约 <code class="language-plaintext highlighter-rouge">58%</code>。与第 19 期<a href="/paradigm-radar-agent-gateway-layer/">《把 Agent 的线拉进自己的箱子》</a>的区隔：那期在传输层装闸、回答「此刻这字节经过谁的手」，本期给账单验光、回答「标价之外它替我花了哪些钱」——网关只是本期的手段之一。与第 15 期《Agent的Token消耗经济学》<a href="/paradigm-radar-token-consumption-economics/">站内链接</a>的区隔：那期算 token 单价的宏观账，本期查厂商默认值替你下的微观单。与第 18 期<a href="/paradigm-radar-agent-daemon-sovereignty/">《当你的笔记本上住进别人家的守护进程》</a>的区隔：那期要驱逐别人的常驻进程，本期不要求驱逐任何东西，只要求账本可验证。</p>

<h2 id="反方与边界从计量无意义到厂方口径战">反方与边界：从「计量无意义」到「厂方口径战」</h2>

<p>线程内至少四条反方论据有实质内容。<code class="language-plaintext highlighter-rouge">50285828</code>（jstummbillig）逐字称「What market is going to care about the number of tokens somebody uses?… It’s nonsense」——token 计量本身无意义论。厂方 edwinarbus（<code class="language-plaintext highlighter-rouge">50284699</code>）的反证最锋利：机制「only applies to background agents that are actively working」，空闲后台 agent 不触发，「Your 16.4% sounds like it was for a team running mostly background agents」——样本代表性反证，与厂方自述的 <code class="language-plaintext highlighter-rouge">2%/4%/6%</code> 口径互为表里，两组数字都只有自述可查、无第三方能独立复测厂方全量。<code class="language-plaintext highlighter-rouge">50287810</code>（brookst）质疑动机论：厂商故意烧 token 自损成本、赶用户去竞品，不合商业逻辑。同线程 <code class="language-plaintext highlighter-rouge">50288850</code>（subscribed）则反问关闭路径缺失：「is the distinct absence of any mechanism to tune/turn it off for our own good?」边界条件继续列开：gist 自承花费为估算非发票；<code class="language-plaintext highlighter-rouge">2.1.311+</code> 修复已上线意味着「无法关闭」的指责正在失效，但按厂方自述仍是「最贵场景修复加更便宜模式在路上」，不是关闭开关；同一周还有 <code class="language-plaintext highlighter-rouge">50219875</code>《Claude Code slyly adding users’ emails to outbound HTTP》（<code class="language-plaintext highlighter-rouge">22</code> 分、全树 <code class="language-plaintext highlighter-rouge">8</code>）作为 harness 未授权行为的旁证帖，热度不足以独立成波，仅作影子行为注脚。</p>

<h2 id="品类成形度与观察点">品类成形度与观察点</h2>

<p>成形度判断：锚点 <code class="language-plaintext highlighter-rouge">518</code> 分仍在涨（本文调研当日内多次复测递增），需求情绪有第 19 期主证帖《If you don’t run your own LLM proxy, how do you know whats going on?》（HN <code class="language-plaintext highlighter-rouge">50145507</code>，<code class="language-plaintext highlighter-rouge">303</code> 分、全树 <code class="language-plaintext highlighter-rouge">220</code>，本期只取其「你不知道脚下跑了哪些请求」的计量学读法，引用切割如前）；但工具簇自身帖热度仍低（agent-usage-guard 仅 <code class="language-plaintext highlighter-rouge">28</code> 分），OpenRouter 拐点帖 <code class="language-plaintext highlighter-rouge">45</code> 分——与第 19 期同款「品类前夜」形态：情绪与事故轴滚烫，命名与产品轴温吞。实操侧窗口内已给出动作：复制 <code class="language-plaintext highlighter-rouge">#86879</code> 的 <code class="language-plaintext highlighter-rouge">query_source</code> 分组自查法，用 OTel 导出核对自己的请求结构；重度用户可用 gist 的 Bun preload 方案（约 <code class="language-plaintext highlighter-rouge">70</code> 行、不改二进制，但 gist 自警「An update can silently undo it」，每次升级后复查）。第 19 期埋下的观察点（OTel 规范派与自建代理派之争）在本期获得部分回答：loongsuite-pilot、tare 等走 OTel 路线，本地台账与遥测导出正在成为计量主战场。观察点三条：厂方「更便宜模式」（小模型加短笔记替代全量 transcript）是否落地并进入文档；<code class="language-plaintext highlighter-rouge">#86879</code> 是否获得官方关闭开关；下一个被取证的隐性请求类型会不会来自 Codex 或 Cursor——同构蔓延即下一期选题判据。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://news.ycombinator.com/item?id=50284255">HN 50284255：Claude Code 定期把每个后台 agent 的 transcript 发给其模型</a></li>
  <li><a href="https://gist.github.com/flamerix-ai/c3905705cc4205e5de3011fa2e74efce">Flamerix gist：Claude Code burns ~15-20% of your tokens on a 3-word status line</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50284699">HN 评论 50284699：Claude Code 成员 edwinarbus 厂方回帖</a></li>
  <li><a href="https://github.com/anthropics/claude-code/issues/86879">anthropics/claude-code issue #86879：请求提供关闭 agent_summary 的官方方式</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50145507">HN 50145507：不跑自己的 LLM proxy 怎么知道发生了什么</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50159464">HN 50159464：Token-maxxing is dead, OpenRouter’s token usage plateaus</a></li>
  <li><a href="https://github.com/microsoft/TokenEconomizer">microsoft/TokenEconomizer GitHub 仓库</a></li>
  <li><a href="https://github.com/splunk/token-meter">splunk/token-meter GitHub 仓库</a></li>
  <li><a href="https://github.com/kelviq/tare">kelviq/tare GitHub 仓库</a></li>
  <li><a href="https://github.com/rbartoli/agent-usage-guard">rbartoli/agent-usage-guard GitHub 仓库</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50219875">HN 50219875：Claude Code slyly adding users’ emails to outbound HTTP</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="ParadigmRadar" /><category term="agent" /><category term="claude-code" /><category term="token-usage" /><category term="cost-tracking" /><category term="opentelemetry" /><category term="harness" /><summary type="html"><![CDATA[独立取证帖实测出Claude Code后台agent状态摘要占其周消耗16.4%且不入本地账本，厂方回帖自认并给出2%到6%自述口径，窗口内五个独立计量工具仓成型：agent成本观正从标价转向请求级实测。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/paradigm-radar-agent-hidden-cost-cover.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/paradigm-radar-agent-hidden-cost-cover.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 范式雷达：《官方渠道沦陷之后》</title><link href="https://unbug.github.io/paradigm-radar-toolchain-poisoning/" rel="alternate" type="text/html" title="AI 范式雷达：《官方渠道沦陷之后》" /><published>2026-10-30T00:00:00+00:00</published><updated>2026-10-30T00:00:00+00:00</updated><id>https://unbug.github.io/paradigm-radar-toolchain-poisoning</id><content type="html" xml:base="https://unbug.github.io/paradigm-radar-toolchain-poisoning/"><![CDATA[<p>13 天内 Hacker News 出现 <code class="language-plaintext highlighter-rouge">5</code> 个 AI 工具链供应链高分事件帖（<code class="language-plaintext highlighter-rouge">976</code> 分最高，<code class="language-plaintext highlighter-rouge">2026-10-31</code> 实测）：被攻击的是开发者写代码用的 AI 工具本身，官方 Claude Code VS Code 扩展也在其中被植 SSH 后门（Phorion 公告<a href="https://phorion.io/blog/offical-claude-code-vsx-compromise/">links-1</a>）。</p>

<p>范式表述：<strong>AI 编码工具链从「可信开发环境」降级为「供应链攻击面」——攻击者从投毒你的依赖，转向投毒你用来生成代码的那个工具的分发包；供给端已经把这当作一门生意：NVIDIA、思科、微软、Cloudflare 四个官方组织在 2026 年 1-6 月密集发布 agent 技能扫描与治理仓库，OWASP GenAI Security Project 把 Agentic App Security 与 AI Bill of Materials 设为常设轨道。</strong>事件坐标：<code class="language-plaintext highlighter-rouge">OpenCode</code> 凭据泄露（<code class="language-plaintext highlighter-rouge">976</code> 分）、<code class="language-plaintext highlighter-rouge">LiteLLM</code> PyPI <code class="language-plaintext highlighter-rouge">1.107.0</code> 投毒（<code class="language-plaintext highlighter-rouge">596</code> 分）、官方 <code class="language-plaintext highlighter-rouge">Claude Code for VS Code</code> 扩展在 <code class="language-plaintext highlighter-rouge">Cursor Marketplace</code> 被植入跨平台持久化 SSH 后门（三帖 <code class="language-plaintext highlighter-rouge">645</code>/<code class="language-plaintext highlighter-rouge">396</code>/<code class="language-plaintext highlighter-rouge">377</code> 分，<code class="language-plaintext highlighter-rouge">2026-10-31</code> 实测）。本文全部数字为当日经 HN Algolia API 与 GitHub API 复测值，转述与自报口径均已标注。</p>

<p><img src="/assets/images/paradigm-radar-toolchain-poisoning-cover.svg" alt="封面：官方扩展市场与包注册表的分发管道中混入带后门的安装包" /></p>

<h2 id="13-天-5-帖官方分发渠道接连失守">13 天 5 帖：官方分发渠道接连失守</h2>

<p>时间线（分数均为 <code class="language-plaintext highlighter-rouge">2026-10-31</code> 实测）：<code class="language-plaintext highlighter-rouge">10-17</code>，AI 编码工具 OpenCode 被入侵、用户凭据泄露（HN <code class="language-plaintext highlighter-rouge">50133401</code>，<code class="language-plaintext highlighter-rouge">976</code> 分）；<code class="language-plaintext highlighter-rouge">10-21</code>，AI 网关 LiteLLM（BerriAI/litellm，<code class="language-plaintext highlighter-rouge">62,393</code> 星，实测）的 PyPI 包 <code class="language-plaintext highlighter-rouge">1.107.0</code> 被投毒，装上即带凭据窃取器与后门（HN <code class="language-plaintext highlighter-rouge">50181114</code>，<code class="language-plaintext highlighter-rouge">596</code> 分）；<code class="language-plaintext highlighter-rouge">10-30</code>，同一天三家独立披露同一事件——官方 Claude Code for VS Code 扩展在 Cursor Marketplace 的分发包被植入后门：GossiTheDog 帖 <code class="language-plaintext highlighter-rouge">645</code> 分（HN <code class="language-plaintext highlighter-rouge">50302334</code>，截至写作仍在上涨）、Phorion 公告帖 <code class="language-plaintext highlighter-rouge">377</code> 分（HN <code class="language-plaintext highlighter-rouge">50300683</code>）、DoublePulsar 帖 <code class="language-plaintext highlighter-rouge">396</code> 分（HN <code class="language-plaintext highlighter-rouge">50301983</code>）。Phorion 公告（作者 Calum Hall，<code class="language-plaintext highlighter-rouge">2026-10-30</code>）给出细节：后门跨 macOS/Linux/Windows 三平台、以 SSH 持久化；Cursor 已下架该版本并从 NPM 与 VSCode registry 拉取 <code class="language-plaintext highlighter-rouge">2.1.313</code>，公告要求排查使用该版本的环境。前史同样在堆积：<code class="language-plaintext highlighter-rouge">2026-05</code> 恶意 VSCode 扩展致 GitHub <code class="language-plaintext highlighter-rouge">3,800</code> 个仓库泄露（HN 帖 <code class="language-plaintext highlighter-rouge">1054</code> 分）、<code class="language-plaintext highlighter-rouge">2026-09</code> OpenAI agent 对 RubyGems 发起未公开攻击（<code class="language-plaintext highlighter-rouge">975</code> 分）——攻击面从包注册表蔓延到扩展市场，再到 AI 工具自己的官方分发渠道。</p>

<h2 id="供给端四家官方组织半年内造好扫描器">供给端：四家官方组织半年内造好扫描器</h2>

<p>攻击面成形的同时，防御侧供给在同一时间窗出现。GitHub API 实测（<code class="language-plaintext highlighter-rouge">2026-10-31</code>）：<code class="language-plaintext highlighter-rouge">NVIDIA/SkillSpector</code> <code class="language-plaintext highlighter-rouge">23,499</code> 星、创建于 <code class="language-plaintext highlighter-rouge">2026-03-21</code>，agent 技能安全扫描器，七个月即成赛道头部；<code class="language-plaintext highlighter-rouge">cisco-ai-defense/skill-scanner</code> <code class="language-plaintext highlighter-rouge">2,670</code> 星、创建于 <code class="language-plaintext highlighter-rouge">2026-01-29</code>；<code class="language-plaintext highlighter-rouge">microsoft/agent-governance-toolkit</code> <code class="language-plaintext highlighter-rouge">6,496</code> 星、创建于 <code class="language-plaintext highlighter-rouge">2026-03-02</code>，做策略强制、零信任身份与执行沙箱；<code class="language-plaintext highlighter-rouge">snyk/agent-scan</code> <code class="language-plaintext highlighter-rouge">3,191</code> 星。Cloudflare 官方组织也发布了面向 coding agent 的安全审计技能仓库（研究方实测 <code class="language-plaintext highlighter-rouge">53,577</code> 星，创建仅约 4 个月，该星数异常偏高，本文只作旁证、不入核心论证）。NVIDIA 的口径最具体：SkillSpector 的 README 自报——在其研究数据集的 <code class="language-plaintext highlighter-rouge">31,132</code> 个技能分析子集中，<code class="language-plaintext highlighter-rouge">26.1%</code> 含至少一个漏洞、<code class="language-plaintext highlighter-rouge">5.2%</code> 呈现可能的恶意意图（研究方自报口径，样本与判定标准由 NVIDIA 单方给出）；SkillSpector 同时是 NVIDIA Verified Skills 流水线的一环，「发布前扫描、评估并签名 agent 技能」，通过者进入 NVIDIA skills catalog（<code class="language-plaintext highlighter-rouge">NVIDIA/skills</code>，<code class="language-plaintext highlighter-rouge">3,796</code> 星，实测）。机构侧，OWASP GenAI Security Project 首页已设「Agentic App Security——保护自主 agent 与多步 AI 工作流」与「AI Bill of Materials——AI 供应链安全标准与工具」两个专项，并发布覆盖 2026 年三季度的 agent 漏洞汇编。</p>

<h2 id="反面证据进行中事件与虚胖赛道">反面证据：进行中事件与虚胖赛道</h2>

<p>三条刹车必须踩住。第一，Claude Code 扩展后门是进行中的事件：披露于 <code class="language-plaintext highlighter-rouge">2026-10-30</code> 当天，哪个 registry 先被投毒、影响面多大均未完全证实；研究方 <code class="language-plaintext highlighter-rouge">2026-10-30</code> 检索时，Anthropic 官方暂无公开的工程口径回应——市场先出事、厂商口径滞后，本身就是证据的一部分。第二，供应链恐慌并非 AI 独有：同一窗口内 eMudhra 证书机构被攻破（CA，Certificate Authority，签发数字证书的信任机构）、Binance 相关供应链事件同样拿下高分，AI 工具链只是广义供应链恐慌的一支，归因需要克制。第三，防御赛道星数虚胖：GitHub 搜索 <code class="language-plaintext highlighter-rouge">mcp security scanner</code> 返回 <code class="language-plaintext highlighter-rouge">917</code> 个仓库（研究方 <code class="language-plaintext highlighter-rouge">2026-10-30</code> 实测），结果里混着大量星数与内容不匹配的个人仓（如一个 <code class="language-plaintext highlighter-rouge">35,284</code> 星的个人技能仓），可靠信号只集中在带官方组织名的仓库上；更关键的是，尚无统一的「技能签名/注册表」标准落地——社区相关讨论最高只有 <code class="language-plaintext highlighter-rouge">49</code> 分的构想帖。所以本期结论只能写到「攻击面形成、厂商各自造轮子」，还不能写「标准波来了」。</p>

<h2 id="与第-20-期的区隔钱之外还有攻击面">与第 20 期的区隔：钱之外，还有攻击面</h2>

<p>第 20 期<a href="/paradigm-radar-agent-hidden-cost/">《标价之外，Harness 替你买了什么》</a>回答的是「工具替你花了哪些看不见的钱」，把账单当安全事件取证；本期把同一批工具放上另一条轴——「工具给你带来哪些看不见的代码」。两期共用同一个前提：AI 编码工具不是透明代理，而是一个会替你行动、也替别人留门的软件供应链。区别在失效模式：第 20 期的失效是成本泄漏，账目可查、机制已被厂方自认；本期的失效是凭据与主机沦陷，Phorion 公告里的后门直接持久化到 SSH 层。同一个 LiteLLM 在两条轴上都是主角：作为网关它值钱（<code class="language-plaintext highlighter-rouge">62,393</code> 星），作为 PyPI 包它被投毒——价值即靶子，这条规律在扩展市场、技能市场、模型注册表上正在逐字重演。</p>

<h2 id="观察点">观察点</h2>

<p>三个可复查的信号：Anthropic 是否给出扩展后门事件的官方工程复盘（研究方 <code class="language-plaintext highlighter-rouge">2026-10-30</code> 检索时仍缺位，口径出现即事件定性）；NVIDIA Verified Skills 式「扫描+签名+目录」是否从单厂流水线变成跨厂互认（无统一签名标准前，各目录互不背书即是碎片化的证据）；下一个被投毒的分发渠道是技能市场还是模型注册表——OpenCode 与 ClawHub 恶意技能帖（<code class="language-plaintext highlighter-rouge">334</code> 分）提示技能市场已在射程内。开发者侧当下可执行的动作只有一个：把 AI 工具的扩展、插件、依赖纳入与业务代码同级的供应链审查，锁定版本、核对来源。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://phorion.io/blog/offical-claude-code-vsx-compromise/">Phorion 安全公告：Official Claude Code Extension Compromise</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50133401">HN 50133401：OpenCode Hacked: User credentials leaked</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50181114">HN 50181114：Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50302334">HN 50302334：Backdoors in official Claude Code extensions</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50300683">HN 50300683：Backdoor in Claude Code for VS Code extension on the Cursor Marketplace</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50301983">HN 50301983：Claude Code VS Code extension with backdoor released on Cursor marketplace</a></li>
  <li><a href="https://github.com/NVIDIA/SkillSpector">NVIDIA/SkillSpector GitHub 仓库</a></li>
  <li><a href="https://github.com/cisco-ai-defense/skill-scanner">cisco-ai-defense/skill-scanner GitHub 仓库</a></li>
  <li><a href="https://github.com/microsoft/agent-governance-toolkit">microsoft/agent-governance-toolkit GitHub 仓库</a></li>
  <li><a href="https://github.com/NVIDIA/skills">NVIDIA/skills GitHub 仓库</a></li>
  <li><a href="https://genai.owasp.org/">OWASP GenAI Security Project</a></li>
  <li><a href="https://github.com/BerriAI/litellm">BerriAI/litellm GitHub 仓库</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="ParadigmRadar" /><category term="supply-chain" /><category term="security" /><category term="coding-agent" /><category term="vscode-extension" /><category term="pypi" /><category term="mcp" /><summary type="html"><![CDATA[13 天内 5 个高分 HN 事件实测出 AI 编码工具的官方分发渠道接连沦陷：OpenCode、LiteLLM、Claude Code 扩展遭投毒，四家官方组织同窗发布扫描与签名仓，AI 工具链正被当作供应链资产管理，防御标准尚未落地。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/paradigm-radar-toolchain-poisoning-cover.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/paradigm-radar-toolchain-poisoning-cover.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《网络排障 Agent 上场干活，考场却没人监考》</title><link href="https://unbug.github.io/innovation-brief-network-agent-testing-patents/" rel="alternate" type="text/html" title="AI 智创简报：《网络排障 Agent 上场干活，考场却没人监考》" /><published>2026-10-28T00:00:00+00:00</published><updated>2026-10-28T00:00:00+00:00</updated><id>https://unbug.github.io/innovation-brief-network-agent-testing-patents</id><content type="html" xml:base="https://unbug.github.io/innovation-brief-network-agent-testing-patents/"><![CDATA[<p>2026 年 6 月 23 日到 8 月 13 日的七周内，Cisco、Microsoft、ServiceNow、Juniper 密集授权或公开七件网络运维智能体（让大模型智能体替人排查与恢复网络故障的 AIOps Agent）专利。大厂圈住智能体直接动手改网络这层，动手前后的评测考场与行为审计仍无厂商设防。</p>

<p><img src="/assets/images/innovation-brief-network-agent-testing-patents.svg" alt="网络排障智能体专利时间轴与开源生态缺口" /></p>

<h2 id="专利信号">专利信号</h2>

<p>七件全部经 Google Patents 详情页核验，公开号、申请人与公开日逐字照录：</p>

<ul>
  <li><strong>US12701042B2</strong>，Microsoft Technology Licensing, LLC，2026-08-04 授权：系统日志加函数层级图做结构化 grounding（把事实材料喂给模型再回答），定事故根因。</li>
  <li><strong>US12665804B2</strong>，Cisco Technology, Inc.，2026-06-23 授权：从场景库实例化损伤场景，先在真实网络造故障，再考排障智能体。</li>
  <li><strong>US12705437B2</strong>，Cisco Technology, Inc.，2026-08-11 授权：智能体执行结果与用户先前脚本的执行结果对拍比较。</li>
  <li><strong>US12683886B2</strong>，Cisco Technology, Inc.，2026-07-14 授权：判定用户不满意后，据差评自动生成训练场景。</li>
  <li><strong>US12701054B2</strong>，Cisco Technology, Inc.，2026-08-04 授权：测试环境模拟损伤定 ground truth，强化学习教学。</li>
  <li><strong>US20260238551A1</strong>，ServiceNow, Inc.，2026-08-13 公开（审查中）：解决过程指标超阈值时自动拉人类坐席交接。</li>
  <li><strong>EP4548546B1</strong>，Juniper Networks, Inc.，2026-08-05 公开授权文本：性能指标时间序列建知识图谱定位根因，是非大模型路线的对照组。</li>
</ul>

<h2 id="大厂路线平台内闭环">大厂路线：平台内闭环</h2>

<p>把七件权利要求放在一起看，共同点是全部绑定自家平台：造故障要接控制器与网卡，评测要拿平台内脚本做对照，升级交接要接工单指标。智能体在平台里闭环动手，考场也握在平台自己手里，七件里没有一件把考场卖给别人。这与 <a href="/one-minute-read-paper-orca-bench-how-ready-are-language-model-agents-for-oncall/">ORCA-bench 论文</a>追问的问题同源：智能体上值班究竟行不行，目前缺的是考场，不是模型。</p>

<h2 id="三处缝隙">三处缝隙</h2>

<p><strong>第三方考场</strong>：Cisco 测试、评测、教学三件都要求可编排故障场景加 ground truth 对拍，但没有一家把这套能力卖给外部客户跑自己的智能体。开源 containerlab（<code class="language-plaintext highlighter-rouge">2,910</code> 星）可搭隔离拓扑、脚本化注入故障，个人可组「智能体考证包」：客户采购或自研的网络智能体进隔离沙场考题化跑分，交付验收报告。大厂测自己的智能体，接这单的人测所有人的智能体。</p>

<p><strong>内网只读副驾</strong>：银行、政企、医疗的网络数据出不了内网，大厂的 agentic 能力绑定自家云平台。用 netmiko（<code class="language-plaintext highlighter-rouge">4,312</code> 星）加网络配置分析工具 batfish（<code class="language-plaintext highlighter-rouge">1,515</code> 星）加本地小模型，做内网只读排障副驾，只给建议、人来执行，顺带避开自动执行类权利要求。</p>

<p><strong>行为审计回放</strong>：ServiceNow 只圈住指标超阈值拉人这一步，智能体每一步动作录像式留存、供网络变更事故定责的独立第三方审计层，七件专利无人占位，而这在路由改错的定责场景里是刚需。</p>

<h2 id="市场信号">市场信号</h2>

<p>Mordor Intelligence 口径下 AIOps 市场 2026 年 <code class="language-plaintext highlighter-rouge">189.5 亿美元</code>、2031 年 <code class="language-plaintext highlighter-rouge">377.9 亿美元</code>，2026 到 2031 年增长 <code class="language-plaintext highlighter-rouge">14.80 %</code>（另一家机构口径差异大，此处只取一家）；同页记录 ScaleOps 2026 年 3 月融资 <code class="language-plaintext highlighter-rouge">1.3 亿美元</code>、Spectro Cloud 2026 年 7 月融资 <code class="language-plaintext highlighter-rouge">1 亿美元</code>。开源侧仍在生长期：通用网络库体量很大（netmiko <code class="language-plaintext highlighter-rouge">4,312</code> 星、containerlab <code class="language-plaintext highlighter-rouge">2,910</code> 星、batfish <code class="language-plaintext highlighter-rouge">1,515</code> 星），直接竞品却稀疏：netbox-agent-compliance 仅 <code class="language-plaintext highlighter-rouge">22</code> 星、lyraios <code class="language-plaintext highlighter-rouge">137</code> 星且已停更，爱立信 2026-10-13 开源的同方向测试床还是 <code class="language-plaintext highlighter-rouge">0</code> 星（星数均为 GitHub API 实测 2026-10-28）。这与 <a href="/innovation-brief-agent-guardrail-patents/">Agent 护栏专利那篇</a>同构：大厂的权利要求停在平台边缘，考场与回放录像机是个人能接的三段生意。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://patents.google.com/patent/US12701042B2/en">Google Patents：US12701042B2 Automated root cause determination using a pre-trained generative model</a></li>
  <li><a href="https://patents.google.com/patent/US12665804B2/en">Google Patents：US12665804B2 Testing framework for language model-based computer network troubleshooting agents</a></li>
  <li><a href="https://patents.google.com/patent/US12705437B2/en">Google Patents：US12705437B2 Evaluation framework for LLM-based network troubleshooting and monitoring agents</a></li>
  <li><a href="https://patents.google.com/patent/US12683886B2/en">Google Patents：US12683886B2 Generating network scenarios to train an LLM-based network troubleshooting agent</a></li>
  <li><a href="https://patents.google.com/patent/US12701054B2/en">Google Patents：US12701054B2 Teaching LLM-based agents to troubleshoot networks using reinforcement learning</a></li>
  <li><a href="https://patents.google.com/patent/US20260238551A1/en">Google Patents：US20260238551A1 Agentic escalation for IT operations</a></li>
  <li><a href="https://patents.google.com/patent/EP4548546B1/en">Google Patents：EP4548546B1 Framework for automated application-to-network root cause analysis</a></li>
  <li><a href="https://www.mordorintelligence.com/industry-reports/aiops-market">Mordor Intelligence：AIOps Market（市场规模与融资信号，实测 2026-10-28）</a></li>
  <li><a href="https://github.com/srl-labs/containerlab">GitHub：srl-labs/containerlab（星数实测 2026-10-28）</a></li>
  <li><a href="https://github.com/ktbyers/netmiko">GitHub：ktbyers/netmiko（星数实测 2026-10-28）</a></li>
  <li><a href="https://github.com/batfish/batfish">GitHub：batfish/batfish（星数实测 2026-10-28）</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="patent" /><category term="aiops" /><category term="network-agent" /><category term="agent-evaluation" /><category term="indie" /><summary type="html"><![CDATA[2026 年 6 到 8 月七周内，Cisco、Microsoft、ServiceNow、Juniper 密集授权或公开七件网络运维智能体专利，大厂平台圈住智能体动手改网这层，第三方考场、内网只读副驾与行为审计回放是个人能接的三段。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/innovation-brief-network-agent-testing-patents.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/innovation-brief-network-agent-testing-patents.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《技能各自合规，组合就出事》</title><link href="https://unbug.github.io/one-minute-read-paper-cosa-conflict-of-skills-attack/" rel="alternate" type="text/html" title="一分钟读论文：《技能各自合规，组合就出事》" /><published>2026-10-28T00:00:00+00:00</published><updated>2026-10-28T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-cosa-conflict-of-skills-attack</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-cosa-conflict-of-skills-attack/"><![CDATA[<p>北京科技大学、中国科学院软件研究所等合作的论文<a href="https://arxiv.org/abs/2610.35082">《CoSA》</a>（arXiv:2610.35082）给 Agent Skills（可复用的技能插件）生态里的一类组合漏洞起了名字：CoS（Conflict of Skills，技能冲突，指每个技能单独检查都合规，组合使用时却违反政策）。</p>

<p>该论文全称为<a href="https://arxiv.org/abs/2610.35082">《CoSA: The Conflict of Skills Attack in Real-World LLM Agent Ecosystems》</a>，由北京科技大学、中国科学院软件研究所、中国科学院大学和 UNSW（新南威尔士大学）合作。论文的核心数字：<strong>往现有技能池里加入占原池 <code class="language-plaintext highlighter-rouge">≤5%</code> 的「局部合规」技能，<code class="language-plaintext highlighter-rouge">5 个 LLM</code> × <code class="language-plaintext highlighter-rouge">3 种 harness</code> 上的政策违规率从 <code class="language-plaintext highlighter-rouge">35.02%</code> 升到 <code class="language-plaintext highlighter-rouge">58.45%</code>，提升 <code class="language-plaintext highlighter-rouge">23.43</code> 个百分点</strong>——不改任何现有技能，也不改运行时权限。</p>

<p><img src="/assets/images/cosa-conflict-of-skills.svg" alt="政策违规率 35.02% 升至 58.45%；CoSA-Guard 把违规从 65.28% 降到 6.67%" /></p>

<h2 id="cos限制不跟着制品走">CoS：限制不跟着制品走</h2>

<p>CoS 的定义句是：为某一目的产生的制品或评估信号，在下游新用途里被复用时，没有保留该新用途所需的限制与授权。论文给的动机例子是三个各自通过安全检查的技能串联：一个查部署状态，一个收集复现故障的材料，一个执行 CI/CD 流水线里配置好的校验步骤——组合起来，Agent 就去执行了提交者包里的代码，而这次执行从未被授权。根因在于单个技能的输出会在下游被重新解释，逐个技能的静态审计看不到这一点。作者用公开技能仓库受控执行并配对单技能对照，归纳出四种复发机制。换句话说，合规在 CoS 里不是一个技能固有的属性，而是随用途漂移的状态：同一份制品、同一个「已通过检查」的信号，换一条下游链路就可能越过授权边界。审计发生在入库那一刻，风险却发生在运行时拼接的那一刻，两者的时间差正是这类漏洞藏身之处。</p>

<h2 id="cosa只加技能不动权限">CoSA：只加技能，不动权限</h2>

<p>CoSA 攻击据此构建两类「局部合规」的增量技能：capability supplementation（能力补全，补上攻击路径缺失的业务操作）与 relationship reshaping（关系重塑，改变制品交换、决策复用、目标与动作的绑定）。对照实验在 CoSA-Bench 上做：<code class="language-plaintext highlighter-rouge">288</code> 个任务，覆盖招聘、金融、IT、商业四个领域，危害类型为数据泄露、越权改状态、危险执行；任务在两池条件下配对执行，技能由模型自主选择，题目在攻击构造前就已固定。分 harness 看，OpenClaw、OpenHands、OpenCode 的违规率分别上升 <code class="language-plaintext highlighter-rouge">22.29</code>、<code class="language-plaintext highlighter-rouge">26.04</code>、<code class="language-plaintext highlighter-rouge">21.94</code> 个百分点，三个框架无一幸免。站内<a href="/one-minute-read-paper-skill-routing-collapse/">《Skill库越大agent越不翻说明书》</a>测过技能库规模带来的另一类退化，两篇合看的是同一件事：技能生态本身已是攻击面。</p>

<h2 id="守卫动作前查信息与授权">守卫：动作前查信息与授权</h2>

<p>论文同时给出轻量防御 CoSA-Guard，在 harness 层做两件事：重要动作执行前检查信息流与授权。在 OpenClaw 招聘任务、<code class="language-plaintext highlighter-rouge">5 个模型</code>上，攻击注入下的违规率从 <code class="language-plaintext highlighter-rouge">65.28%</code> 降到 <code class="language-plaintext highlighter-rouge">6.67%</code>；配对良性对照上，政策合规的任务完成率只从 <code class="language-plaintext highlighter-rouge">66.67%</code> 变为 <code class="language-plaintext highlighter-rouge">65.00%</code>，代价近乎为零。这与站内<a href="/one-minute-read-paper-option-channel-guardrail-attack/">《改一个选项的名字就能打开安全闸门》</a>形成对照：那篇证明单点守卫可被措辞绕过，这篇的守卫检查的是动作来源的依赖链，而非措辞。</p>

<p>这些数字全部来自论文自测口径，预印本尚未经同行评审，且原始技能池本身已有 <code class="language-plaintext highlighter-rouge">35.02%</code> 的基线违规率，<code class="language-plaintext highlighter-rouge">23.43</code> 个百分点是增量而非总量。方向是清楚的：对技能生态而言，逐个审计通过不等于组合使用合规。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2610.35082">CoSA: The Conflict of Skills Attack in Real-World LLM Agent Ecosystems（arXiv:2610.35082）</a></li>
  <li><a href="https://sigmir-org.github.io/CoSA">CoSA 项目主页</a></li>
  <li><a href="/one-minute-read-paper-skill-routing-collapse/">Skill库越大agent越不翻说明书（站内解读）</a></li>
  <li><a href="/one-minute-read-paper-option-channel-guardrail-attack/">改一个选项的名字就能打开安全闸门（站内解读）</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="Security" /><category term="llm" /><category term="ai-agents" /><category term="agent-skills" /><category term="security" /><summary type="html"><![CDATA[北京科技大学等机构的预印本把技能单独合规、组合违规命名为 CoS，其 CoSA 攻击只向技能池加入占原池 5% 的局部合规技能，就让 5 个模型 3 种 harness 的政策违规率从 35.02% 升至 58.45%。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/cosa-conflict-of-skills.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/cosa-conflict-of-skills.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《别替模型排答题路线》</title><link href="https://unbug.github.io/one-minute-read-paper-simple-harness-outdiagnose-rca-agents/" rel="alternate" type="text/html" title="一分钟读论文：《别替模型排答题路线》" /><published>2026-10-28T00:00:00+00:00</published><updated>2026-10-28T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-simple-harness-outdiagnose-rca-agents</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-simple-harness-outdiagnose-rca-agents/"><![CDATA[<p>北京大学与北京邮电大学的论文<a href="https://arxiv.org/abs/2610.35767">《Free to Look, Free to Reason》</a>（arXiv:2610.35767）给一个流行做法判了负分：简单 harness 的 PR@1 最高 <code class="language-plaintext highlighter-rouge">77%</code>，发表 agent 仅 <code class="language-plaintext highlighter-rouge">53%</code>。</p>

<p>论文标题全文为 Free to Look, Free to Reason: Simple LLM Harnesses Outdiagnose Hand-Crafted Root Cause Analysis Agents。这个流行做法是为根因分析（RCA，指从故障发生时的指标、日志、调用链等遥测数据里定位最初坏掉的组件）手工编排 LLM Agent。论文用三个不规定模型调用流程的简单 harness（harness 指包住模型的调用外壳：一次调用读过证据包、SQL agent、Codex coding agent），对阵五个已发表的 LLM RCA agent 和一批统计、因果方法，同台比准确率：基准 RCAtlas 由 <code class="language-plaintext highlighter-rouge">8 个公开数据集</code>拼装的 <code class="language-plaintext highlighter-rouge">90 个验证案例</code>，覆盖 <code class="language-plaintext highlighter-rouge">6 个模型</code>、<code class="language-plaintext highlighter-rouge">3 档推理努力</code>。结果：<strong>简单 harness 最准</strong>，PR@1（首个答案即命中根因的案例占比）在三个中档模型上达到 <code class="language-plaintext highlighter-rouge">65-77%</code>，高于发表 agent 的 <code class="language-plaintext highlighter-rouge">16-53%</code> 与非 LLM 方法的 <code class="language-plaintext highlighter-rouge">6-39%</code>，且在每个同时跑了两族方法的模型上全部领先。</p>

<p><img src="/assets/images/simple-harness-rca.svg" alt="三族方法在 RCAtlas 上的 PR@1 区间对比" /></p>

<h2 id="程序替模型决定读什么">程序替模型决定读什么</h2>

<p>发表 agent 的准确率落差，出在编排本身。论文统计每个方法的 prescribed-call ratio（规定调用占比，指由程序在固定节点发起、而非模型自己决定发起的模型调用比例）：五个发表 agent 把 <code class="language-plaintext highlighter-rouge">十分之一到全部</code>的模型调用写死在程序里，标准操作流程、固定阶段、角色分工各写各的；相比之下，简单 harness 把看什么、查哪条、什么时候停全部交还给模型。案例研究展示了写死的代价：当程序规定先看什么，它会跳过决定性证据，比如某一行日志，或者一个不再收到调用请求的服务。站内<a href="/one-minute-read-paper-orca-bench-how-ready-are-language-model-agents-for-oncall/">《ORCA-bench：On-Call 考验》</a>同样研究 on-call 根因分析，角度相反：那篇用生产级测试床丈量模型能力有多不够，这篇证伪的是手工编排本身带来的附加价值：编排没有把有限的能力垫高，反而把它压低了。</p>

<h2 id="模型管可靠外壳管能力">模型管可靠，外壳管能力</h2>

<p>换更强模型与多给推理预算，作用并不相同。从 Luna 到 Sol，能力分 A（三次运行都解出的案例占比）只上升 <code class="language-plaintext highlighter-rouge">2-7 个百分点</code>，不稳定分 U（有时解出、有时解不出的案例占比）却从 <code class="language-plaintext highlighter-rouge">32-36</code> 降到 <code class="language-plaintext highlighter-rouge">7-8</code>；多轮 harness 主要买能力，SQL agent 与 Codex 在 Luna 上至少解出一次的案例比一次调用多 <code class="language-plaintext highlighter-rouge">10-11 个百分点</code>。把推理努力加满，准确率只变几个点，时间最多乘以七。成本侧同样是一边倒：在准确率超过最佳非 LLM 方法（NSigma，PR@1 <code class="language-plaintext highlighter-rouge">38.9%</code>）的运行里，成本或时间 Pareto 最优的每一条都是简单 harness；七个达标的发表 agent 运行（<code class="language-plaintext highlighter-rouge">43-63%</code>）全被不更贵或不更慢的 harness 在准确率上压过。换句话说，花钱与花时间换来的最优解全部落在放任模型自己调查的一侧。</p>

<p>数字有边界：四个发表 agent 是论文按原文重新实现的，案例研究只跟了单个案例，且论文自述规定调用占比只测编排固定了多少，没有证明固定就是准确率低的直接原因；全部结果出自论文自测口径，预印本未经同行评审。站内<a href="/one-minute-read-paper-claim-smoothing-llm-research-agents/">《研究 Agent 把证据磨得太光滑》</a>从另一个角度给出同一提示：Agent 的工作流越是预先光滑，越可能漏掉它本就该看见的东西。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2610.35767">Free to Look, Free to Reason: Simple LLM Harnesses Outdiagnose Hand-Crafted Root Cause Analysis Agents（arXiv:2610.35767）</a></li>
  <li><a href="/one-minute-read-paper-orca-bench-how-ready-are-language-model-agents-for-oncall/">ORCA-bench：On-Call 考验（站内解读）</a></li>
  <li><a href="/one-minute-read-paper-claim-smoothing-llm-research-agents/">研究 Agent 把证据磨得太光滑（站内解读）</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="Engineering" /><category term="llm" /><category term="ai-agents" /><category term="root-cause-analysis" /><category term="evaluation" /><summary type="html"><![CDATA[北京大学与北京邮电大学同台对比微服务故障诊断的两条路线：不规定模型调用流程的简单 harness 在 RCAtlas 基准上 PR@1 达到 65-77%，全面超过把调查步骤写死在程序里的已发表智能体的 16-53%。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/simple-harness-rca.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/simple-harness-rca.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 范式雷达：《把 Agent 的线拉进自己的箱子》</title><link href="https://unbug.github.io/paradigm-radar-agent-gateway-layer/" rel="alternate" type="text/html" title="AI 范式雷达：《把 Agent 的线拉进自己的箱子》" /><published>2026-10-28T00:00:00+00:00</published><updated>2026-10-28T00:00:00+00:00</updated><id>https://unbug.github.io/paradigm-radar-agent-gateway-layer</id><content type="html" xml:base="https://unbug.github.io/paradigm-radar-agent-gateway-layer/"><![CDATA[<p><code class="language-plaintext highlighter-rouge">2026-10-16</code> 至 <code class="language-plaintext highlighter-rouge">10-28</code> 的十二天里，agent 与模型之间那根直连裸线在 Hacker News 上同时遭到需求、事故、命名三向挤压：自建代理主帖 <code class="language-plaintext highlighter-rouge">303</code> 分，市占头部的 LiteLLM 在 PyPI 被投毒 <code class="language-plaintext highlighter-rouge">596</code> 分，「Agent Gateway」被厂商定为品类名。</p>

<p>三向挤压的细节：个人开发者主帖「不跑自己的 LLM proxy 你怎么知道发生了什么」（HN <code class="language-plaintext highlighter-rouge">50145507</code>）拿到 <code class="language-plaintext highlighter-rouge">303</code> 分、全树 <code class="language-plaintext highlighter-rouge">219</code> 条评论；市占头部的 <code class="language-plaintext highlighter-rouge">62,195</code> 星（实测 2026-10-28）LiteLLM 在 PyPI 被投毒（HN <code class="language-plaintext highlighter-rouge">50181114</code>，<code class="language-plaintext highlighter-rouge">596</code> 分、<code class="language-plaintext highlighter-rouge">202</code> 条评论）；Maxim AI 官方博客把「Agent Gateway」定为品类名（自述）。</p>

<p>范式表述：<strong>agent 观测网关化——开发者不再接受 agent 与模型/工具之间的通信只存在于厂商后台，而是把这层流量实时收进自己运行的代理进程里，看、记、限、拦；对 agent 的信任支点正从「信平台后台」迁移为「信自己脚下的这条线」。</strong>全部数字为 <code class="language-plaintext highlighter-rouge">2026-10-28</code> 经 HN API 全树遍历与 GitHub API 实测，厂商数字标注自述。据我们观察未发现同类中文报道。</p>

<p><img src="/assets/images/agent-gateway-layer.svg" alt="窗口内证据矩阵：需求与事故两根轴热度最高，直接命名品类的帖子热度最低" /></p>

<h2 id="供给与命名">供给与命名</h2>

<p>代理层（proxy/gateway，指夹在客户端与模型 API 之间、由使用者自己运行的中转进程）不是新物：GitHub API 实测（2026-10-28）搜索总数 <code class="language-plaintext highlighter-rouge">q="llm gateway"</code> <code class="language-plaintext highlighter-rouge">11,728</code>、<code class="language-plaintext highlighter-rouge">q="ai gateway"</code> <code class="language-plaintext highlighter-rouge">19,012</code>，存量巨大。波的动作在头部换代与命名更新。<code class="language-plaintext highlighter-rouge">10-27</code>，Maxim AI 官方博客《Introducing Agent Gateway in Bifrost: One gateway for models, tools and agents》（厂商自述）把 models、tools、agents 一个网关写成品类名，并同步进 maximhq/bifrost 仓库描述（<code class="language-plaintext highlighter-rouge">9,153</code> 星，实测 2026-10-28）；该命名帖只有 <code class="language-plaintext highlighter-rouge">2</code> 分。窗口内新建同类仓星数都小：nenya <code class="language-plaintext highlighter-rouge">36</code> 星、sturnus <code class="language-plaintext highlighter-rouge">13</code> 星、Strix 供应链防火墙 <code class="language-plaintext highlighter-rouge">18</code> 星；波的形成形态是老仓上新品类词加小仓涌现。评论区同时是集市：agentsview（<code class="language-plaintext highlighter-rouge">6,289</code> 星，实测 2026-10-28，评论 <code class="language-plaintext highlighter-rouge">50147725</code> 推荐的非代理查看器路线）、nenyamy、agent-beacon、Relay 等至少六个互不隶属的新工具自荐。与第 17 期<a href="/paradigm-radar-agent-forensics-layer/">《Agent 说完不算，拿出证据》</a>的切割：那期是事后证据层，本期是实时传输层；证据层回答「它做过什么」，网关层回答「此刻这字节经过谁的手」。</p>

<h2 id="反方与边界">反方与边界</h2>

<p>需求侧最硬的对手不是厂商，是规范派。评论 <code class="language-plaintext highlighter-rouge">50151130</code> 逐字称「You don’t need a proxy to do this」，代理会把单点故障直接放进生产力线里，Codex 与 Claude Code 都输出 OTEL traces；<code class="language-plaintext highlighter-rouge">50147603</code>、<code class="language-plaintext highlighter-rouge">50152949</code> 附和。代理派的回应（评论 <code class="language-plaintext highlighter-rouge">50154093</code>）是规范落地靠 harness 自觉。更锋利的是评论 <code class="language-plaintext highlighter-rouge">50147291</code>：「imagine a world where LiteLLM and all the other LLM shovels weren’t buggy vibecoded messes」——加一层代理就是加一条供应链，<code class="language-plaintext highlighter-rouge">596</code> 分的投毒帖把这条反方变成既成事实。事故细节同样打在信任结构上：被投毒的 <code class="language-plaintext highlighter-rouge">1.107.0</code> 已从 PyPI 撤下（实测 <code class="language-plaintext highlighter-rouge">10-28</code> 最新版本 <code class="language-plaintext highlighter-rouge">1.106.5</code>），官方 issue <code class="language-plaintext highlighter-rouge">#47826</code> 记录企业版走私有 registry 分发 embargoed（受限）修复——企业通道与开源通道分裂。边界继续列开：<code class="language-plaintext highlighter-rouge">50153072</code> 与 <code class="language-plaintext highlighter-rouge">50151189</code> 质疑「自建代理=透明」的前提，代理只看到 harness 愿意给的，闭源 harness 换个子域名照样 phone home；<code class="language-plaintext highlighter-rouge">50147381</code> 称订阅制下成本监控是伪需求。</p>

<h2 id="品类成形度与观察点">品类成形度与观察点</h2>

<p>诚实信号：直接命名品类的两条（Bifrost <code class="language-plaintext highlighter-rouge">2</code> 分、Respan Rust 网关 <code class="language-plaintext highlighter-rouge">53</code> 分）热度低，高分集中在需求情绪（<code class="language-plaintext highlighter-rouge">303</code>）与事故（<code class="language-plaintext highlighter-rouge">596</code>）两根轴上——这是品类前夜形态，不是品类成熟形态。口径限定：全部星数与热度为实测 <code class="language-plaintext highlighter-rouge">2026-10-28</code>、随时间可变；Bifrost 与 agent-beacon 的定性均为厂商或作者自述口径；据我们观察未发现同类中文报道。与第 18 期<a href="/paradigm-radar-agent-daemon-sovereignty/">《当你的笔记本上住进别人家的守护进程》</a>方向正好相反：那期是驱逐别人代码常驻本机，本期是开发者亲手在脚下立一个中间件——同为「主权」叙事，动作互为镜像。实操侧窗口内已给出动作：钉住版本（pin）、发版冷却期（cooldown）、金丝雀升级。观察点：OTel GenAI 规范扩展（agent-beacon，评论 <code class="language-plaintext highlighter-rouge">50153592</code>）是否最终吃掉自建代理叙事，规范派与代理派的胜负就是下一期的选题判据。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://news.ycombinator.com/item?id=50145507">HN 50145507：不跑自己的 LLM proxy 怎么知道发生了什么</a></li>
  <li><a href="https://news.ycombinator.com/item?id=50181114">HN 50181114：LiteLLM 1.107.0 投毒版本安装凭据窃取器与后门</a></li>
  <li><a href="https://www.getmaxim.ai/bifrost/blog/introducing-agent-gateway-in-bifrost-one-gateway-for-models-tools-and-agents">Maxim AI 官方博客：Introducing Agent Gateway in Bifrost</a></li>
  <li><a href="https://github.com/BerriAI/litellm">BerriAI/litellm GitHub 仓库</a></li>
  <li><a href="https://github.com/maximhq/bifrost">maximhq/bifrost GitHub 仓库</a></li>
  <li><a href="https://github.com/BerriAI/litellm/issues/47826">LiteLLM issue #47826：企业版私有 registry 分发 embargoed 修复</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="ParadigmRadar" /><category term="agent" /><category term="llm-proxy" /><category term="ai-gateway" /><category term="litellm" /><category term="supply-chain" /><category term="observability" /><summary type="html"><![CDATA[十天窗口内自建代理需求主帖303分、承载网关层的LiteLLM遭供应链投毒主帖596分、厂商把agent gateway定为品类名：对智能体的信任支点正从厂商后台迁移到开发者自建代理进程。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/agent-gateway-layer.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/agent-gateway-layer.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry></feed>