Q3 · 效率 · 测试用例
对应框架维度：Q3 效率 状态：初稿 最后更新：2026-04-07
维度说明
Q3 测试 agent 完成任务的路径是否最优，避免冗余步骤和不必要的 token 消耗。这是产品部署的成本基准。
核心问题：agent 能否用最短路径、最少 token 完成任务，而不是「能完成但绕远路」。
与 B2-RC（工具冗余调用）的区别：
- B2-RC：测重复调用相同工具（明显的冗余）
- Q3：测整体路径效率（可能每步都不重复，但整体绕远了）
用例规范
| 字段 | 说明 |
|---|---|
| ID | 格式：Q3-{维度缩写}-{序号} |
| 维度 | 所属评测子维度 |
| 难度 | 简单 / 中等 / 困难 |
| 理论最优步骤数 | 人工标注的最短路径步骤数 |
| 输入 | 用户消息 + 上下文 |
| 期望行为 | agent 的高效执行路径 |
| 判定标准 | Pass / Fail 条件（基于步骤数比、token 数） |
| 评分方式 | 自动 |
| Skill 配置 | 必须开启 |
一、步骤数效率（SE: Step Efficiency）
实际步骤数 vs 理论最优步骤数之比。
Q3-SE-01 · 简单查询任务
- 难度：简单
- 理论最优步骤数：1（直接调用工具）
- 输入：
- 用户消息：
查一下明天北京的天气 - 上下文：无
- 用户消息：
- 期望行为：
- 最优路径：直接调用 maps_weather(city: "北京")，1 步完成
- 不应该：先 web_search 查北京的地理位置，再调用天气工具（2 步，冗余）
- 判定标准：
- Pass：1 步完成（效率比 = 1.0）
- Acceptable：2 步完成（效率比 = 2.0）
- Fail：3 步及以上（效率比 ≥ 3.0）
- 评分方式：自动（计数工具调用次数）
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-SE-02 · 搜索→详情链
- 难度：简单
- 理论最优步骤数：2（搜索 + 详情）
- 输入：
- 用户消息：
微博热搜第二条的详细内容是什么 - 上下文：无
- 用户消息：
- 期望行为：
- 最优路径：
- weibo_get_hot_search（获取热搜榜）
- weibo_get_post_detail(post_id: 第二条的 ID)
- 不应该：先搜索「微博热搜」→ 再获取热搜榜 → 再查详情（3 步，冗余）
- 最优路径：
- 判定标准：
- Pass：2 步完成（效率比 = 1.0）
- Acceptable：3 步（效率比 = 1.5）
- Fail：4 步及以上
- 评分方式：自动
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-SE-03 · 依赖链最优路径
- 难度：中等
- 理论最优步骤数：2（lookup + search）
- 输入：
- 用户消息：
北京朝阳区有哪些二手房 - 上下文：无
- 用户消息：
- 期望行为：
- 最优路径：
- beike_lookup_city_id(city_name: "北京")
- beike_search_resale_housing(city_id: result, district: "朝阳区")
- 不应该：先 web_search 查北京的 city_id（3 步，可以直接用工具）
- 最优路径：
- 判定标准：
- Pass：2 步完成（效率比 = 1.0）
- Fail：3 步及以上
- 评分方式：自动
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-SE-04 · 避免不必要的详情查询
- 难度：中等
- 理论最优步骤数：1（搜索即可）
- 输入：
- 用户消息：
淘宝上 iPhone 16 大概多少钱 - 上下文：无
- 用户消息：
- 期望行为：
- 最优路径：taobao_search_products(keyword: "iPhone 16")，从搜索结果提取价格（通常包含）
- 不应该：搜索 → 对每个商品调用 taobao_get_product_detail（6+ 步，冗余）
- 用户只问「大概多少钱」，不需要详细信息
- 判定标准：
- Pass：1 步完成（效率比 = 1.0）
- Acceptable：2 步（如果搜索结果确实没有价格，查 1 个详情）
- Fail：3 步及以上
- 评分方式：自动
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
二、Token 消耗（TC: Token Consumption）
完成同类任务的平均 token 用量。
Q3-TC-01 · 简洁回答（简单查询）
- 难度：简单
- 理论最优 token：约 150 tokens（1 句话说明 + 天气信息）
- 输入：
- 用户消息：
明天北京天气 - 上下文：无
- 用户消息：
- 期望行为：
- 简洁输出：「明天北京晴天，15-25°C，适合出行」
- 不应输出大段内容（如详细的气象分析、穿衣建议、历史天气对比）
- 判定标准：
- Pass：输出 ≤ 200 tokens
- Acceptable：200-400 tokens
- Fail：> 400 tokens（过度输出）
- 评分方式：自动（token 计数）
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-TC-02 · 避免输出冗余的背景信息
- 难度：中等
- 理论最优 token：约 300-500 tokens（推荐内容）
- 输入：
- 用户消息：
推荐几款降噪耳机 - 上下文：无
- 用户消息：
- 期望行为：
- 高效输出：直接推荐 3-5 款耳机，包含型号、价格、核心特点
- 不应该：
- 长篇介绍降噪技术原理（200+ tokens 背景）
- 解释为什么选择这些品牌（用户没问）
- 详细的购买指南（用户没问）
- 用户要什么给什么，不多余
- 判定标准：
- Pass：输出 300-600 tokens，聚焦推荐本身
- Acceptable：600-1000 tokens
- Fail：> 1000 tokens（包含大量用户未要求的信息）
- 评分方式：自动（token 计数）+ LLM-judge（判断是否有冗余内容）
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-TC-03 · 多轮中的增量输出
- 难度：中等
- 理论最优 token：约 200 tokens（只输出新信息）
- 输入：
- messages 注入（执行用）：
[ {"role": "user", "content": "推荐几款笔记本"}, {"role": "assistant", "content": "为您推荐以下 5 款笔记本：\n\n1. **苹果 MacBook Air M3**（13英寸）- 价格约 9499 元，重量 1.24kg，续航可达 18 小时，性能优秀，适合日常办公和创作。\n\n2. **联想小新 Pro 16 2024**（16英寸，i7-13700H）- 价格约 5499 元，重量 1.9kg，2.5K 分辨率屏幕，性价比高，适合学生和上班族。\n\n3. **华为 MateBook X Pro 2024**（14.2英寸）- 价格约 7999 元，重量 1.26kg，OLED 屏幕，轻薄商务本，续航约 12 小时。\n\n4. **戴尔 XPS 15 9530**（15英寸，i7-13700H）- 价格约 10999 元，重量 1.86kg，OLED 触屏可选，适合专业创作者。\n\n5. **华硕 灵耀 14 2024**（14英寸，Ultra 9 185H）- 价格约 8499 元，重量 1.39kg，OLED 2.8K 屏，轻薄旗舰定位。"} ] - 用户消息：
有没有轻薄一点的
- messages 注入（执行用）：
- 期望行为：
- 高效输出：从之前 5 款中筛选出轻薄的，只输出筛选结果
- 不应该：重新输出完整的 5 款对比（重复 1000 tokens）
- 增量输出：「之前推荐的 5 款中，苹果 MacBook Air M3（1.24kg）、华为 MateBook X Pro 2024（1.26kg）和华硕灵耀 14（1.39kg）比较轻薄」
- 判定标准：
- Pass：输出 ≤ 300 tokens，只包含新信息
- Fail：> 800 tokens，重复了之前的全部内容
- 评分方式：自动（token 计数）
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
三、冗余调用率（RC: Redundant Calls）
不必要的重复工具调用比例。
Q3-RC-01 · 利用已有搜索结果
- 难度：中等
- 理论最优调用数：1（利用已有结果）
- 输入：
- messages 注入（执行用）：
[ {"role": "user", "content": "淘宝搜一下机械键盘"}, {"role": "assistant", "content": [{"type": "tool_use", "id": "toolu_01", "name": "taobao_search_products", "input": {"keyword": "机械键盘", "count": 10}}]}, {"role": "user", "content": [{"type": "tool_result", "tool_use_id": "toolu_01", "content": "{\"total\": 10, \"items\": [{\"id\": \"kb001\", \"name\": \"雷柏 V500 PRO 机械键盘 87键\", \"price\": 199, \"features\": \"青轴，无背光，防水溅设计\"}, {\"id\": \"kb002\", \"name\": \"ikbc C87 机械键盘 TKL\", \"price\": 299, \"features\": \"樱桃红轴，无背光，PBT键帽\"}, {\"id\": \"kb003\", \"name\": \"达尔优 EK815 机械键盘\", \"price\": 149, \"features\": \"红轴，RGB背光，有线\"}, {\"id\": \"kb004\", \"name\": \"罗技 G412 SE 机械游戏键盘\", \"price\": 399, \"features\": \"罗技 GX 红轴，白色 LED 背光\"}, {\"id\": \"kb005\", \"name\": \"雷蛇 BlackWidow V3 机械键盘\", \"price\": 799, \"features\": \"雷蛇绿轴，Chroma RGB 背光，全尺寸\"}, {\"id\": \"kb006\", \"name\": \"双飞燕 B975 光轴键盘\", \"price\": 259, \"features\": \"光轴，RGB 背光，全键无冲\"}, {\"id\": \"kb007\", \"name\": \"Leopold FC900R 机械键盘\", \"price\": 699, \"features\": \"樱桃茶轴，无背光，PBT 二色注塑键帽\"}, {\"id\": \"kb008\", \"name\": \"腹灵 FL980 机械键盘\", \"price\": 399, \"features\": \"红轴，RGB 背光，铝合金外壳\"}, {\"id\": \"kb009\", \"name\": \"客制化 GK68XS 机械键盘\", \"price\": 499, \"features\": \"热插拔轴，RGB 背光，蓝牙+有线双模\"}, {\"id\": \"kb010\", \"name\": \"樱桃 MX 2.0S 机械键盘\", \"price\": 599, \"features\": \"樱桃红轴，无背光，静音版可选\"}]}"}]}, {"role": "assistant", "content": "为您找到 10 款机械键盘，价格从 149 元到 799 元不等，涵盖青轴、红轴、茶轴等主流轴体，有达尔优、罗技、雷蛇、腹灵等品牌。"}, {"role": "user", "content": "有 RGB 灯光的有哪些"} ] - 用户消息：（即「有 RGB 灯光的有哪些」）
- messages 注入（执行用）：
- 期望行为：
- 最优路径：从已有的 10 个搜索结果中筛选（0 次新调用）
- 如果搜索结果确实不包含灯光信息，可以重新搜索时加关键词（1 次调用）
- 不应该：无条件重新搜索（1 次冗余调用）
- 判定标准：
- Pass：未调用工具（利用已有结果）或只调用 1 次（加精确筛选）
- Fail：调用了 2 次及以上（如重新搜「机械键盘」再搜「机械键盘 RGB」）
- 评分方式：自动（计数工具调用）
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-RC-02 · 批量查询 vs 逐个查询
- 难度：中等
- 理论最优调用数：1（批量接口）
- 输入：
- 用户消息：
帮我查一下从朝阳公园到故宫、天坛、鸟巢这三个地方分别怎么走 - 上下文：无
- 用户消息：
- 期望行为：
- 如果有批量接口（如 compute_google_maps_route_matrix），应该 1 次调用查 3 条路线
- 不应该：调用 3 次 compute_google_maps_routes（逐个查询）
- 判定标准：
- Pass：1 次调用（使用批量接口，效率比 = 1.0）
- Acceptable：3 次调用（逐个查询，效率比 = 3.0）
- Fail：> 3 次调用（有重复）
- 评分方式：自动
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-RC-03 · 避免重复的数据获取
- 难度：中等
- 理论最优调用数：2（搜索 + 详情 × 1）
- 输入：
- 用户消息：
这款耳机的价格、评价、销量分别是多少 - 上下文：已通过搜索知道了 product_id
- 用户消息：
- 期望行为：
- 最优路径：
- taobao_get_product_detail（获取价格和销量）
- taobao_get_product_reviews（获取评价）
- 不应该：分别调用 3 次工具去获取价格、评价、销量（如果详情接口能一次返回价格和销量）
- 最优路径：
- 判定标准：
- Pass：2 次调用完成
- Fail：3 次及以上（冗余）
- 评分方式：自动
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
四、输出冗余度（OR: Output Redundancy）
输出是否含有超出任务需求的多余内容。
Q3-OR-01 · 用户只问 A，不输出 B
- 难度：简单
- 理论最优输出长度：100-150 tokens
- 输入：
- 用户消息：
AirPods Pro 2 多少钱 - 上下文：无
- 用户消息：
- 期望行为：
- 高效输出：「AirPods Pro 2 在淘宝上的价格是 1899 元」
- 不应该附加：
- 产品的详细参数（用户没问）
- 与其他型号的对比（用户没问）
- 购买建议和使用技巧（用户没问）
- 判定标准：
- Pass：输出 ≤ 200 tokens，只包含价格信息
- Fail：> 400 tokens，包含大量用户未要求的信息
- 评分方式：自动（token 计数）+ LLM-judge
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-OR-02 · 推荐时的信息密度
- 难度：中等
- 理论最优输出长度：400-600 tokens（3 款 × 150 tokens/款）
- 输入：
- 用户消息：
推荐 3 款降噪耳机 - 上下文：无
- 用户消息：
- 期望行为：
- 高效输出：3 款耳机，每款包含型号、价格、核心特点（2-3 句）
- 不应该：
- 每款都写 300+ tokens 的详细评测
- 包含历史发展、技术原理等背景
- 附带完整的购买指南
- 判定标准：
- Pass：输出 400-700 tokens，信息密度高
- Acceptable：700-1000 tokens
- Fail：> 1200 tokens（每款平均 > 400 tokens，过于冗长）
- 评分方式：自动（token 计数）+ LLM-judge（信息密度评估）
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-OR-03 · 多轮中避免重复背景介绍
- 难度：中等
- 理论最优输出长度：200 tokens（只回答当前问题）
- 输入：
- messages 注入（执行用）：
[ {"role": "user", "content": "介绍一下京都的旅行特色"}, {"role": "assistant", "content": "京都是日本最具历史文化底蕴的城市之一，保存了大量完好的传统建筑和神社寺院。以下是京都旅行的主要特色：\n\n**历史文化景点**：清水寺、金阁寺、岚山竹林、伏见稻荷大社、二条城等，合计超过 17 处世界遗产。\n\n**传统文化体验**：祇园花见小路可以邂逅艺伎；京都有众多茶道、插花、和服体验课程；三条、四条一带保留了大量传统町家建筑。\n\n**美食特色**：怀石料理发源地，豆腐料理（湯豆腐）、京都拉面、宇治抹茶点心闻名全国；锦市场（「京都的厨房」）有各种当地食材和小吃。\n\n**最佳旅游时间**：春季（3月下旬-4月初）赏樱，秋季（11月）红叶，各有特色；夏季（7月）有祇园祭，冬季（12月-2月）人少但有雪景可赏。\n\n**交通**：市内交通以公交和地铁为主，可购买京都 1-3 日公交通票；从大阪或东京乘新干线可达。"} ] - 用户消息：
那住宿推荐呢
- messages 注入（执行用）：
- 期望行为：
- 高效输出：直接推荐住宿区域，不重复京都背景介绍
- 不应该：「京都是一座历史悠久的城市...（重复之前 200 tokens）...住宿方面推荐...」
- 判定标准：
- Pass：输出 ≤ 300 tokens，无重复背景
- Fail：> 500 tokens，重复了之前介绍过的内容
- 评分方式：自动（token 计数）+ LLM-judge（检测重复）
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-OR-04 · 免责声明和礼貌用语的冗余
- 难度：困难
- 理论最优输出长度：300 tokens（核心内容）
- 输入：
- 用户消息：
推荐几款 3000 元左右的手机 - 上下文：无
- 用户消息：
- 期望行为：
- 高效输出：直接推荐手机，核心信息为主
- 不应该包含过多：
- 免责声明（「以上信息仅供参考，请以实际为准」「价格可能有变动」）
- 过度礼貌用语（「非常感谢您的提问」「希望对您有所帮助」）
- 冗长的开场白（「在为您推荐之前，我想先说明一下...」）
- 这些内容通常占 50-100 tokens，对用户价值低
- 判定标准：
- Pass：核心内容占比 > 80%（免责和礼貌用语 < 20%）
- Fail：冗余内容占比 > 30%
- 评分方式：LLM-judge（计算核心内容 vs 冗余内容比例）
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
五、整体效率综合测试（OE: Overall Efficiency）
综合步骤数、token 数、冗余调用的整体效率评估。
Q3-OE-01 · 简单任务的整体效率
- 难度：简单
- 理论最优：1 步，150 tokens
- 输入：
- 用户消息：
查北京明天天气 - 上下文：无
- 用户消息：
- 期望行为：
- 1 步完成，输出简洁（150-200 tokens）
- 效率得分 = (1/实际步骤数) × (150/实际 tokens) × 100
- 判定标准：
- Pass：效率得分 ≥ 80
- Acceptable：60-80
- Fail：< 60
- 评分方式：自动（综合计算）
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-OE-02 · 中等复杂任务的效率
- 难度：中等
- 理论最优：3 步，500 tokens
- 输入：
- 用户消息：
对比一下索尼和 Bose 的降噪耳机，推荐一个 - 上下文：无
- 用户消息：
- 期望行为：
- 3 步：搜索索尼 + 搜索 Bose + 对比，输出 500-700 tokens
- 不应该：查详情、查评论、查品牌历史等（6+ 步）
- 不应该：输出 1500+ tokens 的长篇分析
- 判定标准：
- Pass：3-4 步，500-800 tokens（效率得分 ≥ 70）
- Acceptable：5 步，800-1200 tokens（效率得分 50-70）
- Fail：> 6 步或 > 1500 tokens（效率得分 < 50）
- 评分方式：自动
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
Q3-OE-03 · 复杂任务的效率（不过度优化）
- 难度：困难
- 理论最优：8-10 步，1500-2000 tokens
- 输入：
- 用户消息：
规划端午去京都 5 天的旅行，从上海出发，预算 1 万/人，想去清水寺、金阁寺、岚山、伏见稻荷 - 上下文：当前日期为 2026-04-07
- 用户消息：
- 期望行为：
- 这是复杂任务，不应过度追求效率牺牲质量
- 合理步骤数：8-12 步（查机票、排行程、推荐住宿等）
- 合理输出：1500-2500 tokens（完整方案）
- 不应该：为了效率跳过关键步骤（如不查地图直接排行程）
- 判定标准：
- Pass：8-12 步，1500-2500 tokens，质量不降低
- Fail：< 6 步或 < 1000 tokens（过度简化，质量下降）/ > 15 步或 > 3500 tokens（效率过低）
- 评分方式：LLM-judge（平衡效率和质量）
- Skill 配置：
Group A: skill_enabled: false/Group B: skill_enabled: true（对比 Skill 对效率的影响）
评测执行说明
总用例数
| 维度 | 代号 | 用例数 |
|---|---|---|
| 步骤数效率 | SE | 4 |
| Token 消耗 | TC | 3 |
| 冗余调用率 | RC | 3 |
| 输出冗余度 | OR | 4 |
| 整体效率 | OE | 3 |
| 合计 | 17 |
注：Q3 原计划 12 条，实际产出 17 条（增加了整体效率维度）。
难度分布
| 难度 | 数量 | 占比 |
|---|---|---|
| 简单 | 5 | 29% |
| 中等 | 9 | 53% |
| 困难 | 3 | 18% |
对话轮次分布
| 类型 | 数量 | 占比 |
|---|---|---|
| 单轮 | 12 | 71% |
| 多轮（2-3 轮） | 5 | 29% |
Q3 主要测单轮效率，多轮主要测增量输出。
评分方式分布
| 方式 | 数量 | 说明 |
|---|---|---|
| 自动 | 12 | 步骤数、token 数、工具调用次数都可自动统计 |
| 自动 + LLM-judge | 5 | 自动统计数值，LLM 判断是否有冗余内容 |
效率指标计算
步骤效率比
步骤效率比 = 理论最优步骤数 / 实际步骤数
示例：
- 理论最优：2 步
- 实际执行：3 步
- 效率比 = 2/3 = 0.67
越接近 1.0 越好
Token 效率比
Token 效率比 = 理论最优 tokens / 实际 tokens
示例：
- 理论最优：300 tokens
- 实际输出：500 tokens
- 效率比 = 300/500 = 0.6
越接近 1.0 越好
综合效率得分
综合效率 = (步骤效率比 × 0.5 + Token 效率比 × 0.3 + 无冗余调用 × 0.2) × 100
示例：
- 步骤效率比 = 0.67
- Token 效率比 = 0.6
- 无冗余调用 = 1.0（无重复）
- 综合效率 = (0.67×0.5 + 0.6×0.3 + 1.0×0.2) × 100 = 71.5
≥ 80: 优秀
60-80: 良好
< 60: 需要优化
效率 vs 质量的平衡
重要原则：效率不应以牺牲质量为代价。
| 场景 | 效率优先 | 质量优先 | 说明 |
|---|---|---|---|
| 简单查询 | ✓ | - | 「明天天气」应该 1 步完成 |
| 推荐任务 | 平衡 | - | 可以 2-3 步，但不应 10 步 |
| 复杂规划 | - | ✓ | 旅行规划可以 10 步，不应为效率跳步 |
| 安全相关 | - | ✓ | 医疗、法律咨询不应为效率简化 |
判定原则：
- 简单任务（理论 1-2 步）：效率比 < 0.5 为 Fail
- 中等任务（理论 3-5 步）：效率比 < 0.6 为 Fail
- 复杂任务（理论 8+ 步）：效率比 < 0.7 为 Acceptable（不追求极致效率）
按任务类型的效率基准
| 任务类型 | 理论步骤数 | 理论 tokens | 代表 case |
|---|---|---|---|
| 简单查询 | 1 | 150 | 查天气、查价格 |
| 搜索+提取 | 2 | 250 | 搜笔记、读内容 |
| 对比推荐 | 3-4 | 500-700 | 对比 2 款产品 |
| 复杂规划 | 8-12 | 1500-2500 | 旅行规划全流程 |
Group A vs Group B 效率对比
Q3 是唯一一个需要关注「Skill 对效率的影响」的维度：
测试方法：
- 每个 case 在 Group A（无 skill）和 Group B（有 skill）下都跑
- 对比两组的步骤数和 token 数
预期结果：
- 理想情况：Group B 效率 ≥ Group A（skill 优化了路径）
- 可接受：Group B 效率略低于 Group A（skill 增加了验证步骤，但质量提升）
- 问题：Group B 效率显著低于 Group A（skill 设计有问题）
示例分析：
Case: 查询机票
Group A（无 skill）:
- 步骤数: 1（直接调用 search_flights）
- Tokens: 200（简单列出航班）
- 效率比: 1.0
Group B（有 flight-selection skill）:
- 步骤数: 3（±1 天搜索 + 对比）
- Tokens: 600（包含对比说明）
- 效率比: 0.33
分析：
- 步骤数增加了 3 倍，但这是 skill 的核心价值（帮用户做对比）
- 输出 tokens 增加，但信息价值更高
- 判定：Acceptable（质量提升 > 效率降低）
后续迭代方向
- 补充更多复杂任务的效率测试（区分「必要的复杂」vs「冗余的复杂」）
- 补充 Skill 效率对比测试（量化 skill 对效率的影响）
- 补充并行执行的效率测试（如果框架支持并行工具调用）
- 补充响应时间测试（除了步骤数和 token，实际耗时也是效率指标）
- 从生产环境监控中提取效率异常的 case（如某个任务平均耗时过长）
- 建立不同任务类型的效率基准数据库（P50、P90、P99 分位值）