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

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还是先接 MCP1. 先把 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需要最后产出可验证文件或外部系统状态需要 Agent3. 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 HostAI 应用本体例如 Claude Desktop、Claude Code、IDE 插件MCP ClientHost 为每个 MCP Server 创建的连接组件MCP Server提供上下文和能力的程序可以在本地也可以在远端MCP Server 暴露给客户端的核心能力也不只有“工具”能力含义Tools可执行动作例如查数据库、读文件、调 APIResources可读取上下文例如文件内容、数据库 schema、业务记录Prompts可复用交互模板例如某类任务的提示模板这点很重要。MCP 不只是“函数调用协议”它还包括资源、提示、能力发现、连接生命周期和传输层。只是落到日常使用里大家最容易感知到的是工具调用。从工程视角看MCP 更像“插座和接口规范”而不是“业务流程本身”。例如在 Claude Code 里添加 MCP 服务器资料中提到过几种典型方式。当前 MCP 官方文档里主要强调两类传输本地进程常用stdio远程服务常用 Streamable HTTP具体客户端的命令会按产品不同略有差异。# 远程 HTTPclaude mcpadd--transporthttpnameurl# 本地 stdioclaude mcpadd--transportstdio--envKEYVALUEname--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 判断是否需要这个 SkillSKILL.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 和 CIsubagent 可以专门做只读 reviewSkill 则沉淀团队的评审清单、风险分级、输出格式和“不应该擅自改什么”的规则。如果你发现自己只是在当前对话里补一句要求用 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?pli1MCP Introductionhttps://modelcontextprotocol.io/docs/getting-started/introMCP Architecturehttps://modelcontextprotocol.io/docs/learn/architectureMCP Local Servershttps://modelcontextprotocol.io/docs/develop/connect-local-serversMCP Remote Servershttps://modelcontextprotocol.io/docs/develop/connect-remote-serversMCP Registryhttps://registry.modelcontextprotocol.io/Claude Code MCP 文档https://docs.claude.com/en/docs/claude-code/mcpAnthropic Agent Skills 文档https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overviewAnthropic Skills 示例库https://github.com/anthropics/skillsClaude Skills 介绍https://www.claude.com/blog/skills-explainedExtending Claude with Skills and MCP servershttps://claude.com/blog/extending-claude-capabilities-with-skills-mcp-serversBuilding Agents with Skillshttps://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills