deepseek-v4-pro 在「简单工具调用」的评测结果
这是该 AI 模型在此测试用例上的详细评测结果。
基本信息
- 模型名称：deepseek-v4-pro
- 用例名称：简单工具调用
- 测试类型：文本生成
- 评测维度：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 调用块之外附加多余的假设、追问或无关解释。
评测结果
综合得分
该模型在此用例的得分为：42.5 分（满分 100 分），未通过
基础难度评测结果
- 得分：42.5 分
- 通过状态：未通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
用户请求查询上海的天气，`get_weather` 工具完全匹配该意图，使用“上海”作为城市参数。 ```xml get_weather 上海 ```
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【KIMI】候选输出在 XML 格式上完全合规，但在核心任务上严重偏离。依据 EVAL_BLOB 的 reference_answers，评分对象是参数值为'北京'的工具调用，但候选输出针对的是对话后续中'上海'的查询，且完全忽略了用户关于错误处理的前半部分询问。这是对用户当前完整请求的片面理解和错误响应，导致工具选择和参数准确性完全失败。
进阶难度评测结果
- 得分：79.4 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
我将首先使用 `get_weather` 工具查询北京的天气，并将可选参数 `unit` 设置为 "celsius" 以符合要求。 get_weather 北京 celsius
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】候选输出在格式规范和输出纪律方面表现优秀，XML 结构严格符合 Schema 且内容简洁。然而，核心问题在于完全误判了评测任务：参考答案要求响应「纽约 + 华氏度」的查询，但候选输出却响应了后续对话中的「北京 + 摄氏度」请求，导致工具选择逻辑维度得分为零。这是对评测上下文的根本性误读，使得整体评分严重失衡。建议模型在多轮对话场景中明确锚定评测目标任务节点。 【GEMINI】模型在处理复杂的序列请求时表现出色。尽管 EVAL_BLOB 中的评分维度描述和参考答案仍保留在上一轮对话（纽约）的指令上，但模型能够准确识别并响应对话上下文中的最新用户请求（北京/上海），并严格遵守了“单次调用”、“XML 格式”及“显式设置可选参数”的所有系统约束。其逻辑判断准确，格式严谨，输出极其克制。 【KIMI】整体评价：输出完全符合要求，正确选择了工具并设置了参数，XML格式正确无误，输出内容简洁且没有多余信息，表现优秀。
困难难度评测结果
- 得分：95.8 分
- 通过状态：已通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
## 能力边界分析 用户请求可拆解为两个独立需求： 1. **查询北京今天的当前天气**（时间：当前，地点：北京）—— 工具 `get_weather` 描述为“获取指定城市的当前天气信息”，完全匹配。 2. **将 28 摄氏度换算为华氏度**—— 工具 `calculate` 描述为“进行数学计算”，换算公式为纯数学表达式，完全匹配。 满足所有规则，可同时输出两个工具调用。 --- ```xml get_weather 北京 celsius calculate (28 * 9 / 5) + 32 ```
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【KIMI】候选输出在用户修改需求后的新对话轮次中表现正确：准确识别'北京今天'与get_weather'当前天气'的匹配性，以及'摄氏度转华氏度'与calculate的匹配性，同时输出两个规范的XML调用块。未对原'下周三预报'需求进行幻觉调用。主要改进点：应更严格遵循'逐一排查每个可用工具'的要求，对所有4个工具进行显式排除说明，即使某些工具明显无关；同时可简要呼应时间维度从'未来'到'当前'的转变以增强推理完整性。
相关链接
您可以通过以下链接查看更多相关内容：
