<?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-08-21T16:20:45+00:00</updated><id>https://unbug.github.io/feed.xml</id><title type="html">Micropaper 一分钟读论文</title><subtitle>Micropaper 一分钟读论文：每天用一分钟读懂一篇 AI 论文，并提供 AI 范式雷达与 AI 智创简报，覆盖智能体、大模型、AI 安全与专利机会洞察。</subtitle><author><name>unbug</name></author><entry><title type="html">一分钟读论文：《MidTool：工具使用需要专门的中间训练》</title><link href="https://unbug.github.io/one-minute-read-paper-midtool-mid-training-tool-use/" rel="alternate" type="text/html" title="一分钟读论文：《MidTool：工具使用需要专门的中间训练》" /><published>2026-08-21T00:00:00+00:00</published><updated>2026-08-21T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-midtool-mid-training-tool-use</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-midtool-mid-training-tool-use/"><![CDATA[<p>Snowflake、华盛顿大学和北卡罗来纳大学教堂山分校合作的论文<a href="https://arxiv.org/abs/2608.20314">《MidTool: Mid-training Data Synthesis for Agentic Tool Use》</a>提出，智能体工具使用能力需要专门的 mid-training 数据管线，而不是只依赖 post-training。这与站内此前的<a href="/one-minute-read-paper-bitter-lesson-tool-calling/">《工具调用的苦涩教训》</a>不同：那篇对比的是推理时方法（JSON 工具调用与程序化工具调用），本篇是训练数据管线的视角。论文于 2026 年 8 月 20 日提交 arXiv（v1，cs.AI），提交人 Fengqing Jiang，共 8 位作者。核心论点是：工具使用像数学和科学一样，需要专门的 mid-training 数据，而不是全靠 post-training。论文构建了 <code class="language-plaintext highlighter-rouge">20.3B</code> token 的 mid-training 语料 MidTool-Mix，在 Qwen3-4B-Base 与 Qwen3-8B-Base 上完成监督微调（SFT）与强化学习（RL）后，BFCLv3、tau2-Bench 与 MCP-Universe 三个基准一致提升。</p>

<p><img src="/assets/images/midtool-mid-training-tool-use.svg" alt="MidTool mid-training 数据合成与评测框架图" /></p>

<h2 id="midtool-mix203b-token-的语料构成">MidTool-Mix：20.3B token 的语料构成</h2>

<p>mid-training（中间训练）指预训练完成之后、SFT 之前的继续预训练阶段，用大规模领域数据向 base 模型注入专门能力。论文摘要将这项工作描述为一条开放的语料构建管线：先收集真实 web 文本、PDF 与代码，再从真实工具 API、MCP（Model Context Protocol）skills 与文档工作流生成合成监督信号，两部分混合成 <code class="language-plaintext highlighter-rouge">20.3B</code> token 的 MidTool-Mix，总量与后文对照实验所用的 Dolmino-20BT 相当；管线按论文 Section 2 分为数据源采集、数据预处理与 agentic 轨迹合成三个阶段。这些合成监督信号在 mid-training 阶段注入 base 模型，为工具调用行为提供训练样本。语料与 mid-trained 模型都在 Hugging Face collection 中发布，abs 页 comments 标注为 Data &amp; Model，可直接复现或扩展。</p>

<h2 id="三个基准的一致提升">三个基准的一致提升</h2>

<p>BFCLv3 overall（Table 3）上，表格依次给出三种配置：SFT 基线、加入 MidTool-Mix 做 SFT、再叠加 RL。Qwen3-4B-Base 的 SFT 基线为 <code class="language-plaintext highlighter-rouge">39.73</code>，加入 MidTool-Mix 做 SFT 后升至 <code class="language-plaintext highlighter-rouge">50.25</code>（+10.5），SFT + RL 进一步到 <code class="language-plaintext highlighter-rouge">54.18</code>；官方 Qwen3-4B 仅 <code class="language-plaintext highlighter-rouge">24.27</code>，官方 Qwen3-8B 仅 <code class="language-plaintext highlighter-rouge">26.45</code>。这两行官方发布模型作为参照线，说明不做 mid-training 时，更大的 8B 也追不上 mid-trained 的 4B。也就是说，在 Qwen3 家族的 BFCLv3 overall 上，mid-trained 的 4B 超过了官方 8B，论文 Figure 1 右图给出同一结论。tau2-Bench overall Pass@1（Table 4）上，4B 从 SFT 基线 <code class="language-plaintext highlighter-rouge">8.54</code> 提升到 MidTool-Mix + SFT + RL 的 <code class="language-plaintext highlighter-rouge">19.96</code>，约 2.3 倍；8B 从 <code class="language-plaintext highlighter-rouge">10.43</code> 到 <code class="language-plaintext highlighter-rouge">21.31</code>。MCP-Universe overall（Table 5）上，4B 的 score / pass rate 从 <code class="language-plaintext highlighter-rouge">13.20 / 1.68%</code> 升到 <code class="language-plaintext highlighter-rouge">23.80 / 10.06%</code>，pass rate 约提升 6 倍；8B 从 <code class="language-plaintext highlighter-rouge">15.18 / 3.35%</code> 到 <code class="language-plaintext highlighter-rouge">25.16 / 9.50%</code>。对比 SFT 与 SFT + RL 两行，RL 在 BFCLv3 overall 上再提升约 3.9 分；但两个模型 RL 后的 tau2-Bench overall Pass@1 仍在 <code class="language-plaintext highlighter-rouge">20%</code> 上下。以上数字均取自论文正文 Table 3–5。</p>

<h2 id="数据构成比数据量更关键">数据构成比数据量更关键</h2>

<p>论文设置了 matched-budget 对照来排除「数据多就好」的解释：Dolmino-20BT（Table 6）是同等规模的通用 mid-training 语料。matched-budget 指两份语料的 token 规模相当，唯一变量是数据构成，因此增益差异可以归因于构成而非规模。该基线的 BFCL overall 仅提升 <code class="language-plaintext highlighter-rouge">+3.4</code>，MCP-Universe score 反而下降 <code class="language-plaintext highlighter-rouge">-7.8</code>。相比之下，MidTool-Mix 在同一批基准上带来两位数增益：仅 SFT 就在 BFCLv3 overall 上增加 10.5 分，叠加 RL 后达到 54.18。工具专用的合成轨迹与通用 web 数据的构成差异，比数据量本身更关键；对工具使用能力而言，应先优化构成再考虑扩大规模。</p>

<h2 id="能力边界telecom-与-web-search">能力边界：telecom 与 Web Search</h2>

