Gemini API 支持工具组合后怎么设计调用链：函数调用、Google Search 与 Maps grounding 的取舍

把“查公开信息”和“查自己系统”塞进同一条 Agent 流程时，最容易出现的不是模型不会调用工具，而是工具之间的职责混在一起：搜索结果被当成库存事实，地点结果又直接写进订单。Gemini API 最近支持在一次交互里同时传入内置工具和自定义函数，适合把这条链路拆得更清楚。

建议先按数据归属分工：Google Search 负责公开网页信息，Google Maps 负责地点与空间信息，自定义函数只访问自己的业务数据；跨工具传递时保留每次工具调用的 ID，才能在异步流程里对上输入和结果。

这次变化解决的是哪一段编排

Google 在 2026 年 3 月的 Gemini API 工具更新中明确提到，开发者可以在同一次请求里组合 Google Search、Google Maps 等内置工具和自定义函数。以前常见的做法是应用层先判断“该搜网页还是调后端”，再把第一步结果拼进第二次请求；现在可以把工具声明一起交给模型，让它根据任务在交互中切换。

这不是把后端数据库开放给搜索工具，也不是让模型自动获得订单写权限。它只是把工具选择和上下文流转的外围代码压薄，权限、参数校验和最终写入仍由业务服务负责。

从一个库存核对场景看工具怎么分工

假设采购助手收到一句话：“查今天热门的降噪耳机，再确认我们库存里有没有这些型号。”这个问题天然分成两段：热门型号属于公开信息，库存属于企业内部信息。前一段可以交给 google_search，后一段交给只读的 check_inventory 函数。

from google import genai

client = genai.Client()

check_inventory = {
    "type": "function",
    "name": "check_inventory",
    "description": "Checks the internal inventory database for a product model.",
    "parameters": {
        "type": "object",
        "properties": {"product_name": {"type": "string"}},
        "required": ["product_name"]
    }
}

interaction = client.interactions.create(
    model="gemini-3-flash-preview",
    input="Search for three trending noise-canceling headphones today, then check our inventory.",
    tools=[{"type": "google_search"}, check_inventory]
)

这段示例表达了一个重要边界：google_search 返回的是公开网页依据，check_inventory 才能返回内部库存。自定义函数的服务端实现仍应验证型号、租户和访问身份，不能因为模型给出了函数调用就直接执行高风险写操作。

上下文传递为什么比“再发一次请求”更稳

多步工具调用的麻烦在于第二个工具需要看到第一个工具的结果。例如模型先查到三个型号，再逐个调用库存函数。如果应用层只把一段自然语言摘要拼回去，容易丢掉来源、参数和原始响应。官方更新提到的 context circulation，会把工具调用及其响应保留在模型上下文里，让后续步骤能基于原始结果继续推理。

工程上仍然要做自己的审计记录。推荐至少记录请求 ID、工具名、参数摘要、调用开始和结束时间、返回状态，以及模型给出的工具响应 ID。这样当库存结果和搜索结果对不上时，可以知道是搜索结果变了、参数映射错了，还是内部函数返回了旧数据。

Google Maps grounding 该放在什么问题里

如果问题换成“找出某个区域步行可达、当前营业的三家门店”，Google Maps grounding 的职责就比普通网页搜索更明确：它提供地点、营业信息、通勤时间和位置相关数据。官方文章说明，这项能力扩展到 Gemini 3 家族，并可与内部库存 API 组合。

但“附近有店”不等于“这家店有货”。可靠的链路仍是先用 Maps 得到地点候选，再把标准化后的门店标识交给内部库存或门店系统。地址、营业状态和库存状态要分别展示，避免把一个工具的结论伪装成另一个系统的事实。

工具组合上线前先做四个检查

公开数据和内部数据有没有越权

给每个工具写清数据范围。搜索工具只负责公开网页，Maps 只负责空间信息，自定义函数按租户和角色访问业务库。不要把数据库连接、内部 URL 或密钥放进工具描述。

函数参数是否能被服务端重新校验

模型传来的型号、地点和数量都当作不可信输入。服务端要做长度、格式、租户归属和权限校验；只读查询和写入动作最好拆成不同函数，避免一个描述模糊的函数拥有过大权限。

异步回调能否对上原始调用

官方示例展示了为工具调用提供唯一 id 的做法。你的日志系统也要把这个 ID 贯穿请求、函数回调和最终回答，尤其是并行函数调用时，不能用数组顺序猜对应关系。

失败时能否停在安全状态

搜索超时、Maps 没有结果、库存服务返回旧版本数据，都不应该自动触发订单创建。先返回“公开信息已取到、内部库存未确认”这样的明确状态，再让用户决定是否重试或转人工。

它适合哪些团队，不适合哪些调用

如果团队已经有稳定的内部函数接口，且流程确实需要公开信息与业务数据交叉判断，工具组合能减少胶水代码。原型阶段可以先做只读场景，观察工具选择准确率、函数失败率、上下文长度和人工接管比例。

如果业务只有一个简单函数调用，或者每一步都要求固定、可审计的顺序，显式编排反而更容易测试。新闻里的“能组合”是能力边界，不是所有场景都应该交给模型自由决定。

相关问题

Google Search 能直接查企业内部库存吗？

不能。库存应由企业自己的函数或服务返回，搜索结果最多提供公开型号、评测或网页信息。

Google Maps grounding 能代替门店数据库吗？

不能。Maps 负责地点和空间相关信息，实时库存、内部价格和订单状态仍要从业务系统核对。

工具调用 ID 只用于调试吗？

它首先帮助调试和异步结果映射，也可以作为审计链的一部分，但仍要结合权限、请求 ID 和业务日志保存。

落地时先从只读闭环开始

第一版可以只实现“公开信息检索→内部库存查询→带来源的回答”，暂不允许模型直接创建订单或修改库存。把每次工具选择、参数校验、响应 ID 和失败状态记下来，跑过一轮真实数据后，再决定是否增加 Maps 或写操作。这样才能判断工具组合减少的到底是编排代码，还是只是把复杂度挪到了更难排查的地方。