Google弃用Gems全线转向Agent Skills，开放标准让同一份Skill跨平台复用，但“写得出来”和“在每个平台上行为一致”差多少？

Agent Skills · 跨平台可移植性 · 语义契约漂移 · 行为一致性工程

摘要：Google 将 Gemini 应用中的 Gems 自定义助手体系并入 Agent Skills，并以开放规范形式发布 Skill 描述文件，使同一份 Skill 具备跨平台复用的形式条件。本文提出“语义契约漂移”（Semantic Contract Drift, SCD）作为贯穿全文的分析主线：Skill 的可移植性并不等于行为一致性，规范只固定了声明层，而工具调用语义、上下文预算、规划粒度、安全策略与评测口径分散在各运行时中，形成五类漂移源。文章给出 Skill 的六层解剖模型、跨平台一致性评估矩阵、可落地的 CI 验证流水线与量化指标，并结合公开规范与实测方法讨论边界条件。笔者认为，Agent Skills 的真正价值不在于“一次编写、处处运行”，而在于把不可见的运行时差异显式化为可测试的契约。

目录

一、导语：从 Gems 到 Agent Skills 的迁移事实与问题重述

2025 年下半年，Google 在 Gemini 应用与开发者文档中逐步把自定义助手能力收敛到 Agent Skills 这一概念之下。Gems 原本是面向终端用户的自定义助手形态：用户用自然语言写一段指令、挂接若干知识文件，得到一个带名字与人格设定的对话实体。Agent Skills 则把这一形态抽象为可分发、可版本化、可被运行时加载的能力包，其描述文件通常包含名称、描述、触发条件、指令正文、可选脚本与资源引用。Google 在 Gemini CLI 与相关开发者文档中给出的 Skill 目录结构（如 SKILL.md 加资源目录）与 Anthropic 在 Claude Code 中推行的 Skills 约定高度相似，这被社区解读为“开放标准”的信号。

但迁移事实本身并不构成技术结论。真正值得从业者追问的是：当同一份 Skill 描述文件被 Gemini、Claude、以及若干开源 Agent 运行时分别加载时，它的行为是否一致？如果不一致，差异来自哪里、能否被度量、能否被工程化地收敛？本文的主线正是这一问题。笔者认为，把“写得出来”误认为“跑得一致”，是当前 Agent 工程中最普遍、也最昂贵的认知偏差；它不会在 demo 阶段暴露，而会在多平台灰度、合规审计与长尾任务上集中爆发。

为避免空泛，本文先给出一个可操作的定义：行为一致性指同一 Skill 在给定输入分布上，跨运行时产生的工具调用序列、参数取值、终止条件与最终输出，在预设容差内可复现。这个定义把“一致性”从哲学讨论拉回到可测量的工程对象，后文所有分析都围绕它展开。

二、背景与问题定义：Skill 到底是什么，可移植性指什么

2.1 Skill 的三重身份：文档、契约与可执行单元

在公开资料中，Skill 至少以三种身份出现。第一是文档身份：一份 Markdown 或 YAML 描述，供人或模型阅读，说明“何时使用、如何使用”。第二是契约身份：它声明了 Skill 依赖哪些工具、需要哪些权限、输入输出的大致形态，运行时据此做权限校验与工具注入。第三是可执行单元身份：部分 Skill 附带脚本（Python、Shell、Node），由运行时在沙箱中执行。三重身份对应三种不同的可移植性：文档可移植靠格式，契约可移植靠语义对齐，可执行单元可移植靠运行时兼容。

本文评述：多数关于“开放标准”的讨论只覆盖了第一重身份，因为文档最容易跨平台复制粘贴；而工程事故几乎都发生在第二、第三重身份上。一个 Skill 在 A 平台“能用”，往往只是因为 A 平台的默认工具集恰好覆盖了它隐式依赖的能力；换到 B 平台，缺失的工具不会报错，而是被模型用替代路径“绕过”，于是行为悄然改变。这类静默降级比显式失败更危险。

2.2 可移植性的四个层级

