利用异步编程的 future 思想，让 LLM Agent 快 1.44 倍

一句话总结Agent 系统中 function calling 存在同步阻塞AsyncFC 借鉴异步编程中的 future/promise 机制在执行层实现解码与函数执行的重叠以及函数间并行在不修改模型、不打破 FC 协议的情况下显著降低延迟论文标题Concurrency without Model Changes: Future-based Asynchronous Function Calling for LLMs论文地址https://arxiv.org/abs/2605.15077作者背景加州大学伯克利分校一、动机现代 LLM Agent 的核心能力之一是 function calling工具调用。标准协议很简单模型生成一个结构化的函数调用 → Runtime 框架执行 → 结果追加到对话历史 → 模型继续解码。问题在于这个过程是严格同步的模型发出函数调用后解码完全阻塞直到函数执行完毕返回结果想象一下你让 Agent 帮你订机票、查天气、发邮件三件事。同步模式下模型必须等订票 API 返回可能要好几秒才能开始想下一步。即使查天气和发邮件跟订票结果完全无关也得排队等着。这就像一个程序员写了三行独立的 API 调用却非要用 await 串行执行之前的解决方案主要有两类1. 展示中间结果在函数执行期间不阻塞模型而是把 “函数正在执行中” 或 “部分结果” 这类中间状态直接暴露给模型让模型在看到这些不完整信息的情况下继续生成这实际上破坏了 function calling 协议模型需要理解适应新的交互模式可能造成效果变差2. 规划任务依赖让模型自己拆解任务理清每一步的依赖关系最终生成可以部分并行的函数调用。这对模型能力的要求较高可能需要额外训练对此作者提出了 AsyncFC 方法目标是让系统 Runtime 做并发管理而模型完全无需知道自己在异步执行二、实现方案2.1 Future 即刻返回AsyncFC 的核心灵感来自异步编程中的 future/promise 模式。当模型发出一个函数调用时Runtime 框架不再阻塞等待执行完成而是立即返回一个 future placeholder符号占位符。模型拿到这个占位符后可以继续解码后续的函数调用 —— 就像写异步代码时拿到一个 Promise 对象后可以继续写下一行一样具体来说AsyncFC 做了三件事1. Schema 变换把同步函数的 schema 自动改写为支持 future 输入输出的版本。具体地允许工具函数的返回值是 “future ID”输入参数也可以接受具体值或 future ID这样模型就能把一个函数的 future 结果直接传给下一个函数作为参数2. await_future 函数当模型确实需要某个函数的具体结果才能继续推理时可以调用await_future来显式等待。Runtime 框架检测到这个调用后会提前终止解码开始轮询已完成的结果3. 结果注入已完成的函数结果会在 turn boundary模型停止解码的时刻被主动注入到上下文中不需要模型显式 await2.2 依赖感知调度异步执行带来了一个新问题如果两个函数调用之间有依赖关系盲目并行会导致错误。AsyncFC 的调度器默认保守地按解码顺序串行执行所有函数开发者可以通过一个装饰器标注函数的资源访问模式读/写哪些路径调度器据此推导依赖关系只在安全时才并行执行调度流程分三个阶段准入屏障函数调用入队后按队列顺序逐个准入。如果函数的资源路径依赖于尚未解析的 future 值则等待冲突分析State Tree 记录每个函数的读写区域。新函数到来时检查是否与已注册的访问标签有重叠。有重叠则建立阻塞依赖执行派发无阻塞依赖的函数被派发到独立 worker 执行。执行完成后释放 future 和访问标签解除下游函数的阻塞这个设计类似于 CPU 中的 scoreboarding 调度和 Legion 的 region-based 依赖分析 —— 用硬件/系统级的方法解决并发安全问题而不是让程序员模型自己操心2.3 LLM 天生能理解 Future一个关键发现是现有的 LLM 不需要任何额外训练就能正确处理 future 占位符。模型能够正确地把 future ID 作为参数传递给后续函数调用在 future 被解析后正确地利用注入的具体值继续推理在需要具体值时主动调用 await_future作者推测这种能力来自预训练语料中大量的异步编程模式Promise、async/await、非阻塞 I/O模型已经学会了 “符号句柄稍后解析” 这种思维模式三、实验结果3.1 实验设置对照组同步基线Sequential FC顺序函数调用标准的顺序 FC API每个 turn 最多发出一个函数调用模型阻塞等待结果返回后才能继续解码。无任何并发Parallel FC并行函数调用并行 FC API允许模型在同一个 turn 内发出多个函数调用这些同 turn 调用并发执行。但下一个解码 turn 仍然阻塞直到当前 turn 的所有函数全部返回。跨 turn 无并发实验组AsyncFCAsyncFC(S)在 Sequential FC API 之上叠加 AsyncFC 执行层。底层模型仍然使用顺序 FC 协议每 turn 一个调用但运行时通过 future 机制实现 decode-execution overlap 和跨 turn 的函数间并行AsyncFC(P)在 Parallel FC API 之上叠加 AsyncFC 执行层。底层模型使用并行 FC 协议AsyncFC No-Ann(S)不提供任何依赖标注的 AsyncFC(S) 变体。调度器退化为保守串行执行但仍能获得 decode-execution overlap 收益所有对比都在相同模型主要是 GPT-4o和相同任务集上进行。延迟加速比的统计显著性通过配对 t 检验验证准确率差异通过 McNemar 检验确认无显著退化3.2 BFCL 基准测试在 BFCL v3 Multi-Turn150 个多轮用例注入 5s 函数延迟和 BFCL v4 Web Search真实后端延迟上评估异步 FC 实验组在所有情景中均未表现出统计意义上的准确率差异且在所有设置下均实现了加速3.3 延迟分解分析相比于基准测试实际工作中更可能面临更显著的函数执行延迟和更复杂的步骤交错。所以作者为工具函数添加了不同程度的延迟并观察各组方案的平均耗时可见函数执行耗时越长AsyncFC 的加速效果越明显此外作者还分析了「解码-函数调用重叠」和「函数间并行」两种加速收益的变化趋势可见低函数延迟时 decode-execution overlap 贡献主要收益并逐渐饱和高函数延迟时 inter-function parallelism 成为主导贡献者3.4 跨模型泛化AsyncFC 的 Runtime 搭好后作者还测试切换 LLM 时的鲁棒性把 gpt-4o 模型换成 Gemini 3.1 Pro 后BFCL v3 上也实现了准确率无显著下降的加速3.5 标注鲁棒性尽管完全不提供依赖标注No-Ann 模式时AsyncFC 还是能通过「解码-函数调用重叠」获得加速但标准的实现还是需要开发者手动填好各工具函数的执行信息这存在一定工作量。对此作者还测试了 AsyncFC 对这些执行标注的鲁棒性完全依靠外部 LLM 做一次性离线标注生成在 BFCL v3 上测试结果上看即使用的是不那么准确的 LLM 标注AsyncFC 也实现了 1.22 倍的加速准确率不降接近于上述手工标注效果3.6 下游应用软件工程将 AsyncFC 集成到 SWE-agent 中使用 GPT-5.2 评估。通过规则匹配自动生成依赖标注如python/pytest命令锁定根路径无需人工介入。在 2x 函数延迟缩放下AsyncFC 实现 1.44x 加速且 issue 解决率与基线持平异步思考AsyncFC 天然支持异步思考即将子 Agent 推理视为高延迟函数调用主模型作为协调者把子问题 上下文作为参数传给 “思考工具”工具返回推理结果。100 个原始任务组合为 50 个配对工作负载后AsyncFC 实现 1.24x 加速且准确率无损局限与展望工作负载依赖严格串行的任务或函数延迟可忽略的场景AsyncFC 收益有限额外开销await_future 的解码开销在某些情况下可能抵消收益可通过并行解码缓解最佳场景长延迟、写入型操作订票、发邮件、机器人控制物理执行与推理重叠潜在优化beam search 探索不同的函数调用顺序选择能最大化并发吞吐的解码路径