MCP、Skill、Function Calling，到底是什么关系？

MCP，全称 Model Context Protocol，是 AI 应用接入外部工具和数据的开放通信协议。它统一能力描述、发现、调用和结果返回，让同一套外部能力能够被不同 AI 应用复用，减少重复适配。

三者的职责分别是：Tool Calling 让模型表达“调用哪个工具、传什么参数”；MCP 规定应用怎样发现外部能力、发送请求并取得结果；Agent 根据任务目标和返回结果决定下一步。

例如把天气查询封装为 MCP Server 后，聊天应用和编程 IDE 都可以通过各自的 MCP Client 获取工具说明、发送城市参数并接收天气结果。模型再根据结果回答用户，或继续处理信息缺失的问题。

MCP 统一的是接入方式，不负责规划任务，也不保证调用正确。应用和服务端仍要检查参数、权限和执行结果；工具也可以由程序直接触发，不必每次都经过模型。

MCP 中三种角色的分工是：

• Host 是用户使用的 AI 应用，管理对话、模型调用、可用工具和授权策略，并把需要的信息交给模型。
• Client 是 Host 内的 MCP 协议组件，与对应 Server 交换能力发现、工具调用和结果消息；它不是语言模型。
• Server 暴露工具、资源和提示模板，并在收到请求后访问实际文件、数据库或业务 API，返回结果。

一次工具调用通常是：Client 获取工具定义，Host 适配给模型；模型提出调用，Host 检查并经 Client 发给 Server，Server 执行后沿原路径返回。

协议统一了这些接口，也提供授权框架；工具是否可信、用户能操作哪个资源、执行进程有什么权限，仍要由 Host、Server 和底层系统落实。Host 限制本次允许的动作，Server 校验身份与资源范围，文件和网络访问再由实际权限或隔离机制约束。

Function Calling 是模型根据用户问题和工具定义，生成工具名称及结构化参数，再由应用执行工具、把结果交回模型的过程。完整流程可以分成五步：提供工具定义、模型生成调用、应用校验并执行、按调用标识回填结果、模型继续判断或回答。

例如用户问北京天气，应用把天气工具的用途和城市参数说明发给模型。模型提出查询北京的调用，应用实际请求天气服务，再把查询结果关联到这次调用交回模型，模型才据此组织回答。工具定义不代表函数已经执行；一次任务也可能不调用工具，或者连续调用多轮。

Function Calling 通常指模型通过约定格式表达工具名称和参数的机制；MCP 是应用与外部能力提供方之间的标准连接协议；Tool Use 泛指使用工具，也常被厂商用作 Function Calling／Tool Calling 的接口名称。 三者可以出现在同一条调用链里，不能机械地划成互斥的三种方案。

• Function Calling／Tool Calling：解决模型如何接收工具定义、提出调用请求，以及结果怎样关联回本次调用。实际执行由应用、工具服务或供应商运行时负责。
• MCP：解决宿主应用怎样发现和调用外部工具、读取资源或获取提示模板。工具部分有自己的定义、请求和结果契约。
• Tool Use：描述工具使用过程时范围较宽；在具体 API 文档里也可能就是结构化工具调用的名字。例如 Anthropic 明确把 tool use 与 function calling 并称。

例如“查北京天气”：模型生成天气工具调用后，应用可以直接调用本地函数或 HTTP API；也可以把请求交给 MCP Client，再由天气 MCP Server 执行。没有 MCP 仍能做 Function Calling；接入 MCP 也不会自动让模型选对工具或填对参数。

模型获得 MCP 工具信息，要经过 Server 提供定义、Client 发现、Host 适配并传给模型 这条链路：

1. Server 定义工具的名称、用途和 inputSchema，其中 JSON Schema 描述参数类型、必填项和取值约束。
2. Host 中的 MCP Client 通过 tools/list 获取当前可用工具；Host 选择本次允许使用的工具，并适配成模型接口支持的工具定义格式。
3. Host 调用模型时，把用户请求、必要上下文和工具定义一起提供。模型据此选择工具并生成结构化名称与参数；这些信息进入的是本次推理输入，不是模型权重。
4. Host 解析、校验并路由调用，由 Client 发出 tools/call，Server 执行后返回结果，再由 Host 作为对应工具结果交回模型。

所以 MCP 的 inputSchema 和模型接口的工具字段分属不同接口，中间需要宿主适配；模型输出了工具调用，也还没有执行工具。

业务接口封装成MCP工具，我会先定义一个模型能理解、业务能校验的稳定契约，再在Server里适配原接口：

1. 明确工具用途：名称、适用场景、前置条件和副作用，避免一个工具承接所有业务操作。
2. 设计入参：用 inputSchema 描述字段、类型、必填、枚举和单位；身份、凭证及内部地址由可信程序处理。
3. 设计出参：保留业务结果、状态、时间和来源等必要信息。需要结构化校验时提供 outputSchema，返回相应的 structuredContent。
4. 实现执行适配：校验参数和资源权限，转换为原接口请求，再规范化结果、错误、超时及重试行为。
5. 分层处理兼容：分别管理工具业务版本、底层API版本、SDK版本和MCP协议revision，用实际Client验证发现、调用及异常路径。

