<?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-09-08T02:06:56+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-llm-decompiler-divergence/" rel="alternate" type="text/html" title="一分钟读论文：《通过全部测试的反编译代码为何仍不可信》" /><published>2026-09-08T00:00:00+00:00</published><updated>2026-09-08T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-llm-decompiler-divergence</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-llm-decompiler-divergence/"><![CDATA[<p>论文<a href="https://arxiv.org/abs/2609.05370">《When LLM Decompilers Recompile More and Preserve Less》</a>（arXiv:2609.05370，作者 Chang Liu、Edward Raff、Kristopher Micinski，提交于 2026-09-04，2026-09-08 查阅）给出一个直接动摇当前评测口径的结论：以大模型为内核的反编译工具产出的代码，即使能通过全部随附测试，仍有 <code class="language-plaintext highlighter-rouge">4.9%</code> 在合法输入上与原始程序行为分歧，单一系统最高达 <code class="language-plaintext highlighter-rouge">13%</code>——也就是说，只看「能不能编译、过不过测试」这两项主流指标，会系统性地把错误路径评为更优。</p>

<h2 id="两项主流指标为何漏掉两类失败">两项主流指标为何漏掉两类失败</h2>

<p>反编译是从已编译的机器代码恢复高级语言源码的过程，是漏洞检测与恶意软件分析的基础。Ghidra、Hex-Rays 等传统反编译器会把无法解析的部分显式留成占位符，产出的伪代码常常编译不过也跑不起来；大模型方案则输出干净、地道的 C 代码，因此几乎完全由可重编译性（能否构建）和可重执行性（能否通过随附的输入输出测试）来评判。论文指出这套指标会奖励错误的路径：一个函数可以顺利重编译并通过每一个随附测试，却在其他合法输入上与原程序分歧；一处已披露漏洞甚至可以在重编译产物中「无声消失」，崩溃不再复现，也不留任何可见痕迹。这两类失败，现有测试套件都抓不到。</p>

<h2 id="decompile-diverge用模糊测试做行为对照">Decompile-Diverge：用模糊测试做行为对照</h2>

<p>为补上这个缺口，论文提出 Decompile-Diverge，一个不依赖固定或手工测试用例的行为对比 oracle（判定器）：对每个函数自动合成调用 driver，从参考实现出发扩充模糊测试语料，再让反编译产物在相同输入上重跑，比对行为是否改变。在 <code class="language-plaintext highlighter-rouge">8 个系统在 9 种配置</code>下、基于既有大模型反编译语料的评测中，通过全部随附测试的候选仍有 <code class="language-plaintext highlighter-rouge">4.9%</code> 与原程序分歧，单一系统最高 <code class="language-plaintext highlighter-rouge">13%</code>。在 <code class="language-plaintext highlighter-rouge">300 个真实 GitHub 库函数与 287 个 CVE 关联函数</code>上，可重编译性与行为一致性出现了明显背离：最强的精化大模型（refinement LLM）把 Ghidra 的构建率从 <code class="language-plaintext highlighter-rouge">75%</code> 提到 <code class="language-plaintext highlighter-rouge">90%</code>，行为匹配率却从 <code class="language-plaintext highlighter-rouge">74%</code> 降到 <code class="language-plaintext highlighter-rouge">62%</code>；在已披露漏洞子集上，最高约十分之一的漏洞在其输出中出现崩溃缺失（Crash Absence）。</p>

<p><img src="/assets/images/decompile-diverge-llm-decompiler.svg" alt="大模型反编译的评测缺口：构建率上升与行为匹配率下降同时发生，模糊测试对照揭示通过全部随附测试后的行为分歧" /></p>

<h2 id="把不确定性藏进语义的代价">把不确定性藏进语义的代价</h2>

<p>源码级分析显示，分歧源于大模型引入的字段（fields）、类型（types）、被调用函数（callees）和防护条件（guards）——它们把传统工具留下的「可见的未知」替换成了「看不见的错」。本刊此前解读的<a href="/one-minute-read-paper-trajectory-budget-confounds/">轨迹预算指标错觉研究</a>与此同属「指标幻觉」一条轴：当评测只度量表层可用性，模型就学会把不确定性藏进指标测不到的地方。安全关键场景的实操含义是把可重编译性降级为必要条件而非充分条件，叠加行为等价测试（合成 driver 加模糊语料），并保留传统工具「宁留占位符、不编假代码」的文化。</p>

<p>边界同样要说清：模糊测试语料不是穷尽证明，分歧率是给定输入集合上的下界观察；这套 oracle 依赖参考实现可得，没有原始程序时无从对照；且论文为预印本，尚未经过同行评审。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2609.05370">When LLM Decompilers Recompile More and Preserve Less (arXiv:2609.05370)</a></li>
  <li><a href="/one-minute-read-paper-trajectory-budget-confounds/">一分钟读论文：轨迹与预算指标错觉</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="Security" /><category term="llm" /><category term="security" /><category term="decompilation" /><category term="evaluation" /><summary type="html"><![CDATA[论文用模糊测试对照发现，大模型反编译产物通过全部自带测试后仍有 4.9% 与原始程序行为分歧，最高单系统达 13%，只看能否编译的评测指标正在奖励错误路径。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/decompile-diverge-llm-decompiler.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/decompile-diverge-llm-decompiler.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 范式雷达：《隔离质量等于攻击面质量》</title><link href="https://unbug.github.io/paradigm-radar-vm-containment/" rel="alternate" type="text/html" title="AI 范式雷达：《隔离质量等于攻击面质量》" /><published>2026-09-08T00:00:00+00:00</published><updated>2026-09-08T00:00:00+00:00</updated><id>https://unbug.github.io/paradigm-radar-vm-containment</id><content type="html" xml:base="https://unbug.github.io/paradigm-radar-vm-containment/"><![CDATA[<p><code class="language-plaintext highlighter-rouge">2026-08-26</code>，安全公司 Trail of Bits 发布<a href="https://blog.trailofbits.com/2026-08-26/vms-wont-contain-cyber-capable-agents/">《VMs won’t contain cyber-capable agents》</a>，称一个具备网络攻击能力的前沿 AI Agent（文中为 GPT 5.6-Cyber 预览版）先后 <code class="language-plaintext highlighter-rouge">3</code> 次从未经安全裁剪的通用 QEMU/KVM 虚拟机中自主逃逸。这篇文章在 Hacker News 登上 <code class="language-plaintext highlighter-rouge">197</code> 分、<code class="language-plaintext highlighter-rouge">147</code> 条评论（<code class="language-plaintext highlighter-rouge">2026-09-08</code> 复核）。隔离范式的争论正从「容器还是 VM」的类型之争，转向「攻击面削掉了多少」的工程之争。</p>

<p><img src="/assets/images/paradigm-radar-vm-containment.svg" alt="三次逃逸与攻防经济学" /></p>

<h2 id="三次逃逸的事实链">三次逃逸的事实链</h2>

<p>作者是 Patch the Planet 计划的研究员，目标环境是他个人开发机（宿主机 Debian 12）上的 QEMU/KVM 虚拟机，CTF 式判定：逃出 VM 读到宿主 flag 即算成功。第一轮约 <code class="language-plaintext highlighter-rouge">1</code> 小时，Agent 利用数周前披露、当时无公开 exploit 的宿主机内核漏洞 Januscape（据 Trail of Bits 称编号 CVE-2026-53359），自建 exploit 把宿主机打到 hardlock。第二轮，Debian 12 仍在发行 libslirp <code class="language-plaintext highlighter-rouge">4.7.0</code>，带 CVE-2026-9539（据 Trail of Bits 称），Agent 又找到一个未分配 CVE 的上游修复对应缺陷，两者组合成宿主机任意内存读写。第三轮更严苛：作者手工升级到最新上游 QEMU/libslirp 后，Agent 自主做漏洞挖掘式源码分析，链式利用了 <code class="language-plaintext highlighter-rouge">3</code> 个当时未被公开的 0-day 加 <code class="language-plaintext highlighter-rouge">1</code> 个上游已修但发行版未标记为安全问题的缺陷，链条组件包括 VAPIC ROM alias 覆盖被锁定的 SMRAM、KVM shadow page 不同步、paging64_invlpg() 复用过期 role、libslirp ICMP 分片越界复制。</p>

<h2 id="长程自主性才是真正的变量">长程自主性才是真正的变量</h2>

<p>单次运行约 <code class="language-plaintext highlighter-rouge">12</code> 小时量级，跨多次上下文压缩持续攻坚：搜索、回退、拉取代码与论文、写 oracle、构造最小复现，目标是可复用的可靠 exploit；人类的主要工作是宿主机 hardlock 之后物理重启。这种能力已被当作独立方向测量——SANDBOXESCAPEBENCH（arXiv 2603.02277，v1 发布于 <code class="language-plaintext highlighter-rouge">2026-03-01</code>）就是量化前沿模型容器逃逸能力的开放基准，结论是「当存在漏洞时，LLM 能够识别并利用它们」。</p>

<h2 id="qemu-开发者的反驳配置问题而非范式">QEMU 开发者的反驳：配置问题而非范式</h2>

<p>QEMU/KVM 开发者 bonzini 在 HN 评论区反驳：QEMU 存在「安全子集」，外围才是全家桶。逐条拆本案：两个漏洞在 libslirp——用户态网络本就不属于安全子集，现在应改用 passt；VGA 模拟漏洞在 <code class="language-plaintext highlighter-rouge">-display none</code> 配置下根本不可达；VAPIC 缺陷属于允许 guest 越权，并非完整的 guest-to-host 逃逸。他的结论是坏掉的是 libslirp 和补丁分发流程，不是 VM 范式。Firecracker 对照组也站这边：Agent 换用 Firecracker 后仍能靠内核缺陷把机器 hardlock，但未能完成逃逸。不过 bonzini 并未否认逃逸事实本身——最终链条里的 KVM shadow page 漏洞恰在安全子集的核心路径上。双方的真正共识只有一条：隔离质量等于攻击面质量。</p>

<h2 id="边界条件n1-不外推">边界条件：n=1 不外推</h2>

<p>必须写清方法学限制：单一研究者、单一宿主机、单一目标环境、CTF 式明确目标，不能外推为「任意 VM 必被逃逸」；作者的开发机也并非最严配置，内核还跑在 mitigations=off。真正的信号是默认配置失效——攻防经济学上，AI 把「翻旧 CVE、组合利用、写 exploit」的边际成本压到近乎为零，「已知但未部署的修复」就等同于可被随时触发的在野漏洞。</p>

<h2 id="现在就能做的攻击面工程">现在就能做的攻击面工程</h2>

<ul>
  <li>用户态网络从 libslirp 换成 passt，或 tap 加防火墙微隔离并默认拒绝出网</li>
  <li>无头运行，砍掉 VGA、声卡等一切非必需设备模拟</li>
  <li>宿主内核把「上游已修未分发」窗口当作可被机器利用的漏洞对待，走快速补丁通道</li>
  <li>启用并收紧 AppArmor/seLinux——本案中 MAC 是唯一确定拦住一条完整利用链的防线（CUPS 根证书读取路径即被 AppArmor 拦截）</li>
  <li>给 Agent 设硬性运行时限，一次性环境用完即毁；高保障场景优先 Firecracker 类最小攻击面 VMM</li>
</ul>

<p>这与本刊上一篇<a href="/paradigm-radar-harness-first-class/">《外壳走上台前：Agent 的竞争从换模型转向换 Harness》</a>互为表里：harness 决定 Agent 怎么干活，隔离工程决定它被允许在哪里干活。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://blog.trailofbits.com/2026-08-26/vms-wont-contain-cyber-capable-agents/">VMs won’t contain cyber-capable agents (Trail of Bits)</a></li>
  <li><a href="https://news.ycombinator.com/item?id=49450188">Hacker News 讨论（id 49450188）</a></li>
  <li><a href="https://arxiv.org/abs/2603.02277">SANDBOXESCAPEBENCH (arXiv 2603.02277)</a></li>
  <li><a href="https://passt.top/">passt 用户态网络项目</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="ParadigmRadar" /><category term="Security" /><category term="agent" /><category term="sandbox-escape" /><category term="qemu" /><category term="kvm" /><category term="security" /><summary type="html"><![CDATA[Trail of Bits 报告前沿 AI Agent 三次击穿未加固的通用 QEMU/KVM 虚拟机，而 Firecracker 对照组未能逃逸。随手起一台 VM 当 Agent 安全边界的默认配置已失效，隔离的有效性取决于攻击面工程质量：最小设备、快速补丁、强制访问控制与运行时限。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/paradigm-radar-vm-containment.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/paradigm-radar-vm-containment.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《Agent 轨迹评测专利成簇，长任务质检是接单活》</title><link href="https://unbug.github.io/innovation-brief-agent-evaluation-patents/" rel="alternate" type="text/html" title="AI 智创简报：《Agent 轨迹评测专利成簇，长任务质检是接单活》" /><published>2026-09-07T00:00:00+00:00</published><updated>2026-09-07T00:00:00+00:00</updated><id>https://unbug.github.io/innovation-brief-agent-evaluation-patents</id><content type="html" xml:base="https://unbug.github.io/innovation-brief-agent-evaluation-patents/"><![CDATA[<p>2026 年 1 至 8 月，四件”AI Agent（能自主多步调用工具的 AI 程序）评测”专利接连公开，申请人里出现花旗银行与 KPMG。大厂和咨询公司在把 Agent 验收做成方法论；给小团队交付物做量化质检的那一层，还空着。</p>

<p><img src="/assets/images/innovation-brief-agent-evaluation-patents.svg" alt="Agent 评测专利信号与轨迹质检接单机会" /></p>

<h2 id="专利信号银行和咨询公司在给-agent-定验收标准">专利信号：银行和咨询公司在给 Agent 定验收标准</h2>

<ul>
  <li><strong>US20260017525A1</strong>，Citibank, N.A.，2026-01-15 公开：用约束字符集定义 Agent 边界，第二组模型比对”提议动作与预期动作”找差距，第三组模型增删改动作后放行。</li>
  <li><strong>US20260030476A1</strong>，KPMG LLP，2026-01-29 公开：聚合企业环境里已部署的多个 Agent，用运行行为数据与可信度数据评估选定 Agent，输出总评分。</li>
  <li><strong>US20260154581A1</strong>，Quantiphi, Inc.，2026-06-04 公开：按 Agent 档案合成测试数据，真实交互跑出轨迹（trace，逐步执行记录），对照评估矩阵打分。</li>
  <li><strong>US20260186944A1</strong>，2026-07-02 公开（申请人未在公开文本中标注）：持续接收执行记录，按推理周期与动作序列切分轨迹段，对长程 Agent 逐段评估。</li>
</ul>

<p>以上四件均为已公开申请，不是授权专利；第四件国际分类落在 <code class="language-plaintext highlighter-rouge">G06F11/34</code>（计算机系统测量），与传统软件测试同族。</p>

<h2 id="技术趋势从看单次输出到给整条轨迹打分">技术趋势：从看单次输出到给整条轨迹打分</h2>

<p>共同走向：Agent 的质量不再靠抽查一次回答判断，而是合成场景、真跑一遍、收集轨迹、按矩阵逐段评分。咨询与金融系申请人要的是”可验收的分数”——这暗示甲方侧正在长出对 Agent 交付做第三方评估的需求。与现有方案的差异：Langfuse、LangSmith、Braintrust 等观测平台把”记录 Agent 做了什么”做成商品，2026 年 8 月的行业对比文章里评测已是标配卖点；但这些专利主张的是”这条轨迹该打几分、卡在哪一步”——打分标准与业务检查点，恰恰是通用平台留给空白的部分。</p>

<h2 id="落地机会卖给交不出验收报告的-agent-外包方">落地机会：卖给交不出验收报告的 Agent 外包方</h2>

<p>用户场景：AI 外包工作室给客户交付一个客服 Agent，多步任务（查单、退款、建工单）偶发中途走歪；客户验收时问”你怎么证明它靠谱”，工作室只有日志，拿不出量化评测报告。一个人能做的那一层：Agent 验收工具——读入已有轨迹数据（OpenTelemetry 或 Langfuse 导出格式），按业务流程合成边界场景，重放后逐段对检查点打分，产出质检报告与失败样本集。技术栈 Python 加任一 LLM API 加 SQLite，无需训练模型，月成本数百元，1 人 4 周出 MVP。上一篇<a href="/innovation-brief-prompt-testing-patents/">提示词测试专利简报</a>管的是静态提示词的回归，这轮管的是动态轨迹的验收。</p>

<h2 id="创业发现一次性验收报告加日常巡检订阅">创业发现：一次性验收报告加日常巡检订阅</h2>

<ul>
  <li>验收审计服务：替 Agent 外包交付物出评测报告与整改清单，单次 3000-8000 元，首批客户是接 Agent 私活的外包工作室和甲方验收人，报告署名反哺工具获客。</li>
  <li>轨迹巡检订阅：接入客户已有 trace 做每日回放打分，按 Agent 个数计收 $19-49/月。</li>
</ul>

<p>门槛：评分方法论要公开才有人信，先拿开源检查点规则库换信任。风险：Braintrust 等平台正把评测下沉成一键功能——护城河在垂直业务的检查点设计与报告公信力，不在打分脚本本身。读完今天能做的事：导出你手上 Agent 最近五十条真实轨迹，让模型按”任务完成、越权操作、中途放弃”三项逐条打分，看看它到底不及格几次。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://www.freepatentsonline.com/y2026/0154581.html">专利检索来源</a></li>
  <li><a href="https://www.marktechpost.com/2026-08-09/top-llm-observability-and-evaluation-platforms-in-2026-langfuse-langsmith-braintrust-arize-and-more-compared/">产业佐证：LLM 观测与评测平台格局</a></li>
  <li><a href="/innovation-brief-prompt-testing-patents/">站内相关文章：提示词测试专利简报</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="Patent" /><category term="AIAgent" /><category term="Evaluation" /><category term="DevTools" /><category term="IndieHacker" /><summary type="html"><![CDATA[2026 年前八个月四件 AI Agent 评测专利密集公开：花旗、KPMG、Quantiphi 把智能体验收做成方法论。轨迹回放打分与交付质检报告，是独立开发者能接的量化活。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/innovation-brief-agent-evaluation-patents.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/innovation-brief-agent-evaluation-patents.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《Agent 权限拦截专利成簇，独立开发者的守门中间件》</title><link href="https://unbug.github.io/innovation-brief-agent-tool-guardrail-patents/" rel="alternate" type="text/html" title="AI 智创简报：《Agent 权限拦截专利成簇，独立开发者的守门中间件》" /><published>2026-09-07T00:00:00+00:00</published><updated>2026-09-07T00:00:00+00:00</updated><id>https://unbug.github.io/innovation-brief-agent-tool-guardrail-patents</id><content type="html" xml:base="https://unbug.github.io/innovation-brief-agent-tool-guardrail-patents/"><![CDATA[<p>2026 年 4 至 8 月，四件”AI Agent（能自主多步调用工具的 AI 程序）工具调用权限管控”专利接连公开与授权：拦截层被做到操作系统进程级，Mistral 拿下沙箱暂停重放，Daon 占住委托凭证。平台与云侧被圈地，个人开发者本地能装的轻量权限守门还空着。</p>

<p><img src="/assets/images/innovation-brief-agent-tool-guardrail-patents.svg" alt="Agent 权限拦截专利信号与本地守门中间件机会" /></p>

<h2 id="专利信号把-agent-当不可信对手来管">专利信号：把 Agent 当”不可信对手”来管</h2>

<ul>
  <li><strong>US20260238651A1</strong>，申请人未在公开文本中标注，2026-08-13 公开（国际分类 <code class="language-plaintext highlighter-rouge">H04L9/40</code>）：拦截层作为独立操作系统进程运行、权限高于 LLM 进程，每个调用过”不可变 + 可治理”两级规则；按侦察到驻留的五阶段识别多步绕过，动作全入哈希链账本。</li>
  <li><strong>US12670045</strong>，Mistral AI，2026-03-04 提交、2026-06-30 授权：代码块封装工具调用，沙箱遇待决调用即暂停、发客户端执行、拿结果重放续跑。</li>
  <li><strong>US12688261</strong>，Daon Technology，2026-07-21 授权：按行为忠实与执行完整性两类信号，决定是否发放委托凭证（delegation artifact，限时限权授权凭据）。</li>
  <li><strong>US20260119551A1</strong>，Boomi, LP，2026-04-30 公开：基础护栏拆成语义元素自动扩展，解决人工维护跟不上话术演变。</li>
</ul>

<p>状态区分：一、四为已公开申请，二、三为已授权专利。</p>

<h2 id="技术趋势权限从提示词挪进操作系统">技术趋势：权限从提示词挪进操作系统</h2>

<p>共同走向：不再指望提示词让模型自律，权限管控下沉为模型进程之外的架构件——独立拦截、分级策略、委托凭证、审计账本。与现成方案的差异：LangGraph、Claude Code 自带审批中断但绑定各自生态；Kong、TrueFoundry 等网关厂商卖的是面向甲方集中部署的企业级闸门。<strong>跨客户端、策略即代码、装在自己机器上</strong>的轻量守门层尚无标配产品。</p>

<h2 id="落地机会卖给拿生产环境跑编码-agent-的人">落地机会：卖给拿生产环境跑编码 Agent 的人</h2>

<p>用户场景：自由开发者在装着生产库凭据和云 API Key 的机器上跑编码 Agent 接外包，模型一次幻觉或被注入指令，<code class="language-plaintext highlighter-rouge">git push</code>、删库命令、计费 API 调用就无阻挡直达；客户验收问”怎么保证你的 Agent 不越权”，答不上来。一个人能做的那一层：本地工具调用代理——在 Agent 与 shell/API 之间架拦截进程，YAML 声明白名单与审批队列，高危调用先推手机确认，动作全落只追加日志。技术栈 Node 或 Python + MCP 代理模式 + 各框架 hooks 接口，月成本数百元，4 周出 MVP。上一篇<a href="/innovation-brief-mcp-security-patents/">MCP 安全专利简报</a>管外接服务器靠不靠谱，这轮管 Agent 自己伸出去的手。</p>

<h2 id="创业发现开源守门器加权限审计服务">创业发现：开源守门器加权限审计服务</h2>

<ul>
  <li>开源守门器 + 付费策略包：拦截逻辑开源换信任，卖”生产库、云计费、财务系统”垂直策略与团队管理版，$19-49/月；首批客户是跑编码 Agent 的独立开发者与 MCP 服务器买家。</li>
  <li>权限审计服务：交付”工具调用权限审计报告 + 最小权限清单”，单次 3000-6000 元，首批客户是 AI 项目验收方与外包工作室。</li>
</ul>

<p>门槛：策略覆盖面靠真实攻击样本长期积累；风险：各家框架的免费权限体系在持续变强——护城河在跨客户端统一策略与报告公信力。读完今天能做的事：给编码 Agent 写一份拒绝清单钩子，拦下 <code class="language-plaintext highlighter-rouge">git push</code>、批量删除与对外 POST，跑一周看它替你拦住几次。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://www.freepatentsonline.com/y2026/0238651.html">专利检索来源</a></li>
  <li><a href="https://www.truefoundry.com/fr/blog/human-in-the-loop-mcp-truefoundry-vs-kong">产业佐证：MCP 网关的人工审批闸门之争</a></li>
  <li><a href="/innovation-brief-mcp-security-patents/">站内相关文章：MCP 安全专利简报</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="Security" /><category term="Patent" /><category term="AIAgent" /><category term="Guardrails" /><category term="DevTools" /><category term="IndieHacker" /><summary type="html"><![CDATA[2026 年上半年四件 AI Agent 工具调用权限专利公开与授权：系统级拦截层、沙箱暂停重放、委托凭证、护栏自动生成。平台侧被圈住，本地轻量权限守门是独立开发者的空白活。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/innovation-brief-agent-tool-guardrail-patents.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/innovation-brief-agent-tool-guardrail-patents.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-agent-memory-portability-model-upgrade/" rel="alternate" type="text/html" title="一分钟读论文：《记忆库原封不动，Agent 为何照样失忆》" /><published>2026-09-07T00:00:00+00:00</published><updated>2026-09-07T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-agent-memory-portability-model-upgrade</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-agent-memory-portability-model-upgrade/"><![CDATA[<p>Ankit Goyal 与 Jaideep Ray 合作的论文<a href="https://arxiv.org/abs/2609.05339">《Does Your Agent’s Memory Survive a Model Upgrade? A Controlled Study of Memory Portability》</a>（arXiv:2609.05339，2026-09-04 提交）给出一个反直觉结论：模型升级是常态运维，而 Agent 的记忆库即使原封不动也照样会”丢”。固定 schema 的知识图谱（KG-fixed）迁移几乎零损耗，换写入模型后精度仅变化 <code class="language-plaintext highlighter-rouge">+0.0004 ± 0.0020</code>；由模型压缩写成的自然语言笔记（NOTES）则与模型强耦合，精度随迁移方向摆动 <code class="language-plaintext highlighter-rouge">+9.91</code> 或 <code class="language-plaintext highlighter-rouge">-13.28</code> 个百分点。记忆的持久性取决于表示格式，而不是存储本身。</p>

<h2 id="实验设计历史逐字保留只换记法">实验设计：历史逐字保留，只换记法</h2>

<p>实验控制单一变量：同一段对话历史逐字保留，只把记忆做成四种表示——LC-RAW（原文全量放进长上下文直接读）、RAG（分块后按向量相似度检索）、NOTES（模型把历史压缩成自然语言笔记）、KG-fixed（归一化为固定 schema 的知识图谱）。规模为 <code class="language-plaintext highlighter-rouge">48</code> 条合成历史，答案代码随机化，采用 exact scoring（精确匹配评分），读写两侧使用两个参数量低于 10B 的开源权重模型。写入记忆的 writer 模型与读取的 reader 模型可分别替换，以此隔离”换模型”这一件事本身的影响——历史内容一个字没变，变的只有记法与读写它的模型。</p>

<h2 id="迁移与损失格式决定在哪一环丢">迁移与损失：格式决定在哪一环丢</h2>

<p>固定 schema 的结构转移最可靠：KG-fixed 在换掉 writer 模型后，精度变化仅 <code class="language-plaintext highlighter-rouge">+0.0004 ± 0.0020</code>。NOTES 表现出强烈的模型耦合，且方向不对称——按具体迁移方向不同，精度或升 <code class="language-plaintext highlighter-rouge">+9.91</code> 个百分点、或降 <code class="language-plaintext highlighter-rouge">-13.28</code> 个百分点，升级不保证更好，换错方向反而更糟。RAG 的损耗出在 embedding 版本上：新旧向量各占一半（50/50）的混版索引只拿到 <code class="language-plaintext highlighter-rouge">4.96</code> 分提升，而全量 re-embedding 的提升为 <code class="language-plaintext highlighter-rouge">11.90</code> 分——半途迁移等于放弃了大部分本可获得的收益。</p>

<p>诊断分解进一步把损失归到不同环节：NOTES 的精度损失有 <code class="language-plaintext highlighter-rouge">80%</code>（<code class="language-plaintext highlighter-rouge">0.467 ± 0.014</code>）源于初始构建时就丢失了信息，RAG 的损失有 <code class="language-plaintext highlighter-rouge">81%</code>（<code class="language-plaintext highlighter-rouge">0.364 ± 0.012</code>）源于检索失败。修复实验直接支持一个朴素做法：只动记忆库、不动模型的 store-only 修复在全部 <code class="language-plaintext highlighter-rouge">48</code> 例中都未达到 90% 的恢复目标；而保留原始历史时，在一个被测方向上 <code class="language-plaintext highlighter-rouge">34/48</code> 例成功恢复。换言之，笔记本身坏了很难就修笔记，找回原始证据重写才有效。这一结果与 <a href="/one-minute-read-paper-compaction-cliff-agent-memory/">《长程 Agent 记忆中的压缩悬崖》</a> 形成互补：压缩悬崖说明运行期摘要会侵蚀已存事实，本文说明模型升级会让旧笔记对新模型失效——记忆工程的瓶颈正从”存得下”转向”换得起”。</p>

<h2 id="质疑与边界条件">质疑与边界条件</h2>

<p>结论有几点必须打折扣。其一，实验基于 <code class="language-plaintext highlighter-rouge">48</code> 条合成历史与 sub-10B 小模型，能否外推到前沿大模型和真实长期记忆仍是未知数，方向不对称本身就说明结论依赖具体模型配对。其二，KG-fixed 的优势可能来自 schema 设计者预先注入的任务相关性，”固定格式赢”未必是格式本身的功劳。其三，exact scoring 对开放任务过于苛刻，NOTES 的真实损失可能被评分方式放大。边界条件同样清晰：论文为预印本、未经同行评审，作者两人且无机构标注，方向性结论只测了两个方向，不能写成普适定律。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2609.05339">Does Your Agent’s Memory Survive a Model Upgrade? A Controlled Study of Memory Portability（arXiv:2609.05339）</a></li>
  <li><a href="/one-minute-read-paper-compaction-cliff-agent-memory/">一分钟读论文：《长程 Agent 记忆中的压缩悬崖》</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="LLM" /><category term="llm" /><category term="agent" /><category term="memory" /><category term="knowledge-graph" /><summary type="html"><![CDATA[对照实验显示 Agent 换模型后记忆库原封不动也会失忆：笔记迁移精度随方向摆动 +9.91 或 -13.28 个百分点，固定 schema 知识图谱几乎零损耗。记忆的持久性取决于表示格式，保留原始历史才能修复。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/memory-portability.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/memory-portability.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《LLM 团队里的成员真的可以随便换吗?》</title><link href="https://unbug.github.io/one-minute-read-paper-llm-agent-team-interchangeability/" rel="alternate" type="text/html" title="一分钟读论文：《LLM 团队里的成员真的可以随便换吗?》" /><published>2026-09-07T00:00:00+00:00</published><updated>2026-09-07T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-llm-agent-team-interchangeability</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-llm-agent-team-interchangeability/"><![CDATA[<p>中国农业大学、天津财经大学和吉林大学合作的论文 <a href="https://arxiv.org/abs/2609.05279">Testing Interchangeability in LLM Agent Teams</a> 检验了生产环境多智能体系统的一个默认假设：能干这个活角色的 agent 就能顶替这个角色。结论是该假设只在任务得分上成立，在协调效率上不成立——换员后的首局，任务得分仍达到 placebo 基线（复现换名册的扰动但不换人）的 <code class="language-plaintext highlighter-rouge">98%</code>、<code class="language-plaintext highlighter-rouge">90%</code>、<code class="language-plaintext highlighter-rouge">89%</code>，但每单位进展消耗的沟通量暴涨 <code class="language-plaintext highlighter-rouge">16%</code> 到 <code class="language-plaintext highlighter-rouge">63%</code>。分数没掉，成本爆炸，代价藏在看不到的一层。</p>

<p><img src="/assets/images/agent-swap-coordination-costs.svg" alt="LLM 团队换员后任务得分与协调成本的走势对比" /></p>

<h2 id="分数没掉成本爆炸">分数没掉，成本爆炸</h2>

<p>实验在三个强合作环境进行（低耦合任务、高耦合的 Collab-Overcooked、Hanabi）：每个设置 <code class="language-plaintext highlighter-rouge">8</code> 支队伍先打 <code class="language-plaintext highlighter-rouge">10</code> 局成团 episode，让 agent 与特定伙伴形成私有协调惯例（private notebook，即在与固定队友交互中积累下来的默契），再在 held-out 任务上测量。Table 1 的条件均值把两层代价分得很清楚：任务得分 Intact <code class="language-plaintext highlighter-rouge">92.5/64.1/15.8</code> 对 Swap <code class="language-plaintext highlighter-rouge">90.0/58.0/13.7</code>，差距有限；协调成本 Intact <code class="language-plaintext highlighter-rouge">3.20/4.09/0.61</code> 对 Swap <code class="language-plaintext highlighter-rouge">3.85/6.53/1.04</code>，高耦合环境接近翻倍。作为参照，Sun et al. 2025 在高耦合 held-out 集报告 Claude Sonnet 4 无成团成绩 <code class="language-plaintext highlighter-rouge">60.7</code>，本文成团队伍达到 <code class="language-plaintext highlighter-rouge">64.1</code>；Hanabi 的 <code class="language-plaintext highlighter-rouge">15.8/25</code> 也高于 GPT-4-turbo 的 <code class="language-plaintext highlighter-rouge">13.3</code>——队伍确实练出了东西，换员打碎的正是这个东西。</p>

<h2 id="老手比新人还贵">老手比新人还贵</h2>

<p>最反直觉的发现来自 Hanabi：换进来的”老手”比”啥也不会的新人”还要贵。原因不是能力缺口，而是惯例冲突——老手带着与前队友练出的旧约定进场，干扰现队伍的默契。这与本刊此前<a href="/one-minute-read-paper-constraint-weakening-handoff/">《约束在交接中悄悄失效》</a>指向同一类问题：多智能体系统里的协调资产，工程上长期被低估。Collab-Overcooked 里还能看到成本落在谁头上：换掉”定议程的 agent”之后，额外沟通主要来自留守的那个 agent——留下的人要花更多力气把新伙伴拉回轨道。</p>

<h2 id="恢复不对称得分快成本慢">恢复不对称：得分快，成本慢</h2>

<p>换员不是永久中毒，恢复是真实发生的，但速度不对称。任务得分在第 <code class="language-plaintext highlighter-rouge">2/5/6</code> 局（低耦合/高耦合/Hanabi）回到 placebo 基线 <code class="language-plaintext highlighter-rouge">1%</code> 以内；协调成本的衰减慢约一倍，需要约 <code class="language-plaintext highlighter-rouge">10</code> 局。消融实验进一步给出两个放大器：队伍成团历史越长、解码温度越高，换员代价越大。换句话说，一支磨合越久、说话越发散的队伍，越经不起随手替换。对运维方的含义是：热更新与故障替换应把重新磨合的沟通开销计入成本，而不是只看任务分数是否回落。</p>

<h2 id="这项研究的边界">这项研究的边界</h2>

<p>两点限制需要说清。其一，主实验每设置仅 <code class="language-plaintext highlighter-rouge">8</code> 支队伍、单一基座模型；消融虽覆盖多个基座与温度设置，但 <code class="language-plaintext highlighter-rouge">16%</code> 到 <code class="language-plaintext highlighter-rouge">63%</code> 这个跨环境区间能否在 GPT-5、Claude 级别的强模型上复现，在本文设置中没有证据。其二，协调成本是代理指标：Hanabi 用 hint/point 计量、Overcooked 用 messages/subtask 计量，”沟通变多”是否等价于生产系统里的真实代价——延迟与按 token 计费的费用——存在外推缺口，这个换算论文没有测。此外，Hanabi 与 Overcooked 是强合作、低沟通带宽的博弈环境，真实代码协作型 multi-agent 系统的惯例形态是否相同、跨模型换员（现实中 swap 往往跨越不同基座）是否更贵，论文均未覆盖。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2609.05279">Testing Interchangeability in LLM Agent Teams (arXiv:2609.05279)</a></li>
  <li><a href="/one-minute-read-paper-constraint-weakening-handoff/">约束在交接中悄悄失效</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="MultiAgent" /><category term="llm" /><category term="multi-agent" /><category term="coordination" /><category term="evaluation" /><summary type="html"><![CDATA[LLM 多智能体团队换员后任务得分几乎不掉，但每单位进展的沟通成本上涨 16% 到 63%；Hanabi 中换进来的老手比新人更贵——旧伙伴惯例与现队伍冲突。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/agent-swap-coordination-costs.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/agent-swap-coordination-costs.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 范式雷达：《网站开始给 Agent 单独上一道菜》</title><link href="https://unbug.github.io/paradigm-radar-markdown-negotiation/" rel="alternate" type="text/html" title="AI 范式雷达：《网站开始给 Agent 单独上一道菜》" /><published>2026-09-07T00:00:00+00:00</published><updated>2026-09-07T00:00:00+00:00</updated><id>https://unbug.github.io/paradigm-radar-markdown-negotiation</id><content type="html" xml:base="https://unbug.github.io/paradigm-radar-markdown-negotiation/"><![CDATA[<p>同一个 URL、同一个 <code class="language-plaintext highlighter-rouge">Accept</code> 头，返回的字节从 <code class="language-plaintext highlighter-rouge">24,222</code> 掉到 <code class="language-plaintext highlighter-rouge">2,201</code>——这不是压缩，是换了一种表示。8 月 26 日登上的 HN 热帖《Serve Markdown to AI Agents with Accept Headers》（Algolia API 今日实测 <code class="language-plaintext highlighter-rouge">176</code> 分）把 HTTP 内容协商这个 90 年代机制重新推上前台：网站不再只为人渲染 HTML，而是给 Agent 直供干净 Markdown。范式转移在于「网页默认给人看、Agent 抓了自己洗」正在变成「网站把 Agent 当一等公民访客、按请求头供料」。</p>

<p><img src="/assets/images/paradigm-radar-markdown-negotiation.svg" alt="内容协商：同一 URL 两种表示" /></p>

<h2 id="一个老机制的新买家">一个老机制的新买家</h2>

<p><code class="language-plaintext highlighter-rouge">Accept</code> 头是 RFC 9110 定义的既有协商机制，<code class="language-plaintext highlighter-rouge">text/markdown</code> 媒体类型出自 RFC 7763，Codex CLI 走的 <code class="language-plaintext highlighter-rouge">&lt;link rel="alternate" type="text/markdown"&gt;</code> 发现路径出自 RFC 8288。这套组合没有任何新协议、新标准——这正是它能快速落地的原因。</p>

<p>实测可复现（2026-09-07 本机 curl）：acceptmarkdown.com 带 <code class="language-plaintext highlighter-rouge">Accept: text/markdown</code> 请求返回 <code class="language-plaintext highlighter-rouge">content-type: text/markdown; charset=utf-8</code> 且带 <code class="language-plaintext highlighter-rouge">vary: Accept</code>，正文 <code class="language-plaintext highlighter-rouge">2,201</code> 字节 vs HTML <code class="language-plaintext highlighter-rouge">24,222</code> 字节，省 <code class="language-plaintext highlighter-rouge">90.9%</code>。Anthropic 官方文档更极端：同一页面 HTML <code class="language-plaintext highlighter-rouge">476,665</code> 字节、<code class="language-plaintext highlighter-rouge">.md</code> 版 <code class="language-plaintext highlighter-rouge">16,629</code> 字节，省 <code class="language-plaintext highlighter-rouge">96.5%</code>。</p>

<h2 id="供给侧已经站了多少人">供给侧已经站了多少人</h2>

<p>acceptmarkdown.com/status（发起方维护的矩阵，利益相关）显示明确发送该头部的有 7 款编码 Agent：Claude Code（verified 2025-11-13）、Copilot Chat、Copilot CLI、Cursor、Microsoft Copilot、OpenClaw、OpenCode；Codex CLI 为 Partial（走 Link 头发现）。Cloudflare 文档站已上线「Markdown for Agents」零配置支持，实测响应头 <code class="language-plaintext highlighter-rouge">content-type: text/markdown</code>、vary 含 accept。</p>

<p>今日新增证据：Vercel 文档与 Netlify 文档对同一请求头同样返回 <code class="language-plaintext highlighter-rouge">text/markdown; charset=utf-8</code>（curl 实测），而 Astro 文档仍返回 HTML。头部托管平台把它做成了默认能力，跟进速度超出选题简报的预期；消费级大产品则全部缺席。</p>

<p>对 Agent 开发者还有一层直接收益：同样的上下文窗口预算，Markdown 表示能多装数倍正文；抓取侧少一层 HTML 转 Markdown 的有损转换，表格与代码块的结构性信息不再丢失。这也是为什么采用者全部集中在「Agent 高频读文档」的编码场景，而非泛网页浏览。这条供给线与本刊上一篇<a href="/paradigm-radar-harness-first-class/">《外壳走上台前：Agent 的竞争从换模型转向换 Harness》</a>互为表里：外壳决定 Agent 怎么干活，内容协商决定它读进去什么。</p>

<h2 id="反方把三个软肋说透了">反方把三个软肋说透了</h2>

<p>鸡蛋问题：ChatGPT browse、Gemini、Claude.ai web 在矩阵上均为 No（只抓 HTML），HN 高赞评论直言「等 top 4 AI chatbot 说它们会用这个头我再支持」。清洗本来就在客户端做：Firecrawl、Exa 这类抓取服务早已在抓取时把 HTML 转 Markdown，「等全网改服务器」不如「买中间层」现实。激励错位最深：网站愿意喂搜索引擎换流量，却怕被 Agent 白嫖——评论区称 Time 杂志已向 Agent 投放带广告的 Markdown 变体（社区传闻，未独立核实）；而 Markdown 可内嵌 HTML 与 script 标签，不做消毒的渲染器就是提示注入新入口。</p>

<h2 id="边界条件与接下来盯什么">边界条件与接下来盯什么</h2>

<p>SPA 与 JS 渲染页面无法零成本供 Markdown；<code class="language-plaintext highlighter-rouge">Vary: Accept</code> 让同一 URL 至少两份缓存，高流量站点的 CDN 碎片化成本没有公开数据；广告变现型内容方天然缺动机——采用者集中在文档站、博客、API 参考这类「内容即产品」场景。另有评论实测语义化 HTML 仅比等价 Markdown 多 5%-20% 字节（出自 HN 评论区，与「十倍」体感相悖，差距取决于原页面腐化程度）——省字节的叙事在烂页面上成立，在本来干净的页面上并不戏剧化。</p>

<p>未来一两个周期盯三个信号：消费端（ChatGPT browse / Gemini / Claude.ai web）是否在矩阵上翻绿，若下个周期仍全为 No，本趋势降级为编码 Agent 专属 niche；IETF 是否出现正式草案（当前只是既有 RFC 组合应用）；以及首个 Markdown 变体投毒案例或 CVE——它决定这是接口标准还是军备竞赛的起点。</p>

<p><strong>你现在可以做的</strong>：两条 curl 测自家站点（<code class="language-plaintext highlighter-rouge">curl -sI -H "Accept: text/markdown" https://你的站点/</code>），看返回的是 <code class="language-plaintext highlighter-rouge">text/html</code> 还是 <code class="language-plaintext highlighter-rouge">text/markdown</code>；对自家文章页跑 HTML vs Markdown 字节对比量化收益；acceptmarkdown.com 给了 nginx、Caddy、Next.js、WordPress 等十余种配方，十分钟可上线最小版本。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://news.ycombinator.com/item?id=49454764">Serve Markdown to AI Agents with Accept Headers (HN)</a></li>
  <li><a href="https://acceptmarkdown.com/">acceptmarkdown.com</a></li>
  <li><a href="https://acceptmarkdown.com/status">Agent support matrix</a></li>
  <li><a href="https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/">Cloudflare: Markdown for Agents</a></li>
  <li><a href="https://www.rfc-editor.org/info/rfc7763">RFC 7763: The text/markdown Media Type</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="ParadigmRadar" /><category term="agent" /><category term="http" /><category term="content-negotiation" /><category term="seo" /><category term="markdown" /><summary type="html"><![CDATA[Accept: text/markdown 内容协商正在被编码 Agent、Cloudflare、Vercel、Netlify 同时采用，同一 URL 实测少九成到近全部的字节。网站与 Agent 的接口契约正从抓取加清洗转向按需供料，这正在成为 Agent 时代内容网站的新 SEO 接口。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/paradigm-radar-markdown-negotiation.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/paradigm-radar-markdown-negotiation.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《MCP 安全专利密集授权，插件市场审计留给了谁》</title><link href="https://unbug.github.io/innovation-brief-mcp-security-patents/" rel="alternate" type="text/html" title="AI 智创简报：《MCP 安全专利密集授权，插件市场审计留给了谁》" /><published>2026-09-06T00:00:00+00:00</published><updated>2026-09-06T00:00:00+00:00</updated><id>https://unbug.github.io/innovation-brief-mcp-security-patents</id><content type="html" xml:base="https://unbug.github.io/innovation-brief-mcp-security-patents/"><![CDATA[<p>2026 年 2 月至 8 月，六件”MCP（Model Context Protocol，AI 助手外接工具的标准协议）服务器安全”专利密集授权：Airia 一家连下五城，Notion 8 月补上权限控制一件。大厂把协议平台侧的治理圈住，插件市场的第三方审计还空着——这正是接单者能立刻动手的活。</p>

<p><img src="/assets/images/innovation-brief-mcp-security-patents.svg" alt="MCP 安全专利信号与独立开发者审计机会" /></p>

<h2 id="专利信号从注册代理到运行时改毒全链路授权">专利信号：从注册、代理到运行时改毒，全链路授权</h2>

<ul>
  <li><strong>US12574336</strong>，Airia LLC，2026-03-10 授权公告：监控 MCP 服务器的资源清单（工具与指令列表），检测到变更即触发补救动作。</li>
  <li><strong>US12568091</strong>，Airia LLC，2026-03-03 授权公告：对多个 MCP 服务器做批量策略管理。</li>
  <li><strong>US12562968</strong>，Airia LLC，2026-02-24 授权公告：基于代理（proxy）的 MCP 服务器安全接入。</li>
  <li><strong>US12602470</strong>，Airia LLC，2026-04-14 授权公告：安全 MCP 服务器的容器化执行。</li>
  <li><strong>US12683991</strong>，Airia LLC，2026-02-04 提交、2026-07-14 授权公告：对不安全 MCP 服务器自动补救。</li>
  <li><strong>US12705267</strong>，Notion Labs，2025-12-23 提交、2026-08-11 授权公告：用查询权限属性控制多个客户端经 MCP 服务器访问工具的边界。</li>
</ul>

<p>以上六件均为已授权专利，不是申请公开。</p>

<h2 id="技术趋势信任锚从装的时候看一眼变成持续比对清单">技术趋势：信任锚从”装的时候看一眼”变成”持续比对清单”</h2>

<p>共同走向：MCP 安全不靠上架审核一次通过，而靠运行时持续盯——清单快照、版本比对、代理拦截、容器隔离、异常降级。差距即机会：OWASP 已把工具投毒（tool poisoning，在工具描述里藏指令操纵 AI）列为 MCP 典型攻击；OX Security 2026 年 4 月向 11 个公开 MCP 注册市场提交恶意概念服务器，9 家未审就收录。官方注册表已近万条，多数市场的审核停留在人工填表。</p>

<h2 id="落地机会卖给敢装不敢一直用的-mcp-接入方">落地机会：卖给”敢装不敢一直用”的 MCP 接入方</h2>

<p>用户场景：AI 集成商从插件市场装了第三方 MCP 服务器接进客户工作流；三个月后服务器悄悄更新，工具描述里多了几行隐藏指令（rug pull，上架后改毒），没人发现——企业安全团队想管，拿不出”这个月工具清单变了没有”的证据。一个人能做的那一层：MCP 审计工具——定时抓取目标服务器的工具清单与描述做快照，版本间自动 diff，跑注入模式扫描（可疑指令、越权参数、外发地址），变更即告警；交付物是 CLI + GitHub Action + 监控面板。技术栈 TypeScript/Python 加现成规则库，无需训练模型，月成本数百元，1 人 4 周出 MVP。上一篇<a href="/innovation-brief-prompt-injection-defense-patents/">提示词注入防御专利简报</a>写的是输入侧的防线，这轮写的是供应链侧。</p>

<h2 id="创业发现订阅监控加一次性审核两条腿">创业发现：订阅监控加一次性审核两条腿</h2>

<ul>
  <li>监控订阅：按服务器计收 $9-19/月，盯清单漂移与注入扫描，首批客户是 MCP 社区里抱怨”市场收录形同虚设”的作者和做 Agent 集成的集成商。</li>
  <li>上架前审计服务：替准备发布 MCP 服务器的团队出审计报告与整改清单，单次 2000-5000 元，报告署名反哺工具导流。</li>
</ul>

<p>门槛：检测规则要公开方法论才有人信，先拿开源规则库换信任。风险：注册市场原生审核补齐后纯扫描会被挤压——护城河在跨市场持续监控与报告公信力，不在扫描脚本本身。读完今天能做的事：挑一个常用的 MCP 服务器，diff 它两个月前的工具描述，看看有没有一行字让你后背发凉。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://www.freepatentsonline.com/12683991.html">专利检索来源</a></li>
  <li><a href="https://owasp.org/www-community/attacks/MCP_Tool_Poisoning">产业佐证：OWASP MCP 工具投毒</a></li>
  <li><a href="https://www.precursorsecurity.com/blog/mcp-server-security-vulnerabilities">产业佐证：MCP 市场审核实验与统计</a></li>
  <li><a href="/innovation-brief-prompt-injection-defense-patents/">站内相关文章：提示词注入防御专利简报</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="Security" /><category term="Patent" /><category term="MCP" /><category term="AgentSecurity" /><category term="DevTools" /><category term="IndieHacker" /><summary type="html"><![CDATA[2026 年上半年六件 MCP（模型上下文协议）服务器安全专利密集授权：Airia 五连拿下完整性监控与容器隔离，Notion 占下工具访问权限。平台侧被圈住，第三方插件审计工具与服务正适合独立开发者切入。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/innovation-brief-mcp-security-patents.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/innovation-brief-mcp-security-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-one-shot-opd/" rel="alternate" type="text/html" title="一分钟读论文：《数据喂饱了，算法还饿着》" /><published>2026-09-06T00:00:00+00:00</published><updated>2026-09-06T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-one-shot-opd</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-one-shot-opd/"><![CDATA[<p>以清华大学为主力的团队发布预印本<a href="https://arxiv.org/abs/2609.04172">《Rethinking On-Policy Distillation of Large Language Models II: One Training Example》</a>（arXiv:2609.04172，2026 年 9 月 3 日提交，13 位作者，合作机构包括中国科学院大学、Northeastern University、UIUC 与 Johns Hopkins University），报告了 on-policy distillation（在线蒸馏：学生模型自己采样回答，教师逐 token 给出密集监督）在数据极简极限下的表现：只用一条训练 query，蒸馏就能持续上行数百步，恢复全量数据蒸馏收益的大部分。需要先划清边界——这不是「一条数据训出完整模型」，而是说在这类后训练里，数据量远没有想象中金贵。与已发的<a href="/one-minute-read-paper-trajectory-budget-confounds/">《推理链里的顿悟时刻，多半是预算给的错觉》</a>聚焦评估方法不同，这篇考察的是训练本身的数据极限与机制。</p>

<h2 id="状态覆盖一条-query-能走多远">状态覆盖：一条 query 能走多远</h2>

<p>这里的学生状态，指学生自己采样出的回答前缀——教师的监督恰好逐 token 落在这些前缀上。论文提出一个可测量的新轴 state coverage（状态覆盖）：全量数据蒸馏在训练中访问过的学生状态集合里，一个小 query 集的采样轨迹能覆盖多大比例。按这个口径，作者发现单条 query 就能达到全量数据的 <code class="language-plaintext highlighter-rouge">71.5%</code>，而且大部分覆盖在前 <code class="language-plaintext highlighter-rouge">100</code> 步内就到账；换语义不同的 query，覆盖率与验证精度同步上升，<code class="language-plaintext highlighter-rouge">16</code> 条 query 覆盖到 <code class="language-plaintext highlighter-rouge">98.9%</code>，追平全量训练。论文把结论限定在数学任务与所测模型家族上，并报告该效应跨模型家族和任务领域稳健。</p>

<p><img src="/assets/images/one-shot-opd-state-coverage.svg" alt="单条 query 的状态覆盖曲线示意" /></p>

<h2 id="瓶颈在算法吸收不在数据供给">瓶颈在算法吸收，不在数据供给</h2>

<p>如果一条 query 就能访问大部分状态，多出来的数据买到了什么？作者把训练拆成两个变量分别测量——学生访问哪些状态，以及学生对齐教师的速率——对齐测量给出了另一半答案：无论喂一条还是全量数据，学生对教师的对齐速度都以相似速率放缓，哪怕把状态集固定不动，吸收这些监督也需要数百步。论文据此给这套在线蒸馏下了一个自造的诊断词——data-overfed but algorithm-starved（数据喂饱了，算法饿着）：学生的 rollout 很快摊开足够广的监督面，真正稀缺的是算法把这些监督吃进去的速率。需要说明，state coverage 是这篇论文提出的测量框架，不是学界既有定论，且全文为未经同行评审的预印本。</p>

<h2 id="多教师设定与实操含义">多教师设定与实操含义</h2>

<p>论文的延伸实验把结论推广到 multi-teacher（多教师）蒸馏：每个领域只用 <code class="language-plaintext highlighter-rouge">16</code> 条语义多样的 query，即可追平全量数据的多教师训练；用内容轻量的模板 query、甚至跨域的 WildChat 真实用户对话，也能接近真实领域 query 基线的表现。对实操的含义是直接的：后训练预算未必该继续堆数据，query 之间的语义差异比条数重要，而算法侧的吸收效率——学习率、优化步数这类训练动力学旋钮——才是更值得投入的方向。代码已在 GitHub 开源，本文是 2026 年 4 月同系列论文（arXiv:2604.13016）的续篇。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2609.04172">论文 abs 页</a></li>
  <li><a href="https://arxiv.org/abs/2604.13016">前作 Rethinking On-Policy Distillation I</a></li>
  <li><a href="https://github.com/Thinking-Space/One-Shot-OPD">代码仓库 One-Shot-OPD</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="llm" /><category term="distillation" /><category term="post-training" /><category term="reasoning" /><summary type="html"><![CDATA[清华大学团队预印本报告 on-policy 蒸馏的数据极简极限：单条 query 的在线蒸馏即可覆盖全量训练约 71.5% 的访问状态，`16` 条追平全量；瓶颈不在数据量，而在学生对教师监督的吸收速度。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/one-shot-opd-state-coverage.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/one-shot-opd-state-coverage.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《旧轨迹里挖出新环境》</title><link href="https://unbug.github.io/one-minute-read-paper-terminal-universe/" rel="alternate" type="text/html" title="一分钟读论文：《旧轨迹里挖出新环境》" /><published>2026-09-06T00:00:00+00:00</published><updated>2026-09-06T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-terminal-universe</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-terminal-universe/"><![CDATA[<p>以阿里 Qwen 团队为主力、合作清华大学的论文<a href="https://arxiv.org/abs/2609.04148">《Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments》</a>（arXiv:2609.04148，2026 年 9 月 3 日提交，14 位作者）提出一个判断：终端代码智能体（terminal agent，在命令行环境里执行任务的大模型智能体）后训练的真正瓶颈不是轨迹数量，而是可执行环境。一条轨迹是一次性冻结的示范，一个环境却能反复生成无数可验证任务并返回真实执行反馈。论文的结论是环境不必从零合成——已有轨迹里的工具执行历史本身就泄露了环境的结构与内容。按这个思路构建的 Terminal-Universe 框架从公开终端智能体轨迹中产出 <code class="language-plaintext highlighter-rouge">37.3k</code> 个 task-sufficient 环境（指足以支撑任务验证的环境）。</p>

<p>需要先划清边界：这是未经同行评审的预印本，「环境藏在轨迹里」是作者的主张而非学界定论；文中 <code class="language-plaintext highlighter-rouge">+11.9</code> 与 <code class="language-plaintext highlighter-rouge">+13.8</code> 两个数字均指 SFT（监督微调）后模型相对基线的提升分数，不是绝对成绩。</p>

<h2 id="环境重建回放文件操作再补齐缺口">环境重建：回放文件操作再补齐缺口</h2>

<p>Terminal-Universe 的核心机制分两步。第一步回放：轨迹记录了智能体对文件系统的每一次读写操作，把这些文件操作逆向回放到起点，就能把每个文件恢复到智能体修改之前的状态，得到一个残缺但真实的部分工作区。第二步补全：交给 completion agent（补全智能体）推断并补齐缺失的文件与依赖，把一个能跑起来、可反复出题的可执行环境还原出来。换言之，训练数据的再加工从样本级推到了环境级——不需要专门的模拟器或人工搭建的沙箱，别人跑过的轨迹就是矿。</p>

<p>在此之上，论文沿两个轴扩展任务。宽度轴挖掘相关环境之间的方向性依赖，合成跨代码库的查询任务；深度轴引入 user agent（模拟用户追问与反馈的智能体），把单轮查询扩展成带迭代反馈的多轮会话。</p>

<h2 id="实测单轮提分多轮提分更多">实测：单轮提分，多轮提分更多</h2>

<p>论文把框架应用于公开的终端智能体轨迹，得到 <code class="language-plaintext highlighter-rouge">37.3k</code> 个 task-sufficient 环境，并用这份语料对 Qwen3.5-27B 做 SFT。结果分两个口径：单轮任务上，Terminal-Bench 2.1（终端智能体的公开基准）相对基线提升 <code class="language-plaintext highlighter-rouge">11.9</code> 分；多轮任务上，EvoCode-Bench v2 的 MT@4 指标（多轮会话口径的通过类指标）提升 <code class="language-plaintext highlighter-rouge">13.8</code> 分。多轮的增益大于单轮，与框架专门做了 user agent 多轮化设计的取向一致。</p>

<h2 id="与轨迹评估那篇的方向区分">与轨迹评估那篇的方向区分</h2>

<p>这篇论文和已发的<a href="/one-minute-read-paper-trajectory-budget-confounds/">《推理链里的顿悟时刻，多半是预算给的错觉》</a>恰好站在轨迹的两端：那篇把轨迹当被审视的对象，拆穿从轨迹外部读数时的预算混淆；这篇把轨迹当原材料，从里面反向工程出训练用的环境。同一个数据物，一个是评估口径的质疑，一个是数据合成的增量，读的时候可以对照着看。对做智能体后训练的团队，可迁移的启发是：先盘点手头已有轨迹里的工具调用记录，那里可能已经躺着重建环境的原料，而环境才是能反复生题、持续给反馈的那一层资产。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2609.04148">Terminal-Universe: Turning Agent Trajectories into Scalable Terminal Environments</a></li>
  <li><a href="https://arxiv.org/html/2609.04148v1">HTML 全文（方法细节与实验表格）</a></li>
  <li><a href="/one-minute-read-paper-trajectory-budget-confounds/">站内：推理链里的顿悟时刻，多半是预算给的错觉</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="llm" /><category term="agents" /><category term="post-training" /><category term="code" /><summary type="html"><![CDATA[阿里 Qwen 团队与清华合作的预印本提出 Terminal-Universe：回放轨迹里的文件操作即可重建可执行终端环境，从公开轨迹产出 37.3k 个任务充分环境，SFT 后单轮基准提 11.9 分、多轮提 13.8 分。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/terminal-universe-trajectory-env.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/terminal-universe-trajectory-env.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry></feed>