通过代理技能弥合知识差距
Source: Google Developers Blog
大型语言模型（LLMs）拥有固定的知识，训练于特定的时间点。软件工程实践节奏快且经常变化，每天都有新库发布，最佳实践也在快速演进。
这导致了语言模型无法自行解决的知识鸿沟。在 Google DeepMind，我们从几个方面看到这一点：我们的模型在训练时并不了解自身，也不一定能感知最佳实践的细微变化（比如 thought circulation）或 SDK 更新。
已有许多解决方案，从网页搜索工具到专用的 MCP 服务，但最近，agent skills 作为一种极其轻量却可能有效的方式出现，用以弥合此鸿沟。
虽然我们作为模型构建者可以实施一些策略，但我们想探讨对任何 SDK 维护者而言可能的做法。下面是我们构建 Gemini API developer skill 的过程以及它对性能产生的影响。
我们构建的内容
为了帮助使用 Gemini API 的编码代理，我们构建了一个技能，该技能能够：
- 解释 API 的高级功能集，
- 描述每种语言对应的当前模型和 SDK，
- 演示每个 SDK 的基础示例代码，以及
- 列出文档入口点（作为真实来源）。
该技能是一组基本的原始指令，引导代理使用我们的最新模型和 SDK，同时引用文档以鼓励从真实来源检索最新信息。
该技能可在 GitHub 上获取，或直接安装到项目中：
# 使用 Vercel skills 安装
npx skills add google-gemini/gemini-skills --skill gemini-api-dev --global
# 使用 Context7 skills 安装
npx ctx7 skills install /google-gemini/gemini-skills gemini-api-dev技能测试
我们创建了一个评估框架，包含 117 条提示，这些提示使用 Gemini SDK 生成 Python 或 TypeScript 代码。这些提示覆盖了多个类别，包括代理式编码任务、构建聊天机器人、文档处理、流式内容以及许多特定的 SDK 功能。
测试在两种模式下进行：
- Vanilla – 直接对模型进行提示。
- With skill – 模型收到与 Gemini CLI 相同的系统指令（参见 source）以及两个工具：
activate_skill和fetch_url（用于下载文档）。
如果提示使用了我们旧的 SDK，则视为失败。
技能有效，但需要推理
- 最新的 Gemini 3 系列模型在加入
gemini-api-dev技能后取得了卓越的成绩，基线提升显著（3.0 Pro 与 Flash 均为 6.8 %，3.1 Pro 为 28 %）。 - 较早的 2.5 系列同样受益，但提升幅度没有那么大。使用具备强大推理能力的现代模型会带来明显的差异。
所有类别表现良好
在几乎所有领域中，添加该技能对表现最佳的模型（gemini-3.1-pro-preview）都很有效。
SDK Usage 的通过率最低，仅为 95 %。这些失败涉及一系列任务，包括一些困难或不明确的请求，尤其包括明确要求使用 Gemini 2.0 模型的提示。
示例（失败的 SDK‑usage 提示）
当我使用 Python API 调用 Gemini 2.0 Flash 模型，且输出相当长时，返回的内容是一组输出块，而不是完整的内容。我猜它在进行某种流式输入。如何关闭它并一次性获取完整输出？
技能问题
这些初步结果令人鼓舞，但我们从 Vercel 的研究 中了解到，通过 AGENTS.md 直接指令往往比使用技能更有效。因此，我们正在探索其他方式来提供 SDK 的实时知识，例如直接使用 MCP 来获取文档。
技能的简洁性是一个巨大的优势，但它没有很好的更新机制——用户必须手动更新。从长远来看，过时的技能信息可能会留在用户的工作区，潜在地造成的危害可能大于收益。
尽管有这些小问题，我们仍然对在工作流中使用技能感到兴奋。Gemini API 技能仍然相对新颖，但我们会在推动模型更新并探索改进途径的同时保持维护。关注 Mark 和 Phil 获取最新动态，别忘了 尝试一下 并 分享你的反馈。