这两年我一直在琢磨一件事：手机里的语音助手到底什么时候才能真的“干点活”。你说“帮我把相册里重复的照片删掉”，它回你一句“好的，我帮你删掉重复照片”，然后就没有然后了。问题不出在对话理解上，而在于模型压根没有“动作出口”——它只学会了说话，没学会调工具。这正是函数调用（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 如果转太多轮，体验会直线下滑。所以我在工程上会加两个阀门：一是“最大循环次数”，默认给 3～4 次，防止模型陷入死循环；二是“如果某个工具连续调用失败两次，立即强制退出并回复兜底提示”。这两个阀门看着简单，但它们保证了一个端侧智能体的最后底线——绝不让用户面对一个“正在转圈但永远不结束”的对话。再说容错。端侧插件接口不一定稳定，工具执行端可能抛异常。模型本身是高冷范儿，你如果直接把 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”这一步。请你继续做下去——把返回值喂回对话，让它根据天气决定要不要带伞，再把这个决定变成一条真实的提醒通知。那才是“从对话迈向行动”真正该有的体验。跑通的那一刻，你会明显感觉到，手里的模型不再是一个聊天框，而是一个能干活的小助手了。
这两年我一直在琢磨一件事：手机里的语音助手到底什么时候才能真的“干点活”。你说“帮我把相册里重复的照片删掉”，它回你一句“好的，我帮你删掉重复照片”，然后就没有然后了。问题不出在对话理解上，而在于模型压根没有“动作出口”——它只学会了说话，没学会调工具。这正是函数调用（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 如果转太多轮，体验会直线下滑。所以我在工程上会加两个阀门：一是“最大循环次数”，默认给 3～4 次，防止模型陷入死循环；二是“如果某个工具连续调用失败两次，立即强制退出并回复兜底提示”。这两个阀门看着简单，但它们保证了一个端侧智能体的最后底线——绝不让用户面对一个“正在转圈但永远不结束”的对话。再说容错。端侧插件接口不一定稳定，工具执行端可能抛异常。模型本身是高冷范儿，你如果直接把 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”这一步。请你继续做下去——把返回值喂回对话，让它根据天气决定要不要带伞，再把这个决定变成一条真实的提醒通知。那才是“从对话迈向行动”真正该有的体验。跑通的那一刻，你会明显感觉到，手里的模型不再是一个聊天框，而是一个能干活的小助手了。