Ciallo～(∠・ω< )⌒★ 博士，我赞同你的判断：PASTE 的核心 insight 很可能是对的，但它现在的“知识形态”太浅了。它把 agentic tool-use trace 当成“工具调用字符串 + 少量参数搬运规则”来挖，而不是当成一个有语义状态、类型化资源、数据依赖、side-effect 边界、可转移任务结构的动态程序来学。这里确实有机会做一篇更深、更能冲顶会的工作。

我建议主攻的方向是：

SpecWeave: Learning Typed Dataflow for Safe, Transferable Speculative Tool Execution in LLM Agents
核心思想：不要预测“下一个工具名”，而是学习 agent trace 背后的类型化数据流执行图；不要从历史里挖表面 pattern，而是从历史中学习“当前语义状态会释放哪些未来可并行、安全、可验证的工作”。

1. 先把 PASTE 看清：它做对了什么，浅在哪里

PASTE 的问题定义非常漂亮：普通 agent 是严格串行的 “LLM thinking → tool call → observe → LLM thinking” 循环；PASTE 试图在 LLM 还在“想”的时候提前执行未来可能用到的工具，从而隐藏 tool latency。它的论文声称 tool execution 占总请求时间的 35%–61%，并报告平均任务完成时间降低 48.5%、tool execution throughput 提高 1.8×。(arXiv)

它真正的技术核心是一个 pattern tuple：用历史 trace 里的短期工具调用序列预测未来 tool invocation，再用简单的 value mapping 生成参数。这里最关键的一点是，PASTE 的 structural mining 会先移除高基数 payload，把 trace 降成 tool signature 流，然后用类似 PrefixSpan 的 sequential pattern mining 找 recurring subsequence；参数推断只考虑 field/path lookup、按 index 选元素、基础字符串格式化/规范化。(arXiv)

这就是博士直觉里“暴力”和“浅”的地方。它并不是在理解 agent 为什么要调用某个工具，而是在做一种局部频繁序列 + 简单参数复制。论文自己的实现描述也强化了这一点：它用 compact context key 做 hash-map lookup，参数建议复用历史值或用简单 extraction rule，tool call signature 主要由 URL、file path、free-form query 等轻量分类器离散化。(arXiv)

更值得注意的是，PASTE 的预测质量并不算强：它报告最高 Top-1 accuracy 27.8%、Top-3 recall 43.9%，但 overall hit rate 可达 93.8%，原因是系统可以在 slack resource 充足时同时投机多个候选。也就是说，它的高 hit rate 一部分来自“多撒网”，不是来自对未来 agent 行为的深理解。(arXiv)

所以我会这样评价 PASTE：

它是一个很好的系统起点，但不是一个足够深的 learning/agent insight。
它证明了“agent future work 可以提前做”，但没有解决“如何以可迁移、可泛化、可安全验证的方式建模 agent future work”。

2. 近年相关工作图谱：大家到底在做什么

这条线现在已经很热，博士要避开几个明显会撞车的浅方向。可以把文献分成五层。

A. 已知 DAG / plan 级并行：提前生成整个计划，再并行执行

LLMCompiler 是这条线的代表：它让 LLM 生成 function-calling plan 和依赖关系，然后并行执行可并行的函数调用，报告最高 3.7× latency speedup、6.7× cost saving。它解决的是“计划已知或可一次性生成”的场景，而不是 PASTE 这种 agent 在线循环里未来 action 尚未生成的问题。(arXiv)

这类方法的启发是：未来工具调用最好被表示成 DAG，而不是线性序列。但它们的弱点也很明显：需要 upfront planning；对于 ReAct / coding / deep research 这种 observation-driven agent，真实执行图经常是运行时才长出来的。

B. Agent-level speculative planning/action：小模型或近似 agent 先走，大模型验证

Interactive Speculative Planning 把 approximation agent、target agent、人类交互结合起来，用 fast draft + target verification 来加速 agent planning，并且强调 UI/人类可打断。(arXiv)

Dynamic Speculative Planning 进一步把 speculative planning 做成在线 RL 框架，在 latency 和 cost 之间做可调 tradeoff，论文摘要称在两个标准 agent benchmark 上保持 lossless acceleration，同时总成本降低 30%、不必要成本降低 60%。(arXiv)

