Skills + 工具调用：把 Gemini 变成执行型助手

gemini镜像站入口：chat.aimirror123.com
gemini 镜像备用站：gemini-3.shop。
摘要：本文聚焦工具调用，让 Skills 从“会说”变成“能做事”。

工具调用解决的不是“说得更好”，而是“做得更稳”

纯文本推理有天花板。你想让模型查资料、读文件、算数据、写入系统，这些都该交给工具。 Gemini 的 function calling 机制就是为这个设计的。

你声明函数，模型选择何时调用，并把参数填好。返回结果再交给模型做总结或下一步。 这就是“可执行的 Skill”。官方文档也强调，函数声明要写清楚参数和用途，否则模型会乱猜。

函数声明要像接口文档

这是很多人忽略的一点。你写的不是 prompt，而是接口说明书。函数名要具体，描述要告诉模型 何时调用，参数要给清楚类型和含义。比如“searchDocs”要说明它返回哪些字段、最多几条。

我一般会把“什么时候用、用完该返回什么”写进 description。模型看得懂，你也能少踩坑。

先画一条“动作链”

在写代码前，我会先把动作写成链条：先检索，再读取，再总结。每个动作都对应一个函数。 这样做的好处是，你不会一上来就堆成一个大函数，后期维护会轻很多。

如果链条超过三步，我会考虑拆成多个 Skill。工具调用能跑，但复杂度也会上来。

三种调用模式，各有用处

Gemini 提供了三种 function calling 模式：AUTO、ANY、NONE。AUTO 让模型自己判断要不要调用， ANY 是强制调用工具，NONE 则完全禁用。

新手最稳妥的做法是 AUTO。你先观察模型什么时候会乱调用，再考虑是否要收紧。 如果你的 Skill 天生就要调用工具（比如“查资料后输出摘要”），那就用 ANY，避免它偷懒。

参数校验是“第二道防线”

模型再聪明，也会传错参数。比如把日期格式写错、漏字段、传空值。你一定要在工具层做校验， 这不是鸡蛋里挑骨头，而是线上稳定性的保证。

我会让工具返回清晰错误，让模型知道“刚才没成功”。然后让模型重试一次，而不是直接崩掉。 这一步做完，Skill 的可靠性会提高一截。

失败策略要写出来

很多 Skill 会因为一次失败就“假装成功”。这非常危险。你要告诉模型：调用失败就返回错误， 不要编造结果。然后在系统层面做一次重试或降级。

这一步不花时间，但能避免很多线上事故。真正稳定的 Skill 都有失败策略。

把工具调用拆成“小动作”

很多人想做一个“万能工具”，结果函数参数又长又复杂。实际操作中，小工具更好用。 例如：一个函数负责搜索，一个函数负责读取网页内容，一个函数负责做格式化。

函数越小，模型越不容易传错参数。你也更容易定位问题。

工具返回值也要“可读”

这里说的可读不是给人看，而是给模型看。工具返回的 JSON 要有清晰字段， 不要把一大段原文塞进一个字段。否则模型只能乱总结。

我会把返回值拆成“标题、链接、摘要、时间”这种小字段。模型拿到这些字段后， 总结出来的内容会更准。

工具调用和结构化输出是搭档

工具调用让模型拿到真实数据，结构化输出让结果更稳定。这两件事最好一起用。 比如“搜索 + 输出 JSON 摘要”，你可以要求模型用 JSON Schema 返回标题、来源、要点。

Gemini 支持结构化输出配置，你可以限定输出格式，减少“自由发挥”。这对工具调用后的汇总很关键。

内置工具和自定义函数怎么选

Gemini 提供了一些内置工具，比如搜索、代码执行、URL 读取。你可以直接用，省掉很多开发时间。 但如果你的业务有特定系统，比如内部数据库或后台接口，就需要自定义函数。

选择原则很简单：能用内置就用内置，省心；必须接业务系统时再写自定义函数。 不要为了“完全可控”而自己造轮子。

顺序调用还是并发调用

有些任务必须串行，比如先搜索再读取；有些任务可以并发，比如同时拉三页资料。 你需要明确哪些步骤有依赖，哪些可以并行。并行能节省时间，但也更容易出错。

我一般的做法是“先串后并”：先跑通串行流程，确保结果稳定，再尝试并发。

避免“工具循环”

模型有时会陷入循环调用，比如不断搜索同一个问题。你要设置边界，比如最多调用三次， 或者在第二次就要求模型给出结论。

这类限制最好写进系统指令或调用策略里，靠人工盯着很难撑住。

什么时候该把工具调用拿掉

如果你的 Skill 不需要外部数据，只是简单的改写、提炼，那没必要用工具。 工具调用会增加复杂度和成本。能用文本解决的，就别硬加工具。

这是现实问题：工具不是免费的，调用次数多了费用会上去，延迟也会上来。你要评估它值不值。

一个简单的组合例子

“教程更新检查”是一个典型场景。流程可以是：搜索官方更新 → 读取更新说明 → 输出摘要。 这就是三个小函数的组合。你让模型按顺序调用，然后用结构化输出把内容收口。

这样写出来的 Skill，几乎不需要人工干预，就能稳定产出“更新摘要”。

调用成本要心里有数

工具调用会增加请求时间，也会增加成本。如果你做的是高频功能， 最好算一下平均调用次数和延迟。能少一步就少一步，能缓存就缓存。

这不是斤斤计较，而是让 Skill 真正能在生产环境里活下去。

多轮调用的上下文要收紧

当一个 Skill 需要调用多次工具，模型会带着越来越多的上下文。信息一多就容易跑偏。 我会在每次工具返回后做一次“瘦身”：只保留关键字段，再交给模型总结。

这不是“删信息”，而是防止模型被噪声淹没。尤其是搜索和网页内容，原文越长越容易误导。

重复调用要做去重

如果一个 Skill 经常查同样的资料，最好加缓存或去重逻辑。这样能省钱，也能降低延迟。 你不需要做很复杂的缓存系统，哪怕是简单的本地缓存也有用。

日志和可追溯性

工具调用一旦出问题，第一件事就是看日志。你至少要记录：调用了哪个工具、参数是什么、返回了什么。 这样才能排查错误，也能知道模型是不是在乱调用。

如果你担心隐私，就做脱敏。不要为了“干净”而不记录。没有日志就没有稳定性。

权限边界要明确

只要涉及写入系统或敏感数据，就要设权限。模型可以提出调用，但最终是否执行， 由你的系统决定。别把权限完全交给模型。

我一般会在高风险工具前加一道确认，或者把它们拆成“只读”和“可写”两个函数。

告诉模型何时停手

工具调用如果没有“停止条件”，模型可能会一直找下去。你可以在 system instruction 里 明确：最多调用几次、达到什么条件就收尾。这样能避免无意义的反复检索。

一句话总结：你要把“结束标准”写清楚，否则模型会自己找标准。

写给想上线的人

工具调用不是炫技，它是工程能力。你要对返回数据做校验，对失败做重试， 对模型回答做限制。把这些做完，Skill 才能上线。

如果你只能做一件事，那就先把函数声明写好。模型理解对了，后面才有稳定性可谈。