桌面 Agent Function Calling 四模型实测 | DeepSeek V3 / Qwen Plus / MiniMax M2.5

作者：Sebastilan & Claude（AI 协作）

问题背景

我在做一个 AI 桌面助手项目（Soul Mate），需要模型具备可靠的 function calling 能力来操作用户电脑。2 月 9 日做了 DeepSeek V3 和 Qwen Plus 的基线测试后，又陆续测了两个场景：

DeepSeek 更新重测（02-12）：2 月 11 日 DeepSeek App 推送重大更新（128K→1M 上下文，知识截止日期更新到 2025-05），想验证 function calling 有没有连带提升。

MiniMax M2.5 评测（02-13）：MiniMax 最近发布了 M2.5，号称编码和 Agent 场景 SOTA，成本仅为 Claude Opus 的 1/20。它是一个 thinking model（类似 DeepSeek R1，每次请求会先在 <think> 标签中进行推理），这引出了一个有趣的问题：推理型模型的"深度思考"在 function calling 场景中是优势还是负担？

测试方法

测试框架

Soul Mate 是一个 Tauri v2 桌面应用（Rust 后端 + React 前端），内置了 3 个工具供 AI 调用：

测试脚本完整模拟 Agent 循环：System Prompt → LLM API → 工具调用 → 结果回传 → 继续对话，直到模型给出最终回复。所有 API 调用均使用 OpenAI 兼容格式的 /chat/completions + tools 参数。

测试集设计

参考 BFCL（调用模式分类）和 OSWorld（桌面 Agent 任务域），设计了 29 个用例：

评分体系

每个用例 5 个维度 x 2 分 = 10 分：

模型配置

注：MiniMax M2.5 / Lightning / Highspeed 是同一个模型的三个速度档（50/100 TPS），能力完全一致，都带 <think> 推理过程，无法关闭。

结果

总评

排名：Qwen Plus (96.5%) >> MiniMax M2.5 (88.5%) > MiniMax Lightning (85.8%) > DeepSeek V3 (81.5%)

逐用例对比

标粗的是丢分项（<=8 分）。

语音模式对比

DeepSeek 新旧对比

各模型弱点分析

DeepSeek V3：不信任工具结果，反复重试

无论新旧版，DeepSeek 在 function calling 场景中始终有三个核心问题。

1. 错误/截断后反复重试

当工具返回错误或输出被截断时，DeepSeek 不信任结果，反复用不同命令尝试获取"完整"信息。

• C02-5 进程列表：tasklist 输出超 4000 字被截断 → 换 wmic、powershell 等反复查（5-6 轮）
• C06-2 删除不存在的文件：del 报错 → 用 dir 确认 → 再 del → 再 dir...（7-8 轮）

Qwen 的做法：截断了就基于现有信息总结，报错了就直接告知用户，2 轮搞定。

2. Windows cmd 知识薄弱

• C04-3 找最大文件：不会用 dir /O-S 按大小排序，试了多种方法都不对
• C05-1 模糊搜索：不会一步 dir *test*，而是先 dir，再 findstr...（6 轮）
• C05-2 找 .lnk：同样不会 dir *.lnk，绕了 6 轮

3. GBK 编码处理差

• C07-2（新版）：尝试 type、chcp 65001、powershell Get-Content 等多种方式读取中文文件，反复 10 轮触发上限
• C02-2（旧版）：read_file 读到乱码后不信任结果，额外调 2 次 run_command 验证

MiniMax M2.5：Thinking Model 的"过度思考"

MiniMax M2.5 作为 thinking model，每次请求都会先在 <think>...</think> 中进行推理。这在某些场景是优势（推理质量确实不错），但在桌面 Agent 场景中暴露了三个问题。

1. 简单任务也要"多想一步"，导致轮数偏高

MiniMax 倾向于多做验证，即使任务已经完成。

最极端的是 V04 磁盘查询：Qwen 直接从上下文回答，0.6 秒；MiniMax 反复调用 WMI 命令，花了 195 秒（超过 3 分钟），因为 thinking 过程让它"觉得应该查一下才准确"。

2. 速度全面落后——thinking 开销不可忽视

即使工具调用轮数相同，MiniMax 每一轮都比 Qwen 慢。原因是每次 API 调用都有 <think> 推理过程的额外耗时。

一个"你好"就要 2.2 秒（Qwen 0.76 秒），因为 MiniMax 也要先 think 一番。在桌面助手场景中，这种延迟严重影响用户体验。

3. 语音模式不听话——无视 System Prompt 约束

语音模式要求模型控制回复长度（50-60 字以内），Qwen 能精准遵守，MiniMax 完全无视。

MiniMax 在 V02 中逐个列出了桌面上的每一个文件（包括文件名和分类），完全忽略"语音模式请简短回复"的系统提示。这说明 thinking model 的推理过程可能会"覆盖"掉 system prompt 中的约束规则——模型 think 完之后认为应该给出完整信息，而不是遵守简短要求。

Qwen Plus：不是完美，但瑕不掩瑜

Qwen Plus 虽然总分遥遥领先，也不是没有弱点：

