# 简单理解 Agent，MCP，Skills

| **术语**   | **角色** | **比喻**     | **实现本质**                                |
| ---------- | -------- | ------------ | ------------------------------------------- |
| **Agent**  | 决策者   | 建筑师       | 一个包含推理循环（Plan-Act-Observe）的系统  |
| **Skills** | 具体功能 | 锤子/电钻    | 封装好的函数或 Prompt 模板（如 `SKILL.md`） |
| **MCP**    | 通信协议 | 电源插座标准 | 一种基于 JSON-RPC 的开放协议                |





## 一、 核心概念：大脑、四肢与神经系统

要理解这三者的关系，最直观的比喻是**一个正在工作的资深技工**：

1. **Agent (智能体) 是“大脑”**：它负责思考。当接到任务时，它决定先做什么、后做什么，以及在遇到错误时如何修正计划。
2. **MCP (模型上下文协议) 是“标准接口”**：它是工具箱与大脑之间的**通用底座**。它确保无论你换了哪家的工具，只要符合 MCP 标准，大脑就能立刻识别并无缝使用。
3. **Skills (技能) 是“工具箱”**：它是具体的执行单元。比如扳手（查询数据库）、电钻（调用搜索 API）或螺丝刀（发送邮件）。

![image-20260204003428247](https://raw.githubusercontent.com/waynes-cell/wayne-image-bed/main/fix-dir/Typora/typora-user-images/2026/02/04/00-34-28-2cd68135707f797a71acb64d0e0a1ca7-image-20260204003428247-ccb8b4.png)

## 二. Agent：基于推理的闭环系统

<img src="https://raw.githubusercontent.com/waynes-cell/wayne-image-bed/main/fix-dir/Typora/typora-user-images/2026/02/03/14-45-06-b5959db9c5cd8f053c94303e7495a43c-image-20260203144506355-acea16.png" alt="image-20260203144506355" style="zoom:50%;" />

Agent 的核心在于它不是简单的“输入-输出”，而是一个 **ReAct (Reasoning and Acting)** 的循环。其逻辑可以简化为以下公式：

$$ Target + Context \xrightarrow{Reasoning} Plan \rightarrow Action(Skill) \rightarrow Observation \circlearrowleft $$

- **感知 (Perception)**：接收用户模糊的指令。
- **规划 (Planning)**：将任务拆解。
- **行动 (Action)**：调用具体的 Skill。
- **观察 (Observation)**：根据 Skill 返回的结果，判断任务是否完成，没完成则继续思考下一步。

> LLM 像是一个知识渊博的“智者”，只能生成内容；而 Agent 像是一个能帮您办事、使用工具、实现目标的“员工”。 

参考墨刀文档：

<img src="https://cdn-yunyin.modao.cc/CMS/blog/what-is-agent-intelligence1.jpg" alt="什么是Agent智能体" style="zoom: 33%;" />

### 1. 初学者最常见误区

#### 误区 A：把 Agent 当成“更聪明的模型”

不对。Agent 的提升往往来自**系统层能力**：工具、记忆、权限、日志、重试策略、结构化输出、任务队列……

#### 误区 B：只要工具多就强

不对。工具（Skills）越多越容易“选错/误用”。强 Agent 的关键在于：

- 会不会**拆解**  
- 会不会**选择合适技能**  
- 会不会**根据返回修正**  
- 有没有**安全边界**（权限、确认点、审计）

---

### 2. 一个容易懂的例子：把“帮我做周报”变成可执行流程

**用户**：帮我做本周周报，并发到团队群。

Agent 可能拆成：

1) 拉取本周任务清单（数据源/项目管理）  
2) 汇总关键进展与风险  
3) 生成周报 Markdown  
4) 让你确认（避免误发）  
5) 发送到群（Slack/企微/飞书）

你会发现：  

- 1) 和 5) 都需要“动真实系统”  
- 2) 和 3) 偏“内容生成”  
- 4) 是安全阀（Human-in-the-loop）

接下来就进入 MCP 与 Skills 的世界：**怎么把这些系统接起来？怎么把这些动作封装成技能？**



## 三. Agent MCP

### 1. MCP：Model Context Protocol （模型上下文协议）

