Llama3在启用工具调用后出现“有问必调用”的行为——即使提问“你是谁？”也强制生成JSON格式的函数调用，根本原因在于模型未经过工具调用专项微调，且chat template中tools参数被错误地全局激活，导致推理时始终将用户输入视为需工具响应的指令。
llama3在启用工具调用后出现“有问必调用”的行为——即使提问“你是谁？”也强制生成json格式的函数调用，根本原因在于模型未经过工具调用专项微调，且chat template中`tools`参数被错误地全局激活，导致推理时始终将用户输入视为需工具响应的指令。
这是当前本地部署Llama3实现Function Calling时最典型的误用陷阱：把“支持工具调用的接口能力”等同于“具备工具调用决策能力的模型”。实际上，原生Llama3-1B-Instruct（或8B/70B标准版）完全不理解工具调用协议——它既没有在训练阶段学习过{"name": "get_weather", "arguments": "{...}"}这类结构化输出格式，也没有被微调以判断“何时该调用工具、何时该直接回答”。
你代码中的关键问题在于这一行：
inputs = tokenizer.apply_chat_template(messages, tools=tools, add_generation_prompt=True, ...)
tokenizer.apply_chat_template(..., tools=tools) 是 Hugging Face transformers 库为已适配工具调用的模型（如 Llama-3-Groq-8B-Tool-Use、Octopus、或经Modelfile定制的llama3.2-tools）提供的专用模板注入逻辑。但你的模型 Llama-3.2-1B-Instruct 并非此类模型——它没有被微调支持工具调用，其分词器也未定义tools字段的渲染规则。结果就是：apply_chat_template 强行将工具描述拼入system prompt，却未同步注入对应的引导性系统指令（如“You MUST ONLY output a JSON object with 'name' and 'arguments' if the user asks for real-time or computational info…”），更缺乏微调带来的格式约束能力。模型在困惑中“妥协”为：只要看到tools存在，就一律尝试生成工具调用。
✅ 正确路径分三步走：
-
换用真正支持工具调用的模型
推荐两个开箱即用选项：- ✅ Ollama生态：构建带工具能力的变体
echo -e 'FROM llama3.2:3b\nPARAMETER num_ctx 32768\nSYSTEM "You are a helpful AI assistant that can call functions. Only call a function when explicitly requested or when the question requires real-time data, calculation, or external action. Otherwise, answer directly in natural language."\nTEMPLATE """{{.System}}\n{{.Prompt}}"""' > llama3-tools.Modelfile ollama create llama3.2-tools -f llama3-tools.Modelfile ollama run llama3.2-tools "Who are you?" # → 自然语言回答 ollama run llama3.2-tools "What's the weather in Tokyo?" # → JSON工具调用 - ✅ Hugging Face GGUF模型：直接下载已微调版本
如Llama-3-Groq-8B-Tool-Use-Q5_K_M.gguf—— 它内置了groq-llama3-tool提示模板与格式约束头，可配合llama-cpp-python安全使用。
- ✅ Ollama生态：构建带工具能力的变体
-
严格分离“工具调用请求”与“普通对话”逻辑
即使使用正确模型，也不应无条件传入tools=参数。推荐模式：# Step 1: 先用纯自然语言prompt询问（不带tools） messages_plain = [{"role": "user", "content": "Who are you?"}] inputs_plain = tokenizer.apply_chat_template(messages_plain, add_generation_prompt=True, return_tensors="pt") # Step 2: 模型输出后，由Orchestrator（如LangChain/LangGraph）解析是否含工具调用意图 # 若检测到JSON结构 → 提取并执行工具 → 将结果作为新message喂回模型 # 若为纯文本 → 直接返回给用户 永远记住：LLM从不真正“调用”工具
这是核心认知边界。模型仅负责生成符合协议的字符串（如{"name":"get_temperature","arguments":"{\"location\":\"Paris\",\"unit\":\"celsius\"}"}），真正的HTTP请求、数据库查询、代码执行，必须由你编写的应用层调度器（Orchestrator）完成。LangChain的ToolNode、LlamaIndex的FunctionCallingAgentWorker、或自研的if-elif-else工具路由逻辑，才是让AI“行动”起来的关键。
⚠️ 注意事项：
- 不要对
llama3.2:3b等基础镜像强行注入tools=参数——这会破坏其原始指令遵循能力；- 避免在system prompt中同时要求“友好回答”和“强制JSON输出”，二者逻辑冲突；
- 本地测试时，优先用
ollama run验证模型行为，再集成到Python pipeline；- 工具调用不是功能开关，而是模型能力+提示工程+应用架构三位一体的工程实践。
工具调用的本质，是赋予LLM“决策权”而非“执行权”。当你的模型开始对每个问题都输出{"name":...}，请先检查它是否真的被教会了“何时沉默，何时开口”。
