Function Calling、Tools、Tool Calling、MCP Tool、Skill 总结

适合 Agent 项目中常见的工具调用、MCP、Skill 概念。
核心记忆：Tool 是能力，Function Calling / Tool Calling 是调用方式，MCP Tool 是标准化远程/本地工具，Skill 是给 AI Coding 用的工程规则和任务范式。

---

1. 总体关系

可以先用一句话串起来：

Function Calling / Tool Calling：
模型调用外部能力的机制

Tools：
Agent 可以调用的能力集合

MCP Tool：
通过 MCP 协议暴露出来的标准化 Tool

Skill：
AI Coding / Agent 开发时遵循的工程规则、流程、经验模板

更形象地理解：

Agent = 执行者

Tool = 具体工具
Function Calling = 调用工具的动作
Tool Calling = Agent 场景下的工具调用说法
MCP Tool = 标准化暴露出来的工具
Skill = 作战手册 / 工程规范 / 任务流程
LangGraph = 多步骤、多 Agent 的流程编排框架

---

2. Function Calling

2.1 是什么

Function Calling 是模型调用外部函数的机制。

模型本身不会真的执行函数，它只是根据用户问题生成一段结构化调用信息，例如：

{
  "name": "get_weather",
  "arguments": {
    "city": "Tokyo"
  }
}

然后由你的后端程序真正执行：

def get_weather(city: str):
    ...

执行完以后，函数结果再返回给模型，由模型整理成人话回复用户。

---

2.2 流程

用户问题
  ↓
LLM 判断需要外部能力
  ↓
LLM 生成 function call
  ↓
后端程序执行真实函数
  ↓
函数结果返回给 LLM
  ↓
LLM 生成最终回答

例如用户问：

今天东京天气怎么样？

模型可能生成：

{
  "name": "get_weather",
  "arguments": {
    "city": "Tokyo"
  }
}

后端调用天气 API 后，再把结果交给模型总结。

---

2.3 重点

Function Calling 偏底层机制，强调：

模型如何输出结构化参数
程序如何根据参数调用函数
调用结果如何返回给模型

一句话：

Function Calling 是模型调用外部函数/API 的底层机制。

---

3. Tools

3.1 是什么

Tools 是 Agent 可调用的外部能力集合。

Tool 可以是：

普通 Python 函数
HTTP API
数据库查询
网页搜索
文件读写
代码执行
MCP 暴露出来的工具
RAG 检索工具

比如 LangChain / LangGraph 里：

tools = [search_tool, weather_tool, database_tool]

agent = create_agent(
    model=model,
    tools=tools
)

这里的 tools 就是模型可以调用的能力列表。

---

3.2 Tool 通常包含什么

一个 Tool 一般包含：

name：工具名称
description：什么时候使用这个工具
parameters / input_schema：参数结构
executor：真正执行逻辑

例如：

{
  "name": "query_order",
  "description": "根据订单号查询订单状态、支付状态、订单明细。",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "订单号"
      }
    },
    "required": ["order_id"]
  }
}

---

3.3 Tool 描述很重要

Tool 能不能被模型正确调用，很大程度取决于：

工具名称是否清晰
description 是否写清楚使用场景
参数 schema 是否明确
是否区分只读工具和写入工具

不好的写法：

{
  "name": "query",
  "description": "查询数据"
}

好的写法：

{
  "name": "query_order",
  "description": "当用户询问订单状态、支付状态、退款状态、订单明细时使用。需要传入 order_id。"
}

---

3.4 重点

Tools 偏 Agent 能力抽象。

一句话：

Tool 是 Agent 可以调用的外部能力，Function Calling 是调用 Tool 的一种机制。

---

4. Tool Calling

4.1 是什么

Tool Calling 是 Agent 场景下对工具调用过程的说法。

它和 Function Calling 很接近，很多时候可以简单理解成同一类事情。

区别在于：

Function Calling：
更偏模型 API 层的结构化函数调用机制

Tool Calling：
更偏 Agent 框架中的工具调用行为

比如：

OpenAI API 里可能叫 function calling / tool calling
LangChain / LangGraph 里通常叫 tools
Agent 执行过程中叫 tool call

---

4.2 流程

用户问题
  ↓
Agent 选择 Tool
  ↓
生成 Tool Call 参数
  ↓
执行 Tool
  ↓
返回 Tool Result
  ↓
LLM 基于结果继续推理或输出

例如：

用户：帮我查订单 12345 为什么没支付成功

Agent 看到有工具：

query_order：查询订单详情
query_payment：查询支付状态

