4ier's Blog

AI Skill 的分发困境：工具与认证的断裂

13 Jan 2026

AI Skill 是可复用的专家经验封装——Prompt 承载知识与判断力，Tool 提供执行能力。这本该是 AI 时代的「App」形态。但现实是：Prompt 可以 git clone，Tool 和认证却不能。 越强大的 Skill，越难分发。

Skill 的价值：专业知识的民主化

Skill 的本质是什么？

Skill = Prompt (知识/判断/审美) + Tool (执行能力)

一个资深设计师的 Skill，可以把多年积累的审美判断和工作流固化下来；一个运维专家的 Skill，可以把故障排查的经验编码成可执行的检查流程。

这是真正的知识民主化——专家经验不再锁在个人脑中，而是可以分发、可以复用、可以交易。

方向没有问题。问题在于：当前的技术架构无法支撑这个愿景。

核心矛盾：分发链的断裂

看一下当前主流平台的能力矩阵：

平台 Prompt 分发 Tool 分发 认证分发
Claude Skills ✅ TOML 可分发 ❌ script 本地执行 ❌ 用户自配
OpenAI GPTs ✅ 云端托管 ⚠️ Actions 需配 endpoint ❌ 用户自配
Cursor Rules ✅ 纯文本 ❌ 无 tool 能力 ❌ 无

共同困境：Prompt 的分发已经解决，Tool 和认证的分发完全断裂。

这导致一个悖论：

纯 Prompt 的 Skill 容易分发，但能力有限； 带 Tool 的 Skill 能力强大，但几乎无法分发。

问题一：工具的编写与维护

以 Claude Skill 为例，当前的 script 执行模型是用户侧执行：

Skill 作者写 script → 用户 clone → 用户本地执行

这意味着什么？

  • 用户需要有 Python/Node 环境
  • 用户需要安装正确版本的依赖
  • Skill 作者无法控制执行环境
  • 跨平台兼容性是噩梦

对于开发者群体，这勉强可以接受。但如果目标是让「各行各业的专业用户」能够创建和使用 Skill，这就是致命的障碍。

一个设计师为什么要会配 Python 环境？一个律师为什么要理解 npm install 失败的报错？

本质问题：运行时归属。谁的机器，谁装依赖，谁维护环境。

问题二：认证的设计与分发

假设一个 Skill 需要调用图片生成 API、搜索 API、数据库 API，当前的认证模型是：

API Provider → 用户 → Skill

每个用户需要：

  1. 去 N 个平台注册账号
  2. 获取 N 个 API key
  3. 正确配置到 Skill 的环境变量或配置文件中
  4. 管理这些 key 的轮换和安全

这不是分发，这是劝退。

本质问题：信任链。外部 API 信任谁？谁持有 key？谁为滥用负责？

一个可能的方向：Server 态 MCP

MCP（Model Context Protocol）已经被 Claude 原生支持。如果把 Skill 的 Tool 层从客户端脚本改为服务端 MCP，架构变成：

当前：User → Claude → Local Script → External API
改进：User → Claude → MCP Server → External API

这能解决什么？

问题 解决方式
依赖管理 服务端统一安装维护，用户无需配置环境
认证管理 服务端持有底层 API key，对用户暴露代理认证
跨平台 用户只需要 MCP client，与本地环境无关
版本更新 服务端更新，用户无感知

但这不是银弹。Server 态引入了新的问题：

  • 延迟：网络调用不可避免
  • 成本：服务器谁来付钱？
  • 隐私：用户数据经过第三方服务器
  • 依赖：Skill 作者被绑定到特定平台

这是一个 trade-off，不是完美解。但在当前的技术条件下，这可能是最务实的路径。

另一个 Trade-off：Context 膨胀

MCP 方案还有一个容易被忽视的问题：工具定义会吃掉大量 Context Window。

问题有多严重？

根据社区讨论的实际数据：

指标 数值
每个工具的 Schema 开销 ~80 tokens
106 工具的 MySQL MCP Server 54,600 tokens（仅初始化）
开发者实际场景 70-400 个工具规模

关键问题在于：MCP 当前的设计是全量预加载——所有工具定义在会话开始时就注入 Context，即使你只用其中 2-3 个工具。

如果一个 Skill 平台集成了多个 MCP Server，每个 Server 暴露几十个工具，Context 会被工具定义迅速填满，留给实际对话的空间反而被压缩。

社区正在探索的方向

1. Lazy Tool Loading (LTAP) — GitHub Discussion #1945

核心思路：不再一次性加载所有工具 Schema，而是：

  • 会话开始时只加载压缩的关键词索引（每工具 ~4 tokens）
  • LLM 需要时再请求特定工具的完整 Schema
  • 任务完成后自动释放

声称可实现 82-182 倍的 token 效率提升。

2. Primitive Groups — GitHub Discussion #1567（83 票支持）

思路：给工具分组，让 LLM 先选组再选工具，减少决策复杂度和 Context 占用。

3. 动态服务器管理 — GitHub Discussion #2044

允许运行时 add/remove MCP Server，按需连接，用完断开。

对 Skill 分发的启示

这意味着 Server 态 MCP 方案需要额外考虑：

  1. Skill 设计层面：精简工具数量，合并相似功能，避免工具爆炸
  2. 平台层面：实现工具的按需加载，而非全量注入
  3. 长期：等待 MCP 协议层面的官方支持

Context 膨胀不是致命问题，但确实是一个需要在架构设计阶段就考虑的约束。

更远的思考

真正解决 AI Skill 分发问题，可能需要一个新的协议层：

  • 类似 npm/pip 的包管理，但包含执行环境的完整描述
  • 类似 OAuth 的认证协议，但为 AI Agent 场景设计
  • 可能基于 WASM 实现真正的跨平台执行

这不是短期能实现的。但问题已经清晰：

Skill 生态的繁荣，卡在工具和认证的分发上。谁先解决这个问题，谁就能定义 AI 时代的应用分发范式。

Related Posts