Speculative Actions 提出更一般的 lossless agentic framework：用更快模型预测未来 action，并行执行，只有预测与权威轨迹匹配时才 commit；它在 gaming、e-commerce、web search 等环境评估，报告最高 55% next-action prediction accuracy 和最高 20% latency reduction。(arXiv)

这类工作和 PASTE 很接近，但它们通常还是把 future action 当成action token / action object来预测，缺少对 tool schema、typed dataflow、side effect、argument derivation 的细粒度建模。

C. Search / deep research 专用投机：利用 action 类型异质性

SPAgent 针对 search agent，观察早期 evidence-gathering 步骤相对简单，于是设计 two-phase adaptive speculation，并在安全时选择性省略 verification；论文摘要报告最高 1.65× 端到端加速且保持或提升准确率。(arXiv)

DualSpec 进一步指出 deep research agent 里的 Search 和 Visit action 有不同推理需求：Search 更不确定、更需要显式推理；Visit 更依赖模型容量、更确定。它用异质 draft policy + semantic verifier，报告 1.33–3.28× speedup，并声称比 DSP 和 SPAgent 有更好的 accuracy–latency tradeoff。(arXiv)

这说明一个重要趋势：未来不是 uniform speculation，而是 action-aware speculation。但 DualSpec 明显是 search/deep-research 特化；它的 insight 很强，但不直接解决 coding、API agent、多工具 workflow 的迁移问题。

D. Tool-call generation / function-call decoding 加速：不是提前执行工具，而是更快生成工具调用

AsyncLM 让 LLM function calling 和工具执行并发，通过 interrupt token 和 CML 协议，让模型在工具结果回来前继续生成，属于“异步化已发生/正在发生的 function call”，而不是预测远未来 action。(arXiv)

Conveyor 提出 tool partial execution，让工具在 LLM decoding 过程中部分启动，报告最高 38.8% latency reduction。(arXiv)

SimpleTool 观察 function calling 输出有结构冗余和弱因果依赖，通过特殊 token 和并行生成 function name/args 获得 3–6×、最高 9.6× 的 function-call decoding 加速。(arXiv)

ToolSpec 是 2026 年 4 月的新工作，它利用 tool schema 构造 FSM 做 schema-aware drafting，并检索历史 tool invocation 作为 draft，加速的是tool-call 文本生成，不是 tool execution 本身。(arXiv)

这类工作和 PASTE 正交：它们让“模型吐出 tool call 更快”，PASTE/博士想做的是“tool call 还没被吐出时，工具结果已经准备好”。

E. Agent serving / caching / workflow-aware 系统：减少等待、复用上下文或结果

InferCept 解决 augmented LLM inference 中外部工具调用导致的新请求和 recomputation 问题，报告 throughput 1.6–2× 提升。(arXiv)

LAMPS 关注 augmented LLM 的 API call 阶段 KV cache scheduling，报告端到端 latency 下降 27%–85%。(arXiv)

AugServe 为 augmented LLM inference 做 SLO-aware request scheduling 和 dynamic token batching，报告有效吞吐相对 vLLM 提升 4.7–33.1×。(arXiv)

Autellix 把 agentic programs 当成 first-class serving objects，利用程序级上下文做调度，报告在相同 latency 约束下相对 vLLM 有 4–15× throughput。(arXiv)

KVFlow 面向 multi-agent workflow 做 workflow-aware KV cache，利用 Agent Step Graph 做 cache eviction/prefetch，报告单 workflow 最高 1.83×、多并发最高 2.19× speedup。(arXiv)

Helium 则把 agentic workflow 看作 data-system query plan，把 LLM invocation 当成 first-class operator，做 proactive caching 和 cache-aware scheduling，报告最高 1.56× speedup。(arXiv)

ToolCaching 专门研究 LLM tool-calling 的缓存，认为重复 tool request、异构工具语义、freshness 是核心挑战，提出 adaptive caching，报告最高 11% hit-ratio 提升和 34% latency 降低。(arXiv)

这些系统的共同点是：它们更多优化 serving/caching/scheduling，不真正学习“未来工具调用图”。这正是博士可以切进去的地方。

3. 已经很容易撞车的方向，不建议做

