Qwen-Agent DeepPlanning 基准评测实践跨领域 Agent 规划能力的一体化评测、结果解读与复现指南【免费下载链接】Qwen-AgentAgent framework and applications built upon Qwen3.0, featuring Function Calling, MCP, Code Interpreter, RAG, Chrome extension, etc.项目地址: https://gitcode.com/GitHub_Trending/qw/Qwen-AgentDeepPlanning Benchmark 是 Qwen-Agent 仓库中专门用于量化评估 AI Agent 多领域规划能力的综合评测基准覆盖旅行行程规划与电商购物规划两大典型场景。本指南以 benchmark/deepplanning/README.md 为骨架结合 run_all.sh、aggregate_results.py、models_config.json 等源码与配置文件完整讲解环境搭建、数据准备、模型配置、统一评测执行以及 match_rate、composite_score、avg_acc 等核心指标的生成逻辑与解读方法帮助你在自己的模型上复现论文中的实验流程并横向对比不同 Agent 的规划能力。一、DeepPlanning Benchmark 概览DeepPlanning 是一个面向 Agent 规划能力的多领域综合评测基准评估 Agent 在复杂规划任务上的表现其两个核心领域分别为旅行规划Travel Planning评估 Agent 完成旅行行程规划任务的能力涉及航班、酒店、餐厅、景点、火车、道路路线等多类信息查询与方案编排同时提供中英文双语言评测集。购物规划Shopping Planning评估 Agent 完成电商购物任务的能力Agent 需要根据用户需求搜索商品、按品牌/颜色/尺寸/价格区间筛选、排序、加购、应用优惠券等并提供 13 三个难度等级。评测的执行方式灵活分为两种统一运行Unified Run推荐通过统一编排脚本run_all.sh一次跑完两个领域这也是官方文档明确推荐的工作流用于复现论文中报告的实验结果。本指南以该统一流程为主线展开。独立运行Independent Run每个领域也可脱离统一编排独立运行领域级细节分别见 shoppingplanning/README.md 与 travelplanning/README.md。从仓库结构看评测实现完全开源在 benchmark/deepplanning 目录下shoppingplanning/与travelplanning/各自包含agent/Agent 实现、tools/工具集与 JSON Schema、data/评测查询元数据、evaluation/评测管线根目录则提供统一的models_config.json、env.example、requirements.txt、run_all.sh与 aggregate_results.py。二、快速开始从零搭建统一评测环境步骤 1安装依赖建议使用 Python 3.10 创建独立 conda 环境并从 benchmark 根目录安装统一依赖# Create and activate conda environment conda create -n deepplanning python3.10 -y conda activate deepplanning pip install -r requirements.txt其中 requirements.txt 同时服务于两个领域关键依赖包括依赖版本要求用途qwen-agent0.0.10旅行领域核心 Agent 包openai1.0.0OpenAI SDK同时兼容 OpenAI、DashScope 及各类兼容 APIdashscope1.11.0阿里云 DashScope API 客户端rank-bm250.2.2购物领域商品搜索所用的 BM25 算法pandas/numpy1.5.0 / 1.24.0CSV 数据库加载与数值运算json5/jsonlines/jsonschema各 0.9.0 / 3.0.0 / 4.0.0旅行领域 JSON5、JSON Lines 解析与 Schema 校验python-dotenv1.0.0从.env加载环境变量pydantic/tiktoken2.3.0 / 0.5.0数据校验与 token 计数eval-type-backport/pillow/tabulate—类型求值兼容、图像处理按需、表格美化输出步骤 2下载数据文件从 HuggingFace 的 Qwen/DeepPlanning 数据集下载评测数据库并按以下路径放置到项目中购物规划Shopping Planningshoppingplanning/database_zip/database_level1.tar.gz— Level 1 购物数据库shoppingplanning/database_zip/database_level2.tar.gz— Level 2 购物数据库shoppingplanning/database_zip/database_level3.tar.gz— Level 3 购物数据库旅行规划Travel Planningtravelplanning/database/database_zh.zip— 中文数据库travelplanning/database/database_en.zip— 英文数据库放置规则为压缩包放入shoppingplanning/database_zip/与travelplanning/database/对应目录。步骤 3解压数据库文件下载完成后解压全部压缩包# Extract shopping databases cd shoppingplanning/database_zip tar -xzf database_level1.tar.gz -C .. tar -xzf database_level2.tar.gz -C .. tar -xzf database_level3.tar.gz -C .. cd ../.. # Extract travel databases cd travelplanning/database unzip database_zh.zip # Chinese database (flights, hotels, restaurants, attractions) unzip database_en.zip # English database cd ../..解压后购物领域将得到database_level1/、database_level2/、database_level3/三份数据库目录旅行领域将得到中英文两份数据库。步骤 4配置模型编辑 benchmark 根目录下的 models_config.json按需添加要评测的模型{ models: { qwen-plus: { model_name: qwen-plus, model_type: openai, base_url: https://dashscope.aliyuncs.com/compatible-mode/v1, api_key_env: DASHSCOPE_API_KEY, temperature: 0.0 }, gpt-4o-2024-11-20: { model_name: gpt-4o-2024-11-20, model_type: openai, base_url: https://api.openai.com/v1/models, api_key_env: OPENAI_API_KEY, temperature: 0.0 } } }关于 qwen-plus 的重要说明qwen-plus配置是必需的因为旅行领域的转换阶段evaluation/convert_report.py默认使用它来解析并格式化 Agent 生成的旅行计划如果希望使用其他模型做转换可以修改 convert_report.py 中的conversion_model变量。支持的模型类型openai类型适用于 OpenAI 及所有兼容模型GPT-4、Qwen、DeepSeek 等。仓库中实际自带的 models_config.json 还预置了qwen3-max与gpt-5-2025-08-07-high两个条目。其中gpt-5-2025-08-07-high展示了两个值得注意的扩展用法配置键名与model_name可以不同键名用于脚本内引用model_name为实际请求的模型名并且可以通过extra_body传入额外请求参数此处为reasoning_effort: high。所有预置条目的temperature均为 0.0以保证评测结果的可复现性。从load_model_config见 travelplanning/agent/call_llm.py 与 shoppingplanning/agent/call_llm.py的实现可以看出脚本按配置键名加载base_url、api_key_env对应环境变量名与temperature因此新增模型只需在models下追加同构条目。步骤 5设置 API Keys在 benchmark 根目录创建.env文件以 env.example 为模板cp .env.example .env # Edit .env and add your API keysenv.example 内容如下# API Keys for different model providers # Copy this file to .env and fill in your API keys # For Qwen models (via DashScope) DASHSCOPE_API_KEYyour_dashscope_api_key_here # For OpenAI models OPENAI_API_KEYyour_openai_api_key_here也可以不创建.env直接以环境变量形式导出DASHSCOPE_API_KEY、OPENAI_API_KEY。统一编排脚本 run_all.sh 在启动时会自动检测并source根目录下的.env文件见脚本中if [ -f $BASE_DIR/.env ]分支。步骤 6运行统一基准评测编辑 run_all.sh 顶部的配置区然后执行bash run_all.sh统一评测会依次完成以下工作对每个模型在指定领域上顺序运行评测旅行领域同时运行中英文两个语言版本购物领域按难度等级 1 → 2 → 3 依次运行在各领域结果目录中生成领域级统计跨领域聚合结果并计算总体得分将聚合结果保存到aggregated_results/{model_name}_aggregated.json。三、run_all.sh 统一编排器配置项与执行机制环境变量配置一览run_all.sh顶部集中了全部运行配置README 给出的默认值如下与仓库脚本一致# Configuration in run_all.sh DOMAINStravel shopping # Domains to run BENCHMARK_MODELqwen-plus # Default model for all domains # Shopping domain configuration SHOPPING_MODEL${BENCHMARK_MODEL} # Model(s) for shopping SHOPPING_LEVELS1 2 3 # Levels to run SHOPPING_WORKERS50 # Parallel workers SHOPPING_MAX_LLM_CALLS400 # Max LLM calls per sample # Travel domain configuration TRAVEL_MODEL${BENCHMARK_MODEL} # Model(s) for travel TRAVEL_LANGUAGE # Language (zh/en/empty for both) TRAVEL_WORKERS50 # Parallel workers TRAVEL_MAX_LLM_CALLS400 # Max LLM calls per sample TRAVEL_START_FROMinference # Start point: inference, conversion, evaluation TRAVEL_OUTPUT_DIR # Output directory (optional) TRAVEL_VERBOSEfalse # Verbose output TRAVEL_DEBUGfalse # Debug mode各配置项的语义如下配置项默认值说明DOMAINStravel shopping要运行的领域列表空格分隔可只保留一个领域BENCHMARK_MODELqwen-plus全局默认模型名须在 models_config.json 中存在SHOPPING_MODEL/TRAVEL_MODEL继承BENCHMARK_MODEL领域级模型覆盖支持空格分隔的多模型SHOPPING_LEVELS1 2 3购物评测难度等级SHOPPING_WORKERS/TRAVEL_WORKERS50 / 50并行 worker 数SHOPPING_MAX_LLM_CALLS/TRAVEL_MAX_LLM_CALLS400 / 400每个样本的最大 LLM 调用次数TRAVEL_LANGUAGE空zh / en / 空两者都跑TRAVEL_START_FROMinference旅行领域起点inference、conversion 或 evaluationTRAVEL_OUTPUT_DIR空旅行结果自定义输出目录可选执行机制与调用链从 run_all.sh 源码看编排器遵循如下逻辑启动校验检查models_config.json是否存在存在则加载.env环境变量否则报错退出。模型去重合并从SHOPPING_MODEL与TRAVEL_MODEL两个列表合并出唯一的MODELS_LIST避免重复评测。领域循环外层按模型、内层按领域逐个cd到对应领域目录并导出领域级环境变量BENCHMARK_MODEL、BENCHMARK_WORKERS、BENCHMARK_MAX_LLM_CALLS、BENCHMARK_LEVELS、BENCHMARK_LANGUAGE、BENCHMARK_START_FROM等随后调用该领域的bash run.sh。逐模型聚合每个模型跑完所有领域后调用python aggregate_results.py --model_name ${MODEL}若设置了TRAVEL_OUTPUT_DIR则追加--travel-output-dir参数聚合跨领域结果。模型间冷却多模型串行评测时模型之间自动sleep 60秒再启动下一个避免 API 限流。失败处理任一领域脚本返回非零退出码即中止整个流程聚合步骤失败仅告警不阻断。aggregate_results.py跨领域聚合的原理aggregate_results.py 是聚合逻辑的实现其核心行为可以从源码确认购物领域读取shoppingplanning/result_report/{model_name}_statistics.json提取total中的total_cases、successful_cases、successful_rate、match_rate、weighted_average_case_score、valid、levels_completed字段旅行领域分别读取{model}_zh与{model}_en两个语言目录下的evaluation/evaluation_summary.json提取composite_score、case_acc、commonsense_score、personalized_score等指标再对两种语言取算术平均作为旅行领域的整体得分总体得分跨领域汇总total_cases、successful_cases、successful_rate各领域成功率的均值并当两个领域都有效时计算跨领域核心指标avg_acc (shopping 的 weighted_average_case_score travel 的 case_acc) / 2输出将聚合结果写入benchmark/deepplanning/aggregated_results/{model_name}_aggregated.json目录不存在时自动创建并在控制台打印分领域明细与总体摘要。这也解释了聚合 JSON 中travel.composite_score会被映射到overall.travel_composite_score、travel.case_acc映射到overall.travel_case_acc的原因——源码在加载旅行统计时即以match_rate/weighted_average_case_score作为内部通用字段承载旅行领域的composite_score/case_acc。四、结果解读结果文件位置与指标体系结果文件位置旅行领域评测结果benchmark/deepplanning/travelplanning/results/{model}_{language}/evaluation/evaluation_summary.json转换后的计划benchmark/deepplanning/travelplanning/results/{model}_{language}/converted_plans/轨迹benchmark/deepplanning/travelplanning/results/{model}_{language}/trajectories/购物领域分等级结果benchmark/deepplanning/shoppingplanning/result_report/summary_report_{model}_{level}_{timestamp}.json跨等级总体统计benchmark/deepplanning/shoppingplanning/result_report/{model}_statistics.json推理输出benchmark/deepplanning/shoppingplanning/database_infered/跨领域聚合结果跨领域聚合benchmark/deepplanning/aggregated_results/{model}_aggregated.json购物与旅行领域的细粒度指标说明分别见 Shopping Results Documentationmatch_rate、weighted_average_case_score 与各等级统计与 Travel Results Documentationcomposite_score、case_acc、commonsense_score、personalized_score。聚合结果格式运行完毕后查看聚合结果cat benchmark/deepplanning/aggregated_results/{MODEL}_aggregated.json示例输出{ model_name: qwen-plus, aggregation_time: 2026-01-05T15:30:00.000000, domains: { shopping: { total_cases: 120, successful_cases: 17, successful_rate: 0.1417, match_rate: 0.6209, weighted_average_case_score: 0.1417, valid: true, levels_completed: [1, 2, 3] }, travel: { total_cases: 240, successful_cases: 238, successful_rate: 0.9917, composite_score: 0.2813, case_acc: 0.0, commonsense_score: 0.4292, personalized_score: 0.1333, valid: true, languages_completed: [zh, en], language_details: { zh: { composite_score: 0.2813, case_acc: 0.0, commonsense_score: 0.4292, personalized_score: 0.1333 }, en: { composite_score: 0.2850, case_acc: 0.0, commonsense_score: 0.4300, personalized_score: 0.1350 } } } }, overall: { total_cases: 360, successful_cases: 255, successful_rate: 0.5667, valid: true, domains_completed: [shopping, travel], num_domains: 2, shopping_match_rate: 0.6209, shopping_weighted_average_case_score: 0.1417, travel_composite_score: 0.2813, travel_case_acc: 0.0, travel_commonsense_score: 0.4292, travel_personalized_score: 0.1333, avg_acc: 0.0708 } }核心指标解析购物领域match_rate⭐期望商品被正确匹配的百分比是论文主报告指标weighted_average_case_score⭐按各等级样本数加权后的平均用例完成得分是论文主报告指标。旅行领域composite_score⭐常识分与个性化分的加权组合是论文主报告指标case_acc⭐通过全部约束的用例占比是论文主报告指标commonsense_score常识约束满足度得分personalized_score个性化需求满足度得分。跨领域avg_acc⭐购物weighted_average_case_score与旅行case_acc的平均值是主要的跨领域综合指标其计算式已由 aggregate_results.py 的源码确认。示例中购物 120 例、旅行 240 例zh 120 en 120、合计 360 例的结构正是统一评测购物三等级 旅行双语配置下的典型输出形态。五、购物领域深入评测管线与结果指标两级管线推理与评估购物领域评测分两个阶段详见 shoppingplanning/README.md阶段一推理Agent 规划从data/level_{level}_query_meta.json如 level_1_query_meta.json加载购物任务调用 LLM Agent 生成购物方案Agent 通过工具查询数据库搜索商品、筛选、加购等将 Agent 轨迹与执行日志保存在database/case_{id}/目录下其中messages.json保存执行轨迹、cart.json保存最终购物车、validation_cases.json保存标注真值。阶段二评估将 Agent 生成的购物车与真值对比计算准确率得分商品匹配、优惠券匹配校验用例完成情况并生成评估报告输出到result_report/下每个用例对应一份case_*_report.json并汇总为summary_report.json。购物 Agent 与工具集从源码看购物 Agent 实现在 shopping_agent.py 中的ShoppingFnAgent类它将 shopping_tool_schema.json 加载为 OpenAI Chat Completions 格式的工具定义动态加载BaseShoppingTool子类工具实例然后迭代式地调用 LLM 并执行 tool_calls直至给出最终答案。工具集覆盖了完整电商链路包括search_products_tool基于 BM25 的商品搜索、filter_by_brand_tool/filter_by_color_tool/filter_by_size_tool/filter_by_range_tool品牌/颜色/尺寸/价格区间筛选、sort_product_tool排序、get_product_details_tool商品详情、add_product_to_cart/delete_product_from_cart/get_cart_info购物车操作、add_coupon_to_cart/delete_coupon_from_cart/filter_by_applicable_coupons_tool优惠券相关、get_user_info用户信息、calculate_transport_time_tool配送时间计算等均位于 tools 目录 下。跨等级统计与有效模型判定运行完某个模型的所有等级后脚本自动通过evaluation/score_statistics.py计算跨等级总体统计并保存到result_report/{model}_statistics.json。其中关键字段的语义为successful_rate获得满分全部商品与优惠券均匹配的用例占比match_rate⭐正确匹配的期望商品占比论文主报告指标weighted_average_case_score⭐按各等级样本数加权的平均用例得分论文主报告指标levels_completed纳入统计的等级列表valid模型是否有效——判定条件为所有等级的incomplete_rate未完成率不超过 10%。值得注意的是无论valid与否评估报告始终都会保存以便在模型因提前终止或报错导致高未完成率时仍可进行调试与分析valid标志仅用于标识结果是否适合作为可靠基准。六、旅行领域深入三阶段管线、缓存续跑与错误分析三阶段管线旅行领域评测由 travelplanning/run.py 集成为一条流水线依次执行三阶段详见 travelplanning/README.md阶段一推理Agent 规划从data/travelplanning_query_{lang}.json如 travelplanning_query_zh.json加载任务调用 LLM Agent 生成旅行方案Agent 通过工具查询数据库航班、酒店、餐厅、景点等其工具定义见 tool_schema.json 及中英文本地化版本 tool_schema_zh.json、tool_schema_en.json保存轨迹与可读报告results/{model}_{lang}/trajectories/id_0_trajectory.json与results/{model}_{lang}/reports/id_0_report.txt。阶段二转换方案解析使用 LLM默认qwen-plus可配置将 Agent 输出的Markdown 格式旅行计划解析并转换为标准化 JSON存于converted_plans/id_0_converted.json为什么需要转换Agent 生成的是人类可读的 Markdown 计划而评估代码需要结构化 JSON 才能自动计算约束满足度与各类指标。该转换逻辑实现在 convert_report.py其默认转换模型通过conversion_model变量指定。阶段三评估检查交付率是否生成了方案评估 8 个维度的常识得分实现见 constraints_commonsense.py校验个性化约束实现见 constraints_hard.py计算最终得分输出evaluation/evaluation_summary.json与每个任务的id_*_score.json。智能缓存与断点续跑当START_FROMinference时run.sh会自动执行增量检测逻辑扫描reports/文件夹找出缺失的报告文件如id_0_report.txt扫描converted_plans/文件夹找出缺失的转换计划文件如id_0_converted.json从总共 120 个任务ID 0119中识别缺失的任务 ID自动决定起点报告齐全但转换计划缺失 → 从conversion阶段续跑报告缺失 → 从inference阶段重跑两者皆齐 → 直接跳过该模型。这使得长时间运行的评测可以被安全地中断并随时恢复不会丢失已完成的进度。此外旅行领域run.sh支持对多模型并发执行评测每个模型进程写独立日志并汇总成功/失败状态。错误分析旅行领域的评估摘要还会输出常见失败模式的错误统计例如error_statistics: [ { rank: 1, error_type: [Hard] train_seat_status, count: 15, affected_samples: [0, 12, 25, ...] } ]它按影响样本数对错误类型如[Hard] train_seat_status这类硬约束错误排序便于快速定位 Agent 在哪些约束维度上系统性失败。七、购物领域独立运行与并发隔离除统一编排外购物领域支持独立运行推荐用环境变量方式SHOPPING_AGENT_MODELqwen-plus \ SHOPPING_LEVELS1 2 3 \ SHOPPING_WORKERS50 \ SHOPPING_MAX_LLM_CALLS400 \ bash run.sh可用环境变量SHOPPING_AGENT_MODELmodels_config.json 中的模型名多个模型用空格分隔SHOPPING_LEVELS要运行的等级空格分隔如1 2 3SHOPPING_WORKERS并行 worker 数SHOPPING_MAX_LLM_CALLS每个样本的最大 LLM 调用次数。也可以直接修改 run.sh 中:-后的默认值实现永久变更。从脚本源码看购物领域的执行流程为为每次运行创建带唯一时间戳的隔离数据库副本如database_run_qwen-plus_level1_20250105143022_12345/从而支持多个并发运行互不干扰对指定模型在所有等级上依次执行推理等级 1 → 2 → 3推理完成后将结果目录移动到database_infered/对每个等级运行evaluation/evaluation_pipeline.py评估管线生成result_report/下的报告即使模型无效也始终保存报告通过evaluation/score_statistics.py计算该模型跨等级总体统计保存到result_report/{model}_statistics.json。由于每个运行使用独立的数据库目录你可以安全地并行运行多组评测例如同时测试多个模型等级之间默认间隔 10 秒、模型之间默认间隔 60 秒以规避 API 限流。八、注意事项与使用建议qwen-plus 是必需配置旅行领域转换阶段默认依赖它若要替换需同步修改convert_report.py中的conversion_model变量数据文件需要手动下载仓库不携带评测数据库需从 HuggingFace Qwen/DeepPlanning 数据集下载并解压到指定目录温度设置为 0.0为保证评测可复现建议所有模型条目沿用temperature: 0.0valid不等于无效报告评估报告总是生成valid仅指示结果是否适合作为可靠基准购物领域判定阈值为未完成率 ≤ 10%旅行领域可断点续跑善用START_FROM与自动缓存检测避免中断后重复消耗 API 额度跨领域对比看avg_acc该指标统一了购物与旅行两个领域的得分口径是衡量模型整体规划能力的主指标细粒度分析则应分别查看购物match_rate/weighted_average_case_score与旅行composite_score/case_acc及其语言明细。通过统一编排器你只需配置好 models_config.json、.env与 run_all.sh 三处即可在 Qwen、GPT-4o 等任意 OpenAI 兼容模型上完整复现 DeepPlanning 的跨领域评测流程并借助aggregated_results/下的聚合 JSON 进行模型间横向对比。【免费下载链接】Qwen-AgentAgent framework and applications built upon Qwen3.0, featuring Function Calling, MCP, Code Interpreter, RAG, Chrome extension, etc.项目地址: https://gitcode.com/GitHub_Trending/qw/Qwen-Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Qwen-Agent DeepPlanning 基准评测实践：跨领域 Agent 规划能力的一体化评测、结果解读与复现指南
Qwen-Agent DeepPlanning 基准评测实践跨领域 Agent 规划能力的一体化评测、结果解读与复现指南【免费下载链接】Qwen-AgentAgent framework and applications built upon Qwen3.0, featuring Function Calling, MCP, Code Interpreter, RAG, Chrome extension, etc.项目地址: https://gitcode.com/GitHub_Trending/qw/Qwen-AgentDeepPlanning Benchmark 是 Qwen-Agent 仓库中专门用于量化评估 AI Agent 多领域规划能力的综合评测基准覆盖旅行行程规划与电商购物规划两大典型场景。本指南以 benchmark/deepplanning/README.md 为骨架结合 run_all.sh、aggregate_results.py、models_config.json 等源码与配置文件完整讲解环境搭建、数据准备、模型配置、统一评测执行以及 match_rate、composite_score、avg_acc 等核心指标的生成逻辑与解读方法帮助你在自己的模型上复现论文中的实验流程并横向对比不同 Agent 的规划能力。一、DeepPlanning Benchmark 概览DeepPlanning 是一个面向 Agent 规划能力的多领域综合评测基准评估 Agent 在复杂规划任务上的表现其两个核心领域分别为旅行规划Travel Planning评估 Agent 完成旅行行程规划任务的能力涉及航班、酒店、餐厅、景点、火车、道路路线等多类信息查询与方案编排同时提供中英文双语言评测集。购物规划Shopping Planning评估 Agent 完成电商购物任务的能力Agent 需要根据用户需求搜索商品、按品牌/颜色/尺寸/价格区间筛选、排序、加购、应用优惠券等并提供 13 三个难度等级。评测的执行方式灵活分为两种统一运行Unified Run推荐通过统一编排脚本run_all.sh一次跑完两个领域这也是官方文档明确推荐的工作流用于复现论文中报告的实验结果。本指南以该统一流程为主线展开。独立运行Independent Run每个领域也可脱离统一编排独立运行领域级细节分别见 shoppingplanning/README.md 与 travelplanning/README.md。从仓库结构看评测实现完全开源在 benchmark/deepplanning 目录下shoppingplanning/与travelplanning/各自包含agent/Agent 实现、tools/工具集与 JSON Schema、data/评测查询元数据、evaluation/评测管线根目录则提供统一的models_config.json、env.example、requirements.txt、run_all.sh与 aggregate_results.py。二、快速开始从零搭建统一评测环境步骤 1安装依赖建议使用 Python 3.10 创建独立 conda 环境并从 benchmark 根目录安装统一依赖# Create and activate conda environment conda create -n deepplanning python3.10 -y conda activate deepplanning pip install -r requirements.txt其中 requirements.txt 同时服务于两个领域关键依赖包括依赖版本要求用途qwen-agent0.0.10旅行领域核心 Agent 包openai1.0.0OpenAI SDK同时兼容 OpenAI、DashScope 及各类兼容 APIdashscope1.11.0阿里云 DashScope API 客户端rank-bm250.2.2购物领域商品搜索所用的 BM25 算法pandas/numpy1.5.0 / 1.24.0CSV 数据库加载与数值运算json5/jsonlines/jsonschema各 0.9.0 / 3.0.0 / 4.0.0旅行领域 JSON5、JSON Lines 解析与 Schema 校验python-dotenv1.0.0从.env加载环境变量pydantic/tiktoken2.3.0 / 0.5.0数据校验与 token 计数eval-type-backport/pillow/tabulate—类型求值兼容、图像处理按需、表格美化输出步骤 2下载数据文件从 HuggingFace 的 Qwen/DeepPlanning 数据集下载评测数据库并按以下路径放置到项目中购物规划Shopping Planningshoppingplanning/database_zip/database_level1.tar.gz— Level 1 购物数据库shoppingplanning/database_zip/database_level2.tar.gz— Level 2 购物数据库shoppingplanning/database_zip/database_level3.tar.gz— Level 3 购物数据库旅行规划Travel Planningtravelplanning/database/database_zh.zip— 中文数据库travelplanning/database/database_en.zip— 英文数据库放置规则为压缩包放入shoppingplanning/database_zip/与travelplanning/database/对应目录。步骤 3解压数据库文件下载完成后解压全部压缩包# Extract shopping databases cd shoppingplanning/database_zip tar -xzf database_level1.tar.gz -C .. tar -xzf database_level2.tar.gz -C .. tar -xzf database_level3.tar.gz -C .. cd ../.. # Extract travel databases cd travelplanning/database unzip database_zh.zip # Chinese database (flights, hotels, restaurants, attractions) unzip database_en.zip # English database cd ../..解压后购物领域将得到database_level1/、database_level2/、database_level3/三份数据库目录旅行领域将得到中英文两份数据库。步骤 4配置模型编辑 benchmark 根目录下的 models_config.json按需添加要评测的模型{ models: { qwen-plus: { model_name: qwen-plus, model_type: openai, base_url: https://dashscope.aliyuncs.com/compatible-mode/v1, api_key_env: DASHSCOPE_API_KEY, temperature: 0.0 }, gpt-4o-2024-11-20: { model_name: gpt-4o-2024-11-20, model_type: openai, base_url: https://api.openai.com/v1/models, api_key_env: OPENAI_API_KEY, temperature: 0.0 } } }关于 qwen-plus 的重要说明qwen-plus配置是必需的因为旅行领域的转换阶段evaluation/convert_report.py默认使用它来解析并格式化 Agent 生成的旅行计划如果希望使用其他模型做转换可以修改 convert_report.py 中的conversion_model变量。支持的模型类型openai类型适用于 OpenAI 及所有兼容模型GPT-4、Qwen、DeepSeek 等。仓库中实际自带的 models_config.json 还预置了qwen3-max与gpt-5-2025-08-07-high两个条目。其中gpt-5-2025-08-07-high展示了两个值得注意的扩展用法配置键名与model_name可以不同键名用于脚本内引用model_name为实际请求的模型名并且可以通过extra_body传入额外请求参数此处为reasoning_effort: high。所有预置条目的temperature均为 0.0以保证评测结果的可复现性。从load_model_config见 travelplanning/agent/call_llm.py 与 shoppingplanning/agent/call_llm.py的实现可以看出脚本按配置键名加载base_url、api_key_env对应环境变量名与temperature因此新增模型只需在models下追加同构条目。步骤 5设置 API Keys在 benchmark 根目录创建.env文件以 env.example 为模板cp .env.example .env # Edit .env and add your API keysenv.example 内容如下# API Keys for different model providers # Copy this file to .env and fill in your API keys # For Qwen models (via DashScope) DASHSCOPE_API_KEYyour_dashscope_api_key_here # For OpenAI models OPENAI_API_KEYyour_openai_api_key_here也可以不创建.env直接以环境变量形式导出DASHSCOPE_API_KEY、OPENAI_API_KEY。统一编排脚本 run_all.sh 在启动时会自动检测并source根目录下的.env文件见脚本中if [ -f $BASE_DIR/.env ]分支。步骤 6运行统一基准评测编辑 run_all.sh 顶部的配置区然后执行bash run_all.sh统一评测会依次完成以下工作对每个模型在指定领域上顺序运行评测旅行领域同时运行中英文两个语言版本购物领域按难度等级 1 → 2 → 3 依次运行在各领域结果目录中生成领域级统计跨领域聚合结果并计算总体得分将聚合结果保存到aggregated_results/{model_name}_aggregated.json。三、run_all.sh 统一编排器配置项与执行机制环境变量配置一览run_all.sh顶部集中了全部运行配置README 给出的默认值如下与仓库脚本一致# Configuration in run_all.sh DOMAINStravel shopping # Domains to run BENCHMARK_MODELqwen-plus # Default model for all domains # Shopping domain configuration SHOPPING_MODEL${BENCHMARK_MODEL} # Model(s) for shopping SHOPPING_LEVELS1 2 3 # Levels to run SHOPPING_WORKERS50 # Parallel workers SHOPPING_MAX_LLM_CALLS400 # Max LLM calls per sample # Travel domain configuration TRAVEL_MODEL${BENCHMARK_MODEL} # Model(s) for travel TRAVEL_LANGUAGE # Language (zh/en/empty for both) TRAVEL_WORKERS50 # Parallel workers TRAVEL_MAX_LLM_CALLS400 # Max LLM calls per sample TRAVEL_START_FROMinference # Start point: inference, conversion, evaluation TRAVEL_OUTPUT_DIR # Output directory (optional) TRAVEL_VERBOSEfalse # Verbose output TRAVEL_DEBUGfalse # Debug mode各配置项的语义如下配置项默认值说明DOMAINStravel shopping要运行的领域列表空格分隔可只保留一个领域BENCHMARK_MODELqwen-plus全局默认模型名须在 models_config.json 中存在SHOPPING_MODEL/TRAVEL_MODEL继承BENCHMARK_MODEL领域级模型覆盖支持空格分隔的多模型SHOPPING_LEVELS1 2 3购物评测难度等级SHOPPING_WORKERS/TRAVEL_WORKERS50 / 50并行 worker 数SHOPPING_MAX_LLM_CALLS/TRAVEL_MAX_LLM_CALLS400 / 400每个样本的最大 LLM 调用次数TRAVEL_LANGUAGE空zh / en / 空两者都跑TRAVEL_START_FROMinference旅行领域起点inference、conversion 或 evaluationTRAVEL_OUTPUT_DIR空旅行结果自定义输出目录可选执行机制与调用链从 run_all.sh 源码看编排器遵循如下逻辑启动校验检查models_config.json是否存在存在则加载.env环境变量否则报错退出。模型去重合并从SHOPPING_MODEL与TRAVEL_MODEL两个列表合并出唯一的MODELS_LIST避免重复评测。领域循环外层按模型、内层按领域逐个cd到对应领域目录并导出领域级环境变量BENCHMARK_MODEL、BENCHMARK_WORKERS、BENCHMARK_MAX_LLM_CALLS、BENCHMARK_LEVELS、BENCHMARK_LANGUAGE、BENCHMARK_START_FROM等随后调用该领域的bash run.sh。逐模型聚合每个模型跑完所有领域后调用python aggregate_results.py --model_name ${MODEL}若设置了TRAVEL_OUTPUT_DIR则追加--travel-output-dir参数聚合跨领域结果。模型间冷却多模型串行评测时模型之间自动sleep 60秒再启动下一个避免 API 限流。失败处理任一领域脚本返回非零退出码即中止整个流程聚合步骤失败仅告警不阻断。aggregate_results.py跨领域聚合的原理aggregate_results.py 是聚合逻辑的实现其核心行为可以从源码确认购物领域读取shoppingplanning/result_report/{model_name}_statistics.json提取total中的total_cases、successful_cases、successful_rate、match_rate、weighted_average_case_score、valid、levels_completed字段旅行领域分别读取{model}_zh与{model}_en两个语言目录下的evaluation/evaluation_summary.json提取composite_score、case_acc、commonsense_score、personalized_score等指标再对两种语言取算术平均作为旅行领域的整体得分总体得分跨领域汇总total_cases、successful_cases、successful_rate各领域成功率的均值并当两个领域都有效时计算跨领域核心指标avg_acc (shopping 的 weighted_average_case_score travel 的 case_acc) / 2输出将聚合结果写入benchmark/deepplanning/aggregated_results/{model_name}_aggregated.json目录不存在时自动创建并在控制台打印分领域明细与总体摘要。这也解释了聚合 JSON 中travel.composite_score会被映射到overall.travel_composite_score、travel.case_acc映射到overall.travel_case_acc的原因——源码在加载旅行统计时即以match_rate/weighted_average_case_score作为内部通用字段承载旅行领域的composite_score/case_acc。四、结果解读结果文件位置与指标体系结果文件位置旅行领域评测结果benchmark/deepplanning/travelplanning/results/{model}_{language}/evaluation/evaluation_summary.json转换后的计划benchmark/deepplanning/travelplanning/results/{model}_{language}/converted_plans/轨迹benchmark/deepplanning/travelplanning/results/{model}_{language}/trajectories/购物领域分等级结果benchmark/deepplanning/shoppingplanning/result_report/summary_report_{model}_{level}_{timestamp}.json跨等级总体统计benchmark/deepplanning/shoppingplanning/result_report/{model}_statistics.json推理输出benchmark/deepplanning/shoppingplanning/database_infered/跨领域聚合结果跨领域聚合benchmark/deepplanning/aggregated_results/{model}_aggregated.json购物与旅行领域的细粒度指标说明分别见 Shopping Results Documentationmatch_rate、weighted_average_case_score 与各等级统计与 Travel Results Documentationcomposite_score、case_acc、commonsense_score、personalized_score。聚合结果格式运行完毕后查看聚合结果cat benchmark/deepplanning/aggregated_results/{MODEL}_aggregated.json示例输出{ model_name: qwen-plus, aggregation_time: 2026-01-05T15:30:00.000000, domains: { shopping: { total_cases: 120, successful_cases: 17, successful_rate: 0.1417, match_rate: 0.6209, weighted_average_case_score: 0.1417, valid: true, levels_completed: [1, 2, 3] }, travel: { total_cases: 240, successful_cases: 238, successful_rate: 0.9917, composite_score: 0.2813, case_acc: 0.0, commonsense_score: 0.4292, personalized_score: 0.1333, valid: true, languages_completed: [zh, en], language_details: { zh: { composite_score: 0.2813, case_acc: 0.0, commonsense_score: 0.4292, personalized_score: 0.1333 }, en: { composite_score: 0.2850, case_acc: 0.0, commonsense_score: 0.4300, personalized_score: 0.1350 } } } }, overall: { total_cases: 360, successful_cases: 255, successful_rate: 0.5667, valid: true, domains_completed: [shopping, travel], num_domains: 2, shopping_match_rate: 0.6209, shopping_weighted_average_case_score: 0.1417, travel_composite_score: 0.2813, travel_case_acc: 0.0, travel_commonsense_score: 0.4292, travel_personalized_score: 0.1333, avg_acc: 0.0708 } }核心指标解析购物领域match_rate⭐期望商品被正确匹配的百分比是论文主报告指标weighted_average_case_score⭐按各等级样本数加权后的平均用例完成得分是论文主报告指标。旅行领域composite_score⭐常识分与个性化分的加权组合是论文主报告指标case_acc⭐通过全部约束的用例占比是论文主报告指标commonsense_score常识约束满足度得分personalized_score个性化需求满足度得分。跨领域avg_acc⭐购物weighted_average_case_score与旅行case_acc的平均值是主要的跨领域综合指标其计算式已由 aggregate_results.py 的源码确认。示例中购物 120 例、旅行 240 例zh 120 en 120、合计 360 例的结构正是统一评测购物三等级 旅行双语配置下的典型输出形态。五、购物领域深入评测管线与结果指标两级管线推理与评估购物领域评测分两个阶段详见 shoppingplanning/README.md阶段一推理Agent 规划从data/level_{level}_query_meta.json如 level_1_query_meta.json加载购物任务调用 LLM Agent 生成购物方案Agent 通过工具查询数据库搜索商品、筛选、加购等将 Agent 轨迹与执行日志保存在database/case_{id}/目录下其中messages.json保存执行轨迹、cart.json保存最终购物车、validation_cases.json保存标注真值。阶段二评估将 Agent 生成的购物车与真值对比计算准确率得分商品匹配、优惠券匹配校验用例完成情况并生成评估报告输出到result_report/下每个用例对应一份case_*_report.json并汇总为summary_report.json。购物 Agent 与工具集从源码看购物 Agent 实现在 shopping_agent.py 中的ShoppingFnAgent类它将 shopping_tool_schema.json 加载为 OpenAI Chat Completions 格式的工具定义动态加载BaseShoppingTool子类工具实例然后迭代式地调用 LLM 并执行 tool_calls直至给出最终答案。工具集覆盖了完整电商链路包括search_products_tool基于 BM25 的商品搜索、filter_by_brand_tool/filter_by_color_tool/filter_by_size_tool/filter_by_range_tool品牌/颜色/尺寸/价格区间筛选、sort_product_tool排序、get_product_details_tool商品详情、add_product_to_cart/delete_product_from_cart/get_cart_info购物车操作、add_coupon_to_cart/delete_coupon_from_cart/filter_by_applicable_coupons_tool优惠券相关、get_user_info用户信息、calculate_transport_time_tool配送时间计算等均位于 tools 目录 下。跨等级统计与有效模型判定运行完某个模型的所有等级后脚本自动通过evaluation/score_statistics.py计算跨等级总体统计并保存到result_report/{model}_statistics.json。其中关键字段的语义为successful_rate获得满分全部商品与优惠券均匹配的用例占比match_rate⭐正确匹配的期望商品占比论文主报告指标weighted_average_case_score⭐按各等级样本数加权的平均用例得分论文主报告指标levels_completed纳入统计的等级列表valid模型是否有效——判定条件为所有等级的incomplete_rate未完成率不超过 10%。值得注意的是无论valid与否评估报告始终都会保存以便在模型因提前终止或报错导致高未完成率时仍可进行调试与分析valid标志仅用于标识结果是否适合作为可靠基准。六、旅行领域深入三阶段管线、缓存续跑与错误分析三阶段管线旅行领域评测由 travelplanning/run.py 集成为一条流水线依次执行三阶段详见 travelplanning/README.md阶段一推理Agent 规划从data/travelplanning_query_{lang}.json如 travelplanning_query_zh.json加载任务调用 LLM Agent 生成旅行方案Agent 通过工具查询数据库航班、酒店、餐厅、景点等其工具定义见 tool_schema.json 及中英文本地化版本 tool_schema_zh.json、tool_schema_en.json保存轨迹与可读报告results/{model}_{lang}/trajectories/id_0_trajectory.json与results/{model}_{lang}/reports/id_0_report.txt。阶段二转换方案解析使用 LLM默认qwen-plus可配置将 Agent 输出的Markdown 格式旅行计划解析并转换为标准化 JSON存于converted_plans/id_0_converted.json为什么需要转换Agent 生成的是人类可读的 Markdown 计划而评估代码需要结构化 JSON 才能自动计算约束满足度与各类指标。该转换逻辑实现在 convert_report.py其默认转换模型通过conversion_model变量指定。阶段三评估检查交付率是否生成了方案评估 8 个维度的常识得分实现见 constraints_commonsense.py校验个性化约束实现见 constraints_hard.py计算最终得分输出evaluation/evaluation_summary.json与每个任务的id_*_score.json。智能缓存与断点续跑当START_FROMinference时run.sh会自动执行增量检测逻辑扫描reports/文件夹找出缺失的报告文件如id_0_report.txt扫描converted_plans/文件夹找出缺失的转换计划文件如id_0_converted.json从总共 120 个任务ID 0119中识别缺失的任务 ID自动决定起点报告齐全但转换计划缺失 → 从conversion阶段续跑报告缺失 → 从inference阶段重跑两者皆齐 → 直接跳过该模型。这使得长时间运行的评测可以被安全地中断并随时恢复不会丢失已完成的进度。此外旅行领域run.sh支持对多模型并发执行评测每个模型进程写独立日志并汇总成功/失败状态。错误分析旅行领域的评估摘要还会输出常见失败模式的错误统计例如error_statistics: [ { rank: 1, error_type: [Hard] train_seat_status, count: 15, affected_samples: [0, 12, 25, ...] } ]它按影响样本数对错误类型如[Hard] train_seat_status这类硬约束错误排序便于快速定位 Agent 在哪些约束维度上系统性失败。七、购物领域独立运行与并发隔离除统一编排外购物领域支持独立运行推荐用环境变量方式SHOPPING_AGENT_MODELqwen-plus \ SHOPPING_LEVELS1 2 3 \ SHOPPING_WORKERS50 \ SHOPPING_MAX_LLM_CALLS400 \ bash run.sh可用环境变量SHOPPING_AGENT_MODELmodels_config.json 中的模型名多个模型用空格分隔SHOPPING_LEVELS要运行的等级空格分隔如1 2 3SHOPPING_WORKERS并行 worker 数SHOPPING_MAX_LLM_CALLS每个样本的最大 LLM 调用次数。也可以直接修改 run.sh 中:-后的默认值实现永久变更。从脚本源码看购物领域的执行流程为为每次运行创建带唯一时间戳的隔离数据库副本如database_run_qwen-plus_level1_20250105143022_12345/从而支持多个并发运行互不干扰对指定模型在所有等级上依次执行推理等级 1 → 2 → 3推理完成后将结果目录移动到database_infered/对每个等级运行evaluation/evaluation_pipeline.py评估管线生成result_report/下的报告即使模型无效也始终保存报告通过evaluation/score_statistics.py计算该模型跨等级总体统计保存到result_report/{model}_statistics.json。由于每个运行使用独立的数据库目录你可以安全地并行运行多组评测例如同时测试多个模型等级之间默认间隔 10 秒、模型之间默认间隔 60 秒以规避 API 限流。八、注意事项与使用建议qwen-plus 是必需配置旅行领域转换阶段默认依赖它若要替换需同步修改convert_report.py中的conversion_model变量数据文件需要手动下载仓库不携带评测数据库需从 HuggingFace Qwen/DeepPlanning 数据集下载并解压到指定目录温度设置为 0.0为保证评测可复现建议所有模型条目沿用temperature: 0.0valid不等于无效报告评估报告总是生成valid仅指示结果是否适合作为可靠基准购物领域判定阈值为未完成率 ≤ 10%旅行领域可断点续跑善用START_FROM与自动缓存检测避免中断后重复消耗 API 额度跨领域对比看avg_acc该指标统一了购物与旅行两个领域的得分口径是衡量模型整体规划能力的主指标细粒度分析则应分别查看购物match_rate/weighted_average_case_score与旅行composite_score/case_acc及其语言明细。通过统一编排器你只需配置好 models_config.json、.env与 run_all.sh 三处即可在 Qwen、GPT-4o 等任意 OpenAI 兼容模型上完整复现 DeepPlanning 的跨领域评测流程并借助aggregated_results/下的聚合 JSON 进行模型间横向对比。【免费下载链接】Qwen-AgentAgent framework and applications built upon Qwen3.0, featuring Function Calling, MCP, Code Interpreter, RAG, Chrome extension, etc.项目地址: https://gitcode.com/GitHub_Trending/qw/Qwen-Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考