紫老头聊AI

Appearance

1. Function Calling 是什么？ ​

核心定义 ​

Function Calling 是一种让大语言模型（LLM）在推理过程中主动调用外部函数或工具的机制。
开发者预先向模型提供一组函数的结构化描述（包括名称、参数、功能说明），模型在回答问题时可判断是否需要调用，并以标准格式输出调用指令，由应用层执行后将结果反馈给模型，最终生成准确回答。

本质作用 ​

  • 赋予 LLM 与外部世界交互的能力（如查询数据库、调用 API、执行计算）；
  • 实现 “思考 + 行动” 的闭环，是构建智能 Agent 的关键技术之一。

2. Function Calling 解决了什么问题？ ​

1. 结果解析困难 ​

  • 传统方式：模型通过自然语言描述“我想查北京天气”，开发者需用正则或 NLP 解析器从中提取意图和参数；
  • 问题：解析规则脆弱、易出错、维护成本高。

2. 工具使用不准确 ​

  • 若函数定义模糊，模型可能：
    • 编造不存在的函数名；
    • 传错参数类型或遗漏必填项；
    • 产生不可执行甚至危险的操作。
  • 后果：调用失败、系统不稳定、安全风险。

Function Calling 的改进 ​

  • 通过结构化 Schema 约束，强制模型输出合法、可执行的调用指令；
  • 应用层可直接解析 JSON，无需复杂文本理解，提升可靠性与安全性。

3. Function Calling 的工作流程 ​

1. 函数注册（Function Registration） ​

  • 在调用 LLM 前，将可用函数的元信息以 JSON Schema 形式注入提示词（prompt）或通过 API 参数传入。

2. 调用意图生成（Intent Generation） ​

  • 模型根据用户问题和函数列表，判断是否需要调用工具；
  • 若需要，则输出结构化的函数调用请求（通常为 JSON 格式），而非自然语言。

3. 应用执行调用（Execution by Application） ​

  • 应用代码检测模型输出：
    • 若识别为函数调用消息，解析出函数名和参数；
    • 调用对应的本地函数或外部 API；
    • 获取执行结果（如 {"temperature": "25°C"}）。

4. 结果反馈与最终回答（Result Injection & Final Response） ​

  • 将函数返回结果作为 “Observation” 追加到对话上下文中；
  • 再次调用 LLM，基于新信息生成面向用户的自然语言回答（如“北京今天气温是25°C”）。

此过程可嵌套多轮，形成 ReAct 式推理循环。

4. Function Calling 的底层实现机制 ​

1. 模型能力来源：SFT 微调 ​

大模型通过监督微调（Supervised Fine-Tuning, SFT） 获得两项关键能力：

  • 意图识别能力：判断当前任务是否需要调用外部工具；
  • 结构化输出能力：严格按照预定义 Schema 生成 JSON 格式的调用指令。

2. 提示词（Prompt）的辅助作用 ​

  • 在推理时动态传入 functions 列表，告知模型“当前可用哪些工具”；
  • 提示词中通常包含调用格式示例和约束说明，引导模型正确使用。

3. 与 Agent 框架的集成 ​

  • Function Calling 是 LangChain、LlamaIndex 等框架中 Tool 使用的核心基础；
  • 与 ReAct、Plan-and-Execute 等 Agent 策略结合，实现复杂任务自动化。

5. 什么是 MCP（Model Context Protocol）？ ​

基本定义 ​

  • MCP（Model Context Protocol，模型上下文协议）是由 Anthropic（Claude 母公司） 提出的一种标准化通信协议。
  • 目标：让大语言模型（LLM）通过统一接口，安全、高效地连接外部数据源和工具，获取实时信息或执行操作，打破模型与外部世界的壁垒。

核心价值 ​

1. 降低开发成本 ​

  • 无需为每个数据源或工具单独编写 Function Calling 适配代码；
  • 统一协议后，一次集成即可支持多种后端服务。

2. 提升系统扩展性 ​

  • 新增工具或数据源时，只需部署一个 MCP Server；
  • LLM 应用（MCP Host）可自动发现并调用新能力，无需修改模型提示词或业务逻辑。

6. 为什么需要 MCP？ ​

传统方案的痛点 ​

  • 静态知识局限：大模型训练数据截止，无法获取实时信息（如股价、天气、用户私有数据）；
  • 接口碎片化：
    • 开发者需为每个模型（如 GPT、Claude、Llama）和每个数据源（数据库、API、文件）编写定制化对接逻辑；
    • 维护成本高，复用性差，扩展困难。

MCP 的解决思路 ​

  • 引入中间层协议，将“工具/数据”抽象为标准化服务；
  • 模型只需与 MCP 交互，无需关心底层实现细节。

