用 llama.cpp 与 GGUF 搭建本地 Function Calling 网关：从量化、提示模板到边缘部署
前言：为什么要把工具调用放到本地 过去两年，很多团队在做 AI 应用时都会先接一个云端大模型 API：把用户问题发出去，拿回一段文本，再在业务系统里解析。这个方案上手快，但一旦进入现场环境，问题很快就会浮出来：工厂内网不能直接访问公网，设备日志里可能含有客户数据，弱网场景下延迟不稳定，云端调用成本也不容易预估。更麻烦的是，一些“看起来只是聊天”的需求，本质上并不是聊天，而是让模型根据自然语言选择工具、填好参数、调用接口、再把结果解释给用户。比如“帮我查一下 3 号产线最近 10 分钟的温度异常”，模型需要决定调用 query_metric，参数包含产线编号、时间窗口和指标名；再比如“把这台边缘网关切到低功耗模式”，模型需要识别这是一个有副作用的动作，必须做权限确认和参数校验。 这类场景如果完全依赖云端，系统链路会变长，失败点会变多。相反，如果把小到中等规模的语言模型以 GGUF 格式部署在本地，通过 llama.cpp 提供推理服务，再在旁边放一个严格的 Function Calling 网关，就能得到一个更可控的架构：模型负责“理解意图”和“生成结构化调用计划”，网关负责“验证、授权、执行、审计”。这种分工非常适合工控边缘盒子、门店私有服务器、实验室内网助手、个人知识库一体机等场景。 本文不是简单介绍如何运行 ./llama-cli -m model.gguf，而是围绕一个可落地的本地工具调用网关展开：如何选择模型和量化格式，如何设计提示模板让模型稳定输出 JSON，如何用 Python 写一个流式调用编排器，如何处理超时、重试、权限和审计，最后如何把它部署到一台资源有限的边缘设备上。文章中的代码尽量保持小而完整，方便你按自己的业务接口替换。 一、整体架构：模型不要直接碰业务系统 一个常见误区是：既然模型可以生成函数名和参数，那就让模型输出什么就执行什么。这个做法在演示里很顺，但在生产环境里非常危险。语言模型是概率系统，它可能拼错函数名，可能把用户随口说的一句话理解成执行命令，也可能在上下文受到污染时生成越权参数。正确的做法是把模型放在“建议者”的位置，业务网关才是“裁判”和“执行者”。 本文采用的架构由五层组成： 客户端层：Web UI、命令行、企业微信机器人、串口控制台都可以作为入口。它们只负责收集用户输入和展示结果。 会话编排层：维护上下文、拼接系统提示词、把可用工具列表注入给模型，并解析模型输出。 本地推理层：llama.cpp 或 llama-server 加载 GGUF 模型，提供 OpenAI 兼容接口或原生命令行接口。 工具安全层：根据白名单、参数 schema、用户权限、二次确认规则决定是否允许执行。 业务适配层：真正访问数据库、设备驱动、HTTP API、MQTT、Modbus、文件系统等外部资源。 这个拆分的关键点是：模型输出永远只是“候选动作”，不能直接等价于“已授权动作”。即使模型说要调用 set_relay_state(channel=1, state="on")，网关也要检查当前用户是否有控制继电器的权限，channel 是否在允许范围内，动作是否需要二次确认，执行结果是否要写审计日志。 下面是最小化的工具描述格式。它不依赖某个云厂商的 Function Calling 协议，但足够表达函数名、用途、参数类型和安全属性。 { "name": "query_metric", "description": "查询某条产线或设备在指定时间窗口内的指标数据", "side_effect": false, "parameters": { "type": "object", "required": ["device", "metric", "window_minutes"], "properties": { "device": {"type": "string", "description": "设备或产线编号，例如 line-3"}, "metric": {"type": "string", "enum": ["temperature", "humidity", "current"]}, "window_minutes": {"type": "integer", "minimum": 1, "maximum": 1440} } } } 这里的 side_effect 很重要。查询类工具通常可以直接执行，控制类、写入类、删除类工具则应默认要求确认。很多事故不是模型“不聪明”，而是系统把模型的建议当成了不可质疑的命令。...