MCP、Function Calling 和 API Gateway 怎么配？AI Agent 工具接入的三层架构

很多人在做 AI Agent 工具调用时，会问一个问题：

我已经有 Function Calling 了，还要不要 MCP？

这个问题听起来很正常，但实际已经把层级搞混了。

Function Calling、MCP、API Gateway 不是三个互相替代的东西。它们更像一套从模型到生产系统的三层结构：Function Calling 负责让模型表达“我要调用什么工具、参数是什么”；MCP 负责把外部工具、文件、数据库、SaaS、上下文资源标准化接入；API Gateway 负责把真实生产环境里的身份校验、限流、审计、隔离和成本管住。

如果只做 Demo，你可能只需要 Function Calling。如果要让一个 Agent 同时接文件系统、GitHub、数据库、内部知识库、浏览器和多个业务工具，你会开始需要 MCP。如果这个 Agent 要服务真实用户、访问真实系统、产生真实操作，光有 MCP 也不够，前面还得有网关、权限、审计和降级策略。

这篇文章不再重复讲 “MCP vs Function Calling 谁更好”。那篇我已经单独写过：MCP vs Function Calling：区别、适用场景、什么时候该用 MCP？。今天只讲一个更工程化的问题：一个真正能上线的 AI Agent，工具接入层到底应该怎么拆？

一、Function Calling 是调用表达层

Function Calling 解决的第一件事，是让模型用结构化方式表达调用意图。

比如用户问：“帮我查一下这个用户最近 30 天的订单状态。”模型自己不能直接访问业务系统。你可以给它一个工具定义，告诉它这个工具叫什么、需要哪些参数、参数类型是什么。模型看到工具后，并不是自己真的去查数据，而是返回一个结构化调用请求。然后你的应用代码拿到参数，执行真实查询，再把结果返回给模型继续生成答案。

所以 Function Calling 的核心价值是：工具参数结构化，减少自然语言解析错误，让模型能在多个工具里做选择，让业务代码保留最终执行权，也让调用过程可以进入日志和调试链路。

但它也有明显边界。

Function Calling 不会自动帮你管理一堆工具服务，不会自动发现文件系统里有哪些资源，不会替你做用户授权，也不会天然解决多客户端、多工具、多 Agent 复用问题。它更像模型和应用之间的“调用契约”：模型想调用这个工具，并且给出了这些参数。

至于这个工具在哪里、谁有权限调用、调用失败怎么办、日志怎么记、是否允许写操作，这些都不属于 Function Calling 本身能完全解决的问题。

二、MCP 是工具和上下文的协议层

MCP 的价值，不是把 Function Calling 干掉。它解决的是另外一层问题：当工具、资源和上下文越来越多时，怎么用统一协议把它们接进 AI 应用生态？

MCP 里有几个关键角色：Host 是发起连接的 LLM 应用，比如 IDE、聊天应用、Agent 平台；Client 是 Host 内部的连接器；Server 是提供工具、资源和上下文能力的服务。

如果用普通 Function Calling，你可能会在每个应用里重复写一遍工具定义：IDE 里写一套 GitHub 工具，聊天应用里写一套 GitHub 工具，自动化工作流里再写一套 GitHub 工具，内部 Agent 平台又写一套 GitHub 工具。这很快会失控。

MCP 的思路是：把 GitHub、文件系统、数据库、浏览器、知识库这些能力包装成 MCP Server，然后不同 Host 通过 MCP Client 去连接。

也就是说，MCP 更像 AI 时代的工具协议层。它让工具不再只是某一个应用里写死的函数，而是可以被多个 AI 客户端复用的上下文服务。

MCP Server 可以暴露三类能力：Resources 是给模型使用的上下文和数据；Prompts 是可复用的提示词模板和工作流；Tools 是模型可以请求执行的函数能力。

这就比单纯 Function Calling 更适合复杂系统。

比如你要做一个内部研发 Agent，它需要读取代码仓库、查询 issue、读取设计文档、检索数据库变更、执行受限任务，再把结果写回项目管理系统。这些工具都写成 Function Calling 当然也能做，但维护成本会迅速变高。工具定义散落在应用里，权限边界也容易混在业务代码里。更麻烦的是，你以后换一个 Host，还要重新接一遍。

MCP 更适合把这些外部能力标准化、服务化、协议化。这也是我为什么在 MCP Server 生产化治理 和 MCP 安全最佳实践 里反复强调：MCP 的重点不是“多一个调用方式”，而是“多一层工具和上下文边界”。

三、API Gateway 是生产治理层

但到这里还没完。

很多人以为有了 MCP，就可以直接让 Agent 连内部系统。这其实不稳。

因为 MCP Server 仍然可能连接真实文件、数据库、接口和业务系统。只要涉及真实系统，问题就会从“怎么调工具”变成“怎么管边界”。

这时候 API Gateway 就该出现了。

