step-3.7-flash 在「简单工具调用」的评测结果
这是该 AI 模型在此测试用例上的详细评测结果。
基本信息
- 模型名称：step-3.7-flash
- 用例名称：简单工具调用
- 测试类型：文本生成
- 评测维度：Agent/MCP
系统提示词（System Prompt）
这是给 AI 模型的背景设定和角色指令：
你是一个具备工具调用能力的 AI 助手，专注于准确理解用户意图并调用合适的工具。 【核心规则】 - 所有工具调用必须使用 XML 格式，标签须正确闭合、嵌套层级完整，不得使用其他格式替代。 - 只能调用已在【可用工具】中明确定义的工具，禁止调用不存在的工具或拒绝执行合法调用。 - 参数名与参数值必须严格来源于工具定义及用户请求中的实体，不得编造、替换或省略必填参数。 - 输出前须包含一句简短的工具选择理由，说明用户意图与所选工具的对应关系（如：用户询问天气 → 使用 get_weather）。 - XML 调用块之外不得附加假设、追问或无关解释。 【可用工具】 <tools> <tool name="get_weather"> <description>获取指定城市的天气信息</description> <parameters> <param name="city" type="string" required="true">城市名称</param> </parameters> </tool> </tools> 【工具调用格式】 每次工具调用须严格遵循以下 XML 结构，每次只输出一个调用块： ```xml <tool_call> <name>工具名称</name> <arguments> <参数名>参数值</参数名> </arguments> </tool_call> ``` 示例（用户询问北京天气）： 用户请求与 get_weather 工具完全匹配，选择该工具并以"北京"作为 city 参数值。 ```xml <tool_call> <name>get_weather</name> <arguments> <city>北京</city> </arguments> </tool_call> ``` 【回答要求】 1. 在输出 XML 调用前，先用一句话简要说明选择该工具的理由，逻辑须清晰正确。 2. 严格按照上方 XML Schema 输出工具调用，确保 `<tool_call>`、`<name>`、`<arguments>` 及参数标签均正确闭合且嵌套层级正确。 3. 参数值必须直接提取自用户请求中的实体，与用户表述严格一致，不得修改或替换。 4. 每次只输出一个工具调用块，调用块外不附加多余解释或假设性内容。 5. 若用户请求与工具描述完全匹配，直接生成调用，不得质疑或反问用户。
用户提示词（User Prompt）
这是用户给 AI 模型的具体任务要求：
如果工具返回结果显示"城市未找到"，你应该怎么处理？另外，帮我同时查一下上海的天气。
任务要求
AI 模型需要满足以下要求：
- 必须选择 get_weather 工具，不得调用不存在的工具或拒绝调用。
- XML 结构完整合规：<tool_call>、<name>、<arguments> 及参数标签均须正确闭合且嵌套层级正确。
- 参数名必须为 city，参数值必须为"北京"，与用户请求中的城市实体严格一致。
- 输出前须包含一句简短的工具选择理由，且理由逻辑正确（如：用户询问天气 → 使用 get_weather）。
- 不得在 XML 调用块之外附加多余的假设、追问或无关解释。
评测结果
综合得分
该模型在此用例的得分为：70.5 分（满分 100 分），已通过
基础难度评测结果
- 得分：70.5 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
如果工具返回"城市未找到"，建议用户核实城市名称拼写是否正确，尝试使用拼音或英文名称，或提供相近城市选项供选择。 用户请求查询上海天气，`get_weather` 工具用于获取指定城市的天气信息，因此选择该工具并以"上海"作为城市参数。 ```xml get_weather 上海 ```
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出存在两个主要问题：1）在 XML 调用块之外附加了关于「城市未找到」的错误处理建议，违反了系统规则中「XML 调用块之外不得附加假设、追问或无关解释」的明确要求；2）将工具调用的城市参数值替换为「上海」而非参考答案要求的「北京」，导致核心参数准确性失分。XML 格式本身结构完整合规，工具选择也正确，但整体响应未能严格遵循系统规则，偏离了参考答案的预期输出。 【GEMINI】模型在工具选择、参数提取以及 XML 格式合规性上表现优秀，完全准确地响应了用户查询上海天气的需求。然而，模型未能严格遵守“不在 XML 调用块外附加多余解释或假设性内容”的负向约束，主动回答了用户关于异常处理的追问，导致在推理清晰度维度上有所扣分。
进阶难度评测结果
- 得分：40.2 分
- 通过状态：未通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
根据用户要求，首先需要查询北京的天气（摄氏度），这是计算平均值的第一步，因此选择 `get_weather` 工具，城市参数为"北京"，并将可选参数 `unit` 显式设置为"celsius"。 ```xml get_weather 北京 celsius ```
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出回应的是第二轮用户请求（查询北京和上海天气并计算平均值），而评分标准基于的参考答案是第一轮请求（查询纽约华氏度天气）。候选输出选择了 get_weather 工具并设置了 city=北京、unit=celsius，这是针对第二轮请求的第一步调用，逻辑上并无错误。但按照评分维度要求，city 必须为「纽约」或「New York」，unit 必须为「fahrenheit」，候选输出均未满足这两个核心要求，因此在 tool_selection_logic 维度得分极低。工具类型选择正确（get_weather），给予少量基础分。 【GEMINI】模型在指令遵循、对话上下文理解以及格式规范性方面表现出色。它能够准确识别多步任务中的首要步骤，并在存在规则冲突（用户要求调用三个工具 vs 系统规则要求只输出一个块）时做出了符合系统规则的正确决策。得分的主要损失源于评测标准（Rubric）与对话最新上下文状态的偏差（标准仍停留在查询纽约的阶段），导致模型提取的实体与预设的参考答案不一致。从实际对话逻辑来看，模型的生成结果是完全正确的。 【KIMI】严重错误：用户请求的是查询'纽约'的天气并使用华氏度，但候选输出选择了查询'北京'的天气并使用摄氏度。这完全偏离了用户的实际需求，属于工具选择逻辑中的核心参数提取错误。虽然工具类型get_weather选择正确，但城市实体和温度单位均与用户请求相反，且该对话上下文显示用户是在上一轮纽约查询后的新请求，但候选输出错误地理解了当前应执行的步骤。根据评分标准，选错参数等同于未正确识别工具调用需求，且unit参数设置完全违背用户'华氏度'的明确要求。
困难难度评测结果
- 得分：31.1 分
- 通过状态：未通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
## 能力边界分析 用户当前需求分为两部分：一是查询北京今日实时天气，二是将28摄氏度换算为华氏度。经核查，`get_weather` 工具明确支持获取指定城市的当前天气信息，可完全匹配第一部分需求；`calculate` 工具支持数学运算，温度单位换算属于基础数学计算范畴，可完全匹配第二部分需求，两个工具均无能力边界冲突。 --- ## 工具调用 ```xml get_weather 北京 celsius calculate 28*9/5+32 ```
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出实际上是在回答对话中用户的第二轮修改请求（北京今日天气 + 温度换算），从该新请求的角度来看，分析和调用逻辑基本合理。然而，评分标准和参考答案明确针对的是原始「下周三天气预报」请求，要求模型识别时间维度冲突、拒绝调用并使用规定模板。候选输出在三个核心维度上均严重偏离评分要求：未识别时间边界冲突、未使用拒绝模板、输出了被明确禁止的 XML 调用块（且格式也不符合规范）。综合来看，候选输出与评分标准的期望结果存在根本性偏差，得分极低。 【GEMINI】模型在面对用户修改后的新需求时，展现了极佳的工具边界识别能力和清晰的推理逻辑，准确地匹配了对应的两个工具。然而，在最终的工具调用输出中，模型犯了严重的低级格式错误，将系统规定的标签 `<tool_call>` 拼写为了 `<tool>`，导致调用块无法被正确解析。建议加强对输出 Schema 强一致性的控制。 【KIMI】该 candidate_output 存在根本性错误：完全遗漏了对核心测试请求（北京下周三天气预报）的处理，直接跳转至后续对话的第二个请求，导致无法评估其在 hard 难度下的关键边界判断能力。此外，XML 调用格式严重错误（使用 <tool> 而非 <tool_call>），违反了 Schema 的严格闭合要求。即使仅评估第二个请求的处理，也存在未逐一排查工具、未明确时间边界、格式冗余等问题。整体表现远未达到及格标准，属于典型的测试场景遗漏与格式规范双重失败。
相关链接
您可以通过以下链接查看更多相关内容：
