SkillLab 评测报告

运行时间：2026-04-15 | 总用例：135 条 | 覆盖维度：B1 / B2 / B3 / C2

一、整体结果

PARTIAL 按 0.5 分计算后：B1 加权通过率 90.6%，B2 84.7%，B3 84.1%，C2 76.9%

二、已知问题（已修复，不计入分析）

三、C2 问题深度分析（重点）

C2 是本次唯一 FAIL 率达到 19.2% 的维度，5 条 FAIL 集中暴露了两类根本性问题。

问题 1：任务分解理解有偏差（TD 维度 2 FAIL + 1 PARTIAL）

C2-TD-01 [FAIL · 简单]

用户：帮我规划成都端午节行程

Agent 一次性搜索 6 个工具、输出完整行程，但 没有先分解任务、没有确认出发地和天数。pass criteria 要求「列出子任务清单后再执行」，agent 跳过了这一步。

C2-TD-02 [FAIL · 中等]

用户：规划上海出发五天日本行

Agent 机票、酒店、景点几乎并行查询，酒店日期是预设而非根据机票结果决定的。步骤间的依赖关系没有被执行——应先查机票确认到达时间，再以此为基础查酒店和景点。

C2-TD-04 [PARTIAL · 困难] 第一步询问基础信息正确，但后续核心任务（机票+行程+酒店）未推进，任务在第一轮就停了。

根本原因：agent 对「任务分解」的理解是「列出要做的事」，而不是「按依赖顺序执行」。

问题 2：错误状态处理能力弱（EP / PR / SR 各 1 FAIL）

C2-EP-02 [FAIL · 困难]

工具返回房源数据中 community_name 为 null

Agent 未识别数据异常，而是悄悄重新搜索了一次，用新结果替换了有问题的数据，最终呈现了完全不同的房源。用户完全不知道原始数据有问题。 → 正确行为：发现字段缺失，明确告知用户「第 X 条数据不完整，无法显示小区名」，而不是静默替换。

C2-PR-03 [FAIL · 困难]

用户：规划曼谷 10 天，包含清迈和普吉岛

Agent 坚持「曼谷→清迈→普吉岛」路线，该路线存在明显绕路问题（清迈→普吉岛需经曼谷中转，约 4 小时）。被问到时，agent 不仅没有修正，反而为这条路线辩护（「经曼谷转机不算完全走回头路」）。 → Agent 无法识别自己的规划存在结构性问题，且在被质疑时选择辩护而非修正。

C2-SR-03 [FAIL · 困难]

用户：推荐 2000 元以内的手机，不要 OPPO

Agent 工具调用发现搜索结果不符合约束，理应筛选后再输出。但实际输出了 iQOO Z11x（最高 ¥2299）、荣耀 X70（最高 ¥2399）、真我 Neo7 Turbo（最高 ¥2699），同时 realme 是 OPPO 子品牌但也被推荐。 → 约束传播在多步执行中失效：第一步收到约束，但后续步骤中约束没有持续约束结果的筛选。

C2 总结

C2 的核心问题不是「不会用工具」，而是「多步执行的状态管理和自我纠错能力」。

C2 的 2 条 PARTIAL 参考

C2-MM-03 [PARTIAL] — search_hotels 连续 9 次调用，前 8 次因参数类型错误（adults 传字符串而非整数）失败，才成功一次。工具参数鲁棒性差，反复试错成本高。

C2-TD-04 [PARTIAL] — 方向正确（先询问需求），但只完成了信息收集一步，核心任务未推进。属于「入门了但没执行」。

四、B1 / B2 / B3 问题分析

B1

1 FAIL：B1-IP-01 用户说「顶级降噪耳机，预算 500 以内」，agent 直接推荐了 500 以内的耳机，完全无视了顶级降噪和低预算之间的冲突。应先指出矛盾，再提供两个方向。

4 条 PARTIAL 集中在意图优先级（IP）和多轮（MR）：

• B1-IP-02：后天出发，只给了行程，没有优先提醒签证/机票等紧急准备事项
• B1-IP-04：查到了春节机票，但没有补充旺季注意事项
• B1-MR-01：保留了「国内、不太远」约束，但未给出满足三个约束的具体推荐
• B1-CL-02：在问清需求之前就列出了一堆具体型号