Host通过Client发现工具并适配给模型，模型提出调用后，Server才执行实际业务。MCP统一连接方式，不会自动解决字段语义、授权和业务副作用。

stdio 和 Streamable HTTP 都用来传递 MCP 的 JSON-RPC 消息，区别主要在服务怎样启动、消息怎样传输，以及响应是否可以分多次送达。

• stdio：Client 拉起 Server 子进程，通过管道通信。Server 从标准输入读取请求，将响应写到标准输出；消息按换行分隔，日志写到标准错误。
• Streamable HTTP：Server 独立提供 HTTP 服务，Client 向 MCP 端点发送 POST。响应可以一次返回 JSON，也可以在这次请求的 SSE 响应流中逐步发送消息。

所以它是支持流式响应的 HTTP 传输方式，每个请求不必都返回流。这种“流式”也不等于大模型必然逐 Token 输出，更不表示它是专门传送音视频帧的媒体协议。

下面的具体行为按 MCP 2026-07-28 说明；接入旧 Server 时，要匹配它实际使用的协议版本。

Agent Skill 是把一类任务的执行方法整理成可复用的技能包，通常包括任务说明、操作步骤和输出要求，还可以附带脚本、参考资料与模板。Agent 在遇到相关任务时加载这些内容，再使用已有工具完成工作。

以常见的 Agent Skills 格式为例，技能目录的入口是 SKILL.md：元信息描述名称和适用场景，正文说明怎样执行。系统可以先提供少量元信息，匹配任务后加载正文，需要时再读取资源或运行脚本。这种按需展开的方式，让一套较完整的工作方法可以复用，同时减少每次都塞入全部资料的开销。

例如“面试题答案编写”Skill 可以规定怎样查证资料、组织核心回答、处理图示和检查来源；真正的检索、读文件和生成内容，由 Agent 结合工具执行。

**MCP 是 AI 应用接入外部能力的协议；Skill 是 Agent 可复用、按需加载的任务能力包。**这里的 Skill 指 Agent Skills 这类组织任务知识和流程的方式，不局限于某一个产品。

MCP 约定客户端和服务端怎样发现能力、传递参数、读取资源和返回结果，常见能力包括 Tools、Resources 和 Prompts。Skill 则说明什么时候处理某类任务、按什么步骤做、参考哪些资料、交付什么结果；采用 Agent Skills 格式时，通常以 SKILL.md 为入口，也可以附带脚本、模板和参考文件。

例如做代码审查，Skill 规定先理解需求和差异，再检查正确性、安全和边界条件，最后按位置和依据输出问题；Agent 可以通过 MCP 工具读取仓库差异、提交记录或测试信息。**Skill 提供任务方法，MCP 提供标准化接入，两者可以组合。**只用本地文件、CLI 或直接 API 的 Skill 也能工作；接入 MCP 的 Agent 也不必依赖 Skill。

编写 Skill，是把一类任务中可复用的方法整理成能被发现、按步骤执行、结果可检查的能力包。我会按下面的顺序做：

1. 选定任务和成功标准：明确处理什么输入、输出什么结果，先用实际例子找出需要补充的业务知识和步骤。
2. 写好触发描述：在 SKILL.md 的元数据里给出清楚的名称和适用场景，让 Agent 能判断什么时候使用。
3. 写可执行的正文：说明输入要求、默认步骤、工具或资源用法、结果格式，以及缺信息或执行失败时怎样处理。
4. 按需拆资源：长资料放参考文件，稳定操作可封装脚本，模板放资源目录；主文件写清何时使用它们。
5. 在目标宿主验证并迭代：分别检查该不该触发、是否按流程执行、产物是否符合要求，再根据具体失败调整。

简单任务从一个清楚的 SKILL.md 开始就够了，不需要一开始搭完整平台或堆很多目录。

Skill的渐进式披露是先让Agent发现“有哪些能力”，任务匹配后再读“怎么做”，执行中才加载所需细节。它把能力发现与详细内容分开，减少无关说明长期占据上下文，也让同一个Agent可以管理更多专业方法。

常见组织是名称与描述、SKILL.md正文、按需引用的资料和脚本三层。这里的“层”描述信息加载时机，不是要求技能必须拆成三个文件，也不是让用户一步步确认。

Agent 使用 Skill，通常经历发现技能 → 判断是否匹配 → 加载正文 → 按指令执行 → 检查结果这条链路。

宿主先发现技能包，把名称、描述等简短信息提供给模型；模型结合任务判断需要哪项技能，或由用户显式指定。随后，宿主通过文件读取工具、专用加载工具或直接注入，将 SKILL.md 的指令放入本次上下文。模型据此组织步骤，按需读取参考资料、使用模板或请求执行脚本；运行时负责真正调用工具并返回结果，模型再检查是否满足任务要求。

**选择 Skill、读取 Skill 和执行业务动作是不同环节。**模型输出调用请求，程序执行请求；读取到一份文档并不意味着里面的脚本已经运行。Skill 也不一定需要业务工具，例如表情翻译技能加载规则后就可以直接生成结果。