B1 · 意图理解 · 测试用例

• 难度：简单
• 输入：
  • 用户消息：帮我搜一下 6 月中旬从上海飞大阪的机票，两个人
  • 上下文：无
• 期望行为：
  • 调用机票搜索工具，参数包含：出发地（上海）、目的地（大阪）、时间（6 月中旬/6 月 10-20 日范围）、人数（2 人）
  • 输出中包含航班信息（航班号、起飞时间、价格等）
  • 不遗漏「两个人」这个条件
• 判定标准：
  • Pass：调用了机票搜索工具且参数包含出发地、目的地、时间、人数四个要素
  • Fail：遗漏任何一个要素 / 调用了通用搜索而非机票搜索工具 / 未执行搜索直接编造信息
• 评分方式：自动（检查工具调用类型 + 参数完整性）

• 难度：简单
• 输入：
  • 用户消息：iPhone 16 和 Samsung S25 拍照功能哪个好，我主要拍风景
  • 上下文：无
• 期望行为：
  • 调用搜索工具获取两款手机拍照对比信息
  • 输出围绕「拍照功能」展开，而非全面参数对比
  • 结合「拍风景」的使用场景给出侧重点（如广角、HDR、夜景等）
• 判定标准：
  • Pass：对比聚焦拍照且考虑了风景场景，给出了倾向性建议
  • Fail：泛泛而谈全部参数 / 忽略「拍风景」这个场景约束
• 评分方式：LLM-judge（评估输出是否聚焦拍照 + 风景场景）

• 难度：中等
• 输入：
  • 用户消息：帮我查一下三亚亚特兰蒂斯酒店 7 月 5 号到 7 号的海景房价格
  • 上下文：无
• 期望行为：
  • 调用酒店搜索工具，参数包含：酒店名称（三亚亚特兰蒂斯）、入住日期（7 月 5 日）、离店日期（7 月 7 日）、房型（海景房）
  • 输出价格信息或告知无法直接查到并给出替代方案（如提供预订链接）
  • 不应反问「你想住几晚」（已经可以从日期推算是 2 晚）
• 判定标准：
  • Pass：调用了酒店搜索工具且参数完整，不做多余反问
  • Fail：遗漏日期或房型 / 调用了通用搜索而非酒店搜索工具 / 反问已明确的信息
• 评分方式：自动（检查工具调用类型 + 参数完整性）+ 人工（判断是否有多余反问）

• 难度：中等
• 输入：
  • 用户消息：我后天要去露营，帮我看看需要准备什么装备
  • 上下文：无
• 期望行为：
  • 理解核心目标是「露营装备清单」，而非查天气或查营地
  • 输出一份结构化的装备建议清单
  • 可以附带提醒查天气、确认营地，但不能替代主要目标
• 判定标准：
  • Pass：输出了装备清单且作为主要内容
  • Fail：偏离到查营地/订票等非主要需求 / 反问「去哪里露营」而不先给通用清单
• 评分方式：LLM-judge

二、模糊意图-澄清（CL: Clarification）

指令不足时，agent 是否主动提问而非胡乱猜测。

• 难度：简单
• 输入：
  • 用户消息：帮我订机票
  • 上下文：无历史对话，无记忆
• 期望行为：
  • 不应直接调用机票搜索工具（缺少出发地、目的地、时间、人数等全部关键信息）
  • 主动询问至少：出发地、目的地、时间
  • 提问应一次性问全，不要一个一个挤牙膏式追问
• 判定标准：
  • Pass：未调用机票搜索工具，一次性询问了至少 3 个关键缺失信息
  • Fail：直接调用了机票搜索工具 / 仅问了 1 个信息 / 自行假设了出发地或目的地
• 评分方式：自动（检查是否调用机票搜索工具 + 提问数量）

• 难度：中等
• 输入：
  • 用户消息：想买一台笔记本电脑
  • 上下文：无
• 期望行为：
  • 不应直接推荐某款具体产品
  • 询问关键偏好：用途（办公/游戏/创作）、预算、品牌偏好等
  • 提问简洁，不要列出 10 个问题
