<?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:51:30+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-capability-correlation-risk/" 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-capability-correlation-risk</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-capability-correlation-risk/"><![CDATA[<p>Jillian Ross、Eric So、Zoe De Simone、Charles Pozniak 与 Andrew W. Lo 合作的论文 <a href="https://arxiv.org/abs/2609.04373">Why Better Models Can Create Riskier Systems: Evidence from LLM Agents in Financial Markets</a>（2026年9月3日提交预印本）给出一个反直觉结论：提升单个模型的能力，可能让系统级结果变差而不是变好。机制不在个体犯错率，而在行为相关性——共享训练与架构让更强的模型行为更相似，相似的行为无法通过”多请几个专家”来分散，形成一条 <code class="language-plaintext highlighter-rouge">非可分散风险下限</code>（non-diversifiable risk floor）。</p>

<p><img src="/assets/images/capability-correlation-risk.svg" alt="能力提升与行为相关性同向上升，在正确与错误信息环境下产生相反的系统结果" /></p>

<h2 id="能力悖论的机制">能力悖论的机制</h2>

<p>论文的核心假设是：能力更强的 LLM 来自更大规模的共享训练数据和相近的架构谱系，因此它们不仅”更对”，也更”像”。当多个 agent 被部署进同一个系统——金融市场、内容审核、招聘——决策主体的数量在增加，有效独立的观点数量却没有同步增加。作者为此建立了一个通用框架：只要行动之间存在相关性，风险就不能随参与者数量无限摊薄，相关性越高，摊不掉的底线越高。这就是 <code class="language-plaintext highlighter-rouge">能力悖论</code>（capability paradox）的由来：个体层面的改进与系统层面的安全之间，存在一条方向不明的通道。日常直觉认为”把模型换强一点、把 agent 多加几个”总是更安全，这篇论文指出该直觉在一个可刻画的条件下失效。</p>

<h2 id="模拟市场的三个发现">模拟市场的三个发现</h2>

<p>验证手段是 agent-based 金融市场模拟：让按通用能力分级的 LLM 充当交易员，观察市场级风险随参与结构的变化。摘要报告了三个结果。其一，前沿 LLM 的行为呈现显著相关，且相关性随能力提升而上升。其二，当共享推理是准确的时候，扩大 agent 参与确实降低了市场级风险——多样性红利正常兑现。其三，当 agent 们处在 <code class="language-plaintext highlighter-rouge">共享错误信息环境</code>（common misinformation environment）里，同一套相关性立刻反转为负债：所有模型一起自信地错，且错得步调一致。三个结果合起来说明，问题不是”要不要用更强的模型”，而是强模型的集体偏差会把整个系统带到同一个方向上，没有任何一个参与者负责纠偏。</p>

<h2 id="边界模拟口径与外推">边界：模拟、口径与外推</h2>

<p>这项证据的分寸感比结论本身更重要，至少四点限制必须写清。其一，agent-based 模拟不等于真实市场：模拟中的 LLM 交易员没有真实资金约束、没有清算压力，也没有监管干预，市场级风险的量级不能直接搬到现实。其二，”相关性”的度量口径与”能力分级”的方式均为论文自定义，换一个口径结论的强度可能变化。其三，这是未经同行评审的预印本。其四，最危险的第三个发现限定在共享错误信息环境这一情景，作者自己也将”同样的动力学是否出现在其他领域”列为待验证的开放问题，不能泛化为”所有部署都会如此”。与本刊此前<a href="/one-minute-read-paper-beyond-transcript-latent-collusion/">《拍卖桌下的暗线，多智能体隐藏合谋的检测与干预》</a>相比，两者的威胁面不同轴：那篇是 agent 之间建立隐蔽通道的主动合谋，需要检测与干预；本篇没有任何合谋，模型甚至彼此不知情，风险纯粹来自训练层面的结构性相关——防住了通信审计，也防不住它。对采购方的直接含义是：堆同一家模型的多个实例，买到的可能是一个决策加若干份复制品。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2609.04373">Why Better Models Can Create Riskier Systems (arXiv:2609.04373)</a></li>
  <li><a href="/one-minute-read-paper-beyond-transcript-latent-collusion/">拍卖桌下的暗线，多智能体隐藏合谋的检测与干预</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="Safety" /><category term="llm" /><category term="agents" /><category term="safety" /><category term="financial-markets" /><summary type="html"><![CDATA[2026年9月的预印本用 LLM 交易员做 agent-based 金融市场模拟，发现更强的大语言模型行为相关性更高：共享推理正确时降低市场级风险，共享错误信息环境时同一相关性变成无法分散的系统风险。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/capability-correlation-risk.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/capability-correlation-risk.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><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">一分钟读论文：《删掉的记忆为何仍会从行为里漏出来》</title><link href="https://unbug.github.io/one-minute-read-paper-user-model-extraction-umpeek/" 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-user-model-extraction-umpeek</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-user-model-extraction-umpeek/"><![CDATA[<p>论文<a href="https://arxiv.org/abs/2609.03815">《Inferring Hidden User Models from the Behavior of Personalized LLM Agents》</a>（arXiv:2609.03815，2026-09-03 提交，cs.CR 预印本）给出一个对业界话术很不利的结论：个性化 Agent 把用户记忆压缩成结构化的「user model」（用户模型，指供后续决策使用的压缩或结构化表示）后，即使原文已从普通接口可达的状态中删除，黑盒攻击者依然能从被它塑造的个性化选择里恢复隐私信息。论文的表述是：keeping records and backend state inaccessible does not guarantee semantic privacy（记录与后端状态不可访问，并不保证语义隐私）。</p>

<h2 id="删掉原文为什么没删掉影响">删掉原文，为什么没删掉影响</h2>

<p>记忆提取类攻击依赖读到存储的文本，所以业界默认：压成用户模型、删掉原始措辞，攻击就失去了目标。论文指出这忽略了一个事实——用户模型仍然在每一次回复里做选择，而选择是可见的。论文引用的 LongMemEval 实验也印证了这个缺口：关键事实摘要使注入的高熵金丝雀文本被逐字提取的比例下降 <code class="language-plaintext highlighter-rouge">64%</code> 至 <code class="language-plaintext highlighter-rouge">76%</code>，个性化召回却几乎不受影响——压缩删掉了文本，保留了影响。</p>

<h2 id="umpeek假设引导的自适应追问">UMPeek：假设引导的自适应追问</h2>

<p>攻击分三步循环：从一次请求留下的可选空间生成关于用户模型的假设；在多个普通后续任务之间切换试探，避免每次都问同一件事；只保留被可见行为支持、且未被行为矛盾的主张。整个过程是黑盒的，不需要读存储或后端状态。</p>

<p>评测覆盖 <code class="language-plaintext highlighter-rouge">4</code> 个个性化任务基准、<code class="language-plaintext highlighter-rouge">3</code> 种用户模型后端，与 <code class="language-plaintext highlighter-rouge">7</code> 个已有攻击（记忆提取、提示词泄露、属性推断等方向）对比，每个目标最多 <code class="language-plaintext highlighter-rouge">16</code> 次追问。结果显示，UMPeek 的语义恢复分数 UMR-F1（用确定性词汇匹配规则打分，不依赖大模型或嵌入模型评判）超过最强对比攻击 <code class="language-plaintext highlighter-rouge">六倍</code> 以上，并在全部基准与后端的组合中领先；预算对齐实验进一步表明，优势来自假设引导的任务选择，而不是单纯追问数量多。</p>

<h2 id="真实系统与防御缺口">真实系统与防御缺口</h2>

<p>作者声称在「信息确证被保留」的真实系统上做了验证：三个托管服务加一个端到端个人 Agent（OpenClaw），UMPeek 在所有托管服务的保留目标上都拿到评估攻击中的最高恢复——注意这是作者自述，且限定在其确认信息仍被保留的场景，不是对产品隐私状况的全面测量。防御侧的结论同样有限定：PrivacyChecker 与 Theory-of-Mind 这类响应级防御下，自适应追问仍能恢复大量用户信息；只有更强的状态化反事实控制（撤掉那些去掉个性化就会改变的决定）能把恢复压得更低，代价是个性化任务性能同步下降。</p>

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

<p>第一，论文是预印本，未经同行评审，作者未标注机构。第二，「六倍以上」是相对论文自定义的 UMR-F1 词汇匹配指标而言，该分数与真实隐私损害之间的距离并不明确。第三，真实系统验证限于作者确证保留的目标，不能外推为所有个性化产品都在泄露。第四，它与<a href="/one-minute-read-paper-agent-memory-portability-model-upgrade/">《记忆库原封不动，Agent 为何照样失忆》</a>同属 Agent 记忆安全族但角度相反：那篇说换模型会让旧记忆失效，问题在表示格式；这篇说存储再可靠也没用——只要保留的信息继续塑造可见行为，删除原文就删不掉影响。压缩表征正在成为记忆工程里新的攻击面。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2609.03815">Inferring Hidden User Models from the Behavior of Personalized LLM Agents（arXiv:2609.03815）</a></li>
  <li><a href="/one-minute-read-paper-agent-memory-portability-model-upgrade/">一分钟读论文：《记忆库原封不动，Agent 为何照样失忆》</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="Security" /><category term="llm" /><category term="agent" /><category term="privacy" /><category term="security" /><summary type="html"><![CDATA[UMPeek 证明个性化 Agent 即使删掉记忆原文，黑盒攻击者仍能通过假设引导的自适应追问从可见行为恢复隐私信息：语义恢复超过最强基线六倍以上，响应级防御也拦不住。删除记录不等于删除影响。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/user-model-extraction-umpeek.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/user-model-extraction-umpeek.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></feed>