「Agent Tool」Function Calling 和 MCP 的适用场景？

0 前言

本文内容整理自公众号「小林面试笔记」的文章 7. Function Calling 也属于工具调用，请问什么场景下使用 Function Calling，什么场景下使用 MCP？，用于记录与总结 AI Agent 工具调用相关的核心面试知识点。

「Function Calling 也属于工具调用，请问什么场景下使用 Function Calling，什么场景下使用 MCP？」，可以这样作答：

场景选型不是一刀切，判断的核心问题只有一个：这个工具会不会在这个应用之外被用到？ 会的话，封装成 MCP Server 是更长远的选择。

Function Calling 适合「只用自己、只用一次、不需要复用」的场景，主要有四类：快速原型和 Demo（直接在代码里定义 schema，不用起进程、不用配置）；工具只为单一应用服务（比如查本公司私有数据库的内部接口，永远不会被其他地方用到）；需要对执行逻辑做精细控制（权限校验、参数二次处理、错误处理、链路追踪直接嵌在调用代码里）；部署环境受限（Serverless 等平台不允许启动子进程，stdio 模式的 MCP 没法用，只能退回 Function Calling）。

MCP 适合这四类场景：跨项目或跨团队复用（同一套 GitHub 操作，Claude Desktop、同事的 Cursor、团队的 CI/CD Agent 都要用，Server 维护一次、所有客户端受益）；社区已有现成 Server（GitHub、Slack、PostgreSQL、Puppeteer、Google Maps 都有经过测试的官方或社区 Server，配置几行 JSON 即用，不用重复造轮子）；工具规模起来了（没有具体数字门槛，而是由数量、复杂度、团队规模、变更频率综合判断——schema 散落各处、改接口要连坐多处的维护泥潭）；构建 Agent 系统（工具来源多而杂，MCP 让工具按需连 Server、来源模块化，Agent 核心逻辑与工具管理解耦）。

实用的判断顺序：先看社区有没有现成 Server → 再看有没有跨项目复用需求 → 综合看工具规模 → 考虑是不是正式 Agent 系统 → 最后检查部署环境。总结一句话：「只用自己、只用一次、不需要复用」才适合 Function Calling，其他情况优先考虑 MCP。两者不是竞争关系，MCP 底层本来就是靠 Function Calling 驱动的，选型取决于工程需求，而不是技术层面的优劣。

如今主流 AI 客户端都内置了 MCP 支持，GitHub、Slack、PostgreSQL、Puppeteer、Google Maps 等高频工具均有官方或社区 MCP Server，配置文件加几行 JSON、重启即零代码接入；而在快速原型、内部私有工具、Serverless 函数这类轻量场景里，业界普遍还是直接写 Function Calling——两条路线在真实产品里各据主场，这正说明选型要看工程场景而非技术本身。

1 先建立一个直觉：内嵌 vs 独立

为什么会有「什么时候用哪个」的问题？因为 Function Calling 和 MCP 的工具在存在方式上有本质区别。

Function Calling 的工具是「内嵌」在应用代码里的：工具定义（schema）和调用逻辑都直接写在你的项目代码中，工具和应用绑在一起，应用换了、代码就要跟着重写一遍。

MCP 的工具是「独立」的：封装成一个独立运行的进程，对外暴露标准接口，任何支持 MCP 的 AI 客户端都能连上来直接用。工具的生命周期和应用解耦，可以独立部署、独立维护、一次实现、到处复用。

Function Calling 工具内嵌在应用代码里，MCP 工具是独立进程、可多客户端复用

这个「内嵌 vs 独立」的本质区别，直接决定了两者各自适合的场景——内嵌的代价是换应用要重写，好处是轻；独立的代价是要起一个进程，好处是可复用、可共享。

2 Function Calling 的适用场景：轻量、临时、不需要复用

什么时候用 Function Calling 就够了？一句话：「轻量、临时、不需要复用」的场景。具体展开是四种情况。

Function Calling 适用场景：快速原型、单一应用、精细控制、部署受限

第一种，做快速原型和 Demo。目标是跑通一个想法或做演示，直接在代码里定义 schema 和调用逻辑就行，不需要启动任何额外进程、不需要额外配置。这种场景上 MCP 完全没必要——你花在搭 Server 上的时间，可能超过原型本身的价值。

