Act While Thinking: Accelerating LLM Agents via Pattern-Aware Speculative Tool Execution #

Yifan Sui, Han Zhao, Rui Ma, Zhiyuan He, Hao Wang, Jianxun Li, Yuqing Yang | 2026-03 | https://arxiv.org/abs/2603.18897 Category: agent | Tags: serving, speculation, scheduling, tool-execution, latency-optimization Read: 2026-04-20

TL;DR #

PASTE 通过模式感知的推测性工具执行（speculative tool execution）将 agent 任务完成时间缩短 48.5%、工具执行吞吐提升 1.8×。核心思路：agent 的 tool 调用序列虽然语义多变，但在应用层存在稳定的控制流模式（如 search→fetch、edit→test）和可预测的数据依赖（参数来自前序 tool 输出），PASTE 用 Pattern Tuple $(C, T, f, p)$ 形式化这些模式，在 LLM 还在"思考"时就提前投机执行下一个 tool。

Core Contribution #

提出 Pattern Tuple $(C, T, f, p)$ 抽象将 agent tool-call 的控制流和数据流解耦，配合风险感知的投机调度器，在不影响正确性的前提下实现 tool execution 与 LLM generation 的时间重叠，将 agent 端到端延迟降低 48.5%。

Summary #

动机：LLM Agent 以串行的 "LLM→Tool→LLM→Tool" 循环执行任务，tool 执行占总时间 35%-61%（§2.2, Figure 3a）。现有优化要么关注 cold start（仅占工具时间 <20%，Figure 3b），要么优化 LLM serving 本身，都无法减少工具执行等待时间。serverless 工作流优化（ORION, SpecFaaS）假设静态 DAG，不适用于 agent 的在线生成控制流。

方法：PASTE 以两个洞察为基础——(1) agent tool 调用在应用层呈现稳定的控制流模式（coding 中 55% 的 file_editor 后紧跟 pytest；deep research 中 51% 的 search 后跟 web_fetch），(2) tool 参数可从前序 tool 输出中符号推导（95% 的 URL 来自 search 结果）。PASTE 引入 Pattern Tuple $(C, T, f, p)$：$C$ 是控制流上下文（事件签名序列），$T$ 是预测目标工具，$f$ 是符号值映射函数（延迟绑定参数推导），$p$ 是置信概率。离线阶段通过 PrefixSpan 挖掘频繁序列 + 符号依赖推断构建 pattern pool；在线阶段通过 hash-map 匹配 $O(1)$ 查找触发预测。风险感知调度器将工作负载分为 authoritative（正确性关键）和 speculative（尽力而为、可抢占），投机任务仅使用 slack 资源，通过 promotion protocol 在匹配时零冗余提升。

结果：在 3 种 agent（Gemini-CLI、Qwen-DR、VirtualLab）×3 种 benchmark（DeepResearchBench、SWE-bench、ScholarQA）的全面评估中，PASTE 平均将 E2E 延迟降低 48.5%，p95/p99 尾延迟分别降低 48.6%/61.9%，tool 执行吞吐提升 1.8×。Pattern predictor 达到 27.8% Top-1 准确率、93.8% overall hit rate。资源开销极低：每减少 1 秒延迟仅消耗 0.02 core-seconds CPU、2.6 MB 内存。

Key Findings #

• Tool 执行占 agent 总延迟 35%-61%，是端到端延迟的主要瓶颈（§2.2, Figure 3a）
• Cold start 仅占工具时间 <20%，优化 cold start 对整体延迟贡献有限（§2.2.2, Figure 3b）
• Agent tool 调用存在强控制流模式：coding 中 55% edit→test、38% grep→edit；research 中 51% search→fetch（§2.3.1）
• 95% 的 URL 参数可从前序 search 结果中直接提取，参数推导是可行的（§2.3.2）
• PASTE 将 tool 等待时间减少 67%，overlap（tool 执行与 LLM 思考重叠）提升 10×（§7.3, Figure 13）
• 在并发度从 5 增至 100 时，PASTE 持续保持 1.76-2.05× 以上加速，投机不影响隔离性（§7.4）

Key Figures #

