当AI智能体学会"一心多用"：AsyncTool揭示大模型异步工具调用的真实水平
📖 核心摘要
你让AI帮你同时订机票、查天气、发消息——它真的能像人一样"等着订票系统响应的时候顺手去查天气"吗？这篇来自中科大的论文提出了AsyncTool基准，专门测试LLM智能体在工具有延迟反馈时能否高效交错处理多个任务。结果相当扎眼：即便是最强的GPT-4.1，Overall准确率也只有38.06%；开源模型里最好的DeepSeek-V3.1也只有28.93%。更有意思的是，频繁切换任务不等于做得好——真正厉害的模型是在"对的时机"切换，而不是瞎切。这篇论文填补了一个很实际的评估空白：现有benchmark几乎都假设工具调用是即时返回的，但现实世界哪有这么理想？
📋 论文信息
- 标题：AsyncTool: Evaluating the Asynchronous Function Calling Capability under Multi-Task Scenarios
- 作者：Kou Shi, Ziao Zhang, Shiting Huang, Avery Nie, Zhen Fang, Qiuchen Wang, Lin Chen, Huaian Chen, Zehui Chen, Feng Zhao
- 机构：中国科学技术大学、多伦多大学
- arXiv：2605.27995
- 代码：https://github.com/StoKou/repo-asynctool
- 日期：2026年5月
🎯 问题动机：工具调用的"时间盲区"
做过Agent开发的人应该都有这个体感：你调一个外部API，它不可能瞬间返回结果。查航班要等几秒，数据库查询可能更久。这段等待时间里，一个聪明的Agent应该去处理其他任务——就像你在等外卖的时候会刷手机一样。
但现有的工具调用评估基准几乎都在回避这个问题。不管是Berkeley的BFCL、NestFul还是τ-bench，它们的设定都是：调工具→立刻拿到结果→继续下一步。这跟真实场景差距太大了。
作者总结了现有研究的三个盲区：
| 问题 | 具体表现 |
|---|---|
| 异步场景缺失 | 只测单任务即时响应，不考虑延迟 |
| 脱离真实环境 | 不在交互式环境中运行 |
| 缺乏效率指标 | 只看对不对，不看快不快 |
TimeArena（复旦 & AI2，2024）是之前最接近的工作——它确实考虑了时间维度和并发任务，但它不涉及函数调用（function calling），更像是在模拟"做饭时可以同时烧水"这类日常任务。AsyncTool的定位更精准：带延迟的、交互式的、多步函数调用场景。
图1：数据构建四步走——从基准收集原始数据，经Gemini 2.5 Pro粗重建，再人工精标注，最后混合策略组合成多任务数据集
🏗️ 方法核心：怎么测"异步能力"
交互范式设计
AsyncTool的核心设计思路很直觉：给智能体同时塞多个任务，每次调工具后不是立刻返回结果，而是告诉你"结果还没好，你先干别的"。
具体来说，假设智能体收到两个独立任务 task₁ 和 task₂，各自需要按序调用一组函数：
- 智能体开始处理 task₁，调用 \(f_1\)
- 环境反馈：\(f_1\) 的结果还没好（模拟延迟）
- 聪明的做法：切换到 task₂，调用 \(f_2\)
- 当 \(f_1\) 结果返回后，回到 task₁ 继续调 \(f_3\)
- 如此交错，直到所有任务完成
图2：一个具体的交互例子——Task 1是"把Alpha Tech加到watchlist并存500美元"，Task 2是"找到Password Reset Failure那个工单并提升优先级"。智能体在等待 \(f_1\) 结果时切换去处理 Task 2，两条轨迹在时间线上交错执行
这里面有三个关键挑战： - 延迟感知：知道什么时候该等、什么时候该切 - 依赖追踪：记住每个任务做到哪了，下一步需要什么 - 状态维护：跨任务切换时不搞混各任务的上下文
数据集构建
数据来源是NESTFUL和BFCLv3两个已有基准，经过四步处理：
- 数据收集：提取12种工具、358个任务
- 粗重建：用Gemini 2.5 Pro重建任务描述和执行轨迹
- 细粒度人工标注：修正三类常见错误——误解初始条件、违反依赖、工具功能误用
- 多任务组合：按数量（2任务/3任务）× 类型（类内SIMILAR/跨类CROSS）组合，最终得到712个实例
三级评估体系
这是我觉得设计得比较讲究的地方——不是一刀切判对错，而是分层看问题出在哪：
| 评估层级 | 关注点 | 具体指标 |
|---|---|---|
| 步骤级 | 单次工具调用对不对 | 函数名准确率、参数准确率（F1） |
| 子任务级 | 单个任务的完整轨迹对不对 | 轨迹完成度、环境状态匹配 |
| 任务级 | 所有任务都做对了吗 | 全部子任务同时正确才算通过 |
另外还引入了效率指标——Same-task Streak，衡量模型连续处理同一任务的最长回合数。这个数越低，说明模型的交错能力越强。
🧪 实验结果：谁能真正"一心多用"
主实验：19个模型的全面对比
作者测了6个闭源模型和13个开源模型，结果如下（只列关键列）：
| 模型 | Step Func. | Step Param. | Sub-Task Acc. | Task Env. | Overall |
|---|---|---|---|---|---|
| GPT-4.1 | 96.22 | 84.08 | 67.14 | 64.89 | 38.06 |
| GPT-4o | 93.92 | 82.26 | 61.41 | 60.53 | 31.74 |
| Gemini 2.5 Pro | 89.08 | 78.27 | 62.05 | 54.35 | 32.44 |
| GPT-5 | 92.21 | 80.11 | 60.67 | 58.43 | 31.32 |
| Kimi-K2 | 96.14 | 80.46 | 56.79 | 51.69 | 24.44 |
| DeepSeek-V3.1 | 86.10 | 75.32 | 56.21 | 49.30 | 28.93 |
| Qwen2.5-32B | 94.24 | 81.73 | 56.48 | 49.72 | 24.86 |
| Qwen3-32B | 79.95 | 70.37 | 46.71 | 41.43 | 19.10 |
| Qwen2.5-14B | 81.32 | 70.22 | 46.28 | 38.20 | 18.82 |
| LLaMA-3.1-8B | 78.29 | 43.69 | 12.47 | 14.61 | 1.26 |
几个值得注意的点：
GPT-4.1一骑绝尘，Overall 38.06%，比第二名Gemini 2.5 Pro高了近6个点。但说实话，38%的绝对数字也不算高——这说明异步多任务对当前最强模型仍然是个硬骨头。
GPT-5居然没打过GPT-4o，这有点意外。GPT-5的Overall是31.32%，GPT-4o是31.74%。可能GPT-5在其他维度更强，但在这种需要精确状态追踪的任务上反而没优势。
开源模型的差距很大。DeepSeek-V3.1拿到28.93%，已经接近闭源模型的水平了；但LLaMA系列在这个任务上表现很差——LLaMA-3.1-70B只有2.81%，比8B的Qwen3都不如。这说明模型大不等于能做好异步协调。
效率与准确性的权衡
图4：x轴是Overall Score，y轴是Same-task Streak（越低表示交错越频繁）。理想模型应在右下角——既准确又善于交错
这张图非常直观地揭示了一个关键洞察：
GPT-4.1在右下角——Overall最高，Same-task Streak也很低（约2.6），说明它既能频繁切换又能保持正确性。而LLaMA-3.3-70B在左上角——Same-task Streak高达6.0+，Overall却只有个位数，说明它一直在死磕一个任务不肯切换，结果还做不对。
最有意思的对比是DeepSeek-V3.1：它的Overall不错（28.93%），但Same-task Streak偏高（约3.8）。这说明它的策略更偏"把一个任务做完再换下一个"，而不是频繁交错。这种策略在某些场景下也能work，但效率上不如GPT-4.1。
作者的结论很精辟：最佳模型不是切换最频繁的，而是在正确时机切换同时保持任务正确性的。
失败模式分析
作者识别了四种主要的失败模式：
- 缺乏时间推理：低性能模型在工具还没返回结果时就强行执行下一步——相当于你还没收到快递就签收了
- 任务遗忘：某些模型只记得最近的任务，把早期任务忘了。小模型更严重，三任务比双任务更频繁
- 工具误识别：跨任务搞混工具——比如在该处理数据的时候去调了航班预订API
- 幻觉参数：等不及结果返回就自己编造参数往下走
延迟和任务数量的影响
| 设置 | GPT-4.1 | Gemini 2.5 Pro | DeepSeek-V3.1 | Qwen3-8B |
|---|---|---|---|---|
| 延迟1轮（默认） | 38.06 | 32.44 | 28.93 | 10.67 |
| 随机0-1轮 | 34.55 | 35.25 | 26.26 | 14.04 |
| 随机1-2轮 | 29.49 | 29.35 | 16.57 | 7.16 |
| 固定2轮 | 26.40 | 25.70 | 14.61 | 6.60 |
延迟越长，所有模型都在掉分。GPT-4.1从38.06掉到26.40（延迟2轮），下降了30%+。而Qwen3-8B直接从10.67掉到6.60。
任务数量方面，从2任务到3任务的下降也很明显。在同步设置下（表7），LLaMA-3.3-70B从20.63%掉到8.70%，降幅达57.83%——上下文管理能力的差距在多任务时被急剧放大。
与现有基准的定位对比
| 基准 | 异步执行 | 函数调用 | 多任务 | 多步骤 | 跨场景 |
|---|---|---|---|---|---|
| τ-bench | ✗ | ✓ | ✗ | ✗ | ✗ |
| BFCL v3 | ✗ | ✓ | ✗ | ✓ | ✗ |
| NestFul | ✗ | ✓ | ✗ | ✓ | ✗ |
| TimeArena | ✓ | ✗ | ✓ | ✓ | ✗ |
| AsyncTool | ✓ | ✓ | ✓ | ✓ | ✓ |
AsyncTool是唯一同时覆盖异步执行、函数调用、多任务、多步骤和跨场景的基准。TimeArena虽然有异步和多任务，但不涉及函数调用；BFCL v3有函数调用和多步骤，但没有异步和多任务。
🔬 消融与深入分析
Few-shot能帮多少忙
| 模型 | Zero-shot | Few-shot | 提升 |
|---|---|---|---|
| LLaMA-3.1-8B | 1.26 | 6.74 | +5.48 |
| Qwen2.5-7B | 6.04 | 8.29 | +2.25 |
| Qwen3-8B | 10.67 | 11.24 | +0.57 |
| Qwen2.5-14B | 18.32 | 21.91 | +3.59 |
| Qwen2.5-72B | 31.04 | 34.55 | +3.51 |
Few-shot对小模型帮助最大（LLaMA-8B从1.26涨到6.74），但整体提升有限。这说明异步工具调用不是靠"看几个例子"就能学会的——它需要模型具备内在的状态追踪和时序推理能力。
交互轮数分析
成功完成任务时，各模型的平均交互轮数：
- 2任务场景：强模型（GPT-4.1）约6.7轮，弱模型（LLaMA-3.3-70B）需要10.6轮
- 3任务场景：强模型约10.5轮，弱模型需要16轮以上
轮数越多意味着效率越低——弱模型需要更多"试错"才能完成任务。
💡 我的判断
亮点
- 问题定义精准：异步工具调用确实是一个被忽视但极其实际的能力维度。任何做过Agent产品的人都知道，工具延迟是真实存在的
- 评估设计分层：步骤级→子任务级→任务级的三层评估，能精确定位模型的能力瓶颈在哪
- Same-task Streak指标：这个效率指标的设计很巧妙，把"切换频率"和"切换质量"分开看
值得商榷的地方
- 延迟模型过于简化：论文用固定轮数延迟（1轮、2轮）来模拟现实延迟，但真实场景中不同工具的延迟差异巨大——查天气可能100ms，数据库查询可能5秒，订票可能30秒。这种差异化延迟对调度策略的影响没有被探索
- 数据集规模偏小：712个实例、12种工具，对于一个benchmark来说不算大。而且数据来源只有NESTFUL和BFCLv3，场景多样性受限
- 缺少训练方案：论文只做了评估，没有探索如何提升模型的异步能力。比如能否通过特定的训练数据或RLHF来增强这种能力？
- GPT-4.1的优势来源不明：为什么GPT-4.1比GPT-5还强？是训练数据的差异还是架构设计的区别？论文没有深入分析
工程启发
如果你在做Agent产品，这篇论文有几个直接可用的takeaway：
- 不要假设工具即时返回：在Agent框架设计中，必须内置异步调度机制
- 状态管理是关键：模型的"任务遗忘"问题说明，仅靠上下文窗口是不够的，可能需要外部的任务状态存储
- 切换策略比切换频率重要：与其让Agent疯狂切换任务，不如设计好"什么时候该切"的决策逻辑
🤔 写在最后
AsyncTool（arXiv: 2605.27995）这篇论文做了一件很有价值的事：把"异步"这个在软件工程里早就是常识的概念，正式引入到LLM Agent的评估体系中。38%的最高分说明，当前的大模型在"一心多用"这件事上还差得远。
但我更好奇的是下一步：既然我们知道了模型在哪里失败（时间推理、任务遗忘、工具误识别），那怎么针对性地提升？是靠更好的系统提示、更长的上下文窗口，还是需要在预训练阶段就引入异步交互的数据？这可能是比评估本身更有意义的问题。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我