1. 本地部署 8B/14B 开源大模型 function call 能力实测哪些模型能稳定完成工具调用你手里有一张 24G 显存的卡或者一台 32G 内存的 Mac想跑一个 8B 或 14B 的开源模型然后接上自己的工具链做 Agent。第一个卡住你的问题往往不是显存够不够而是这个模型到底能不能稳定地吐出结构化的 function call 参数我试过把同一个天气查询请求丢给不同量级的模型结果差异大到离谱。有的模型规规矩矩返回{name: get_current_weather, parameters: {location: 北京}}有的模型直接给你写一段北京今天晴18 到 25 度的自然语言还有的模型把 JSON 包在好的我将为您调用天气函数这种废话里解析器直接崩掉。这就是本地部署 8B/14B 模型做 function call 的真实处境。它不是一个支持/不支持的二元问题而是一个在什么提示词下、什么温度参数下、多大概率能返回合法 JSON的连续问题。基础模型Base基本不用想它只会续写文本指令微调模型Instruct靠提示工程能跑通简单场景专门为工具调用微调过的模型比如 Functionary、Gorilla 这类成功率明显更高但依然需要你在外面套一层解析和执行框架。这篇文章不聊虚的直接给你三样东西一份可复制的模型清单标注哪些 8B/14B 模型在 function call 上表现相对稳、一套可复制的调用配置含 JSON 工具定义和系统提示词模板、一个能直接跑的验证脚本批量测试工具选择准确率和 JSON 合规率。你照着跑一遍就知道自己手里的模型到底能不能上生产。适合谁看正在用 Ollama、vLLM、llama.cpp 本地起模型想接 LangChain 或自己写 Agent 框架的开发者手里有 8B/14B 量化模型不确定要不要换更大模型的人以及被模型说它会 function call 但实际跑起来全是解析错误坑过的人。核心检索词先摆出来本地部署大模型 function call 能力验证、8B 14B 开源模型工具调用测试、function call JSON 格式合规率。下面从问题拆解开始一步步给你可跟做的方案。2. TaoToken 前置用统一 API 做对照组快速判断模型 function call 行不行在本地折腾 8B/14B 模型之前我建议你先做一件事拿一个已知 function call 能力稳定的 API 做对照组。原因很简单——如果你的验证脚本本身有 bug或者工具定义写错了本地模型返回垃圾你可能以为是模型不行其实是你的测试代码有问题。有个稳定参照物排障效率完全不一样。TaoToken 在这里的角色就是那个对照组 兜底通道。它提供 OpenAI 兼容的接口你可以用同一套openaiPython SDK只改base_url和api_key就能在本地模型和云端模型之间切换。这样你的验证脚本写一次两边都能跑直接对比通过率。具体怎么接TaoToken 的 API 地址是https://taotoken.net/api兼容 OpenAI 的/v1/chat/completions路径。你在代码里这样配from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api/v1, api_key你的_TaoToken_Key )注意base_url要带/v1这是 OpenAI SDK 的约定。Key 在控制台的 API Keys 页面生成地址是https://taotoken.net/console/api-keys。生成后复制出来别提交到 Git。为什么强调用 TaoToken 做对照因为本地 8B/14B 模型最常见的失败模式是JSON 嵌套在自然语言里而稳定的 API 模型基本不会犯这个错。你跑同一个测试用例如果 API 模型返回的是干净的tool_calls结构本地模型返回的是一坨带解释文字的 JSON 字符串那问题就定位清楚了——是模型的格式遵循能力不够不是你的解析逻辑写错了。另外TaoToken 的模型对话功能可以让你在不写代码的情况下手动测几个边界 case。比如你输入帮我查一下北京天气然后发邮件给 testexample.com看模型是一次返回两个 tool_calls还是只返回一个还是直接拒绝。这个手动测试花两分钟能帮你判断这个模型值不值得写自动化脚本去测。对于长期要做 Agent 开发的场景TaoToken 的 Coding Plan 提供了更稳定的调用配额适合把对照组固定下来每次本地模型调参后都跑一遍回归测试。地址是https://taotoken.net/coding-plan。接入文档在https://taotoken.net/doc里面有完整的请求示例和参数说明。如果你用的是 Claude Code 这类工具Anthropic 兼容的接入方式也有对应说明https://taotoken.net/claude-code-anthropic。一句话总结这一节本地模型 function call 能力验证别自己闷头测。先用 TaoToken 跑通一套标准测试用例确认脚本和工具定义没问题再把base_url换成http://127.0.0.1:11434/v1Ollama或你的 vLLM 地址对比通过率。这样你得到的结论才可信。3. 可复制配置8B/14B 模型 function call 的 JSON 工具定义与系统提示词模板这一节直接给可复制的配置。你不需要从零设计提示词照着改就行。3.1 工具定义OpenAI 兼容格式不管你用 Ollama、vLLM 还是 llama.cpp 的 server工具定义都走 OpenAI 的tools字段。下面这份 JSON 可以直接用[ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气信息, parameters: { type: object, properties: { location: { type: string, description: 城市名称例如北京、上海 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位默认摄氏度 } }, required: [location] } } }, { type: function, function: { name: send_email, description: 发送电子邮件, parameters: { type: object, properties: { recipient: { type: string, description: 收件人邮箱地址 }, subject: { type: string, description: 邮件主题 }, body: { type: string, description: 邮件内容 } }, required: [recipient, subject, body] } } }, { type: function, function: { name: search_web, description: 在网络上搜索信息, parameters: { type: object, properties: { query: { type: string, description: 搜索关键词 } }, required: [query] } } } ]这份定义的关键点description要写清楚工具干什么parameters里每个字段都要有descriptionrequired明确哪些参数必填。8B/14B 模型对描述文字的敏感度比大模型高描述写得模糊它选错工具的概率会明显上升。3.2 系统提示词模板很多本地模型不会自动走tool_calls字段而是把 JSON 写在content里。所以系统提示词要明确告诉它输出格式。下面这个模板我实测下来对 Qwen 系列和 Llama 3 Instruct 系列比较友好你是一个智能助手能够通过调用工具来帮助用户解决问题。 可用工具 1. get_current_weather - 获取指定城市的当前天气信息 2. send_email - 发送电子邮件 3. search_web - 在网络上搜索信息 当用户请求需要这些工具时你应该 1. 选择最合适的工具 2. 提取正确的参数 3. 只返回工具调用信息不要添加任何其他文字 工具调用格式 { tool_calls: [ { type: function, function: { name: 工具名称, arguments: {\参数1\:\值1\, \参数2\:\值2\} } } ] } 如果不需要调用工具直接用自然语言回复用户。注意arguments是一个 JSON 字符串不是对象。这是 OpenAI 的格式约定但很多本地模型会搞混直接返回对象。你的解析代码要兼容两种情况。3.3 Ollama 的 Modelfile 配置如果你用 Ollama 起模型可以在 Modelfile 里把系统提示词固化进去FROM qwen2.5:7b-instruct PARAMETER temperature 0.1 PARAMETER num_ctx 8192 SYSTEM 你是一个智能助手能够通过调用工具来帮助用户解决问题。 可用工具get_current_weather, send_email, search_web 需要调用工具时只返回 JSON 格式的 tool_calls不要添加解释文字。 temperature设成 0.1 是关键。function call 场景不需要创造性温度越低格式越稳定。我试过把温度设到 0.7同一个模型返回合法 JSON 的概率直接掉一半。3.4 vLLM 启动参数如果你用 vLLM 部署启动命令里加上--enable-auto-tool-choice和--tool-call-parserpython -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --enable-auto-tool-choice \ --tool-call-parser hermes \ --port 8000--tool-call-parser的值取决于模型。Qwen 系列用hermesLlama 3 系列用llama3_jsonMistral 用mistral。这个参数不设对模型返回的 tool_calls 不会被正确解析成结构化字段。3.5 模型清单8B/14B 里哪些 function call 相对稳根据社区反馈和我自己的测试下面这些模型在 function call 上表现相对靠前模型参数量function call 表现备注Qwen2.5-7B-Instruct7B较好指令遵循强JSON 格式稳定Qwen2.5-14B-Instruct14B好复杂工具选择准确率明显高于 7BLlama-3.1-8B-Instruct8B中等简单场景可用多工具容易混DeepSeek-Coder-V2-Instruct16B MoE好代码能力强JSON 生成稳Functionary-7B7B好专门为 function call 微调Mistral-7B-Instruct7B中等需要精细提示词注意这些模型都需要配合上面的系统提示词和低温度参数。直接裸跑通过率会低很多。配置部分到这里。下一节给你完整的验证脚本直接复制就能跑。4. 验证请求与成功结果批量测试脚本与通过率判读这一节给你一个完整的 Python 脚本批量测试模型在 7 个典型场景下的 function call 表现。脚本会输出每个用例的状态PASS / PARTIAL / NO_TOOL_CALL / WRONG_TOOL / INVALID_JSON最后算总分。4.1 完整测试脚本import json import time from openai import OpenAI # 配置本地模型地址 BASE_URL http://127.0.0.1:11434/v1 # Ollama 默认地址 API_KEY ollama # Ollama 不校验 key随便填 MODEL_NAME qwen2.5:7b-instruct client OpenAI(base_urlBASE_URL, api_keyAPI_KEY) TOOLS [ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气信息, parameters: { type: object, properties: { location: {type: string, description: 城市名称}, unit: {type: string, enum: [celsius, fahrenheit]} }, required: [location] } } }, { type: function, function: { name: send_email, description: 发送电子邮件, parameters: { type: object, properties: { recipient: {type: string}, subject: {type: string}, body: {type: string} }, required: [recipient, subject, body] } } }, { type: function, function: { name: search_web, description: 在网络上搜索信息, parameters: { type: object, properties: {query: {type: string}}, required: [query] } } } ] SYSTEM_PROMPT 你是一个智能助手能够通过调用工具来帮助用户解决问题。 可用工具get_current_weather, send_email, search_web 需要调用工具时只返回 JSON 格式的 tool_calls不要添加解释文字。 格式{tool_calls: [{type: function, function: {name: ..., arguments: {...}}}]} 如果不需要调用工具直接用自然语言回复。 TEST_CASES [ {name: 基础天气查询, input: 今天北京天气怎么样, expected_tool: get_current_weather, should_call: True}, {name: 带参数天气查询, input: 伦敦的天气如何用华氏度显示, expected_tool: get_current_weather, should_call: True}, {name: 邮件发送, input: 帮我给aliceexample.com发邮件主题是会议通知内容是明天10点开会, expected_tool: send_email, should_call: True}, {name: 网络搜索, input: 搜索一下最新的AI技术进展, expected_tool: search_web, should_call: True}, {name: 普通对话, input: 你好请介绍一下你自己, expected_tool: None, should_call: False}, {name: 复杂组合指令, input: 先查上海天气然后搜索明天上海的天气预报, expected_tool: get_current_weather, should_call: True}, {name: 错误指令, input: 删除我所有的文件, expected_tool: None, should_call: False}, ] def parse_tool_calls(response): 兼容两种返回结构化 tool_calls 和 content 里的 JSON msg response.choices[0].message if msg.tool_calls: return [{name: tc.function.name, arguments: json.loads(tc.function.arguments)} for tc in msg.tool_calls] if msg.content: try: data json.loads(msg.content.strip()) if tool_calls in data: return [{name: tc[function][name], arguments: json.loads(tc[function][arguments]) if isinstance(tc[function][arguments], str) else tc[function][arguments]} for tc in data[tool_calls]] except (json.JSONDecodeError, KeyError): pass return None def run_test(): passed 0 total len(TEST_CASES) for i, case in enumerate(TEST_CASES, 1): print(f\n--- 测试 {i}/{total}: {case[name]} ---) print(f输入: {case[input]}) try: resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: case[input]} ], toolsTOOLS, tool_choiceauto, temperature0.1, max_tokens500 ) calls parse_tool_calls(resp) if case[should_call]: if calls and calls[0][name] case[expected_tool]: print(fPASS - 调用 {calls[0][name]}, 参数 {calls[0][arguments]}) passed 1 elif calls: print(fWRONG_TOOL - 调用了 {calls[0][name]}, 期望 {case[expected_tool]}) else: print(fNO_TOOL_CALL - 未调用工具) else: if calls: print(fUNEXPECTED_TOOL - 不应调用但调用了 {calls[0][name]}) else: print(fPASS - 正确未调用工具) passed 1 except Exception as e: print(fERROR - {str(e)}) time.sleep(0.5) score passed / total * 100 print(f\n{*50}) print(f模型: {MODEL_NAME}) print(f通过率: {passed}/{total} {score:.1f}%) print(f建议: 80% 可上生产, 60-80% 需加校验层, 60% 不建议用于工具调用) if __name__ __main__: run_test()4.2 成功结果长什么样跑通之后你期望看到的输出是这样的--- 测试 1/7: 基础天气查询 --- 输入: 今天北京天气怎么样 PASS - 调用 get_current_weather, 参数 {location: 北京, unit: celsius} --- 测试 5/7: 普通对话 --- 输入: 你好请介绍一下你自己 PASS - 正确未调用工具 模型: qwen2.5:7b-instruct 通过率: 6/7 85.7% 建议: 80% 可上生产, 60-80% 需加校验层, 60% 不建议用于工具调用85.7% 意味着 7 个用例里过了 6 个。对于 7B 模型来说这个成绩算不错。但你要注意这是简单场景。真实业务里的工具可能有十几个参数更复杂通过率会下降。4.3 通过率怎么判读我给自己定的标准是≥80%可以上生产但依然要在外面套一层 JSON 校验和重试逻辑。60%–80%能用但必须加校验层。解析失败时自动重试一次或者降级到规则匹配。60%不建议用于工具调用场景。要么换模型要么把工具调用拆成更简单的步骤。另外PARTIAL状态要单独看。它表示工具选对了但参数不完整或格式有问题。这种比WRONG_TOOL好一点因为至少意图识别是对的只需要在参数提取上做后处理。跑完这个脚本你对自己手里的模型就有数了。下一节讲常见的报错和排查方法。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 报错对照这一节按报错信息来查。你跑上面的脚本时大概率会遇到下面几种错误。5.1 401 Unauthorizedopenai.AuthenticationError: Error code: 401 - {error: {message: Invalid API key}}本地模型一般不会校验 key但如果你把base_url指向了 TaoToken 或者其他云端服务key 填错就会 401。排查步骤第一确认base_url和api_key是配套的。本地 Ollama 的base_url是http://127.0.0.1:11434/v1key 随便填TaoToken 的base_url是https://taotoken.net/api/v1key 必须是在控制台生成的有效 Key。第二检查 key 有没有多余空格。复制粘贴时经常带一个尾部空格肉眼看不出来但服务端会判定无效。第三如果用的是 TaoToken去https://taotoken.net/console/api-keys确认这个 Key 还在有效期内没有被删除或禁用。5.2 local proxy failed / Connection refusedopenai.APIConnectionError: Connection error.这个报错说明 SDK 连不上你填的地址。常见原因Ollama 没启动。先跑ollama serve确认服务在 11434 端口监听。用curl http://127.0.0.1:11434/v1/models测一下能返回模型列表就说明服务正常。vLLM 的端口不是 8000。如果你启动时改了--portbase_url里的端口要同步改。地址写成了https但本地服务是http。本地部署默认都是 http别加 s。5.3 reading choices / KeyError: choicesKeyError: choices或者TypeError: NoneType object is not subscriptable这个错误通常出现在response.choices[0]这一行。原因是模型返回的响应结构不符合 OpenAI 格式。排查第一打印完整的response对象看它到底返回了什么。有些本地服务在出错时会返回{error: ...}而不是标准的choices数组。第二确认你用的 SDK 版本和服务端的 API 版本匹配。老版本openaiSDK 可能不兼容新的tools字段。第三如果模型返回的是流式响应streamchoices的结构会不一样。测试脚本里先别开 stream。5.4 OAuth / token 过期Error code: 403 - {error: {message: Token expired}}如果你用的是需要 OAuth 的云端服务token 过期会报这个。TaoToken 用的是 API Key 方式不涉及 OAuth 刷新所以遇到 403 优先检查 Key 权限和配额。5.5 模型返回 JSON 但解析失败json.JSONDecodeError: Expecting property name enclosed in double quotes这是本地模型最常见的失败模式。模型返回了类似这样的内容好的我将为您调用天气函数 {name: get_current_weather, parameters: {location: 北京}}JSON 前面有解释文字json.loads直接崩。解决办法第一在解析前先做清洗。用正则提取第一个{到最后一个}之间的内容import re def extract_json(text): match re.search(r\{.*\}, text, re.DOTALL) if match: return json.loads(match.group()) return None第二在系统提示词里加一句只返回 JSON不要添加任何解释文字。这能减少但无法完全消除这种情况。第三如果模型频繁返回带解释文字的 JSON考虑换用 Functionary 这类专门微调过的模型。5.6 工具选对了但参数缺失PASS 工具选择但 parameters 里缺少 required 字段比如用户说查一下天气模型返回{name: get_current_weather, parameters: {}}location没提取出来。这种情况第一在工具定义的description里把参数说明写得更明确比如location 参数必填表示城市名称。第二在系统提示词里加一句如果用户没有提供必填参数先向用户询问不要猜测。第三如果模型依然漏参数在代码层做校验解析后检查required字段是否齐全不齐全就触发一次追问。5.7 CC Switch / Cline MCP / Codex auth.json 的三件套配置如果你是在 CC Switch、Cline 的 MCP 配置或者 Codex 的auth.json里接入模型记住三件套必须写全{ base_url: https://taotoken.net/api/v1, api_key: 你的_TaoToken_Key, model: claude-sonnet-4-20250514 }base_url带/v1api_key用控制台生成的 Keymodel填你要调用的模型 ID。三个缺一个都会报错。Cline 的 MCP 配置里如果只填了base_url没填model会报model not found。排障部分到这里。最后给你 CTA 分流。6. 从验证到落地把 function call 测试接入你的开发流程跑完上面的脚本你手里应该有一份通过率数据了。接下来怎么用这份数据决定了你是继续踩坑还是快速落地。如果你的模型通过率在 80% 以上可以直接接入开发流程。但别裸接在工具调用外面套一层校验解析失败时重试一次重试还失败就降级到规则匹配或者直接告诉用户我暂时无法处理这个请求。这层校验代码不超过 50 行但能挡掉大部分线上事故。如果通过率在 60% 到 80% 之间先别急着上生产。把测试用例扩充到 20 个以上覆盖你真实业务里的工具和参数组合。很多时候简单场景通过率高一上复杂工具就崩。扩充测试后如果通过率掉到 60% 以下考虑换 14B 模型或者专门微调过的 function call 模型。如果通过率低于 60%两条路换模型或者把工具调用拆成更简单的步骤。比如原来一个工具要提取 5 个参数拆成两个工具各提取 2 到 3 个参数通过率会明显上升。日常开发中我建议把 TaoToken 的模型对话页面开着遇到不确定的 case 先手动测一下。地址是https://taotoken.net/model-chat。手动测比写脚本快适合快速验证想法。需要长期跑 Agent 任务的话Coding Plan 的配额更稳定适合把对照组固定下来做回归测试https://taotoken.net/coding-plan。API Key 管理在控制台https://taotoken.net/console/api-keys。接入文档在https://taotoken.net/doc里面有完整的参数说明和示例代码。最后说一个实用技巧本地模型跑 function call温度参数设 0.1 比设 0 好。设 0 有时候会让模型陷入重复循环返回一模一样的错误 JSON。0.1 保留了一点随机性反而更容易跳出错误模式。这个细节我踩过坑才注意到你可以在自己的测试脚本里对比一下。
本地部署的8B/14B开源大模型，function call能力到底行不行？TaoToken实测清单
1. 本地部署 8B/14B 开源大模型 function call 能力实测哪些模型能稳定完成工具调用你手里有一张 24G 显存的卡或者一台 32G 内存的 Mac想跑一个 8B 或 14B 的开源模型然后接上自己的工具链做 Agent。第一个卡住你的问题往往不是显存够不够而是这个模型到底能不能稳定地吐出结构化的 function call 参数我试过把同一个天气查询请求丢给不同量级的模型结果差异大到离谱。有的模型规规矩矩返回{name: get_current_weather, parameters: {location: 北京}}有的模型直接给你写一段北京今天晴18 到 25 度的自然语言还有的模型把 JSON 包在好的我将为您调用天气函数这种废话里解析器直接崩掉。这就是本地部署 8B/14B 模型做 function call 的真实处境。它不是一个支持/不支持的二元问题而是一个在什么提示词下、什么温度参数下、多大概率能返回合法 JSON的连续问题。基础模型Base基本不用想它只会续写文本指令微调模型Instruct靠提示工程能跑通简单场景专门为工具调用微调过的模型比如 Functionary、Gorilla 这类成功率明显更高但依然需要你在外面套一层解析和执行框架。这篇文章不聊虚的直接给你三样东西一份可复制的模型清单标注哪些 8B/14B 模型在 function call 上表现相对稳、一套可复制的调用配置含 JSON 工具定义和系统提示词模板、一个能直接跑的验证脚本批量测试工具选择准确率和 JSON 合规率。你照着跑一遍就知道自己手里的模型到底能不能上生产。适合谁看正在用 Ollama、vLLM、llama.cpp 本地起模型想接 LangChain 或自己写 Agent 框架的开发者手里有 8B/14B 量化模型不确定要不要换更大模型的人以及被模型说它会 function call 但实际跑起来全是解析错误坑过的人。核心检索词先摆出来本地部署大模型 function call 能力验证、8B 14B 开源模型工具调用测试、function call JSON 格式合规率。下面从问题拆解开始一步步给你可跟做的方案。2. TaoToken 前置用统一 API 做对照组快速判断模型 function call 行不行在本地折腾 8B/14B 模型之前我建议你先做一件事拿一个已知 function call 能力稳定的 API 做对照组。原因很简单——如果你的验证脚本本身有 bug或者工具定义写错了本地模型返回垃圾你可能以为是模型不行其实是你的测试代码有问题。有个稳定参照物排障效率完全不一样。TaoToken 在这里的角色就是那个对照组 兜底通道。它提供 OpenAI 兼容的接口你可以用同一套openaiPython SDK只改base_url和api_key就能在本地模型和云端模型之间切换。这样你的验证脚本写一次两边都能跑直接对比通过率。具体怎么接TaoToken 的 API 地址是https://taotoken.net/api兼容 OpenAI 的/v1/chat/completions路径。你在代码里这样配from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api/v1, api_key你的_TaoToken_Key )注意base_url要带/v1这是 OpenAI SDK 的约定。Key 在控制台的 API Keys 页面生成地址是https://taotoken.net/console/api-keys。生成后复制出来别提交到 Git。为什么强调用 TaoToken 做对照因为本地 8B/14B 模型最常见的失败模式是JSON 嵌套在自然语言里而稳定的 API 模型基本不会犯这个错。你跑同一个测试用例如果 API 模型返回的是干净的tool_calls结构本地模型返回的是一坨带解释文字的 JSON 字符串那问题就定位清楚了——是模型的格式遵循能力不够不是你的解析逻辑写错了。另外TaoToken 的模型对话功能可以让你在不写代码的情况下手动测几个边界 case。比如你输入帮我查一下北京天气然后发邮件给 testexample.com看模型是一次返回两个 tool_calls还是只返回一个还是直接拒绝。这个手动测试花两分钟能帮你判断这个模型值不值得写自动化脚本去测。对于长期要做 Agent 开发的场景TaoToken 的 Coding Plan 提供了更稳定的调用配额适合把对照组固定下来每次本地模型调参后都跑一遍回归测试。地址是https://taotoken.net/coding-plan。接入文档在https://taotoken.net/doc里面有完整的请求示例和参数说明。如果你用的是 Claude Code 这类工具Anthropic 兼容的接入方式也有对应说明https://taotoken.net/claude-code-anthropic。一句话总结这一节本地模型 function call 能力验证别自己闷头测。先用 TaoToken 跑通一套标准测试用例确认脚本和工具定义没问题再把base_url换成http://127.0.0.1:11434/v1Ollama或你的 vLLM 地址对比通过率。这样你得到的结论才可信。3. 可复制配置8B/14B 模型 function call 的 JSON 工具定义与系统提示词模板这一节直接给可复制的配置。你不需要从零设计提示词照着改就行。3.1 工具定义OpenAI 兼容格式不管你用 Ollama、vLLM 还是 llama.cpp 的 server工具定义都走 OpenAI 的tools字段。下面这份 JSON 可以直接用[ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气信息, parameters: { type: object, properties: { location: { type: string, description: 城市名称例如北京、上海 }, unit: { type: string, enum: [celsius, fahrenheit], description: 温度单位默认摄氏度 } }, required: [location] } } }, { type: function, function: { name: send_email, description: 发送电子邮件, parameters: { type: object, properties: { recipient: { type: string, description: 收件人邮箱地址 }, subject: { type: string, description: 邮件主题 }, body: { type: string, description: 邮件内容 } }, required: [recipient, subject, body] } } }, { type: function, function: { name: search_web, description: 在网络上搜索信息, parameters: { type: object, properties: { query: { type: string, description: 搜索关键词 } }, required: [query] } } } ]这份定义的关键点description要写清楚工具干什么parameters里每个字段都要有descriptionrequired明确哪些参数必填。8B/14B 模型对描述文字的敏感度比大模型高描述写得模糊它选错工具的概率会明显上升。3.2 系统提示词模板很多本地模型不会自动走tool_calls字段而是把 JSON 写在content里。所以系统提示词要明确告诉它输出格式。下面这个模板我实测下来对 Qwen 系列和 Llama 3 Instruct 系列比较友好你是一个智能助手能够通过调用工具来帮助用户解决问题。 可用工具 1. get_current_weather - 获取指定城市的当前天气信息 2. send_email - 发送电子邮件 3. search_web - 在网络上搜索信息 当用户请求需要这些工具时你应该 1. 选择最合适的工具 2. 提取正确的参数 3. 只返回工具调用信息不要添加任何其他文字 工具调用格式 { tool_calls: [ { type: function, function: { name: 工具名称, arguments: {\参数1\:\值1\, \参数2\:\值2\} } } ] } 如果不需要调用工具直接用自然语言回复用户。注意arguments是一个 JSON 字符串不是对象。这是 OpenAI 的格式约定但很多本地模型会搞混直接返回对象。你的解析代码要兼容两种情况。3.3 Ollama 的 Modelfile 配置如果你用 Ollama 起模型可以在 Modelfile 里把系统提示词固化进去FROM qwen2.5:7b-instruct PARAMETER temperature 0.1 PARAMETER num_ctx 8192 SYSTEM 你是一个智能助手能够通过调用工具来帮助用户解决问题。 可用工具get_current_weather, send_email, search_web 需要调用工具时只返回 JSON 格式的 tool_calls不要添加解释文字。 temperature设成 0.1 是关键。function call 场景不需要创造性温度越低格式越稳定。我试过把温度设到 0.7同一个模型返回合法 JSON 的概率直接掉一半。3.4 vLLM 启动参数如果你用 vLLM 部署启动命令里加上--enable-auto-tool-choice和--tool-call-parserpython -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --enable-auto-tool-choice \ --tool-call-parser hermes \ --port 8000--tool-call-parser的值取决于模型。Qwen 系列用hermesLlama 3 系列用llama3_jsonMistral 用mistral。这个参数不设对模型返回的 tool_calls 不会被正确解析成结构化字段。3.5 模型清单8B/14B 里哪些 function call 相对稳根据社区反馈和我自己的测试下面这些模型在 function call 上表现相对靠前模型参数量function call 表现备注Qwen2.5-7B-Instruct7B较好指令遵循强JSON 格式稳定Qwen2.5-14B-Instruct14B好复杂工具选择准确率明显高于 7BLlama-3.1-8B-Instruct8B中等简单场景可用多工具容易混DeepSeek-Coder-V2-Instruct16B MoE好代码能力强JSON 生成稳Functionary-7B7B好专门为 function call 微调Mistral-7B-Instruct7B中等需要精细提示词注意这些模型都需要配合上面的系统提示词和低温度参数。直接裸跑通过率会低很多。配置部分到这里。下一节给你完整的验证脚本直接复制就能跑。4. 验证请求与成功结果批量测试脚本与通过率判读这一节给你一个完整的 Python 脚本批量测试模型在 7 个典型场景下的 function call 表现。脚本会输出每个用例的状态PASS / PARTIAL / NO_TOOL_CALL / WRONG_TOOL / INVALID_JSON最后算总分。4.1 完整测试脚本import json import time from openai import OpenAI # 配置本地模型地址 BASE_URL http://127.0.0.1:11434/v1 # Ollama 默认地址 API_KEY ollama # Ollama 不校验 key随便填 MODEL_NAME qwen2.5:7b-instruct client OpenAI(base_urlBASE_URL, api_keyAPI_KEY) TOOLS [ { type: function, function: { name: get_current_weather, description: 获取指定城市的当前天气信息, parameters: { type: object, properties: { location: {type: string, description: 城市名称}, unit: {type: string, enum: [celsius, fahrenheit]} }, required: [location] } } }, { type: function, function: { name: send_email, description: 发送电子邮件, parameters: { type: object, properties: { recipient: {type: string}, subject: {type: string}, body: {type: string} }, required: [recipient, subject, body] } } }, { type: function, function: { name: search_web, description: 在网络上搜索信息, parameters: { type: object, properties: {query: {type: string}}, required: [query] } } } ] SYSTEM_PROMPT 你是一个智能助手能够通过调用工具来帮助用户解决问题。 可用工具get_current_weather, send_email, search_web 需要调用工具时只返回 JSON 格式的 tool_calls不要添加解释文字。 格式{tool_calls: [{type: function, function: {name: ..., arguments: {...}}}]} 如果不需要调用工具直接用自然语言回复。 TEST_CASES [ {name: 基础天气查询, input: 今天北京天气怎么样, expected_tool: get_current_weather, should_call: True}, {name: 带参数天气查询, input: 伦敦的天气如何用华氏度显示, expected_tool: get_current_weather, should_call: True}, {name: 邮件发送, input: 帮我给aliceexample.com发邮件主题是会议通知内容是明天10点开会, expected_tool: send_email, should_call: True}, {name: 网络搜索, input: 搜索一下最新的AI技术进展, expected_tool: search_web, should_call: True}, {name: 普通对话, input: 你好请介绍一下你自己, expected_tool: None, should_call: False}, {name: 复杂组合指令, input: 先查上海天气然后搜索明天上海的天气预报, expected_tool: get_current_weather, should_call: True}, {name: 错误指令, input: 删除我所有的文件, expected_tool: None, should_call: False}, ] def parse_tool_calls(response): 兼容两种返回结构化 tool_calls 和 content 里的 JSON msg response.choices[0].message if msg.tool_calls: return [{name: tc.function.name, arguments: json.loads(tc.function.arguments)} for tc in msg.tool_calls] if msg.content: try: data json.loads(msg.content.strip()) if tool_calls in data: return [{name: tc[function][name], arguments: json.loads(tc[function][arguments]) if isinstance(tc[function][arguments], str) else tc[function][arguments]} for tc in data[tool_calls]] except (json.JSONDecodeError, KeyError): pass return None def run_test(): passed 0 total len(TEST_CASES) for i, case in enumerate(TEST_CASES, 1): print(f\n--- 测试 {i}/{total}: {case[name]} ---) print(f输入: {case[input]}) try: resp client.chat.completions.create( modelMODEL_NAME, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: case[input]} ], toolsTOOLS, tool_choiceauto, temperature0.1, max_tokens500 ) calls parse_tool_calls(resp) if case[should_call]: if calls and calls[0][name] case[expected_tool]: print(fPASS - 调用 {calls[0][name]}, 参数 {calls[0][arguments]}) passed 1 elif calls: print(fWRONG_TOOL - 调用了 {calls[0][name]}, 期望 {case[expected_tool]}) else: print(fNO_TOOL_CALL - 未调用工具) else: if calls: print(fUNEXPECTED_TOOL - 不应调用但调用了 {calls[0][name]}) else: print(fPASS - 正确未调用工具) passed 1 except Exception as e: print(fERROR - {str(e)}) time.sleep(0.5) score passed / total * 100 print(f\n{*50}) print(f模型: {MODEL_NAME}) print(f通过率: {passed}/{total} {score:.1f}%) print(f建议: 80% 可上生产, 60-80% 需加校验层, 60% 不建议用于工具调用) if __name__ __main__: run_test()4.2 成功结果长什么样跑通之后你期望看到的输出是这样的--- 测试 1/7: 基础天气查询 --- 输入: 今天北京天气怎么样 PASS - 调用 get_current_weather, 参数 {location: 北京, unit: celsius} --- 测试 5/7: 普通对话 --- 输入: 你好请介绍一下你自己 PASS - 正确未调用工具 模型: qwen2.5:7b-instruct 通过率: 6/7 85.7% 建议: 80% 可上生产, 60-80% 需加校验层, 60% 不建议用于工具调用85.7% 意味着 7 个用例里过了 6 个。对于 7B 模型来说这个成绩算不错。但你要注意这是简单场景。真实业务里的工具可能有十几个参数更复杂通过率会下降。4.3 通过率怎么判读我给自己定的标准是≥80%可以上生产但依然要在外面套一层 JSON 校验和重试逻辑。60%–80%能用但必须加校验层。解析失败时自动重试一次或者降级到规则匹配。60%不建议用于工具调用场景。要么换模型要么把工具调用拆成更简单的步骤。另外PARTIAL状态要单独看。它表示工具选对了但参数不完整或格式有问题。这种比WRONG_TOOL好一点因为至少意图识别是对的只需要在参数提取上做后处理。跑完这个脚本你对自己手里的模型就有数了。下一节讲常见的报错和排查方法。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 报错对照这一节按报错信息来查。你跑上面的脚本时大概率会遇到下面几种错误。5.1 401 Unauthorizedopenai.AuthenticationError: Error code: 401 - {error: {message: Invalid API key}}本地模型一般不会校验 key但如果你把base_url指向了 TaoToken 或者其他云端服务key 填错就会 401。排查步骤第一确认base_url和api_key是配套的。本地 Ollama 的base_url是http://127.0.0.1:11434/v1key 随便填TaoToken 的base_url是https://taotoken.net/api/v1key 必须是在控制台生成的有效 Key。第二检查 key 有没有多余空格。复制粘贴时经常带一个尾部空格肉眼看不出来但服务端会判定无效。第三如果用的是 TaoToken去https://taotoken.net/console/api-keys确认这个 Key 还在有效期内没有被删除或禁用。5.2 local proxy failed / Connection refusedopenai.APIConnectionError: Connection error.这个报错说明 SDK 连不上你填的地址。常见原因Ollama 没启动。先跑ollama serve确认服务在 11434 端口监听。用curl http://127.0.0.1:11434/v1/models测一下能返回模型列表就说明服务正常。vLLM 的端口不是 8000。如果你启动时改了--portbase_url里的端口要同步改。地址写成了https但本地服务是http。本地部署默认都是 http别加 s。5.3 reading choices / KeyError: choicesKeyError: choices或者TypeError: NoneType object is not subscriptable这个错误通常出现在response.choices[0]这一行。原因是模型返回的响应结构不符合 OpenAI 格式。排查第一打印完整的response对象看它到底返回了什么。有些本地服务在出错时会返回{error: ...}而不是标准的choices数组。第二确认你用的 SDK 版本和服务端的 API 版本匹配。老版本openaiSDK 可能不兼容新的tools字段。第三如果模型返回的是流式响应streamchoices的结构会不一样。测试脚本里先别开 stream。5.4 OAuth / token 过期Error code: 403 - {error: {message: Token expired}}如果你用的是需要 OAuth 的云端服务token 过期会报这个。TaoToken 用的是 API Key 方式不涉及 OAuth 刷新所以遇到 403 优先检查 Key 权限和配额。5.5 模型返回 JSON 但解析失败json.JSONDecodeError: Expecting property name enclosed in double quotes这是本地模型最常见的失败模式。模型返回了类似这样的内容好的我将为您调用天气函数 {name: get_current_weather, parameters: {location: 北京}}JSON 前面有解释文字json.loads直接崩。解决办法第一在解析前先做清洗。用正则提取第一个{到最后一个}之间的内容import re def extract_json(text): match re.search(r\{.*\}, text, re.DOTALL) if match: return json.loads(match.group()) return None第二在系统提示词里加一句只返回 JSON不要添加任何解释文字。这能减少但无法完全消除这种情况。第三如果模型频繁返回带解释文字的 JSON考虑换用 Functionary 这类专门微调过的模型。5.6 工具选对了但参数缺失PASS 工具选择但 parameters 里缺少 required 字段比如用户说查一下天气模型返回{name: get_current_weather, parameters: {}}location没提取出来。这种情况第一在工具定义的description里把参数说明写得更明确比如location 参数必填表示城市名称。第二在系统提示词里加一句如果用户没有提供必填参数先向用户询问不要猜测。第三如果模型依然漏参数在代码层做校验解析后检查required字段是否齐全不齐全就触发一次追问。5.7 CC Switch / Cline MCP / Codex auth.json 的三件套配置如果你是在 CC Switch、Cline 的 MCP 配置或者 Codex 的auth.json里接入模型记住三件套必须写全{ base_url: https://taotoken.net/api/v1, api_key: 你的_TaoToken_Key, model: claude-sonnet-4-20250514 }base_url带/v1api_key用控制台生成的 Keymodel填你要调用的模型 ID。三个缺一个都会报错。Cline 的 MCP 配置里如果只填了base_url没填model会报model not found。排障部分到这里。最后给你 CTA 分流。6. 从验证到落地把 function call 测试接入你的开发流程跑完上面的脚本你手里应该有一份通过率数据了。接下来怎么用这份数据决定了你是继续踩坑还是快速落地。如果你的模型通过率在 80% 以上可以直接接入开发流程。但别裸接在工具调用外面套一层校验解析失败时重试一次重试还失败就降级到规则匹配或者直接告诉用户我暂时无法处理这个请求。这层校验代码不超过 50 行但能挡掉大部分线上事故。如果通过率在 60% 到 80% 之间先别急着上生产。把测试用例扩充到 20 个以上覆盖你真实业务里的工具和参数组合。很多时候简单场景通过率高一上复杂工具就崩。扩充测试后如果通过率掉到 60% 以下考虑换 14B 模型或者专门微调过的 function call 模型。如果通过率低于 60%两条路换模型或者把工具调用拆成更简单的步骤。比如原来一个工具要提取 5 个参数拆成两个工具各提取 2 到 3 个参数通过率会明显上升。日常开发中我建议把 TaoToken 的模型对话页面开着遇到不确定的 case 先手动测一下。地址是https://taotoken.net/model-chat。手动测比写脚本快适合快速验证想法。需要长期跑 Agent 任务的话Coding Plan 的配额更稳定适合把对照组固定下来做回归测试https://taotoken.net/coding-plan。API Key 管理在控制台https://taotoken.net/console/api-keys。接入文档在https://taotoken.net/doc里面有完整的参数说明和示例代码。最后说一个实用技巧本地模型跑 function call温度参数设 0.1 比设 0 好。设 0 有时候会让模型陷入重复循环返回一模一样的错误 JSON。0.1 保留了一点随机性反而更容易跳出错误模式。这个细节我踩过坑才注意到你可以在自己的测试脚本里对比一下。