<p>论文实验仅用 Qwen3-4B-Base 与 Qwen3-8B-Base 两个 base 模型验证，结论不能外推到其他模型家族。两个边界需要如实指出。其一，tau2-Bench 的 telecom 子集在 MidTool-Mix + SFT + RL 配置下 Pass@1 仅 <code class="language-plaintext highlighter-rouge">6.36</code>，远低于 overall 水平；其二，MCP-Universe 的 Web Search 列在所有配置行均为 <code class="language-plaintext highlighter-rouge">0.00 / 0.00%</code>。论文将后者解读为独立的能力边界而非迁移失败——browser、financial、location 等其他子集均有提升。引用该论文结论时应同时考虑这两个边界。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2608.20314">MidTool: Mid-training Data Synthesis for Agentic Tool Use（arXiv）</a></li>
  <li><a href="https://hf.co/collections/MidTool/midtool-release">MidTool 数据与模型 Hugging Face collection</a></li>
  <li><a href="/one-minute-read-paper-bitter-lesson-tool-calling/">一分钟读论文：《工具调用的苦涩教训》</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="LLM" /><category term="llm" /><category term="tool-use" /><category term="mid-training" /><summary type="html"><![CDATA[Snowflake、华盛顿大学与北卡罗来纳大学教堂山分校构建了 20.3B token 的工具使用中间训练语料 MidTool-Mix，在 Qwen3-4B/8B-Base 上经 SFT+RL 后 BFCLv3、tau2-Bench 与 MCP-Universe 均显著提升，表明工具使用需要专门的中间训练而非仅靠后训练。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/midtool-mid-training-tool-use.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/midtool-mid-training-tool-use.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《测试时扩展：瓶颈在筛选，不在采样》</title><link href="https://unbug.github.io/one-minute-read-paper-tts-exploitation-bottleneck/" rel="alternate" type="text/html" title="一分钟读论文：《测试时扩展：瓶颈在筛选，不在采样》" /><published>2026-08-21T00:00:00+00:00</published><updated>2026-08-21T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-tts-exploitation-bottleneck</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-tts-exploitation-bottleneck/"><![CDATA[<p>Thomson Reuters 的论文<a href="https://arxiv.org/abs/2608.18931">《Test-Time Scaling in the Wild: Why Exploitation, Not Exploration, Is the Bottleneck》</a>是首个在不可精确验证的开放生成任务上对五类测试时扩展（TTS）方法做算力归一化对比的工作，结论是：瓶颈不在「生成更多候选」（探索有效），而在「从候选池里选出最终答案」（利用失效）。这与本站此前介绍的<a href="/one-minute-read-paper-llm-as-a-verifier/">《LLM-as-a-Verifier》</a>把验证当作缩放轴的系列不同——在开放生成任务上，验证器恰恰是失效环节。</p>

<p><img src="/assets/images/tts-exploitation-bottleneck.svg" alt="测试时扩展的探索/利用分解框架图" /></p>

<h2 id="算力归一化的方法族对比">算力归一化的方法族对比</h2>

<p>实验覆盖五个没有精确验证器的开放生成基准：HealthBench（<code class="language-plaintext highlighter-rouge">5000</code> 题医学）、LEXam（<code class="language-plaintext highlighter-rouge">516</code> 题法律）、PRBench（<code class="language-plaintext highlighter-rouge">1650</code> 题金融/法律）、WildBench（<code class="language-plaintext highlighter-rouge">1024</code> 题通用对话）、WritingBench（<code class="language-plaintext highlighter-rouge">555</code> 题创意写作）。六种方法在四档算力下对比，算力档对应 Best-of-N（BoN）<code class="language-plaintext highlighter-rouge">N=2/4/8/16</code> 的输出 token 量：BoN、Beam Search、Particle Filter（PF）、Sequential Refinement（SR）、Fusion，另加 Budget Forcing 对照。生成器覆盖 OLMo3-7B-Think、OLMo3.1-32B-Think、Qwen3.5-9B 与 Qwen3.5-35B-A3B 四个模型，四档算力在 <code class="language-plaintext highlighter-rouge">25%</code> 容差内对齐。探索侧全部有效：oracle 质量随算力单调上升，说明「多采候选」本身是有效的；论文同时给出偏差校正的 oracle 估计器，因为 naive oracle 会系统性高估可用质量。论文的理论部分推导出 BoN 的头空捕获约等于验证器相关性 rho_v，实测回归为 <code class="language-plaintext highlighter-rouge">y=1.198*rho_v-0.011</code>（R²=<code class="language-plaintext highlighter-rouge">0.66</code>，p&lt;10^-36）。</p>

<h2 id="利用侧全面失效">利用侧全面失效</h2>

<p>用统一裁判 Qwen3.5-397B-A17B 与各基准原生裁判对齐后，在 <code class="language-plaintext highlighter-rouge">152</code> 个样本上测得：Skywork-Reward-V2-Llama-3.1-8B 的 Spearman 相关 rho_v 仅 <code class="language-plaintext highlighter-rouge">0.120</code>，Llama-3.1-70B-Instruct-RM-RB2 为 <code class="language-plaintext highlighter-rouge">0.107</code>——当前一代开源奖励模型在开放生成上几乎无法区分好坏，基于它的 BoN 选择近乎随机。头空捕获（方法实际回收的、多候选可带来质量增益的比例）定义为 h=(BoN@16-单样本均值)/(Oracle@16-单样本均值)，跨基准平均下来，Fusion 约 <code class="language-plaintext highlighter-rouge">40%</code>，BoN 只有约 <code class="language-plaintext highlighter-rouge">15%</code>；算力、奖励模型规模、生成器规模三条缩放轴都补不上这个差距。论文的概括是：候选池不是瓶颈，从里面选才是。</p>

<h2 id="树搜索与自我修正的失败模式">树搜索与自我修正的失败模式</h2>

<p>两种经典方法的失败方式各不相同。<strong>树搜索在多样性上坍缩</strong>：Particle Filter 最终输出的平均成对余弦距离只有 <code class="language-plaintext highlighter-rouge">0.036</code>-<code class="language-plaintext highlighter-rouge">0.069</code>，BoN 为 <code class="language-plaintext highlighter-rouge">0.123</code>-<code class="language-plaintext highlighter-rouge">0.124</code>；WritingBench 上 <code class="language-plaintext highlighter-rouge">16</code> 个粒子相似度 &gt;=0.997，等效于单条轨迹；正文记录树搜索的多样性只剩独立采样的 <code class="language-plaintext highlighter-rouge">40-60%</code>，它在探索与利用两侧同时失败。<strong>Sequential Refinement 只在五个基准中的一个（PRBench）真实提升</strong>：HealthBench 与 LEXam 上逐轮变差；WildBench 的增益全部来自 Coding &amp; Debugging 单一子任务，剔除后净回退；WritingBench 的表观增益被冗长度混淆（SR 长度-分数相关 rho=+0.33，BoN 为 +0.20，裁判的内容/长度判别力只有 0.7 倍）。</p>

<h2 id="可复现的最小验证">可复现的最小验证</h2>

<p>统一裁判本身经过信效度校验：HealthBench 上对医生标注的 Macro F1 为 <code class="language-plaintext highlighter-rouge">0.679</code>（高于标注者间一致均值），PRBench 的 kappa 为 <code class="language-plaintext highlighter-rouge">0.679</code>。主结果表（Qwen3.5-35B-A3B 单模型）里，HealthBench 的 BoN 从 Low 到 XHigh 算力档停在 <code class="language-plaintext highlighter-rouge">0.536</code>→<code class="language-plaintext highlighter-rouge">0.539</code>，Fusion 为 <code class="language-plaintext highlighter-rouge">0.574</code>→<code class="language-plaintext highlighter-rouge">0.588</code>；PRBench 是 <code class="language-plaintext highlighter-rouge">0.292</code>→<code class="language-plaintext highlighter-rouge">0.292</code> 对 <code class="language-plaintext highlighter-rouge">0.315</code>→<code class="language-plaintext highlighter-rouge">0.331</code>；LEXam 是 <code class="language-plaintext highlighter-rouge">0.525</code>→<code class="language-plaintext highlighter-rouge">0.530</code> 对 <code class="language-plaintext highlighter-rouge">0.546</code>→<code class="language-plaintext highlighter-rouge">0.547</code>。Beam Search 与 Particle Filter 全面低于单样本基线。论文把 Fusion 定位为目前唯一一致有效的方法，而非解决方案——剩余约六成头空仍是开放问题。对个人开发者，核心洞察数小时内可复现：在小规模开放任务上采样 N 个候选，用 LLM 裁判打分，对比 BoN 选择与合成式 Fusion，单卡或 API 调用即可，无需论文级的算力规模。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2608.18931">Test-Time Scaling in the Wild (arXiv:2608.18931)</a></li>
  <li><a href="/one-minute-read-paper-llm-as-a-verifier/">LLM-as-a-Verifier 站内解读</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="LLM" /><category term="llm" /><category term="test-time-compute" /><category term="verification" /><summary type="html"><![CDATA[Thomson Reuters 首个算力归一化的五类测试时扩展方法对比发现，开放生成任务的瓶颈在利用不在探索：奖励模型与真实质量相关仅约 0.12，BoN 选择近乎随机，Fusion 也只回收约 40% 可用质量。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/tts-exploitation-bottleneck.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/tts-exploitation-bottleneck.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《标签可撕，凭证要验：内容溯源的打标缺口》</title><link href="https://unbug.github.io/innovation-brief-content-provenance-patents/" rel="alternate" type="text/html" title="AI 智创简报：《标签可撕，凭证要验：内容溯源的打标缺口》" /><published>2026-08-20T00:00:00+00:00</published><updated>2026-08-20T00:00:00+00:00</updated><id>https://unbug.github.io/innovation-brief-content-provenance-patents</id><content type="html" xml:base="https://unbug.github.io/innovation-brief-content-provenance-patents/"><![CDATA[<p>2026 年 AI 内容溯源与水印主题的美国申请至少公开 6 件，其中 3 件在近 90 天内。8 月 2 日 EU AI Act 透明度条款生效，AI 生成内容必须机器可读标记。「标签可撕」与「可验证凭证」之间的缺口，是一个能接的活儿。</p>

<p><img src="/assets/images/innovation-brief-content-provenance-patents.svg" alt="AI 内容溯源专利信号与独立开发者机会" /></p>

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

<p>四件代表性专利，均为<strong>申请公开</strong>，不等于已授权：</p>

<table>
  <thead>
    <tr>
      <th>公开号</th>
      <th>申请人 / 公开日</th>
      <th>要点</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">US20260236564</code></td>
      <td>Music IP Holdings · 2026-08-13</td>
      <td>AI 生成内容用水印、元数据、哈希等附溯源数据，使用限制推给合作平台</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">US20260195422</code></td>
      <td>Music IP Holdings · 2026-07-09</td>
      <td>AI 衍生作品水印分散嵌入多个频段，难以剥离</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">US20260187746</code></td>
      <td>SAP · 2026-07-02</td>
      <td>块级频域水印嵌入，用于内容全生命周期校验</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">US20260099327</code></td>
      <td>U.S. Bank · 2026-04-09</td>
      <td>编辑器插件用署名 token 逐段标记人写与 AI 生成</td>
    </tr>
  </tbody>
</table>

<p>Music IP Holdings 在「AI 衍生作品 + 分发管控」同方向还有多件申请与授权，构成同一申请人的专利族。</p>

<h2 id="技术趋势">技术趋势</h2>

<p>这些专利的共同走向：溯源从「人工勾选」走向<strong>「机器可验证」</strong>，从「生成时打一个水印」走向「全链路的凭证」。现状是用户在平台手动勾选「AI 生成」，标签可撕、无法核验；专利方向是把凭证写进文件本身——C2PA（内容凭证标准）式元数据清单、多频段水印、哈希指纹、内容库条目，分发链上任何节点都能验。U.S. Bank 的署名 token 更进一步，不只标「是不是 AI」，还标「哪段是人写的」。这一层不碰模型能力，是文件格式与元数据的纯工程。上一篇<a href="/innovation-brief-agent-guardrail-patents/">Agent 纠错专利</a>解决「Agent 不可信」，内容溯源解决的是「内容不可信」。</p>

<h2 id="落地机会">落地机会</h2>

<p>用户场景：EU AI Act 第 50 条 2026 年 8 月 2 日生效，生成式 AI 系统的提供者必须把合成内容以机器可读格式标记，各大平台也在陆续上线 AI 内容披露要求。自媒体运营、MCN 编辑批量产出 AI 图、视频与文案，平台或客户问「这是不是 AI 做的，拿证据」时，只能口头自证——标签可撕，没有可验证凭证。</p>

<p>一个人能做的层：</p>

<ul>
  <li>封装 C2PA 开源 SDK（<code class="language-plaintext highlighter-rouge">c2pa-rs</code> / <code class="language-plaintext highlighter-rouge">c2pa-python</code> / <code class="language-plaintext highlighter-rouge">c2pa-js</code>）做<strong>批量打标 Web 工具</strong>：上传 AI 生成内容，自动附加 Content Credentials 清单（AI 声明、模型、时间戳），输出可验证文件</li>
  <li>每个文件附一个验证页，任何人打开链接即可看到生成记录</li>
  <li>技术栈：Rust 或 Python SDK + 一台小云主机 + 对象存储，起步成本月均几百元，MVP 两周可跑通</li>
</ul>

<h2 id="创业发现">创业发现</h2>

<ul>
  <li><strong>批量合规打标 SaaS</strong>：面向 MCN、自媒体工具商、企业营销部门，按月订阅 99-299 元。首批客户在开发者社区与自媒体运营群的「AI 内容合规」讨论里。门槛低，护城河在批量处理与团队工作流集成；风险是平台原生标签可能覆盖「打标」环节，需往「合规证明 + 报告」做深</li>
  <li><strong>署名归属报告服务</strong>：对人机混合内容标注哪些段落人写、哪些 AI 生成，输出合规报告。首批客户是企业法务合规部门、出版社、广告代理，按项目收费。门槛是向非技术客户讲清流程；风险是一次性项目不复利，报告要尽早产品化</li>
</ul>

<blockquote>
  <p>大厂专利抢的是「生成端」；「验证与证明」这层是平台看不上、个人能接的薄活儿。</p>
</blockquote>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://www.freepatentsonline.com/20260236564.html">US20260236564 AI-Generated Content Provenance and Distribution Control</a></li>
  <li><a href="https://www.freepatentsonline.com/20260195422.html">US20260195422 Watermarking of AI-Generated Derivative Works</a></li>
  <li><a href="https://www.freepatentsonline.com/20260187746.html">US20260187746 Digital Watermarking for Authenticity and Security in Lifecycle Management of Digital Content</a></li>
  <li><a href="https://www.freepatentsonline.com/20260099327.html">US20260099327 Auditable Authorship Attribution with Automatically Applied Authorship Tokens</a></li>
  <li><a href="https://artificialintelligenceact.eu/article/50/">EU AI Act Article 50: Transparency Obligations for Providers and Deployers of Certain AI Systems</a></li>
  <li><a href="https://c2pa.org/">C2PA: Coalition for Content Provenance and Authenticity</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="Patent" /><category term="ContentProvenance" /><category term="C2PA" /><category term="AIGC" /><category term="IndieHacker" /><summary type="html"><![CDATA[AI 内容溯源专利密集公开，EU AI Act 第 50 条 8 月生效，AI 生成内容须机器可读标记。个人开发者可用开源 C2PA SDK 做批量打标工具，卖给 MCN 与企业营销团队。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/innovation-brief-content-provenance-patents.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/innovation-brief-content-provenance-patents.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">AI 智创简报：《路由有专利，账单有水分：API 中间层省钱活》</title><link href="https://unbug.github.io/innovation-brief-llm-routing-cache-patents/" rel="alternate" type="text/html" title="AI 智创简报：《路由有专利，账单有水分：API 中间层省钱活》" /><published>2026-08-20T00:00:00+00:00</published><updated>2026-08-20T00:00:00+00:00</updated><id>https://unbug.github.io/innovation-brief-llm-routing-cache-patents</id><content type="html" xml:base="https://unbug.github.io/innovation-brief-llm-routing-cache-patents/"><![CDATA[<p>2026 年大模型路由、语义缓存与成本预测主题的美国申请至少公开 6 件，其中 NVIDIA 与 IBM 的 2 件落在近 90 天。这些专利指向同一层：API 中间层。对交 API 账单的开发者，这是一层能接的活儿。</p>

<p><img src="/assets/images/innovation-brief-llm-routing-cache-patents.svg" alt="大模型路由与缓存专利信号和独立开发者机会" /></p>

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

<p>6 件均为<strong>申请公开</strong>，不等于已授权。4 件代表性：</p>

<table>
  <thead>
    <tr>
      <th>公开号</th>
      <th>申请人 / 公开日</th>
      <th>要点</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">US20260187482</code></td>
      <td>NVIDIA · 2026-07-02</td>
      <td>用「提示词-响应评分」数据训练语言模型路由器，按请求自动选最合适的模型</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">US20260195537</code></td>
      <td>IBM · 2026-07-09</td>
      <td>根据用户交互模式预测下一个提示词，预热边缘缓存，降延迟降成本</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">US20260119922</code></td>
      <td>BOOMI, LP · 2026-04-30</td>
      <td>用相似历史输入预测本次调用成本，超预算自动拦截</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">US20260134002</code></td>
      <td>Infobip · 2026-05-14</td>
      <td>先分类，再用上下文赌博机按成本/质量/吞吐选 LLM 供应商</td>
    </tr>
  </tbody>
</table>

<p>BOOMI 同日还公开 <code class="language-plaintext highlighter-rouge">US20260119921</code>（评分 Agent 监控性能偏差、动态调节治理），Palo Alto Networks 的 <code class="language-plaintext highlighter-rouge">US20260064670</code>（自然语言查询路由，2026-03-05 公开）同簇。</p>

<h2 id="技术趋势">技术趋势</h2>

<p>这些专利的共同走向：从「每次调用都付全价」到「先选模型、再缓存、后管预算」。与现有方案的差异：写死模型或用 OpenRouter 式路由平台，都是静态规则；专利方向是闭环——NVIDIA 的路由器用评分数据训练，路由越准数据越多；IBM 更进一步，预测下一个提示词，请求到达前预热缓存；BOOMI 把预算护栏放在调用前，先预测成本再拦截。这一层不碰模型能力，是 API 中间层的纯工程。上一篇<a href="/innovation-brief-agent-guardrail-patents/">Agent 纠错专利</a>解决「Agent 不可信」，路由缓存层解决的是「Agent 太贵」。</p>

<h2 id="落地机会">落地机会</h2>

<p>用户场景：给电商小店做客服机器人的独立开发者，API 账单一个月翻了三倍——80% 的问题是「我的订单什么时候到」这类重复提问，每次都按全价付费；他不知道每个任务哪个模型最便宜又够用，也不敢让 Agent 放开跑，一次失控的循环能烧掉几百美元。</p>

<p>一个人能做的层：一个 <strong>LLM 代理（中间件）</strong>，夹在应用与模型 API 之间，做三件事：</p>

<ul>
  <li>语义缓存：重复问题命中缓存直接返回，不再付费调用（GPTCache 开源）</li>
  <li>路由：便宜模型做分类与简单任务，贵模型只处理复杂请求（LiteLLM 开源网关，内置成本追踪）</li>
  <li>成本护栏：按请求记录 token 与金额，预测本次调用成本，超预算告警或拦截（BOOMI 两件专利揭示的问题）</li>
</ul>

<p>技术栈全是开源：LiteLLM + GPTCache + 小 VPS（约 50-100 元/月），起步月均几百元，MVP 4 周可演示。</p>

<h2 id="创业发现">创业发现</h2>

<ul>
  <li><strong>成本审计服务</strong>：先做一次性「API 成本审计」：拆解账单，找出可缓存问题与可降级模型，交付降本报告，按项目收费（2000-5000 元）。首批客户是开发者社区、GitHub issue 区与 X 上抱怨 API 账单的独立开发者与 3 人以内小团队，审计后转订阅代理。</li>
  <li><strong>垂直成本优化代理</strong>：单一场景（如电商客服）的托管代理服务，月订阅 99-299 元，卖点是「接入后账单降 30%，不降不收费」。首批客户来自审计存量客户。</li>
  <li>门槛低（开源组件齐全），竞争者也多；风险是 OpenRouter 与模型厂商把路由/缓存内置；对策是垂直化，积累行业调优经验。</li>
</ul>

<blockquote>
  <p>大厂在专利里抢「路由」，账单在应用层，钱在「帮人省」这一头。</p>
</blockquote>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://www.freepatentsonline.com/y2026/0187482.html">US20260187482 Performance-Based Language Model Routing</a></li>
  <li><a href="https://www.freepatentsonline.com/y2026/0195537.html">US20260195537 Edge Computing Based Predictive Prompt Caching for Large Language Model</a></li>
  <li><a href="https://www.freepatentsonline.com/y2026/0119922.html">US20260119922 Dynamic and Adaptive Prediction of Model Costs Prior to Utilization of AI Models</a></li>
  <li><a href="https://www.freepatentsonline.com/y2026/0119921.html">US20260119921 Dynamic and Adaptive Optimization of AI Agents at Inference Time</a></li>
  <li><a href="https://www.freepatentsonline.com/y2026/0134002.html">US20260134002 Systems and Methods for Processing Data for Large Language Models</a></li>
  <li><a href="https://www.freepatentsonline.com/y2026/0064670.html">US20260064670 Natural Language Endpoint Manipulation with a Large Language Model</a></li>
  <li><a href="https://github.com/BerriAI/litellm">LiteLLM: 开源 AI 网关</a></li>
  <li><a href="https://github.com/zilliztech/GPTCache">GPTCache: 开源 LLM 语义缓存</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="InnovationBrief" /><category term="Patent" /><category term="LLM" /><category term="ModelRouting" /><category term="CostOptimization" /><category term="IndieHacker" /><summary type="html"><![CDATA[NVIDIA、IBM 密集公开大模型路由与语义缓存专利，指向 API 中间层。独立开发者用 LiteLLM 加 GPTCache 搭成本护栏，帮小团队降账单。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/innovation-brief-llm-routing-cache-patents.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/innovation-brief-llm-routing-cache-patents.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-bayes-belief-agent-adaptive-replanning/" rel="alternate" type="text/html" title="一分钟读论文：《贝叶斯伙伴建模与 LLM 协同重规划》" /><published>2026-08-20T00:00:00+00:00</published><updated>2026-08-20T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-bayes-belief-agent-adaptive-replanning</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-bayes-belief-agent-adaptive-replanning/"><![CDATA[<p>论文<a href="https://arxiv.org/abs/2608.18490">《Bayesian Partner Modelling enables Adaptive Replanning for LLM Coordination》</a>针对多智能体大语言模型系统的一个常见问题：队友会在任务中途切换策略，智能体却常常在公开证据表明伙伴已更换技能之后，仍继续执行过时的计划。现有方法要么把伙伴追踪当作被动上下文，知道变化发生但反应迟缓，要么不加区分地频繁重规划。论文提出 BayesBeliefAgent，将基于 GPT-4o 的分层大语言模型规划器与一个贝叶斯追踪模块配对，仅当伙伴的实际动作与推断技能直接矛盾时，才中断当前技能并触发重规划。除标准奖励外，论文以重规划效率与 belief-action gap 作为核心评估维度。</p>

<h2 id="信念-行动差距一个新指标">信念-行动差距：一个新指标</h2>

<p>论文引入 <strong>belief-action gap</strong> 指标：在所有决策点中，智能体对伙伴的估计正确、却仍执行不互补技能的比例。不互补技能指与队友当前技能重叠或不配合的动作，例如两个智能体同时执行同一任务步骤。该指标衡量”知道”与”做到”之间的脱节：即使对伙伴的信念正确，智能体也可能继续执行过时、重复或不互补的宏观动作。论文同时提出 <strong>replanning efficiency</strong> 指标，定义为平均奖励除以每 episode 的重规划次数。</p>

<p>在 Overcooked 基准上，BayesBeliefAgent 与基线 ProAgent 的伙伴技能识别准确率几乎相同（Open 布局 <code class="language-plaintext highlighter-rouge">0.79</code> 对 <code class="language-plaintext highlighter-rouge">0.78</code>），但 gap 率在 Open 布局从 <code class="language-plaintext highlighter-rouge">0.41</code> 降到 <code class="language-plaintext highlighter-rouge">0.20</code>，在 Ring 布局从 <code class="language-plaintext highlighter-rouge">0.38</code> 降到 <code class="language-plaintext highlighter-rouge">0.28</code>。互补性指标 Comp@3 在 Open 布局从 <code class="language-plaintext highlighter-rouge">0.39</code> 升到 <code class="language-plaintext highlighter-rouge">0.66</code>，重复技能率从 <code class="language-plaintext highlighter-rouge">0.30</code> 降到 <code class="language-plaintext highlighter-rouge">0.15</code>。这说明差距不在智能体能否”看穿”伙伴，而在于信念是否被用作控制信号。</p>

<h2 id="门控中断机制">门控中断机制</h2>

<p>BayesBeliefAgent 将系统分为两层：规划器是基于 GPT-4o 的分层大语言模型规划器，以宏观技能为单位组织行为，每个技能包含多步动作序列；贝叶斯追踪模块根据观察到的动作持续推断伙伴当前技能的后验分布，并在每个决策点更新信念。仅当伙伴动作与推断技能直接矛盾时，系统才中断当前技能并触发重规划，论文称之为后验门控中断，把伙伴信念从”被动上下文”升级为”主动控制信号”。消融实验表明，把后验用作控制信号，优于仅将其作为规划器提示词的上下文。</p>

<p><img src="/assets/images/bayes-belief-agent-framework.svg" alt="BayesBeliefAgent 框架：贝叶斯追踪、矛盾检测、门控中断与重规划流程，及 belief-action gap 对比数字" /></p>

<h2 id="实验结果与局限">实验结果与局限</h2>

<p>实验使用 Overcooked 的 Open、Ring 与 Forced Coordination 三种布局，外加 Burrito 环境，伙伴均为行为偏好多样的未见过队友。在 Open 布局上，Full 变体平均每 episode 重规划 <code class="language-plaintext highlighter-rouge">1.8-3.0</code> 次，Periodic-10 与 Compl./held 变体分别需要 <code class="language-plaintext highlighter-rouge">15-51</code> 次与 <code class="language-plaintext highlighter-rouge">50-169</code> 次，三者的平均奖励相当，重规划次数少 20-80 倍。</p>

<p>论文同时说明自身局限：在 Forced Coordination 布局上收益较小，底层规划器的局限在该设置下更为明显，论文明确识别出选择性重规划收益有限的设置。规划器以 GPT-4o 为主配置，论文另以 GPT-5.2 做 backbone 敏感性检查，两种 backbone 互有胜负、无一一致占优。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2608.18490">Bayesian Partner Modelling enables Adaptive Replanning for LLM Coordination（arXiv:2608.18490v1）</a></li>
  <li><a href="https://arxiv.org/html/2608.18490v1">论文 HTML 全文</a></li>
  <li><a href="/one-minute-read-paper-brainpilot-automating-brain-discovery/">BrainPilot 多 Agent 科研系统</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="MultiAgent" /><category term="llm" /><category term="multi-agent" /><category term="planning" /><summary type="html"><![CDATA[论文提出 BayesBeliefAgent，用贝叶斯后验追踪队友技能，仅在动作与信念矛盾时中断并重规划；Overcooked 上 belief-action gap 从 0.41 降到 0.20，重规划次数减少 20-80 倍。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/bayes-belief-agent-framework.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/bayes-belief-agent-framework.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《最佳选手未必是最佳教练》</title><link href="https://unbug.github.io/one-minute-read-paper-best-player-not-best-coach/" rel="alternate" type="text/html" title="一分钟读论文：《最佳选手未必是最佳教练》" /><published>2026-08-20T00:00:00+00:00</published><updated>2026-08-20T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-best-player-not-best-coach</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-best-player-not-best-coach/"><![CDATA[<p>加州大学伯克利分校哈斯商学院数据创新与人工智能实验室（DIAL）的论文<a href="https://arxiv.org/abs/2608.18554">《CentaurBench: Benchmarking LLM Capabilities on Augmenting vs. Automating Real-World Work Tasks》</a>发现，大语言模型的”自动化”能力与”增强”能力几乎不相关：最会自己干活的”选手”，未必是最会指导别人干活的”教练”。论文用统一框架在 7 个真实工作任务上评测 9 个助手模型，每任务独立重复 10 次，两种角色排名的模型级 Spearman 相关仅 <code class="language-plaintext highlighter-rouge">0.48</code>（p=0.187），在常规显著性水平下与零不可区分。</p>

<h2 id="两种角色一套框架">两种角色，一套框架</h2>

<p>自动化模式下，助手模型直接产出交付物；增强模式下，助手只写一段 200-250 词的过程性指导文本，实际交付物由固定的工人模型 GPT-3.5-Turbo 完成。9 个助手模型来自 Claude、Gemini、DeepSeek 与 GPT 四个家族，固定弱工人是为了模拟实践中强模型指导弱模型的常见配置。7 个任务都来自有经济意义的真实场景：咨询、旅行规划、菜单规划、报税、辅导、运筹与市场趋势分析。评分由 LLM 评审团盲评两两对比，使用任务专属评分标准，且评审模型不评价自家模型的输出。</p>

<p><img src="/assets/images/centaur-bench-augment-vs-automate.svg" alt="CentaurBench 框架：自动化与增强两种角色" /></p>

<h2 id="选手排名与教练排名对不上">选手排名与教练排名对不上</h2>

<p>任务级相关从 -0.04（旅行规划）到 0.85（报税，p=0.004）不等，仅报税通过 Bonferroni 校正。7 个任务中有 5 个的”增强冠军”与”自动化冠军”不是同一个模型。下文排名均为 10 次重复的平均排名，1 表示最佳。论文给出两组角色反转：市场趋势任务上，Claude-Opus-4.8 自动化平均排名 2.05，增强却只有 8.15，是最弱的助手之一；咨询任务上 GPT-4.1 正好相反，增强排名 3.80 为所有受助条件最佳，自动化排名却只有 7.40。这些差异在 10 次独立重复后依然稳定。</p>

<h2 id="指导有时帮倒忙">指导有时帮倒忙</h2>

<p>无指导的 GPT-3.5-Turbo 基线在运筹、报税、旅行规划三个任务上排名第一，胜过所有”受助”条件。GPT-5-Mini 是唯一在自动化与增强两种方案下平均排名都第一的模型；在增强对比中，无指导基线的整体平均排名第二（3.79），唯一整体优于它的受助条件就是 GPT-5-Mini（3.66）。作者认为这不是指导无用的证据，而是说明指导的价值依任务而定、甚至可以为负：匹配不当或过于复杂的指导，会让工人比独自工作表现更差。</p>

<h2 id="局限与启示">局限与启示</h2>

<p>论文自称 pilot 研究，并列出明确局限：依赖 LLM 评审而非人类专家判断，评审偏差无法完全消除；增强只测一次性指导文本，未测多轮交互；工人固定为 GPT-3.5-Turbo，结论能否迁移到其他工人未知；7 个任务、10 次重复的覆盖面有限。其核心启示是自动化能力是协助质量的不完全代理，合适的模型取决于它扮演的角色与支持的任务，模型选型应当依据角色而非单一榜单。此前介绍的<a href="/one-minute-read-paper-bayes-belief-agent-adaptive-replanning/">《贝叶斯伙伴建模与 LLM 协同重规划》</a>关注 LLM 与动态伙伴的协同重规划，CentaurBench 则回答一个更基础的问题：哪个模型适合扮演哪个角色。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2608.18554">CentaurBench: Benchmarking LLM Capabilities on Augmenting vs. Automating Real-World Work Tasks（arXiv:2608.18554v1）</a></li>
  <li><a href="https://arxiv.org/html/2608.18554v1">论文 HTML 全文</a></li>
  <li><a href="https://github.com/kennywong524/best-player-not-best-coach">代码仓库</a></li>
  <li><a href="https://kennywong524.github.io/centaur-benchmark">CentaurBench 项目页</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="LLM" /><category term="llm" /><category term="benchmark" /><category term="multi-agent" /><summary type="html"><![CDATA[UC Berkeley Haas 的 CentaurBench 在 7 个真实工作任务上对比 LLM 的自动化与增强两种角色，模型级排名相关仅 0.48，5/7 任务冠军不同，无指导基线在 3 个任务胜过所有指导。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/centaur-bench-augment-vs-automate.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/centaur-bench-augment-vs-automate.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《工具调用的苦涩教训》</title><link href="https://unbug.github.io/one-minute-read-paper-bitter-lesson-tool-calling/" rel="alternate" type="text/html" title="一分钟读论文：《工具调用的苦涩教训》" /><published>2026-08-18T00:00:00+00:00</published><updated>2026-08-18T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-bitter-lesson-tool-calling</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-bitter-lesson-tool-calling/"><![CDATA[<p>普华永道美国（PricewaterhouseCoopers U.S.A.）的论文<a href="https://arxiv.org/abs/2608.06370">《The Bitter Lesson of Tool Calling》</a>（v1 提交于 <code class="language-plaintext highlighter-rouge">2026</code> 年 <code class="language-plaintext highlighter-rouge">8</code> 月），在伯克利函数调用基准（Berkeley Function-Calling Leaderboard，BFCL）v4 上用 <code class="language-plaintext highlighter-rouge">14</code> 个模型系统对比了两种工具调用范式：JSON tool calling（模型输出 JSON 函数调用）与 programmatic tool calling（PTC，模型写 Python 代码调用类型化 stub）。核心发现是 PTC 在 <code class="language-plaintext highlighter-rouge">11/14</code> 的模型上持平或更优、长链任务领先 <code class="language-plaintext highlighter-rouge">18.8%</code>，但全模型宏平均反而略低——优势随模型代际而非厂商分化。</p>

<h2 id="两种范式与实验设置">两种范式与实验设置</h2>

<p>JSON tool calling 是主流大语言模型 API 的原生接口：模型每轮输出一个 JSON 函数调用，执行结果回填后再进入下一轮推理，工具序列的每一步都对应一次独立的模型往返。PTC 则让模型直接写一段 Python 代码，通过类型化 stub（带签名约束的占位函数）在程序内循环、条件分支地调用工具，整段代码一次性生成并整体执行。BFCL v4 是评估大语言模型函数调用与工具使用能力的基准；实验取其 <code class="language-plaintext highlighter-rouge">309</code> 条代表性子集与 <code class="language-plaintext highlighter-rouge">8</code> 个任务类别，覆盖 <code class="language-plaintext highlighter-rouge">2024</code> 年 <code class="language-plaintext highlighter-rouge">11</code> 月至 <code class="language-plaintext highlighter-rouge">2026</code> 年 <code class="language-plaintext highlighter-rouge">7</code> 月发布、跨厂商与代际的 <code class="language-plaintext highlighter-rouge">14</code> 个模型。需要强调：BFCL v4 使用 echo-return stub——函数原样返回参数、不执行真实 API，因此测的是<strong>参数序列化准确率</strong>，不是端到端工具执行正确性。本站此前报道的 <a href="/paradigm-radar-codeact-agent-execution/">CodeAct 智能体执行范式雷达</a> 记录了微软将代码作为智能体执行接口的产品化动向，本篇是该路线在基准层面的量化补充。</p>

<p><img src="/assets/images/bitter-lesson-tool-calling.svg" alt="两种工具调用范式对比：JSON tool calling 与 PTC 在 BFCL v4 上的关键数字" /></p>

<h2 id="优势从哪里来">优势从哪里来</h2>

<p>PTC 的收益集中在三类场景。<strong>链式任务</strong>：链条长度达到 <code class="language-plaintext highlighter-rouge">12</code> 步以上时，PTC 较 JSON tool calling 拉开 <code class="language-plaintext highlighter-rouge">18.8%</code> 的绝对差距，短链无此效应；原因是 JSON 范式每个环节多一次推理回合，往返开销随链条累积，而 PTC 在一段程序内完成全部调用。<strong>并行扇出</strong>：JSON tool calling 超过一定阈值后直接丢弃工具调用（阈值因模型而异，Claude Sonnet 5 的为 <code class="language-plaintext highlighter-rouge">N=70–72</code>），PTC 在 <code class="language-plaintext highlighter-rouge">N=100</code> 仍保持 <code class="language-plaintext highlighter-rouge">100%</code> 枚举准确率，暴露了原生范式的结构性硬上限；并行场景 PTC 在 <code class="language-plaintext highlighter-rouge">14</code> 个模型中 <code class="language-plaintext highlighter-rouge">13</code> 个持平或更优。<strong>上下文污染</strong>（context flooding）：向上下文注入大量无关内容后，PTC 平均绝对提升 <code class="language-plaintext highlighter-rouge">5.5%</code>，JSON 基线平均退化 <code class="language-plaintext highlighter-rouge">2.3%</code>，文件系统发现式对比方法退化 <code class="language-plaintext highlighter-rouge">32%</code>。模型代际上，GPT-5.6 家族收益最大：GPT-5.6-Sol 与 GPT-5.6-Terra 各自较自身 JSON 基线绝对提升 <code class="language-plaintext highlighter-rouge">10.6%</code>，OpenAI 最新三个 GPT-5.6 变体全部为正（<code class="language-plaintext highlighter-rouge">+4.2%</code> 至 <code class="language-plaintext highlighter-rouge">+10.6%</code>），而三个旧模型未达持平线。</p>

<h2 id="边界与成本取舍">边界与成本取舍</h2>

<p>PTC 并非全面胜出。全模型宏平均上 PTC 反而略低：BFCL v4 主评测 JSON <code class="language-plaintext highlighter-rouge">78.6%</code> vs PTC <code class="language-plaintext highlighter-rouge">77.0%</code>，差距主要由三个 OpenAI 旧模型（GPT-4o、GPT-4.1、GPT-5.4-mini）在并行类别的 <code class="language-plaintext highlighter-rouge">\n</code> 编码失败驱动；「持平或更优」是逐模型口径，两种口径方向相反。成本上，链式消融中 PTC 输入 token 为 JSON tool calling 的 <code class="language-plaintext highlighter-rouge">1.5</code> 倍，高扇出时该开销反转；输出 token 两范式无差异，PTC 属以固定输入开销换取长链与高扇出收益的取舍。此外，消融样本量较小（每条件 n=<code class="language-plaintext highlighter-rouge">31–52</code>），单模型结果置信区间宽，只有跨模型聚合模式可可靠解读；论文明确将 echo-return stub、消融样本量小与 PTC 的固定输入 token 开销列为自身局限。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2608.06370">The Bitter Lesson of Tool Calling（arXiv:2608.06370v1）</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="LLM" /><category term="llm" /><category term="tool-use" /><category term="benchmark" /><summary type="html"><![CDATA[普华永道美国团队在 BFCL v4 上用 14 个模型对比 JSON 工具调用与程序化工具调用：PTC 在 11/14 的模型上持平或更优、长链任务领先 18.8%，但全模型宏平均反而略低，优势随模型代际而非厂商分化。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/bitter-lesson-tool-calling.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/bitter-lesson-tool-calling.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《G0.5：单流自回归统一机器人推理与动作》</title><link href="https://unbug.github.io/one-minute-read-paper-g05-single-autoregressive-stream/" rel="alternate" type="text/html" title="一分钟读论文：《G0.5：单流自回归统一机器人推理与动作》" /><published>2026-08-17T00:00:00+00:00</published><updated>2026-08-17T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-g05-single-autoregressive-stream</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-g05-single-autoregressive-stream/"><![CDATA[<p>上海机器人公司银河通用（Galaxea）的论文<a href="https://arxiv.org/abs/2608.11739">《G0.5: One Autoregressive Stream for Robot Reasoning and Action》</a>，提出预训练自回归视觉-语言-动作模型（VLA）G0.5：单一 transformer decoder 在同一 token 流中同时输出推理与动作。主流 VLA 配方把预训练视觉语言模型（VLM）当上下文编码器、另配独立 flow-matching 动作专家（通过回归向量场生成连续动作），使 VLM 只负责编码上下文；G0.5 让 VLM 直接成为决策者。相对主流配方，这是架构层面的改变而非训练技巧。真机微调成功率 <code class="language-plaintext highlighter-rouge">76.7%</code>，超过 π0.5 的 <code class="language-plaintext highlighter-rouge">53.3%</code> 和 GR00T-N1.7 的 <code class="language-plaintext highlighter-rouge">24.4%</code>；模型权重已开放，为社区验证这一路线提供了可复现起点。</p>

<h2 id="单流自回归架构">单流自回归架构</h2>

<p>G0.5 在大规模机器人轨迹数据集与 VQA（视觉问答）样本上联合预训练，由三个组件支撑。跨本体可学习动作 tokenizer：把 <code class="language-plaintext highlighter-rouge">14</code> 种本体的异构机器人动作映射到共享词表（统一 <code class="language-plaintext highlighter-rouge">27</code> 维动作空间），使不同机器人的动作用同一套 token 表示。原生思维链流：任务分解、物体定位与动作提示等推理 token 与动作 token 交替出现在同一条自回归序列中，由单一目标函数训练；这种交错排列意味着模型在生成的每一步先输出对任务状态的判断再给出动作，推理不是外挂模块，而是动作生成过程本身的一部分。视觉记忆模块：通过视觉编码器注入数秒级历史观测，弥补单帧输入的时序信息缺失。</p>

<p><img src="/assets/images/g05-single-autoregressive-stream.svg" alt="G0.5 单流自回归架构：推理与动作共享同一 transformer decoder" /></p>

<p>推理与动作共享同一套权重是这一设计的直接后果：VLM 预训练获得的指令跟随能力可以迁移到物理行为上，模型对指令的遵循也更紧密。本站此前解读的 <a href="/one-minute-read-paper-w0-latent-predictive-world-action-model-for-concurrent-humanoid-loco-manipulation/">w-0 世界动作模型</a> 走的是预测未来潜变量再生成动作的路线，G0.5 则直接改造策略架构本身，两者属于不同层面的工作。</p>

<h2 id="实验结果">实验结果</h2>

<p>论文在 <code class="language-plaintext highlighter-rouge">7</code> 个独立评测设置中报告了结果。真机实验使用公司自研的 R1-Lite 与 R1-Pro 机器人（4 任务 6 配置）微调后：成功率 <code class="language-plaintext highlighter-rouge">76.7%</code>，π0.5 为 <code class="language-plaintext highlighter-rouge">53.3%</code>，GR00T-N1.7 为 <code class="language-plaintext highlighter-rouge">24.4%</code>。2025 BEHAVIOR Challenge（50 个长程家庭移动操作任务，每个任务跨感知、规划与执行多个阶段）：G0.5 以单一通用策略 checkpoint 取得 <code class="language-plaintext highlighter-rouge">31.4%</code>，超过 π0.5 的 <code class="language-plaintext highlighter-rouge">26.3%</code> 与冠军方案 RLC 的 <code class="language-plaintext highlighter-rouge">26.1%</code>；仅训练 <code class="language-plaintext highlighter-rouge">1</code> epoch 即达 <code class="language-plaintext highlighter-rouge">29.0%</code>，已高于 π0.5。DROID 后训练后向未见环境与物体的零样本迁移（Franka 臂、10 任务）成功率 <code class="language-plaintext highlighter-rouge">82.5%</code>；LIBERO <code class="language-plaintext highlighter-rouge">98.9%</code>、RoboTwin 2.0 <code class="language-plaintext highlighter-rouge">93.3%</code>、SimplerEnv-Bridge <code class="language-plaintext highlighter-rouge">87.3%</code>，另在语言跟随 Pick-and-Place 基准上超过现有模型。论文还显示，仅修改 prompt 即可调节动作粒度、任务时程与分布外场景处理而无需再训练，这类部署侧调优不再依赖新数据采集或微调。</p>

<h2 id="边界条件">边界条件</h2>

<p>需要指出三点边界：</p>

<ul>
  <li>BEHAVIOR 的绝对成功率仅约 <code class="language-plaintext highlighter-rouge">31.4%</code>，冠军方案 RLC 本身也只有约 <code class="language-plaintext highlighter-rouge">26%</code>，该基准整体仍属困难问题，长程家庭任务远未解决；</li>
  <li>真机实验每配置仅 <code class="language-plaintext highlighter-rouge">15</code> episodes、共 4 个任务，样本量偏小，且为团队自报数据；</li>
  <li>“7 independent regimes” 混合了不同评测协议与数据集，横向可比性有限。</li>
</ul>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2608.11739">G0.5 论文（arXiv:2608.11739v1）</a></li>
  <li><a href="https://droid-dataset.github.io/">DROID 机器人操作数据集项目页</a></li>
  <li><a href="https://libero-project.github.io/">LIBERO 基准项目页</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="embodiedai" /><category term="robotics" /><category term="embodied-ai" /><category term="vlm" /><category term="reasoning" /><category term="long-horizon" /><summary type="html"><![CDATA[银河通用发布开放权重 VLA 模型 G0.5，用单一自回归流同时生成推理与动作 token，真机微调成功率 76.7%，超过 π0.5 的 53.3%。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/g05-single-autoregressive-stream.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/g05-single-autoregressive-stream.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《SABLE：智能体编排的先导化合物优化》</title><link href="https://unbug.github.io/one-minute-read-paper-sable-dmta-computational-twin/" rel="alternate" type="text/html" title="一分钟读论文：《SABLE：智能体编排的先导化合物优化》" /><published>2026-08-17T00:00:00+00:00</published><updated>2026-08-17T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-sable-dmta-computational-twin</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-sable-dmta-computational-twin/"><![CDATA[<p>美国北卡罗来纳大学教堂山分校（UNC Chapel Hill）的论文<a href="https://arxiv.org/abs/2608.11483">《A Modular Agentic Framework for Synthetically Constrained Multi-Objective Hit-to-Lead Optimization》</a>，提出开源智能体框架 SABLE（Synthetically-accessible Agentic Bayesian Ligand Exploration）：LLM 解析自然语言优化目标并路由任务，调度反应模板类似物枚举、ADMET 与理化性质预测、Boltz-2 结构亲和力打分、贝叶斯优化四类专用工具，构成药物发现「设计-合成-测试-分析」（DMTA）循环中分析与优先级排序阶段的<strong>计算孪生体</strong>。METTL3 回顾性案例中，单次运行即得到预测浓度 <code class="language-plaintext highlighter-rouge">102.33 nM</code> 的头部类似物（相对起始化合物约 <code class="language-plaintext highlighter-rouge">95</code> 倍预测活性提升），且论文明确该候选未经湿实验验证、属前瞻性优先级排序。</p>

<h2 id="核心问题与方法">核心问题与方法</h2>

<p>先导化合物优化要求在效力、选择性、药代动力学、安全性与合成可行性等竞争约束下迭代设计类似物，传统流程依赖人工逐轮执行 DMTA 循环。SABLE 将该循环的分析与优先级排序阶段搬到计算侧：用户以自然语言下达目标（如最小化对 METTL3 的预测亲和力），<strong>LLM 编排层</strong>解析出优化目标与迭代预算并路由任务；HEALER 反应模板引擎枚举合成可及的类似物库，RDKit 与 STOPLIGHT 提供理化性质和 ADMET 预测，Boltz-2 从蛋白序列与配体输入联合预测复合物结构与亲和力分数（logIC50），贝叶斯优化迭代挑选候选。每个数值输出均记录来源工具与调用参数、可逐条回溯；模块化架构下仅需编辑配置文件即可替换枚举引擎或表征后端。本站此前解读的 <a href="/one-minute-read-paper-brainpilot-automating-brain-discovery/">BrainPilot 多 Agent 科研系统</a> 同样以可追溯性为核心设计；SABLE 则把可溯源落到每个数值输出的工具级出处，复现所需提示词与 JSON 状态转储随代码仓库开源。</p>

<p><img src="/assets/images/sable-dmta-computational-twin.svg" alt="SABLE 智能体编排架构：LLM 路由到四个专用工具，构成 DMTA 计算孪生体" /></p>

<h2 id="实验结果">实验结果</h2>

<p>实验覆盖单目标、双目标与四靶点三类优化战役。单目标战役以 CAMKK2（UniProt Q96RR4）为靶点：最佳观测预测 logIC50 较种子改善 <code class="language-plaintext highlighter-rouge">1.03</code> 个 log 单位（–0.52 到 –1.55），前 <code class="language-plaintext highlighter-rouge">20</code> 名候选的累积分布在约 <code class="language-plaintext highlighter-rouge">5</code> 次迭代后进入平台期。双目标战役同时优化 Boltz-2 预测亲和力与类药性 QED，得到覆盖不同折中点的非支配解集。四靶点案例选取 BACE1、碳酸酐酶 XII、ABL1 与 S1P1 受体：ChEMBL 数据仅用于挑选低活性种子分子与参考化合物，优化过程未输入 SAR 轨迹或实验标签，唯一信号是 Boltz-2 分数；找到的类似物在预测亲和力上达到或超过各系列最佳化合物，其中 BACE1 的种子从预测 <code class="language-plaintext highlighter-rouge">58.88 µM</code> 改善到 <code class="language-plaintext highlighter-rouge">370 nM</code>。效率上，收敛前仅评估枚举库的一小部分，相对穷举筛选的 Boltz-2 推理调用节省量在 <code class="language-plaintext highlighter-rouge">10^3</code>–<code class="language-plaintext highlighter-rouge">10^6</code> 规模库上随库大小近似线性增长。METTL3 回顾性案例中，起始化合物预测 IC50 为 <code class="language-plaintext highlighter-rouge">9.77 µM</code>（实验值约 <code class="language-plaintext highlighter-rouge">7 µM</code>），单次运行得到的头部类似物即上述 <code class="language-plaintext highlighter-rouge">102.33 nM</code> 候选。</p>

<h2 id="局限与风险">局限与风险</h2>

<p>第一，<strong>全部结果均为计算预测</strong>：Boltz-2 在 SABLE 中只充当计算预言机（oracle，昂贵评估的代理模型）而非实测生化效力的替代；<code class="language-plaintext highlighter-rouge">95</code> 倍提升是预测值，头部候选未经任何湿实验验证。第二，回顾性案例存在对已知 SAR（构效关系）过拟合的风险；论文声明优化信号仅为 Boltz-2 分数、未输入 SAR 轨迹与实验标签，但 ChEMBL 种子选择本身来自已发表系列。第三，框架性能受限于枚举引擎反应模板的覆盖度与表征模型的校准质量，且缺少与其他 agentic 药物发现系统的正面基线对比；论文将其定位为支持而非取代药物化学评审与实验验证，把纳入真实 DMTA 实验闭环列为后续工作。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2608.11483">SABLE 论文（arXiv:2608.11483v1）</a></li>
  <li><a href="https://github.com/molecularmodelinglab/SABLE">SABLE 代码仓库（Apache 许可开源）</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="DrugDiscovery" /><category term="drug-discovery" /><category term="llm-agent" /><category term="dmta" /><category term="bayesian-optimization" /><summary type="html"><![CDATA[北卡罗来纳大学教堂山分校开源 SABLE 框架，用 LLM 编排反应模板枚举、性质预测、亲和力打分与贝叶斯优化，构成 DMTA 分析的计算孪生体；METTL3 回顾性案例单次运行得到预测活性提升约 95 倍的候选分子。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/sable-dmta-computational-twin.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/sable-dmta-computational-twin.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry><entry><title type="html">一分钟读论文：《近端文本梯度下降驱动的智能体技能自进化》</title><link href="https://unbug.github.io/one-minute-read-paper-skillprox-self-evolving-agent-skills/" rel="alternate" type="text/html" title="一分钟读论文：《近端文本梯度下降驱动的智能体技能自进化》" /><published>2026-08-17T00:00:00+00:00</published><updated>2026-08-17T00:00:00+00:00</updated><id>https://unbug.github.io/one-minute-read-paper-skillprox-self-evolving-agent-skills</id><content type="html" xml:base="https://unbug.github.io/one-minute-read-paper-skillprox-self-evolving-agent-skills/"><![CDATA[<p>香港科技大学与澳门大学的论文<a href="https://arxiv.org/abs/2608.07449v1">《SkillProx: Self-Evolving Agent Skills via Proximal Textual Gradient Descent》</a>，针对智能体技能（由主指令文件 SKILL.md 和可选引用资源目录构成的结构化文本工件）提出受近端梯度下降（交替执行任务损失方向步与正则约束子问题求解的优化算法）启发的”前向-后向”双阶段框架：前向闭环诊断演化验证每次编辑的实际效果，后向效用感知近端精炼审计并收缩累积知识。在 SpreadSheetBench、WikiTQ 和 HiTab 三个基准上，SkillProx 相比最强基线 SkillGrad 平均提升约 <code class="language-plaintext highlighter-rouge">3.0</code> 个百分点，且分布外（OOD）泛化显著更稳：Qwen3.5-4B 下 SkillOpt 的 OOD 得分在 WikiTQ、HiTab 上分别跌至 <code class="language-plaintext highlighter-rouge">26.0</code> 和 <code class="language-plaintext highlighter-rouge">16.0</code>，SkillProx 则达到 <code class="language-plaintext highlighter-rouge">78.5</code> 与 <code class="language-plaintext highlighter-rouge">69.2</code>。</p>

<h2 id="技能演化的两个核心问题">技能演化的两个核心问题</h2>

<p>现有方法如 SkillGrad、SkillOpt 和 EvoSkill 在技能演化中暴露出两个根本缺陷。第一个是<strong>无验证的前向更新</strong>：LLM 生成的诊断被直接当作有效更新方向提交，未经重新执行验证实际效果，某些看似合理的编辑反而降低任务性能。第二个是<strong>不受控的技能增长</strong>：迭代打补丁使技能膨胀为重复指令、冲突启发式与过度泛化的特定解法；留一法审计发现存在负效用知识单元——移除它们反而将准确率从 <code class="language-plaintext highlighter-rouge">46%</code> 提升到 <code class="language-plaintext highlighter-rouge">54%</code>。SkillProx 将技能演化形式化为复合优化问题：最小化任务损失（期望准确率）与文本复杂度（总字符数）的加权和，为双阶段设计提供理论基础。</p>

<h2 id="前向-后向双阶段框架">前向-后向双阶段框架</h2>

<p><img src="/assets/images/skillprox-forward-backward-framework.svg" alt="SkillProx 闭环诊断演化与近端精炼双阶段框架" /></p>

<p>核心创新是将技能演化分解为两个正交阶段，分别对应标准近端梯度下降的前向梯度步与后向近半步。<strong>前向——闭环诊断演化</strong>：在当前技能上执行训练批次后，诊断器分析失败轨迹、成功轨迹与拒绝原因提出编辑方向（智能体轨迹中的错误分析方法可参考<a href="/one-minute-read-paper-trajdebug-error-lifecycle-agent-trajectories/">《追踪错误生命周期以识别长程 Agent 轨迹中的关键失败》</a>）；Patcher 生成候选技能后在同批次重执行验证，仅当硬准确率与平均单元格准确率同时不下降才接受更新，被拒绝的编辑及其性能变化注入后续诊断形成语义历史。<strong>后向——验证门控近端精炼</strong>：将技能解析为可审计的知识单元（二级章节与三级引用组），对每个单元执行冻结留一法效用审计计算边际贡献，按单元格效用升序排列、负效用优先处理；Shrinker 生成的临时副本须满足结构有效、复杂度严格降低、硬准确率不下降且单元格准确率降幅不超过阈值。前向决定哪些新知识进入技能，后向决定哪些累积知识保留。</p>

<h2 id="实验结果与局限">实验结果与局限</h2>

<p>在 Qwen3.5-4B、Qwen3.5-27B 和 Qwen3.6-27B 三个骨干模型上的实验提供了关键证据。IID 任务上 SkillProx 全面领先：Qwen3.6-27B 下 SpreadSheetBench <code class="language-plaintext highlighter-rouge">54.5</code>（最佳）、WikiTQ <code class="language-plaintext highlighter-rouge">86.2</code>、HiTab <code class="language-plaintext highlighter-rouge">80.0</code>（最佳），较 SkillGrad（<code class="language-plaintext highlighter-rouge">50.0/84.8/78.3</code>）分别提升 4.5、1.4、1.7 个百分点；相比人工编写技能（<code class="language-plaintext highlighter-rouge">36.7/85.7/78.0</code>）IID 提升高达 <code class="language-plaintext highlighter-rouge">17.8</code> 个百分点。消融实验验证两阶段独立贡献：完整 SkillProx（<code class="language-plaintext highlighter-rouge">54.5</code>）优于仅 Prox（<code class="language-plaintext highlighter-rouge">53.0</code>）与仅闭环诊断（<code class="language-plaintext highlighter-rouge">52.0</code>），移除 Prox 降幅更大（-2.5pp），说明仅靠前向编辑会积累冗余内容。压缩-准确率权衡显示，tau=-0.001 时达到最佳准确率 <code class="language-plaintext highlighter-rouge">52.3%</code> 同时压缩 25.7%，即使移除 74.9% 技能内容仍保留 <code class="language-plaintext highlighter-rouge">51.0%</code> 准确率；最终技能长度与 IID 硬准确率负相关（r=-0.628）。局限方面，评估仅覆盖三个高度结构化的表格基准，效果能否推广到更开放的编程或推理场景未知；留一法审计需对每个知识单元执行完整评估，LLM 调用开销大；Prox 门控基于固定验证集，存在过拟合风险。</p>

<h2 id="references">References</h2>
<ul>
  <li><a href="https://arxiv.org/abs/2608.07449v1">SkillProx 论文（arXiv:2608.07449v1）</a></li>
  <li><a href="https://github.com/Steven011018/SkillProx">SkillProx 代码仓库</a></li>
</ul>]]></content><author><name>unbug</name></author><category term="AI" /><category term="Agent" /><category term="agentic-coding" /><category term="self-evolving" /><category term="agent-skills" /><summary type="html"><![CDATA[香港科技大学与澳门大学提出 SkillProx，用闭环诊断演化加近端精炼双阶段框架实现智能体技能自进化，在三个表格基准上平均提升约 3 个百分点，分布外泛化显著更稳。]]></summary><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://unbug.github.io/assets/images/skillprox-forward-backward-framework.svg" /><media:content medium="image" url="https://unbug.github.io/assets/images/skillprox-forward-backward-framework.svg" xmlns:media="http://search.yahoo.com/mrss/" /></entry></feed>