据 TechCrunch 报道，在一体化 AI 智能体产品逐渐升温的背景下，Google 正在调整 Gemini 的功能方向：此前用于构建特定任务智能体的 Gems 功能将被结束，并转向名为 “skills” 的能力体系。来源显示，这一变化发生在 Meta 的 Muse、Instinct 等面向综合智能体的产品受到关注之际，Google 选择不再继续沿用 Gems 这一任务型代理构建入口，而是将相关能力整合到新的技能化框架中。
对普通用户而言，这可能只是 Gemini 产品界面与使用方式的一次变化；但对开发者、企业 API 使用者和 AI 应用集成方来说，这代表 Google 对“智能体能力如何被组织、调用和复用”的思路正在改变。过去的 Gems 更像是面向用户的定制化小代理，而 skills 更可能强调模块化能力、可组合任务和统一调度，这与当前大模型应用从“聊天”走向“执行任务”的趋势一致。
从 Gems 到 skills：Google 为什么调整智能体入口
Gems 的定位是让用户围绕具体任务创建定制化智能体，例如为某类工作流配置角色、目标或固定处理方式。此类设计适合个人效率场景，也便于用户快速搭建“专用助手”。不过，随着 AI 产品竞争进入智能体阶段，仅靠一个个独立的任务型代理，可能难以支撑更复杂的跨应用、跨步骤执行。
来源提到，Meta 的 Muse 和 Instinct 等一体化 AI agents 正在获得关注，这意味着行业焦点正在从“创建一个小助手”转向“让系统具备一组可被调度的能力”。在这种思路下，skills 更像是底层能力单元：模型可以根据用户意图选择合适能力，而不是要求用户预先进入某个 Gems 或手动切换特定代理。
这种调整并不必然意味着 Gemini 放弃智能体，反而可能是将智能体能力从前台功能迁移到更底层、更统一的架构中。对 Google 这类拥有搜索、办公、移动系统和云服务生态的公司来说，技能化能力如果能够统一接入，将比单点代理更容易扩展到多产品场景。
对 API 开发者和模型调用方的影响
从 API 与应用开发角度看，Gems 退场、skills 上位，最值得关注的是能力封装方式的变化。过去开发者往往围绕提示词、系统设定、工具调用和会话状态来构建一个“类智能体”。如果平台开始强调 skills，后续可能会推动更标准化的能力注册、调用和编排方式。
- 应用架构可能更偏模块化：开发者不再只设计一个完整代理，而是拆分为多个可复用技能，如检索、总结、表格处理、任务规划等。
- 调用链路可能更复杂：模型需要判断何时调用技能、调用哪个技能，以及如何把结果返回给用户，这会影响延迟、稳定性和成本控制。
- 平台兼容性更重要：如果不同模型厂商都推出自己的 skills 或 agent 能力，应用方需要考虑抽象层，避免被单一平台接口锁定。
- 中转与聚合服务价值提升：对于同时接入 OpenAI、Claude、Gemini 等模型的团队，统一鉴权、额度管理、并发控制和故障切换会变得更关键。
尤其是企业级场景，智能体能力通常不是单次问答，而是多轮、多工具、多权限的流程。skills 化之后，开发者需要更细地评估每一步调用的 token 消耗、工具执行时间、失败重试策略以及权限边界。对 API 使用者而言，成本不再只由“输入输出文本”决定，还会受到任务拆解和技能调用频率影响。
对 Gemini 生态和第三方接入的解读
Google 此次调整也反映出 Gemini 生态正在追赶更广义的智能体竞争。相比单独提供一个用户可见的代理创建功能，skills 更适合嵌入到产品和开发平台中，成为模型完成任务时可调用的标准能力层。若后续 Google 将其与 Gemini API、Workspace 或云端服务进一步结合，开发者可能会获得更直接的自动化能力，但也需要适配新的调用规范。
对通过 API 使用 Gemini 的团队来说，短期内应关注官方文档和接口变化，确认 Gems 相关能力是否影响现有工作流；中长期则应把“智能体能力”从应用层硬编码中抽象出来，例如将模型选择、工具调用、上下文管理和权限控制拆成独立模块。这样即便不同厂商的 agent/skills 方案变化，也能更平滑地迁移。
总体来看，Google 结束 Gems 并转向 skills，不只是一次产品命名变化，而是智能体能力组织方式的转向。未来 AI 应用竞争的重点，可能不再是谁能创建更多专用助手，而是谁能以更低成本、更高稳定性把模型、工具和业务流程连接起来。对于开发者和 API 调用方，提前设计可替换、可编排、可观测的模型调用架构，将比押注单一前台功能更稳妥。