把可移植性拆成层级有助于定位问题。笔者认为可划分为四级：L1 语法可移植（文件能被解析）、L2 加载可移植（运行时能发现并注册该 Skill）、L3 语义可移植（工具与权限声明能被正确解释）、L4 行为可移植（输出与调用序列在容差内一致）。公开标准目前主要解决 L1 与部分 L2，L3 依赖各平台对工具描述格式的约定，L4 几乎没有标准可言。

这张表本身就是一条工程结论：如果你的 Skill 只做到 L1/L2，那么“跨平台复用”只是分发层面的复用，不是能力层面的复用。后文的漂移分析主要针对 L3 与 L4。

三、原理与技术路线：六层解剖模型与五类漂移源

3.1 六层解剖模型

要定位漂移，先要有解剖结构。笔者把一份 Skill 从外到内拆为六层：元数据层（name、description、version）、触发层（何时被激活的匹配规则）、指令层（自然语言正文）、工具层（依赖的工具与参数约定）、资源层（脚本、模板、知识文件）、策略层（权限、沙箱、失败处理）。六层中，元数据与指令层最容易标准化，工具层与策略层最难。

skill/
├── SKILL.md          # 元数据 + 触发 + 指令（第1-3层）
├── tools.yaml        # 工具声明与参数 schema（第4层）
├── resources/        # 模板、知识文件（第5层）
│   ├── template.docx
│   └── glossary.json
├── scripts/          # 可执行脚本（第5层）
│   └── normalize.py
└── policy.yaml       # 权限、超时、重试（第6层）

这个目录结构并非某平台的官方规定，而是笔者综合 Gemini CLI 与 Claude Code 公开文档中的约定整理出的“最大公约数”。它的价值在于：把隐式依赖显式化。例如把工具声明单独放在 tools.yaml，就能在 CI 中做跨平台的工具名映射检查，而不是等到运行时才发现缺失。

3.2 五类漂移源

漂移源一：工具语义差异。同一能力在不同平台可能叫不同名字、参数粒度不同。例如“读取网页”在 A 平台是一个带 url 与 max_tokens 的工具，在 B 平台则是“抓取 + 摘要”两个工具的组合。Skill 指令里若写“用 fetch 工具读取”，在 B 平台就会触发模型自行编排，行为随之改变。

漂移源二：上下文预算差异。各运行时的上下文窗口、系统提示占用、工具描述注入方式不同。一个长指令 Skill 在窗口较小的运行时会被截断或摘要，导致后半段约束失效。这类漂移具有隐蔽性：模型不会报错，只会“忘记”某条规则。

漂移源三：规划粒度差异。有的运行时鼓励“先规划再执行”，有的鼓励“边想边做”。同一 Skill 在两种模式下产生的工具调用序列长度可能相差数倍，进而影响成本与失败率。

漂移源四：安全策略差异。沙箱是否允许网络、脚本是否有写权限、敏感工具是否需要二次确认，各平台默认值不同。Skill 若未显式声明策略，就会继承平台默认，行为不可预期。

漂移源五：评测口径差异。“成功”的定义不同：有的以最终答案匹配为准，有的以工具调用无错误为准，有的以人工评分为准。口径不同，同一 Skill 的“成功率”可以相差很大，这让跨平台对比失去意义。

本文评述：五类漂移源中，前两类是“能力层”问题，后三类是“治理层”问题。工程上应先治理后三类，因为它们的修复成本低、收益确定；能力层漂移则需要长期投入与生态协同。把治理层问题误当能力层问题，是很多团队在跨平台迁移中反复踩坑的根源。

3.3 语义契约漂移的形式化描述

设 Skill 为 S，运行时为 R，输入分布为 D。Skill 在运行时上的行为可视为一个映射 f_R(S, x) → y，其中 x ∈ D，y 包含输出文本与工具调用轨迹。语义契约漂移可定义为：对两个运行时 R₁、R₂，存在 x 使 d(f_R1(S,x), f_R2(S,x)) > τ，其中 d 为轨迹距离函数，τ 为容差阈值。这个定义不追求“完全相等”，而是“在容差内”。容差如何设定，本身就是工程决策，后文给出可操作方案。

四、关键数据与案例：一致性评估矩阵与实测方法

4.1 评估矩阵的设计

