做 AI Agent，先弄懂 MCP 和 Skills
分清MCP与Skills，AI Agent的正确打开方式！一文解析两者区别及使用场景。核心内容：1. MCP的定义与作用：Model Context Protocol作为中间层标准化外部数据调用2. MCP与提示词工程、上下文工程的区别：明确不同AI应用场景的处理逻辑3. MCP解决的关键问题：安全、标准地将外部数据和工具接入AI模型
MCP和Skills分别应该在什么时候使用。
读完后，两者的区别与适用场景就清楚了。
先从大模型本身讲起。
大模型可以被看作一台预测机器：它阅读过大量书籍、网页、文档和论坛帖子，再依据这些信息中的模式回答各种问题。
例如询问唐朝的发展历史，它会知道。
如果问怎么检查一个数据库，它也了解一些通用做法。
不过，要让它真正给出正确答案，只有“它知道很多”还不够。
更重要的是把正确的上下文提供给它。
上下文可能包含许多内容。
例如，你希望数据以什么格式输出。
也可能是你们团队如何配置数据库。
还可能是某个工具刚查询过数据库，并把查询结果交还给模型。
如果只是告诉模型一个角色、一个任务，让它回答问题，这通常叫提示词工程。
当格式要求、外部数据、工具返回结果和业务规则被一并提供，让模型依据这些上下文作出判断时，就更接近上下文工程。
简单说，提示词工程更像是“怎么问”。
所谓上下文工程，更像是“预先备齐模型作判断所需的信息”。
于是问题出现了：
正确的上下文究竟该怎样交给 AI？
又该怎样以此为基础，打造一个真正能做事的 Agent？
先来看 MCP。
假设 Agent 需要读取 CRM，也就是客户关系管理系统中的数据。
有一种粗糙方法：把该系统的 API 文档和访问凭证都交给大模型，再对它说：
请更新这个客户的联系方式，一定不要出错。
这种方式听上去并不稳妥。
因为文档理解、接口调用判断、认证处理和请求格式处理，实际上全被交给了模型。
MCP，即 Model Context Protocol，正是为解决这个问题而来。
它将 AI 模型与各类数据源之间的沟通方式进行了标准化。
可以把它看成一个中间层。
服务 API 会被它包装成大模型更易使用的格式，认证、权限和读写范围等事项也由它处理。
在后台，MCP server 接收来自 AI 应用或开发环境的请求。模型提出所需信息后，MCP server 把请求转换为实际接口调用，例如一次查询或更新请求。
服务随后返回结果，结果再被放入模型的上下文窗口。
这样，AI 无须拿着大段接口文档自行猜测，而能经由标准层访问外部数据源。
那么，MCP 更适合解决哪类问题？
概括来说，就是“如何安全、标准地把外部数据和工具交给模型”。
但另一个问题随之出现。
MCP 能帮助模型取得外部数据，却不一定了解团队希望如何处理这些数据。
例如，同样从 CRM 读取客户资料，销售团队可能规定每次必须按固定格式输出：
输出客户姓名、联系方式、最近一次沟通记录，以及客户偏好的沟通方式，如微信、电话或企业微信。
例子虽然具体，反映的问题却很真实。
如果你希望模型每一次都用同一种格式、同一种规则、同一种流程来做事，只靠临时提示词就会比较累。
大模型并非完全确定；面对同一任务，它今天和明天可能采用不同写法。
Skills 的价值正在这里。
Skills 更接近一套为模型准备、可以重复使用的能力包。
其中可以包含一个 Markdown 文件，用来说明 Skill 的名称、使用时机和具体做法。
此外，它还能附带资源文件、示例乃至脚本。
例如，你经常借助大模型清理 Excel 文档、检查代码、执行某种验证或进行合规检查。
这些固定提示词、固定步骤、配套脚本，都可以打包成一个 Skill。
更关键的是，Skill 能在有需要时自动进入模型上下文。
询问代码错误时，模型才加载与代码调试有关的 Skill；询问文档整理时，再加载对应的 Skill。
这样一来，无须每次手动向模型重复粘贴大量规则。
现在回到前面的问题：
何时选择 MCP，何时选择 Skills？
如果 AI 应用需要访问实时数据，并且必须在受控方式和权限边界内访问，MCP 会更合适。
例如，查询某位客户的最新信息。
这类需求都属于“AI 前往外部系统获取数据或调用工具”。
但若只想为 AI 增加一项可复用的自定义能力，配置 MCP 可能显得过重。
这种情况更适合 Skills。
Skills 较为轻量，作用是教模型怎样完成一件事。
例如获取投资数据并进行分析，或利用 Skill 附带的脚本和示例完成某项任务。
因此，可以这样理解：
MCP 类似于 Agent 与外部工具之间的集成层。
Skills 则像模型完成某类任务时使用的说明书与工具包。
登录查看剩余 70% 内容
