1. 项目背景与测试目标
最近在开发一款名为 Soul Mate 的 AI 桌面助手项目时,我遇到了一个关键问题:如何选择最适合 function calling 场景的大语言模型。function calling 能力直接决定了 AI 能否准确、高效地操作用户电脑,是桌面 Agent 的核心功能。
为了找到最佳解决方案,我设计了一套完整的测试方案,对当前主流的四款模型进行了横向对比:
- DeepSeek V3(新旧两个版本)
- Qwen Plus
- MiniMax M2.5(包括标准版和 Lightning 版)
测试重点关注三个核心问题:
- 不同模型在桌面 Agent 场景下的实际表现差异
- Thinking Model(思考型模型)在工具调用场景中的优劣势
- DeepSeek 最近更新对 function calling 能力的影响
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 测试框架与方法论
2.1 测试环境搭建
测试基于 Tauri v2 框架开发的桌面应用,采用 Rust 后端 + React 前端架构。系统内置了三个基础工具供 AI 调用:
| 工具名称 | 功能描述 | 使用场景示例 |
|---|---|---|
| run_command | 执行 Windows cmd 命令 | 查看文件列表、获取系统信息 |
| read_file | 读取指定文件内容 | 查看文档、配置文件 |
| write_file | 创建或覆盖写入文件 | 保存笔记、创建配置文件 |
2.2 测试用例设计
参考 Berkeley Function Calling Leaderboard (BFCL) 和 OSWorld 的研究成果,设计了 29 个测试用例,覆盖 7 个关键场景:
| 类别 | 用例数 | 测试重点 |
|---|---|---|
| 基础对话 | 4 | 无需工具调用的基础能力 |
| 单步读取 | 5 | 一次性文件读取操作 |
| 单步写入 | 3 | 一次性文件创建/写入操作 |
| 多步串行 | 4 | 需要多步工具调用的复杂任务 |
| 模糊输入 | 2 | 用户指令不明确时的处理能力 |
| 错误处理 | 2 | 文件不存在等异常情况的处理 |
| 中文编码 | 2 | GBK/UTF-8 编码文件的处理能力 |
| 安全控制 | 3 | 危险命令的识别与拒绝 |
| 语音模式 | 4 | 简短口语化回复能力 |
2.3 评分体系
每个用例从 5 个维度进行评分(每维度 2 分,总分 10 分):
- 结果正确性:任务是否完成
- 工具选择:是否选择了正确的工具和参数
- 轮数效率:是否以最优轮数完成任务
- 响应速度:总耗时是否在合理范围内
- 回复质量:回复是否自然、有用
3. 模型表现深度分析
3.1 总体表现对比
| 指标 | DeepSeek V3 | Qwen Plus | MiniMax M2.5 |
|---|---|---|---|
| 总分 | 81.5% | 96.5% | 88.5% |
| 满分用例数 | 8/22 | 19/22 | 8/22 |
| 低分用例(≤6) | 8/22 | 0/22 | 1/22 |
| 平均轮数 | 3.9 | 2.0 | 2.3 |
| 平均耗时 | 15.1s | 4.3s | 29.5s |
3.2 DeepSeek V3 的核心问题
DeepSeek 在测试中暴露出三个主要弱点:
-
过度不信任工具结果
- 当工具返回错误或输出被截断时,会反复用不同命令重试
- 例如在查询进程列表时,因输出超4000字被截断,就换用wmic、powershell等多种方式反复查询
-
Windows cmd 知识薄弱
- 不会使用
dir /O-S按大小排序文件 - 模糊搜索时不会一步
dir *test*,而是先dir再findstr
- 不会使用
-
中文编码处理能力差
- 读取中文文件时尝试多种编码方式,导致轮数暴增
- 新版反而退步,反复尝试不同编码命令触发轮数上限
3.3 MiniMax M2.5 的思考负担
作为 Thinking Model,MiniMax 每次请求都会先在 <think> 标签中进行推理,这带来了三个问题:
-
简单任务也要"多想一步"
- 读不存在的文件时,会先尝试读取,再调用 dir 列目录确认
- 找最大文件时,先 dir 列出,再 dir /O-S 排序
-
速度全面落后
- 即使工具调用轮数相同,每轮都有额外思考时间
- 一个简单的"你好"问候就要2.2秒(Qwen仅0.76秒)
-
无视System Prompt约束
- 语音模式要求简短回复,却列出桌面所有文件详情
- 思考过程覆盖了系统提示的约束规则
3.4 Qwen Plus 的优异表现
Qwen 在测试中展现出显著优势:
-
果断执行
- 平均仅需2.0轮就能完成任务
- 截断输出时直接基于现有信息总结
-
知识全面
- 熟练掌握Windows cmd各种实用参数
- 中文编码处理得当
-
响应迅速
- 平均耗时仅4.3秒
- 语音模式响应精准控制在60字内
唯一的小问题是偶尔会"偷懒"——承诺要查磁盘空间但未实际调用工具。
4. 关键发现与选型建议
4.1 Thinking Model 的适用场景
测试结果表明,Thinking Model 在 function calling 场景中弊大于利:
- 简单文件操作不需要深度思考
- 思考过程增加了每次调用的延迟
- 在多轮工具调用中延迟会累积放大
- 可能覆盖system prompt的约束规则
4.2 各模型适用场景推荐
| 场景 | 推荐模型 | 理由 |
|---|---|---|
| 桌面Agent/工具调用 | Qwen Plus | 速度快、执行果断、性价比高 |
| 复杂推理/代码生成 | MiniMax M2.5 | 思考模型推理质量高 |
| 简单对话/预算有限 | DeepSeek V3 | 价格最便宜 |
| 快速响应需求 | 避免MiniMax | 思考延迟不可关闭 |
4.3 成本效益分析
| 模型 | 输入价格 | 输出价格 | 性价比评价 |
|---|---|---|---|
| DeepSeek V3 | $0.07/M | $0.28/M | 最便宜但能力有限 |
| Qwen Plus | $0.08/M | $0.40/M | 性价比最优 |
| MiniMax M2.5 | $0.15/M | $1.20/M | 思考开销导致成本高 |
Qwen 只比 DeepSeek 贵约40%,但效率好2倍以上,综合成本反而更低。
5. 实操建议与避坑指南
5.1 系统提示词设计要点
-
明确工具使用规则
- 强调"不需要二次验证工具结果"
- 规定"遇到错误直接告知用户"
-
约束回复风格
- 语音模式明确字数限制
- 要求回复简洁直接
-
环境信息完整
- 包含OS版本、用户目录等关键信息
5.2 工具定义最佳实践
-
参数描述清晰
- 明确要求使用绝对路径
- 说明各工具的具体用途
-
功能单一化
- 避免多功能复合工具
- 保持工具职责明确
5.3 性能优化技巧
-
设置合理超时
- 单轮调用超时限制
- 总轮数上限控制
-
输出长度限制
- 防止过长输出导致处理延迟
- 关键信息提取优化
-
重复检测机制
- 避免相同命令反复执行
- 异常情况自动终止
6. 测试方案复现指南
如需在自己的环境中复现测试,需要准备:
-
基础环境
- Windows 11系统
- 支持OpenAI兼容API的调用环境
-
核心组件
- 三个基础工具实现
- 测试用例定义文件
-
执行流程
- 加载系统提示词
- 依次执行29个测试用例
- 记录每轮交互详情
- 自动计算各维度得分
完整测试定义和实现代码已开源在项目GitHub仓库,包含:
- 详细的用例说明
- 评分标准细则
- 自动化测试脚本
- 原始测试数据
在实际开发中,我发现模型选择只是桌面Agent成功的一个因素。同样重要的是系统提示词的设计、工具接口的定义以及异常处理机制的完善。Qwen Plus虽然表现出色,但也需要配合精心设计的系统环境才能发挥最大效用。
对于正在开发类似项目的同行,我的建议是:
- 先明确核心使用场景
- 设计最小可行工具集
- 用实际用例验证模型选择
- 持续优化系统提示词
最后分享一个实用技巧:在语音模式测试中,除了字数限制外,增加"用口语化表达"的要求,可以让AI的回复更加自然亲切。这在Qwen上效果尤为明显,能生成既简短又生活化的回复。