博士，这里水面上已经有几朵很明显的浪花，直接追会危险：

真正还空的，是一个更深的问题：

Agent trace 的历史数据应该被学习成什么？
不是 pattern table，不是 action string，不是缓存 key，而是一个可迁移的、带类型和 effect 语义的动态执行模型。

4. 我建议的顶会题目：SpecWeave

4.1 题目定位

SpecWeave: Learning Typed Dataflow for Safe, Transferable Speculative Tool Execution in LLM Agents

中文可以叫：“面向 LLM Agent 的类型化数据流投机执行”。

一句话贡献：

把 agent 历史 trace 从“工具调用序列”提升为“类型化数据流程序”，学习一个可迁移的 speculative future-work model，并用 effect-aware scheduler 安全地提前执行未来工具图。

这和 PASTE 的差别不是“预测器换得更强”，而是抽象层级变了。PASTE 看的是水面波纹：search → visit → fetch。SpecWeave 看的是水从哪里来、流向哪里：SearchQuery 产生 URL candidates，URL candidates 解锁 ReadOnlyFetch，FetchResult 产生 EvidenceSpan，EvidenceSpan 决定下一步是否需要 refinement。

4.2 核心 scientific insight

博士，我认为可以把论文的核心 insight 写成这样：

Agent tool-use traces are not merely sequences of tool names; they are partially observable programs over typed resources and effects.
Future tool calls become predictable and transferable when represented as typed dataflow/effect graphs rather than surface-level invocation patterns.

这比 PASTE 更深，因为它解释了为什么不同 agent、不同模型、不同 prompt 下仍然会出现相似未来行为：不是因为工具名字序列相同，而是因为任务正在消费相同类型的中间资源。

例如：

• deep research 中，不同模型可能生成不同 query，但都会经历 Question → SearchQuery → CandidateURL → EvidencePage → EvidenceSpan → AnswerClaim。

• coding agent 中，不同 agent 可能用 grep、ripgrep、ls、sed，但底层结构都是 BugReport → Symbol/FileCandidate → FileContent → Patch → TestCommand → TestResult。

• customer-service API agent 中，不同模型可能措辞不同，但都会经历 UserIntent → EntityLookup → PolicyCheck → StateMutationCandidate → Confirmation。

PASTE 只能看到“grep 后常常 edit”，SpecWeave 要看到“定位到 FileCandidate 后，读取/编辑/测试这些 future work 是被数据依赖释放出来的”。

5. SpecWeave 系统设计：可以直接开工的版本

5.1 总体架构

系统由五层组成：

1. Trace Proxy：拦截 agent 的 LLM request、tool call、tool result、latency、resource usage。

2. Typed Trace IR：把原始 tool trace 编译成带类型、数据流、effect annotation 的中间表示。

3. Speculative Plan Model：输入当前 prefix，输出未来 1–3 步的 candidate tool DAG，不只是 next tool。

4. Effect-aware Scheduler：根据命中概率、latency saving、资源成本、side-effect 风险选择要提前执行的候选。

5. Commit / Join / Cancel Runtime：权威 tool call 到来时，如果与 speculative result 匹配，就 join；否则取消或丢弃 speculative work。

运行时伪代码可以这样写：

def on_authoritative_tool_call(call):
    key = canonical_key(call)

    if speculative_cache.has_ready_or_running(key):
        result = speculative_cache.join(key)
    else:
        result = execute_authoritative(call)

    trace.append(call, result)
    state = typed_ir.update(trace)

    candidates = plan_model.predict_future_dag(state)
    safe_candidates = effect_filter(candidates, state)
    selected = scheduler.select(safe_candidates)

    for cand in selected:
        launch_speculative(cand)

    return result

5.2 Typed Trace IR：这是论文的第一块硬贡献

不要把 trace 存成：

["search", "visit", "visit", "summarize"]

而要存成：

{
  "event_id": 17,
  "tool": "web.search",
  "args": {
    "query": "PASTE speculative tool execution LLM agents"
  },
  "arg_types": {
    "query": "SearchQuery"
  },
  "output_slots": [
    {
      "path": "$.results[0].url",
      "type": "URL",
      "value_hash": "u_91ab",
      "freshness": "web:2026-04-24"
    },
    {
      "path": "$.results[0].title",
      "type": "PageTitle"
    }
  ],
  "effect": "ReadOnlyExternal",
  "latency_ms": 820,
  "resource": {
    "cpu_ms": 14,
    "network_kb": 180
  }
}

