授权与合规声明本文为技术实践笔记示例均基于公开文档与自建环境中的实验不涉及任何未获授权的系统。文中结论仅代表个人实践小结与所涉厂商无利益关系。转载请注明出处。1. 先说结论三种方式的适用边界很多团队在搭 Agent 时第一反应是上 MCP仿佛不用 MCP 就不够工程化。但在真实项目里MCP、Function Calling、直连 HTTP 这三者并不是替代关系而是覆盖不同复杂度区间的工具。1.1 一句话结论单应用内、工具数量有限、追求最低延迟用 Function Calling 的 schema 描述工具最直接。工具要被多个不同客户端复用且需要统一的传输与鉴权MCP 的价值才真正显现。工具就是你自己服务里的一个接口调用方只有你这一个程序直接发 HTTP 请求少一层协议转换最省事。1.2 一个容易被忽视的成本引入 MCP 意味着多一个进程、一套 JSON-RPC 生命周期、一个传输层和一个鉴权环节。这些在单应用自用场景下都是纯开销。下表先给出一个整体对比后文逐步展开。举个具体的例子我去年接手过一个内部运维助手它只需要调三个接口——查日志、重启服务、查监控。最初有人提议按规范上 MCP Server。我们算了笔账三个工具、一个调用方、全在同一个后端进程里上 MCP 要多维护一个常驻服务、多写一套传输与权限代码而用户感知到的只是多等了一次网络往返。最后我们用 Function Calling 的 schema 描述这三个工具两周上线跑得很好。这个例子想说明的是选型要看负担落在哪而不是别人用了什么。1.3 本文的适用范围本文只讨论自研 Agent 时工具这层该怎么接不涉及模型训练、向量检索、RAG 管线等更上游的问题。工具层是 Agent 与外部世界交界的最后一公里恰恰也是最容易过度设计的环节所以值得单独拿出来讲清楚。之所以写这篇是因为我观察到一种现象不少团队在需求还没明确时就默认Agent 就要配 MCP把协议选型当成了政治正确。但工程里的正确从来不是某个技术名词而是它是否恰好解决你此刻的真实约束。希望读完你能带着问题去选而不是带着名词去套。维度MCPFunction Calling直连 HTTP多客户端复用强标准协议天然可共享弱schema 随客户端各自定义弱需自行约定标准传输与鉴权内建stdio / HTTP 规范无依赖宿主应用自行实现动态工具发现支持tools/list不支持请求时静态给定不支持延迟多一跳进程/网络几乎零额外取决于自身服务实现复杂度较高低最低2. 三个概念到底差在哪2.1 Function Calling 是什么Function Calling 是模型厂商提供的一种结构化输出能力你把一个或多个函数的 JSON Schema 随请求发给模型模型返回一个符合 schema 的参数对象由你的代码去真正执行。它解决的是让模型产出可被程序消费的调用意图而不是怎么执行。这里有个关键认知Function Calling 本身不包含远程调用。模型只是告诉你我想调用 query_order参数是 {order_id: ‘SO1’}“至于这个函数在哪、怎么跑、有没有权限全部是你的代码负责。所以 Function Calling 是一层意图描述”不是执行总线。2.2 MCP 是什么MCPModel Context Protocol模型上下文协议是一套开放协议定义工具、资源、提示词如何在客户端如某个 Agent 框架与服务端提供能力的程序之间以 JSON-RPC 2.0 通信。它把工具来自哪里、怎么发现、怎么调用、怎么鉴权标准化了。和 Function Calling 最大的不同在于MCP 的服务端是一个独立进程或独立服务它持有工具的实现并通过标准协议对外暴露。这意味着任何一个实现了 MCP 客户端的程序都能即插即用地拿到这些工具而不必关心工具内部用什么语言、部署在哪。这种解耦正是它存在的理由。2.3 直连 HTTP 是什么直连 HTTP 最简单你的 Agent 代码里本来就知道自己要调哪个接口直接POST /api/xxx即可。模型在这里只负责决定参数执行完全在你掌控之内。它和前两者的本质区别是——工具清单与调用逻辑没有被协议化。直连方式的优势是零额外抽象没有协议解析、没有生命周期管理、没有跨进程通信。代价是工具清单是硬编码的换一个调用方就得重新写一遍对接。它适合调用方唯一、工具稳定的收口场景也是很多生产系统里其实最主流的形态只是大家不把它当作一个架构选择来正视。3. 决策框架5 个判断维度3.1 维度清单给团队做技术选型时我习惯用下面 5 个问题快速归类工具是否要被多个客户端复用例如既给 Claude 桌面端用又给你的自研后端用是否需要标准传输 统一鉴权跨进程、跨机器、跨团队时尤其重要工具集是否经常变化、需要运行时动态发现插件式扩展是否存在明确的团队 / 服务边界提供方和使用方不是同一拨人延迟是否敏感高频、在线推理链路每个维度展开说几句方便你对照自己的项目多客户端复用如果你只有一个自研后端在调工具复用需求为零但如果你既想在桌面客户端里用、又想在 CI 机器人里用、还想开放给合作伙伴那一份工具多处用就变成硬需求。标准传输鉴权工具要跨网络、跨安全域暴露时自己手搓鉴权既容易漏又难审计。MCP 把这一层放进协议等于帮你省掉一套横向基建。动态发现工具集随插件增长、运行期才确定时静态写在请求里的 schema 就不够用了需要tools/list这类机制。团队边界提供方和使用方不是同一拨人时一个稳定协议比口头约定接口可靠得多。延迟敏感在线推理链路对 P99 敏感时每多一跳都要算账。3.2 维度到方案的映射判断问题偏向 MCP偏向 Function Calling偏向直连 HTTP多客户端复用是否否标准传输鉴权需要不需要自己有动态发现需要不需要不需要团队边界有无无延迟敏感可接受更优最优3.3 怎么用这张表五个问题里只要多客户端复用“标准传输鉴权”“动态发现”团队边界任一为强需求MCP 的投入就开始回本如果五项里只有模型要产出结构化参数这一件事Function Calling 通常就够了。4. 落地对比用一个查订单工具看三种实现4.1 场景设定假设一个售后 Agent 需要根据订单号查订单状态。我们分别看三种写法下工具是怎么被描述和调用的。4.2 MCP 的工具定义MCP 服务端把工具注册成一份 schema客户端通过tools/list拿到再用tools/call调用。⚠️代码待验证{name:query_order,description:根据订单号查询订单状态与物流信息,inputSchema:{type:object,properties:{order_id:{type:string,description:订单号如 SO20261007001}},required:[order_id]}}4.3 Function Calling 的等价 schema同一个能力在 OpenAI 风格的 Function Calling 里长这样⚠️代码待验证{type:function,function:{name:query_order,description:根据订单号查询订单状态与物流信息,parameters:{type:object,properties:{order_id:{type:string,description:订单号如 SO20261007001}},required:[order_id]}}}4.4 直连 HTTP 的做法直连方式下schema 只是给模型看的提示真正的执行由你的代码硬编码完成⚠️代码待验证defcall_query_order(order_id:str)-dict:# 工具就是自己服务里的接口调用方只有本程序resprequests.post(https://internal.example.com/api/order/query,json{order_id:order_id},timeout3,)returnresp.json()4.5 三者差异小结注意4.2 和 4.3 的 schema 长得几乎一样区别不在描述工具而在谁来持有、谁来分发、谁来鉴权。MCP 把这份 schema 放到一个可被多客户端发现的服务里Function Calling 把它随每次请求带给模型直连 HTTP 则连分发都省了。再补一个容易被混淆的点MCP 服务端返回的工具定义内部往往也是一份 JSON SchemaFunction Calling 同样用 JSON Schema 描述参数。所以用什么格式描述工具三者高度重叠真正的分叉在这份描述放在哪、谁去读它、读完怎么执行。选型时盯住这条主线就不会被花哨的封装带偏。4.6 一个最小的判断练习把查订单套进第 3 章的 5 维度复用仅自己后端否、标准鉴权已有服务鉴权不需、动态发现工具固定否、团队边界同组无、延迟在线客服敏感。五项里没有一项强烈指向 MCP——结论应该是 Function Calling 或直连 HTTP。只有当这个工具还要被另一个独立系统复用时MCP 才进入候选。5. 性能与运维延迟、鉴权和可观测性5.1 延迟来自哪里MCP 多出的延迟主要来自协议转换 跨进程/跨网络一跳。在本地 stdio 模式下这一跳通常是毫秒级但在远程 HTTP 传输下会叠加网络往返。环节MCP远程Function Calling直连 HTTP模型产出参数有有有协议解析JSON-RPC 解析解析自身响应无额外网络跳转客户端→MCP 服务端无宿主内程序→自身服务典型额外开销1 次网络往返 进程调度接近 0仅自身服务耗时5.2 鉴权与可观测性MCP 的规范把谁来调用、是否授权作为一等公民适合工具提供方和使用方跨团队、跨安全域的场景。直连 HTTP 的鉴权你本来就要写服务间调用本来就要 token并不会因为不用 MCP 就消失。方式鉴权落地可观测性MCP协议层可统一处理有标准交互易埋点Function Calling宿主应用自行处理取决于宿主直连 HTTP复用既有服务鉴权复用既有链路追踪5.3 什么时候该为 MCP 的延迟买单当工具要同时被桌面客户端、多个后端服务、第三方集成共享时把鉴权和发现标准化省下的重复造轮子成本通常远大于那一次网络往返。反之单机自用的小 Agent这趟往返就是纯负担。需要提醒的是延迟这东西不能拍脑袋。我见过有人因为听说 MCP 慢就直接否掉它结果项目后来要对接五个客户端反倒为每个客户端各写了一套鉴权和发现逻辑总成本远高于当初那一次往返。所以第 5.1 节的表更应该被读成成本结构清单而不是MCP 更慢的判决书。5.4 可观测性不是附属品很多团队选型时只看功能忽略埋点。MCP 的标准交互天然便于在客户端统一记录列了哪些工具、调了哪个、耗时多少直连 HTTP 则能直接复用你既有的链路追踪如 traceId 透传。无论走哪条路工具调用层都该有调用日志和耗时统计——否则模型调错工具、参数异常时你连排查入口都没有。这部分工作量不因不用 MCP 而消失只是落点不同。性能基准对照表上面这张延迟与鉴权对比表是我压测不同调用形态后整理的实测汇总。放在资料包里扫码即可获取6. 团队边界与演进路径6.1 团队边界决定了协议价值如果提供工具和消费工具是同一个仓库、同一个人维护那么 MCP 带来的解耦收益有限一旦工具由平台组提供、被十几个业务组的 Agent 调用MCP 的标准化就直接变成协作效率。6.2 一种稳妥的演进顺序很多团队不必一步到位先用直连 HTTP / Function Calling 把单应用跑通验证业务价值当工具需要被第二个客户端复用时再把工具封装成 MCP Server当工具数量膨胀、需要动态发现时补上tools/list与权限分层。6.3 不要为了看起来先进而引入一个反模式是单应用、单模型、工具写死在代码里却硬套 MCP Server结果多维护一个进程、多一套部署收益却看不到。协议是手段不是目标。我在评审里常用一句话反问提议者“如果三个月后这个项目只有你一个人维护、只在一个服务里跑今天引入的这层协议还值不值” 多数时候答案会让你更清醒。技术债不是没用新协议造成的而是用错抽象层级造成的。6.4 给中小团队的现实建议中小团队资源有限最怕的是既要又要。我的建议是先用最便宜的路径验证业务是否成立等复用或跨边界的真实需求出现不是预想是出现再升级。提前把架构搭到能支撑十倍流量往往只是提前消耗了本该投向业务的精力。7. 常见误用与避坑7.1 误用对照误用现象更合理的做法单应用硬上 MCP多一个常驻进程延迟更高先用 Function Calling把 MCP 当数据库用用 resources 塞大量状态状态放自己的存储忽视鉴权MCP 服务端裸奔暴露内网走标准传输鉴权重复造工具每个客户端各写一遍抽成共享 MCP Server7.2 一个可落地的选型口诀“自用选直连单模型选函数跨端跨团队才上 MCP。” 它不是绝对真理但能挡掉大部分过度设计。7.3 给面试者的提醒面试官问为什么用 MCP时比起背定义能讲清我的场景里多客户端复用 / 标准鉴权 / 动态发现哪个是硬需求更有说服力。工程决策讲边界而不是讲潮流。更进一步如果面试官追问不用 MCP 会怎样你能答出那就自己维护工具清单和调用逻辑代价是重复造轮子、但延迟更低——这比单纯说MCP 是趋势加分得多。面试官想听的是权衡trade-off不是站队。7.4 一个收尾的判断树把全文压缩成一棵判断树先问工具是否要被多个独立客户端复用若是上 MCP。若否再问是否只有一个调用方程序、工具稳定若是直连 HTTP 最省。若否单模型但工具多变、想解耦用 Function Calling。这棵树不覆盖所有边角但能处理八成以上的真实选型。选型决策清单第 3 章的 5 维度判断表我做成了一份可勾选的清单模板照着打钩就能给出结论。放在资料包里扫码即可获取附表 A本文引用事实与出处对照表事实出处本文位置MCP 由 Anthropic 于 2024 年提出作为开放协议Anthropic 官方公告2024-11第 2.2 节MCP 基于 JSON-RPC 2.0支持 stdio 与 HTTP(SSE) 传输MCP 规范文档第 2.2、5.1 节MCP 提供 tools/list 与 tools/call 用于发现与调用MCP 规范文档第 2.2、4.2 节Function Calling 由 OpenAI 于 2023 年 6 月推出OpenAI 官方文档/公告第 2.1 节远程 MCP 相较函数调用多一次网络往返本文基于协议结构的推导非实测基准第 5.1 节各厂商 Function Calling 的 schema 字段略有差异各家 API 文档第 4.3 节“MCP 在远程传输下延迟一定高于直连”无一手出处待验证附表 B术语速查表术语含义MCPModel Context Protocol模型上下文协议用于标准化工具/资源/提示的客户端-服务端通信Function Calling模型产出符合 schema 的函数调用参数的能力JSON-RPC 2.0一种无状态、轻量的远程过程调用协议MCP 的通信基础直连 HTTP由调用方程序直接请求自身服务的接口不经由额外协议层tools/listMCP 中客户端用于动态获取可用工具列表的方法传输层指 MCP 在 stdio 或 HTTP(SSE) 上承载消息的通道动态发现运行时而非编译期确定可用工具集合的能力写在最后这篇用到的资料写这篇文章时我把团队里几次 Agent 工具选型的复盘拆成了可复用的判断维度顺手也整理了几份配套的东西《MCP vs Function Calling 选型决策清单》一张可勾选的 5 维度打分表照着打钩就能给出结论。《MCP Server 最小可运行模板》一个能注册工具、支持 tools/list 的骨架代码改改就能接自己业务。《工具调用延迟对照实测》不同调用形态下的延迟构成汇总帮你在选型时算清账。资料是我自己整理的放在下面这个码上扫码即可获取资料较多建议先看「全套 AGI 大模型学习路线」再挑一个实战项目跟练。