Figure 1: Example Patterns in Agent Workflows #

What it shows: 深度研究 agent (a) 和编码 agent (b) 中观察到的工具调用模式——Model Thinking（蓝色圆）与 Tool Execution（绿色方块）交替，橙色虚线箭头表示控制流模式（pattern-1: Search→Browse, pattern-2: Browse→Browse, pattern-3: Run Test→Install Missing Packages）。

Why it matters: 这是整篇论文的 motivation 图，直观展示了"虽然 agent 请求语义多样，但应用层存在可预测的控制流模式"这一核心洞察。

Detailed description: 图分为两部分。(a) Deep research agent：Search tool 执行后，LLM 思考，然后调用 Browse，再次思考后又调用 Browse。pattern-1 连接 Search→第一个 Browse，pattern-2 连接第一个 Browse→第二个 Browse，体现级联 fetch 模式。(b) Coding agent：Run Test 执行后，LLM 思考，再次执行另一个 tool，然后 Install Missing Packages。pattern-3 显示 test 失败后安装缺失包的因果模式。

Figure 5: System Architecture of PASTE #

What it shows: PASTE 的完整系统架构——作为 middleware 层介入 Agent 和 Tool System 之间，包含 Event Extractor、Pattern Miner、Predictor、Speculative Scheduler 和 Speculative Invocation Arbiter 五大组件。

Why it matters: 这是论文的"灵魂图"，展示了 PASTE 如何将投机执行无缝嵌入现有 agent 运行时。

Detailed description: 顶层是 Agent，发出 Agent Tool Calls 进入 PASTE 中间件。Event Extractor 将工具调用标准化为事件签名，一路送给 Predictor 做在线预测，另一路送给 Pattern Miner 做离线挖掘。Pattern Miner 产出 Pattern Pool (P1, P2, P3...)。Predictor 从 Pattern Pool 查找匹配，生成 Speculative Tool Calls 送给 Speculative Scheduler。Scheduler 根据资源预算调度投机任务到 Spec Tool Procs，同时 Speculative Invocation Arbiter 管理 authoritative vs speculative 的优先级和 promotion。Tool System 包含 Agent Tool Procs（权威执行）和 Spec Tool Procs（投机执行，可抢占），Tool Call Results 反馈给 Pattern Miner 更新模式。

Figure 3a: Agent Time Breakdown (LLM vs Tools) #

What it shows: 四种 agent 配置下 LLM 调用与 Tool 调用的时间占比——Gemini-Coding (Tool ~52%), Gemini-DR (Tool ~43%), Qwen-DR (Tool ~61%), Virtual-Lab (Tool ~35%)。

Why it matters: 量化了论文的核心 motivation：tool 执行占总时间的大头，且跨 agent/benchmark 一致。

Figure 7: E2E Latency Comparison #

What it shows: PASTE 与 SpecFaaS、ORION 的 E2E 延迟对比柱状图。PASTE（绿色）在所有四种配置中均显著低于两个 baseline。

Why it matters: 主实验结果图，直接证明 PASTE 的有效性——average speedup 1.25×/1.32× over ORION/SpecFaaS。

Figure 13: Time Breakdown and Overlap Analysis #

What it shows: ORION、SpecFaaS、PASTE 三者的时间组成分解——Overlap Region（黄色）、Tool Execution（绿色）、Tool Stall（红色）、Spec. Overhead（橙色）。PASTE 的 overlap 区域显著大于 baseline，tool stall 大幅缩小。

Why it matters: 解释了 PASTE 加速的机制——不是减少 tool 执行本身的时间，而是通过投机执行将 tool 工作与 LLM generation 重叠，从而隐藏 tool stall。ORION 约 150s 中大量红色 stall；PASTE 约 100s 中大部分是绿色执行+黄色 overlap，stall 显著减少。

Key Tables #

Table 1: Example Pattern Definition #

Takeaway: Pattern Tuple 将控制流（C）和数据流（f）解耦——P1 在搜索成功后预测 fetch 第一个 URL；P2 在首次 fetch 失败后降级到第二个 URL，体现了 fallback 模式的形式化。

Table 2: Evaluation Setup #