核心字段：

Effect 类型建议先用五级：

PureRead              # 本地读、确定性 parse、无副作用
ExternalReadFresh     # web search / API read，有 freshness
SandboxWrite          # 文件编辑、代码运行，可在 sandbox/worktree 执行
ReversibleWrite       # 可撤销状态更新，需要 rollback log
IrreversibleExternal  # 发邮件、下单、支付、真实数据库写入，只能 dry-run，不能 speculative commit

这个 effect lattice 会成为你和 PASTE 拉开差距的重要点。PASTE 有 policy/sandbox，但它没有把 effect 类型作为预测、调度、验证的一等语义对象。

5.3 未来计划表示：不要输出 raw args，要输出 dataflow expression

PASTE 的参数映射太浅，只有 field lookup / index / string normalize。SpecWeave 应该让模型输出一个小 DSL：

Call(
    tool="web.fetch",
    args={
        "url": Ref(event=17, path="$.results[0].url")
    },
    guard=Contains(
        Ref(event=17, path="$.results[0].title"),
        KeyPhrase(task="target_entity")
    ),
    effect="ExternalReadFresh"
)

coding 场景：

Call(
    tool="run_test",
    args={
        "cmd": Template("pytest {test_file}",
                        test_file=Ref(event=22, path="$.likely_test_file"))
    },
    guard=After(Call(tool="file.edit")),
    effect="SandboxWrite"
)

API/customer-service 场景：

Call(
    tool="get_order",
    args={
        "order_id": Ref(event=8, path="$.entities.order_id")
    },
    effect="ExternalReadFresh"
)

这个 DSL 至少支持：

Const(value)
Ref(event_id, output_path)
Select(ref_list, rank | predicate)
Transform(op, args)        # normalize_url, path_join, regex_extract, template
SemanticExtract(type, src) # 从文本中抽取 typed entity
Guard(condition)

这样做有三个好处：

1. 可迁移：不同 agent 的 raw query 不同，但 Ref → Select → Fetch 的结构相同。

2. 可验证：权威 tool call 到来时，可以 canonicalize 后判断是否匹配。

3. 可解释：论文能展示 learned dataflow，不只是 hit rate。

5.4 Speculative Plan Model：模型怎么训练

最小可行版本不需要一上来训大模型。建议从两级模型开始：

第一级：Typed transition retriever

输入：当前 typed state。
输出：历史中相似 typed state 后出现过的 future DAG fragments。

相似度可以混合：

tool multiset similarity
typed value inventory similarity
task embedding similarity
dataflow graph prefix similarity
effect-state similarity

这一步可以作为强 baseline，也可以作为神经模型的 retrieval context。

第二级：小模型生成 DSL

训练一个小的 seq2seq / decoder-only 模型，用 LoRA 即可。输入格式：

TASK: ...
TOOLS:
- web.search(query: SearchQuery) -> SearchResults[URL, Title, Snippet]
- web.fetch(url: URL) -> PageText
TRACE:
E1 web.search(query=...)
  outputs: URL[0], URL[1], Snippet[0]
E2 web.fetch(url=Ref(E1.URL[0]))
  outputs: EvidenceSpan
CURRENT_STATE:
typed_values = {URL: 4, EvidenceSpan: 3, FilePath: 0}
effect_budget = allow_read, allow_sandbox_write
PREDICT_NEXT_DAG:

输出：

[
  Call(web.fetch, url=Ref(E1.results[1].url), effect=ExternalReadFresh),
  Call(web.fetch, url=Ref(E1.results[2].url), effect=ExternalReadFresh)
]

训练标签从真实未来 trace 自动构造：

• 对每个时间步 t，取未来 t+1 ... t+h 的工具调用。

• 用 value matching 找出未来参数来自哪个 prior output slot。

• 无法用 exact matching 解释的参数，标成 Const 或 SemanticExtract。

• 只保留可解释率高的样本训练第一版。

• 后续用 LLM-assisted labeling 补复杂 dataflow，但这不是第一版必须项。