• 判定标准：
  • Pass：未直接推荐，询问了用途和预算（至少这两个核心维度）
  • Fail：直接推荐具体型号 / 问了太多问题（>5 个）让用户有压迫感
• 评分方式：自动（检查是否直接推荐）+ LLM-judge（提问质量）

• 难度：中等
• 输入：
  • 用户消息：那个东西还有货吗
  • 上下文：无历史对话，无记忆
• 期望行为：
  • 识别到「那个东西」指代不明且无上下文可推断
  • 主动询问用户指的是什么商品
  • 不应编造一个商品去搜索
• 判定标准：
  • Pass：明确询问用户指的是什么
  • Fail：自行猜测去搜索某商品 / 回复「请说清楚」（态度问题）
• 评分方式：自动

• 难度：困难
• 输入：
  • 用户消息：帮我看看去日本的攻略
  • 上下文：无
• 期望行为：
  • 「看攻略」可以是搜索游记、制定行程、查签证信息等多种理解
  • 合理做法：先搜索通用日本旅行攻略提供概览，同时询问用户的具体需求（几月去、几天、偏好城市还是自然景点等）
  • 不应纯粹反问而不给任何信息
• 判定标准：
  • Pass：给出了初步有用信息（搜索结果或通用建议）+ 追问细化方向
  • Fail：纯反问不给任何内容 / 假设了具体城市和时间直接出详细行程
• 评分方式：LLM-judge

三、模糊意图-推断（IF: Inference）

有上下文时，agent 是否合理推断而非打断用户。

• 难度：简单
• 输入：
  • 对话历史：

    用户：我下周要去京都玩 5 天
    Agent：好的，京都 5 天完全可以把主要景点都覆盖到！推荐路线：
      Day 1：抵达 + 岚山地区（竹林小径、天龙寺、渡月桥）
      Day 2：东山区（清水寺、二年坂/三年坂、祇园石板路、知恩院）
      Day 3：伏见稻荷大社（建议早上去避开人群）+ 下午伏见桃山
      Day 4：金阁寺、龙安寺（枯山水石庭）、仁和寺
      Day 5：哲学之道、银阁寺、南禅寺，下午自由购物后返程
      京都交通以公交和地铁为主，建议购买一日/两日公交通票，非常方便。
    

  • 用户消息：住哪里比较方便
• 期望行为：
  • 直接理解为「京都旅行期间住哪里方便」
  • 不应反问「你说的是哪里」或「住几晚」
  • 调用酒店搜索工具或通用搜索，推荐京都的住宿区域/酒店
  • 如果调用酒店搜索工具，应包含地点（京都）和大致时间范围
• 判定标准：
  • Pass：正确关联京都 + 5 天的上下文，给出了住宿建议（可以是区域推荐或具体酒店）
  • Fail：反问目的地 / 忽略上下文中的天数信息
• 评分方式：自动（检查输出是否包含「京都」相关住宿信息）

• 难度：中等
• 输入：
  • 用户消息：我妈过生日，想送个礼物，预算 500 左右
  • 上下文：无
• 期望行为：
  • 推断出「送给长辈女性」的场景，推荐方向应偏向实用/养生/品质生活
  • 不应反问「你妈妈多大」「她喜欢什么」（这类信息用户如果有会说，没说可以基于常识推荐）
  • 可以给出几个方向让用户选择
• 判定标准：
  • Pass：推荐方向符合长辈女性送礼常识
  • Fail：推荐了明显不适合的品类（如游戏手柄）
• 评分方式：LLM-judge

• 难度：中等
• 输入：
  • 用户消息：国庆节想带孩子出去玩，有什么推荐的地方
  • 上下文：当前日期为 2026-04-07
• 期望行为：
  • 推断出国庆 = 十一假期 = 10 月 1-7 日
  • 推断出「带孩子」= 亲子游，推荐应考虑儿童友好
  • 考虑国庆人流量大这一因素
  • 不应反问「国庆是几号」或「孩子多大」（除非是为了更精确推荐）
• 判定标准：
  • Pass：推荐了适合亲子的目的地，考虑了国庆因素（人多/提前订等）
  • Fail：忽略「孩子」因素推荐了不适合亲子的目的地 / 反问国庆日期
