先从一个任务理解问题
假设你要开发一个订单助手。用户输入：“查一下我的订单，解释为什么还没发货。”
可以把需求拆成三件事：选择查询操作并填写参数，连接订单系统，再按业务规则解释结果。Function Calling、MCP 和 Skills 分别可以承担其中一部分。
它们处于不同层次：Function Calling 侧重模型如何提出调用请求，MCP 侧重应用如何对接外部能力，Skills 侧重组织完成任务所需的知识和步骤。实际开发中，可以将三者组合使用。(developers.openai.com)
Function Calling：把意图变成调用请求
Function Calling 通常译为“函数调用”。开发者向模型提供函数名称、用途和参数结构，模型根据用户需求，生成包含函数名与参数的结构化请求。对于应用自定义函数，实际执行由应用代码负责。(developers.openai.com)
例如，你提供一个 get_order(order_id) 工具，并说明订单号必须是字符串。用户询问订单 A123 时，模型可能生成：
{
"name": "get_order",
"arguments": {"order_id": "A123"}
}
接着，应用检查参数与访问权限，执行查询，把结果回传给模型。模型再根据结果回答用户，或者继续提出其他调用。这构成了“模型请求—程序执行—结果回传”的循环。(developers.openai.com)
它解决的是自然语言与程序接口之间的衔接。只开发一个应用、接入少量自有接口时，建议先用这种方式跑通完整流程。
MCP：让外部能力采用统一接口
MCP 的全称是 Model Context Protocol，即模型上下文协议。它规定了 AI 应用与外部服务交换上下文和调用能力的方式。除了工具，服务端还可以提供资源与提示词模板，因此 MCP 的范围比函数调用接口更广。(modelcontextprotocol.io)
典型结构包含三个角色：宿主是 AI 应用，客户端是宿主中的连接组件，服务端负责提供具体能力。客户端可以通过 tools/list 发现工具，通过 tools/call 请求执行。服务端既可以在本地运行，也可以部署在远程。(modelcontextprotocol.io)
在订单助手中，你可以将订单查询封装成 MCP 服务。宿主读取工具定义，将其转换为模型可使用的工具描述；模型提出调用后，宿主再把请求交给 MCP 客户端转发。这样，Function Calling 与 MCP 就连接在同一条执行链上。(modelcontextprotocol.io)
当多个 AI 应用需要复用订单能力，或者你要接入已有 MCP 服务时，值得考虑这层标准化接口。
Skills：把做事方法打包保存
本文的 Skills 指采用 Agent Skills 格式的技能包。一个技能通常是包含 SKILL.md 的目录，其中记录名称、适用场景和操作指引，还可以附带脚本、参考资料与模板。它适合保存团队希望重复执行的工作方法。(agentskills.io)
例如，“订单异常解释”技能可以规定：
- 缺少订单号时，先向用户补充询问。
- 查询状态后，检查是否存在异常原因。
- 将已确认事实与推测分开表达。
- 没有预计发货时间时，不自行承诺日期。
支持该格式的 Agent 通常先读取技能名称与描述，匹配任务后再加载完整指引，其他文件按需读取。这种渐进加载方式可以减少一次性放入上下文的内容。(agentskills.io)
技能也可以包含可执行脚本，但能否运行取决于宿主提供的环境。仅把文件放进项目目录，并不意味着应用已经具备技能发现、加载和执行能力。(agentskills.io)
用订单助手决定先做哪一层
建议把第一版控制在一个明确目标：查询订单并解释结果。
先定义订单查询函数，写清参数、返回字段和错误情况，完成调用与回传。再用几个案例测试：正常订单、订单不存在、接口超时、用户无权访问。
如果回答经常漏掉检查步骤，就把解释流程整理成 Skill；如果多个应用开始重复接入订单系统，再把查询能力封装为 MCP 服务。
可以按当前问题选择下一步：
| 当前需求 | 建议优先考虑 |
|---|---|
| 让模型调用几个已有函数 | Function Calling |
| 让多个兼容应用复用外部能力 | MCP |
| 固化处理步骤、规则和输出要求 | Skills |
| 同时需要接口复用和业务流程 | 组合使用 |
对这个示例，我会设计成：Skill 提供处理指引，模型提出订单查询请求，宿主通过 MCP 调用查询服务，最后依据结果生成解释。每层都承担明确职责，便于单独排查问题。
常见坑：接通之后还要验证
参数符合格式，不代表业务判断正确。 即使使用严格的参数结构约束，也只能约束结构；订单号是否真实、是否属于当前用户，仍应由业务代码验证。(help.openai.com)
不要把 Skill 指引当作强制流程。 Skill 的主体是进入模型上下文的指令。我的建议是，将权限校验、金额限制等必须执行的规则写进程序，将说明与操作方法放进技能。(agentskills.io)
不要只测试成功路径。 为调用循环设置次数上限和超时；将“查询失败”与“订单不存在”分开返回；对于会产生写入的操作，设计重复调用保护。
避免工具与技能描述过于含糊。 工具应写清输入含义，技能应写清适用任务。例如，“处理订单”不如“查询订单状态并解释未发货原因”容易判断何时使用。(developers.openai.com)
小结
入门时，建议先完成一个可验证的函数调用流程，再根据实际问题补充技能和标准化连接。选型时关注三个问题：现在缺的是调用能力、系统接入，还是可复用的做事方法？从最直接的问题开始，就能逐步形成清楚、可维护的 Agent 应用。
参考来源
- 选题参考：小林面试笔记 · 同主题文章（本文为本站原创撰写，未转载原文）