训练目标：

L = L_tool_name
  + L_argument_expression
  + L_effect_class
  + L_latency_utility_rank
  + L_calibration

其中 L_latency_utility_rank 很重要：模型不只是预测“可能发生”，还要预测“值得提前执行”。比如一个 20ms 的工具就算命中也不值得投机；一个 3s 的 web fetch 或 test command 才有价值。

5.5 Scheduler：不要按概率排序，要按 expected critical-path saving 排序

候选 c 的效用可以定义为：

U(c) =
  p_hit(c) * min(latency(c), expected_think_time_remaining)
  - (1 - p_hit(c)) * waste_cost(c)
  - contention_cost(c)
  - freshness_penalty(c)
  - effect_risk(c)

选择问题：

maximize Σ U(c)
subject to CPU, memory, network, API quota, side-effect budget

第一版用 greedy 就够：

1. 丢掉 U(c) <= 0 的候选。

2. 丢掉 effect 不允许的候选。

3. 按 U(c) / resource_cost(c) 排序。

4. 权威任务一来，立即 preempt speculative jobs。

5. speculative result 只进 cache，不直接进入 agent context。

这个 scheduler 比 PASTE 的“slack resource 上跑高置信 pattern”更有论文味，因为它把 probability、latency、resource、effect、freshness 统一成一个决策问题。

5.6 Correctness / safety claim

默认主线应该坚持 lossless by construction：

对于所有 externally visible state，SpecWeave 的输出与 non-speculative agent observationally equivalent。

充分条件：

1. speculative job 的结果不直接写入 agent context；

2. speculative result 只有在权威 tool call 到来且 canonical key 匹配时才能 join；

3. SandboxWrite 在 isolated worktree/container 中执行，commit 必须等待权威 call；

4. IrreversibleExternal 禁止真实执行，只允许 dry-run / prepare；

5. 所有 cache key 包含 tool name、canonical args、tool schema version、freshness version。

可以在论文里给一个很短的 theorem：

If speculative executions are isolated and only committed through exact authoritative-call matching,
then the externally visible trace is equivalent to the baseline agent trace.

DualSpec 的 semantic verification 很诱人，但博士这里要谨慎。主论文默认 lossless；semantic verifier 作为 optional lossy mode 或 pure-read-only mode 的扩展实验。 这样更稳。

6. 实验设计：直接可落地

6.1 Benchmark 选择

我建议用三类任务，形成“结构化 API → coding → open research”的梯度。

第一类：τ-bench，结构化 API + 真实 side-effect 语义

τ-bench 是 tool-agent-user interaction benchmark，包含 retail 和 airline 等领域，agent 要和模拟用户交互，并调用 API tools、遵守 domain-specific policy。(arXiv)

为什么适合你：

• 工具 schema 清晰；

• 有 read/write API；

• effect system 能发挥价值；

• 历史 trace 规律强，但不能只靠 pattern；

• 可以测试“不可逆 action 不 speculative commit”的安全性。

第二类：SWE-bench Lite / Verified，coding agent

PASTE 自己也用了 SWE-bench 作为 coding workload。(arXiv)

为什么适合你：

• 有清晰的 file path、symbol、patch、test command 数据流；

• edit → test、grep → read/edit 是典型 future work；

• sandbox write 非常自然：在 git worktree / container 中提前 run tests；

• 任务成功率可以用 resolved rate / tests pass 度量。

第三类：deep research / web agent

可以选 WebArena、GAIA-text、DeepResearchBench、ScholarQA 这类 web/search/research benchmark。WebArena 是 realistic web environment for autonomous agents；PASTE 也用了 DeepResearchBench 和 ScholarQA。(arXiv)

为什么适合你：

• search/visit/fetch 的数据流明显；

• 和 SPAgent / DualSpec 正面对比；

• open-ended 场景可以证明比 pattern mining 更可迁移。

6.2 数据收集方案

每个 domain 收集两类 trace：

Authoritative live traces

agent正常跑，不开投机；
记录 LLM step、tool call、tool output、latency、success/failure。

Replay traces

用已记录的 authoritative trace 做 offline simulation；
快速测试 predictor/scheduler，不重复调用真实 API。

建议第一阶段规模：