API Gateway 不负责让模型更聪明，也不负责替代 MCP。它负责的是生产环境里最细、最容易被忽略的部分：用户身份、租户隔离、工具调用白名单、请求签名、限流、日志审计、成本控制、字段过滤、写操作确认、失败降级。

举个例子。你有一个财报分析 Agent，它可以读取用户上传的年报 PDF，提取 KPI、风险因素、source_page 和 evidence。这个场景看起来只是“读取文件”，但生产环境里至少要考虑：文件归属、任务状态、证据页码、失败重试、人工复核、结果边界。尤其是财经内容，不能输出买卖建议、目标价、仓位建议。

这些不是 MCP 自己能完全兜住的。

MCP 可以把“PDF 解析工具”“表格抽取工具”“JSON Schema 校验工具”暴露出来；Function Calling 可以让模型表达要调用哪个工具；但权限、审计、用户隔离、写入限制和风险提示，仍然需要网关和业务层治理。

所以我更倾向于把 AI Agent 工具接入拆成三层：

LLM
  ↓ Function Calling
Agent Runtime
  ↓ MCP Client
MCP Server
  ↓ API Gateway
业务 API / 数据库 / 文件 / SaaS / 内部系统

Function Calling 让模型说清楚自己要什么。MCP 让工具和上下文以标准协议接进来。API Gateway 让这些调用在生产环境里可控、可审计、可回滚。

少一层都能跑 Demo，但上线以后就会变成事故入口。

四、三层架构怎么分工？

层级	主要负责	不负责	适合场景
Function Calling	结构化表达工具调用意图	工具发现、资源管理、权限治理、审计	工具少、后端自控、Demo 或小型业务
MCP	工具、资源、提示词和上下文的标准化接入	业务侧完整鉴权、限流、账单、合规策略	多工具、多客户端、多 Agent 复用
API Gateway	鉴权、限流、审计、租户隔离、成本控制、风控	模型推理、工具协议、上下文理解	真实生产环境、用户数据、写操作、企业系统

这张表背后的重点是：不要在 Function Calling 里硬塞协议治理，也不要指望 MCP 替你做完整生产治理。

很多项目出问题，就是因为把三层混在一起。

比如把几十个工具全部塞进一次 Function Calling 请求里；每个工具的 description 越写越长，最后模型选择越来越不稳定；MCP Server 直接连业务数据库，没有网关隔离；写操作没有人工确认；工具失败后没有 fallback；只记录模型最终答案，不记录 tool_call 和 tool_output；没有区分读权限和写权限；没有成本上限。

这些问题一开始不明显。Demo 阶段，Agent 能回答问题，就觉得系统已经能跑。但到生产环境里，真正的问题不是“能不能调用工具”，而是调错了怎么办、调慢了怎么办、调用成本失控怎么办、用户越权怎么办、工具返回脏数据怎么办、模型把工具描述当成可信事实怎么办。

这些问题都不是一个 tools: [] 参数能解决的。

五、什么时候只用 Function Calling？

只用 Function Calling 没问题，前提是系统足够简单。

我会在这些场景里直接用 Function Calling：工具数量很少；不需要跨客户端复用；业务风险低；还在验证产品方向。

比如只有 get_user_profile、get_order_status、create_support_ticket 这类工具，并且它们都由同一个后端服务提供，参数结构清楚，权限逻辑也在现有业务系统里，那就没必要一开始上 MCP。

早期 MVP 最怕为了“架构正确”把自己拖死。先用 Function Calling 把用户路径跑通，再决定是否抽 MCP Server，是更现实的路线。

但即使用 Function Calling，我也建议做三件事：schema 尽量严格，tool_call 和 tool_output 必须进日志，写操作必须单独加确认，不要和只读工具混在一起。

这个阶段可以简单，但不能完全没有边界。

六、什么时候该引入 MCP？

当你开始遇到这些信号，就该考虑 MCP：同一个工具要被多个 AI 客户端复用；工具数量越来越多，维护 tools schema 很痛苦；Agent 要接文件、数据库、GitHub、浏览器、知识库等多类资源；你希望工具能力从应用代码里拆出来；你希望不同 Host 都能使用同一套上下文服务。

比如一个独立开发者网站运营 Agent。它可能要接 Search Console 数据、GA4 页面数据、Cloudflare 404 日志、Astro 本地内容库存、GitHub 仓库、文章发布系统、UTM Builder、SEO inventory 报告。

如果所有东西都塞在一个 Function Calling 列表里，很快会变成工具大杂烩。

更合理的方式是拆 MCP Server：

xbstack-content-mcp
xbstack-analytics-mcp
xbstack-github-mcp
xbstack-publisher-mcp

每个 Server 管一类资源。Agent Runtime 只负责根据任务连接合适的 MCP Server。

这样后续无论你用 Chat 页面、CLI、后台运营台，还是 IDE 插件，都可以复用同一套工具能力。这才是 MCP 的实际价值。