1. C05-2 快捷方式计数（8/10）：用了 4 轮才完成（最优 2 轮），先 dir，再 dir *.lnk，再 dir /A:H *.lnk，有点过度谨慎。有趣的是，MiniMax 在这个用例上一步到位（9/10），反而比 Qwen 更果断。

2. 偶尔"懒"——不调工具直接回答：V04 磁盘查询中，Qwen 说"我帮你查下磁盘空间"但没有实际调用工具。虽然响应飞快（0.6 秒），但严格来说这不是正确行为——用户期望的是真实数据，不是一句话承诺。

这些是小问题，不影响 Qwen 的整体领先地位。

MiniMax Lightning 值不值？

MiniMax 提供三个速度档（M2.5 / Lightning / Highspeed），能力完全相同，只是推理速度和价格不同：

实测对比：

结论：Lightning 不值。花两倍价钱买了点速度，质量反而下降了（可能因为推理速度加快导致 thinking 质量略降）。而且即使快了 2.5 倍，V04 仍然要 79 秒——对比 Qwen 的 0.6 秒，量级差距没有本质改变。

数字总览

MiniMax 的数据很有意思：满分用例数和 DeepSeek 一样（8/22），但低分用例只有 1 个（vs DeepSeek 的 8 个）——它的问题不是"做错"，而是"做慢"。大部分扣分来自耗时和轮数效率维度。

关于价格

Qwen 只比 DeepSeek 贵约 40%，但效率好 2 倍以上，综合成本反而更低。MiniMax 因为 thinking model 的特性，每次请求都有额外的推理 token 开销，实际成本比标价高不少。

总结

1. Thinking Model 在 Function Calling 场景中弊大于利

MiniMax M2.5 的测试给出了明确信号：推理型模型的深度思考在工具调用场景中主要是负担。

• 简单的文件操作不需要"思考"，需要的是果断执行
• <think> 过程增加了每次调用的延迟，在多轮工具调用中延迟会累积放大
• 推理过程可能"覆盖"system prompt 的约束（如语音模式的简短要求）

如果你的应用重度依赖 function calling，优先选择快速果断的非推理模型。

2. DeepSeek 更新对 Function Calling 无实质改善

总分完全不变（81.5%），改善 1 处退步 4 处。上下文扩展和知识更新是基础能力升级，但 function calling 的核心弱点（不信任结果、cmd 知识弱、GBK 处理差）没有修复。

3. Qwen Plus 在 Agent 场景下仍是最优选择

• 几乎每个用例都以最优路径完成（平均 2.0 轮）
• 速度快（平均 4.3s，MiniMax 29.5s，DeepSeek 15.1s）
• 价格适中（只比最便宜的 DeepSeek 贵 40%）

4. 选模型看场景

附录：完整测试集（可复现）

如果你也在做 Agent 性能评估，以下是完整测试集定义。只需要一个支持 OpenAI 兼容格式 function calling 的 API，配合 3 个基础工具（run_command / read_file / write_file），就可以在自己的环境上复现。完整实验报告见 GitHub 仓库。

System Prompt

你是 Soul Mate，桌面伙伴兼助手。

## 系统环境
OS: Windows 11
User: {username}
Home: {home_path}

## 规则
- 友善、温暖、有个性
- 需要操作用户电脑时，使用提供的工具
- 工具调用后根据结果用自然语言回复用户
- 路径一律使用绝对路径
- 你没有联网能力，无法查询天气、新闻等实时信息，直接告知用户
- 工具返回错误时直接告知用户，不要反复重试同类命令
- 工具返回成功即为成功，不需要再调工具二次验证

工具定义

[
  {
    "type": "function",
    "function": {
      "name": "run_command",
      "description": "在用户电脑上执行 shell 命令。用于查看文件列表、运行程序、获取系统信息等。",
      "parameters": {
        "type": "object",
        "properties": {
          "command": {"type": "string", "description": "要执行的命令"}
        },
        "required": ["command"]
      }
    }
  },
  {
    "type": "function",
    "function": {
      "name": "read_file",
      "description": "读取用户电脑上的文件内容。",
      "parameters": {
        "type": "object",
        "properties": {
          "path": {"type": "string", "description": "文件的绝对路径"}
        },
        "required": ["path"]
      }
    }
  },
  {
    "type": "function",
    "function": {
      "name": "write_file",
      "description": "在用户电脑上创建或覆盖写入文件。",
      "parameters": {
        "type": "object",
        "properties": {
          "path": {"type": "string", "description": "文件的绝对路径"},
          "content": {"type": "string", "description": "要写入的内容"}
        },
        "required": ["path", "content"]
      }
    }
  }
]

用例速查

• 常规 22 个（C01-C07）+ 安全 3 个（S01-S03）+ 语音 4 个（V01-V04）= 29 个
• 每个常规/语音用例 10 分满分，总分 260
• Agent 循环约束：最大 10 轮，输出截断 4000 字，重复检测
• 详细用例定义见 GitHub 仓库

一起交流

如果你觉得有帮助，欢迎：

• 📌 订阅本专栏，跟进后续更新
• 💬 评论区留言，交流你的想法
• ⭐ 点赞收藏，让更多朋友看到

— Sebastilan & Claude