第二种，工具只为这一个应用服务。假设你在做一个内部工具，里面有一个查本公司私有数据库的接口，这个接口绝不会被任何其他地方用到，那用 Function Calling 把逻辑直接写在项目里反而更清晰——何必额外维护一个独立的 MCP Server 进程呢？

第三种，需要对工具的执行逻辑做精细控制。Function Calling 的调用逻辑完全在你的代码里，想加权限校验、参数二次处理、特殊错误处理、调用链路追踪，都可以直接嵌进去；MCP Server 是独立进程，这类定制逻辑要跨进程传递或约定，远不如写在调用代码里方便。

第四种，部署环境受限。某些受限的云环境或 Serverless 平台不允许启动子进程，stdio 模式的 MCP Server 根本没法用。这种情况只能退回 Function Calling，工具逻辑都写在主进程里反而最稳妥。

3 MCP 的适用场景：会被反复使用的工具，都值得封装

那什么时候该上 MCP？概括成一句话：只要工具不是「自己用、用一次就扔」，MCP 基本都值得考虑。具体四类场景。

核心场景：工具要跨项目或跨团队复用

想一个画面：同一套 GitHub 操作工具，你自己的 Claude Desktop 要用、同事的 Cursor 要用、团队的 CI/CD Agent 也要用。如果用 Function Calling，意味着三处各维护一份 schema 和调用代码，工具接口一变就要同步改三处，漏改一处就出 bug。

MCP 的做法优雅得多：工具封装成独立 Server，任何人在配置文件里加几行就能接进来，维护责任集中在 Server 那一侧，所有客户端自动受益。

最务实的理由：社区已经有现成的 MCP Server

GitHub、Slack、PostgreSQL、Puppeteer、Google Maps 这类高频工具，都有经过测试、文档完整的官方或社区 MCP Server。你不需要自己写一遍，直接配置就能用：

1
2
3
4
5
6
7
8
9
// 在 claude_desktop_config.json 里加几行，一行工具代码都不用写
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

社区现成 MCP Server：配置文件加几行 JSON 即用，无需手写对接代码

这种情况下还用 Function Calling 手写 GitHub API 的调用代码，那就是重复造轮子，完全没必要。

工具规模起来后，管理优势就明显了

注意，这里不想给一个绝对的数字门槛（比如「超过 3 个就要上 MCP」），实际判断要综合几个维度：工具的复杂度（每个工具的 schema 和调用逻辑是几行还是几十行）、团队规模（一个人维护还是多人协作）、变更频率（工具接口经常改还是基本稳定）。

如果你的工具平均复杂度不低、团队好几个人都在碰这些代码、接口还时不时调整，那就算只有 5 个工具，也很快会把你拖进维护泥潭；反过来，两个极其简单、几乎不动的工具，没必要为它们引入一套独立 Server。

为什么工具多了 Function Calling 就难维护？因为 schema 定义和调用逻辑会散落在代码各处：新加工具要改应用代码，工具有 bug 也要进应用代码改，出问题时定位链路很长。MCP 的自动发现机制正好解决这个问题：主程序不感知具体工具、只连 Server，新增工具只需在 Server 里加实现，主程序完全不用动。

构建 Agent 系统：MCP 几乎是必选项

Agent 系统的工具需求往往多样、来源复杂，可能同时需要代码执行、文件系统、数据库、外部 API 等各类工具。全靠 Function Calling 的话，工具 schema 会成为 Agent 代码里最难维护的部分。

Agent 按需连接多个 MCP Server：工具来源模块化，核心逻辑与工具管理解耦

MCP 让 Agent 可以按需连不同的 Server，工具来源模块化，Agent 的核心逻辑和工具管理完全解耦，架构干净很多。

4 一个实用的判断方法

碰到「用 Function Calling 还是 MCP」这个选择题，其实不需要纠结太久，按几个问题依次过一遍就清楚了。

选型决策流程：社区现成 Server → 复用需求 → 工具规模 → 是否 Agent → 部署环境

第一问，社区有没有现成的 MCP Server？ 有的话直接用，不要重复造轮子，这是最省事的路径。

