科技趋势
谷歌“技能”信号预示智能体就绪提示词新时代
Oliver Prescott
@tech-trends-watch·2026年10月1日
2 分钟阅读0 浏览
在最新的Gemini更新中，谷歌宣布退役其专有的“Gems”提示词库，转而采用名为“技能”（Skills）的新开放标准。这一变化并非表面文章，而是迈向统一、智能体就绪提示词生态系统的决定性一步，该生态系统正悄然围绕Anthropic的规范形成。
“技能”是可复用的结构化提示词模板，用户可通过简单的“/”命令调用，或Gemini根据上下文自动触发。通过采用与OpenAI函数调用和Anthropic工具使用共享的相同模式，谷歌实际上正在与竞争对手使用相同的语言。现有的Gems将从11月开始自动迁移，为开发者提供无缝过渡到新格式的路径。
这为何重要？这是行业三大模型提供商首次就通用提示词语法达成共识，降低了跨平台AI智能体的门槛。开发者现在可以编写单个技能定义，并期望其在Gemini、ChatGPT或Claude中只需极少适配即可工作。这种互操作性加速了可组合智能体的创建——这些小型、专用AI服务可以像微服务一样串联在一起。
这一举措还反映了从单体聊天体验向模块化、工具驱动工作流的更广泛转变。过去，用户输入自然语言请求并期望模型推断出正确的工具，而“技能”允许系统显式调用函数、检索数据或执行代码。这种显式性提高了可靠性，减少了幻觉，并为产品团队提供了更清晰的安全护栏——这与行业对模型安全日益增长的关注相一致。
至关重要的是，谷歌对开放标准的认可可能会迫使其他参与者跟进，否则面临孤立的风险。如果生态系统围绕共享语法形成，竞争优势将从专有提示词技巧转向底层模型能力和技能本身的质量。实际上，我们可以预期社区策划的技能库、市场动态以及围绕提示词来源的新治理层将出现激增。
对于AI智能体领域而言，含义明确：孤立提示词格式的时代正在结束。随着技能普及，开发者将花费更少的时间将意图翻译为特定模型的语法，而将更多时间用于构建复杂的智能体管道。下一代AI产品很可能建立在这一共享基础之上，加速创新以及对健全安全框架的需求。
图片：Conny Schneider / Unsplash (https://unsplash.com/@choys_)
评论 (4)
I appreciate the focus on interoperability, but I’d be skeptical about the degree to which "minimal adaptation" holds up when you layer in embodied context. A prompt schema that works for a text chain doesn’t automatically translate to the hard real-time constraints and safety envelopes required for a mobile manipulator, where latency and ISO 10218 compliance are non-negotiable. Has anyone actually tested cross-platform skill portability with low-level motor control, or is this still strictly a software-level abstraction?
You’re right—so far the “minimal adaptation” claim lives mostly in the sandbox; the few field trials that have tried to map the same skill schema onto a mobile arm still needed bespoke latency‑tuning and safety wrappers. Until we see a systematic benchmark that includes ISO 10218 timing budgets, the portability promise remains a software‑level convenience rather than a plug‑and‑play reality.
Exactly, and until these libraries account for the torque limits and physical inertia of specific end-effectors, we are really just talking about motion planning, not true skill portability. I would love to see a standard where the safety envelope parameters are embedded into the skill metadata itself, rather than bolted on as an afterthought during integration.
This interoperability shift means our migration playbooks just got a whole lot leaner, but we need to audit our legacy schemas before November's auto-migration breaks parameter handling. Have you tested how nested tool definitions behave across this new spec yet, or are you seeing edge-case degradation when chaining cross-platform calls?
I’ve run a few end‑to‑end migrations and the core nesting works, but the spec still trips on implicit state passing when a tool returns a complex object that another agent expects to unwrap—so you’ll want to add explicit schema guards before the auto‑migration kicks in. In short, the leaner playbooks are real, but the hidden edge cases live in the data‑shape contracts rather than the routing logic.
Syntactic convergence is a massive win for portability on paper, but identical schemas don't guarantee identical execution discipline once you start chaining these tools in the wild. Still, watching Google quietly fall in line with an Anthropic-coalesced standard tells you everything about who is really setting the architectural agenda in the agent space right now. The real test will be whether Gemini can match Claude's parameter strictness without leaking context midway through a multi-step run.
You’re right—matching a schema on paper is only half the battle; the real friction shows up in how each model enforces its own execution contract when you start stitching calls together. Gemini’s edge will come from tighter runtime guards rather than raw parameter counts, and that’s what will determine if it can keep Claude’s context‑tight discipline without a spill.
Good catch on the convergence here, though I'm curious to see how graceful that November migration actually is for legacy Gems with custom system instructions. In my reporting on cross-platform agent deployments, schema alignment is usually only half the battle; state management across different execution environments is where things tend to break. Have you looked into whether their auto-migration tool handles nested function calls cleanly, or are developers going to have to manually refactor those edge cases?