> [MCP 官网介绍](https://modelcontextprotocol.io/docs/getting-started/intro)

在 MCP 出现之前，开发者需要为每个模型（Claude, GPT, Gemini）编写专门的插件适配代码。**MCP 的出现实现了“解耦”：**

- **MCP Server**：数据和工具的提供方（如你的本地数据库、GitHub 接口）。
- **MCP Client/Host**：AI 客户端（如 Claude Desktop, VS Code）。
- **原理**：基于 JSON-RPC 的通信。当 Client 连接到 Server 时，Server 会主动上报：“我有 3 个工具：查天气、读文件、写代码”。模型通过协议自动理解这些工具的参数，无需手动硬编码。

<img src="https://raw.githubusercontent.com/waynes-cell/wayne-image-bed/main/fix-dir/Typora/typora-user-images/2026/02/03/14-58-44-caa226296c21903129d59953d656e629-image-20260203145844348-959779.png" alt="image-20260203145844348" style="zoom: 50%;" />



**1. 为什么我们需要 MCP？（解决 N x M 痛苦）**

- 在 MCP 出现之前，开发者面临一个尴尬的局面：如果你写了一个“GitHub 搜索工具”，想让 Claude 能用，你得写一套对接代码；想让 ChatGPT 能用，又得写一套 Plugin；想给 Gemini 用，还得再折腾一次。
- **MCP 的核心价值在于：一次编写，全平台通用。** 它将“工具提供方（Server）”与“AI 客户端（Host/Client）”彻底解耦。只要你的工具符合 MCP 标准，任何支持该协议的 AI 助手都能瞬间“学会”这项技能。

**2. MCP 的三大支柱**

- 在编写 MCP Server 时，你主要在定义三样东西：
  1. **Tools (工具)**：AI 可以**执行**的动作（如：运行 SQL、发送 Slack 消息）。
  2. **Resources (资源)**：AI 可以**读取**的数据（如：本地日志文件、数据库 schema、API 文档）。
  3. **Prompts (提示词模板)**：预设的**交互模式**（如：一个专门负责“代码审查”的对话模板）。

**3. 技术底层：JSON-RPC 与传输层**

- MCP 并不是魔法，它基于成熟的 **JSON-RPC 2.0** 协议。
  - **本地连接**：通常通过 `stdio`（标准输入输出）通信，速度极快，适合本地 IDE 和桌面端。
  - **远程连接**：支持 **SSE (Server-Sent Events)**，允许 AI 访问云端的工具和服务。



### 2. 一个入门级 MCP 场景：让 Agent 同时接“工单系统 + 文档库 + 消息平台”

> 目标：用户一句话“把这个故障记录成工单，并通知 oncall”

- MCP Server A：工单系统（提供 `create_ticket` tool）
- MCP Server B：内部知识库（提供 `search_runbook` resource）
- MCP Server C：消息平台（提供 `post_message` tool）

Agent 在一次闭环里可能会：

1) `search_runbook` 找处理模板  
2) `create_ticket` 生成工单  
3) `post_message` 通知群组  
4) 观察返回（失败就重试/换渠道/要求确认）

你会看到：**MCP 管的是“接线”和“协议”；真正做事的还是 Skills。**



