大模型小白必看：收藏！揭秘AI如何调用外部工具，解锁Agent核心能力

ai绘画-安安妮

443人浏览 · 2026-04-03 10:51:45

ai绘画-安安妮 · 2026-04-03 10:51:45 发布

你有没有想过，当你问 AI "今天北京天气怎么样"的时候，它是怎么知道答案的？毕竟，大模型的训练数据是有截止日期的，它不可能实时感知这个世界。

秘密就藏在一套叫做"工具调用"的机制里。

一、先说一个比喻：大脑与双手

想象一下，大模型（LLM）是一个极其聪明的大脑。这个大脑知识渊博，能写诗、能编码、能分析——但它没有手，没有眼睛，无法直接去触碰这个世界。

它无法查股票、无法开网页、无法写文件，也无法发邮件。它所有的知识，都来自训练时灌入的数据，训练结束后就冻结了。

工具调用，就是给这个大脑装上一双手。

从 Function Call 到 Tool，从 MCP 到 Skill，再到 CLI，这一套体系，其实在回答同一个问题：AI 应该怎么调用外部能力？

这篇文章，我们就来把这套体系从底层逻辑一路讲清楚。

二、Function Call：最底层的"调手"协议

2.1 它是什么

Function Call（函数调用），是 OpenAI 在 2023 年首先标准化的一种大模型交互机制，后来几乎被所有主流模型厂商跟进采用。

它的核心思想很简单：让模型不是直接回答问题，而是告诉你"我需要调用哪个函数、传什么参数"。

你来执行，执行完了把结果告诉模型，模型再给你最终答案。

2.2 交互流程

整个交互分四步：

第一步：你定义工具清单

在发起对话前，你把可用的工具用 JSON Schema 格式描述出来，作为 tools 参数传给模型。

{  "name": "get_weather","description": "获取某城市的实时天气","parameters": {    "type": "object",    "properties": {      "city": {        "type": "string",        "description": "城市名称，如北京、上海"      }    },    "required": ["city"]  }}

第二步：模型决策

用户问"北京今天天气怎样"，模型看了工具列表，判断需要调用 get_weather，于是返回：

{  "tool_calls": [    {      "function": {        "name": "get_weather",        "arguments": "{\"city\": \"北京\"}"      }    }  ]}

注意：模型只是发出了"指令"，它并没有真正去查天气。

第三步：你的程序执行函数

你的代码接收到这个 JSON，去调用真实的天气 API，拿到结果，比如 "今天北京，晴，25°C，微风"。

第四步：模型整合回答

你把这个结果作为 tool 角色的消息塞回对话，模型再次生成，给用户一个完整、自然的回答：

“北京今天天气晴朗，气温 25 摄氏度，有微风，很适合出行。”

2.3 这里面有两层能力

很多人会问：Function Call 到底是模型的能力，还是框架的能力？

答案是：两层缺一不可。

模型层：需要通过专门的指令微调（Instruction Tuning），让模型理解"什么时候该调工具"以及"如何按 Schema 格式输出参数"。GPT-4o、Claude 3.5、Qwen2.5 等都经过了这类训练。
框架层：推理引擎（如 vLLM、OpenAI API、Ollama）需要支持接收 tools 参数，解析模型输出的工具调用指令，并能正确地把工具结果塞回上下文。

所以你如果拿一个没有微调过工具调用的模型、或者用一个不支持 Function Call 的接口，就算你传了 tools 参数，效果也会很差。

三、Tool：Function Call 的"进化版"叫法

3.1 名字的演变

在早期，这套机制叫 Function Call（函数调用）。但随着生态发展，"函数"这个词显得太窄了——调用的不只是函数，还可能是数据库、API、本地文件系统……

于是，业界逐渐统一用 Tool（工具） 这个词，涵盖所有"模型可以请求调用的外部能力"。

Function Call 现在更多是描述这套机制本身，而 Tool 是对单个可调用能力的抽象。

3.2 Tool 的标准结构

一个标准的 Tool 定义，通常包含：

字段	说明
`name`	工具唯一标识，模型靠这个名字调用
`description`	工具功能描述，这是模型决策的主要依据
`parameters`	入参的 JSON Schema，定义类型、必填项、含义