第二问，这个工具需不需要在多个项目或多人之间复用？ 需要就选 MCP，一次封装、到处使用。

第三问，工具规模到了那个「感觉到散乱」的拐点了吗？ 综合看数量、复杂度、团队规模和变更频率——规模上来之后，MCP 的统一管理比散落在代码各处的 Function Calling 清爽得多。

第四问，你是在做正式的 Agent 系统，还是 Demo 原型？ 正式系统选 MCP 更利于长期维护，Demo 的话 Function Calling 上手更快。

第五问，部署环境允许吗？ 如果平台不允许启动子进程，Function Calling 就是更稳妥的选择。

五个问题过完，答案自然就出来了。

5 面试总结

回答这道题，最典型的误区就是用单一维度做选型判断，比如只看项目规模、只看工具数量。面试官想听的是你能根据具体场景做出合理取舍，而不是一刀切地倾向某一个方案：

误区 正解
小项目用 FC、大项目用 MCP 规模不是唯一因素——大项目如果工具只在内部用、不需要复用，也不一定上 MCP
工具少用 FC、工具多就用 MCP 数量只是维度之一；社区已有现成 Server 时，哪怕只接一个工具也优先 MCP
只讲「什么时候用 MCP」 FC 的四种适用场景（快速原型、单一应用、精细控制、部署受限）同样要讲，展示全方位取舍
项目规模大 = 一定要 MCP 还要综合复用需求、社区生态、是否 Agent 系统、部署环境五个维度

再按这张框架组织答案：

判断维度 要点
本质区别 FC 工具「内嵌」在应用代码里、与应用绑定；MCP 工具「独立」，独立进程 + 标准接口，一次实现到处复用
FC 的四类场景 快速原型/Demo、工具只服务单一应用、需要精细控制执行逻辑、Serverless/受限部署环境不能起子进程
MCP 的四类场景 跨项目/跨团队复用、社区已有现成 Server（配置即用）、工具规模与管理复杂度上来、构建 Agent 系统
判断方法 五问决策：社区现成 Server → 复用需求 → 规模综合 → 是否 Agent → 部署环境
核心结论 「只用自己、只用一次、不需要复用」才适合 FC，其他优先 MCP；两者非竞争关系，MCP 底层由 FC 驱动

追问预案：

  • 「选型只看项目规模行不行？」——不行，规模只是维度之一。大项目若工具只在内部用、不需要复用，FC 反而更轻；还要看复用需求、社区生态、Agent 与否、部署环境（机制差异的完整拆解见本系列第 4 篇）。
  • 「工具数量有具体的数字门槛吗？」——没有。看四个维度的综合：工具复杂度、团队规模、变更频率、数量；5 个复杂、多人维护、接口常变的工具就很快进维护泥潭，2 个简单稳定不动的工具没必要引入独立 Server。
  • 「Serverless 环境为什么只能用 Function Calling？」——stdio 模式的 MCP 需要以子进程方式启动 Server，受限云环境和 Serverless 平台不允许，只能把工具逻辑写进主进程（也就是 FC 的调用代码里）。
  • 「为什么 Agent 系统更该选 MCP？」——Agent 工具来源多而杂，全用 FC 则 schema 散落代码各处、成为最难维护的部分；MCP 按需连 Server、工具模块化，Agent 核心逻辑与工具管理解耦，新增工具不动主程序。
  • 「社区有现成 Server 还手写 FC 对接吗？」——属于重复造轮子。官方/社区 Server 经过测试、文档完整，配置几行 JSON 即用，任何客户端受益（接 Server 的具体写法见第 4 篇的实际跑一遍）。
  • 「FC 和 MCP 是竞争关系吗？」——不是，MCP 底层本就靠 Function Calling 驱动，选型取决于工程需求而非技术优劣。

参考

本文图片均来源于公众号「小林面试笔记」，版权归原作者所有。

追逐繁星 > Agent Tool
#AI #Agent #大模型 #LLM
「Agent Tool」Function Calling 和 MCP 的适用场景？
https://marisamagic.github.io/2026/08/19/20260819_FC与MCP使用场景/
作者
MarisaMagic
发布于
2026年8月19日
许可协议