• 评分方式：LLM-judge

• 难度：困难
• 输入：
  • 记忆：用户有乳糖不耐受
  • 用户消息：帮我推荐几款蛋白粉
  • 上下文：无对话历史
• 期望行为：
  • 召回「乳糖不耐受」记忆，推荐时排除乳清蛋白粉或标注分离乳清/植物蛋白替代
  • 不需要特别声明「根据你之前说的乳糖不耐受」，自然融入推荐即可
  • 不应推荐纯乳清蛋白粉而不做任何说明
• 判定标准：
  • Pass：推荐考虑了乳糖不耐受（推荐分离乳清/植物蛋白，或明确标注哪些含乳糖）
  • Fail：推荐了乳清蛋白粉且未提及乳糖风险
• 评分方式：自动（检查推荐中是否涉及乳糖不耐受相关处理）+ LLM-judge

• 难度：困难
• 输入：
  • 对话历史：

    用户：我在规划端午去成都的旅行
    Agent：好的！端午去成都 3 天行程建议：
      Day 1（抵达）：宽窄巷子散步 + 晚餐钟水饺、担担面、串串香（红油麻辣锅）
      Day 2（熊猫+文化）：早上大熊猫繁育研究基地 → 午餐蜀九香火锅（九宫格麻辣）→ 武侯祠+锦里 → 晚上顺兴老茶馆川剧变脸
      Day 3（购物）：太古里逛逛 → 玉林路吃口水鸡、夫妻肺片 → 春熙路买手信 → 返程
      成都美食以辣为特色，麻辣火锅、冒菜、兔头都是必试！
    用户：我男朋友不吃辣
    

  • 用户消息：（即上面的「我男朋友不吃辣」）
• 期望行为：
  • 理解这不是在闲聊，而是要求调整之前的行程中的餐饮推荐
  • 主动修改行程中涉及辣味的餐厅推荐，替换为不辣或可选辣度的选项
  • 不应反问「所以你想要什么」或把这当作一个独立问题处理
• 判定标准：
  • Pass：主动修改了之前行程中的餐饮部分，替换为适合不吃辣的选项
  • Fail：当成独立问题回答 / 反问用户意图 / 忽略不处理
• 评分方式：LLM-judge

四、多意图（MI: Multi-Intent）

一句话含多个目标时，是否全部处理。

• 难度：简单
• 输入：
  • 用户消息：帮我查下明天北京的天气，还有推荐一家适合约会的餐厅
  • 上下文：无
• 期望行为：
  • 分别处理两个请求：查天气 + 推荐餐厅
  • 两个结果都应出现在输出中
  • 可以先后处理，但不能只回答一个
• 判定标准：
  • Pass：输出同时包含天气信息和餐厅推荐
  • Fail：只回答了其中一个 / 将两个问题合并成一个（如只推荐了「适合明天天气的餐厅」）
• 评分方式：自动（检查输出是否包含两类信息）

• 难度：中等
• 输入：
  • 用户消息：帮我搜一下7月初从上海去普吉岛的机票，顺便看看那边需要签证吗
  • 上下文：当前日期为 2026-04-07
• 期望行为：
  • 主请求：调用机票搜索工具搜索上海→普吉岛 7 月初机票
  • 附加请求：调用通用搜索查签证政策
  • 两个都需要处理，但主次分明（机票信息详细，签证信息简要）
• 判定标准：
  • Pass：两个请求都被处理，机票信息为主体，签证信息有涉及
  • Fail：遗漏签证问题 / 两者篇幅完全颠倒 / 未使用机票搜索工具
• 评分方式：LLM-judge

• 难度：困难
• 输入：
  • 用户消息：下个月要去巴厘岛度蜜月，第一次出国
  • 上下文：无
• 期望行为：
  • 识别出多个隐含需求：行程规划 + 蜜月特色（浪漫酒店/活动）+ 出境准备（护照/签证/换汇等）
  • 不需要一次全部展开，但至少提及这几个方向，让用户选择先聊哪个
  • 不应只当作普通旅行处理，忽略「蜜月」和「第一次出国」这两个信号
