在大语言模型（LLM）迅速演进的当下，越来越多的智能应用系统不仅仅满足于“问答生成”，而是开始向“具备工具使用能力的智能体（Agent）”发展。为了实现这一目标，LLM 被赋予了 function call 的能力，并结合调度组件（Agent）和上下文协议（MCP）共同构建出一整套可以执行任务、管理流程、调用工具的智能系统。

本文将讲解以下内容：

• LLM 的 function call 本质与流程

• Agent 的角色与调度职责

• MCP（Model Context Protocol）的定位与作用

• 三者之间的协作机制

---

LLM Function Call 是什么？

function call 是指：让大模型根据用户请求和上下文，自动生成一个调用函数（或插件、工具）所需的函数名和参数信息，由外部系统实际执行这个函数后再返回结果供模型继续推理生成。

它使 LLM 从“只能说”变成了“能干活”。这也是我们看到大模型从对话助手向自动化执行体转型的关键起点。

传统大模型仅能生成语言内容，如回答问题、写摘要、翻译文本。但 function call 引入之后，模型可以做到以下场景：

• 查询天气

• 执行数据库查询

• 生成图表

• 自动化表格处理

• 网络检索或爬虫

• 调用公司内部API完成任务

---

LLM Function Call 的关键机制

要实现这一能力，需要以下几个基本组成：

1. 函数定义（tools schema）

开发者向 LLM 提供一个或多个函数的“结构定义”，通常以 JSON Schema 格式描述。包括函数名、作用、每个参数的类型和含义。

{
  "name": "get_weather",
  "description": "获取某城市在指定日期的天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "城市名称"
      },
      "date": {
        "type": "string",
        "description": "查询日期"
      }
    },
    "required": ["city", "date"]
  }
}

2. 用户发起自然语言请求

比如用户说：

“帮我查一下明天长沙的天气。”

3. 模型判断是否需要调用函数

• 如果模型判断可以直接回答，它就返回自然语言响应；

• 如果模型判断需要工具支持，它会输出一个结构化的函数调用请求，如下：

{
  "function_call": {
    "name": "get_weather",
    "arguments": "{ \"city\": \"长沙\", \"date\": \"明天\" }"
  }
}

4. Agent 执行函数调用

Agent 或外部服务接收到这个 function_call 结构后，解析出参数，调用后端逻辑（如查API、查数据库），返回结果。

5. 模型基于结果继续生成回答

模型接收函数结果后继续生成响应，比如：

“明天长沙多云，最高气温30°C，最低气温22°C。”

---

Agent 的角色与作用

尽管 function call 是由 LLM 生成的，但系统中是否真的执行这个调用、怎么执行，其实由 Agent 决定。Agent 是围绕大模型构建的“任务执行智能体”。

Agent 的职责包括：

• 构造 prompt（或 MCP）上下文给 LLM

• 提供或组合 tools schema

• 判断 LLM 输出是否包含 function_call 请求

• 校验 function_call 的合法性（如函数是否存在、参数是否缺失）

• 调用外部函数/服务/插件

• 将结果再次传入 LLM 或用于最终响应

• 管理任务状态、用户 memory、多轮任务链路

Agent 并不会自己生成 function_call

很多人误以为 Agent 自己在判断是否要调用函数。其实，function call 的触发是由 LLM 的输出决定的。

Agent 的工作是：

当 LLM 输出中包含 function_call 字段，Agent 就根据定义的工具描述，解析、执行，并管理结果。

---

MCP（Model Context Protocol）：上下文的基石

MCP 是由 OpenAI 提出的一种“上下文组织协议”，用来标准化 LLM 所需的任务背景、用户记忆、函数调用记录、文件引用、对话历史等内容。

关于MCP的详细知识，有一篇文章写的很好，可以参考：

MCP (Model Context Protocol)，一篇就够了。 - 知乎

MCP的核心目标：

• 提供结构化、可复用的上下文环境

• 实现多轮、跨工具任务的上下文一致性

• 支持多模态（图文表）和多 Agent 协同执行

• 降低 prompt 拼接复杂度，提升可控性

MCP的典型内容字段包括：

• 用户身份与偏好（memory）

• 当前任务意图（intent）

• 上下文对话历史（conversation history）

• 已使用的工具/函数及其输入输出（tool usage trace）

• 附件、图片、文档等引用（multi-modal context）

MCP 实质上是对传统“prompt”的结构化升级，统一了上下文组织方式，推动 AI 应用从“对话”走向“执行系统”。

---

三者之间的关系（LLM + Agent + MCP）

这三者在整个智能任务执行流程中的关系如下：

角色	职能说明
LLM	根据上下文判断是否生成 function_call 请求，并生成最终语言输出
Agent	调度流程、管理状态、执行函数、组织上下文
MCP	用标准协议结构组织所有上下文，供 LLM 和 Agent 使用

协作流程图（简化版）

[用户输入]
     ↓
[Agent]
   - 整理 MCP 上下文
   - 插入历史记录、memory、工具 schema
     ↓
[LLM]
   - 输出 function_call 请求 或 普通回复
     ↓
[Agent]
   - 判断是否调用函数
   - 执行调用（如API/插件/脚本）
     ↓
[Agent]
   - 将函数结果封装入新上下文
     ↓
[LLM]
   - 再次生成自然语言输出
     ↓
[返回给用户]

---

示例场景：财务数据分析助手

用户上传了一份 Excel 表格，并说：

“请帮我分析下本季度销售数据，并生成柱状图。”

步骤拆解：

1. Agent 生成 MCP 上下文：

   • 用户意图：“分析销售数据”

   • 文件引用：excel 表格

   • 工具 schema：parse_excel, generate_chart

2. LLM 读取上下文，生成 function_call：

{
  "function_call": {
    "name": "parse_excel",
    "arguments": "{ \"file\": \"sales_q2.xlsx\" }"
  }
}

1. Agent 执行 parse_excel 工具，返回结构化数据表

2. LLM 接收数据表后，再次生成 function_call：

{
  "function_call": {
    "name": "generate_chart",
    "arguments": "{ \"type\": \"bar\", \"data\": [...], \"x\": \"月份\", \"y\": \"销售额\" }"
  }
}

1. 最终模型生成结果并呈现柱状图解释给用户

---

function call 相关的常见误区与澄清

1. function call 是模型主动生成的吗？

是的。LLM 根据上下文自动决定是否生成 function_call 字段。没有 function_call，就不会发生函数调用。

2. Agent 能代替模型去调用函数吗？

不行。Agent 只在 LLM 明确“指令调用”的前提下才执行。它自己不会发起调用，但它可以拒绝执行模型输出的不合法调用。

3. MCP 是必须的吗？

不是。你也可以用传统 prompt + tool list 构造上下文。但 MCP 提供了结构化和一致性的优势，适合中大型多工具场景。

---

function call 赋予大模型实际动手能力，Agent 提供执行策略与任务管理，MCP 为其组织强上下文的能力提供标准化支持。它们不是彼此替代，而是形成协作网络，使 LLM 不再只是对话引擎，而是一个具备记忆、判断、行动能力的 AI 系统。