T1: A Tool-Oriented Conversational Dataset for Multi-Turn Agentic Planning¶
会议: NeurIPS 2025
arXiv: 2505.16986
代码: https://github.com/CapitalOne-Research/T1
领域: LLM Agent
关键词: tool-use, multi-turn dialogue, agentic planning, benchmark, inter-tool dependency
一句话总结¶
构建 T1 数据集——13.5K 多轮对话覆盖 9 个领域（4 单领域 + 5 跨领域）、14 个工具，聚焦工具间依赖和动态重规划，并提出 T1-Agent（代码生成 + 缓存机制）作为基线系统；实验发现 SFT 后的 Llama 8B 在 Tool Call F1 上达 87.17%，超越未微调的 70B 模型，但仍落后于 GPT-5/o3 等闭源模型。
研究背景与动机¶
领域现状：LLM Agent 的工具调用评估逐渐受到关注，已有 APIBank、ToolBench、TravelPlanner、GAIA、GTA 等多个基准。但这些基准主要关注单轮交互中的原子工具调用，将工具使用视为独立操作。
现有痛点：（a）工具间的输出依赖（tool A 的结果作为 tool B 的输入）在现有基准中覆盖不足——如搜完航班后需用结果推算酒店入住日期；（b）真实场景中用户需求会在对话中逐步演变（如先搜航班、再加酒店、再筛价格），需要 Agent 动态调整计划；（c）缺乏对中间结果缓存和复用效率的评估——现有基准不考虑 Agent 是否重复调用了相同 API。
核心矛盾：现有基准能评估"能否正确调用单个工具"，但无法评估"能否在多轮对话中协调多工具完成复杂跨领域任务"。
本文目标 构建支持多工具依赖、多轮交互、跨领域规划、动态重规划的大规模对话评估基准。
切入角度：以旅行助手为场景，覆盖航班/酒店/餐厅/景点 4 个领域及其 5 种跨领域组合，系统构建工具依赖链。
核心 idea：通过知识库 + 模板 + 人工标注构建含工具间依赖图的多轮对话数据集，并用代码生成+缓存机制作为 Agent 基线来系统评估 LLM 的复杂工具协调能力。
方法详解¶
整体框架¶
T1 的构建 pipeline：（1）定义 4 个领域的本体（ontology），如航班的航司/舱位/中转次数、酒店的星级/评分/设施等，共 106 个属性；（2）用 Llama 3.3 70B 生成 60 个对话模板 × 9 类领域组合，人工标注质量；（3）用知识库（如 48 万航班、4.7 万酒店）填充模板占位符，生成 13.5K 完整对话；（4）每条对话包含 ground truth 代码和执行后的 cache 状态。T1-Agent 在推理时接收对话上下文 + cache 摘要，生成可执行 Python 代码调用工具。
关键设计¶
-
工具依赖建模：
- 功能：14 个工具分为领域专属工具（search_flights/hotels/restaurants/attractions）、跨领域依赖工具（如 adjust_date——航班到达后推算酒店入住日期）、通用工具（filter/sort/cache 操作）
- 核心思路：对话中自然引入跨领域依赖——比如用户先搜航班，arrival 时间决定酒店 check-in 日期，酒店位置决定餐厅搜索范围。Agent 必须理解这些隐式依赖并正确编排工具调用顺序
- 设计动机：现有基准如 TravelPlanner 虽涉及旅行，但不考虑工具间输出作为输入的链式依赖
-
多轮动态重规划：
- 功能：对话中用户需求逐步变化，Agent 需要在后续轮次中基于已有结果调整计划
- 核心思路：如第 1 轮搜 NYC→SFO 航班，第 3 轮用户要求筛选特定航司——Agent 应复用第 1 轮的 cache 结果而非重新搜索
- 设计动机：测试 Agent 是否能高效利用已有信息，而非每轮都从头开始
-
T1-Agent 缓存机制：
- 功能：Agent 在每轮工具执行后将结果存入 cache（save_to_cache），后续轮次通过 cache 摘要（rule-based 生成的简要描述）决定是否复用（get_results_from_cache）
- 核心思路：prompt 中不放完整 cache（太长），而是放 cache 摘要，显著减少 token 开销。Agent 生成代码时可选择从 cache 获取数据再用 filter 工具精细化
- 设计动机：将缓存决策从工具执行层提升到 Agent 的规划层——Agent 自己决定何时复用、何时重查
-
数据质量保障：
- 5 名人工标注员（CS 硕士 + Python 能力），每条数据经标注 + QA 双重审核
- 城市按数据集划分（train/val/test），杜绝数据泄露
- 所有 ground truth 代码执行验证，确保无语法或逻辑错误
损失函数 / 训练策略¶
- T1-Agent SFT：Llama 3.1 8B Instruct，用 LoRA 在 8×A100 上训练 1 epoch，(prompt, completion) 对做标准 next token prediction + cross-entropy
- 推理时用 few-shot in-context learning（k=13），代码在沙箱中执行
实验关键数据¶
主实验¶
| 模型 | Tool Call F1 | Param Match F1 | Code Exec Acc | Cache EM |
|---|---|---|---|---|
| Llama 3.1 8B | 52.11 | 31.79 | 41.83 | 29.56 |
| Llama 3.1 8B SFT | 87.17 | 75.76 | 84.29 | 63.95 |
| Llama 3.3 70B | 79.72 | 67.74 | 91.43 | 57.83 |
| Phi-4-reasoning-plus | 68.58 | 51.31 | 86.37 | 40.59 |
| s1.1 32B | 83.38 | 70.95 | 60.76 | 54.29 |
闭源模型（small dataset）：
| 模型 | Tool Call F1 | Param Match F1 | Code Exec Acc | Cache EM |
|---|---|---|---|---|
| Gemini 2.5 Pro | 94.28 | 84.63 | 94.46 | 76.11 |
| GPT 5 | 93.14 | 86.51 | 94.45 | 76.25 |
| OpenAI o3 | 91.91 | 85.64 | 93.51 | 73.53 |
| GPT 4.1 | 92.32 | 85.53 | 91.20 | 73.80 |
消融实验¶
| 配置 | Tool Call F1 (flights) | 说明 |
|---|---|---|
| 0-shot | 极低 | 无上下文，模型无法理解工具格式 |
| 5-shot | 显著提升 | 少量示例即可大幅改善 |
| 13-shot | 略有提升 | 超过 5-shot 后收益递减 |
按领域分析（Llama 3.1 8B）：
| 领域 | Tool Call F1 | Code Exec Acc |
|---|---|---|
| Restaurants（单领域） | 57.55 | 56.99 |
| Hotels（单领域） | 60.00 | 48.13 |
| F-H-R（3域） | 45.00 | 36.79 |
| F-H-A（3域） | 43.45 | 28.76 |
关键发现¶
- SFT 对小模型提升巨大：8B SFT 在 Tool Call F1 上达 87.17%，大幅超越未微调的 8B（52.11%），甚至超过 70B（79.72%）——任务特定微调能弥补模型规模差距
- 闭源 vs 开源差距显著：GPT-5/Gemini 2.5 Pro 在 Tool Call F1 上达 93-94%，而最佳开源 8B SFT 为 87%，说明复杂工具规划仍需更强的基座模型
- 多领域比单领域难很多：3 域场景（F-H-A）的 Code Exec Acc 仅 28.76%，远低于单域（~50%），说明跨领域工具协调是核心瓶颈
- Cache 利用率差异大：SFT 模型的 Cache EM 为 63.95%，远高于未微调版本的 29.56%，说明高效缓存复用需要专门训练
- 代码生成范式很关键：Agent 将工具调用转化为 Python 代码而非 JSON，天然支持变量传递和条件逻辑，更适合表达复杂工具依赖
亮点与洞察¶
- 系统化的工具依赖评估维度：首次将工具间输入-输出依赖链作为核心评估维度，填补了 Agent 基准的空白。这提醒我们评估 Agent 不应只看"能否调用工具"，更要看"能否协调工具"
- 缓存机制的设计哲学：将缓存决策从工具层提升到 Agent 规划层——Agent 看到 cache 摘要后自主决定复用还是重查。这比传统的自动缓存（如 LRU）更灵活，也更接近人类助手的思维方式
- 小模型 SFT 的启示：8B SFT > 70B zero-shot，说明对于结构化工具调用任务，领域适配比模型规模更重要
局限与展望¶
- 对话由模板+知识库填充生成，虽然经过人工审核，但自然度和多样性可能不如真实对话
- 仅覆盖旅行场景（航班/酒店/餐厅/景点），虽有 9 个领域组合但都围绕旅行，对其他场景（编程、数据分析、科研）的泛化性未知
- 仅英文场景，未考虑多语言
- Cache 摘要用 rule-based 方法生成，可以探索用 LLM 生成更灵活的摘要
- 未评估 Agent 的错误恢复能力——当工具调用失败时如何重规划
相关工作与启发¶
- vs TravelPlanner：同为旅行场景，但 TravelPlanner 是单轮规划，不涉及多轮交互和工具间依赖；T1 的多轮 + 缓存设计更贴近真实场景
- vs APIBank/ToolBench：覆盖大量 API，但多为单轮单工具调用，不测试工具协调
- vs GTA：GTA 有多工具链，但缺乏缓存和动态重规划维度
- vs Tau-Bench：Tau-Bench 关注对话中的约束追踪，T1 更关注工具间依赖
评分¶
- 新颖性: ⭐⭐⭐⭐ 工具依赖和缓存复用评估维度新颖，但场景局限于旅行
- 实验充分度: ⭐⭐⭐⭐ 13.5K 对话 + 开源闭源多模型对比 + few-shot/SFT 分析，较全面
- 写作质量: ⭐⭐⭐⭐ 数据构建过程透明，表格丰富，但部分细节在附录
- 价值: ⭐⭐⭐⭐ 对 Agent 工具协调能力评估有实际推动，Cache 设计可复用