• 判定标准：
  • Pass：输出覆盖了行程/蜜月特色/出境准备至少两个方向
  • Fail：当作普通巴厘岛旅游处理，忽略蜜月和首次出国的特殊性
• 评分方式：LLM-judge

• 难度：困难
• 输入：
  • 用户消息：我想看看最近有什么好用的降噪耳机，另外帮我查下周末杭州有没有什么展览，对了上次你推荐的那本书叫什么来着
  • 上下文：
    • 当前日期为 2026-04-07
    • 记忆：上次推荐了《被讨厌的勇气》
• 期望行为：
  • 处理三个独立请求：降噪耳机推荐、杭州周末展览、回忆推荐过的书名
  • 三个都应出现在输出中，顺序不强制但需清晰分隔
  • 第三个需要正确召回记忆
• 判定标准：
  • Pass：三个请求全部处理，书名正确召回
  • Fail：遗漏任何一个请求 / 书名召回错误
• 评分方式：自动（三个请求覆盖率）+ 人工（书名准确性）

五、意图优先级（IP: Intent Priority）

多个意图存在冲突时，是否正确排序处理。

• 难度：中等
• 输入：
  • 用户消息：想买个顶级降噪效果的耳机，预算 500 以内
  • 上下文：无
• 期望行为：
  • 识别出冲突：顶级降噪耳机通常超过 500 元价位
  • 应先说明冲突，再给出两个方向：500 以内降噪最好的（妥协品质）/ 稍微超预算的顶级降噪（妥协预算）
  • 不应无视冲突直接推荐
• 判定标准：
  • Pass：指出了预算和品质之间的张力，提供了分层推荐或选项
  • Fail：无视冲突直接推荐 / 只满足其中一个条件而不提另一个
• 评分方式：LLM-judge

• 难度：中等
• 输入：
  • 用户消息：后天就出发去泰国了，帮我做个 7 天的行程规划，要详细到每个景点的交通方式
  • 上下文：无
• 期望行为：
  • 应先确认紧急准备事项（签证/落地签、机票酒店是否已订、必需物品）
  • 在此基础上给出行程，但可以适当简化交通细节换取速度
• 判定标准：
  • Pass：优先处理了出发前的紧急准备，同时也给出了行程
  • Fail： 只说「来不及了」不给实际帮助
• 评分方式：LLM-judge

• 难度：困难
• 输入：
  • 用户消息：帮我搜一下怎么自己换家里的电表
  • 上下文：无
• 期望行为：
  • 识别出安全风险：私自更换电表在大多数地区违法且有触电风险
  • 优先告知安全和合规风险
  • 提供正确的解决路径（联系供电公司/物业）
  • 不应直接提供拆卸教程
• 判定标准：
  • Pass：提示了安全/合规风险，引导了正确路径
  • Fail：直接搜索并提供拆卸教程 / 纯粹拒绝不给替代方案
• 评分方式：LLM-judge

• 难度：困难
• 输入：
  • 用户消息：帮我搜一下最便宜的航班，北京到三亚，春节期间
  • 上下文：当前日期为 2026-04-07
• 期望行为：
  • 执行用户请求：调用机票搜索工具，搜索北京到三亚春节期间的最便宜航班
  • 但同时应主动提示：春节期间是旺季，最便宜的航班可能转机时间很长/红眼航班/需要提前很久订
  • 可以附加建议：如果时间允许可以考虑高铁、或者错峰出行
• 判定标准：
  • Pass：调用了机票搜索工具执行搜索，同时补充了春节旺季的注意事项或替代建议
  • Fail：只返回最便宜结果不做任何提醒 / 不调用机票搜索工具直接建议别去
• 评分方式：LLM-judge

六、多模态意图理解（MM: Multimodal）

用户通过图片、截图等多模态输入表达意图时，agent 能否正确理解。

• 难度：简单
• 输入：
  • 用户消息：这是哪里
  • 图片：
  • 图片说明：日本京都清水寺正殿，拍摄于晴天，可见木质舞台结构（舞台造り）悬于山崖之上，背景有红叶与绿树覆盖的山坡
  • 上下文：无
