Gemini Gems 退场，Google 要把 Agent 变成可复用的 Skills

Google 正在把 Gemini 的任务型 Agent 从 Gems 迁移到 Skills，这意味着用户未来不再主要通过“创建一个专属助手”来固定工作流，而是把任务规则、背景资料和工具使用方式封装成可重复调用的技能。

据 TechCrunch 9 月 28 日报道，Google 正在结束 Gemini Gems 这一功能路线，转而推动名为 Skills 的新机制。Skills 是一组可重复使用的指令、背景资料和工具使用规则，Gemini 可以在执行任务时自动识别并调用它们。

这不是一次简单的改名。Gems 更像“配置好的专属聊天机器人”，Skills 则更接近 Agent 工作流里的“能力模块”。前者解决的是“我想要一个固定用途的助手”，后者解决的是“一个 Agent 如何在不同任务中复用同一套做事方法”。

Google 正在重做任务型 Agent 的基本单位

Gemini Gem 是一种预先配置好的自定义 AI 助手，用户可以把角色、任务目标、背景文件和输出格式保存下来，以便反复处理同类问题。

例如，一个“写作编辑 Gem”可能被设置为：检查文章结构、压缩冗余表达、保留技术细节，并以 Markdown 输出。过去，用户需要进入这个 Gem，与一个固定身份的 Gemini 对话。

Skills 的定义则不同。Gemini Skill 是一组可独立保存、重复使用并组合调用的工作规则，重点不是“它是谁”，而是“它应该如何完成某一类工作”。

从产品形态看，Gem 的最小单位是一个专属助手，Skill 的最小单位是一段可以嵌入多个任务的能力。这个变化类似于从“安装一个完整软件”转向“加载一个可组合插件”：用户不用为每一种场景都创建一个新的 Agent，而是可以把多个技能拼接到同一项任务中。

目前 Google 的官方说明显示，Skills 主要服务于 Gemini Spark。Spark 是 Gemini 中用于执行多步骤、后台任务和定时工作的 Agent 能力。Google 将三者的关系概括为：任务决定“做什么”，排程决定“什么时候做”，技能决定“怎么做”。

例如，用户可以创建一个“管理伦敦出差”的任务，设置每周一上午 8 点检查行程，再让 Spark 调用“旅行预订”技能和“Gmail 撰写”技能，完成酒店变更并发送确认邮件。

这比单独保存一条 Prompt 更接近真正的 Agent 编排。Prompt 通常只描述一次对话的要求，而 Skill 可以成为多个任务共享的执行规范。

Gems 和 Skills 到底有什么区别？

Gems 是面向用户的固定用途 AI 助手，Skills 是面向 Agent 的可调用工作能力。两者都能保存指令，但在调用方式、组合能力和适用场景上并不相同。

| 对比维度 | Gemini Gems | Gemini Skills | |---|---|---| | 核心定位 | 自定义 AI 助手 | 可复用的 Agent 技能模块 | | 主要解决的问题 | 固定一种角色和对话方式 | 让 Agent 按指定规则完成工作 | | 调用方式 | 用户主动进入 Gem 对话 | Spark 可由用户指定，也可自动识别调用 | | 组合能力 | 通常以单个助手为中心 | 可以在同一任务中组合多个 Skills | | 适用任务 | 写作、编程、头脑风暴、学习辅导 | 背景自动化、定时任务、多步骤工作流 | | 可移植性 | 更偏向 Gemini 产品内部使用 | 可下载为 .zip，便于分享和复用 | | 当前依赖 | Gemini 对话体验 | Gemini Spark | | 典型使用方式 | “建立一个 SEO 编辑助手” | “让 Agent 按 SEO 规范研究、写作并发送报告” |

一个具体例子是：如果用户只想让 Gemini 以技术编辑的口吻修改一篇文章，Gem 已经足够。但如果任务变成每天抓取 AI 新闻、筛选来源、提炼要点、生成摘要、写入文档并发送邮件，那么 Gem 只是其中一个角色配置，Skill 才更适合作为流程中的能力组件。

