夜雨聆风
如果把时间拨回到大模型刚开始“会用工具”的那几年，很多人对工具调用的想象其实很简单。
用户问一句话。
模型判断要不要查数据库、调接口、发请求。
然后把结果组织成自然语言返回。
这已经能让你觉得很厉害了。
因为在那之前，大模型更像一个关在房间里的聪明人。它知道很多东西，但碰不到外部世界。Function Calling 出现后，门终于开了一条缝。
但今天回头看，那只是第一步。
真正重要的变化，不是模型终于能“调一个函数”。
而是 AI 系统和外部世界之间的连接方式，正在从一次性的接口调用，进化成一套越来越完整的工作系统。
这条线索大概经历了三次变化：
Function Calling：让模型能调用工具 MCP：让工具和上下文能被标准化连接 Skills：让一整套经验、流程和资源能被打包复用
表面上看，它们都和“工具调用”有关。
但如果只把它们理解成三种调用接口，就会错过真正关键的东西。
它们背后其实是在回答同一个问题：
怎样让模型不只是会说，而是真的能在一个复杂世界里持续做事？
这篇文章，我想把这件事讲透。
不是把 Function Calling、MCP、Skills 当成三个名词并排解释。
而是认真看一眼：AI 工具调用到底是怎么一步步从“调用一个函数”，走向“组织一套工作能力”的。
一、第一阶段：Function Calling 解决的是“能不能伸手”
最早的 Function Calling，解决的是一个非常基础、但非常关键的问题：
模型怎么把意图变成一个可执行动作？
在没有 Function Calling 之前，你当然也可以让模型输出一段 JSON，让程序再去解析。
比如用户说：
“帮我查一下北京明天的天气。”
模型输出：
{"city":"北京","date":"明天"}然后你的代码拿这个 JSON 去调天气接口。
但这种方式很脆。
字段名可能写错。
格式可能不稳定。
有时候多一句解释，有时候少一个括号。
对人来说，这些小毛病不算什么；对程序来说，它就是一次失败调用。
Function Calling 的核心价值，就是把这个过程变得更像一个工程接口。
开发者先告诉模型：
这里有一个函数。
它叫什么。
它需要哪些参数。
参数是什么类型。
哪些字段必填。
模型要做的，不是自由发挥一段文本，而是在理解用户意图后，按这个结构生成一次工具调用。
这一步非常重要。
因为它第一次把大模型从“文本生成器”，往“动作规划器”推了一步。
用户说的是自然语言。
模型输出的是结构化调用。
外部系统执行的是确定性动作。
这三者被接了起来。
一句话概括：
Function Calling 让模型第一次有了稳定伸手触碰外部系统的方式。
二、但 Function Calling 很快遇到天花板
Function Calling 很有用，但它的边界也很明显。
它解决的是“单个工具怎么被调用”。
但真实世界的问题，往往不是单个工具的问题。
比如你想让一个 AI 助手帮你处理一次客户投诉。
它可能需要：
查 CRM 里的客户资料 查订单系统里的购买记录 看工单系统里的历史沟通 读取内部知识库里的赔付规则 判断这次应该给什么补偿 最后写一封回复邮件
如果只靠 Function Calling，这些工具当然都能一个个接进去。
但问题来了。
每一个系统都要单独写函数定义。
每一个工具都要单独处理鉴权、参数、返回格式、错误信息。
每一个应用都要重新告诉模型：这些工具是什么、怎么用、什么时候用。
久而久之，系统会变成一堆散落的适配代码。
能跑。
但很难扩展。
更麻烦的是，上下文也没有一个统一入口。
模型到底能看到哪些文件？
能不能查某个数据库？
能不能访问某个代码仓库？
能不能读取某个项目管理系统？
这些能力都要在每个产品里重新做一遍。
所以 Function Calling 的问题，不是它不够好。
而是它太靠近“函数”这一层了。
它像是给模型装上了一只手。
但没有给这只手配一套稳定的工具箱、工作台和说明书。
三、第二阶段：MCP 解决的是“工具和上下文怎么被接入”
MCP 出现后，事情开始往上走了一层。
它关心的重点不再只是：
“模型要调用哪个函数？”
而是：
一个 AI 应用，应该怎样用标准方式连接外部工具、数据和上下文？
这就是 Model Context Protocol 的意义。
你可以把它理解成一种面向 AI 应用的连接协议。
在这个协议里，工具、资源、提示、上下文，不再只是某个应用内部临时写死的东西。
它们可以通过一个标准方式暴露出来。
AI 客户端也可以用一种比较统一的方式去发现、读取和调用它们。
这一步的价值，不在于“又多了一种调接口的方法”。
真正的价值在于：
工具连接开始从私有集成，变成标准化基础设施。
这和早期互联网 API 的演进有点像。
一开始，每家公司都有自己的接口。
能用，但接入成本很高。
后来大家逐渐形成通用协议、认证方式、数据格式和开发习惯，生态才真正长起来。
MCP 做的事情，类似是在 AI 应用这一侧补一层“通用插座”。
比如一个代码助手，不应该每接一个数据库、一个 Git 仓库、一个文档系统，都重新发明一套连接方式。
它更理想的形态是：
工具服务把能力暴露成 MCP server。
AI 客户端按协议发现这些能力。
模型在需要的时候获取上下文、调用工具、组合结果。
这样一来，一个工具不是只能服务某个单独产品。
它可以被多个 AI 客户端复用。
一个 AI 客户端也不必把所有外部世界都硬编码进自己体内。
它可以接入一组可发现、可组合、可替换的外部能力。
这就是第二次进化。
从“模型调用函数”，进化到“AI 应用连接能力网络”。
四、MCP 解决了连接，但没有完全解决“怎么把事做好”
不过，MCP 也不是终点。
它解决了连接问题。
但连接不是完成工作本身。
一个模型能访问代码仓库，不代表它就知道这个仓库的工程习惯。
一个模型能调用设计工具，不代表它就知道这个团队的审美标准。
一个模型能读取企业文档，不代表它就知道哪些规则过时了、哪些经验最可靠。
这就像你给一个新同事开通了所有系统权限。
他能登录 Jira。
能看 Confluence。
能访问 GitHub。
也能进 Slack。
但这不等于他明天就能稳定交付。
真正决定他能不能干活的，是另一层东西：
这个团队怎么拆任务 遇到问题先查哪里
哪些坑不要踩 哪些输出格式必须遵守
哪些脚本、模板、素材可以复用
这些东西很少只存在于一个 API 里。
它们更像经验、流程、偏好和约束的集合。
Function Calling 管的是一次调用。
MCP 管的是连接方式。
但复杂工作还需要第三件事：
把一类任务的做法沉淀成可复用能力。
这就是 Skills 开始变得重要的地方。
五、第三阶段：Skills 解决的是“经验怎么被打包”
Skills 这个概念，最容易被低估。
很多人第一次看到它，会把它理解成“更长一点的提示词”。
这其实太浅了。
真正有价值的 Skill，不只是告诉模型几句规则。
它应该是一套可以被调用的工作能力。
里面可能包括：
任务触发条件 执行步骤 专用脚本 模板文件 示例输出 风格规范 检查清单 对某个领域的特殊判断
也就是说，Skill 不只是“你应该怎么想”。
它还告诉模型：
你应该去哪里拿资料，用哪些工具，按什么顺序做，做到什么程度才算完成。
这一点和普通提示词差别很大。
提示词更像临时指令。
Skill 更像一个可携带的小型工作包。
比如写一篇公众号文章。
如果只是提示词，你会对模型说：
“请模仿这篇文章风格，写一篇新文章。”
但如果是 Skill，它可以进一步规定：
先解析标题和模板路径。
再读取模板。
分析模板结构、节奏、开头、转折和结尾。
然后把文章保存到指定目录。
最后检查标题、路径、格式和可发布性。
这就不只是写作提示了。
它把“如何完成这类工作”的过程也封装了起来。
一句话概括：
Skills 把模型的能力，从一次对话里的临场发挥，推进到了可复用的工作流。
六、三次进化，其实是在不断上移抽象层级
如果把 Function Calling、MCP、Skills 放在一条线上看，会很清楚。
第一层是动作。
模型能不能按结构调用一个函数。
第二层是连接。
AI 应用能不能用标准方式接入外部工具和上下文。
第三层是能力。
一类任务的经验、流程和资源，能不能被打包、迁移、复用。
所以它们不是简单的替代关系。
不是说有了 MCP，Function Calling 就没用了。
也不是说有了 Skills，MCP 就不重要了。
它们更像三层不同的工程抽象。
Function Calling 偏底层动作。
MCP 偏系统连接。
Skills 偏任务组织。
一个成熟的 AI 工作系统，往往会同时需要三者。
模型通过 Function Calling 或类似机制产生结构化动作。
AI 客户端通过 MCP 接入外部世界。
团队再用 Skills 把高频任务沉淀成可重复执行的流程。
这时候，AI 才不只是一个聊天框。
它开始像一个能进入真实工作现场的执行系统。
七、真正的变化，是“调用工具”变成了“经营环境”
很多团队现在做 AI 应用，第一反应还是：
“我要给模型接哪些工具？”
这个问题当然重要。
但它已经不够了。
更关键的问题应该变成：
我要为模型经营一个怎样的工作环境？
工具只是环境的一部分。
更完整的环境还包括：
可发现的上下文 稳定的权限边界 清晰的任务流程 能被机器读取的文档 可以复用的模板和脚本 自动化的质量检查 失败之后能继续修正的反馈回路
这也是为什么很多 AI 项目早期看起来很惊艳，后面却很难落地。
不是因为模型突然不聪明了。
而是因为它们只接了工具，没有经营环境。
一个演示里，模型调一次 API 成功，很容易。
但在真实业务里，模型要持续处理各种边界情况、异常状态、权限变化、历史包袱和组织习惯。
这时候，单纯的“工具调用”就不够了。
你要把外部世界整理成模型能理解、能访问、能验证、能纠错的形态。
Function Calling、MCP、Skills 的演进，本质上都在往这个方向走。
八、对开发者来说，最大的误区是只盯着模型能力
过去一年，很多讨论都在问：
哪个模型更强？
哪个 benchmark 更高？
哪个 Agent 框架更火？
这些问题不是没意义。
但如果你真的要把 AI 放进生产流程，它们往往不是第一瓶颈。
更现实的瓶颈是：
你的工具有没有稳定 schema？
你的上下文是不是散在聊天记录、飞书文档和人的脑子里？
你的内部流程有没有写成机器可执行的步骤？
你的错误信息能不能指导模型修复？
你的权限边界是不是清楚？
你的高频任务有没有沉淀成 Skill？
这些问题听起来没有模型发布会那么刺激。
但它们决定系统能不能稳定工作。
一个没有环境的强模型，常常只能偶尔表现惊艳。
一个被好环境托住的模型，才可能持续产出。
这就是 AI 工程接下来很重要的一条分水岭。
以后很多团队之间的差距，可能不是谁先接了某个模型。
而是谁先把自己的工具、上下文、流程、检查和经验，整理成了一套可被智能体使用的工作系统。
九、普通团队应该怎么理解这三件事
如果你现在正准备做一个 AI 助手，或者想把大模型接进研发、运营、销售、客服、内容生产流程，我会建议你不要一上来就追求“大而全的 Agent”。
可以按这三层来想。
第一，先把关键动作标准化。
哪些动作必须由系统执行？
查订单、建工单、写数据库、发邮件、跑脚本、创建 PR。
这些动作要有清楚的输入、输出、权限和错误处理。
这是 Function Calling 那一层要解决的事。
第二，再把外部上下文接成稳定网络。
模型不能靠人复制粘贴上下文过日子。
知识库、代码仓库、数据库、项目系统、监控日志，如果是高频依赖，就应该被标准方式接入。
这是 MCP 那一层要解决的事。
第三，把高频任务沉淀成可复用 Skill。
不要每次都重新写一大段提示词。
也不要把经验散落在人的口头提醒里。
把流程、模板、检查点、脚本和输出规范打包起来，让模型下次可以沿着同一条路稳定执行。
这是 Skills 那一层要解决的事。
这三层搭起来之后，你会发现，AI 系统的可靠性不是靠一句“请认真一点”换来的。
它是被结构托起来的。
十、总结
Function Calling、MCP、Skills，看起来是三个技术名词。
但它们真正代表的，是 AI 工具调用从低到高的三次变化：
从会调用一个函数。
到能连接一片外部世界。
再到能复用一套完整工作方法。
这也是为什么今天再谈 AI 工具调用，不能只问“模型能调什么接口”。
更应该问：
你有没有把工具、上下文、流程和经验，整理成一个模型真的能工作的环境？
未来真正好用的 AI 系统，大概率不是一个单独的聪明模型。
而是模型、工具、上下文、协议、技能和反馈回路共同组成的系统。
模型负责理解和生成。
工具负责执行。
协议负责连接。
Skills 负责沉淀经验。
反馈负责把错误拉回正轨。
当这几件事被组织到一起，AI 才开始从“会聊天的软件”，变成“能持续做事的系统”。
如果你对 AI 知识、AI 落地工作方法感兴趣，欢迎关注。后续我会持续分享行业趋势、实战经验与可直接落地的方法，内容力求务实、易懂、可复用。
每天更新一点，帮你把复杂的 AI 世界看明白、跟上节奏、不掉队。
