Tool、API、MCP 与 Skill 的位置

一句话收获：协议解决连接，业务边界和验收仍由系统负责。

这个场景在解决什么问题

这个场景要把四个经常被混为一谈的词放回各自的位置：Tool、API、MCP、Skill。原文的做法是让同一个业务能力依次经过模型、Tool、API、MCP 和 Skill，看每一层各自解决什么。它值得单独学，是因为现实中常有人以为"接了 MCP 就安全了""写个 Tool 描述就等于有能力了""一个 Prompt 模板就是 Skill"，这些混淆会直接导致系统边界失守。

先理清这条判断链（文字版）

这个场景是一条"从意图到能力、再到连接和方法"的链：先看模型怎么生成行动意图（Function Calling），再看 API 和 Tool 怎么提供和暴露真实能力，接着看 MCP 怎么统一连接和发现，最后看 Skill 怎么把多对象组织成可复用能力。验收标准是——能不能说清"哪一层解决连接、哪一层负责业务边界和验收"。

先看 Function Calling：模型生成结构化行动意图，尚未产生副作用。
再看 API 与 Tool：API 提供真实能力，Tool 把用途/参数/结果语义暴露给 Agent。
接着看 MCP：统一能力发现和调用方式，解决互操作。
最后看 Skill：把方法、资料、工具、边界、验收组织成可复用能力。

逐层详解

第 1 步：Function Calling

原文：模型生成结构化行动意图，尚未产生外部副作用。

白话：Function Calling（函数调用，指模型输出一个结构化的"我想调用某个函数、参数是什么"的意图）只是模型吐出的一个"意图"，还没有真正去执行、没有产生任何外部副作用。

类比：像你在点餐系统上"下单"这个动作的"心里默念"阶段——你想好了"要一份炒饭、少辣"，但还没提交，厨房还没做。

举例：模型输出一个 JSON 格式的意图「调用 refund_query，参数 order_id=1001」，但这只是模型的想法，退款查询还没真正发生。

为什么重要：它让模型表达想调用什么——Function Calling 的价值是让模型能结构化地表达"我想调用什么"，而不是真的执行。

怎么验证（证据点）：

工具名候选
参数候选
未执行

别踩的坑（边界）：结构化输出不授予权限——模型输出一个结构化的调用意图，不等于它就有了执行权限，权限是另一回事。

落地检查：Function Calling 位于模型输出层——落地时把 Function Calling 定位在"模型输出层"：它只负责表达意图，执行与否由外层决定。

第 2 步：API 与 Tool

原文：API 提供真实系统能力，Tool 将用途、参数和结果语义暴露给 Agent。

白话：API（Application Programming Interface，应用程序编程接口）是系统真实存在的能力；Tool（工具）是把某个 API 的"用途、参数、返回结果的含义"包装好，暴露给 Agent，让它知道有这个能力、怎么用。

类比：API 像一台真实存在、能开动的机器；Tool 像贴在机器上的"中文说明书 + 操作按钮"，告诉 Agent 这台机器能干嘛、按哪个钮、会吐出什么。

举例：后端有一个真实存在的退款 API（能真的发起退款）；Tool 就是把它包装成"发起退款工具"，写清参数（订单号、金额）和返回语义（成功/失败），Agent 通过这个 Tool 描述才能知道怎么调用它。

为什么重要：Tool 连接模型意图与内部业务能力——Tool 是"模型意图"和"真实 API 能力"之间的桥梁，没有它，模型不知道后端有什么。

怎么验证（证据点）：

API 可调用
Tool 描述清楚
后端规则存在

别踩的坑（边界）：Tool 描述不能替代后端权限——把 Tool 描述写得"有权限、能退款"，不代表后端真的校验了权限，后端规则必须真实存在。

落地检查：实际执行仍由程序控制——落地时记住：Tool 描述只是"说明书"，真正执行、真正校验权限的仍是后端程序，别信描述、要看实现。

第 3 步：MCP

原文：MCP 统一能力发现和调用方式，让客户端理解可用资源与工具。

白话：MCP（Model Context Protocol，模型上下文协议）统一了"发现有哪些能力"和"怎么调用"这两件事，让客户端能理解有哪些可用资源、哪些工具。

类比：像 USB 接口——不管里面是什么设备，插上统一的口，电脑就能发现它、用标准方式跟它通信。

举例：通过 MCP，一个 Agent 客户端能自动发现"这个服务器提供哪几个工具、有哪些资源"，并用统一的协议去调用，而不必为每个服务写一套专门的对接代码。

为什么重要：MCP 解决互操作和发现——MCP 的价值在"连接和发现"层面，让不同的服务和客户端能互相理解、统一调用。

怎么验证（证据点）：

服务来源
工具清单
协议连接

别踩的坑（边界）：连接成功不证明工具业务安全——MCP 连上了、能发现工具了，不代表这些工具的业务操作是安全的。

落地检查：MCP 不是业务治理层——落地时把 MCP 定位成"连接协议"，它不负责业务安全、不负责验收，那两件事要另做。

第 4 步：Skill

原文：Skill 将方法、资料、工具、边界和验收组织成可复用能力。

白话：Skill（技能/方法制品）是把"方法、资料、工具、边界、验收条件"打包组织起来，形成一套可复用的能力。

类比：像一份"完整的外卖出餐 SOP"——它不只写"用哪个锅（工具）"，还写清"做什么菜（方法）、用什么食材（资料）、什么情况不能做（边界）、做出来什么样算合格（验收）"。

举例：一个"合同风险审查" Skill，打包了审查方法、风险条款清单（资料）、合同解析工具、审查边界（哪些合同类型不适用）、验收规则（必须覆盖全部风险点并给依据）。

为什么重要：完成一类任务通常需要多个对象共同工作——单靠一个工具或一段提示，往往做不完一类任务，需要方法 + 资料 + 工具 + 边界 + 验收一起上。

怎么验证（证据点）：

适用条件
工具依赖
验收规则

别踩的坑（边界）：Prompt 模板和单个 Tool 都不等于完整 Skill——一个提示模板、一个工具，都只是 Skill 的零件，不是完整的 Skill。

落地检查：Skill 是受版本和验证管理的方法制品——落地时把 Skill 当成"受版本管理、经过验证的方法制品"来维护，而不是一个随手写的 Prompt 模板。

落地可行性小结

本场景涉及的技术栈：Function Calling、API、Tool 包装、MCP（模型上下文协议）、Skill 制品管理。真实落地做法：把能力链条分层——模型输出层（Function Calling）只表达意图，Tool 把 API 包装成 Agent 可理解的能力，MCP 负责跨服务的发现和调用统一，Skill 负责把方法/资料/工具/边界/验收打包成可复用制品并做版本管理。要检查的：Tool 描述是否和真实后端权限一致、MCP 连接后业务安全是否另做、Skill 是否有版本和验收。常见坑：把 Function Calling 当权限、把 Tool 描述当后端规则、把 MCP 当业务治理层、把 Prompt 模板当 Skill。

回顾

Function Calling 在模型输出层，只表达意图，不授予权限。
API 提供真实能力，Tool 把用途/参数/结果语义暴露给 Agent，是意图与能力的桥梁。
MCP 解决连接和发现（互操作），不是业务治理层。
Skill 把方法、资料、工具、边界、验收组织成可复用能力，是受版本和验证管理的方法制品。
协议解决连接，业务边界和验收仍由系统负责。