Skills 的关键变化：从“被打开”到“被调用”

Skills 最大的产品变化，是它们不再要求用户始终手动进入某个专属助手。

Google 官方说明显示，用户可以在执行 Spark 任务时明确指定技能，也可以让 Gemini 根据当前任务自动选择相关技能。比如，当用户提出“重新预订酒店并给同事发确认邮件”时，Spark 可以同时使用“旅行预订”与“Gmail 撰写”两个 Skill。

这种自动选择机制让 Skill 更像 Agent 的工具箱。用户描述的是目标，系统负责判断需要哪些能力，并把对应模块加入执行过程。

但这里也有一个重要边界：自动调用并不等于完全可靠。Skills 通常包含的是规则、上下文和工具使用说明，而不是一个经过严格验证的程序。Agent 是否正确选择 Skill、是否遵守其中的限制、是否在调用外部工具前请求确认，仍然取决于模型推理和产品权限设计。

对开发者而言，Skills 的价值不在于把 Prompt 写得更长，而在于把工作流拆成清晰边界。例如：

• “资料研究”负责查找、筛选和整理来源；
• “数据分析”负责清洗表格、计算指标和识别异常；
• “写作编辑”负责结构、语气和格式；
• “邮件撰写”负责把最终结果转换成适合发送的文本；
• “发布检查”负责校验链接、敏感信息和格式错误。

这些能力可以分别维护，也可以在同一个任务中串联。相比把所有规则塞进一个巨型 Gem，这种拆分更便于调试、更新和复用。

为什么 Google 现在要放弃 Gems？

Google 此次调整的直接背景，是任务型 Agent 正从“聊天产品附加功能”变成独立的产品竞争方向。

TechCrunch 在报道中提到，随着 Meta 的 Muse、Instinct 等一体化 AI Agent 受到关注，Google 正在重新思考如何组织 Gemini 的任务自动化能力。市场竞争的重点已经从“模型能不能回答问题”，转向“Agent 能不能持续完成一项工作”。

Gems 的问题在于，它的产品隐喻仍然是聊天助手。每个 Gem 都像一个独立入口，用户需要知道应该打开哪个助手、向它提出什么指令。这种设计对单点任务很直观，但当任务涉及多个步骤、外部工具和后台执行时，多个 Gem 之间很容易形成孤岛。

Skills 的方向更适合 Agent 化产品，原因主要有三点。

第一，Skills 更容易组合

复杂工作通常不是一个角色能独立完成的。一次出差安排可能同时涉及日历、邮件、地图、酒店和报销；一次产品调研可能同时涉及网页检索、表格分析、文档生成和团队通知。

如果每个 Gem 都把这些能力打包在一起，用户最终会得到大量重叠的“超级助手”。Skills 则允许 Agent 按任务动态组合能力，减少重复配置。

第二，Skills 更适合后台运行

Gem 通常依赖用户主动进入对话，而 Spark 面向的是定时、触发式和后台任务。后台任务需要的是稳定的执行规则，而不是一个具有完整人设的聊天入口。

例如，“每天早上 8 点提供 AI 新闻”是任务，“抓取哪些来源、如何判断重复、如何输出摘要”则属于 Skill。任务和技能分开后，用户可以修改执行时间，而不必重建整个助手。

第三，Skills 更适合跨任务复用

一个“品牌语气”Skill 可以被市场周报、客服回复、邮件撰写和社交媒体发布共同使用。一个“公司报销规则”Skill 可以同时服务差旅预订、费用审核和财务问答。

从工程角度看，这相当于把一次性 Prompt 变成了可维护的配置资产。它可以版本化、导出、分发，并在不同任务中重复使用。

可下载和可分享，意味着生态可能改变