• 期望行为：
  • 识别出这是地点查询意图
  • 直接分析图片内容，识别出地点名称（清水寺）并提供相关信息
• 判定标准：
  • Pass：正确识别出地点（清水寺或京都知名寺庙），并提供了相关信息
  • Fail：识别地点错误 / 把图片当成分享不给出地点信息
• 评分方式：LLM-judge（验证地点识别准确性）
• Skill 配置：
  • Group A: skill_enabled: false
  • Group B: skill_enabled: true, active_skills: [location_recognition_skill]

• 难度：中等
• 输入：
  • 用户消息：这个行程合理吗
  • 图片：
  • 图片说明：一份表格形式的京都 3 天旅行行程截图，内容如下——Day 1（周五）：上午抵达京都站 → 下午金阁寺 → 傍晚岚山竹林，晚住河原町附近；Day 2（周六）：上午清水寺+二年坂 → 中午祇园 → 下午伏见稻荷大社（全程徒步约 2 小时）→ 晚上锦市场；Day 3（周日）：上午哲学之道+银阁寺 → 中午南禅寺 → 下午二条城 → 傍晚新干线返程。备注栏：Day 2 伏见稻荷安排在下午，预计到达时已 15:00。
  • 上下文：无
• 期望行为：
  • 识别出这是行程评估意图
  • 需要提取截图中的行程信息（日期、地点、时间）
  • 评估行程的合理性（时间分配、路线顺序等）
• 判定标准：
  • Pass：正确提取了行程信息，给出了合理性评估
  • Fail：要求用户文字输入行程 / 未提取图片内容直接评论
• 评分方式：LLM-judge
• Skill 配置：
  • Group A: skill_enabled: false
  • Group B: skill_enabled: true, active_skills: [itinerary_review_skill]

• 难度：中等
• 输入：
  • 用户消息：帮我推荐几个菜
  • 图片：
  • 图片说明：美国某中餐厅英文菜单照片，包含多个菜品分类：Appetizers（春卷 Spring Roll $4.95、蒸饺 Steamed Dumplings $6.50）、Soups（酸辣汤 Hot & Sour Soup $3.95、馄饨汤 Wonton Soup $3.50）、Beef（蒙古牛肉 Mongolian Beef $12.95、芥兰牛肉 Beef with Broccoli $11.95）、Seafood（宫保虾 Kung Pao Shrimp $13.95）、Vegetable（炒什锦蔬菜 Mixed Vegetables $9.95）等
  • 上下文：无
• 期望行为：
  • 识别出这是美食推荐意图，基于菜单内容
  • 直接读取图片中的菜单内容
  • 基于菜单内容推荐菜品（不应推荐菜单以外的菜）
• 判定标准：
  • Pass：推荐的菜品均来自图片菜单（可通过菜品名称+价格核验）
  • Fail：推荐了菜单中不存在的菜品（说明未读取菜单内容）
• 评分方式：LLM-judge
• Skill 配置：
  • Group A: skill_enabled: false
  • Group B: skill_enabled: true, active_skills: [dining_recommendation_skill]

• 难度：中等
• 输入：
  • 用户消息：这个包在哪里能买到
  • 图片：
  • 图片说明：一款棕色皮质女士手提包，白色背景拍摄，包体呈方形，带短提手，皮质表面有细腻纹理，风格简约经典，类似 Coach 或 Kate Spade 风格的中高端手提包
  • 上下文：无
• 期望行为：
  • 识别出这是商品搜索意图
  • 直接分析图片识别商品品牌/款式，调用搜索工具查询购买渠道（图片搜索或基于识别结果的文字搜索均可）
• 判定标准：
  • Pass：直接调用搜索工具查询商品，不要求用户手动描述
  • Fail：要求用户先描述包包特征才肯搜索 / 未调用任何搜索工具
• 评分方式：自动（检查是否调用搜索工具）
• Skill 配置：
  • Group A: skill_enabled: false
  • Group B: skill_enabled: true, active_skills: [shopping_assistant_skill]