于是可能调用：

{
  "tool": "query_order",
  "arguments": {
    "order_id": "12345"
  }
}

---

4.3 重点

Tool Calling 强调 Agent 执行过程中的“调工具”行为。

一句话：

Tool Calling 是 Agent 在运行过程中选择并调用工具的动作。

---

5. MCP Tool

5.1 MCP 是什么

MCP，全称 Model Context Protocol，可以理解为：

让 Agent 标准化连接外部工具、数据源、系统能力的协议

它不是具体某个工具，而是一套标准。

MCP 主要解决的问题是：

不同 Agent / IDE / 客户端如何统一接入工具
不同系统如何标准化暴露工具
工具如何被发现、描述、调用

---

5.2 MCP Tool 是什么

MCP Tool 是通过 MCP Server 暴露出来的工具。

例如：

filesystem_mcp
  - read_file
  - write_file
  - list_directory

github_mcp
  - search_repo
  - create_issue
  - read_pull_request

pos_mcp
  - query_order
  - query_member
  - query_payment

这些工具不是直接写在 Agent 项目代码里的，而是由 MCP Server 对外提供。

---

5.3 MCP Tool 的发现流程

Agent 一般不是自己乱猜有哪些 MCP Tool，而是通过 MCP Client 连接已配置的 MCP Server。

流程：

Agent 启动
  ↓
读取 MCP Server 配置
  ↓
连接 MCP Server
  ↓
调用 tools/list
  ↓
拿到工具名称、描述、参数 schema
  ↓
注册成 Agent 可用 tools

例如 MCP Server 返回：

{
  "tools": [
    {
      "name": "query_order",
      "description": "根据订单号查询订单详情",
      "inputSchema": {
        "type": "object",
        "properties": {
          "order_id": {
            "type": "string"
          }
        },
        "required": ["order_id"]
      }
    }
  ]
}

---

5.4 MCP 的通信方式

MCP 消息格式通常是：

JSON-RPC 2.0

常见传输方式：

本地 MCP：stdio
远程 MCP：Streamable HTTP
旧兼容方案：SSE

简单记：

本地工具：stdio
远程服务：Streamable HTTP
底层消息：JSON-RPC

---

5.5 JSON 和 JSON-RPC 的区别

JSON 是数据格式
JSON-RPC 是基于 JSON 的远程调用协议

普通 JSON：

{
  "city": "Tokyo"
}

JSON-RPC 请求：

{
  "jsonrpc": "2.0",
  "method": "tools/list",
  "params": {},
  "id": 1
}

JSON-RPC 响应：

{
  "jsonrpc": "2.0",
  "result": {
    "tools": []
  },
  "id": 1
}

一句话：

JSON 是信封里的纸，JSON-RPC 是规定这封信怎么写“我要调用哪个方法、参数是什么、返回结果是什么”的通信规则。

---

5.6 MCP Tool 和普通 Tools 的关系

不用 MCP：

Agent
  ↓
本地 tools
  ↓
Python 函数 / API / 数据库

用 MCP：

Agent
  ↓
MCP Client
  ↓
MCP Server
  ↓
MCP Tools
  ↓
数据库 / 文件系统 / 外部系统

MCP 不是替代 Tools，而是把 Tools 标准化、服务化、共享化。

---

5.7 为什么不全部直接用 MCP

MCP 适合复杂项目，但简单项目直接 Tools 更轻。

直接 Tools 适合：

单项目
工具数量少
快速 Demo
本地 RAG
工具只给当前 Agent 使用

MCP 适合：

多个 Agent 共享工具
多个客户端共享工具
工具来自不同系统
工具需要独立部署
工具需要统一鉴权
企业内部系统集成
Cursor / Codex / Claude Desktop 等多个客户端都要调用

一句话：

小项目直接写 Tools 更快，企业级工具共享和跨系统接入更适合 MCP。

---

5.8 MCP Tool 调用是异步时，主流程会不会等待

会。

对于当前这一次 Agent 执行链路来说，调用 MCP Tool 后通常要等待结果回来，才能继续推理。

用户问题
  ↓
LLM 决定调用 MCP Tool
  ↓
await MCP Tool
  ↓
MCP Server 返回结果
  ↓
LLM 继续生成回答

但这个等待不等于整个后端卡死。

在 FastAPI 这类异步服务里：

当前用户请求：等待 MCP 返回
其他用户请求：仍然可以继续处理

工程上要注意：

短任务：await + 超时 + 重试 + 流式状态
多个独立工具：并行调用
长任务：task_id + 后台任务 + 进度查询