Google 的帮助文档显示，Skills 可以下载为 .zip 文件，这一点值得关注。它说明 Google 并不只把 Skill 看成用户个人设置，而是开始把它当作一种可以迁移和分发的工作流组件。

对普通用户来说，下载意味着可以保存自己的工作方法，或者把一套技能交给团队成员。对开发者和企业来说，它则意味着未来可能出现围绕 Skills 的共享仓库、模板市场和团队内部技能库。

不过，Skill 的可移植性仍然存在边界。一个 Skill 可能依赖特定的 Google 服务、账号权限、文件结构或 Spark 能力，下载文件并不代表可以无修改地迁移到其他 Agent 平台。它更像“带有运行环境假设的工作流模块”，而不是完全独立的软件包。

Google 在 Gemini CLI 和 Firebase 相关开发材料中也已经使用了 Agent Skills 的概念，技能通常以目录和 SKILL.md 文件组织，里面包含用途说明、执行指令和相关上下文。这表明 Google 正试图让 Skills 同时覆盖消费者端的 Gemini Spark 和开发者端的 Agent 工具链。

对开发者来说，SKILL.md 这类 Markdown 化描述有一个明显好处：门槛低、可读、容易进入 Git 仓库。它不像传统插件那样必须编译，也不像长 Prompt 那样只能藏在某个产品设置里。团队可以通过代码审查检查技能规则，再通过版本控制追踪修改。

这会影响 Gemini 用户什么？

短期内，Gems 用户最关心的不是概念，而是现有配置能不能继续使用、能否迁移以及数据是否保留。

目前公开资料并未给出所有 Gems 的具体迁移时间表，也没有说明每一种 Gem 是否会自动转换为 Skill。因此，已经依赖 Gems 处理写作、编程或知识整理的用户，不应默认所有配置都会原样迁移。

更稳妥的做法是提前保存以下内容：

1. Gem 的系统指令和角色设定；
2. 上传过的参考文件及其版本；
3. 输出格式、风格要求和禁止事项；
4. 使用过的示例输入与理想输出；
5. Gem 依赖的外部工具、邮箱、日历或云端文件权限。

这些信息决定了一个 Gem 能否被重建为 Skill。尤其是示例输入与理想输出，它们往往比一句“请写得专业一点”更能帮助新系统还原原有行为。

需要注意的是，Skills 目前与 Gemini Spark 绑定，而 Spark、任务、排程和技能属于 Google AI Ultra 订阅体系中的功能。Google 的帮助文档显示，如果用户降级或取消相关订阅，系统会保留部分数据，但会暂停或停用 Spark、任务、排程和技能等能力。

这意味着 Skills 虽然看起来更开放、更适合分享，但现阶段仍然是 Google Gemini 产品内部的能力，并非一个完全独立、跨平台的 Agent 标准。

与 GPTs、Claude Projects 等产品相比，Google 走的是另一条路

Gems、Skills、GPTs 和 Claude Projects 都在解决“如何让 AI 记住一套规则”的问题，但产品抽象并不一样。

| 产品形态 | 主要抽象 | 更适合的场景 | 主要局限 | |---|---|---|---| | Gemini Gems | 固定用途的自定义助手 | 个人写作、编程、学习和问答 | 入口和能力相对绑定 | | Gemini Skills | 可组合的 Agent 技能 | 后台任务、排程和多步骤工作流 | 当前依赖 Gemini Spark | | OpenAI GPTs | 可配置的专属 GPT | 共享助手、知识库和定制问答 | 复杂流程编排仍需额外工具 | | Claude Projects | 项目级上下文空间 | 长期项目、资料整理和团队协作 | 更偏上下文管理，不等同于完整技能系统 | | 传统 Prompt 模板 | 一段可复制指令 | 一次性任务和轻量复用 | 缺少自动调用、权限和流程状态 |

如果用户只是需要一个固定风格的聊天助手，Gems 或 GPTs 仍然更容易理解。Skills 的优势要在 Agent 具备后台执行、工具调用和多步骤规划之后才会真正体现出来。

