AI 项目只做 Demo 和 Prompt 已经不够，深入理解 Skill 层是工程化关键。
核心内容：
1. Skill 在 AI Agent 中的核心定义与作用
2. Skill 与 Function Calling 的关键区别
3. 引入 Skill 层解决的工程化问题

面试官问我：“你会做 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_query
description: 查询用户订单信息
input:
  - user_id
output:
  - order_list
permissions:
  - order.read
tools:
  - 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 工程已经开始像后端架构设计了。