---

6. 多 Agent 怎么控制不同 Agent 调不同 MCP Tool

6.1 基础做法：每个 Agent 绑定自己的 tools

例如有 5 个 MCP，每个 MCP 2 个 Tool：

order_mcp
  - query_order
  - query_payment

member_mcp
  - query_member
  - query_points

coupon_mcp
  - query_coupon
  - verify_coupon

kb_mcp
  - search_kb
  - search_error_code

ticket_mcp
  - create_ticket
  - query_ticket

可以给不同 Agent 分配不同工具：

order_agent
  - query_order
  - query_payment

member_agent
  - query_member
  - query_points

kb_agent
  - search_kb
  - search_error_code

ticket_agent
  - create_ticket
  - query_ticket

LangGraph 结构：

用户问题
  ↓
Router Node
  ↓
根据意图分流
  ├── order_agent  → order tools
  ├── member_agent → member tools
  ├── kb_agent     → kb tools
  └── ticket_agent → ticket tools

---

6.2 这样是不是硬编码

是的，如果写死：

mapping = {
    "order_agent": ["order_mcp"],
    "member_agent": ["member_mcp"]
}

本质还是硬编码。

但企业项目里通常是：

权限边界硬约束
工具选择智能化

也就是：

不能让模型决定自己有没有权限
可以让模型参与判断当前问题需要哪些工具

---

6.3 更智能的方式

可以做成：

Tool Registry
  ↓
Tool Retriever
  ↓
Permission Filter
  ↓
Dynamic Tool Injection

流程：

MCP Servers 启动
  ↓
tools/list 拉取所有工具元数据
  ↓
Tool Registry 保存：
  - tool name
  - description
  - input schema
  - mcp server
  - tags
  - risk level
  - required role
  ↓
对 tool description 做向量化
  ↓
用户提问
  ↓
检索 Top-K 相关 tools
  ↓
权限过滤
  ↓
Router 判断单 Agent / 多 Agent
  ↓
动态绑定 tools
  ↓
Agent 执行

这样既能减少硬编码，也能控制安全。

---

6.4 关键原则

LLM 负责语义判断
规则负责权限边界
检索负责工具召回
LangGraph 负责流程编排
MCP 负责工具标准化执行

一句话：

可以让模型智能选择工具，但不能让模型决定权限边界。

---

7. Skill

7.1 Skill 是什么

Skill 通常不是代码里像 Tool 一样被调用，而是项目工程里的规则、流程、经验模板、操作规范。

它主要给：

Codex
Cursor
Claude Code
AI Coding Agent
项目内开发助手

这类 AI Coding 工具使用。

Skill 更像：

遇到某类任务时，应该怎么分析
按什么顺序做
注意哪些边界
输出什么格式
不要踩哪些坑

---

7.2 Skill 和 Tool 的区别

对比	Tool	Skill
本质	可执行能力	工程规则 / 操作手册
是否运行时调用	是	通常不是
形式	函数 / API / MCP Tool	Markdown 文档 / 规则 / 流程
作用	做具体动作	指导 Agent 怎么做事
例子	query_order()	订单问题排查流程

Tool 像：

def query_order(order_id: str):
    return db.query(order_id)

Skill 像：

当排查订单问题时：
1. 先确认订单号
2. 再查支付状态
3. 再查会员信息
4. 再查优惠券核销记录
5. 最后输出原因、处理建议、是否需要人工介入

---

7.3 Skill 是否默认启动时读取

一般来说：

如果 Skill 放在平台约定目录或配置里，Agent 通常会在启动或会话初始化时读取/索引。

但不同平台不完全一样：

有的启动时全量扫描
有的只读项目根目录的 AGENTS.md
有的按需读取相关 Skill
有的需要用户明确指定

更严谨的说法：

Skill 的元信息通常在启动或会话初始化时被发现；
真正完整内容可能在任务命中时再读取。

---

7.4 Skill 是否默认遵循

不一定。

Skill 不是最高优先级规则，而是满足条件时优先参考。

一般优先级可以理解为：

系统指令 / 安全规则
  > 开发者指令
  > 当前用户指令
  > 项目级 AGENTS.md / README / 规则
  > Skill 说明
  > 模型自己的常识

所以 Skill 更像专项操作手册，不是绝对规则。

如果想让 Skill 更稳定生效，最好在 AGENTS.md 里明确写：

处理 RAG、Milvus、混合检索、embedding、reranker、离线知识库问题时，必须优先参考：

- skills/rag_debug/SKILL.md