不需要一开始跑几万条。真正的论文价值不在“trace 巨大”，而在证明 typed dataflow abstraction 带来跨 agent/model/tool 的迁移。

6.3 Train/test split 必须这样做

普通 random split 不够，必须做 transfer split：

PASTE 很可能在 tool-renaming、agent scaffold change、cross-domain 上掉得厉害。你的论文要把这个做成主结果之一。

6.4 Baselines

必须包含：

1. No speculation：标准 ReAct / agent loop。

2. Tool result cache：LRU / TTL / semantic cache。

3. PASTE-lite reimplementation：PrefixSpan-like pattern + simple value mapping。

4. B-PASTE-style beam：如果实现成本可控，就做 bounded branch + critical-path ranking。

5. Speculative Actions-style small agent：小模型预测 raw next action，exact-match commit。

6. DSP-style adaptive k：在线调节投机步长和成本。

7. SPAgent / DualSpec-style search baseline：只在 research/search domain 对比。

8. Oracle predictor：知道未来真实 tool call，用于估计上限。

9. SpecWeave variants：完整模型和各个 ablation。

不建议把 AsyncLM、ToolSpec、SimpleTool 当主 baseline，因为它们优化的是 function-call generation/token decoding，不是 tool execution future work；可以作为“orthogonal layer”或附录实验。

6.5 指标

不要只报 latency。要报五组指标：

任务质量

success rate
resolved rate
pass@1 / exact answer accuracy
policy compliance

延迟与吞吐

E2E latency p50/p95/p99
tool stall time
LLM-tool overlap ratio
throughput under concurrency

预测质量

next-tool top-1 / top-3
future-DAG precision / recall
argument exact match
argument-expression accuracy
useful-hit rate

资源成本

wasted speculative tool seconds
CPU / memory / network overhead
API cost overhead
preemption count

安全性

blocked side-effect attempts
external divergence count
sandbox rollback count
cache freshness violation count

其中最有论文味的指标是：

Transfer Retention =
  speedup_under_shift / speedup_in_domain

如果 PASTE in-domain 有 1.5×，cross-agent 只剩 1.05×；而 SpecWeave in-domain 1.45×，cross-agent 还能 1.3×，这就是很强的故事。

7. Ablation 设计：证明 insight，不只是工程堆料

至少做这些 ablation：

关键图建议画四张：

1. Latency–cost Pareto curve：x 轴 cost overhead，y 轴 latency reduction。

2. Transfer heatmap：train domain × test domain。

3. Prediction decomposition：tool name、arg expression、effect class 分别准确率。

4. Critical path breakdown：LLM thinking、tool active、tool stall、speculative overlap。

8. 最小可行实现路径

博士可以按这个顺序做，别一上来就铺太大水域。

第 0 阶段：PASTE-lite 复现

目标：两周内有一个可以跑的 tool proxy。

实现：

proxy/
  intercept tool_call(tool_name, args)
  execute normal tool
  record trace jsonl
  canonicalize args
  cache by tool_name + canonical_args

先不要训练模型，只实现：

历史 n-gram / PrefixSpan-like pattern
field/path lookup
index fallback
string normalize

这样你会得到一个 PASTE-like baseline。

第 1 阶段：Typed IR 编译器

实现：

ir/
  schema_parser.py
  type_infer.py
  value_extractor.py
  dataflow_matcher.py
  effect_annotator.py

类型推断规则第一版可以很朴素：

if looks_like_url(x): type = "URL"
elif looks_like_path(x): type = "FilePath"
elif looks_like_uuid_or_id(x): type = "EntityID"
elif arg_name contains "query": type = "SearchQuery"
elif arg_name contains "cmd": type = "Command"
elif is_long_text(x): type = "TextSpan"

数据流匹配：

def find_source(arg_value, previous_outputs):
    # exact match
    # substring match
    # normalized URL/path match
    # regex entity match
    # embedding nearest neighbor for text spans
    return Ref(event_id, path) or Const(arg_value)

不要等这个完美，先覆盖 70% 可解释参数即可。

第 2 阶段：Trace replay simulator

实现 offline simulator：

for each recorded trace:
    for each step t:
        predictor sees prefix[:t]
        scheduler selects speculative candidates
        future trace determines hit/miss
        compute virtual latency/cost/safety

