title: 理清 AI 交互中的核心概念
author: Gamehu
date: 2026-01-27 21:36:11
tags:
  - Skills
categories:
  -  AI
---

<div class="tag-container">
  <span class="ai-tag">Skills</span>
  <span class="sub-tag">第1篇</span>
</div>

## **写在前面**
<div class="article-quote">
最近有个不太懂技术的同事来问我，Skills、Rules 这些概念到底有啥区别，该怎么区分它们的作用。我本来以为自己比较了解，结果讲着讲着就发现，我对这些概念的边界和协同逻辑，好像没那么清晰，看着同事那疑惑的眼神以及收尾那不太肯定的“嗯”，想着必须重新了解，从“能力、约束、调度、协议”四个维度，把它们的区别摸透。既能补全自己的认知漏洞，也希望能给有同样困惑的朋友，尤其是刚接触这块的同事，能比较清晰的给他们讲清楚。
</div>

对于 AI 的重度用户或初级开发者来说，经常会混淆：到底什么是“规则”，什么又是“技能”？ 当 Anthropic 推出 MCP 协议后，这层关系变得更加扑朔迷离。
这篇旨在尽量简单生动的理清这四个概念。

# 一、概念定义：AI Agent 的四层架构模型

构建成熟可用的 AI 智能体应用，核心在于协调四大要素形成闭环链路。各层级各司其职、层层支撑，既明确边界又深度协同，共同构成智能体稳定运行的核心骨架。

### 1. Skills（能力层）—— 破解“做得到”的可行性难题

- **技术定义**：Skills 是 AI 智能体的显性能力外延，核心落地形态为 **Function Calling（函数调用）** 与 **External Tools（外部工具集成）**，是智能体突破自身能力边界、落地实际操作的关键载体。

- **核心职能**：大语言模型（LLM）通过 `JSON Schema` 描述符，精准解析工具的功能范围、参数规范及返回格式，打破自身训练数据的时空限制，实现从“文本生成”到“落地执行”的核心跨越。

### 2. Rules（控制层）—— 筑牢“不越界”的合规性底线

- **技术定义**：Rules 是智能体的运行准则与风格锚点，通常通过 **System Prompt（系统提示词）** 硬编码或 **Guardrails（护栏系统）** 部署，形成刚性约束框架，划定运行边界。

- **核心职能**：以确定性逻辑约束随机性模型的输出，在生产环境中承担三大核心职责——安全性防护（Safety）、品牌调性统一（Tone）、输出格式标准化，从根源上规避模型“幻觉”与违规风险。

### 3. Prompt（调度层）—— 打通“懂需求”的意图性链路

- **技术定义**：Prompt 是用户意图与模型上下文的**实时动态组合体（Context Window）**，是指令传递、需求转化与场景激活的核心媒介。

- **核心职能**：在 Rules 划定的约束框架内，精准捕捉并转化用户需求，按需激活对应 Skills 工具，实现“需求-能力”的精准匹配，驱动任务全流程推进。

### 4. MCP（协议层）—— 破解“连得上”的连接性瓶颈

- **技术定义**：**Model Context Protocol（模型上下文协议，简称 MCP）** 由 Anthropic 牵头发起，是聚焦智能体与异构数据源互联适配的开放技术标准。

- **核心职能**：实现数据源（Resources）与模型端的解耦设计，通过标准化接口让 AI 智能体“即插即用”访问各类数据资源（数据库、本地文件、SaaS 应用等），是 **Context-as-a-Service（上下文即服务）** 模式落地的核心基础设施。

---

# 二、场景推演：以“AI 数字化导游”为例

为具象化四大模块的协同逻辑，我们以“AI 商务出行助手”（原“数字化导游”适配场景）为例，拆解智能体响应商务需求的全流程运行链路：

> **用户输入（Prompt）**：“我下周三要去上海出差，帮我结合日程表规划通勤路线，并订一张符合要求的机票。”
> 
> 

|**架构维度**|**实际运行逻辑**|**核心架构价值**|
|---|---|---|
|**Rules**|底层刚性约束：1. 交互全程礼貌称呼用户，保持专业商务调性；2. 机票预订严格遵循公司报销标准（单张≤￥2000）；3. 仅规划通勤路线，严禁推荐无关景区及违规服务。|筑牢合规基准，确保输出既符合企业行政政策，又规避安全风险，保持风格统一。|
|**MCP**|通过 MCP 协议实现数据互联，自动读取用户 Outlook 日程表（确认出差具体时段）、Notion 行程偏好（如座位、航司倾向），无需人工手动录入或复制信息。|低成本构建实时上下文，打通数据孤岛，保障信息获取的高效性与私密性。|
|**Skills**|识别用户核心意图后，自动激活 `Flight_Search_API` 查询符合预算的航班余票，调用 `Map_Routing_SDK` 结合日程与酒店位置计算最优通勤路线。|将文本需求转化为实际业务操作，落地“查询-规划-预订”的核心功能，突破纯文本输出局限。|
|**Prompt**|整合“上海”“下周三”等用户指令参数，叠加 MCP 获取的日程/偏好数据、Skills 返回的航班/路线信息，生成结构化出行建议（含航班备选、通勤方案）。|串联全流程模块，实现“意图输入-结果输出”的闭环，驱动各环节协同落地。|
---

# 三、架构特征对比表

为进一步明确四大维度的定位差异，通过核心特征对比，助力开发者精准把握各模块的设计重点与落地优先级：

|**维度**|**核心角色**|**核心痛点**|**工业级实现**|**变动频率**|
|---|---|---|---|---|
|**Skills**|能力工具箱|解决“手脚不长”、无法落地操作的问题|Function Calling / Plugins / 工具市场集成|中（随业务需求迭代工具矩阵）|
|**Rules**|运行紧箍咒|解决模型“不可控、易幻觉”的问题|System Message / Guardrails / 合规校验引擎|低（仅随合规政策调整）|
|**Prompt**|需求指挥棒|解决“意图理解偏差”的任务匹配问题|Prompt Engineering / CoT（思维链）/ 上下文管理|高（随场景优化指令设计）|
|**MCP**|数据总线/插座|解决“数据孤岛、集成复杂”的问题|MCP Server / Client / 标准化数据接口|极低（作为基础设施长期稳定）|
---