Google Gemini憋了3年的工具组合，开发者实测

2023年还在写"先调地图再调评分"的胶水代码，2026年3月17日Google一纸更新，把两条API缝成了一条。Tool Combinations（工具组合）上线当天，我的LINE Bot代码删了40行——不是优化，是直接废弃。

旧架构的别扭在于：地图上下文和真实数据像两个部门的员工，互相看不见对方的工单。

用户问"附近4星以上的火锅店"，老方案要么让AI自己编评分（Maps Grounding），要么拿到真实分数却不知道人在哪（Places API）。开发者被迫在两者之间搭桥，多一次网络往返，多一层出错概率。

Google这次把google_maps和function_declarations塞进了同一个Tool对象。模型自己决定先拿定位、再调评分、最后拼答案。顺序和衔接由Gemini内部消化，不需要人工编排。

从"胶水代码"到"声明即运行"

改造前的linebot-spot-finder是个典型妥协产物。用户甩来GPS坐标，Bot先走Maps Grounding圈出范围，AI用自然语言描述"附近有几家火锅店，口碑不错"——评分是它"认为"的，不是抓来的。

用户追问"具体多少分"，Bot只能道歉。Places API的密钥躺在服务器里，但老架构不让它和地图工具同时出场。

3月17日的更新改了一行配置：

旧写法：两个Tool对象，二选一
新写法：一个Tool对象，内置工具+自定义函数共存

模型拿到请求后，内部执行链变成：识别位置意图→调用Maps Grounding建立空间上下文→识别数据需求→触发Places API获取真实评分→整合输出。全程一次API往返。

实测对比：同一句话，两种回答

测试指令："找一家4星以上、适合聚餐的火锅店，给名称、地址、评价摘要。"

旧Bot返回："附近有几家火锅店，评分都不错，比如老王火锅和老四川，地址在……"——地址是对的，评分是AI幻觉的。

新Bot返回："老王火锅，4.3星，地址XX路XX号，最近评价提到'包厢够大、锅底偏辣'；老四川火锅，4.1星……"——每个数字都有Places API背书。

差异不在"更聪明"，在责任边界清晰：地图数据归Google Maps，商户评分归Places API，AI只负责整合与表达。

Context Circulation：被低估的暗线

Tool Combinations的显性价值是"少写代码"，隐性价值是多轮对话中的状态保持。Google同期发布的Context Circulation（上下文循环）让模型记住第一次工具调用的结果，第二次调用时直接引用。

场景：用户先问"附近有什么"，Bot列出5家店；用户接着问"第三家评分多少"。

旧架构下，第二次请求是全新的，模型需要重新理解"第三家"指谁，可能再次调用地图工具做无用功。新架构里，第一次的Places结果留在上下文槽位，模型直接定位到第三条记录提取评分，响应快了近一倍。

这个机制对语音交互和快速追问场景尤其关键。人类对话不会每句都重报坐标，AI工具链也不该如此。

开发者视角：省下的不只是代码量

我的linebot-spot-finder改造耗时约3小时，主要花在Places API的响应格式对齐上。Tool Combinations本身零学习成本——原本就会写Function Calling的开发者，把函数声明和地图工具并排放进配置即可。

真正的迁移成本在思维层面：以前习惯"我编排流程"，现在要学会"我描述需求，模型选工具"。初期会不放心，想加日志看模型到底调了哪个工具，调了几次。跑了一周生产流量后，监控显示工具选择准确率97.3%，误调用集中在模糊指令（如"好吃的"未指定品类）。

Google的更新文档里埋了一句：模型对工具的选择基于训练时的工具使用模式，而非硬编码规则。这意味着未来工具生态越丰富，模型的调度能力会随基础模型迭代自动提升，不需要开发者重新部署。

LINE Bot的完整改造路径

具体实现上，LINE的Message API负责收发，Gemini层处理理解+工具调度，Places API提供真实数据。三者的接缝现在极薄：

用户发送位置消息→LINE Webhook推送坐标→Bot构造Gemini请求，附带Maps Grounding和Places查询函数→Gemini返回结构化答案→Bot渲染为LINE Flex Message卡片。

关键代码变化只有Tool对象的构造方式。其余业务逻辑——评分过滤、距离排序、营业状态判断——从"我写在代码里"变成"我写在函数声明的description里"，模型自己决定何时触发。

一个细节：Places API的响应包含大量字段，我在函数声明里用properties显式限定了rating、user_ratings_total、price_level、opening_hours，避免模型被无关信息干扰。这是Prompt Engineering在工具层的新战场。

尚未解决的边缘

Tool Combinations不是万能胶。实测中发现两个限制：

一是工具依赖的隐式顺序。模型偶尔先调Places API再调Maps Grounding，导致第一次调用缺少位置上下文而失败。目前的 workaround 是在Places函数声明的description里强调"需要先获取用户位置"，但不够优雅。

二是延迟累积。单次API调用内部串行执行两个工具，总耗时约1.8秒（旧方案两次调用合计2.4秒），但对延迟敏感的场景仍需流式响应或预加载策略。

Google的更新路线图上写着Q2优化工具并行执行，届时耗时有望压到1秒以内。

3月17日至今，我的Bot处理了约1200次餐厅查询请求，用户追问评分的比例从改造前的34%降到7%——不是问题变少了，是一次回答的信息密度足够高，不需要二次确认。

当你的Bot能在一次对话里同时回答"在哪"和"好不好"，用户会把这当成理所当然。他们不会知道2023年的开发者写过多少胶水代码，就像不会知道自来水管曾经需要逐户凿井。技术债的偿还，最终都变成了体验的基线。

如果Google下一步把预订、排队、优惠券也做成内置工具，你的Bot架构还撑得住吗？