Skill系列1：在Skill之前，大模型为什么“能想，却干不好活”？

我们都知道，大模型最擅长的事情，是理解语言。

它可以理解人类用自然语言发出的指令，并通过或简单、或复杂的思维链，一步步推理出结果。

从“理解问题”到“给出答案”，这一步，大模型已经做得非常优秀。

但问题是——
推理结果，并不等于问题被真正解决。

一、只有“大脑”，没有“手脚”

如果一个系统只有思考能力，却没有执行能力，那它本质上仍然是“空中楼阁”。

就像一个人再聪明，如果没有手脚，也无法真正完成任何现实世界的任务。

大模型也是一样：

• 能分析
• 能推理
• 能给建议

但它无法直接操作世界。

二、第一步补救：给模型“接上手脚”

于是，最自然的思路出现了——
给模型接入工具（Tool Calling）。

让模型不仅能“想”，还能“做”。

比如：

• 查天气
• 调用API
• 执行计算
• 操作数据库

这一步，确实让大模型从“会说话”，进化到“能做事”。

三、新问题：模型怎么知道自己能用什么工具？

但新的问题马上就出现了：

👉 模型并不知道“有哪些工具可以用”。

怎么办？

最直接的方式是：
把所有工具的信息，一股脑塞进上下文里。

让模型在推理过程中：

• 浏览所有工具
• 选择合适的
• 决定是否调用

四、小规模还行，大规模就崩了

如果你只有一两个工具，比如：

• 天气查询
• 简单计算

那问题不大，直接写进提示词就可以。

但当工具数量变多时，比如：

• 十几个
• 二十个
• 甚至更多

问题就开始失控：

• Prompt 变得极其臃肿
• 工具难以维护
• 升级成本极高
• 结构混乱

这时候，必须引入更工程化的方案。

五、MCP ：工程化管理工具

于是，MCP（Model Context Protocol） 出现了。

它的核心思路是：

👉 用一个统一的服务，把所有工具组织起来

并且对每个工具进行标准化定义：

• 参数结构
• 输入格式
• 输出格式
• 类型约束

从工程角度来看，这是一次非常重要的进步。

六、但新的问题更致命

MCP很快暴露出一个致命问题：

👉 上下文爆炸

为了让模型“充分理解工具”，MCP会：

• 把所有工具定义
• 所有参数细节
• 所有数据结构

完整地传给模型

举个更具体的例子：

• 一个模型上下文：128K
• 一个 MCP 定义：
  • 20 个工具
  • 接近 300 个参数

👉 光这些定义，就可能占掉 20K 上下文

更关键的是：

❗ 不管用不用，每一轮对话都会全部传入

七、这意味着什么？

这带来几个非常严重的问题：

• 上下文被大量浪费
• 成本显著上升
• 有效信息被稀释
• 推理质量反而可能下降

本质上，这是一个典型的：

👉 “为了可用性，牺牲效率”的设计问题

八、MCP的核心硬伤

也正是因为这个问题，MCP很快暴露出它的核心缺陷：

👉 它不具备“按需加载”的能力

所有工具：

• 必须提前全部声明
• 必须每轮全部传入

这在规模一旦上来时，就变得不可持续。

九、Skill横空出世

那么问题来了：

👉 有没有一种方式，可以：

• 让模型“知道工具”
• 但又不需要“每次都带全部工具”
• 同时还能保持工程化管理？

这，就是后面要讲的——Skill 机制

在下一篇里，我们会继续展开：

👉 Skill 是什么？
👉 它如何解决 MCP 的问题？
👉 为什么它更适合大规模系统？