简单理解 Agent，MCP，Skills

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

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

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

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

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

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

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

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

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

参考墨刀文档：

1. 初学者最常见误区

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

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

误区 B：只要工具多就强

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

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

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

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

Agent 可能拆成：

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

你会发现：

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

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

三. Agent MCP

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

MCP 官网介绍

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

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

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 在一次闭环里可能会：

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

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

现在已经有非常成熟的社区在收录各种现成的 MCP 工具：

平台名称 网址特点
Smithery smithery.ai 目前最火的 MCP “应用商店”，支持一键安装到 Claude 或 Cursor。
Glama MCP glama.ai/mcp/servers 分类非常详尽，涵盖了从数据库、搜索到多媒体处理的各类 Server。
PulseMCP pulsemcp.com 侧重于开发者工具和高效工作流的 MCP 集合。
Awesome MCP github.com/punkpeye/awesome-mcp 经典的 GitHub Awesome 系列列表，收录了大量的开源实现。
MCP-Get mcp-get.com 提供类似 npm install 的命令行工具，快速在本地部署 Server。

厂商自建 Registry

GitHub MCP Registry: github.com/marketplace —— GitHub 官方已将 MCP Server 整合进其市场，支持在 GitHub Copilot 中直接调用。

平台名称	网址	特点
Smithery	smithery.ai	目前最火的 MCP “应用商店”，支持一键安装到 Claude 或 Cursor。
Glama MCP	glama.ai/mcp/servers	分类非常详尽，涵盖了从数据库、搜索到多媒体处理的各类 Server。
PulseMCP	pulsemcp.com	侧重于开发者工具和高效工作流的 MCP 集合。
Awesome MCP	github.com/punkpeye/awesome-mcp	经典的 GitHub Awesome 系列列表，收录了大量的开源实现。
MCP-Get	mcp-get.com	提供类似 `npm install` 的命令行工具，快速在本地部署 Server。

四、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:
...

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

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

很多人第一次接触 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 的演进大致是三层：

从单步函数 → 多步工作流
例如“生成周报”不再是一个 generate_report()，而是：拉数据 → 清洗 → 生成 → 预览 → 确认 → 发布。
从纯文本返回 → 可交互 UI
把高风险动作（群发、删改、付款）放到表单/确认界面里，减少误操作，让 Human-in-the-loop 更自然。
从“个人技巧” → “组织技能资产”
团队把 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：完善中；有错误请留言改正

目录