过去两年，大模型能力的提升有目共睹。
对话越来越自然，推理能力不断增强，看起来几乎“无所不能”。
但在真实的工程实践中，很多人都有类似的感受：
Demo 很惊艳，真正落地却并不轻松。
问题往往不在模型能力本身，而在于：
我们仍然在用早期的工程抽象，承载已经高度复杂的 AI 能力。
本文尝试从工程视角，回顾 AI 应用从「对话」到「Skills」的演进路径。
一、只能对话的 AI：语言生成阶段
最早一批 AI 应用，本质上可以抽象为：
Prompt + Model = 一个“超级文本接口”
它们擅长：
- 问答
- 翻译
- 总结
- 多轮对话
在工程上，这类系统通常具备几个特征：
- 无状态或弱状态
- 不依赖外部系统
- 非常容易做出 Demo
但它们也有一个根本性的限制：
AI 只能“说”，不能“做”。
一旦需求从“回答问题”升级为“完成任务”，这种形态很快就会触顶。
二、推理能力增强：AI 开始“像人一样思考”
随着推理能力的增强，AI 开始具备：
- 多步推理能力
- 任务拆解能力
- 条件判断和规划能力
这使得 AI 看起来不再只是“生成答案”，而是在解决问题。
然而，工程实践很快暴露出新的边界：
- 推理过程只存在于语言空间
- 推理结果无法被执行
- 无法验证推理是否真正正确
AI 变得更聪明了，但仍然无法影响真实世界。
要真正完成任务，AI 需要具备“行动能力”。
三、Tools：AI 第一次真正“做事”
Tools（或 Function Calling）的出现，是 AI 应用的第一个工程拐点。
它让 AI 可以：
- 调用 API
- 查询数据库
- 操作系统或业务服务
从此，AI 开始具备：
推理 → 决策 → 执行 → 反馈 的闭环能力。
这一步意义重大，它让 AI 从“语言助手”迈向了“执行参与者”。
但问题也随之而来：
- 每个系统都以不同方式定义工具
- 工具描述高度依赖 Prompt
- 工具越多，Prompt 越臃肿
- 安全、权限和可维护性开始失控
Tools 解决了“能不能做事”，却引入了新的工程复杂度。
四、MCP：让工具使用成为基础设施能力
当工具数量不断增长时，单靠 Prompt 协调工具已经不可持续。
这正是 MCP（Model Context Protocol）出现的背景。
可以这样理解 MCP：
MCP 并不是让 AI 更聪明，而是让 AI 使用工具这件事变得可工程化。
它关注的不是业务逻辑，而是工具使用的“基础协议”问题：
- 工具如何被发现
- 工具如何被描述
- 工具如何被安全调用
- 模型如何与工具解耦
在系统架构中，MCP 的角色更接近：
- JDBC
- OpenAPI
- gRPC
它解决的是 “怎么连”，而不是 “连了要干什么”。
五、Skills：从工具能力到业务能力
即使有了 MCP 和 Tools，很多团队仍然会发现：
把真实业务直接交给 AI，依然非常困难。
原因并不复杂：
- 一个业务场景往往需要多个工具协作
- 有明确的执行顺序和条件
- 需要状态管理
- 需要异常处理和回滚逻辑
如果把这些逻辑全部塞进 Prompt，本质上是在编写一种：
不可测试、不可维护、不可复用的“脚本”。
于是，Skills 这个抽象开始浮现。
什么是 Skill？
- Skill 是一个面向业务语义的能力单元
- 内部编排多个工具
- 对外提供清晰、稳定的能力描述
从工程视角看，它非常接近：
- Service
- Use Case
- 业务能力组件
关键变化在于：
- Prompt 从“操作说明”变成“意图表达”
- 复杂流程被移出 Prompt，进入可维护的工程结构
- AI 应用开始真正具备业务能力
Skills 是 AI 从“会用工具”走向“能完成业务”的关键一步。
六、回顾：抽象是如何一步步上移的
回顾这条演进路径，可以清晰看到工程抽象的上移过程：
- 对话：语言生成能力
- 推理：决策与规划能力
- Tools：执行能力
- MCP：协议与规范
- Skills：业务能力
这并不是一部模型升级史，而是一条工程抽象不断上移的路线。
结语：为 AI 设计系统，而不是给 AI 接系统
当 Skills 开始承载业务语义时，AI 应用已经不再只是“模型的外壳”。
我们正在从：
给 AI 接系统
走向：
为 AI 设计系统。
这也许才是 AI 应用真正进入工程时代的开始。