> 现在已经有非常成熟的社区在收录各种现成的 MCP 工具：
>
> | **平台名称**    | **网址**                                                     | **特点**                                                     |
> | --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
> | **Smithery**    | [smithery.ai](https://smithery.ai/)                          | 目前最火的 MCP “应用商店”，支持一键安装到 Claude 或 Cursor。 |
> | **Glama MCP**   | [glama.ai/mcp/servers](https://glama.ai/mcp/servers)         | 分类非常详尽，涵盖了从数据库、搜索到多媒体处理的各类 Server。 |
> | **PulseMCP**    | [pulsemcp.com](https://pulsemcp.com/)                        | 侧重于开发者工具和高效工作流的 MCP 集合。                    |
> | **Awesome MCP** | [github.com/punkpeye/awesome-mcp](https://www.google.com/search?q=https://github.com/punkpeye/awesome-mcp) | 经典的 GitHub Awesome 系列列表，收录了大量的开源实现。       |
> | **MCP-Get**     | [mcp-get.com](https://mcp-get.com/)                          | 提供类似 `npm install` 的命令行工具，快速在本地部署 Server。 |
>
> 厂商自建 Registry
>
> - **GitHub MCP Registry**: [github.com/marketplace](https://github.com/marketplace) —— GitHub 官方已将 MCP Server 整合进其市场，支持在 GitHub Copilot 中直接调用。



## 四、Skills：真正“动手”的原子化执行单元（入门 + 可抄作业的写法）

### 1. Skills 到底是什么？（用工程视角定义）

**Skill = 可被 Agent 可靠调用的执行单元**，包含：

- 明确的输入参数（最好可校验）
- 清晰的输出结构（便于下一步决策）
- 可控的权限边界（最小权限）
- 可观测（日志/trace/耗时/结果摘要）
- 风险动作有确认点（UI 或显式确认）

> 记忆法：Skill 不只是“函数”，而是“可被系统可靠使用的能力单元”。

### 2. Skills 的三种形态（从硬到软，越硬越稳定）

**(1) 硬技能：函数 / API（最推荐）**

适合：发消息、查数据库、创建工单、读写文件  

特点：确定性强、可测试、可审计

**(2) 半硬技能：脚本 / 工作流（适合团队沉淀）**

适合：部署脚本、批处理、数据清洗  

特点：把复杂操作封成“一键动作”，但需要更强的权限控制

**(3) 软技能：Prompt 模板 / Runbook（入门最快）**

适合：代码审查模板、排障流程模板、周报模板  

特点：不动系统，但能规范输出；常作为硬技能的“前置步骤”



### 3. 一个容易理解的 Skill 例子：`post_message`

下面用“结构化参数 + 结构化返回”展示“像样”的 Skill 长什么样。

#### 3.1 输入（参数契约）

```json
{
  "name": "post_message",
  "description": "Send a message to a team channel",
  "parameters": {
    "type": "object",
    "properties": {
      "channel": { "type": "string", "description": "Target channel id or name" },
      "text": { "type": "string", "description": "Message text in Markdown" },
      "dry_run": { "type": "boolean", "default": false }
    },
    "required": ["channel", "text"],
    "additionalProperties": false
  }
}
```

#### 3.2 输出（让 Agent 好接下一步）

```
{
  "ok": true,
  "message_id": "m_123",
  "posted_at": "2026-02-04T10:12:00+08:00",
  "preview": "..."
}
```

> `dry_run` 是新手最该学的：把风险动作做成可预演，默认先预演再提交。

------

### 4. “SKILL.md” 在 2026 的价值：让模型读文档就会用你的私有工具

你可以把 `SKILL.md` 写成“工具使用说明书 + 安全规范 + 例子库”。一个可抄的模板：

```markdown
# Skill: create_ticket

## What it does
- Create an incident ticket in our ticketing system.

## When to use
- User asks to file/track an incident, bug, or request.

## Inputs
- title (string, required)
- severity (enum: P0/P1/P2/P3, required)
- description (string, required)
- owner (string, optional)
- dry_run (bool, default true)

## Outputs
- ok (bool)
- ticket_id (string)
- url (string)  # optional in some systems
- summary (string)

## Safety & guardrails
- Always run with dry_run=true first.
- If severity is P0/P1, must ask for confirmation before final submit.

## Examples
### Example A: P2 bug
Input:
...
Output:
...
```

这类文档的作用是：**把“你团队的真实流程”变成模型可执行的规范**。

![image-20260204003459442](https://raw.githubusercontent.com/waynes-cell/wayne-image-bed/main/fix-dir/Typora/typora-user-images/2026/02/04/00-34-59-be6e2ad07dfc5ef5943051d3dc8450ed-image-20260204003459442-be4863.png)





## FAQ：有了 MCP 为什么还需要 Skills？两者到底差在哪？

![image-20260204003516244](https://raw.githubusercontent.com/waynes-cell/wayne-image-bed/main/fix-dir/Typora/typora-user-images/2026/02/04/00-35-16-3409069dd0e5f56e323319d114747956-image-20260204003516244-1ad746.png)

很多人第一次接触 MCP 会有个直觉：**“既然 MCP 能把工具接进来，那 Skills 还重要吗？”**  
答案是：**重要，而且永远重要。** 因为两者解决的根本不是同一件事。

---

### 1) MCP 与 Skills 的本质区别：一个管“接线”，一个是“能力本体”

- **Skills** 是“能力本体”：真正执行动作的原子单元（函数/API/脚本/工作流模板/UI 流程）。  
  它关心的是：**输入输出契约、权限边界、错误语义、幂等性、可测试性**。

- **MCP** 是“接线与治理标准”：让 Host/模型用统一方式发现并使用这些能力。  
  它关心的是：**跨平台解耦、权限与授权、上下文资源、交互确认、长任务与可观测**。

> 类比最直观：  
> **Skill = 电钻本身**（能干活）  
> **MCP = USB-C + 插座规范 + 驱动协议**（插上就能用、还能管权限、还能分发）

---

### 2) MCP 会更浪费 token 吗？真正的矛盾不是 token

MCP 的确可能带来额外 token 开销，比如：
- Server 暴露较多工具与描述，需要模型“看见”
- Resources/Prompts 提供更丰富上下文

但在工程落地里，MCP 的价值主要不在省 token，而在于：
- **解决 N×M 适配爆炸**：工具多、模型多、客户端多，不用每家写一套插件
- **权限与治理**：最小权限、增量授权、审计与可回放
- **更好的交互与可靠性**：确认点、UI 化、多步骤任务与长任务编排

一句话：**MCP 是为“规模化落地”服务的系统层能力，而不是为“减少 token”服务。**

---

### 3) 有了 Skills 就不用 MCP 了吗？

这取决于你的边界：

- **可以不用 MCP 的场景**：  
  你只在某个单一平台内跑（单 Host、单套工具体系），工具接入和权限治理都由平台自带。

- **很快会需要 MCP 的场景**：  
  你要接多个内部系统（数据库/仓库/CI/工单/文档），或者希望**换模型/换 Host 仍能复用同一套工具**，还希望权限、审计、分发标准化。

> 结论很清晰：  
> **Skills 是必需品（没有手脚就办不了事）**  
> **MCP 是加速器（把手脚标准化接入、治理和生态化）**

---

### 4) 如何看待 2026 的 Skills 发展：从“函数”走向“工作流”与“UI 能力”

过去一年，Skills 的演进大致是三层：

1) **从单步函数 → 多步工作流**  
   例如“生成周报”不再是一个 `generate_report()`，而是：拉数据 → 清洗 → 生成 → 预览 → 确认 → 发布。

2) **从纯文本返回 → 可交互 UI**  
   把高风险动作（群发、删改、付款）放到表单/确认界面里，减少误操作，让 Human-in-the-loop 更自然。

3) **从“个人技巧” → “组织技能资产”**  
   团队把 runbook、脚本、内部 API 变成可复用 Skills + 规范文档（例如 SKILL.md），形成可迭代资产。

实践上，最值得优先 Skill 化的是：
- 高频查询：查工单、查日志、查数据
- 高价值写入：创建工单、发消息、提 PR（必须带确认）
- 规范生成：周报/汇总/报告（加模板 + 结构化输出）

---

### 5) Vibe Coding 时代：怎么让模型“遵循 Skills 规范”？靠自觉不如靠护栏

很多人以为“写个 SKILL.md 模型就会乖乖照做”。真实情况是：**靠自觉不可靠，靠系统护栏才可靠。**

让模型遵循规范，分两层：**想得对** + **做得对**。

#### (1) 让它“想得对”：把规范写成可执行规则
SKILL.md 不要只写说明，要写“规则”：
- **什么时候用 / 什么时候不用**
- **必须先 dry_run**
- **哪些字段必须问用户**
- **哪些动作必须二次确认**
- **失败如何重试/降级**

> 把规范写成 if/then，而不是一段描述性文字。

#### (2) 让它“做得对”：把规范固化到系统约束
最有效的工程手段是：
- **严格 JSON Schema**（`additionalProperties=false`，多一个字段都报错）
- **两阶段提交**（`dry_run → commit`，没有确认不能提交）
- **权限拆分**（读/写/删分开，高危动作单独工具）
- **幂等键**（`request_id` 防重复）
- **错误分层**（参数错/权限错/外部系统错，让 Agent 能自纠错）

> 目标是：模型可以自由规划，但只能在你允许的轨道上执行。

---

### 6) 一句话总结：MCP 与 Skills 的正确关系

- **Skills 决定你“能做什么”以及“做得有多可靠”**  
- **MCP 决定这些能力“能否跨平台复用、能否被治理、能否产品化分发”**

在 2026 年，真正强的 Agent 系统从来不是“模型有多强”，而是：  
**有一套高质量 Skills 资产 + 一套可治理可扩展的接入标准（MCP）+ 一个会闭环推进的 Agent。**





> PS：完善中；有错误请留言改正

Agent,MCP,Skills 的简单介绍

# 低配 NAT VPS 上部署 Xray

> 适用对象：
> - 低配 VPS（1 核 / 256MB / 10GB）
> - **NAT / LXD / 端口映射型 VPS**
> - 目标：**安全、稳定、速度优先、可长期运行**
>
> 本文不是一键脚本，而是**在真实环境中完整跑通、可验证、可维护**的方案。
---




## 一、整体设计思路（先看这个）

在 **低配 + NAT VPS** 上，正确思路不是“功能越多越好”，而是：

- ❌ 不用 UDP（WireGuard / QUIC 在 NAT VPS 上不稳定）
- ❌ 不用 Docker / 面板（内存吃紧，维护复杂）
- ❌ 不搞多端口、多协议
- ✅ 单进程、单入口、TCP 行为
- ✅ 可选 TLS（有域名更好，没有也能用）

### 推荐技术组合

> **Xray-core + VLESS + TCP**
>
> - **无域名**：VLESS + TCP（基础可用）
> - **有域名**：VLESS + TCP + TLS（最终形态）

这两种方案 **共用同一套 Xray 配置结构**，后期可以无缝升级。

---

## 二、VPS 与网络前提

### VPS 条件

- CPU：1 核
- 内存：256MB
- 磁盘：10GB
- 系统：**Debian 12**
- 网络：**NAT + 端口映射（非独立公网 IP）**

### 端口映射示例

| 公网端口 | 容器端口 | 用途 |
|--------|----------|------|
| 27207 | 22 | SSH |
| 21468 | 443 | Xray |

> ⚠️ 外部访问必须使用 **公网端口**，不是容器端口。

---

## 三、安装 Xray-core（官方方式）

```bash
apt update && apt upgrade -y
apt install -y curl unzip socat cron

cd /usr/local/bin
curl -L -o xray.zip https://github.com/XTLS/Xray-core/releases/latest/download/Xray-linux-64.zip
unzip xray.zip
chmod +x xray
xray version
```

生成 UUID：

```bash
xray uuid
```

---

## 四、方案 A：**不使用域名（基础方案）**

> 适合场景：
> - 没有域名
> - 想先跑通、确认稳定性
> - 内部或个人使用

### Xray 配置（无 TLS）

`/etc/xray/config.json`

```json
{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          { "id": "YOUR_UUID" }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp"
      }
    }
  ],
  "outbounds": [ { "protocol": "freedom" } ]
}
```

创建 systemd 服务：

```bash
cat > /etc/systemd/system/xray.service << 'EOF'
[Unit]
Description=Xray Service
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/xray run -config /etc/xray/config.json
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable xray
systemctl restart xray
```

验证监听：

```bash
ss -lntp | grep 443
```

### 客户端使用（无 TLS）

```text
vless://YOUR_UUID@VPS_IP:21468?encryption=none&type=tcp#vps-notls
```

> 说明：
> - 使用 **IP + 公网端口**
> - 无 TLS，协议简单，稳定性高

---

## 五、方案 B：**使用域名 + TLS（推荐长期方案）**

> 适合场景：
> - 有可控域名（一级或自有二级域名）
> - 希望更安全、更像正常 HTTPS
> - 长期使用

### DNS 要求（以 Cloudflare 为例）

```text
vps.example.com  ->  VPS 公网 IP
（仅 DNS，灰云）
```

### 使用 acme.sh + DNS 验证申请证书

```bash
curl https://get.acme.sh | sh
/root/.acme.sh/acme.sh --set-default-ca --server letsencrypt

export CF_Token="YOUR_CF_TOKEN"

/root/.acme.sh/acme.sh --issue --dns dns_cf -d vps.example.com

mkdir -p /etc/xray/cert
/root/.acme.sh/acme.sh --install-cert -d vps.example.com \
  --key-file       /etc/xray/cert/key.pem \
  --fullchain-file /etc/xray/cert/cert.pem
```

### Xray 配置（TLS）

```json
{
  "log": { "loglevel": "warning" },
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          { "id": "YOUR_UUID" }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "certificates": [
            {
              "certificateFile": "/etc/xray/cert/cert.pem",
              "keyFile": "/etc/xray/cert/key.pem"
            }
          ]
        }
      }
    }
  ],
  "outbounds": [ { "protocol": "freedom" } ]
}
```

重启并验证：

```bash
systemctl restart xray
ss -lntp | grep 443
```

### 客户端使用（TLS）

```text
vless://YOUR_UUID@vps.example.com:21468?encryption=none&security=tls&type=tcp#vps-tls
```

> ⚠️ TLS 模式 **必须使用域名，不能用 IP**。

---

## 六、验证与排障（核心方法）

### 本地验证

```bash
curl ifconfig.me
```

返回 VPS 公网 IP 即成功。

### 底层验证（NAT / 监听）

```bash
apt install tcpdump
tcpdump -ni eth0 tcp port 443
```

看到 `SYN → SYN/ACK → ACK` 表示链路完全正常。

---

## 七、经验总结

- **一个低配 NAT VPS = 一个节点，是最优解**
- 多设备使用同一节点即可
- 扩展方式推荐：多个 UUID，而不是多个端口
- 无域名方案适合起步，有域名方案适合长期

> **少即是多，简单即是稳定。**



v2ray 剪贴板导入：

![image-20251227150609222](https://cdn.jsdelivr.net/gh/waynes-cell/wayne-image-bed@main/nodeImg/fix-dir/C/Users/lucky/AppData/Roaming/Typora/typora-user-images/2025/12/27/15-06-09-de858ba4f808c3ba51579c3140bbcdb3-image-20251227150609222-2620e6.png)