Takeaway: 评估覆盖了 API 模型（Gemini, GPT）和本地部署模型（Qwen-30B），确保结论不依赖于特定 LLM。

Limitations #

• Pattern mining 依赖历史 trace 的代表性——新型 agent 工具或全新 workflow 缺乏足够 trace 时，pattern pool 覆盖率可能不足
• Top-1 预测准确率仅 27.8%，依赖 Top-3 recall（43.9%）和多候选投机来补偿——在资源紧张场景下加速收益可能下降
• 论文未讨论 pattern pool 的规模增长和维护成本——长期运行后 pattern 数量爆炸或 drift 问题
• 投机执行的 side-effect 管理依赖用户/运维定义的 policy，未提供自动 side-effect 推断——policy 不完善时可能遗漏危险操作
• 评估仅在 4 节点集群上进行，未验证更大规模（100+ 并发 agent）下的表现

Infrastructure Impact #

• Algorithm: N/A — PASTE 不涉及训练算法，纯推理时优化
• Kernel: 间接影响 — 投机执行增加了 GPU 利用率管理的复杂性，若 tool 涉及 GPU kernel 执行，需要更精细的资源隔离
• Framework: 核心影响 — PASTE 作为 middleware 层可集成到 vLLM、SGLang 等 serving framework 的 tool-calling pipeline 中，为 agent serving 增加投机执行层
• LLM: 模型无关 — 不要求特定模型能力，但 function calling 能力越强的模型，tool-call 模式越稳定，PASTE 收益越大
• Agent: 直接影响 — 改变了 agent serving 的执行模型：从串行 LLM→Tool 循环到部分并行的 pipeline 架构，为 agent runtime 设计提供了新范式
• Code: 实现为 ~12K LOC 的 middleware proxy（8K TypeScript + 4K Python），可作为 sidecar 部署

Deep Analysis (agent) #

1. Agent Architecture #

PASTE 不是一个 agent 本身，而是一个 agent serving 中间件。它位于 agent 和 tool execution backend 之间，作为 tool-serving proxy 运行。

• Agent type: 单 agent，但支持多种 agent 框架（VirtualLab、Qwen-DR、Gemini-CLI）
• Core loop: 不改变 agent 的 ReAct 循环，而是在循环外部拦截 tool calls 并注入投机执行
• Memory mechanism: Event window — 维护有界的最近事件窗口 $E = \langle e_1, \ldots, e_k \rangle$，用于 pattern matching
• Tool use protocol: 透明代理 — agent 通过 PASTE HTTP proxy 发送 tool 请求，PASTE 记录 trace 并协调投机执行
• 决策机制: PASTE 不决定 agent 何时用 tool，而是在 agent 决定之前预测并提前执行

Figure 5: System Architecture of PASTE #

解读: PASTE 的分层架构体现了一个关键设计理念：最小化侵入。Agent 不需要修改任何代码，只需将 tool 请求路由到 PASTE proxy。PASTE 内部的 Event Extractor → Predictor → Scheduler 形成一个旁路的投机执行 pipeline，与 agent 的 authoritative execution 完全隔离。Speculative Invocation Arbiter 是两条路径的汇合点，负责 promotion（投机命中时复用结果）和 preemption（资源争用时抢占投机任务）。

2. Planning & Reasoning #

PASTE 不涉及 agent 的规划或推理——它工作在规划层之下的 执行层。

• Planning granularity: N/A — PASTE 不做任务分解，它处理的是已经分解后的 tool-call 序列
• Backtracking: 通过 Pattern P2 的 fallback 机制隐式处理——当首选路径失败时（如 Web_fetch 返回 fail），自动触发备选 pattern
• Reasoning approach: 纯模式匹配 — 不使用 CoT/ToT，而是基于历史 trace 的统计模式
• Ambiguity handling: 通过多 pattern 并行预测 + 置信度评分处理不确定性

3. Tool & Environment Interface #