七、什么时候必须加 API Gateway？

只要进入真实生产环境，我基本默认要加。

尤其是这些情况：涉及用户数据，涉及写操作，涉及多租户，涉及成本，涉及企业内部系统。

我一般会让 API Gateway 做这些事：校验用户身份，注入 tenant_id 和 user_id，检查工具调用 scope，对写操作增加二次确认，记录 request_id / tool_call_id / trace_id，做 rate limit 和 cost limit，过滤敏感字段，将高风险操作送人工复核，失败时返回结构化错误，保留审计日志。

这部分和 n8n Webhook Production Hardening 的逻辑很像。

公网入口永远不能只问“能不能通”。更重要的是：谁能调？调几次？调什么？失败怎么办？事后能不能追？

八、一个更接近生产的 Agent 架构

如果我现在要做一个生产级 AI Agent 工具系统，我不会这样写：

LLM → tools[] → 业务 API

这太薄了。

我会拆成这样：

用户请求
  ↓
Agent Runtime
  ↓
Function Calling / Tool Choice
  ↓
MCP Client
  ↓
MCP Server
  ↓
API Gateway
  ↓
业务服务 / 数据库 / 文件系统 / SaaS
  ↓
审计日志 / Trace / Cost Meter / Review Queue

其中，Agent Runtime 负责会话、任务状态、工具选择和中断恢复。Function Calling 负责让模型表达调用哪个工具、参数是什么。MCP Client 负责连接不同 MCP Server。MCP Server 负责暴露工具、资源、提示词和上下文能力。API Gateway 负责权限、限流、审计、隔离、降级。业务服务负责真正的数据读写。审计系统负责保留证据链。

这个结构看起来比 Demo 复杂，但它的好处是边界清楚：模型不直接碰业务系统；MCP Server 不直接拥有所有权限；Gateway 不理解模型推理，但管住访问边界；每次调用都能被追踪；失败时知道是哪一层坏了。

这也是我在做 XBSTACK 工具页和 AI Finance 证据链时越来越明确的一点：AI 应用不是把模型接进来就完了，真正费时间的是“模型和真实系统之间的缓冲层”。

九、我的判断公式

最后给一个我自己会用的判断公式。

如果你还在做 Demo：Function Calling 足够。

如果你要接很多工具，并且希望多个客户端复用：Function Calling + MCP。

如果你要服务真实用户、真实数据、真实写操作：Function Calling + MCP + API Gateway。

如果你只是问“我要不要 MCP”，说明你还在协议层纠结。更好的问题应该是：我的系统现在卡在哪一层？

如果卡在模型不知道怎么表达工具调用，那是 Function Calling 的问题。

如果卡在工具太多、上下文太散、客户端复用困难，那是 MCP 的问题。

如果卡在权限、审计、限流、用户隔离、成本和生产治理，那是 API Gateway 的问题。

三层都清楚以后，AI Agent 才不只是一个能演示的聊天框，而是一个能接入真实系统的工程组件。

FAQ

已经有 Function Calling 了，还需要 MCP 吗？

不一定。工具少、业务简单、只服务一个应用时，Function Calling 足够。MCP 更适合多工具、多资源、多客户端复用的场景。

MCP 能替代 API Gateway 吗？

不能。MCP 解决工具和上下文的协议化接入，API Gateway 解决生产环境里的鉴权、限流、审计、隔离和风控。两者不是同一层。

API Gateway 应该放在 MCP Server 前面还是后面？

通常放在 MCP Server 访问真实业务服务之前。MCP Server 可以暴露工具能力，但真实业务系统的权限和审计最好仍由 Gateway 或业务服务控制。

小项目是不是不用这么复杂？

是。小项目可以先用 Function Calling，把路径跑通。但日志、只读和写操作分离、失败处理这三件事最好从第一天就留好。

XBSTACK 站内应该先优化哪篇？

如果你是从 SEO 和站内结构角度看，建议先看主力页：MCP vs Function Calling：区别、适用场景、什么时候该用 MCP？。本文是它的工程架构支撑文，不是替代页。

推荐阅读

• MCP vs Function Calling：区别、适用场景、什么时候该用 MCP？
• MCP Server 生产化治理：权限、审计、工具边界和安全策略
• MCP 安全最佳实践：Prompt Injection、工具边界与审计治理
• n8n Webhook Production Hardening：公网入口怎么做签名、限流和幂等
• AI 财报分析助手研发路线：PDF 解析、任务队列、证据链与人工复核

参考资料

• Model Context Protocol Specification, version 2025-06-18
• OpenAI Function Calling Guide

专题入口 / MCP Hub

继续按 MCP 生产部署路径读，而不是堆 guide / tutorial

MCP 内容统一按协议理解、本地 Server、远程部署、OAuth、安全治理、stdio/JSON-RPC 排障和工具对比来承接，避免站内关键词互相抢。

进入 MCP 专题 → 查看安全治理清单 订阅更新