Skills 的问题与解决方案

2026年02月08日

Skills 的问题与解决方案

一、当前 Skills 设计的三大困境

在 AI Agent 系统中，Skills（技能）是连接大模型与外部世界的桥梁，但目前的设计面临三大结构性问题：

1. 运行时依赖困境

现有 Skills 普遍采用 Prompt + Scripts 模式。Scripts 必然绑定特定运行时（Python/Node/Bash 等）和包管理器。如果去掉 Scripts，Skills 就退化为"大号 Prompt"，失去实际操作能力。这是一种权衡：要实现能力实体化 ，就难免引入环境依赖。

2. 组合性瓶颈

用现有 Skills 构建更复杂的 Skills 往往需要人工手动编排。在 AI 时代，这显得效率低下。Scripts 作为代码，使得自动化组合非常困难------变量冲突、依赖版本、执行环境差异都会成为障碍。

3. 路由成本过高

安装大量 Skills 后，每次执行任务前，系统都需要进行技能路由（Intent → Skill 匹配），这会消耗大量 Tokens。一个缓解方案是使用小型本地模型（如 Qwen3-0.6B）在边缘进行路由，减少对云端大模型的调用。

二、破局关键：分离决策与执行

解决问题的核心在于解耦 ------将"技能的定义"与"技能的执行"分离开。这正是模型上下文协议（Model Context Protocol，MCP） 的价值所在。

MCP 是一种标准化协议，让大模型可以通过统一接口安全地访问外部工具、数据和资源。将其引入技能架构后，技能的定义不再包含具体代码，而是声明式地描述需要调用哪些 MCP 服务（资源或工具）以及调用的顺序。

旧模式（问题根源） ：技能 = Prompt（做什么） + Script（怎么做）
新模式（解耦方案） ：技能 = Prompt（任务目标与规范） + mcp_client_desc（能力需求与流程蓝图）

这里的 mcp_client_desc 是一个纯文本的声明式描述文件（如 JSON 或 YAML），它说明了该技能需要调用的 MCP 服务器、资源、工具，以及参数映射和数据流逻辑。

将 Skills 改造为 Prompt + MCP Client Descriptor 带来了根本性变化：

可合并性（Mergability）

维度	Scripts（代码）	MCP Desc（数据）
语法冲突	变量名、依赖版本、运行时冲突	无，纯声明式
语义合并	需要理解代码逻辑	字段级合并，操作标准
版本回滚	复杂，涉及环境依赖	单文件快照，可瞬间恢复
审查成本	需要代码审查	配置审查，支持自动化规则

纯文本 Skills 支持 GitOps 工作流：基础模板 → 领域变体 → 用户定制，可以层层合并而不会产生冲突。

解锁的新能力

运行时合成（Zero Install）：Agent 启动时动态合成最终技能，纯内存操作，无需下载、安装 Scripts 或启动沙箱。
集体智能：社区共享 Skill 模板，个人 Fork 后定制，上游更新时可自动合并。
环境适配：通过切换 Server Endpoint，同一 Skill 可在开发/生产等不同环境中运行，实现配置即代码。

三、新范式的核心挑战：MCP Server 的部署负担

理想虽好，但新范式面临一个现实挑战：MCP Server 本身的部署负担。这很可能是当前 Skills 设计选择 Scripts 模式的原因。

通过 Script 操作 Excel，目标机器只需要有 Python 和 pandas 库。而通过 MCP，则需要在本地或网络部署并运行一个专门的"Excel MCP Server"，这提高了使用门槛。

因此，技能范式的迁移成功，不仅取决于描述层的革新，更取决于 MCP Server 生态的成熟与易用性。目前有两条技术路线：

短期路线（利用 GraalVM 等统一运行时）：利用能兼容多语言（Java, Python, JS）的高性能运行时，将现有代码库快速"封装"成 MCP Server。此举能快速丰富 MCP 工具生态，但可能带来性能损耗和复杂度。
长期路线（统一到 JS/TS 运行时）：将 MCP Server 的开发与运行统一到 JavaScript/TypeScript 生态（基于 Node.js、Bun、Deno）。这能提供更一致的开发体验、依赖管理和轻量服务，并利用庞大的 npm 生态，有望成为主流标准。

无论哪条路线，成功的标志都是让 MCP Server 的部署变得简单，可能通过智能伴生安装、云-边协同架构或统一的应用商店/管理器来实现。

四、关键基础设施：四个待解决问题

要建立成熟的 Skills 生态，需要依次解决以下问题：

1. 建立集中的 JS MCP Server 仓库（生态基础）

现状痛点：

发现困难：GitHub 搜索碎片化
安装繁琐：各仓库需手动 clone 和 npm install
版本混乱：缺乏语义化版本，变更频繁且不兼容
信任缺失：任意代码执行，缺乏审计

目标形态：提供类似 npx 的体验，但针对 MCP 优化。

bash 复制代码

npx mcp install @mcp/excel      # 安装并注册
npx mcp run @mcp/excel          # 标准化配置加载
npx mcp list --category=data    # 分类发现
npx mcp audit @mcp/excel        # 安全扫描

2. 将 Skills 迁移到 Prompt + MCP Desc（架构升级）

迁移方式：

yaml 复制代码

# 旧模式: Skill = Prompt + Scripts
old_skill:
  prompt: "处理 Excel {{file}}"
  script: |
    import pandas as pd
    df = pd.read_excel(...)

# 新模式: Skill = Prompt + MCP Client Desc
new_skill:
  prompt: "处理 Excel {{file}}"
  mcp_client:
    server: "@mcp/excel"
    tool: "process_workbook"
    input_schema: {file: "path"}
    fallback: "explain_failure"

3. 制定 Skills Router 规范（调度协议）

当前各 Agent 自行实现路由（如 OpenAI Function Calling、LangChain Tool 选择等），导致 Skill 无法跨 Agent 复用。需要标准化：

输入：用户意图 + 上下文 + 可用 Skills 列表
输出：选中的 Skill + 置信度 + 提取的参数 + 降级策略
规划：支持多步骤的有向无环图依赖关系

4. 实现小型模型路由（成本优化）

分层路由协议：

复制代码

第一层：意图分类（小型模型，本地运行，如 Qwen3-0.6B）
   ↓ 输出：领域标签
第二层：Skill 匹配（向量检索，本地或远程）
   ↓ 输出：Top-3 候选 Skills
第三层：参数填充（大语言模型，远程）
   ↓ 输出：最终调用参数

六、结论：从代码资产到数据资产

Skills = Prompt + MCP Client Desc 是"AI Native"的正确抽象。

这一转变实现了：

可合并性：版本控制友好，支持自动化合并策略。
可传输性：纯文本，零依赖，即插即用。
可组合性：声明式编排，支持动态工作流生成。
可治理性：集中化仓库，支持结构化审计。

Scripts 如同工业时代的重型机械，而 Desc 则是信息时代的比特流。随着 MCP 仓库的标准化和小型模型路由的成熟，AI Agent 基础设施将从"代码执行"演进为"能力调度"------这不是过渡方案，而是AI 时代的软件定义能力基础设施。