其中 description 尤为关键——写得好不好，直接影响模型能不能在合适的时候选对工具。这是 Prompt 工程里很重要的一部分。

3.3 并行调用与顺序调用

现代大模型支持在一次回复中发出多个工具调用请求（parallel tool calls）。

比如用户说"帮我查一下北京和上海今天的天气"，模型可以同时发出两个 get_weather 调用，节省时间。

当然，也有需要顺序调用的场景——比如先查数据库拿到 ID，再用这个 ID 查详情。这取决于任务的依赖关系。

在这里插入图片描述

四、MCP：给工具连接装上"USB-C 接口"

4.1 旧世界的痛点

在 MCP 出现之前，每个 AI 应用要连接外部工具，都得自己造轮子：

你要让 Claude 访问 GitHub，得自己写一套 GitHub 的工具定义
你要让 GPT-4 读本地文件，得自己写文件系统的工具
你要换一个模型，所有工具定义可能得重写

工具是烟囱式的，不可复用，维护成本极高。

每个 AI 客户端和每个数据源之间，都要单独建立连接。

4.2 MCP 的设计哲学

2024 年 11 月 25 日，Anthropic 发布了 MCP（Model Context Protocol，模型上下文协议），并将其开源。

MCP 的目标，是定义一套标准化协议，让 任何 AI 客户端 都能用统一方式连接 任何数据源或工具服务器。

类比很流行：MCP 就是 AI 领域的 USB-C 接口。

在 USB-C 出现之前，不同设备有不同接口（Micro-USB、Lightning……），每次充电得找对应的线。USB-C 统一了标准，一条线走天下。

MCP 做的是同样的事情——让 AI 和工具之间的连接标准化、可复用。

4.3 MCP 的架构

MCP 定义了三个角色：

┌─────────────────────┐│    MCP Host         │  ← 你的 AI 客户端（Claude Desktop / Cursor / IDE）│  (AI Application)   │└────────┬────────────┘         │  MCP Protocol（JSON-RPC 2.0）         │┌────────┴────────────┐│    MCP Client       │  ← 内嵌在 Host 中的协议处理层└────────┬────────────┘         │┌────────┴────────────┐│    MCP Server       │  ← 工具/数据源的封装层（可以有很多个）│  (GitHub / DB / FS) │└─────────────────────┘

MCP Server 负责把某类能力（比如读写文件、查数据库、调 GitHub API）封装成标准接口。

MCP Client（Host） 按协议去连接 Server，发现它有哪些工具，然后在需要时发起调用。

4.4 MCP Server 暴露的三类能力

MCP 定义了三类原语（primitives）：

**① Tools（工具）**可执行的操作，比如"搜索文件"、“提交 PR”、“发送邮件”。这对应 AI 的主动行为。

**② Resources（资源）**可读取的数据，比如"返回项目里所有 Markdown 文件的内容"。这对应 AI 的读取行为。

**③ Prompts（提示词模板）**预定义的提示词片段，帮助用户快速完成特定任务。

4.5 传输方式

MCP 支持两种传输方式：

stdio：本地 MCP Server 通过标准输入输出与 Client 通信，适合本地工具
HTTP/SSE：远程 MCP Server 通过网络通信，适合云端工具和共享服务

4.6 MCP 的意义

MCP 把"工具生态"从私有变成了公共基础设施。

有了 MCP：

开发者写一个 GitHub MCP Server，所有支持 MCP 的 AI 客户端都能用
企业可以把内部知识库包装成 MCP Server，任何 AI 工具都能安全接入
AI 应用开发者不用重复造轮子，专注业务逻辑

截至 2025 年，MCP 生态已经爆发式增长，GitHub、Slack、Notion、数据库、代码仓库……几乎所有主流工具都有了对应的 MCP Server。

五、Skill：把工具包装成"可复用的专业能力"

5.1 工具 vs. 能力

Tool 解决了"AI 能调什么"的问题，但还有一个问题没解决：AI 应该怎么用这些工具？