• Available tools: PASTE 与具体 tool 无关——支持任意通过 HTTP proxy 路由的工具（web_search, web_fetch, file_editor, pytest, pip_install, git 等）
• Tool description format: 事件签名 = (tool_type, execution_status)，去除高基数的 payload 数据
• Error handling: 两层机制：(1) Pattern 本身编码失败后的恢复路径（如 P2 处理 fetch 失败后的 fallback），(2) Speculation Eligibility Policy 约束哪些 tool 可以投机执行
• Side-effect management (§5.2): 三级投机——side-effect-free tool 可完整投机（full），有副作用的 tool 限制为 dry-run 或 warm-up，由用户定义 policy 控制。论文报告 602/20000 (~3%) 的投机操作被检测为有潜在副作用并被阻止提交
• Sandboxing: 投机任务在隔离的 Spec Tool Procs 中运行，不会影响 Agent Tool Procs

4. LLM Backbone Requirements #

• Base model: 模型无关 — 评估覆盖 Gemini-2.5-Pro、GPT-5.2（API）和 Qwen-DeepResearch-30B（本地部署）
• Fine-tuning: 不需要 — PASTE 在 LLM 外部工作，不修改模型或 prompt
• Context window: 不增加额外 context 消耗 — pattern matching 和 prediction 完全在 PASTE 内部完成
• Latency sensitivity: 高度延迟敏感 — PASTE 的目标就是减少 agent 的端到端延迟，自身的 pattern 预测 + 调度开销 <100ms

5. Evaluation #

主实验结果 #

• Benchmarks: DeepResearchBench, SWE-bench, ScholarQA — 覆盖深度研究、软件工程、科学研究三大领域
• Agents: Gemini-CLI (coding + research), Qwen-DeepResearch, VirtualLab
• Baselines: ORION (serverless DAG 执行), SpecFaaS (投机 serverless 执行)

Figure 7: E2E Latency Comparison #

解读: 在所有 agent×benchmark 配置中，PASTE 的 E2E 延迟一致低于两个 baseline。Gemini-CLI:Research 场景收益最大（因为 research 任务的 search→fetch 模式高度规律），Virtual-Lab 收益也显著（科研 agent 的工具序列较为固定）。

• Failure analysis: 97% 的请求获得正加速（speedup > 1×），最差情况接近 parity（不损害性能）。Top-1 准确率仅 27.8%，但 overall hit rate 达 93.8%——因为 PASTE 可以同时投机多个候选
• Human evaluation: 无——论文关注系统性能而非 agent 任务质量

6. Multi-Agent #

N/A — PASTE 目前设计为单 agent session 内的优化。但论文的 scalability 实验（§7.4）表明在 100 并发 session 下仍保持 1.76×+ 加速，为 multi-agent 场景提供了基础。

7. Infrastructure Impact #

8. Production Readiness #

• Reliability: 97% 请求获得正加速，0% 产生不同最终结果——correctness 保证完整
• Safety: Speculation Eligibility Policy 提供三级投机控制（full/dry_run/warm-up），602/20000 有副作用的投机被阻止。但 policy 需要人工定义
• Observability: Event Extractor 本身就是一个 tracing 组件，记录所有 tool 调用的签名和 payload
• Scalability: 在 5-100 并发 session 范围内测试通过，资源隔离通过 slack budget 和 preemption 保证

9. Impact on AI Infra #

• Agent Serving 范式转变: PASTE 证明了 agent serving 可以从"被动等待 tool"转变为"主动预测+投机执行"。这可能影响 vLLM、SGLang 等框架的 tool-calling 实现——未来可能内置 pattern-based speculation
• Tool Execution 成为一等公民: 论文的 profiling 数据（tool 占 35-61% 时间）表明 tool execution 优化应该与 LLM inference 优化并重——这对 serving framework 的设计优先级有重大影响
• Middleware 架构: PASTE 的 sidecar 部署模式（~250 MB 内存，1-3 CPU cores）表明投机执行可以低成本地部署在现有 agent runtime 旁边
• 与 Speculative Decoding 的类比: 正如 speculative decoding 用小模型预测大模型的输出来加速 LLM inference，PASTE 用 pattern matching 预测 tool calls 来加速 agent execution——两者共享"投机+验证"的范式

Solution Justification #

作者证明 类型: Agent 类 — empirical sweep matrix + 简化的分析优化模型

Notation:

核心方程:

