Skill：模块化任务流程以及工作原理解构
开发者初次接触Skill首先肯定会有个疑问：既然已经有了MCP能干活了，那为什么还需要Skill呢？ 其实顺着疑问反推就可以大概知道Claude为什么要提出这个“约定”：
- 1.经济性考虑：
模块化加载 = 算力最优解。模型上下文的冗余非常大，输入和输出都是token加上反复召回拼接，那就需要开发者精简且只保留需要的关键的部分的提示词，模块化加载提示词几乎是当下最优解，否则堆积拼接一堆用不到的提示词token后果就是浪费太多输入和输出算力，算力成本加上反复召回带来的token的整体消耗，不够经济不环保，这是最直接的原因； - 2.行为控制：减少自回归的"注意力噪声"，现有模型本身是自回归式的，上下文堆积得越多，干扰和无意义的算力也就越多，会影响最终的生成结果，就像你让模型查天气，没必要也把其他任务也也决策一遍，Skill就是告诉模型怎么专注的干事情，在提示词层面做到减少干扰；
- 3.MCP解决了"怎么调"的工程问题，Skill匹配解决的是"调哪个"的智能决策问题。MCP像是管道，Skill就行阀门，两者不是替代关系是分层的策略思维——只有阀门精准控制，管道中的算力才能高效流向正确的业务终点。
设想一下如果没有Skill的加载机制会导致哪些问题：
| 场景 | 纯MCP的问题 | Skill的解决 |
|---|---|---|
| 100个工具 | 全量Prompt爆炸 | 路由到1个Skill，加载1/100 |
| 多步任务 | LLM反复规划浪费Token | Skill内预编排，零规划消耗 |
| 高频固定流程 | 每次重新推理"先干嘛后干嘛" | 固化执行图，确定性延迟 |
| 精细化成本控制 | 无法区分"轻量查询"vs"重度生成" | Skill级别配额管理 |
归根结底，不是"有了MCP为什么还需要Skill"，而是"只有MCP的话，成本和复杂度扛不住"才有了Skill。
Skill 解决了“模块化”和“执行顺序”的问题，让模型能够遵循业务流程严谨地完成复杂的任务。
这就又引出一个新的问题：skill怎么解决模块化加载的问题？ 其实原理也很简单，方法也很多，Skill其实并没有规定严格的技术选型，是一种“约定”而非“规范”，还是一开始那句话：不要用结构化的定式思维路径来考虑问题，摒弃一些传统思维就会豁然开朗，优先用最低成本的方式匹配或者组合，原则上只要能达到在保持精准度的基础上最大限度减少大模型的Prompt的拼接总量就是最佳方案。以下是常见的策略：
| 方法 | 延迟 | 成本 | 精度 |
|---|---|---|---|
| 规则匹配（可缓存到KV存储） | 极低 | 极低 | 低 |
| Embedding 检索 | 低 | 低 | 中 |
| LLM 推理（不推荐，增加token消耗） | 高 | 高 | 高 |
| 训练路由模型（不推荐，增加token消耗） | 低 | 中（一次性） | 中高 |
匹配策略技术选型的问题实践经验：
可以自由组织匹配策略，从业务的角度来说，规则匹配和Embedding检索都能满足绝大部分常见，还能节省大量token消耗。
举个最典型的场景：用户提问里包含“订单”这个词，那就可以直接关键词匹配订单相关的Skill，抓取出来，这样就省去很多其他Skill的提示词，简洁高效。
Skill 作为一个模块化的按需提取加载的“能力包”，包含：
- 元数据：技能的名称和简短描述。
- SKILL.md：核心指令文档，告诉模型在特定任务中应该按什么步骤调用哪些工具。
- 相关资源：示例、参考文档等。
Skill 的运作流程：
- 系统加载所有技能的元数据（轻量级清单）。
- 根据用户问题，匹配最相关的技能。
- 动态加载该技能的 SKILL.md 到上下文。
- 模型根据技能指引，按顺序生成工具调用。
MCP 与 Skill 的协同
结合 MCP 和 Skill，一个完整的 Agent 工作流如下：
- 用户输入：例如“分析特斯拉股票并生成简报”。
- 技能匹配：系统匹配到
financial_analysis技能，加载其 SKILL.md。 - 构建提示词：将用户问题、技能指令、工具列表（来自 MCP）合并后发给模型。
- 模型决策：模型根据技能指引，依次输出工具调用（如
get_stock_data→calculate_ratios→generate_charts）。 - MCP 转发：MCP Client 将每次调用转发给对应的 MCP Server。
- 结果返回：工具执行结果通过 MCP 返回给模型，模型逐步推理并最终生成简报。
交流联系方式: github.com/ljq
