为什么重要
「帮我规划一次旅行」是 Agent 最典型的卖点场景，也是最容易糊弄的场景——模型可以生成一份看起来很合理的行程，但航班号是编的、预算超了、景点当天闭馆。TravelPlanner 的价值就在于把这件事变成可判分的：它提供一个带真实数据的沙盒环境，模型必须真的去查航班、查住宿、算预算，然后交出一份能被逐条校验的方案。
它的评分分三层，这个设计很值得注意：交付率（有没有交出完整方案）、常识约束（路线是否合理、时间是否冲突）、硬约束（预算、天数、偏好是否违反）。很多 Agent 基准只测「任务完成没」，TravelPlanner 把「完成得对不对」拆成可诊断的层次——模型失败时能看出是卡在工具调用、还是卡在约束满足、还是干脆没交。
对数据侧的意义：这类带可执行环境的规划任务是训练 Agent 的高质量数据来源，因为每个失败的轨迹都能定位到具体环节。相比纯对话式的偏好数据，它提供的是「过程可验证」的监督信号。
构建方式
- 构建一个包含真实航班、住宿、景点、餐厅与交通方式的数据库作为沙盒环境
- 为每个任务指定：出发地、目的地、起止日期、预算上限、人数、偏好（如「不吃辣」「想多逛博物馆」）
- 提供 8 种工具供模型调用（查询航班、查询住宿、查询景点、查询餐厅、计算距离、查询天气等）
- 由人工为部分测试任务标注参考答案
- 评分分三层：
- Delivery：是否提交了符合格式的完整计划
- Common Sense：路线是否连贯、时间是否冲突、是否重复 Visit
- Hard Constraint：预算是否超支、住宿是否覆盖全程、是否违反明确偏好
任务示例
请为我规划一次从北京出发到成都的 3 天旅行，预算 5000 元，2 人同行，偏好川菜、希望每天至少参观一个博物馆。请给出具体航班、住宿、每日行程与预算明细。
模型需要：调用航班查询工具找到符合日期与预算的航班 → 查询住宿并确认覆盖 3 晚 → 查询博物馆开放时间排入行程 → 累加所有花费确认不超 5000 → 输出结构化计划。
任一环节出错都会在对应层被判定失败——比如预算算错会在 Hard Constraint 层挂掉，行程时间冲突会在 Common Sense 层挂掉。
最新进展
- 发布时的基线显示：即便是最强的模型，端到端的完整交付率也很低，多数失败来自约束满足而非工具调用
- 后续工作发现：给模型更明确的「分步 checklist」提示，或在工具返回中提供更结构化的信息，能明显改善成绩
- 它推动了一批「带沙盒环境的规划类基准」出现，把 Agent 评测从「能不能调用工具」推向「能不能在约束下完成多步决策」
关键发现
- 工具调用不是瓶颈，约束满足才是：模型大多能查到信息，但在多约束同时满足上容易顾此失彼
- 三层评分提供可诊断性：失败可以归因到交付 / 常识 / 硬约束，便于针对性改进
- 沙盒环境是高质量数据来源：可执行的失败轨迹比对话偏好数据更能指导 Agent 训练
- 规划长度是难度放大器：天数越多、约束越密，性能衰减越快