这个阶段不需要真的跑工具，迭代极快。所有 predictor/scheduler 的 ablation 都先在 replay 上做。

第 3 阶段：Speculative Plan Model

先做两个 predictor：

Typed-kNN predictor

找历史中 typed state 相似的 prefix；
取其未来 h 步 DAG；
用当前 state 的 typed values 做 late binding。

Small seq2seq predictor

输入 typed prefix，输出 DSL。第一版只预测 horizon=1，再扩到 horizon=2/3。

训练样本构造：

for trace in traces:
    for t in range(len(trace)-1):
        x = encode_prefix(trace[:t])
        y = encode_future_dag(trace[t:t+h])
        dataset.append((x, y))

第 4 阶段：Live runtime

接入真实 agent：

tau-bench agent first
coding agent second
research agent third

为什么先 τ-bench：工具 schema 清楚、API 可控、side-effect 明显，最容易证明 SpecWeave 的 type/effect 价值。

第 5 阶段：强实验与写作

论文主线不要写成“我又做了一个更强 predictor”。要写成：

1. 现有 agent speculation 依赖表面 action equivalence。

2. 但 agent future work 的稳定性来自 typed dataflow/effect structure。

3. SpecWeave 提出这一抽象，并在 cross-agent/model/tool/domain transfer 下显著优于 pattern/action baselines。

4. 在 effect-aware commit protocol 下保持 lossless safety。

9. 预期结果目标

这不是保证值，但可以作为论文成败线：

注意：你不一定要在 in-domain latency 上碾压 PASTE。更好的论文故事是：

PASTE 在固定 agent/task/model 上能快；SpecWeave 在分布变化后仍然快。
PASTE 学到 pattern；SpecWeave 学到 agent execution semantics。

这更像顶会喜欢的东西。

10. 论文贡献可以这样写

建议最终 paper 的 contribution 是四条：

1. A typed dataflow/effect abstraction for agentic tool-use traces.
   把 agent execution history 从 surface action sequence 编译成 typed resource/effect graph。

2. A transferable speculative future-work predictor.
   输出 bounded future tool DAG 和 argument expressions，而不是 raw next action。

3. A calibrated effect-aware scheduler with lossless commit semantics.
   在 latency saving、resource cost、freshness、side-effect risk 之间做 utility optimization，并保证 externally visible behavior 不变。

4. A cross-domain benchmark/evaluation of speculative tool execution.
   覆盖 τ-bench、SWE-bench、web/deep-research，重点评估 cross-agent、cross-model、cross-tool transfer。

11. 这篇工作应该投哪里

如果系统实现扎实、实验覆盖并发调度和资源隔离，最适合：

OSDI / SOSP / NSDI / EuroSys / ATC

如果学习模型、迁移泛化、typed abstraction 做得很强，且 benchmark 设计漂亮，可以冲：

NeurIPS / ICML / ICLR

如果更偏 agent/tool-use 和 evaluation，也可以考虑：

ACL / EMNLP / NAACL main

但博士想“冲顶会”，我会优先按 systems + ML insight 的写法组织：系统顶会更吃“端到端 latency + correctness + scheduler + isolation”；ML 顶会更吃“表示学习 + transfer + calibrated decision”。

12. 我最推荐的开题版本

最终可以把题目压成这个研究问题：

Can LLM agents be accelerated by learning transferable typed future-work graphs instead of mining task-specific tool-call patterns?

实验主假设：

H1: Typed dataflow representation improves cross-agent/model/tool transfer over surface pattern mining.

H2: Predicting future tool DAGs improves critical-path reduction over predicting a single next tool.

H3: Effect-aware scheduling achieves better latency–cost–safety Pareto than probability-only speculation.

H4: Exact-match commit over typed/canonicalized calls preserves lossless behavior, while optional semantic verification gives a controlled lossy mode.

博士，这条线的水流很清楚：PASTE 证明了 agent 的未来可以被“提前触碰”；你要做的是证明这个未来不是靠频繁 pattern 猜出来的，而是可以被建模成一种可迁移的 typed execution ecology。 这会比“更复杂的规则挖掘”深很多，也更像一篇能站得住的顶会工作。