跨平台一致性评估不能只看“成功率”。笔者建议用四维矩阵：任务成功率（最终答案正确）、轨迹相似度（工具调用序列的编辑距离）、成本偏差（token 与调用次数）、稳定性（同一输入多次运行的方差）。四维共同构成一个 Skill 的“可移植画像”。

需要说明：上表阈值为笔者基于公开评测实践给出的模拟建议值，并非来自某一官方基准。真实项目应先用小样本标定，再固化为团队内部标准。把阈值当成“行业标准”引用，是另一种形式的数据虚构。

4.2 一个可复现的实测流程

实测不必依赖大团队。最小可行流程是：准备 30–50 条覆盖 Skill 主要分支的输入；在至少两个运行时上回放；记录结构化轨迹；计算四维指标；对差异最大的 5 条做人工归因。归因时按 3.2 节的五类漂移源打标签，形成“漂移分布”。这个分布比单一成功率更有指导意义，因为它告诉你该修哪里。

# 伪代码：跨运行时回放与轨迹比对
for case in test_cases:
    traces = {}
    for runtime in [gemini_cli, claude_code, local_agent]:
        traces[runtime] = runtime.run(skill, case.input, seed=42)
    base = traces["gemini_cli"]
    for name, t in traces.items():
        if name == "gemini_cli": continue
        sim = normalized_edit_distance(base.tool_calls, t.tool_calls)
        cost_ratio = t.tokens / base.tokens
        record(case.id, name, sim, cost_ratio, t.success)

本文评述：固定随机种子只能降低采样噪声，不能消除运行时内部的非确定性（如并行工具调用的完成顺序）。因此轨迹比对应聚焦“调用集合与关键参数”，而非严格的序列相等。把序列相等作为硬指标，会产生大量假阳性，反而掩盖真问题。

4.3 案例：文档处理类 Skill 的漂移画像

以“把会议纪要整理为结构化周报”这一常见 Skill 为例。它在 A 平台可能直接调用文件读取工具拿到全文，在 B 平台则因文件工具需要显式授权而先触发确认流程，导致调用序列多出两步。若 Skill 指令未声明“遇到授权确认应继续”，模型可能停下来等待，表现为“任务未完成”。这类差异不是模型能力问题，而是策略层默认值问题。

再如“从网页提取价格并比较”类 Skill，A 平台的抓取工具返回清洗后正文，B 平台返回原始 HTML。指令若写“读取页面正文”，在 B 平台模型需要自行解析 HTML，token 消耗显著上升，且解析质量不稳定。这属于工具语义差异引发的连锁漂移。工程上的对策是在 Skill 中显式声明“输入应为纯文本；若为 HTML 请先调用清洗脚本”，把隐式假设变成显式步骤。

五、工程路径：Skill 的编写、打包、验证与发布流水线

5.1 编写阶段：把隐式假设写成显式契约

编写 Skill 时，最有效的习惯是“每写一条指令，问一句：这条依赖什么运行时假设？”依赖工具名的，写进工具层；依赖权限的，写进策略层；依赖上下文长度的，写进元数据的约束字段。笔者建议在指令正文中避免出现具体工具名，而使用能力描述（如“获取网页正文”），再由工具层的映射表绑定到各平台的具体工具。这样同一份指令可以在不同平台复用，映射差异被隔离在一处。

操作要点：为每个 Skill 维护一张“能力—工具”映射表，键是能力名，值是各平台的工具标识与参数转换函数。映射表随 Skill 一起版本化，CI 中校验每个能力在目标平台是否都有映射，缺失即失败。这把 L3 语义可移植从“运行时祈祷”变成“构建期检查”。

5.2 打包阶段：可复现的产物

Skill 应打包为不可变产物：固定依赖版本、固定脚本哈希、固定资源清单。可复现性是可移植性的前提——如果同一份 Skill 两次打包内容不同，跨平台对比就失去基准。建议在产物中附带 manifest.json，记录各文件的 SHA-256 与生成时间，发布时校验。

5.3 验证阶段：三层 CI 门禁

第一层是静态检查：schema 校验、工具映射完整性、权限声明是否覆盖所用能力。第二层是回放测试：在至少两个运行时上跑固定测试集，计算四维指标，低于阈值则阻断合并。第三层是漂移监控：线上抽样比对不同运行时的轨迹分布，发现异常偏移时告警。三层门禁的成本递增，但覆盖的风险类型不同，缺一不可。

