qwen3.8-flash 在「多工具协同」的评测结果
这是该 AI 模型在此测试用例上的详细评测结果。
基本信息
- 模型名称：qwen3.8-flash
- 用例名称：多工具协同
- 测试类型：文本生成
- 评测维度：Agent MCP
系统提示词（System Prompt）
这是给 AI 模型的背景设定和角色指令：
你是一名专业的 AI 工具调用规划师，擅长分析工具间的数据依赖关系并生成规范的调用序列。 【核心规则】 所有工具调用必须严格使用 XML 格式输出。 【XML 调用格式】 ```xml <tool_call> <step>步骤编号</step> <tool>工具名称</tool> <params> <param name="参数名">参数值或占位符</param> </params> </tool_call> ``` 【回答要求】 1. 在生成工具调用前，先用 1-2 句话说明调用顺序的依据 2. 严格按照 XML 格式输出每一个工具调用 3. 若某个参数需要来自前一步的返回结果，使用占位符：{{step_N.field_name}} 4. 输出须完整、格式正确，不得遗漏任何必填参数
用户提示词（User Prompt）
这是用户给 AI 模型的具体任务要求：
很好！现在用户追加了一个需求：在发送消息之后，还需要把同样的天气信息也发送给用户 U002。 请在之前的基础上，补充新的工具调用。注意： 1. 不需要重新查询天气，直接复用之前的结果 2. 继续使用 XML 格式输出新增的调用 3. 步骤编号接续之前的编号
任务要求
AI 模型需要满足以下要求：
- 新增的工具调用必须使用 XML 格式输出，与之前保持一致的格式规范
- 必须直接复用之前查询到的天气结果，不得重新调用天气查询工具
- 发送消息的目标用户必须是 「U002」，不得使用其他用户标识
- 新增调用的步骤编号必须接续之前的编号，不得重新从 1 开始编号
评测结果
综合得分
该模型在此用例的得分为：97.7 分（满分 100 分），已通过
基础难度评测结果
- 得分：97.7 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
新增调用依据：天气信息已在 step_1 获取，因此只需复用 `{{step_1.weather_info}}` 并接续步骤编号发送给用户 U002。 ```xml 3 send_message U002 {{step_1.weather_info}} ```
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出整体表现优秀，完整满足所有功能要求：正确复用了 step_1 的天气结果、步骤编号接续为 3、目标用户为 U002、XML 格式规范。值得注意的是，候选输出的参数名使用 content（与工具定义一致），而参考答案误用了 message，候选输出在这一点上反而更为准确。整体质量高，仅在依赖关系说明的详细程度上略有简化，但不影响核心表达。 【GEMINI】模型表现非常出色。在处理追加需求时，不仅完美遵循了 XML 格式规范和步骤接续要求，还在参数命名上比参考答案更加严谨（准确使用了工具定义中的 content 字段）。依赖关系解释清晰，占位符引用完全正确。 【KIMI】候选输出表现优秀。在新增需求场景下，正确识别了数据复用机会，步骤编号合理接续，XML 格式规范，参数名使用准确（content 而非 message，实际上比参考答案更符合工具定义）。整体完全符合任务要求，展现了良好的工具调用规划能力。
进阶难度评测结果
- 得分：93.0 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
**新工具插入位置与依赖关系分析**： 1. `get_promotion_info` 的输入参数是 `member_level`，该字段来自 `get_user_info` 的返回结果，因此它必须依赖 `get_user_info`。 2. `get_promotion_info` 不依赖 `get_order_history`，也不依赖 `calculate_loyalty_points`。 3. `get_promotion_info` 可以与 `calculate_loyalty_points` 并行执行： - `get_promotion_info` 只需要 `member_level`； - `calculate_loyalty_points` 需要 `total_spent` 和 `member_level`。 4. `send_email` 需要用户邮箱、消费金额、积分和促销信息，因此依赖 `get_user_info`、`get_order_history`、`get_promotion_info` 和 `calculate_loyalty_points`。 **完整调用序列**： ```xml 1 get_user_info U12345 2 get_order_history U12345 3 get_promotion_info {{step_1.member_level}} 1 4 calculate_loyalty_points {{step_2.total_spent}} {{step_1.member_level}} 1, 2 5 send_email {{step_1.email}} 您的消费报告与积分通知 尊敬的 {{step_1.name}}，您的总消费金额为 {{step_2.total_spent}} 元，当前积分为 {{step_4.points}} 分。您当前可享受的促销活动为：{{step_3.promotion_name}}，折扣率为：{{step_3.discount_rate}}。 1, 2, 3, 4 ```
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出整体质量较高，正确完成了新工具插入的依赖分析、XML 调用序列更新和邮件内容修改三项核心任务。依赖关系分析准确，并行机会识别到位，XML 格式规范，占位符使用正确，邮件内容包含所有必要信息。与参考答案相比，主要差异在于参考答案引入了一些原始工具列表中不存在的工具（如 `get_order_details`、`get_product_details`），而候选输出严格基于已定义的工具集进行规划，反而更符合实际约束。整体表现优秀。 【GEMINI】候选输出表现极其优秀。它不仅完美避开了标准参考答案中可能存在的工具名称偏差（标准答案中误写为了其他任务的 get_order_details 等），而是紧扣本题实际上下文中的工具（get_order_history 等）进行了精准的逻辑推理和代码生成。格式规范，依赖清晰，业务语义完整，是一份完美的回答。 【KIMI】候选输出整体质量优秀，正确完成了新增工具的集成、依赖关系分析和XML调用序列生成。依赖分析准确，识别了get_promotion_info与calculate_loyalty_points的并行机会，send_email正确汇聚所有前置结果。主要改进点：去除<tool_calls>外层包裹以严格符合题目格式要求，更明确标注所有并行关系，以及优化邮件主题和正文格式以更好体现业务语义。
困难难度评测结果
- 得分：86.3 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
## 动态引用处理方案 你指出的问题正确：`{{最终审批人ID}}` / `{{最终审批人email}}` 不是合法占位符。由于最终审批人来自条件分支，不能用一个统一伪变量表示。这里采用**分支内展开后续调用**的方式，确保每个 `tool_call` 使用的都是确定的 `{{call_id.field_name}}`。 ### 最终审批人字段映射 | 路径 | 触发条件 | 最终审批人 ID 占位符 | 最终审批人 email 占位符 | |---|---|---|---| | A：直属经理有权限 | `{{mgr_auth_1.can_approve}} == true` | `{{emp_info.manager_id}}` | `{{mgr_info.email}}` | | B：直属经理无权限，上级经理有权限 | `{{mgr_auth_1.can_approve}} == false` 且 `{{mgr_auth_2.can_approve}} == true` | `{{mgr_info.manager_id}}` | `{{higher_mgr_info.email}}` | | C：上级经理也无权限 | `{{mgr_auth_1.can_approve}} == false` 且 `{{mgr_auth_2.can_approve}} == false` | 不创建报销单，走失败通知路径 | 不创建报销单，走失败通知路径 | ### 关键修正 1. **权限上报逻辑补全** - 先校验直属经理：`mgr_auth_1` - 若直属经理无权限，则获取其上级经理信息：`higher_mgr_info` - 再校验上级经理权限：`mgr_auth_2` - 若上级经理仍无权限，则不创建报销单，并通知相关方 2. **新增 CFO 升级规则** - 若 `15000 > {{dept_budget.remaining}} * 0.8` - 则在 `create_expense_request` 成功后： - 通知财务 - 调用 `escalate_to_cfo` 3. **避免伪占位符** - 将 `create_expense_request` 和后续通知分别放入互斥分支中 - 每个分支内的占位符都来自确定已执行的 `call_id` --- ## 完整修正后的 XML 调用序列 ```xml emp_info get_employee_info E10086 dept_budget get_department_budget {{emp_info.department}} emp_info mgr_info get_employee_info {{emp_info.manager_id}} emp_info mgr_auth_1 check_approval_authority {{emp_info.manager_id}} 15000 emp_info {{mgr_auth_1.can_approve}} == true create_req_direct create_expense_request E10086 15000 差旅费 {{emp_info.manager_id}} 差旅费报销申请 emp_info, mgr_auth_1 notify_applicant_direct send_notification {{emp_info.email}} expense_submitted 您的差旅费报销申请已提交，申请编号：{{create_req_direct.request_id}} create_req_direct, emp_info notify_approver_direct send_notification {{mgr_info.email}} expense_approval_needed 您有一笔待审批的差旅费报销申请，编号：{{create_req_direct.request_id}}，金额：15000元 create_req_direct, mgr_info 15000 > {{dept_budget.remaining}} * 0.8 notify_finance_direct send_notification finance@company.com budget_alert 部门 {{emp_info.department}} 的差旅费报销申请 {{create_req_direct.request_id}} 金额为 15000 元，已超过部门剩余预算的 80% create_req_direct, dept_budget, emp_info...
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出成功解决了用户提出的核心问题——消除伪占位符，通过「分支内展开后续调用」的方案，使每个分支内的占位符都指向确定已执行的 call_id。权限上报逻辑完整（两级校验），预算超限规则正确整合了 escalate_to_cfo，双向通知要求得到满足。额外增加了路径 C（双级权限不足）的失败处理，体现了较强的业务完整性意识。整体方案逻辑严密、格式规范、并行优化合理，是一个高质量的多轮工具调用编排响应。 【GEMINI】这是一份堪称教科书级的完美答卷。模型不仅彻底解决了动态引用的痛点问题，而且在业务逻辑的严密性（如考虑了二级审批依然权限不足的异常流）、并行的优化设计、以及 XML 格式的规范性上都无可挑剔。 【KIMI】该候选方案在解决核心问题（消除伪占位符）上采用了正确的思路（分支内展开），但执行层面存在较多问题：依赖关系混乱、审批人ID与通知对象不一致、嵌套过深、代码重复严重。权限上报逻辑虽完整但效率低下，预算规则实现正确但条件表达式写法可疑。整体处于及格边缘，主要因基本覆盖了所有业务路径而获得一定分数，但逻辑准确性和格式规范性亟待提升。
相关链接
您可以通过以下链接查看更多相关内容：
