一句话总结
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（模型停止解码的时刻）被主动注入到上下文中，不需要模型显式 await
2.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 无并发
实验组（AsyncFC）：
- AsyncFC(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-Turn（150 个多轮用例，注入 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 探索不同的函数调用顺序，选择能最大化并发吞吐的解码路径