AI Agent 的三块基石：Skills、Function Call 与 MCP 到底是什么关系？

openclaw越来越出圈地爆火，很多人对这种爆火感到非常诧异，最近我看到一条评论这样写道：

很多人以为是什么颠覆性的东西，完全不知道skills就是上下文工程，上下文工程就是prompt工程，prompt工程就是注意力机制

有些偏颇，但说出了一些本质性的东西。

一、Function Call

Function Call 就是指让模型来调用函数。但是模型本身是一个输入文字输出文字的系统，那么就有两个问题：

1. 模型怎么知道可以调用这个函数？
2. 模型如何来调用这个函数？

答案非常简单，没有什么高深的：只需要将函数文档输入给模型，然后模型输出它想调用什么工具，“我们”来帮它调用即可。这个“我们”我先叫它runtime，它可以是官方写好的框架，也可以是你自己一行行敲出来的代码。具体过程如下：

1. 事先有一些可用的函数/工具
2. 用户向runtime提出自然语言的问题
3. runtime将自然语言问题与可用函数的定义、名称、参数、描述(一般以JSON schema的形式)等一起发送给大模型
4. 大模型如果判断需要调用函数，会返回函数调用指令
5. runtime解析指令，调用对应函数，获取结果
6. runtime将函数调用结果传回大模型
7. 大模型根据调用结果生成最终自然语言回答
8. runtime将最终回答呈现给用户

二、MCP

MCP是一种 让AI系统连接外部工具和数据源的标准协议。就像HTTP，MCP可以分为MCP Client和MCP Server两块。

MCP Server

远程的MCP Server一般以暴露一个端口的方式向外提供服务，本地的MCP Server一般通过stdio来提供服务。MCP Server可以暴露三类能力：

• Tools：可以被AI调用的函数，例如发送邮件
• Resources：可以被AI读取的资源，例如邮件内容
• Prompts：预设的交互模板

可以理解为，Tools就是让AI能“写”，Resources就是让AI能“读”，Prompts是“行动指南”，告诉AI我这个MCP提供哪些功能，以及应当如何使用这些功能。

MCP Client

跟Function Call是有点像的，工作流程如下：

1. MCP Client从MCP Server获取可用的工具列表
2. 用户向runtime提出自然语言的问题
3. runtime将自然语言问题与工具描述一起发送给大模型
4. 大模型如果判断需要使用工具，会返回工具调用指令
5. runtime会让MCP Client向MCP Server执行相应的工具调用
6. runtime将调用结果传回大模型
7. 大模型根据调用结果生成最终自然语言回答
8. runtime将最终回答呈现给用户

三、Skill

Function Call和MCP都侧重解决如何让AI调用一个工具，而Skill侧重解决如何让AI完成一件事。Skill本质是一个封装了特定任务的功能模块，可以认为是一份功能的“说明书”。

举个例子，一个生成测试用例的Skill：

name: "testcase-generator"
description: "基于需求文档和技术方案生成全面的测试用例"

用户想生成测试用例时，按照以下步骤：
1. 提取文档
从用户输入中获取需求文档和技术方案文档，如果没有，向用户索要，XXXXXX...
2. 解析文档
支持文本格式和pdf格式，pdf格式使用pdf-reader工具解析，如果是其他格式，告知用户使用指定格式。xxxxxx......
3. 提取需求点
xxxxxx......
4. 提取技术方案要点
xxxxxx......
5. 生成测试用例
xxxxxx......

原则:
xxxxxx......

示例:
xxxxxx......

这份skill提供了生成测试用例的流程，并提供了一个叫pdf-reader的工具供ai调用。大模型会根据文档的指引一步一步完成任务。当然，Skill并不一定是工作流，也可以只是一个原子能力。

四、三者关系

在一个agent应用中，runtime都是将所谓Function Call、MCP、Skill按需塞入大模型的上下文中。Skill是工具说明，Function Call是调用方式，MCP是工具服务协议。我让AI画了个图来表示AI执行一个流程的过程：

五、注意力机制

注意力机制是 Transformer 模型的核心，负责 选择性关注输入中的哪些信息。

它在模型内部实现了“加权和”的方式，让模型在生成每个 token 时，可以动态参考上下文的不同部分。

上下文工程和注意力机制的关系：

• 上下文工程优化了输入信息，让模型注意力可以集中在对任务重要的部分。
• 上下文工程是人为设计的策略，注意力机制是模型内部自动计算的机制。

Skill是AI的“工具箱+使用说明书“，注意力机制就是AI看说明书时候的”聚焦眼光“。因此，好的上下文工程能让注意力更精准，让大模型更高效地理解和使用Skill，也就是所谓的“skills就是上下文工程”。

六、为什么用Skill

要知道，有另一种很火的AI使用方式，就是搭建工作流，例如LangChain。很多人都会问一个问题：

既然可以写代码搭建工作流，为什么要让大模型自己去理解一个文本的Skill文档来实现相同的效果？

我认为，两种模式解决的问题不同。

1. 灵活度

纯代码工作流方式很稳定、可预测，但是如果遇到经常要变动的需求，每变一次就要改代码，而且逻辑很容易爆炸，要处理很多细枝末节，不好维护，例如：

如果用户是VIP
如果用户VIP过期
如果视频大于1GB

2.模糊需求

不是所有需求都能写出来相对固定的工作流的，有时候我们要利用AI的理解能力来处理模糊需求，使得流程具有扩展能力。

3.易用性

Skill的提出和应用使得没有技术能力的人也可以对照文档模板自己写一个简易的Skill，甚至可以直接和AI对话，告诉它自己的需求，让AI为你生成一个Skill.md。

事实上，两种模式是可以结合使用的。

七、总结

从系统架构上看，大模型并不会真正调用工具，它只是输出调用意图。 真正的执行发生在runtime层，而Skill、Function Call和MCP，本质上都是在解决“如何让模型更好地表达这种调用意图”。