比如，AI 有了"搜索网页"这个 Tool，但如何搜、搜哪些关键词、如何整合多次搜索结果、输出什么格式——这些逻辑，每次都要重新在 Prompt 里写吗？

这就是 Skill（技能） 要解决的问题。

Skill 是在 Tool 之上的一层抽象：把完成某类任务所需的工具组合、使用流程、输出规范，打包成一个可复用的单元。

5.2 Skill 的结构

一个典型的 Skill，包含：

触发条件：什么样的用户请求会激活这个 Skill
使用哪些 Tools：需要哪些工具支撑
执行流程：分几步、每步做什么
输出规范：结果用什么格式呈现

比如，"公众号文章写作"这个 Skill：

触发：用户说"帮我写一篇公众号文章"流程：  Step 1 → 调用搜索 Tool，并行搜 3-5 个关键词  Step 2 → 整合资料，写 5000 字初稿  Step 3 → 生成 5 个备选标题  Step 4 → 提供排版建议输出：Markdown 格式文章 + 标题列表

5.3 Skill 的实现形式

不同平台对 Skill 的实现略有不同，但核心思路一致：

文件形式：一个 SKILL.md 文件，写明触发条件、工具需求和执行步骤，AI 读到文件就知道怎么做
配置形式：YAML/JSON 配置，描述工具链和参数
代码形式：直接用代码定义 Skill 类或函数，注入到 Agent 框架

在 OpenClaw 等现代 AI 助手平台里，Skill 可以像插件一样安装、更新、卸载，极大提升了 AI 能力的可扩展性。

5.4 Skill 与 Tool 的层次关系

层次	概念	类比
原子能力	Tool	锤子、螺丝刀
工作流	Skill	装修施工方案
执行者	Agent	装修工人

工具是孤立的，Skill 把工具串成了有目的的工作流。

六、CLI：让 AI 直接操作系统级能力

6.1 CLI 是什么

CLI（Command Line Interface，命令行界面），是软件通过文字命令与操作系统交互的方式。

在 AI 工具调用体系里，CLI 扮演着非常特殊的角色：它是 AI 访问系统级能力的最直接通道。

当 AI 有了执行 Shell 命令的能力，它能做的事情就是：

操作文件系统（读写删除文件、目录）
运行脚本、执行程序
调用任何有命令行接口的工具（git、ffmpeg、curl……）
管理进程、安装依赖

几乎整个操作系统，都在它触手可及的范围之内。

6.2 AI + CLI = 真正的本地 Agent

这就是为什么 Claude Code、Cursor、OpenClaw 这类 AI 编码助手，都会提供执行 Shell 命令的能力（exec tool）——有了 exec，AI 就不只是一个对话机器人了，它可以真正在本地完成工作。

一个典型的 AI + CLI 工作流：

用户说："帮我把这个目录里所有 PNG 图片转成 WebP 格式"AI：  1. exec: ls ./images | grep '.png'  → 拿到文件列表  2. exec: for img in *.png; do cwebp "$img" -o "${img%.png}.webp"; done  3. 告诉用户：转换完成，共处理 23 张图片

全程无需用户手动操作，AI 自己把任务做完了。

6.3 CLI 与 Tool 的配合

CLI 通常不是孤立存在的，而是作为一类特殊的 Tool 被纳入体系：

AI 平台定义一个 exec Tool（或 bash Tool）
这个 Tool 接受命令字符串作为参数
AI 在需要时调用这个 Tool，传入具体命令
执行结果作为 Tool 返回值回到上下文

这样，CLI 就和其他 API 类工具一样，都变成了 AI 可以调用的"手"。

6.4 CLI 的安全边界

CLI 是双刃剑。给了 AI 执行命令的能力，也给了它潜在的破坏力。

负责任的 AI 平台，都会有一套安全策略：

沙箱隔离：命令在隔离的容器环境中执行，不影响主机
权限控制：限制可执行的命令类型（比如禁止 rm -rf /）
用户确认：高风险操作要求用户明确授权
日志审计：所有执行操作留有记录

安全是 CLI 能力落地的前提。

七、五个概念，一张关系图

