聊几个核心判断：在工程落地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生命周期模型，在原始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 ja va.util.ArrayList;
import ja va.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 getToolsName(Prompt prompt) {
//按角色动态分配工具可见性
List tools = new ArrayList();
tools.add("OrderQuery"); //基础查询权限全员开放
if ("ADMIN".equals(prompt.attr("user_role"))) {
tools.add("OrderCancel"); //仅限管理员调用
}
return tools;
}
@ToolMapping(description = "查询订单详情")
public String OrderQuery(String id) { ... }
@ToolMapping(description = "执行订单取消操作")
public String OrderCancel(String id) { ... }
}
四、架构定位再思考：优势与边界并存
这套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），安全防线前移到协议入口。业务解耦演进：
所有业务规则、权限策略、指令模板都集中部署在服务端，客户端零侵入就能享用最新的能力迭代，协同成本和发布风险都大幅降低了。