投机调度优化目标（Eq. 1）：

$$\max \sum_{j \in \mathcal{J}_s} x_j \cdot p_j \cdot T_j \quad \text{s.t.} \quad \sum_{j \in \mathcal{J}_s} x_j \cdot c_j \leq \min(R_{\text{slack}}, B)$$

物理含义: 在不超过 slack 资源和预算上限的约束下，最大化投机任务的期望延迟收益。这是一个标准的 0-1 背包问题。

为什么是 $\min(R_{\text{slack}}, B)$: $R_{\text{slack}}$ 是物理约束（实际可用资源），$B$ 是策略约束（运维设定的投机上限）。取 min 确保两个约束都满足——即使有大量空闲资源，也不允许投机占用超过预算。

贪心近似的优先级评分（Eq. 2）：

$$U(j_i) = \frac{p_i \cdot T_i}{c_i \cdot d_i}$$

物理含义: 单位资源-时间的期望收益。分子是"成功概率 × 延迟收益"（期望收益），分母是"资源成本 × 执行时间"（投入）。这是一个 ROI 度量——优先投机那些"成功率高、收益大、成本低、速度快"的任务。

单调性: $U$ 对 $p_i, T_i$ 单调递增，对 $c_i, d_i$ 单调递减。这意味着高置信、高收益、低成本的任务总是优先被调度——直觉正确。

模型→数字的一阶映射: 论文的 overall hit rate 达 93.8%（§7.5），意味着大多数投机任务的 $p$ 较高。同时 tool 执行减少 67%（§7.3），对应于 overlap analysis 中 PASTE 的黄色 overlap 区域远大于 baseline。资源开销（0.02 core-sec/s latency reduction）对应于 $c_i$ 项的实际数值——极低的 $c_i$ 使 $U$ 值偏高，解释了为什么 PASTE 可以激进投机而不浪费资源。

纯模型防守: "即使没有实验数据，仅凭 agent tool 调用的 trace 统计（55% edit→test, 95% URL from search），Pattern Tuple 的 confidence threshold $\tau$ 就能筛选出高收益投机目标；Eq. 2 的贪心排序确保在有限资源下最大化期望收益。"

可攻击面:

1. Eq. 1 的 0-1 背包模型假设各投机任务独立——但实际上多个投机任务可能共享资源（如同一个 Docker 环境），存在正/负外部性
2. $p_i$ 是从历史 trace 估计的静态值——在 distribution shift（新工具、新 workflow）时可能失准
3. 优先级评分 $U(j_i)$ 假设 $T_i, c_i, d_i$ 可准确估计——但 tool 执行时间的方差可能很大（网络请求延迟不可控）
4. 贪心近似对背包问题的 approximation ratio 约为 1/2——存在理论上的次优性

论证链重构 (Argument Chain Reconstruction) #

Step	Premise (引用)	Conclusion	Evidence	Load-bearing?
1	Agent 以串行 LLM→Tool 循环运行 (§2.1.2, Figure 2)	Tool 等待是 E2E 延迟的组成部分	架构约束	✓ 基础设定
2	Tool 执行占总时间 35%-61% (§2.2.1, Figure 3a)	Tool 等待是 主要 瓶颈	跨 3 benchmark × 3 agent 的实测数据	✓ 核心 motivation
3	Cold start 仅占 tool 时间 <20%；serverless DAG 假设不适用 (§2.2.2, Figure 3b)	现有方法无法有效减少 tool 执行时间	排除替代方案	✓ 必要条件
4	Agent tool 调用存在稳定控制流模式 (§2.3.1: 55% edit→test, 51% search→fetch)	下一个 tool 是可预测的	在 SWE-bench, MetaGPT, OpenHands 上的统计	✓ 方案可行性前提
5	Tool 参数可从前序输出推导 (§2.3.2: 95% URL from search results)	投机执行不只是预测 tool 类型，参数也可以提前获取	Producer-Consumer 模式分析	✓ 方案完整性前提
6	Pattern Tuple $(C, T, f, p)$ 解耦控制流和数据流 (§4.1, Table 1)	可以形式化、泛化、验证这些模式	抽象设计 + 挖掘算法	方案本身
7	风险感知调度 + promotion + preemption (§5, Algorithm 3)	投机不影响 authoritative 执行的正确性和性能	调度设计	✓ 安全性保证
8	PASTE 减少 E2E 延迟 48.5%, tool 吞吐 1.8×, 97% 请求正加速 (§7.2-7.3)	方案有效且 robust	全面实验	验证

