面试官问我：“你会做 AI Skill 吗？”
那次面试我记得很清楚。
我在聊 AI Agent 项目。
前面一直很顺。
RAG、工作流、Function Calling、Prompt、知识库召回，全都聊过去了。
面试官突然插了一句：
“你们 Agent 的 Skill 怎么设计的？”
我当时脑子里第一反应：
“Skill？不就是工具调用吗？”
结果对方连续追问：
* Skill 和 Function Calling 有什么区别？
* 为什么很多 AI Agent 项目后期都在补 Skill 层？
* 没有 Skill，会出现什么工程问题？
* Skill 是 Prompt 包装，还是能力抽象？
* Skill 如何复用？
* Skill 怎么做权限和参数约束？
那一刻就暴露了问题。
很多人会做 AI Demo。
很多人也会搭工作流。
真正卡在面试里的，往往是：
你有没有“工程化理解”。
现在 AI Agent 项目越来越像后端系统。
只会 Prompt，已经不够了。
不会 Skill，你会发现：
* Agent 能跑
* Demo 能演示
* 工作流能执行
但项目会越来越乱。
工具越来越多。
Prompt 越来越长。
权限越来越失控。
维护成本越来越高。
很多团队现在招 AI 工程师，已经开始默认：
你至少得知道：
* Skill
* MCP
* Function Calling
* Tool Registry
* Agent Routing
这些东西之间到底是什么关系。
* * *
## Skill 到底是什么？
一句话定义：
**Skill 是 AI Agent 中“可复用能力单元”的工程化封装。**
它不是单纯 Prompt。
也不是单纯函数。
它更像：
> “带有输入、输出、规则、描述、权限、上下文的能力模块。”
你可以理解成：
类比对象 对应关系
后端 Service Skill
API 接口 Tool
Prompt 模板 Skill 内部逻辑
SDK Skill 调用层
插件能力 Skill 暴露方式
很多人第一次接触 Skill，会误以为：
“这不就是 Function Calling？”
不完全对。
Function Calling 更偏：
> “模型调用函数”
Skill 更偏：
> “系统组织能力”
这两个粒度完全不同。
* * *
## 为什么 AI 项目越来越需要 Skill？
很多 AI 项目前期都很简单。
比如：
`用户输入→ Prompt→ 大模型→ 返回结果`
项目上线一个月后。
问题开始出现：
* Prompt 到处复制
* 参数规则没人统一
* 工具描述越来越混乱
* Agent 不知道该调哪个工具
* 工作流无法复用
* 新人不敢改 Prompt
尤其团队多人协作时。
你会发现：
Prompt 工程根本不够。
项目缺的是：
* 能力组织
* 调用约束
* 权限边界
* 输入输出规范
* 复用机制
Skill 本质上解决的是：
> “AI 能力如何像后端模块一样管理。”
* * *
## Skill vs Function Calling
这是最容易被问的。
也是面试高频点。
对比维度 Function Calling Skill
本质 模型调用函数 能力抽象层
粒度 单函数 多步骤能力
是否包含 Prompt 不一定 通常包含
是否包含权限 很少 经常需要
是否可复用 较弱 强
是否偏工程化 中 高
主要作用 调工具 管能力
使用方 LLM Agent 系统
典型场景 查天气“订单分析能力”
很多项目里：
一个 Skill 内部可能调用：
* 多个 Function
* 多个 API
* 多个 Prompt
* 多个工作流节点
* * *
## 一句话总结
Function Calling 是“模型怎么调用函数”。
Skill 是“系统怎么组织 AI 能力”。
* * *
## Skill vs Prompt
很多新人会把 Skill 当 Prompt 模板。
这也是错误理解。
对比维度 Prompt Skill
本质 提示词 能力模块
作用 引导模型生成 提供系统能力
是否可独立运行 不一定 通常可以
是否有输入输出规范 弱 强
是否支持复用 一般 强
是否能做权限控制 几乎不能 可以
是否适合多人协作 差 强
是否适合大型项目 有限制 更适合
很多 Prompt 工程后期都会变成：
Prompt + Tool + 参数 + 规则 + 上下文
这时候其实已经开始 Skill 化了。
* * *
## Skill 在项目里到底怎么用？
真实项目里。
Skill 通常长这样：
`skills/├── order_query/│ ├── skill.yaml│ ├── prompt.md│ ├── api.py│ ├── schema.json│ └── examples/│├── customer_service/│ ├── skill.yaml│ ├── workflow.py│ └── tools/│└── report_analysis/ ├── skill.yaml ├── charts.py └── rag/`
你会发现：
Skill 已经不是一句 Prompt 了。
它开始包含：
* Prompt
* API
* 参数定义
* 工作流
* 权限
* 输入输出结构
* RAG 检索
* Tool 调用
这才是真正工程化的 AI 项目。
* * *
## 一个最简单的 Skill 例子
比如：
“订单查询 Skill”
很多人写法：
`prompt = f”””请查询用户订单:用户ID: {user_id}”””`
这种 Demo 可以跑。
项目一定会越来越乱。
Skill 化之后：
`name: order_querydescription: 查询用户订单信息input: – user_idoutput: – order_listpermissions: – order.readtools: – mysql_query – order_api`
然后：
`class OrderQuerySkill: def run(self, user_id): orders = query_order(user_id) return { “orders”: orders }`
这里的重点已经变成：
* 输入规范
* 权限
* 能力复用
* Tool 管理
* 统一调用
而不是 Prompt 本身。
* * *
## Skill 为什么特别容易成为面试考点？
因为它特别能区分：
* Demo 开发
* 工程化开发
很多人会：
* LangChain
* Dify
* n8n
* Prompt
* RAG
但一问：
“你怎么管理能力？”
就开始模糊。
面试官真正想知道的是：
你有没有：
* 模块化思维
* 系统设计能力
* Agent 工程认知
* * *
## Skill 和 MCP 是什么关系？
现在 AI 圈经常一起出现：
* MCP
* Skill
* Tool
* Function Calling
很多人直接看懵。
这里给一个最容易理解的关系。
概念 作用
Function Calling 模型调用函数
Tool 可执行工具
Skill 对能力进行组织
MCP 管理上下文与能力协议
Agent 决定调用谁
你可以理解成：
`Agent ├── Skill │ ├── Tool │ ├── Prompt │ └── Function Calling │ └── MCP └── 管理上下文和协议`
* * *
## 学 Skill 的正确入门路线
很多人一上来：
* 学 LangGraph
* 学 AutoGen
* 学 MCP
* 学多 Agent
结果完全懵。
因为底层抽象没建立。
真正合理的学习顺序：
* * *
## 第一步：理解 Tool
目标：
知道：
* Tool 是什么
* Tool 如何调用
* Tool 如何定义参数
建议练习：
* 天气查询
* SQL 查询
* HTTP API 调用
推荐：
* Python
* FastAPI
* OpenAI Function Calling
* * *
## 第二步：理解 Function Calling
目标：
知道：
* 模型为什么能调函数
* JSON Schema 为什么重要
* 参数约束怎么做
练习：
`tools = [ { “type”: “function”, “function”: { “name”: “get_weather”, “parameters”: { “type”: “object”, “properties”: { “city”: { “type”: “string” } } } } }]`
你会开始理解：
AI 工程已经开始进入：
“接口设计”阶段。
* * *
## 第三步：开始封装 Skill
目标：
学会：
* 能力复用
* Prompt 模块化
* Tool 编排
* 权限控制
建议项目：
* AI 客服
* AI 数据分析
* AI 运维助手
* AI SQL Agent
* * *
## 第四步：理解 MCP
MCP 最近很火。
很多人以为：
“MCP = Agent 框架”
这也不对。
MCP 更像：
> “AI 能力之间的标准通信协议。”
它解决的是：
* 上下文怎么传
* Tool 怎么发现
* Skill 怎么注册
* Agent 怎么协作
现在很多 AI IDE、AI Coding 工具都在接 MCP。
包括：
* Claude MCP
* Cursor MCP
* OpenAI MCP 方向
* 各类 Agent Framework
版本和协议更新很快。
实际使用前需要确认官方文档。
* * *
## 一个真实项目里的 Skill 结构
以 AI 客服为例。
`用户问题 ↓Agent Router ↓Skill Selector ↓CustomerServiceSkill ├── RAG 检索 ├── FAQ Tool ├── Order API ├── Refund Workflow └── LLM 总结`
你会发现：
Skill 已经开始承担：
* 业务边界
* 能力聚合
* 流程控制
这其实已经很像：
后端 Service 层。
* * *
## Skill 学习最容易踩的坑
## 1. 只学 Prompt
这是最常见问题。
Prompt 很重要。
项目真正难的是：
* Tool 管理
* 状态管理
* 上下文管理
* 调用链路
* 权限
* * *
## 2. 工作流堆太多
很多人：
n8n 拉满。
Dify 拉满。
最后没人敢维护。
因为：
“能力没有抽象。”
* * *
## 3. Skill 粒度混乱
错误例子：
`查询订单 Skill查询订单状态 Skill查询订单金额 Skill`
这种会越来越碎。
合理方式：
`OrderSkill ├── query ├── status └── amount`
* * *
## 面试里怎么回答“你会 Skill 吗？”
一个比较稳的回答方式：
> 我理解 Skill 不只是 Prompt。
>
>
> 它更像 AI Agent 里的能力抽象层。
>
>
> Skill 内部通常会封装：
>
>
> * Prompt
>
> * Tool
>
> * Function Calling
>
> * 权限
>
> * 输入输出 Schema
>
> * 工作流
>
>
>
> * 它主要解决：
>
>
> * 能力复用
>
> * Agent 组织
>
> * 工程维护
>
> * 多人协作
>
>
>
> * 在实际项目里，我会把订单查询、客服问答、报表分析等做成独立 Skill。
这类回答。
面试官会明显感觉：
你不是只会搭 Demo。
* * *
## 一句话总结
Prompt 决定“模型说什么”。
Function Calling 决定“模型调用什么”。
Tool 决定“系统能做什么”。
Skill 决定“能力如何组织”。
MCP 决定“能力之间如何通信”。
从 AI Demo 到 AI 工程，中间差的那层东西，很多时候就是 Skill。
* * *
## 推荐项目
## Agent / Skill 学习
* LangChain 官方
* LangGraph
* Dify
* OpenAI Function Calling 文档
* Anthropic MCP 文档
* * *
## 推荐练手项目
建议按这个顺序：
1. 天气查询 Tool
2. SQL 查询 Agent
3. RAG 问答 Skill
4. AI 客服 Skill
5. 多 Skill Agent Router
6. MCP Tool Server
练到第 4 步。
你会明显感觉：
AI 工程已经开始像后端架构设计了。
