在 AI Agent 的工程落地过程中，Model Context Protocol（MCP）已逐渐成为大模型与外部系统交互的事实标准接口。然而，当应用边界从轻量级“个人助理”延伸至高复杂度的“企业级业务流程”时，传统 MCP 的交互范式暴露出明显的 “静态化”缺陷。
Solon AI 提出将 MCP 封装为 Skill 的设计理念，推动工具能力从“被动暴露的 API 列表”，跃迁为“能理解场景、响应上下文、受控执行”的智能技能单元。
一、传统 Tools 的三大现实困境
当前多数 MCP 实现方式，类似于一个“永不休眠的工具仓库”——无论用户意图为何，所有可用功能均被无差别加载：
- 上下文污染（Context Noise）： 即便处理一句“你好”，模型仍需接收数百行冗余的工具 Schema 描述，不仅挤占宝贵 Token 预算，更易导致语义干扰，削弱推理准确性。
- 权限裸奔（Security Risks）： 工具可见性为“全量可见”，缺乏运行时策略控制。无法依据当前会话身份（如普通员工 / 超级管理员）实时屏蔽高危操作（例如：删除核心客户数据）。
- 行为失焦（Instruction Gap）： 工具仅声明“我能做什么”，却未提供“此刻该怎么做”的上下文引导。模型缺少面向具体业务阶段的即时约束与行为提示。
二、破局之道：感知力 + 挂载机制 + 动态分发
Solon AI 引入 Skill（即 Solon AI Skills）生命周期模型，对原始 MCP 协议进行增强封装，构建起三层协同机制：
A. 智能准入判断（isSupported）：
仅当 Prompt 中携带的语义意图、租户标识、环境参数等满足预设条件时，该 Skill 才被纳入本次调用候选集。
B. 上下文指令注入（getInstruction）：
在 Skill 加载阶段，自动向模型注入适配当前上下文的系统级提示（System Message），例如租户专属规则、时效性限制或合规要求。
C. 三阶工具路由（getToolsName）：
服务端依据 Prompt 属性动态裁剪工具列表，支持三种策略模式：
- 全量开放：未配置过滤逻辑时，默认返回全部注册工具；
- 精准授权：按角色、租户、时间窗口等维度筛选，仅暴露合法可用工具；
- 主动熔断：即使 Skill 处于激活状态，也可因安全策略触发“零工具可见”策略。
三、真实开发场景还原
1. 客户端：以业务语义为中心调用
开发者只需注入关键业务属性（如租户 ID、用户角色），工具筛选与协议协商均由 Skill Client 自动完成。
import org.noear.solon.ai.chat.ChatModel;import org.noear.solon.ai.chat.prompt.Prompt;import org.noear.solon.ai.mcp.McpChannel;import org.noear.solon.ai.mcp.client.McpClientProvider;import org.noear.solon.ai.mcp.client.McpSkillClient;//初始化 mcp 客户端McpClientProvider mcpClient = McpClientProvider.builder() .channel(McpChannel.STREAMABLE) .url("http://localhost:8081//skill/order") .build();//构造含业务上下文的提示词Prompt prompt = Prompt.of("帮我取消订单 A001") .attrPut("tenant_id", "solon_001") .attrPut("user_role", "ADMIN"); //模拟管理员身份//绑定技能客户端，模型将仅接收符合权限的工具定义chatModel.prompt(prompt) .options(o -> o.skillAdd(new McpSkillClient(mcpClient))) //将 mcp 客户端包装为 Solon AI Skill .call();
2. 服务端：打造有“判断力”的远程技能
服务端不再机械响应请求，而是基于 Prompt 内容主动决策自身行为边界。
import org.noear.solon.ai.annotation.ToolMapping;import org.noear.solon.ai.chat.prompt.Prompt;import org.noear.solon.ai.mcp.McpChannel;import org.noear.solon.ai.mcp.server.McpSkillServer;import org.noear.solon.ai.mcp.server.annotation.McpServerEndpoint;import java.util.ArrayList;import java.util.List;@McpServerEndpoint(channel = McpChannel.STREAMABLE_STATELESS, mcpEndpoint = "/skill/order")public class OrderSkillServer extends McpSkillServer { @Override public boolean isSupported(Prompt prompt) { //意图识别：仅当用户提及“订单”且租户信息有效时启用 return prompt.getUserContent().contains("订单") && prompt.attr("tenant_id") != null; } @Override public String getInstruction(Prompt prompt) { //注入租户定制化指令 return "你现在是租户[" + prompt.attr("tenant_id") + "]的订单助手，请严格遵守其服务协议。"; } @Override public List
四、架构定位再思考：优势与边界并存
尽管 Skills 模式显著提升了 MCP 在企业级场景下的适应性，但其本质仍需被理性认知：
- 非协议层标准增强：
LLM 原生能力仅涵盖 Prompt 输入与 Tool-Call 输出。Skills 并非 LLM 或 MCP 规范中的官方组件，而是一种由框架层（如 Solon AI）实现的架构抽象模式，用于应对多变业务调度需求。
- 消费端主导的设计范式：
MCP 向 Skills 的演进并非服务端单方面升级，而是强依赖消费侧（Agent 引擎）的能力支持。远程 Skill 的设计必须遵循目标引擎所约定的解析逻辑与扩展规范。
- 场景适配建议：
Tool：适合功能单一、无状态、无需上下文干预的原子能力（如天气查询、单位换算）；
Skill：适用于需融合租户隔离、角色鉴权、流程引导、时效控制等复合要素的业务模块（如审批流、订单管理、工单协同）。
五、价值提炼：一次进化带来的三重增益
将 MCP 升级为 Skills 后，AI Agent 架构将获得以下核心收益：
上下文极致精简：
模型仅接收当前会话真正需要的工具定义（通过getToolsName实现按需加载与权限裁剪），Token 利用率与推理稳定性同步提升。权限天然内嵌：
工具可见性由服务端实时判定，实现跨进程、跨服务的 RBAC 级别细粒度管控（RBAC for Tools），安全防线前移至协议入口。业务解耦演进：
所有业务规则、权限策略、指令模板均集中部署于服务端，客户端零侵入即可享用最新能力迭代，大幅降低协同成本与发布风险。
源码地址：点击下载