7. MCP 与 Function Calling / Tool 的区别 ​

维度Function Calling / Tool（传统方式）MCP
协议性质模型私有实现（如 OpenAI 的 functions 参数）跨模型、跨平台的开放标准协议
工具注册方式需在每次调用时将工具描述硬编码进 prompt 或 API 参数工具由 MCP Server 动态提供，Host 自动发现
扩展性新增工具需修改应用代码和提示词仅需部署新 MCP Server，零代码改动
适用范围单一模型生态内支持多模型、多工具、多数据源的统一接入

✅ MCP 本质是 Function Calling 的标准化、服务化演进。

8. MCP 核心架构 ​

1. MCP Host ​

  • 与用户直接交互的大模型应用（如 Cursor、Claude Chat、自研 Agent 应用）；
  • 内嵌 MCP Client，负责与 MCP Server 通信。

2. MCP Client ​

  • 集成在 Host 中的通信代理；
  • 负责：
    • 与 MCP Server 建立连接；
    • 获取可用工具/资源列表；
    • 转发 LLM 的调用请求；
    • 将执行结果返回给 LLM。

3. MCP Server ​

  • 轻量级服务，通过标准接口暴露三类能力：
    • Resources（资源）：可读取的数据单元，如文件内容、API 响应；
    • Tools（工具）：可被 LLM 调用的函数（如 send_email, query_db）；
    • Prompts（提示模板）：预定义的 prompt 片段，辅助完成特定任务（如“写周报模板”）。

4. 数据源 ​

  • Local Data Sources：本地文件、数据库、私有 API；
  • Remote Services：云服务、第三方 API、SaaS 平台等。

9. MCP 通信协议 ​

  • 基于 JSON-RPC 2.0 标准，确保消息格式统一、可扩展。
  • 支持两种传输方式：
    • Stdio（本地通信）
      • 利用操作系统标准输入/输出管道；
      • 适用于本地工具（如 CLI 工具、本地数据库）；
      • 高效、低延迟。
    • HTTP + SSE（远程通信）
      • 通过 HTTP 长连接 + Server-Sent Events 实现实时双向通信；
      • 适用于分布式部署、远程服务调用。

10. MCP 工作流程 ​

  1. 初始化连接
    MCP Client 与 MCP Server 建立连接，获取当前可用的 Tools / Resources / Prompts 列表。

  2. 用户提问
    用户输入问题（如“帮我查一下昨天的销售数据”）。

  3. LLM 决策
    Host 将问题 + 工具描述发送给 LLM；
    LLM 判断是否需要调用工具，并输出结构化调用指令。

  4. 工具执行
    MCP Client 将调用请求转发给 MCP Server；
    Server 执行对应操作（如查询数据库），返回结果。

  5. 生成最终回答
    结果被注入上下文，LLM 基于新信息生成自然语言回复。

整个过程对用户透明，实现“模型思考 → 工具行动 → 模型总结”的闭环。

11. 什么是 A2A（Agent-to-Agent Protocol）？ ​

基本定义 ​

  • A2A（Agent-to-Agent Protocol）是由 Google 提出的智能体间通信协议；
  • 目标：定义一套标准消息格式与交互规则，使多个 LLM Agent 能够协作、协商、共享状态，共同完成复杂任务。

核心能力 ​

  • Agent 可声明自身：
    • 能力（Capabilities）
    • 当前状态（State）
    • 任务需求（Requests）
  • 支持任务委派、进度同步、结果汇总等协作模式。

12. A2A 与 MCP 的对比 ​

相似点 ​

  • 均为标准化协议，旨在解决 LLM 生态中的信息孤岛问题；
  • 提升系统互操作性与可扩展性；
  • 推动 LLM 应用从“单打独斗”走向“协同智能”。

关键区别 ​

维度MCPA2A
核心目标连接 LLM 与外部工具/数据源实现 Agent 与 Agent 之间的协作
交互对象LLM ↔ 外部服务（数据库、API、文件）Agent ↔ Agent（多个智能体）
交互粒度细粒度：具体工具调用、数据读取（如“调用天气 API”）粗粒度：任务请求、状态通告、能力协商（如“请帮我分析这份报告”）
典型场景单 Agent 获取实时信息或执行操作多 Agent 分工合作（如规划 Agent + 执行 Agent + 审核 Agent）

MCP 解决“模型如何用工具”，A2A 解决“多个模型如何一起干活”。
二者可结合使用：一个 Agent 通过 MCP 调用工具，再通过 A2A 将结果传递给其他 Agent。

Copyright © 2025 LLM Interview Hub