除非用户明确要求跳过，否则按该 Skill 的排查流程执行。

---

7.5 Skill 对实际项目有没有用

有，但它不是线上运行时组件。

Skill 不参与线上业务请求：

前端
  ↓
FastAPI
  ↓
LangGraph
  ↓
Tools / MCP
  ↓
Milvus / MySQL / Redis

这个链路里真正运行的是：

FastAPI
LangGraph
LLM
Tools
MCP
数据库
向量库

Skill 一般不会在线上用户请求时被读取执行。

它的价值在开发期和维护期：

降低 AI 改错概率
统一团队工程规范
沉淀排查流程
加速新人/AI 理解项目
减少重复解释上下文
让 Agent 更稳定地改代码、排错、生成测试

一句话：

Skill 不是运行时架构组件，而是开发期 / 维护期 / AI 协作期的工程规范资产。

---

8. Agent 项目里一般写哪些 Skills

8.1 AGENTS.md：项目总规则

通常写：

项目背景
技术栈
目录结构
启动方式
测试方式
代码风格
禁止修改的内容
接口规范
数据库规范
提交规范

例如：

本项目是 AI Agent + RAG 智能客服系统。
后端使用 FastAPI + LangGraph + Milvus。
接口统一使用 POST。
响应统一使用 BaseResponse[T]。
不要直接修改线上数据库 schema。

---

8.2 RAG / 知识库 Skill

适合写：

知识库构建流程
文档加载规则
chunk 切分规则
embedding 模型选择
向量库字段说明
稠密/稀疏混合检索流程
rerank 流程
Milvus collection schema 检查方法
检索不到结果的排查步骤

例如：

rag_debug/SKILL.md

内容：

1. 先确认文档是否成功入库
2. 再确认 collection 是否存在
3. 再检查 dense vector 维度
4. 再检查 sparse vector 格式
5. 再检查 index metric type
6. 再检查 search 参数
7. 最后检查 reranker 是否过滤过严

---

8.3 Agent 编排 Skill

适合写：

什么时候用单 Agent
什么时候用多 Agent
Router 怎么设计
Supervisor 怎么设计
State 字段规范
Node 命名规范
Conditional Edge 规则
Tool 调用边界
错误兜底流程

例如：

agent_orchestration/SKILL.md

---

8.4 Tool / MCP 接入 Skill

适合写：

Tool 命名规范
Tool description 写法
参数 schema 规范
只读/写入工具区分
MCP Server 连接方式
stdio / Streamable HTTP 使用场景
权限校验规则
超时和重试策略
工具调用日志格式

例如规则：

只读工具命名使用 query_xxx / search_xxx / get_xxx。
写入工具命名使用 create_xxx / update_xxx / delete_xxx。
所有写入类工具必须二次确认。
所有 MCP tool 必须配置 timeout。
禁止把 admin_mcp 暴露给普通客服 agent。

---

8.5 后端 API Skill

适合写：

FastAPI router / service / schema / model 分层
统一响应模型
错误码规范
异常处理规范
日志规范
数据库 session 使用规范
SSE 流式接口规范

例如：

所有接口统一返回 BaseResponse[T]。
router 层只负责参数校验和调用 service。
service 层负责业务逻辑。
错误统一抛 AppException。
错误码放在 errors.py。
流式接口使用 SSE，不直接返回大段 JSON。

9. 最终对比表

名称	本质	是否运行时执行	主要使用者	典型场景
Function Calling	模型调用函数的机制	是	LLM API / 后端程序	模型生成函数名和参数
Tools	Agent 可调用能力集合	是	Agent / LangChain / LangGraph	搜索、查库、调接口
Tool Calling	Agent 调用工具的行为	是	Agent Runtime	根据问题选择并执行工具
MCP Tool	通过 MCP 暴露的标准化工具	是	MCP Client / Agent	文件系统、GitHub、数据库、内部系统
Skill	工程规则 / 任务范式 / 操作手册	通常不是	AI Coding Agent / Codex / Cursor	项目开发、排错、规范沉淀

---

10. 一句话总结

Function Calling 是调用机制；
Tools 是可调用能力；
Tool Calling 是 Agent 调工具的动作；
MCP Tool 是通过 MCP 标准化暴露出来的工具；
Skill 是给 AI Coding 和项目维护用的工程规则与任务范式。

更工程化地说：

MCP / Tools：运行时能力
LangGraph：运行时流程编排
Skill：开发期规范
AGENTS.md：项目级 AI 规则
README / docs：人类和 AI 都能看的项目文档

---