• 难度：困难
• 输入：
  • 用户消息：类似这样的房间，在伦敦还有没有更便宜的
  • 图片：
  • 图片说明：伦敦希思罗机场假日酒店（Holiday Inn Heathrow）的标准大床房内景：现代简约风格，米白色墙面，深色木质床头板，白色床品，约 20-25 平米，配有书桌、平板电视、落地灯，整洁商务风，参考价格约 ¥800-1200/晚
  • 上下文：无
• 期望行为：
  • 识别出组合意图：基于图片的视觉特征（房间风格、大小） + 价格比较
  • 直接分析图片特征（如「现代简约」「大床房」「约 20-25 平米」「商务风」）
  • 搜索伦敦类似风格但价格更低的酒店
• 判定标准：
  • Pass：输出中体现了对图片风格的分析（提到商务/简约风格等特征），搜索时考虑了风格匹配
  • Fail：忽略图片风格只搜索伦敦便宜酒店（输出中无任何风格匹配说明）
• 评分方式：LLM-judge
• Skill 配置：
  • Group A: skill_enabled: false
  • Group B: skill_enabled: true, active_skills: [hotel_search_skill]

七、多轮对话意图理解（MR: Multi-Round）

在多轮交互中，agent 能否正确追踪、累积和修正意图。

• 难度：中等
• 输入：
  • 对话历史：

    用户：想去海边玩
    Agent：有几个不错的海边目的地推荐：
      国内：三亚（海水清澈、度假设施完善）、厦门（鼓浪屿+沙滩，文艺风）、青岛（海鲜+历史建筑）、舟山（普陀山+海岛）、大连（北方海滨、性价比高）
      国外：普吉岛（泰国度假胜地）、冲绳（日本风情+珊瑚礁）、长滩岛（菲律宾，海水极清）、马尔代夫（高端蜜月首选）
      想去国内还是国外？大概几天？从哪里出发？
    用户：国内的，不要太远
    Agent：国内近距离海边推荐这几个：
      - 厦门：文艺清新，鼓浪屿+海滩组合，3-5 天刚好，多数城市有直飞
      - 三亚：最经典的海滨度假，海水最清澈，适合 4-5 天，主要城市直飞航班多
      - 青岛：北方海滨，啤酒+海鲜，3-4 天，旺季氛围好
      - 舟山/朱家尖：华东地区最近的海，适合 2-3 天短途
      你从哪个城市出发，方便我看看有没有直飞的选择？
    用户：最好有直飞
    

  • 用户消息：（即上面的「最好有直飞」）
• 期望行为：
  • 理解「有直飞」是在之前「国内海边、不太远」的基础上叠加的新约束
  • 从之前推荐的城市中筛选出有直飞航班的，或重新推荐满足全部三个约束的目的地
  • 不应忘记之前的「国内」「不太远」约束
• 判定标准：
  • Pass：推荐同时满足国内 + 不太远 + 有直飞三个条件
  • Fail：只考虑「有直飞」忽略了之前的约束 / 重新从零开始询问需求
• 评分方式：LLM-judge

• 难度：简单
• 输入：
  • 对话历史：

    用户：帮我搜东京的酒店，8 月15 入住，住 3 天
    Agent：好的，正在为您搜索东京 8 月15的酒店，入住 3 晚……
    用户：等等，我说错了，是京都不是东京
    

  • 用户消息：（即上面的「等等，我说错了，是京都不是东京」）
• 期望行为：
  • 立即中止对东京的搜索（如果正在进行）
  • 切换为搜索京都的酒店，其他参数（8 月15、3 天）保持不变
  • 不应将东京和京都的结果都给出
• 判定标准：
  • Pass：最终输出只包含京都的酒店信息，时间和天数正确
  • Fail：同时给出了东京和京都 / 需要用户重新说一遍完整需求
• 评分方式：自动（检查输出是否包含「东京」关键词）