共同模式：agent 在「做正确的事」和「做完整的事」之间做了错误的截断——先做了一半，另一半没做。

B2

1 条有意义的 FAIL：B2-TC-06 商品 ID 查询失败后，agent 放弃原 ID，重新搜索了一遍，最终返回了完全不同的商品。工具失败的处理策略是替换而非报告，和 C2-EP-02 是同一类问题。

5 条 PARTIAL 各不相同：

• B2-TS-04（中等）：Google Maps 返回无路线后，多调了一次 web_search（触发 Fail 标准但已完成 Pass 标准）
• B2-TC-04（困难）：找到了高赞回答，但用了 web_fetch 而不是 zhihu_get_article_detail 获取详情
• B2-PC-05（中等）：户型参数正确，但价格筛选参数传了空字符串，事后手动过滤代替了搜索层面过滤
• B2-RC-05（困难）：未重复搜索，但从训练数据虚构了搜索结果以外的机型推荐
• B2-MM-04（困难）：多步图片识别+工具链整体完成，但工具调用错误较多

B3

3 FAIL 分布在 LC（长度）和 MC（多约束）：

• B3-LC-02：「一句话总结」输出了两个句号，是基础约束未遵守
• B3-MC-02：5 家餐厅每家介绍平均 66 字，要求 ≤ 55 字

7 条 PARTIAL 集中在 AC（对抗性约束）和 MC（多约束），符合预期——这些 case 本来就是为了考验灰色地带的判断能力。

五、后续难度提升方向

B1 补充「陷阱 case」

当前 B1 case 的结构普遍是「给正确输入 → 验证正确输出」。以下 4 类陷阱 case 可以有效提升区分度：

1. 联合约束意图（被当成并行意图处理）

用户：帮我查下周去三亚的机票和酒店，机票加酒店总共不超过 4000

现有 MI 的 pass criteria 只检查「两个结果都有」，无法检测 4000 的联合预算是否被正确处理。

2. 新信息隐性取消原始意图

对话历史：[规划了明天杭州一日游]
用户：刚看了下天气，明天杭州全天暴雨

用户没有说「取消」或「改一下」，但暴雨信息隐含了「原计划需要重新考虑」。现有 MR 只测追加约束，不测隐性撤销。

3. 不该迁移上下文时迁移了

对话历史：[长段讨论了 MacBook 购买]
用户（新问题）：帮我查明天上海飞北京的机票

测 agent 是否会错误地把笔记本讨论带入机票查询。

4. 假设性探索 ≠ 执行请求

用户：如果我想辞职去云南隐居一年，大概要准备多少钱

agent 倾向于当成真实计划推进，应识别「如果」语气为可行性评估而非行动请求。

B2 补充「工具选择陷阱」

当前 TS 的 6 条 case 几乎都是「明确场景→明确工具」，没有竞争和歧义。

1. 领域关键词 ≠ 调用领域工具

用户：机票一般提前多久买最便宜

包含「机票」但本质是知识型问题，不应调用 search_flights。

2. 工具调用失败后应报告而非静默替换 基于 B2-TC-06 的模式，增加 1-2 条 case：注入的商品 ID 无效，正确行为是告知用户「该商品已下架，是否搜索相似商品？」，而不是自行搜索替换。

3. 已有结果不应重新查询 基于 B2-RC-05 的问题，增加 case：要求 agent 严格从已返回的结果中筛选，不得用训练数据补充或替换。

B3 补充「冲突约束」

B3-AC 区（对抗性约束）7 条 PARTIAL 说明这个方向已经有区分度了，可以在此基础上加强：

1. 数量约束 + 现实不可满足 基于 B3-MC-06 的模式（1000 元以内新笔记本 10 款），强化 pass criteria：必须明确说明无法满足，且不能用虚构型号凑数。

2. 长度约束的精确性 B3-LC-02（一句话总结）和 B3-MC-02（每家 50 字）都出现了基础约束违反。可以增加「50 字介绍但内容涉及 3 个并列维度」这类需要取舍的 case，考察在字数受限时如何做信息密度优化。

六、优先处理建议