MCP 进化：让静态 Tool 进化为具备“上下文感知”的远程 Skills

聊几个核心判断：在工程落地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自动完成。

2. 服务端：打造有“判断力”的远程技能

服务端不再机械地响应请求了，而是根据Prompt的内容，主动判断自己的行为边界。

四、架构定位再思考：优势与边界并存

这套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），安全防线前移到协议入口。

• 业务解耦演进：
  所有业务规则、权限策略、指令模板都集中部署在服务端，客户端零侵入就能享用最新的能力迭代，协同成本和发布风险都大幅降低了。