AI Agent 落地入门：从模型、工具到 Skills 与 MCP 的分工
文章目录
- AI Agent 落地入门：从模型、工具到 Skills 与 MCP 的分工
- 1. 先把 Agent 从聊天模型里拆出来
- 2. Agent 的核心不是一次回答，而是一个工作循环
- 3. MCP 解决“能连接什么”的问题
- 4. Skills 解决“应该怎么做”的问题
- 5. Skills 和 MCP 的边界：一个管流程，一个管连接
- 6. 别把 Skills、Prompts、Projects、Subagents 混成一件事
- 7. 什么时候用模型、工具、MCP、Skill、Agent
- 常见坑
- 1. 把 Agent 当成“更长的 prompt”
- 2. 以为装了 MCP 就自动可靠
- 3. 把参考实现仓库当成 MCP 服务器大全
- 4. Skill 写成百科全书
- 5. 没有结束条件
- 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 不是随便干，它必须在权限、上下文、工具契约和结束条件里行动。
举个例子，用户说：
帮我整理这几篇资料，写成一篇可以发布的博客，配图给提示词，最后不要直接发布。普通模型可以直接写一篇文章，但它不知道资料真实内容，也不知道本地文件路径，更不会检查图片路径是否存在。Agent 的做法应该是：
- 读取资料来源。
- 判断哪些内容能公开，哪些要去掉。
- 提炼文章主线。
- 规划图片。
- 写 Markdown 文件。
- 生成配图提示词文件。
- 检查代码块、图片引用、占位符和发布状态。
这才是“把事情做完”的形态。
2. Agent 的核心不是一次回答，而是一个工作循环
Agent 的执行过程可以简化成下面这个循环：
目标 -> 观察上下文 -> 推理和计划 -> 调用工具 -> 观察结果 -> 判断是否继续 -> 输出结果这个循环看起来简单，但它解释了 Agent 和普通问答的关键区别。
普通问答通常是：
用户问题 -> 模型回答Agent 更像是：
用户目标 -> 计划第 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；具体客户端的命令会按产品不同略有差异。
# 远程 HTTPclaude mcpadd--transporthttp<name><url># 本地 stdioclaude mcpadd--transportstdio--envKEY=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 目录通常长这样：
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