讲了这么多，我们来整理一下这五个概念的层次关系：

┌─────────────────────────────────────────────────────────────────┐│                          用户请求                                │└──────────────────────────────┬──────────────────────────────────┘                               │                               ▼┌─────────────────────────────────────────────────────────────────┐│                    LLM（大模型）                                 ││             理解意图 → 决策 → 生成工具调用指令                   │└──────────────────────────────┬──────────────────────────────────┘                               │ Function Call / Tool Use                               ▼┌─────────────────────────────────────────────────────────────────┐│                       Skill 层                                  ││         把多个 Tool 组合成有步骤、有规范的工作流               │└──────┬───────────────────────┬──────────────────────────────────┘       │                       │       ▼                       ▼┌─────────────┐    ┌────────────────────────────────────────────┐│   MCP       │    │              Tool 层                       ││  (标准协议) │    │  搜索 / API / 数据库 / CLI(exec) / 文件 / ... │└──────┬──────┘    └────────────────────────────────────────────┘       │       ▼┌────────────────────────────────┐│    MCP Server（外部服务）      ││  GitHub / Notion / DB / ...   │└────────────────────────────────┘

简单总结：

Function Call：定义了 LLM 如何声明"我要调工具"的底层机制
Tool：单个可调用能力的抽象，是 Function Call 的载体
MCP：工具连接的标准协议，让工具生态可复用、可互通
Skill：把 Tool 组合成完整工作流的上层抽象，可复用、可分发
CLI：通过命令行访问系统级能力，是最底层也是最强大的 Tool 类型之一

八、真实世界的应用：一次完整的 AI 任务

为了让这套体系更直观，我们用一个完整的例子走一遍。

场景： 你告诉 AI 助手：“帮我整理一下最近一周 GitHub 上我们项目新增的 Issue，生成一份摘要报告，发到工作群里。”

幕后发生了什么：

1. LLM 分析意图，触发 Skill

AI 识别到"整理 GitHub Issue + 生成报告 + 发消息"这个复合任务，加载对应的 Skill 模板。

2. Skill 开始执行：调用 GitHub Tool

通过 MCP 协议，连接到 GitHub MCP Server，调用 list_issues Tool：

{  "tool": "list_issues",  "arguments": {    "repo": "your-org/your-project",    "since": "2025-03-24T00:00:00Z",    "state": "open"  }}

GitHub MCP Server 返回了 15 条 Issue 的数据。

3. LLM 处理数据，生成摘要

AI 读取 Issue 数据，按优先级分类，生成结构化摘要。

4. 调用 CLI Tool，保存报告

echo "# Issue 周报 2025-03-31\n..." > /reports/issue-summary.md

5. 调用消息发送 Tool，投递到工作群

{  "tool": "send_message",  "arguments": {    "channel": "work-group",    "content": "本周 Issue 周报已生成，共 15 条，其中 P0 问题 3 条..."  }}

整个过程，用户什么都不用做。

这就是 Function Call + Tool + MCP + Skill + CLI 协同工作的结果。

九、未来走向：Agent 时代，工具调用的核心地位

当我们把 Function Call、Tool、MCP、Skill、CLI 这些能力组合起来，就构成了 AI Agent 的基础能力栈。

Agent 是"有目标、会规划、能行动"的 AI——它不是一问一答的聊天机器人，而是一个能自主完成复杂任务的数字员工。

这套工具调用体系，就是 Agent 的"手脚神经系统"。

2025 年，AI 领域最重要的竞争，不再是哪个模型更聪明，而是谁能接入更多工具、让 Agent 在更多场景自主完成任务。

MCP 生态的爆发，正是这个趋势的缩影。

当一个 AI 能查邮件、能读代码、能发消息、能操控浏览器、能执行命令——它就不只是"助手"了，它更像一个真正的团队成员。

十、总结

概念	核心价值	一句话理解
Function Call	底层机制	LLM 声明"我要用什么函数"
Tool	单一能力	一件工具，一个本事
MCP	连接标准	AI 领域的 USB-C 接口
Skill	工作流复用	把工具串成专业流程
CLI	系统级操作	给 AI 一个真实的 Shell