Load-bearing steps: Steps 2, 4, 5 是核心——如果 tool 不是主要瓶颈（step 2 fail），或者 tool 调用不可预测（step 4 fail），或者参数无法推导（step 5 fail），PASTE 的整个论点就不成立。Step 7 是安全性保证——如果投机损害了 authoritative 性能，PASTE 就是 net negative。

核心技术壁垒 #

PASTE 的核心壁垒在于 Pattern Tuple 的 control-data flow decoupling。仅预测下一个 tool 类型（control flow）是相对容易的（transition probability），但要真正提前执行 tool，必须同时解决参数推导（data flow）。PASTE 的 value mapping function $f$ 是一个符号函数（field lookup, index+fallback, string normalization），而不是一个需要 LLM 生成的自由文本——这个设计选择是整个方案 work 的根本原因。如果 $f$ 需要调用 LLM 来生成参数，那投机执行的延迟就和 LLM 推理本身差不多，没有加速空间。$f$ 的简洁性（只覆盖 3 种常见变换）使得参数推导可以在 <100ms 内完成，比 LLM token-by-token 生成快几个数量级。

质疑假设 (Challenge Assumptions) #

1. Pattern 稳定性假设 (攻击 step 4): 论文假设 agent tool 调用的控制流模式在不同用户和任务间是稳定的（如 55% edit→test）。但这些统计来自 SWE-bench/MetaGPT/OpenHands 这些相对结构化的 benchmark。在真实生产环境中，用户行为多样性可能更大，agent 可能使用更多 custom tool，模式可能更碎片化。这部分笔者也不是十分确定——需要更多生产 trace 数据来验证。
1. 符号推导覆盖率假设 (攻击 step 5): $f$ 只支持 3 种变换（field lookup, index+fallback, string normalization）。论文报告 95% 的 URL 参数可以从 search 结果推导，但对于更复杂的参数（如代码 snippet、query string、config 对象），符号推导可能无法覆盖。论文未报告 $f$ 的 coverage rate across all tool parameters——只报告了 URL 的 95%。
1. Greedy approximation 质量 (攻击 作者证明 Eq. 1-2): 论文用贪心近似解 0-1 背包，但未讨论 approximation gap。在投机任务之间有资源依赖时（如多个投机 tool 共用 Docker container），greedy 可能选择次优组合。

生态现状校验: Agent serving 在 2025-2026 仍处于早期阶段。OpenAI Deep Research、Manus、Claude Code 等产品都面临 tool 延迟问题。PASTE 的核心假设（tool 调用有模式、参数可推导）在当前主流 agent 架构（ReAct loop）下是合理的。如果未来 agent 架构发生根本变化（如 tree search with backtracking, 或 model-internal tool execution），模式可能变得不可预测——但在当前 (2026-04) ReAct 仍是主流的 1-2 年窗口内，bet 是安全的。

设计绑定批判 (Design Binding Critique) #

1. 绑定 ReAct-style 串行循环 (对应 step 1, load-bearing): PASTE 的投机执行建立在"LLM 和 tool 严格交替"的假设上。如果 agent 架构允许 LLM 在一次推理中发出多个并行 tool calls（如 Anthropic 的 parallel tool use），投机执行的 overlap 空间会被压缩——因为 LLM 自己就在做并行化。但当前 (2026-04) 大多数 production agent 仍是串行循环，parallel tool use 在 serving 层面尚未成为标准。
1. 绑定 HTTP proxy 部署模式: PASTE 实现为 tool-serving proxy——agent 的 tool 请求必须路由到 PASTE。这要求 agent runtime 的 tool dispatch 接口可以被 wrap。对于 closed-source agent（如 OpenAI Agent SDK 的内部 tool dispatch），可能无法注入 PASTE。
1. 绑定离线 pattern mining: Pattern pool 需要从历史 trace 离线挖掘。对于新部署的 agent 或全新的 tool 集合，冷启动期没有 pattern 可用。论文提到 pattern mining 是 in-memory + periodic checkpoint，但未讨论冷启动策略（如跨 agent 的迁移学习）。

