这两年我一直在琢磨一件事手机里的语音助手到底什么时候才能真的“干点活”。你说“帮我把相册里重复的照片删掉”它回你一句“好的我帮你删掉重复照片”然后就没有然后了。问题不出在对话理解上而在于模型压根没有“动作出口”——它只学会了说话没学会调工具。这正是函数调用Function Calling要解决的问题也是端侧智能体从“对话”迈向“行动”的分水岭。我最近认真摸了一遍 FunctionGemma把这套思路从模型加载、单次调用到自主循环全部跑通之后有一些非常想分享的体会。这篇文章不是什么官方教程的复述而是一个“一个人从零摸到能跑”的全过程包括踩坑、取舍和那些文档里不会写的东西。适合刚接触端侧智能体的人也适合已经在做工具调用但总觉得哪里别扭的人。1. 对话模型为什么“指哪打哪”却“动不了手”——从聊天到执行的断层1.1 你眼里的一句话在模型那里是两道完全不同的工序先打一个比方。传统对话模型像是一个很会聊天但从不站起来的顾问你问他“我饿了怎么办”他能给你讲十分钟营养学但他不会走进厨房。而一个具备函数调用能力的智能体像是一个训练有素的助理你刚说完“帮我订个明天上午的会议室”他就掏出通讯录开始拨号。这两者的差别不在“谁更聪明”而在于模型的输出形态。对话模型的输出是自然语言无论它怎么理解你的意图最终产出的都是“文本”而文本本身不能触达系统里的任何真实操作。函数调用模型则多了一个能力在需要执行动作时输出一段结构化数据——比如一个函数名加一组参数。这段数据可以被程序解析然后真正去调用接口、开关设备、查询数据库。FunctionGemma 这类模型走的正是第二条路。它本身不做具体的事它只负责一件事把你的指令翻译成“该调用哪个函数、传什么参数”然后由外围程序执行。理解与执行由此被焊接在一起这才是“智能体”这个概念真正落地的地方。1.2 行动能力的最小闭环请求、决策、调用、反馈如果只用一个最小模型来描述端侧智能体的工作方式它是四步循环请求用户说出一句话比如“把客厅温度调到24度”。决策模型判断这句话需要触发哪个工具并输出结构化的调用指令。执行外围程序解析指令真正调用“调温度”的接口。反馈接口返回结果模型再根据结果组织下一步动作或回复用户。这四步看起来简单但每一步都有讲究。尤其后面我会提到工程上最容易被忽视的是“反馈”这一步——很多第一次做智能体的人把模型输出解析完、工具调用成功就收工了结果发现多轮对话时模型完全不记得刚才干了什么。原因就是没有把工具执行的返回值写回下一轮输入。1.3 FunctionGemma 到底解决的是哪一段市面上已经有不少通用大模型也能在提示词里塞几个函数定义勉强输出 JSON。但通用模型做函数调用有一个天然短板它在训练时没见过海量“具体函数签名与语义”的配对样本所以对“参数名、类型、取值边界”的敏感度不够。你让它输出一个“日期格式为 YYYY-MM-DD 的字符串”它可能输出“2024年11月3日”。FunctionGemma 这批模型是在针对函数调用做了专门指令微调之后发布的。它的核心卖点不是“更大”而是“更专”——在函数签名的理解、参数抽取、工具选择这棵树上反复打磨过。后面我会给出实测时它在“参数类型边界”上比通用模型明显更稳的观察。2. 选型背后的关键考量为什么端侧智能体更需要“专训函数调用”的小模型2.1 通用模型做工具调用的四宗罪我在 FunctionGemma 之前用通用模型做过一轮工具调用的实现四种典型毛病几乎全踩了一遍参数幻觉函数根本没有某个字段模型自己编了一个填进去。比如函数只定义了city它偏给你加个country。类型漂移模型输出的参数类型和函数签名对不上。明明要求integer它输出字符串23还得在解析层做类型转换增加一层隐患。该调不调不该调乱调有时候一个简单的“你好”也会触发工具调用有时候明确的指令却只在回复里“描述”而没有进入工具调用分支。输出格式漂移要求输出严格的 JSON结果模型在 JSON 前后加了解释性文字解析器直接抛错。通用模型不是做不到这些而是做不“稳”。函数调用是工程行为不稳就意味着每次都要靠上游和下游打各种补丁最终系统变得非常脆弱。专训模型的优势正在于此它把“什么时候不调、什么时候调、调哪个、传什么格式”变成了训练目标的一部分而不是模型自己悟出来的野路子。2.2 1B、3B、7B 到底该选哪个我只说实际部署的感受不给“越大越好”的套话。FunctionGemma 提供了三个规格我简单做过一轮对比规格量化/内存大概量级适合的场景一句话点评1B最低单台普通设备即可运行极简工具集、单意图识别、对延迟极度敏感的端侧场景胜在轻但函数数量一多准确率掉得快3B中等中端设备轻量化后可用常见智能家居、日程、提醒类工具组合目前最均衡的选择推荐大多数场景起步用这个7B较高需要内存大或配合量化复杂多工具、多轮推理、对准确率要求高的场景最强但资源占用也最明显适合“离线但算力不差”的硬件我个人的建议是如果你连第一个 Demo 都还没跑通不要一上来就挑战 7B。先用 3B 级别的模型跑通闭环理解函数定义、解析、循环这几块再把模型换大也不迟。模型不是越大越好而是“刚好装得下你的工具复杂度”最好。2.3 函数定义格式里的门道Go 注释、必填顺序、数据类型这是 FunctionGemma 与通用模型一个很不一样的地方也是很多人第一次配置时最容易翻车的点。它不是用一套自然语言提示词来描述函数长什么样而是倾向于给模型一个高度结构化的函数定义块函数描述带有类似“Go 语言风格”的注释约定。我最初不太理解为什么要这么设计后来才意识到函数调用场景下模型真正需要读的是“精确定义”而不是散文。注释风格统一化之后模型被微调时见过的数据模式一致推理时的准确性自然更高。更关键的两个规则函数参数里不要依赖required和enum这两个字段去约束模型。FunctionGemma 对必填参数的处理是依靠定义顺序来控制的写在前面的一般先被当作必填写在后面的会被模型理解为可选。这个约定和我在通用模型上养成的习惯完全不同切换过来时花了一点时间。参数类型严格遵守 JSON Schema 里的基础类型。不要自作聪明用一个字符串字段去表达一个结构体模型在训练阶段是按照基础类型来学习抽取的你给它一个复合类型它抽取的稳定性就会下降。这其实透露了一个更普遍的道理给模型做工具定义不是给人写接口文档而是给模型写“教材”。教材里的题型组织得越规律评测时的正确率才越能保证。3. 本地部署与第一个函数调用从加载模型到拿到结构化调用3.1 环境准备内存、量化版本、加载框架的替换部署的第一步不是写代码而是先认清你手里的设备能装多大的模型。官方给过内存参考我根据自己的实测经验做一个简化版对照1B 量化版普通 8GB 内存的电脑就能跑几乎是随便装。3B 量化版建议至少 16GB 内存有条件上 GPU 的话体验会好非常多。7B 完整版纯 CPU 不现实建议直接上 8bit 量化内存 32GB 起步才稳。我在本地用的是一台 32GB 内存、带一块中端 GPU 的机器7B 的 4bit 量化版跑起来比较舒服。如果你手头只有内存没有 GPU也不要灰心3B 量化版在纯 CPU 上跑单次调用的延迟虽然感人但端侧智能体本来就是异步任务居多慢一点可以接受。有一点必须提醒加载框架的选择会直接影响你能用哪种量化版本。不同框架对同一份权重的支持程度不一样有的框架能直接加载官方给的量化档位有的框架需要你先转格式。我的做法是先在模型下载页面确认“这份权重适配哪个加载框架”再决定框架而不是反过来。3.2 手写一个“查天气→定闹钟→开灯”的三工具 Demo第一个 Demo 应当足够简单但又要覆盖函数调用的完整链路。我选的三个工具是查天气、定闹钟、开关灯。它们分别对应“查询类操作、时间参数操作、布尔开关操作”覆盖了最常见的参数类型。先定义函数。以查天气为例我用的不是常规的自然语言描述而是严格按照 FunctionGemma 偏好的函数注释体格式来写。下面的代码是“思路级”展示加载框架的 API 细节请按你自己环境里的写法替换# 示意代码请根据本地的模型加载框架替换相关API functions [ { name: get_weather, description: 查询指定城市未来一段时间的天气状况, parameters: { type: object, properties: { city: { type: string, description: 城市名例如 北京、上海 }, days: { type: integer, description: 查询未来多少天的天气默认1天 } } } }, { name: set_alarm, description: 在指定时间设置一个闹钟, parameters: { type: object, properties: { time: { type: string, description: 闹钟时间格式为 HH:MM 24小时制 }, label: { type: string, description: 闹钟的备注名称 } } } }, { name: switch_light, description: 打开或关闭指定房间的灯, parameters: { type: object, properties: { room: { type: string, description: 房间名称例如 客厅、卧室 }, on: { type: boolean, description: true为开灯false为关灯 } } } } ]然后构造提示词。核心是三步系统提示词说明“你是一个能调用工具的智能体当用户的请求需要使用工具时直接输出函数调用”用户消息放入原始请求再把上面那段函数定义拼进去。模型加载与生成这一层各个框架写法差异比较大我不贴具体 API。只说关键点把函数定义序列化成字符串后作为“上下文上下文”的一部分传入模型生成时建议关闭随机采样或者把温度调得很低函数调用场景下要的是确定性不是创意。3.3 解析模型输出拿到“函数名 参数”之后别急着欢呼模型输出出来之后程序要做的是解析。这块官方思路里有一个很推荐的做法尽量用模型配套的响应处理函数来解析而不是自己写一套正则或者 JSON 提取。我一开始图省事自己写了个 JSON loader结果被模型的边界输出折磨了半小时。后来换成了配套解析接口逻辑变成一句大白话把模型的输出交给解析器解析器回给你一个“是否有函数调用、函数名是什么、参数 dict 是什么”的结果。如果解析结果是“没有调用”就把原始输出当成普通回复返回给用户。这里我要强调一个很多人忽略的操作把解析出来的结果构建成“工具响应”之后要作为下一轮的上文重新喂给模型。哪怕是“无调用”的回复也要拼进上下文。否则模型在下一轮对话中就失忆了。# 示意代码伪代码请替换为实际解析接口 result parse_model_output(model_output) if result.has_function_call: fn_name result.function_name fn_args result.arguments # 在这里调用真实的工具执行函数 tool_result execute_function(fn_name, fn_args) # 把 tool_result 等下并入下一轮的 messages else: answer result.text_content # 直接回复用户这一段跑通之后你就拥有了一个最朴素的“能动手”的智能体。坏消息是真正的开发才刚刚开始——单次调用只是点射我们还差一个循环。4. 把单次调用改造成自主循环端侧智能体的“大脑-手-校验”三件套4.1 设计一个最简 Agent Loop请求→决策→执行→反馈→再决策单次函数调用和真正的智能体之间差了一个“循环”。所谓 Agent Loop说白了就是反复执行“模型决策一次代码执行一次”的过程直到模型判断任务完成、不需要再调用工具为止。我自己写过的最简循环大概长这样把当前消息列表包含历史、系统提示、可用的函数定义交给模型。模型输出很可能是一段函数调用也可能是一句普通回复。如果是函数调用就执行对应工具。把工具执行结果作为一条新的“工具消息”拼接到消息列表里。回到第 1 步带上新的上下文再次请求模型。如果模型输出普通回复或者达到最大循环次数就退出。这个循环看着简单但环环相扣的地方在于第 4 步。工具执行结果如果没接回去模型永远不知道“刚才那一步到底成功没有”于是后续的推理就成了无源之水。我第一次跑多工具任务时遇到的问题特别典型让模型“先查北京天气如果明天降温就设一个早上 8 点的闹钟提醒加衣”。如果只做单次调用模型大概率只会调用get_weather然后停下来。加了循环之后它才能拿到天气查询结果再决定要不要触发set_alarm。这个“根据工具结果决定下一个动作”的能力才是智能体真正区别于“命令翻译器”的地方。4.2 多工具联动与上下文记忆管理循环有了紧接着的问题就是上下文管理。端侧模型不像云端大模型那样有动辄几十 K 的上下文窗口FunctionGemma 这类偏端侧的模型上下文资源是有限的。如果每一轮循环都把所有历史消息和全部函数定义原样塞进去几轮之后上下文就顶爆了而且函数定义重复灌入还会稀释模型对最新指令的注意力。我的处理经验可以总结成三条原则函数定义不必每轮都全量灌入。第一次请求之后模型已经“见过”工具形状了后续轮次只需要把“本次被调用过的函数签名”和“新的结果”保留即可。实在需要全量重发时也要压缩描述去掉宽泛解释。历史消息做截断。保留系统提示、最近一轮用户指令、最新的工具结果更早的中间过程可以用一句摘要替代。这不是偷懒而是把宝贵的上下文留给当前决策。单轮循环内只放必要信息。决策“是否再调工具”时模型其实只需要知道“上一步结果是什么”和“用户目标是什么”不需要把五轮之前的对话也拉进来。这些规则听着俗气但正是端侧智能体能不能“连续干活不停顿”的关键。云端模型浪费得起上下文端侧模型浪费不起。4.3 端侧特有的资源约束上下文省着用、错误及时兜底端侧智能体还有两件云端不常碰到的事本地推理延迟和资源极限下的容错。先说延迟。每次模型推理都有时间成本Agent Loop 如果转太多轮体验会直线下滑。所以我在工程上会加两个阀门一是“最大循环次数”默认给 34 次防止模型陷入死循环二是“如果某个工具连续调用失败两次立即强制退出并回复兜底提示”。这两个阀门看着简单但它们保证了一个端侧智能体的最后底线——绝不让用户面对一个“正在转圈但永远不结束”的对话。再说容错。端侧插件接口不一定稳定工具执行端可能抛异常。模型本身是高冷范儿你如果直接把 Python 的Traceback拼成“工具结果”喂回给它它会被带偏。更好的做法是在工具执行层包一层把异常统一转换成一句人类可读的状态描述例如“查询超时请稍后重试”或“参数 city 不存在”。模型看到的是规范和友好的“事实”而不是一团乱码。5. 实测中的坑与调优笔记函数质量、延迟、量化边界5.1 函数描述写得好不好直接决定调用准确率这句话我在很多文章里都见过但真正感受它的分量是在自己把同一个工具用三种方式写了一遍之后。第一次我只写函数名和参数列表描述字段用最简的话结果模型经常把参数搞错——它确实知道该调get_weather但city参数会从用户的无关语句里乱摘。第二次我把描述写得又长又细恨不得讲一段小作文结果模型好像被干扰了开始在该调工具的时候反而犹豫。第三次我参考了官方给的那种“Go 注释式、一句话精准描述、参数逐个说明取值约定”的写法准确率肉眼可见地提升。整理下来函数描述有一个“宁可精准不可冗长”的原则函数描述一句话说清楚“这个工具做什么”不要包含具体调用场景的细节。参数描述重点写清楚“取值约束”和“格式”而不是写这个参数背后的业务意义。不要在函数定义里写任何“业务策略”。比如不要在get_weather的描述里加“如果温度低于 10 度就建议加衣”那是 Agent Loop 里模型该做的判断不是工具描述该干的事。5.2 量化后反而更稳端侧部署的实战观察这个标题听起来有点反直觉但确实是我实测中的一个真实感受。7B 完整版在推理时有时会有一点“过度发散”的倾向偶尔会在函数调用 JSON 后面附带几句解释性文本。换成 4bit 量化版之后模型似乎因为表达能力受限反而更“本分”输出的结构规范性反而更好。我没有办法从严谨的训练理论上解释全部原因但从工程角度来说这其实透露了一个重要信号函数调用任务本身是一个“低熵任务”它不需要模型发挥创造力只需要模型严格遵循格式和抽取规则。适度的量化压缩掉了一部分发散能力反而让它更容易待在任务轨道上。当然这不是说量化越狠越好。1bit 级别那种极端量化我没有在 FunctionGemma 上试过不做评价。但如果你在 7B 完整版上遇到了输出格式抖动的问题可以试试先用官方给的 8bit 或 4bit 版本跑一轮对比。有些问题不是模型不够聪明而是模型“太聪明”了聪明到忍不住想自由发挥。5.3 内存不够时的降级路线与应用边界最后聊一个现实问题如果真的跑不动怎么办我自己的降级路线是这样的7B 跑不动降 3B。3B 跑不动降 1B。1B 如果再跑不动那就不是换模型的问题了而是要把你的工具集合做“瘦身”。端侧智能体有一条隐藏规律工具越少模型选择难度越低。把 50 个工具砍成 5 个高度内聚的工具模型的表现往往比硬塞一个 7B 模型还好。同样的逻辑也适用于应用边界。端侧智能体适合的任务有清晰的画像单目标明确、工具数量可控、延迟容忍度适中、隐私敏感或必须离线。不适合的任务也有清晰画像需要长链条多步推理、需要极其丰富的知识库、必须实时联网获取海量信息。后者建议交给云端方案端侧与云端不是替代关系而是按任务分发的两条流水线。我在实际项目里最喜欢的组合是敏感数据、本地设备控制、日程管理这类任务全部留在端侧需要综合信息检索和复杂推理的任务才上云。这样既保护了隐私又把端侧模型的每一分性能都花在刀刃上。最后一个私心建议如果你准备试 FunctionGemma先从“查天气”这个小工具开始但不要停留在“模型输出了正确 JSON”这一步。请你继续做下去——把返回值喂回对话让它根据天气决定要不要带伞再把这个决定变成一条真实的提醒通知。那才是“从对话迈向行动”真正该有的体验。跑通的那一刻你会明显感觉到手里的模型不再是一个聊天框而是一个能干活的小助手了。
