Google 3月17日甩出1个API组合

开发者用LINE Bot找餐厅时，有个老毛病：问AI附近有什么好吃的，它要么能看地图但评分瞎编，要么能查真实评分却不知道你在哪。Google 3月17日更新的Gemini API Tooling，用一行代码把这两个能力拧在了一起。

以前要调两次API的活，现在一次搞定。

具体场景很典型。用户发完定位，丢过来一句："找家4星以上的火锅，适合聚餐，给店名地址和点评摘要。"旧版Maps Grounding的回复大概是"附近有几家火锅，评分都不错"——AI自己发挥，准不准看运气。换成纯Places API调用，能拿到真实评分，但Gemini根本不知道用户站在哪条街上。

Google 3月17日的更新给了第三种解法：Tool Combinations。同一个Tool对象里，google_maps和function_declarations能并存。模型自己决定什么时候调地图、什么时候调外部API，最后把结果拼成一句人话。

一行代码改的什么

旧写法把两个工具拆开：

types.Tool(google_search=types.GoogleSearch())

types.Tool(function_declarations=[MY_FN])

新写法塞进同一个Tool：

types.Tool(

google_maps=types.GoogleMaps(),

function_declarations=[MY_FN]

差别就这。但背后跟着两个配套更新：Maps Grounding让模型真正感知空间位置，不是读文字描述"附近"，而是知道你在台北101还是新宿站；Context Circulation让多轮工具调用的结果能流向下文，第一次调地图拿坐标，第二次调Places API查评分，模型记得住中间态。

作者实测改了什么

原文作者Mariano Cocirio拿现有项目linebot-spot-finder做了升级。旧版只有Maps Grounding时，AI对评分的描述是生成式的，可能把3.8星说成"评价不错"。新版接入Tool Combinations后，Places API返回的真实评分、评论数、营业状态直接进上下文，Gemini再组织语言输出。

用户得到的回复从"有几家火锅，评分都不错"变成"Lao Wang Hot Pot，4.2星，127条评论，'汤底越煮越香但排队久'"。

这个改动对做本地生活机器人的开发者很实在。以前要自己写逻辑串地图和评分，现在模型内部调度。但有个边界：Tool Combinations目前只支持内置工具（Google Search、Google Maps）和自定义Function Declaration的组合，两个自定义函数之间还不能这么玩。

为什么现在才补上

Google的API设计一直有层窗户纸。Function Calling和Grounding是两条独立的能力线，2024年Function Calling成熟，2025年初Search Grounding开放，但让模型在同一轮对话里自主切换工具，涉及到调用顺序、错误处理、上下文压缩一堆脏活。3月17日的更新相当于官方把管道铺好了。

Mariano Cocirio在更新说明里提到，Context Circulation是容易被忽略的部分。很多开发者试过手动串两个API，但第一轮调地图返回的坐标、边界框怎么传给第二轮的Places查询，格式对齐很麻烦。现在模型自己维护这个状态。

对LINE Bot生态来说，这是个低门槛的升级点。日本、台湾、泰国大量商家还在用LINE做客服和预约，接入Gemini的成本比自建NLP低得多。Tool Combinations出来后，这类机器人的信息准确度能往上抬一档——至少评分不会瞎编了。

Google没公布具体有多少开发者在用Maps Grounding，但从更新文档的篇幅看，这功能之前的使用率可能没达到预期。Tool Combinations更像是降低使用门槛的补丁，而不是技术突破。

作者最后放了个未完成的demo截图，Bot回复到一半截断了。评论区有人问是不是token超限，作者回复说"Context Circulation还在调，长回复容易断"。这大概是现阶段最真实的用户反馈——管道通了，水压还不稳。