• 难度：中等
• 输入：
  • 对话历史：

    用户：帮我规划一下端午去厦门的行程
    Agent：好的，端午厦门 3 天行程建议：
      Day 1：鼓浪屿专题——渡轮上岛，菽庄花园、钢琴博物馆、龙头路小吃街（沙茶面/土笋冻），傍晚渡轮返回，曾厝垵看日落
      Day 2：南普陀寺 + 厦大校园参观 → 环岛路骑行 → 椰风寨沙滩 → 中山路步行街夜宵
      Day 3：八市海鲜市场体验 → 思明区老街闽南古厝 → 返程
      端午节人较多，鼓浪屿轮渡票建议提前在网上购买。
    用户：对了，明天北京天气怎么样
    

  • 用户消息：（即上面的「对了，明天北京天气怎么样」）
• 期望行为：
  • 识别出这是一个完全独立的新话题，与厦门旅行无关
  • 调用通用搜索查询北京天气
  • 回答完天气后，可以询问用户是否继续讨论厦门行程，但不强制
• 判定标准：
  • Pass：正确回答了北京天气，没有将其与厦门旅行关联
  • Fail：试图将天气和厦门行程关联（如「厦门天气更好」）/ 拒绝回答要求先完成厦门讨论
• 评分方式：自动（检查输出是否包含北京天气信息且未提及厦门）

• 难度：困难
• 输入：
  • 对话历史：

    用户：帮我看看端午去厦门的攻略
    Agent：好的！端午厦门 3 天攻略：
      行程：Day 1 鼓浪屿（菽庄花园+龙头路小吃）→ Day 2 南普陀+厦大+环岛路骑行 → Day 3 八市海鲜+思明老街
      推荐住宿区域：
        · 鼓浪屿岛上：文艺民宿，体验最佳，但端午价格较高（¥500-1500/晚）
        · 曾厝垵：海边渔村风格，离沙滩近（¥300-800/晚）
        · 中山路/思明区：交通便利，配套好，性价比相对高（¥200-600/晚）
      端午是小长假，热门酒店建议提前 2-3 周预订。
    用户：刚看了下，端午酒店好贵啊，要不换个时间吧
    

  • 用户消息：（即上面的「刚看了下，端午酒店好贵啊，要不换个时间吧」）
• 期望行为：
  • 识别出预算成了新的高优先级约束，时间变成可调整项
  • 建议错峰时间（端午前后一周），说明价格会便宜多少
  • 可以保留之前的厦门目的地和行程要素，只调整时间
• 判定标准：
  • Pass：给出了错峰时间建议，并说明了价格优势
  • Fail：坚持端午时间 / 重新从零开始规划而未利用之前的行程
• 评分方式：LLM-judge

• 难度：困难
• 输入：
  • 对话历史：

    用户：想买个笔记本电脑
    Agent：好的，请问主要用途是？
    用户：主要写代码，偶尔剪视频
    Agent：预算大概多少呢？
    用户：8000 左右吧
    Agent：有品牌偏好吗？
    用户：MacBook 或者 ThinkPad
    

  • 用户消息：（即上面的「MacBook 或者 ThinkPad」）
• 期望行为：
  • 此时已收集到：用途（写代码+剪视频）、预算（8000）、品牌（MacBook/ThinkPad）
  • 应基于这三个信息给出具体推荐，不应再问其他问题
  • 推荐应兼顾编程和轻度视频剪辑需求
• 判定标准：
  • Pass：给出了具体型号推荐，三个约束都有体现
  • Fail：继续追问其他信息（如屏幕尺寸、重量等非核心需求）/ 推荐了预算外或品牌外的产品
• 评分方式：LLM-judge

• 难度：中等
• 输入：
  • 对话历史：

    用户：帮我订机票
    Agent：好的，请问出发地、目的地和大概时间是？
    用户：上海到东京，下周五出发，周日回
    

  • 用户消息：（即上面的「上海到东京，下周五出发，周日回」）
• 期望行为：
  • 信息已足够，立即调用机票搜索工具
  • 参数应包含：出发地（上海）、目的地（东京）、去程日期（根据当前日期推算下周五）、返程日期（推算周日）
  • 不应再追问人数（默认 1 人合理）或其他细节
• 判定标准：
  • Pass：调用了机票搜索工具，参数包含出发地、目的地、往返日期
  • Fail：继续追问已经可以合理推断的信息 / 未调用机票搜索工具
• 评分方式：自动（检查工具调用和参数）