AI Agent 落地入门：从模型、工具到 Skills 与 MCP 的分工

文章目录

[AI Agent 落地入门：从模型、工具到 Skills 与 MCP 的分工](#AI Agent 落地入门：从模型、工具到 Skills 与 MCP 的分工)
- [1. 先把 Agent 从聊天模型里拆出来](#1. 先把 Agent 从聊天模型里拆出来)
- [2. Agent 的核心不是一次回答，而是一个工作循环](#2. Agent 的核心不是一次回答，而是一个工作循环)
- [3. MCP 解决"能连接什么"的问题](#3. MCP 解决“能连接什么”的问题)
- [4. Skills 解决"应该怎么做"的问题](#4. Skills 解决“应该怎么做”的问题)
- [5. Skills 和 MCP 的边界：一个管流程，一个管连接](#5. Skills 和 MCP 的边界：一个管流程，一个管连接)
- [6. 别把 Skills、Prompts、Projects、Subagents 混成一件事](#6. 别把 Skills、Prompts、Projects、Subagents 混成一件事)
- [7. 什么时候用模型、工具、MCP、Skill、Agent](#7. 什么时候用模型、工具、MCP、Skill、Agent)
- 常见坑
- - [1. 把 Agent 当成"更长的 prompt"](#1. 把 Agent 当成“更长的 prompt”)
  - [2. 以为装了 MCP 就自动可靠](#2. 以为装了 MCP 就自动可靠)
  - [3. 把参考实现仓库当成 MCP 服务器大全](#3. 把参考实现仓库当成 MCP 服务器大全)
  - [4. Skill 写成百科全书](#4. Skill 写成百科全书)
  - [5. 没有结束条件](#5. 没有结束条件)
  - [6. 忽视权限和安全](#6. 忽视权限和安全)
- 一个可落地的建设顺序
- 总结
- 参考资料

很多人第一次接触 AI Agent 时，会把它理解成"更聪明的聊天机器人"或者"一个很长的提示词"。这个理解只对了一小半。

如果只是回答一个概念题，模型本身就够了；但真实任务通常不是这样。你可能希望它读飞书文档、查 GitHub issue、分析数据库、跑脚本、生成文件、打开浏览器、最后把结果发布到某个平台。这个时候，问题已经从"模型会不会回答"变成了"系统能不能可靠地把事情做完"。

所以先记住一句话：Agent 不是一个模型，而是一套围绕目标持续行动的系统。

这篇文章围绕三个问题展开：

AI Agent 和普通大模型到底差在哪里？
MCP 和 Skills 分别解决什么问题，为什么不能互相替代？
如果要在团队里落地 Agent，应该先沉淀 Skill，还是先接 MCP？

1. 先把 Agent 从聊天模型里拆出来

Google Agents 白皮书对 Agent 的定义很朴素：它是一个会观察环境、使用工具并对外部世界采取行动，以尝试达成目标的应用。这个定义比"会聊天的模型"更接近工程实物。

一个最小可用的 Agent，通常至少包含三类东西：

组成	它负责什么	没有它会怎样
Model	理解意图、推理、规划、生成下一步动作	只剩固定脚本，无法处理开放任务
Tools	查询外部信息、操作文件、访问 API、执行动作	只能凭训练记忆回答，容易过时或编造
Orchestration	把"观察、思考、行动、反馈"串成循环	工具调用会变成一次性动作，任务难以闭环

资料里用了一个很直观的说法：模型负责"想"，Agent 负责"想了就干"。这句话有用，但工程上还要再补一句：Agent 不是随便干，它必须在权限、上下文、工具契约和结束条件里行动。

举个例子，用户说：

text 复制代码

帮我整理这几篇资料，写成一篇可以发布的博客，配图给提示词，最后不要直接发布。

普通模型可以直接写一篇文章，但它不知道资料真实内容，也不知道本地文件路径，更不会检查图片路径是否存在。Agent 的做法应该是：

读取资料来源。
判断哪些内容能公开，哪些要去掉。
提炼文章主线。
规划图片。
写 Markdown 文件。
生成配图提示词文件。
检查代码块、图片引用、占位符和发布状态。

这才是"把事情做完"的形态。

2. Agent 的核心不是一次回答，而是一个工作循环

Agent 的执行过程可以简化成下面这个循环：

text 复制代码

目标 -> 观察上下文 -> 推理和计划 -> 调用工具 -> 观察结果 -> 判断是否继续 -> 输出结果

这个循环看起来简单，但它解释了 Agent 和普通问答的关键区别。

普通问答通常是：

text 复制代码

用户问题 -> 模型回答

Agent 更像是：

text 复制代码

用户目标 -> 计划第 1 步 -> 调工具 -> 看结果
         -> 修正计划 -> 调工具 -> 看结果
         -> 达到停止条件 -> 汇总交付

这也是 ReAct、Chain-of-Thought、Tree-of-Thoughts 这些推理框架存在的原因。它们不是为了让回答显得更复杂，而是为了让系统在多步骤任务里有更稳定的行动节奏。

以航班查询为例，模型如果只基于训练数据回答，很容易给出过时信息；Agent 则应该调用实时航班 API，把查询结果拿回来，再根据用户偏好筛选。这里的关键不是"模型知道航班"，而是"系统知道什么时候不能猜，必须查工具"。

判断一个任务是否需要 Agent，可以看它是否满足下面任意条件：

任务特征	是否需要 Agent
只需要解释一个概念	通常不需要
需要读取外部资料或实时数据	需要工具，可能需要 Agent
需要跨多个系统连续操作	基本需要 Agent
需要中途根据结果调整路径	需要 Agent
需要最后产出可验证文件或外部系统状态	需要 Agent

3. MCP 解决"能连接什么"的问题

MCP，全称 Model Context Protocol，官方文档把它描述成连接 AI 应用和外部系统的开放标准，也常用"AI 应用的 USB-C 接口"来类比。这个类比很准确：USB-C 不规定你怎么剪视频、怎么备份照片，它只规定设备如何接上；MCP 也不规定 Agent 怎么推理和编排任务，它规定 AI 应用如何拿到外部系统提供的上下文与能力。

它让模型客户端能够用统一方式发现和调用外部能力，例如：

查询 GitHub issue、PR、CI 状态；
读取 Notion、飞书、Google Drive 里的文档；
查询数据库、监控系统、内部 API；
打开浏览器、操作设计稿、执行自动化流程；
暴露工具、资源和提示模板给 Agent 使用。

MCP 的价值在于"标准化连接"。没有 MCP 时，每接一个系统都要写一套私有适配逻辑；有了 MCP，客户端和服务器之间可以围绕工具列表、输入参数、返回结果、资源引用形成更清晰的契约。

从架构上看，MCP 有三个角色：

角色	作用
MCP Host	AI 应用本体，例如 Claude Desktop、Claude Code、IDE 插件
MCP Client	Host 为每个 MCP Server 创建的连接组件
MCP Server	提供上下文和能力的程序，可以在本地，也可以在远端

MCP Server 暴露给客户端的核心能力也不只有"工具"：

能力	含义
Tools	可执行动作，例如查数据库、读文件、调 API
Resources	可读取上下文，例如文件内容、数据库 schema、业务记录
Prompts	可复用交互模板，例如某类任务的提示模板

这点很重要。MCP 不只是"函数调用协议"，它还包括资源、提示、能力发现、连接生命周期和传输层。只是落到日常使用里，大家最容易感知到的是工具调用。

从工程视角看，MCP 更像"插座和接口规范"，而不是"业务流程本身"。

例如在 Claude Code 里添加 MCP 服务器，资料中提到过几种典型方式。当前 MCP 官方文档里主要强调两类传输：本地进程常用 stdio，远程服务常用 Streamable HTTP；具体客户端的命令会按产品不同略有差异。

shell 复制代码

# 远程 HTTP
claude mcp add --transport http <name> <url>

# 本地 stdio
claude mcp add --transport stdio --env KEY=VALUE <name> -- <command>

# 查看和管理
claude mcp list
claude mcp get github
claude mcp remove github

这些命令解决的是"怎么把外部能力接进来"。但接进来之后，什么时候查、查哪些字段、怎样判断结果是否可信、最后输出成什么结构，MCP 本身并不会自动替你决定。

另外要注意一个原文更新点：modelcontextprotocol/servers 仓库现在更像"参考实现仓库"，不是完整 MCP 服务器黄页。真要找可用服务器，应优先看 MCP Registry 或具体产品的官方连接器说明。

这就引出了 Skills。

4. Skills 解决"应该怎么做"的问题

Skills 可以理解成给 Agent 的"领域工作手册"。它不是简单提示词，而是一组结构化文件，用来封装领域知识、流程步骤、质量标准和可复用脚本。Anthropic 的 Agent Skills 原文后来还补充了一个关键信息：Agent Skills 已经作为开放标准发布，目的就是让这种"技能包"具备跨平台可移植性。

一个 Skill 目录通常长这样：

text 复制代码

blog-md-writer/
├── SKILL.md
├── references/
│   └── style-guide.md
├── scripts/
│   └── validate_markdown.py
└── assets/
    └── template.md

其中 SKILL.md 是入口，通常包含：

什么时候触发这个 Skill；
任务应该按什么步骤做；
需要读取哪些参考资料；
可以使用哪些脚本或模板；
什么结果才算完成；
哪些行为必须避免。

Skills 的一个关键设计是渐进披露：Agent 不需要一开始把所有资料塞进上下文，而是先看到 Skill 的名称和描述；确认需要后，再读取 SKILL.md；如果仍然需要细节，再读取 references/ 或运行 scripts/。官方文档里把这件事讲得很具体：元数据在启动时进入上下文，SKILL.md 只在匹配任务时加载，额外文件和脚本只在需要时读取或执行。

这带来两个好处：

层级	内容	作用
元数据	name、description	让 Agent 判断是否需要这个 Skill
SKILL.md	核心规则和流程	指导任务执行
references/	深入资料、规范、案例	需要时再加载
scripts/	可复用检查或转换逻辑	把易错步骤工具化

所以 Skills 的重点不是"让模型记住更多知识"，而是把专家怎么做事沉淀成可复用流程。这也解释了为什么一个 Skill 可以很大：只要内容放在文件里，未被读取的部分就不会提前挤占上下文。

5. Skills 和 MCP 的边界：一个管流程，一个管连接

最容易混淆的地方是：MCP 也有工具说明，Skill 也有流程说明，那它们谁说了算？

一个实用判断是：

MCP 管"如何正确连接和调用外部系统"；
Skill 管"为了完成这个业务目标，应该怎样组织流程和交付物"。

如果二者发生冲突，通常应该让 MCP 的工具契约优先，因为参数格式、认证方式、返回结构这些东西错了，工具就用不了；而 Skill 负责在工具可用的前提下决定任务路线和输出标准。

可以用一张表理解：

问题	更像 MCP 的职责	更像 Skill 的职责
如何连接 GitHub、数据库、浏览器	是	否
这个任务应该先查 issue 还是先读设计文档	否	是
工具参数应该传 JSON 还是文件路径	是	否
输出应该是日报、PR 描述还是技术博客	否	是
失败后如何保留中间产物并告知用户	部分相关	是
团队的合规、风格和质量检查	否	是

拿"写技术博客并发布"这个场景举例：

环节	Skill 做什么	MCP 或工具做什么
读取资料	规定先读真实资料，不凭链接臆写	通过飞书、文件系统或浏览器读取内容
提炼主线	规定问题驱动、去掉内部信息、保留实战价值	不负责判断文章结构
规划插图	规定封面和正文图要有教学作用	可选调用图片生成工具
生成 Markdown	规定标题、图片路径、代码块、参考资料格式	写入本地文件
发布 CSDN	规定必须先问用户、先校验图片	Playwright MCP 操作网页上传和发布

这就是"Skills + MCP"组合的价值：MCP 让 Agent 能触达外部世界，Skills 让 Agent 按团队认可的方式使用这些能力。

6. 别把 Skills、Prompts、Projects、Subagents 混成一件事

Claude 原文里还有一个很实用的比较：Skills 并不是要替代 prompts、Projects 或 subagents。它们解决的是不同层级的问题。

组件	更适合解决什么问题	和 Skill 的区别
Prompt	一次性的具体指令、当前任务的临时上下文	Prompt 是当场说，Skill 是可复用的方法
Project	某个项目长期共享的背景知识、资料和自定义指令	Project 更像"这里有什么背景"，Skill 更像"这类事怎么做"
Subagent	独立上下文、独立权限、可并行处理的专门执行者	Subagent 是执行单元，Skill 是可被主 Agent 或 subagent 复用的能力
MCP	外部系统连接、工具、数据和资源	MCP 让系统能访问，Skill 规定访问后怎么做

举个代码评审的例子：Project 里可以放代码库背景和团队目标；MCP 可以接 GitHub 和 CI；subagent 可以专门做只读 review；Skill 则沉淀团队的评审清单、风险分级、输出格式和"不应该擅自改什么"的规则。

如果你发现自己只是在当前对话里补一句要求，用 prompt 就够了；如果你每次都复制同一套做法，就应该沉淀成 Skill；如果你需要隔离上下文或限制工具权限，再考虑 subagent。

7. 什么时候用模型、工具、MCP、Skill、Agent

落地时不要一上来就说"我要做一个 Agent 平台"。更短的路径是从任务复杂度倒推。

你要解决的问题	推荐做法
一次性解释、改写、总结	直接用模型
当前任务只差一句临时约束	用 prompt
某个项目需要长期共享背景资料	用 Project
需要读取本地文件或跑一个命令	模型 + 工具
需要稳定连接外部系统	接 MCP
需要复用团队流程和输出标准	写 Skill
需要隔离上下文、限制权限或并行执行	配 subagent
需要跨系统、多步骤、可中途调整	Skill + MCP + Agent 循环
需要多人协作、权限审计、长期运行	再考虑平台化和治理

一个好 Skill 往往比一个"宏大 Agent"更容易先产生价值。原因很简单：真实团队最缺的通常不是模型能力，而是稳定流程。

比如团队里经常有人做这些事：

把会议纪要整理成方案；
根据日志生成排障报告；
把源码分析写成博客；
从 issue、commit、CI 日志里生成 PR 总结；
按公司模板写客户交付文档。

这些任务不一定都需要新 Agent，但很适合先沉淀 Skill。等流程稳定后，再决定要接哪些 MCP，把哪些步骤自动化。

常见坑

1. 把 Agent 当成"更长的 prompt"

Prompt 可以描述目标，但不能替代工具、状态、权限和反馈循环。只靠长 prompt，任务越复杂越容易失控。

2. 以为装了 MCP 就自动可靠

MCP 只是连接能力。工具能调通，不代表结果可信，也不代表 Agent 知道什么时候该调用它。没有流程约束，工具越多反而越容易乱。

3. 把参考实现仓库当成 MCP 服务器大全

modelcontextprotocol/servers 现在主要保存少量 reference servers，用来展示协议和 SDK 用法。找生产可用的连接时，要优先看 MCP Registry、产品官方连接器，或者你们内部维护的 MCP 清单。

4. Skill 写成百科全书

Skill 不是资料仓库。好的 Skill 应该优先写流程、边界和质量标准，详细资料放到 references 里按需读取。

5. 没有结束条件

Agent 循环必须知道什么时候停。比如"文件已生成、检查通过、用户确认是否发布"，这类结束条件比"尽量做好"更可靠。

6. 忽视权限和安全

第三方 MCP 服务器、外部 API、浏览器自动化都有风险。涉及账号、发布、删除、付款、发消息等动作时，必须让用户确认，不能把"能调用"误当成"应该调用"。

一个可落地的建设顺序

如果要在团队里真正用起来，可以按这个顺序推进：

先找高频任务：选择每周都会重复、步骤相对固定、结果容易验收的工作。
写出人工流程：把专家现在怎么做、先看什么、怎么判断、最后交付什么写清楚。
沉淀成 Skill：先写 SKILL.md，再把模板、案例、检查脚本逐步放进去。
补 MCP 连接：只有当流程需要外部系统时，再接 GitHub、Notion、飞书、数据库、浏览器等 MCP。
加质量检查：用示例任务验证输出是否稳定，失败时保留中间产物。
再考虑自动化：先让 Agent 辅助人做，再逐步把低风险步骤交给 Agent 自主完成。

这个顺序的好处是，团队不会陷入"先造一套平台再找场景"的陷阱。第一性原理看，Agent 的价值不是技术名词，而是把一类任务从"每次靠人重新组织"变成"按稳定流程高质量完成"。

总结

AI Agent 的核心不是"模型更聪明"，而是"系统能围绕目标持续观察、推理、行动和校验"。

MCP 和 Skills 则分别解决两个不同问题：

MCP 解决连接问题：Agent 能访问哪些工具、数据和外部系统。
Skills 解决方法问题：Agent 应该按什么流程、标准和风格完成任务。

真正可用的 Agent 往往不是单独靠模型、单独靠 MCP、或者单独靠 Skill，而是三者组合：模型负责推理，MCP 负责触达外部世界，Skills 负责把团队经验变成可复用流程。这样，AI 才能从"会回答"走向"能交付"。

参考资料

Google Agents 白皮书：https://drive.google.com/file/d/1W8EnoPXRLTQesfjvb-b3Zj-dnBf1f--n/view?pli=1
MCP Introduction：https://modelcontextprotocol.io/docs/getting-started/intro
MCP Architecture：https://modelcontextprotocol.io/docs/learn/architecture
MCP Local Servers：https://modelcontextprotocol.io/docs/develop/connect-local-servers
MCP Remote Servers：https://modelcontextprotocol.io/docs/develop/connect-remote-servers
MCP Registry：https://registry.modelcontextprotocol.io/
Claude Code MCP 文档：https://docs.claude.com/en/docs/claude-code/mcp
Anthropic Agent Skills 文档：https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview
Anthropic Skills 示例库：https://github.com/anthropics/skills
Claude Skills 介绍：https://www.claude.com/blog/skills-explained
Extending Claude with Skills and MCP servers：https://claude.com/blog/extending-claude-capabilities-with-skills-mcp-servers
Building Agents with Skills：https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills