Cherry Studio 怎么配置 Function Calling 工具调用，才能让模型真正去调用工具而不是只回一段文字？

Cherry Studio 的工具调用能否真正触发，取决于三个条件同时成立：所选模型本身支持 tools 参数、接口完整透传 tool_calls 字段、客户端里已经挂载并在会话中启用了具体工具。三项缺任何一项，模型都只会把调用意图写成一段自然语言。这套配置不适用于纯文本补全模型，也不适用于会丢弃 tools 字段的转发接口。 先要分清 Cherry Studio 里工具调用的两条入口：一条是模型原生的 Function Calling，由模型直接输出结构化的 tool_calls；另一条是把外部服务注册成 MCP 服务器，由客户端把工具清单注入请求。两条入口在客户端侧走的是同一条链路，工具定义进请求、模型回 tool_calls、客户端执行、结果以 tool 角色回填。把这条链路记住，比对着界面逐个试参数更容易定位问题。 第一步应先选模型，而不是先装工具。在模型编辑里可以为模型标注能力项，只有具备函数调用能力的对话模型才会在请求里接受 tools 数组，主流厂商的工具版本模型属于这一类。纯文本补全模型、多数蒸馏小模型以及部分推理专用模型，即使能读懂提示，也不会返回结构化 tool_calls，界面上看起来一切正常，对话里只会得到一段文字说明。 第二步是把模型服务按 OpenAI 兼容格式填全。在设置里的模型服务页面新增提供商，类型选 OpenAI 兼容，填入以 /v1 结尾的接口地址与密钥，测试连接通过后再手动添加模型 ID，并勾选函数调用能力。两个高频错误是地址重复写了 /v1 导致 404，以及模型 ID 与上游实际名称不一致导致 400。改完记得保存，并确认当前会话选中的就是新加的模型。 接口是否透传 tool_calls，是这类配置失败率最高的一环。不少转发层会把请求里的 tools 数组丢掉，或者把 tool 角色的消息压平成 user 文本，模型看到的就是一次没有工具的普通对话。判定方法是只挂一个最小工具，发一句必须调用它才能回答的话，观察返回里是否带 tool_calls 以及对应的结束原因；拿不到就换成直连或明确支持工具调用的接口，不要在客户端反复改参数。 第三步在 MCP 服务器页面注册工具。本地工具选 stdio，需要先装好 Node 或 Python 运行环境，填启动命令、参数和工作目录；远程工具选 SSE 或 HTTP，填服务地址和鉴权头。保存后看状态，显示已连接并且能展开工具列表才算注册成功，连不上多半是命令路径、环境变量或端口占用。 工具描述写得粗，模型就会在错误的时机调用。函数名用动词加名词的形式，描述里写清什么条件下该用、什么条件下不该用，参数用 JSON Schema 标出类型、必填项和取值范围，枚举参数直接列出可选值。只写「查询数据」这类模糊描述，最常见的后果是该调的不调、不该调的乱调。 工具挂上之后还要在会话里显式开启。对话输入区的工具开关决定本轮请求是否携带工具清单，开关没开，前面配得再对也不会触发。同时要控制工具数量，单轮挂太多工具会明显拉低模型的选择准确率，还挤占上下文；按场景拆成不同助手，每个助手只启用相关的服务器更稳。 采样参数会直接影响工具调用的稳定性。把温度调到较低区间，减少 JSON 结构写坏的概率；给足最大输出长度，避免 tool_calls 被截断成半截参数。如果模型始终只在文字里描述而不发起调用，应改用支持强制调用选项的模型或接口，而不是靠反复加提示词硬压。 报错和异常基本能按现象定位。提示 tools 不被支持，是模型或接口没有这个能力；返回里 tool_calls 为空，多半是转发层丢了字段；同一个工具被连续调用停不下来，通常是工具返回内容过长或缺少明确的结束条件；参数校验失败，则是 schema 与实际实现不一致。模型调用完不复述结果，说明提示里没有要求它基于工具返回值作答。 工具本质上是权限，配置前要先想清楚边界。文件读写、命令执行一类的本地服务器应限定在受控目录和最小权限账户下运行，避免让桌面客户端拿到整机权限。成本方面，每一轮工具调用都会把完整上下文连同工具清单重发一次，工具越多、轮次越多，token 消耗上升越明显；需要严格审计和多人共用的生产场景，更适合在服务端做编排，而不是依赖桌面客户端。 配置是否成功，用一条最小链路就能验证。只挂一个工具，问一个必须调用它才能回答的问题，然后看三件事：请求里是否带了 tools 数组、响应里是否出现 tool_calls、工具结果是否以 tool 角色回填后再次发出。三点都能观察到，说明配置可用；缺哪一步，就回到对应环节检查模型能力、接口透传或服务器连接状态。