OpenAI: gpt-oss-120b 在「简单工具调用」的评测结果
这是该 AI 模型在此测试用例上的详细评测结果。
基本信息
- 模型名称：OpenAI: gpt-oss-120b
- 用例名称：简单工具调用
- 测试类型：文本生成
- 评测维度：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 调用块之外附加多余的假设、追问或无关解释。
评测结果
综合得分
该模型在此用例的得分为：58.83 分（满分 100 分），未通过
基础难度评测结果
- 得分：58.83 分
- 通过状态：未通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
使用 get_weather 查询上海天气，若返回“城市未找到”，意味着城市名称未被识别，需要检查拼写或提供更准确的名称。 ```xml get_weather 上海 ```
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】模型在工具选择和 XML 格式上基本正确，但核心参数提取出现偏差——将「上海」作为本次调用的城市参数，而参考答案要求的是「北京」。同时，在调用块外附加了关于错误处理的解释，违反了系统规则中「XML 调用块之外不得附加假设、追问或无关解释」的要求。整体表现中等偏下，主要失分点在于参数准确性和输出规范性。 【KIMI】模型在格式合规性上表现完美，但在最核心的参数准确性上出现致命错误——完全忽略了用户明确要求的「北京」，擅自替换为「上海」。此外，理由部分不仅城市名称错误，还包含了多余的假设性解释，违反了简洁性要求。这是一个典型的「听错指令」错误，尽管 XML 格式正确，但功能实现完全偏离用户意图。
进阶难度评测结果
- 得分：58.77 分
- 通过状态：未通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
我将首先使用 `get_weather` 工具查询北京的天气，城市参数设为“北京”，并将可选参数 `unit` 明确设置为“celsius”。 get_weather 北京 celsius
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】模型生成结果存在根本性错误：它响应的是对话中后续用户追问（查询北京和上海天气），而非评测所针对的原始请求（查询纽约华氏度天气）。参考答案明确要求 city=New York、unit=fahrenheit，但模型输出 city=北京、unit=celsius，核心参数均错误。格式层面 XML 结构合规，输出也较为简洁，但由于工具调用的实质内容完全偏离评测目标，整体得分较低。 【KIMI】模型出现了严重的任务理解错误。当前用户请求明确是查询「纽约」的「华氏度」天气，但模型却生成了「北京」「摄氏度」的调用，似乎是预设上下文中的后续任务干扰了判断。尽管 XML 格式本身合规，但核心功能完全失败，属于典型的上下文混淆导致的错误。
困难难度评测结果
- 得分：42.13 分
- 通过状态：未通过
模型生成产物
以下是该模型针对此任务的实际生成内容：
get_weather 北京 celsius calculate (28*9/5)+32
AI 评审点评
以下是 AI 评审对该模型输出的点评：
【CLAUDE】本题评分标准针对的是「北京下周三天气预报」这一原始需求的拒绝场景，要求模型识别时间维度冲突并输出规定拒绝模板。模型生成结果是对用户修改后新需求（今天天气+温度换算）的回应，两个工具调用在新需求语境下均正确且格式规范。然而，按照题目给定的评分维度和参考答案，模型应当拒绝调用并使用规定模板，而非输出 XML 调用块。因此，按评分标准衡量，模型在三个维度上均严重不符合要求，整体得分极低。 【KIMI】模型在第二轮对话中表现优异，准确识别了修改后需求与工具能力的匹配关系，正确调用了 get_weather 和 calculate 两个工具，参数准确、格式规范。与第一轮严格拒绝「下周三预报」形成对比，体现了对「当前」与「未来」时间维度的精确区分能力，未出现逻辑矛盾或幻觉调用。
相关链接
您可以通过以下链接查看更多相关内容：