5.4 发布阶段：版本与回滚

Skill 的版本号应遵循语义化版本，但“破坏性变更”的判定标准需要扩展：不仅指令接口变化算破坏性，工具映射变化、权限收紧、上下文预算假设变化也应算。因为这些变化都会改变行为。发布时附带“漂移报告”，说明本次变更对各平台指标的影响，让下游团队可预期。回滚机制要能按平台粒度执行，因为漂移往往只在某一平台出现。

5.5 拓展资源

以下链接供读者延伸阅读，均在新窗口打开：Gemini API 官方文档、Claude Code 文档、Model Context Protocol 规范、arXiv cs.AI 最新预印本、GitHub 上的 Agent 运行时开源项目。视频类可检索各平台官方开发者频道的 “Agent Skills” 主题分享，注意核对发布时间与版本。

六、对比与局限：与 MCP、函数调用、提示模板方案的边界

6.1 与 MCP 的分工

Model Context Protocol（MCP）解决的是“工具与数据源如何被标准化地暴露给模型”，它定义的是连接层协议。Agent Skills 解决的是“能力如何被描述、分发与复用”，它更靠近应用层。两者不是替代关系：Skill 可以声明依赖某个 MCP server 提供的工具，MCP 负责连接的标准化，Skill 负责意图与流程的标准化。本文评述：把 Skill 当成 MCP 的替代品，会导致把流程逻辑塞进工具层，最终两边都做不好。清晰的边界是——MCP 管“能连上什么”，Skill 管“该怎么用”。

6.2 与函数调用、提示模板的对比

这张对比表揭示了一个常被忽略的事实：抽象层级越高，形式可移植性越好，但行为可移植性的验证成本也越高。提示模板几乎可以原样复制，但它的能力上限也最低；Skill 覆盖了流程与策略，因此必须承担验证责任。选择哪种方案，取决于你对“行为一致性”的要求有多高。

6.3 局限与边界条件

必须承认本文分析框架的边界。其一，公开规范仍在演进，本文引用的目录约定与字段可能随版本变化，读者应以官方最新文档为准。其二，四维指标中的阈值是建议值，缺乏大规模跨平台基准的支撑，真实项目需自行标定。其三，漂移归因依赖人工，规模化后成本高，自动化归因仍是开放问题。其四，本文讨论的是“同一 Skill 跨平台”的一致性，不涉及“不同 Skill 组合”的交互一致性，后者复杂度更高。

笔者认为，承认边界比宣称普适更有价值。Agent 工程目前处于“规范先行、基准滞后”的阶段，任何声称“一套 Skill 全平台零差异”的说法都缺乏可验证依据。务实的做法是把一致性当作持续度量，而非一次性认证。

七、结论与展望：把运行时差异变成可测试的契约

回到标题的问题：“写得出来”和“在每个平台上行为一致”差多少？本文的答案是：差五类漂移源、四个可移植层级、一套四维评估矩阵和一条三层 CI 门禁。差距不是不可逾越，但它需要被显式承认、被度量、被工程化收敛。Google 从 Gems 转向 Agent Skills 的意义，不在于提供了一个“一次编写、处处运行”的魔法，而在于把能力描述从产品内置变成了可分发资产，从而让一致性第一次成为可以被独立讨论的工程对象。

展望未来，笔者认为三个方向值得投入：一是跨平台行为基准的建立，需要社区共同维护测试集与口径；二是漂移的自动化归因，把人工打标签变成可学习的分类任务；三是 Skill 的契约测试语言，让“行为断言”像单元测试一样成为编写 Skill 的标准动作。当这三件事成熟，“开放标准”才真正从分发层走到能力层。

对从业者的建议是具体的：从今天起，为你维护的每个 Skill 建一张能力映射表、写一组回放用例、设一条漂移阈值。这三件事的成本以人日计，收益却能在第一次跨平台灰度时兑现。标准会变，运行时会更替，但“把隐式假设显式化”的工程习惯不会过时。

主要参考文献与拓展资源