换句话说，Google 不是把一个更好用的“自定义助手”换成另一个名字，而是在把产品重心从助手目录转向能力编排。这个方向更接近企业自动化，也更接近开发者理解的模块化系统。

对开发者的真正启示：技能需要像软件一样管理

Skills 普及后，最大的挑战不会是创建技能，而是管理技能。

一个能影响邮件、日历、文件和业务系统的 Skill，实际上已经具备了部分软件组件的属性。它需要明确输入和输出，需要记录版本，需要定义失败处理方式，也需要控制权限边界。

至少有四类问题值得提前考虑：

• 版本问题： 修改 Skill 后，旧任务是否仍然使用旧规则？
• 权限问题： Skill 是否可以直接发送邮件、删除文件或提交订单？
• 冲突问题： 两个 Skill 对输出格式和操作规则的要求不一致时，谁优先？
• 审计问题： Agent 为什么选择这个 Skill，执行了哪些步骤，最终由谁确认？

如果 Google 未来希望 Skills 进入企业环境，就不能只提供“保存指令”和“自动调用”，还需要补上权限审批、运行日志、版本回滚、团队共享和安全扫描等能力。

对个人用户来说，Skills 可以显著减少重复输入；对企业来说，Skills 可能成为“把组织经验写进 Agent”的载体。但后者也意味着风险：一旦错误规则被广泛复用，错误就会像软件缺陷一样批量扩散。

我们的判断：Skills 方向正确，但还不是成熟标准

Google 将 Gems 转向 Skills，是一次方向正确、但仍处于早期阶段的产品重构。

它解决了 Gems 作为独立助手时的几个结构性问题：能力重复、入口分散、难以组合，以及不适合后台任务。对于已经使用 Spark 处理定时任务和多步骤工作的用户，Skills 比单个 Gem 更符合 Agent 的工作方式。

但目前 Skills 仍有三个明显限制。

第一，它与 Gemini Spark 的绑定较强，用户不能把它当作完全独立的 Agent 插件使用。第二，自动识别技能依赖模型判断，错误调用和规则冲突仍然可能发生。第三，Google 尚未公开足够完整的迁移机制、版本管理和企业级治理方案。

因此，现阶段最准确的理解不是“Gem 已经彻底消失”，而是 Google 正在把 Gems 所代表的固定助手模式，重新拆解并吸收到以 Skills 为核心的 Agent 架构里。用户层面看到的是功能名称变化，产品层面发生的则是执行模型变化。

接下来值得观察三件事：现有 Gems 是否能够自动迁移；Skills 是否会扩展到普通 Gemini 对话和 Gemini CLI；以及 Google 是否会开放更明确的技能共享、权限控制和跨产品运行能力。

如果这些环节补齐，Skills 有机会成为 Gemini 生态中的“工作流基本单位”。如果只是把原有 Gem 换一个名称，却没有解决迁移、可观测性和权限问题，那么它仍然只是一次产品包装调整。

对开发者和重度用户而言，现在最值得做的不是重新创建大量 Gems，而是把已有 Prompt、参考资料和工作步骤拆分成清晰的能力模块，并为每个模块保留输入、输出和权限边界。未来无论 Google 继续使用 Skills，还是行业出现新的 Agent 技能标准，这种模块化资产都比绑定某个聊天入口更有长期价值。

参考来源

• TechCrunch：《Google is killing off Gemini’s Gems in favor of ‘skills’》，2026 年 9 月 28 日，报道 Google 从 Gems 转向 Skills 的产品变化及行业背景。
• Google Gemini CLI GitHub 仓库：Google 面向开发者的 Gemini CLI 项目，可用于了解 Agent Skills 在开发工具链中的实践方向。
• GitHub Agent Skills 主题搜索：用于观察开源社区围绕 Agent Skills、技能文件和可复用工作流的项目演进。