拆解 (Deconstruction) #

1. 事件提取: Agent tool 调用 → Event Extractor → 标准化事件签名 (tool_type, status)
2. 离线挖掘: 历史 trace → PrefixSpan → 候选 (C, T) → 符号依赖推断 → 验证 ($p \geq \tau$) → Pattern Pool
3. 在线预测: 实时事件窗口 $E$ → hash-map 查找匹配 pattern → 评估 $f$ 生成参数 → 发出 hint $(e_{pred}, p)$
4. 投机调度: Hint → Eligibility Policy 过滤 → $U(j) = p \cdot T / (c \cdot d)$ 排序 → 在 slack budget 内 greedy 调度
5. 执行管理: 投机任务在 Spec Tool Procs 中运行 → authoritative 请求到达时 → 匹配则 promote，不匹配则 preempt → 结果通过 unified cache 返回

实践上下文 (Deployment Context) #

• 适用场景: 任何使用 ReAct-style 循环的 LLM agent 系统——deep research、coding assistance、科研 workflow
• 部署方式: sidecar 部署在 agent runtime 旁边，~250 MB 内存 + 1-3 CPU cores，不需要额外 GPU
• 不适用: (1) one-shot inference（没有 tool 调用），(2) streaming chat（无 tool 循环），(3) 纯训练 workload
• 硬件无关: 不依赖特定 GPU 架构，CPU-only 即可运行 PASTE 本身（tool execution 的硬件需求由 tool 本身决定）

生态影响追踪 (Ecosystem Influence) #

• 与 Speculative Decoding 的关系: PASTE 将 speculative execution 的理念从 LLM token 生成层面扩展到 agent tool 执行层面——可以视为"speculative decoding for tools"
• 与 Sutradhara (2601.12967) 的互补: Sutradhara 优化 agent serving 的 GPU 资源管理（KV cache 在 tool 等待期间的释放/恢复），PASTE 优化 tool 执行本身的时间——两者可以叠加
• 与 AgentOpt (2604.06296) 的对比: AgentOpt 关注 agent 的 token 消耗优化（减少 agent 的 round trip 次数），PASTE 关注每个 round trip 中 tool 执行的延迟——攻击不同的瓶颈
• 与 CPU-Centric Perspective (2511.00739) 的关联: 该工作强调 agent 工作负载中 CPU 端的瓶颈，PASTE 的 pattern mining/prediction/scheduling 全部在 CPU 上运行，进一步验证了 CPU 优化在 agent serving 中的重要性
• 与 Speculative Tool Calls (2512.15834) 的对比: 该工作也做 speculative tool calls，但缺乏 PASTE 的 pattern-based 参数推导和风险感知调度——PASTE 在参数预测和安全性管理上更完善
• 对 vLLM/SGLang 的影响: 如果 PASTE 开源，可能被集成到这些框架的 tool-calling pipeline 中作为内置 feature

Figure 15: Pattern Prediction Quality #



解读: 按 benchmark 分解的预测质量。Top-1 准确率在 coding 任务（结构化循环）上较高，在 open-ended research 任务上较低。但 Overall Hit Rate 普遍较高（因为可以同时投机多个候选）。这验证了 PASTE 的设计哲学：不需要精确预测单个 tool，多候选投机 + 资源控制就足够。

Figure 13: Time Breakdown and Overlap #



解读: 这张图是理解 PASTE 加速机制的关键。ORION 的大量红色 Tool Stall 表明 agent 在等待 tool 完成时空转。SpecFaaS 的 Spec. Overhead 较大但 Overlap 很小，因为它基于静态 DAG 预测，无法准确预测 agent 的动态 tool 调用参数。PASTE 的 Overlap Region 大幅增加，Tool Stall 显著缩小——tool 工作被提前到 LLM 思考时段执行，总时间线从 ~150s 缩短到 ~100s。