我拆了4个顶级AI产品的架构，终于搞懂了Agent、Skill、MCP到底怎么分
最近半年，"Agent"这个词出现的频率越来越高。
OpenAI 在讲 Agent，Anthropic 在讲 Agent，Google 在讲 Agent，飞书也在讲 Agent。
然后紧跟着就是一堆新词：Skill、MCP、工作流、多模型路由、工具调用……
我相信很多人的状态和我一开始一样：每个词都听过，但凑到一起就分不清了。
- Agent 和 Chatbot 有什么区别？
- Skill 和 Prompt 有什么区别？
- MCP 到底是什么，为什么突然到处都是？
- 工作流和 Agent 又是什么关系？
这些问题我也困惑过。后来我做了一件事：把我每天在用的几个 AI 产品拆开看架构。
拆完之后发现，不管是 Claude Code、OpenClaw、飞书 CLI 还是 Figma AI，它们虽然形态不同，底层都在做同一件事。
搞懂了这个共同模式，Agent、Skill、MCP 的区别自然就清楚了。
01. 先用一个比方把三个概念讲清楚
在拆产品之前，先用一个最直观的比方把关系理清。
想象一个餐厅后厨的运作方式：
- Agent = 主厨（懂菜系、能判断客人点的"随便来点好吃的"到底该上什么菜）
- Skill = 菜谱（红烧肉：焯水 → 炒糖色 → 加料 → 炖40分钟，标准化的执行步骤）
- MCP = 厨房里的设备和食材库（烤箱、炒锅、冰柜、调料架——主厨通过这些完成每一道菜）
这三者的关系是：
客人下单后，主厨（Agent）判断该做什么菜、按哪个菜谱（Skill）来做，做的过程中需要用什么设备和食材（MCP）就调用什么。
重点来了：
- 同一口炒锅（MCP）可以被川菜厨师和粤菜厨师（不同 Agent）共用
- 同一份菜谱（Skill）可以被不同厨师复用
- 主厨的价值不在于他会用烤箱，而在于他能判断"这桌客人该上什么菜"
翻译成 AI 的语言：
| 概念 | 一句话定义 | 核心能力 |
|---|---|---|
| Agent | 一个面向具体目标的角色 | 理解意图 + 做决策 + 选择调什么能力 |
| Skill | 一套可复用的标准化执行流程 | 把业务逻辑封装成"输入 → 步骤 → 输出" |
| MCP | 连接外部工具和数据的标准协议 | 让 AI 的手能"够到"真实的系统和数据 |
如果你记不住这张表，就记住这一句：
Agent 决定"做什么"，Skill 决定"怎么做"，MCP 决定"用什么工具做"。
02. 为什么你一定要分清这三个概念？
你对这三个概念的理解深度，直接决定了你能把 AI 用到什么程度。
很多人用 AI 的方式还停留在"问一句答一句"——这本质上是在用 Chatbot，不是在用 Agent。
Agent 和 Chatbot 的核心区别只有一个：
| Chatbot | Agent | |
|---|---|---|
| 能不能调工具 | ❌ 只能对话 | ✅ 能查数据库、操作文档、调用 API |
| 能不能多步执行 | ❌ 一问一答 | ✅ 自己规划步骤、按顺序执行 |
| 有没有决策能力 | ❌ 你问什么答什么 | ✅ 自己判断该调什么能力 |
举个例子：
你问 ChatGPT"帮我查一下上个月德国市场的销量"，它只能说"抱歉我没有你的数据"。
但如果是一个 Agent，它会：
- 先理解你要查什么（意图识别）
- 自动调用销量数据库的接口（MCP）
- 拿到数据后按模板整理成报表（Skill）
- 返回给你一份可以直接用的分析结果
从"能聊天"到"能干活"，中间差的就是 Skill 和 MCP。
03. 第一个产品：Claude Code —— 目前最成熟的 Agent
我每天都在用 Claude Code，一开始只当它是个写代码的工具。
后来越用越深，才发现它本身就是目前最成熟的 Agent 产品——不是因为模型强，而是因为它的 Agent 架构设计得非常完整。
把它的架构拆开看：
CLAUDE.md（指令层：全局规范 + 项目规则 + 目录级指令，越近越优先）
↓
Skills（能力层：/commit、/review、/qa 等可复用工作流）
↓
MCP Server（连接层：Notion、Google Workspace、Figma 等外部工具）
↓
Hooks（守护层：工具调用前/后自动执行检查脚本）
↓
多模型切换（模型层：Opus / Sonnet / Haiku，按任务复杂度路由）
3.1 CLAUDE.md = 指令分层系统
Claude Code 有一个设计让我印象很深：指令是分层的。
它支持三级 CLAUDE.md 文件：
- 全局级（~/.claude/CLAUDE.md）：适用于你所有项目的通用规则
- 项目级（项目根目录/CLAUDE.md）：适用于当前项目的规则
- 目录级（某个子目录/CLAUDE.md）：只适用于特定模块的规则
越近的规则优先级越高。 比如你全局写了"用英文注释"，但某个项目的 CLAUDE.md 里写了"用中文注释"，那在这个项目里就会用中文。
这个设计对做 AI 产品的启发是：
Agent 的行为规范不能一刀切，要分层管理。全局约束管大方向，场景规则管具体行为，单次指令管临时调整。
3.2 Skills = 工作流封装
Claude Code 的 Skills 不是一个简单的 Prompt 模板，而是把一整套业务流程封装成一个可复用的命令。
比如 /review 这个 Skill，它不是"帮我看看代码"这么简单。它背后包含了：
- 审查哪些维度（安全、性能、可维护性）
- 按什么标准判断（通过/需修改/拒绝）
- 调用什么工具（读文件、跑测试、查 diff）
- 输出什么格式（结构化的审查报告）
Skill 和 Prompt 的区别就在这里：
| Prompt | Skill | |
|---|---|---|
| 本质 | 一段文字指令 | 一整套业务流程 |
| 复杂度 | 单次对话 | 多步骤 + 工具调用 + 格式约束 |
| 复用性 | 每次重新输入 | 封装好后一个命令调用 |
| 质量稳定性 | 每次输出不一样 | 按标准流程执行，输出一致 |
我自己也封装了好几个 Skill。比如"文章改写"——以前每次改文章都要重新说"保持我的风格、融入过往案例、优化 SEO"，现在直接一个命令搞定。
核心价值就一句话：把重复的提示词变成可复用的工作流。
3.3 MCP = 让 AI 的手能够到真实工具
MCP（Model Context Protocol）是 Anthropic 推出的一个标准协议，用一句话说：让 AI 能安全地调用外部工具和数据。
Claude Code 通过 MCP 接入了各种外部服务：
- 接 Notion → AI 能读写你的文档和数据库
- 接 Google Workspace → AI 能操作表格和文档
- 接 Figma → AI 能读取设计稿甚至操作画布
MCP 的价值不在协议本身，而在于它让 AI 从"只能聊天"变成了"能操作真实业务工具"。
我现在搭的工作流里，AI 可以自己去 Notion 里查资料、往 Google Sheets 里写数据、读取 Figma 设计稿生成代码。这些操作以前都需要我手动做，现在全部是 AI 通过 MCP 自动完成的。
3.4 Hooks = 自动化守护
这是 Claude Code 里一个容易被忽略但非常重要的设计：Hooks 机制。
你可以配置"在某个工具调用前/后，自动执行一段脚本"。比如：
- 代码提交前自动跑格式检查
- 文件写入后自动跑测试
- 任何破坏性操作前弹出确认
这给了我一个很大的启发：Agent 的输出质量不能只靠 Prompt 约束，还需要自动化的守护机制。
光告诉 AI"请你仔细检查"是不够的，你需要在流程层面加上自动化的"安全网"。
3.5 多模型路由 = 按任务分配资源
Claude Code 支持在 Opus（最强但最贵）、Sonnet（均衡）、Haiku（最快最便宜）之间切换。
成本差异巨大——Opus 的价格可能是 Haiku 的 10 倍以上。
但产品设计上做得很聪明：不是让用户自己选，而是按任务复杂度动态推荐。 复杂的架构设计用 Opus，简单的格式调整用 Haiku。
模型选择不是"用最好的"，而是"按任务匹配最合适的"。 这个思路在做任何 AI 产品时都适用。
04. 第二个产品：OpenClaw —— Agent 运行的最小完整框架
OpenClaw 是一个可以自己部署的 Agent 框架。我在一台 68 块钱/年的阿里云 VPS 上跑起来了，接了飞书消息通道和浏览器自动化。
如果说 Claude Code 是一个成熟的 Agent 产品，那 OpenClaw 就是一个让你自己搭 Agent 的框架。
它的架构非常清晰，三层：
消息入口层：飞书 / / / Web（统一消息网关）
↓
AI Agent 运行层：模型路由 + Skill/MCP 调用编排
↓
工具执行层：浏览器自动化 / 定时任务 / API 调用 / 网页抓取
4.1 消息网关 = 把所有入口统一
OpenClaw 最让我印象深刻的设计是：它先解决的不是"AI 怎么回答"，而是"用户从哪里来"。
你可以同时接飞书和 /。用户在飞书群里 @ 机器人，和在 / 里私聊机器人，背后调用的是同一套 Agent 能力。
这个设计在企业场景里特别有价值——不同团队可能用不同的沟通工具，但 Agent 的能力只需要建设一套。
4.2 Skills 和 MCP 在 OpenClaw 里的关系
OpenClaw 把 Skills 和 MCP 的分工讲得很清楚：
- Skills = 可直接复用的小能力包（浏览器抓取、内容生成、定时任务等）
- MCP = 连接外部系统的协议层（飞书 API、数据库等）
两者组合使用：一个 Skill 内部可能调用多个 MCP 工具来完成任务。
比如"帮我总结今天群里聊了什么"这个任务：
- Skill（流程编排）：读取消息 → 筛选时间范围 → 摘要生成 → 格式化输出
- MCP（工具连接）：调用飞书 API 拉群消息
Skill 定义了"做什么、怎么做"，MCP 解决了"怎么连、怎么拿数据"。
4.3 对比 Claude Code：通用框架 vs 成熟产品
| 维度 | OpenClaw | Claude Code |
|---|---|---|
| 定位 | 自己搭的 Agent 框架 | 开箱即用的 Agent 产品 |
| 灵活性 | 高，什么都能改 | 中，在框架内定制 |
| 上手门槛 | 需要部署 VPS | 装个 CLI 就行 |
| 适用场景 | 想完全自控 Agent 能力 | 想快速用上 Agent 能力 |
但它们验证了同一件事：Agent 的价值不在模型本身，在于你连接了什么工具、编排了什么流程。
05. 第三个产品：飞书 CLI —— Agent-first Design 的典型
飞书官方出了个 CLI 工具（lark-cli），6 天拿了 5000 star，200+ 命令，19 个 AI 技能包。
我之前写过一篇详细的实测文章。这次换个角度，从架构层面聊聊它为什么值得关注。
5.1 一个颠覆认知的设计哲学
lark-cli 最让我意外的不是它有多少命令，而是它的设计哲学：
这个工具不是给人用的，是给 AI Agent 用的。
安装的时候它会自动扫描你电脑上的 AI 工具——Claude Code、Cursor、Windsurf、Codex 等——然后把 19 个技能包自动注入到所有这些工具里。
你不需要记任何命令。装完之后跟 Claude Code 说"帮我查今天有什么会议"，AI 自己就会调用飞书的日历 API 查询。
这意味着什么？意味着工具设计的"第一用户"正在从人变成 AI Agent。
5.2 Agent-friendly 的 API 设计
lark-cli 的命令设计天然对 Agent 友好：
- 结构化输入/输出：不是自由文本，而是明确的参数和 JSON 返回
- dry-run 预览：执行前先预览结果，Agent 确认后再真正执行
- 权限自动管理：安装时自动申请合理权限，不需要人工配置
- 安全扫描：每个 Skill 都有独立的安全评分
我测试的时候，跟 Claude Code 说了一句"帮我给某个群发条消息"，AI 自己做了三件事：
- 搜索群名找到目标群
- 用 dry-run 预览要发的内容
- 确认后发出消息
全程我没查过文档，没手动拼过参数。
5.3 这对我们做产品的启发
如果你在做企业内部系统，或者做任何会被 AI Agent 调用的工具，lark-cli 的设计思路值得参考：
- API 的第一用户可能不再是人，而是 AI Agent — 接口设计要对 Agent 友好
- 结构化 > 自由文本 — Agent 需要明确的输入格式和输出格式
- 支持预览和确认 — 给 Agent 一个"试一试再正式执行"的能力
- 权限要明确 — Agent 调用时需要知道自己能做什么、不能做什么
我把这个趋势总结为 Agent-first Design——未来越来越多的工具，设计时要优先考虑 AI Agent 怎么调用，其次才是人怎么操作。
06. 第四个产品：Figma AI Agent —— 从"辅助"到"执行"
Figma 最近推出了 AI Agents on Canvas。这个更新的力度比我预想的大很多。
6.1 之前 vs 现在
| 旧模式 | 新模式 |
|---|---|
| AI 出建议，人来执行 | AI 直接在画布上操作 |
| 生成的是图片或描述 | 生成的是可编辑的 Figma 图层 |
| 不感知你的设计系统 | 读取你的组件库和变量 |
底层是通过 MCP 协议实现 AI 和 Figma 的双向通信——AI 调用的是 Figma 的操作 API，不是生成图片贴进去，而是真的在操控图层。
6.2 Skills 决定一切
Figma AI Agent 好不好用，很大程度上取决于你的 Skills 写得好不好。
Skills 在这里是一个 Markdown 文件，本质上是给 AI 的"设计规则说明书"。你在里面写清楚：用什么颜色、用哪些组件、间距怎么定义、按钮圆角多少，AI 就会照着来做。
不写 Skills，AI 就是在乱猜。写好 Skills，AI 才能真正用你的设计系统生成一致的设计。
这个经验跟所有 Agent 产品都相通：
Agent 的输出质量 = 模型能力 × Skills 的质量。 模型是公共品，大家用的都差不多。真正拉开差距的是 Skills——也就是你把业务知识、流程规范、质量标准封装得多好。
6.3 MCP 的价值不只是"读"，更在于"写"
之前 AI 和 Figma 的集成，基本上是单向的——AI 读取设计稿，然后在外面生成代码。
现在通过 MCP，变成了双向的——AI 不仅能读，还能往 Figma 里写。这意味着 AI 从"参谋"变成了"执行者"。
这是 AI 产品化的一个重要趋势：从"提供建议"到"直接执行"。
07. 拆完四个产品，我发现了同一套底层模式
把 Claude Code、OpenClaw、飞书 CLI、Figma AI 放在一起看，它们虽然产品形态完全不同，但底层架构惊人地一致。
我把它总结为 6 层 Agent 架构模型：
┌──────────────────────────────────────────┐
│ 第1层：指令层 │
│ 全局规范 + 场景规则 + 单次指令 │
│ 越近越优先，分层覆盖 │
├──────────────────────────────────────────┤
│ 第2层：Agent 层 │
│ 按角色/场景拆分 │
│ 每个 Agent 有明确的能力边界 │
├──────────────────────────────────────────┤
│ 第3层：Skill 层 │
│ 把业务流程封装成可复用的标准化模块 │
│ 一个 Skill 可以被多个 Agent 调用 │
├──────────────────────────────────────────┤
│ 第4层：MCP 层 │
│ 连接外部工具和数据源 │
│ 先开放读操作，再开放写操作 │
├──────────────────────────────────────────┤
│ 第5层：模型层 │
│ 多模型路由，按任务复杂度动态选择 │
│ 不是用最好的，是用最合适的 │
├──────────────────────────────────────────┤
│ 第6层：守护层 │
│ 自动化质量检查 │
│ Hooks / 评分反馈 / 人工确认 │
└──────────────────────────────────────────┘
每个产品对这 6 层的侧重点不同：
| 产品 | 最突出的层 | 设计亮点 |
|---|---|---|
| Claude Code | 指令层 + 守护层 | CLAUDE.md 三级分层，Hooks 自动化守护 |
| OpenClaw | MCP 层 + 模型层 | 消息网关统一入口，多模型自由切换 |
| 飞书 CLI | Skill 层 + MCP 层 | 19 个标准化技能包，Agent-first API 设计 |
| Figma AI | Skill 层 | Skills 质量直接决定输出质量，MCP 双向通信 |
但 6 层都不可少。 缺了指令层，Agent 不知道该遵守什么规则；缺了 Skill 层，Agent 只能闲聊不能干活；缺了 MCP 层，Agent 的手够不到真实数据；缺了守护层，Agent 的输出质量无法保证。
08. 一张图讲清楚 Agent、Skill、MCP 的关系
怕你前面看完还是有点模糊，用一个具体场景把三者串起来：
场景：用户问"帮我查一下 A 产品在德国市场上个月的销量，顺便生成一段促销文案"
用户发出请求
↓
Agent（产品方案专家）接收后判断：
"这里有两个任务——一个是数据查询，一个是内容生成"
↓
任务1：调用 Skill「销量查询」
├── 步骤1：解析意图 → 产品A、德国、上个月
├── 步骤2：调用 MCP → 连接销量数据库，查询结果
├── 步骤3：调用 MCP → 连接库存数据库，补充库存信息
└── 步骤4：按模板格式化数据
↓
任务2：调用 Skill「促销文案生成」
├── 步骤1：把任务1的销量数据作为上下文注入
├── 步骤2：调用 MCP → 检索产品知识库，获取卖点信息
└── 步骤3：按促销文案模板生成输出
↓
Agent 组装两个任务的结果，返回给用户
三者各自的角色：
- Agent 做了判断和编排——识别出两个任务，决定先查后写，最后组装结果
- Skill 做了执行——每个任务有标准化的步骤
- MCP 做了连接——实际去查数据库、检索知识库
如果没有 Agent：用户得自己把任务拆开，分别去两个系统操作
如果没有 Skill：Agent 每次都要重新"想"怎么做，输出不稳定
如果没有 MCP：Agent 只能编故事，没法查到真实数据
09. 三个我越来越确信的判断
拆完这四个产品，加上自己实际搭 Agent 工作流的经验，有三个判断越来越清晰：
判断一：AI 产品的壁垒不在模型，在于连接和编排
模型是公共品——GPT、Claude、Gemini，大家都能用。
但你的 Milvus 向量库里有什么数据、你的 Skill 编排了什么业务流程、你的 MCP 连接了哪些内部系统——这些别人复制不了。
一个只用通用模型的 Chatbot，和一个接了内部数据库 + 知识库 + 业务 API 的 Agent，解决问题的能力完全不在一个量级。
判断二：Agent 的能力边界必须在设计阶段就定义
很多人做 AI 产品的思路是：先上一个通用模型，让用户随便问，看看能不能答对。
这个思路的问题是：模型什么都能"答"，但不是什么都能"答对"。
更好的方式是：
- 先定义 Agent 能做什么、不能做什么（能力边界）
- 对于能做的，用 Skill + MCP 保障执行质量
- 对于不能做的，明确拒绝或引导到人工
- 对于不确定的，标注置信度或加人工确认
Claude Code 的 Hooks、Figma AI 的 Skills 规范、OpenClaw 的权限系统，本质上都是在做同一件事：给 Agent 划定能力边界，让它在边界内做到最好，而不是在边界外胡说。
判断三：从"提供信息"到"提供可执行的行动建议"
以前 AI 产品的输出标准是"回答准确"。
现在顶级 Agent 产品的输出标准已经变了——不是给你一个准确的知识点，而是给你一个可以直接拿去用的东西。
- 不是"这两个产品的参数如下"，而是"面对客户时你可以这样说"
- 不是"翻译结果如下"，而是"已按品牌规范翻译并通过术语检查"
- 不是"代码有这些问题"，而是"已修复并通过测试"
从"提供信息"到"提供可直接执行的行动建议"——这是 AI 产品输出标准的根本转变。
10. 如果你想自己搭一个 Agent 工作流
看完这些，如果你也想动手试试，我的建议是从最简单的开始：
入门路径：Claude Code + Skills + MCP
- 先装 Claude Code，用起来再说
- 封装一个你自己的 Skill——找一个你每天重复做的任务（写周报、整理笔记、审查文档），把流程封装成一个 Skill
- 接一个 MCP Server——Notion、Google Workspace 都有现成的 MCP，接上后 AI 就能操作你的文档和表格
- 写好 CLAUDE.md——把你的工作规范、偏好、常用术语写进去，让 AI 按你的标准来
进阶路径：OpenClaw + 自定义 Agent
如果你想完全自己控制 Agent 的行为：
- 租一台最便宜的 VPS（我用的 68/年的阿里云）
- 装 OpenClaw
- 接消息通道
- 配置模型和 Skills
- 逐步扩展 MCP 工具
不管走哪条路径，核心都是同一件事：
找到一个真实的、高频的、有数据支撑的场景，用 Agent + Skill + MCP 跑通它。
最后
回到开头的问题：Agent、Skill、MCP 到底怎么分？
答案很简单：
- Agent = 谁来做（角色 + 判断 + 决策）
- Skill = 做什么（流程 + 步骤 + 标准）
- MCP = 用什么做（工具 + 数据 + 连接）
这三个概念不是三个独立的东西，而是 Agent 产品的三个必要组成部分。
缺了任何一个，Agent 要么不知道该做什么（缺 Skill），要么做不了真正的事（缺 MCP），要么没有判断力只能机械执行（缺 Agent 的决策能力）。
搞懂了这个，你再看任何 AI Agent 产品，都能快速看到它的架构在哪、长板在哪、短板在哪。
这比记住一堆术语有用得多。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
8
0- 0
已为社区贡献6条内容
所有评论(0)