★ FEATURED ARTICLE 上周评审一个多工具 Agent 时搭档拿着架构图问我我们已经在用 Function Calling 了为什么要再折腾一层 MCP我说你先试试让这个 Agent 在一小时内完成“读取 Figma 设计稿 → 导出切图 → 用 Playwright 打开浏览器验证还原度 → 失败时抓网络请求定位原因”这条链路再回来告诉我 Function Calling 够不够用。他试完第一句话是这些工具好像活在各自的世界里。这话恰好点出了 Function Calling 与 MCP 之间最本质的差距。这篇文章不是要否定 Function Calling而是想拆清楚它到底卡在哪MCP 又是用怎样的协议设计把这些短板一一补上的以及什么样的团队、什么样的场景更适合现在迁移。1. Function Calling 的真实边界它到底卡在哪了1.1 先回到地面Function Calling 在实际工程里解决了什么Function Calling 是 OpenAI 在 2023 年 6 月随 GPT-4 系列更新推出的能力核心意图很简单让模型在对话中不是“说”要用工具而是“结构化地请求”调用工具。开发者把函数和参数定义成 JSON Schema 塞给模型模型在推理时输出一个 tool_call应用层拿到这个调用再去执行函数最后把执行结果回填到对话上下文模型再基于结果生成最终回答。这套机制的意义在当时是革命性的。它第一次让大模型从“只会写文字”变成了“能操作外部系统”。搜索、查数据库、发指令、算库存都能接到模型后面。现在几乎所有主流 Agent 框架不管是 LangChain 还是各类 Chat IDE底层都在用或兼容这套机制。它也确实解决了“如何让模型可靠地表达调工具意图”这个最小可行闭环。所以我不认为 Function Calling 是失败品。恰恰相反它是大模型工具化的地基。只是它解决的是“模型侧”的问题不是“工具侧”的问题。地基之上要盖多工具、多系统协作的房子光靠它就不够了。1.2 多工具协作开始变痛几个“差一口气”的场景我举几个真实场景你在自己项目里大概率能对上号。第一个是工具清单变长后的 token 膨胀。Function Calling 调用前模型需要“看到”所有候选工具的 schema 才能做选择。工具少的时候无所谓工具一多光工具描述就吃掉了几千甚至上万 token。而且这个开销是每一次请求都要付的——模型每轮推理都要把清单过一遍。到了 30 个、50 个工具时从成本到选错率都在肉眼可见地恶化。更麻烦的是工具更新了旧客户端还在发旧 schema版本管理全靠人工。第二个是工具之间的上下文断裂。Function Calling 里工具 A 的结果怎么给工具 B 用唯一的路是塞回对话上下文让模型“阅读理解”后再决定怎么调 B。工具链一长中间结果像传话游戏一样被反复转述信息损耗、token 浪费、延迟上升全来了。在“设计稿切图 → 浏览器渲染 → 对比还原度”这类链式任务里这种断裂几乎是致命的每一步的中间产物都不是给模型读的文本而是文件、DOM 快照、图层数据这类结构化对象。第三个是实时性和订阅机制缺失。Function Calling 本质上是“请求-响应”模型模型要一次工具给一次。可现实里的工具是活的数据库一直在写浏览器一直在动设计稿的图层一直在改安全测试的请求一直在转发。如果你需要模型感知到这种持续变化Function Calling 没有通道可以表达“我想订阅这个变化”。你只能轮询、拉取、快照而这几乎是在用很原始的方式做现在的集成。第四个是鉴权和审批没有统一约定。Function Calling 只是定义了“模型怎么请求调用”至于调用前要不要人批准、调用后怎么审计、远程工具怎么鉴权协议层完全没有定义。每个团队在自己的应用里造各自的轮子安全性完全取决于团队水平。工具少时这问题不明显工具一多谁批准、谁执行、谁审计立刻变成一团乱麻。最后是供应商锁定。说得直白一点OpenAI 的 Function Calling 和 Anthropic 的 tool use、Google 的 function declaration细节都不一样。模型输出的结构不同参数约束不同工具列表格式不同。你从一个模型切到另一个工具层几乎是推倒重来。这在多模型策略越来越普遍的今天是很多人没意识到的大坑。1.3 本质矛盾Function Calling 是“模型的能力”不是“工具的协议”把这些痛点放一起看你会发现它们有一个共同根源Function Calling 是用“模型推理上下文”来承载工具调度逻辑的它把工具描述、参数约束和调用决策全部揉进了 prompt 里。工具越多prompt 越重prompt 越重模型理解和输出就越不稳定工具生态越丰富模型厂商各自的标准就越互不兼容。这就像一个城市只靠口头传话来指挥交通——少数几辆车没问题车一多、路口一多传话的损耗和歧义就把系统拖垮了。MCP 的出现本质上是换了一种思路把“工具接入”从模型上下文里抽出来做成一个独立的、和模型无关的标准协议让工具像设备和电脑之间通过统一接口一样插上就能用。这也是我标题里说的“设计哲学”——MCP 不是在 Function Calling 上打补丁而是改变了问题所在的层面。这里放一张我经常在分享里用的对比表能帮助你更直观地理解差异对比维度Function CallingMCP本质模型推理能力的一部分工具与应用之间的标准化上下文协议工具发现静态把 schema 塞进请求动态发现tools/list 实时返回连接方向模型 → 工具单次问答双向可调用、可订阅、可请求模型采样上下文占用工具描述全部进入 prompt协议层管理按需拉取安全边界应用自己实现协议内定义审批、Roots 边界、OAuth供应商OpenAI、Anthropic、Google 各自实现跨模型、跨客户端、跨服务商通用生态复用换供应商基本重写一套 Server 到处接所以当工具数量少、供应商固定时Function Calling 完全够用但当“生态”二字开始出现MCP 的价值就直线上升。2. MCP 的设计思路像 USB-C 一样统一工具接入2.1 三个角色的分工Host、Client、Server 分别承担什么MCP 的架构设计很有意思它把整个连接体系拆成了三个角色。Host是你正在使用的那个主应用比如 Claude Desktop、Cursor、各种 IDE 或浏览器插件。Server是实际提供能力的一方它暴露工具、资源和提示词可以跑在本地进程stdio 模式也可以部署成远程 HTTP 服务。Client则夹在中间在 Host 内部与某一个 Server 建立一对一的连接负责协议的编解码和消息转发。为什么要拆三层而不是直接让 Host 调 Server因为拆开之后Host 可以同时挂多个 Server每个 Server 又可以被不同的 Host 复用。你写一个 Playwright MCP Server不用关心对面是 Cursor 还是 Claude Desktop只要实现协议就行。这个解耦是“生态”得以出现的前提。如果只是 Host 直接封装一堆工具方法那每个 Host 都得重复造一套轮子热词里那些 Figma、Burp Suite、Blender 的 MCP Server 就不会爆发式出现了。2.2 协议核心操作不仅有“调用”还有“发现”和“采样”MCP 的传输层建立在 JSON-RPC 2.0 之上支持 stdio 和 Streamable HTTP 两种传输方式。协议定义的方法大致可以分成几类连接初始化initialize、工具发现tools/list、工具调用tools/call、资源读取resources/read、提示词获取prompts/get、采样请求sampling/create等等。举个直观的例子一个 Server 通过 tools/list 方法返回自己能力清单返回的格式类似这样{ jsonrpc: 2.0, id: 1, result: { tools: [ { name: get_weather, description: 查询指定城市的实时天气, inputSchema: { type: object, properties: { city: { type: string } } } } ] } }相比 Function Calling 在每次请求里把所有工具都塞给模型MCP 的工具发现是动态的、按需的。模型用完一个工具还能继续发现下一个上下文压力明显轻很多。更重要的是MCP 里还有一个反向通道——sampling/create 允许 Server 反过来请求 Host 去调用大模型做补全。这个设计非常关键它意味着不仅模型能调工具工具也能在需要理解语义时向模型求助。第一次看到这里的时候我是有点吃惊的因为这种“双向性”在 Function Calling 的世界里完全不存在。2.3 为什么“标准化”比“接口好用”更重要聊到这里有人可能会问Function Calling 也挺好用的啊接口简单直接为啥非要一个协议我的观点是好用解决的是一个点标准化解决的是一个面。拿 USB-C 举例它的价值不在于“这个接口比 Lightning 好用多少”而在于一个充电器能同时给笔记本、手机、耳机、显示器供电设备厂商不必各自发明接口。MCP 的定位就是工具集成领域的 USB-C一个 Server 写出来就能被所有支持 MCP 的客户端复用一个客户端支持 MCP就能接入全世界的 Server 生态。这种生态价值在热词里体现得最明显设计领域的蓝湖 MCP、Figma MCP浏览器自动化领域的 Playwright MCP、Chrome DevTools MCP安全领域的 Burp Suite MCP、IDA MCP甚至 3D 领域的 Blender MCP、Unity MCP。它们不是为某一个 AI 写的而是为协议写的。协议一旦统一同一份 Server 可以在 Cursor、Claude Desktop、自研 Agent 之间来回迁移你的学习和运维成本也都沉淀在协议层而不是某个封闭产品里。3. 从协议内部看 MCP资源、提示词、采样和安全边界各自解决什么3.1 Tools 只是入口Resources、Prompts、Sampling 各自的价值很多人一提到 MCP 就只想到工具调用。但 MCP 并不是一个“只做工具调用”的协议它的名字里有个词叫 Context上下文对应的就是一系列围绕上下文服务的机制。Tools工具模型可以通过 Server 执行动作比如调接口、改文件、发请求。Resources资源Server 向模型暴露只读数据源比如文件内容、数据库查询结果、设计稿的结构信息。模型不需要“调用”它们而是直接“读”它们。Prompts提示词Server 可以提供可复用的提示词模板让用户或模型快速生成结构化输入。Sampling采样前面提过的反向通道允许 Server 请求 Host 使用模型能力来生成文本或向量。这几个机制让我重新理解了 MCP 的目标——它不只是“让模型多几只手”而是“让模型拥有关于外部世界的完整上下文”。比如一个设计交付场景Tools 负责导出切图Resources 让模型能直接读取图层树Prompts 把设计评审的框架预置好Sampling 则可以用来做图像描述对比。单靠 Function Calling 的“调用-回填”循环是撑不起这种复合任务的。3.2 安全与权限模型“默认需要批准”为什么反而是优点MCP 的设计里有一点很容易被新手吐槽几乎每个工具调用都需要经过用户授权。开发调试时确实烦躁每次都要点确认。但在生产环境里这个设计恰恰是它最重要的优点之一。Function Calling 时代工具调用经常是无感的——模型在后台静默执行用户直到看到结果才知道发生了什么。这在个人助手场景可以接受在涉及企业数据、支付、写库、发消息等操作时是很危险的。MCP 把“工具执行前需要批准”变成协议内置行为再配合 Roots根目录来限制 Server 能访问的文件系统范围、远程 OAuth 认证机制给出了一套标准化的安全边界。这套设计的哲学是信任不放在模型身上而是放在用户和边界身上。模型可以提议调用但决定权在人和可审计的规则手里。对团队来说安全策略可以统一写在协议层而不是散落在每个应用的业务代码里。3.3 跟着消息流走一遍完整会话为了让你把上面的概念串起来我快速走一遍 MCP 会话的完整流程。假设用户打开一个支持 MCP 的客户端向 Server 提问“北京现在适合穿什么衣服”背后发生的事情大致是Host 里的 MCP Client 启动与 Server 完成 initialize 握手交换协议版本和能力信息。Client 通过 tools/list 拿到 Server 暴露的工具清单比如 get_weather、get_clothing_advice。用户的问题进入模型推理模型决定需要调用 get_weather于是 Client 发出 tools/call 请求。Server 执行实际天气查询返回结构化结果给 Client。Client 把结果回传给模型模型结合结果生成“建议穿薄外套”的回答最终显示给用户。整个链路中每一步都有明确的协议方法承载而不是靠模型“猜”工具怎么用。这也解释了为什么 MCP Server 是高度可维护、可测试的——它本质上是把一个 Agent 的功能拆成了稳定接口剩下的语义推理交给模型。4. 真实场景验证设计稿、浏览器、安全工具接入 MCP 后的实际变化理论讲再多不如真实场景有说服力。我挑三个在热词里被反复提到的 MCP 应用场景说说它们为什么能成立。4.1 设计稿直接进 AIFigma MCP、蓝湖 MCP 把“切图”变成一种服务做研发的人对切图这件事都不陌生设计在 Figma 里画完开发要对着标注手动量间距、导出切片一个页面涉及几十个图层来回沟通成本很高。Figma MCP 和蓝湖 MCP 做的事情是把设计稿的图层、组件和导出规则作为工具和资源暴露给模型。接入 MCP 后你可以在对话里直接说“把首页 Hero 区的切图按 2x 导出按新设计系统重新命名”AI 会先读取设计稿资源再调用对应的导出工具完成切图甚至自动生成样式代码。这个场景的本质是设计资源的访问从“人肉翻图层”变成了“协议化接口”。对设计交付频率高的团队来说节省的时间是数量级的。4.2 浏览器自动化分水岭Playwright MCP 与 Chrome DevTools MCP浏览器自动化以前最大的难题不是“驱动浏览器”而是“让自动化脚本知道页面发生了什么”。传统脚本写死选择器页面一变就崩。Playwright MCP 把浏览器的操作能力变成协议工具模型可以根据页面实时内容决定下一步操作。Chrome DevTools MCP 则更进一步它把 DevTools 的能力——控制台日志、网络请求、DOM 状态、性能面板——暴露给模型。你可以让 AI 自己打开页面、观察控制台报错、抓接口返回然后直接定位问题。这在调试复杂前端问题时体验是颠覆性的你从“自己翻 DevTools 面板”变成了“让 AI 替你翻并把结论直接说出来”。而且因为底层是协议Playwright MCP 写的自动化流程可以平滑地在不同 AI 客户端里复用这是传统自动化脚本做不到的。4.3 安全与逆向Burp Suite MCP、IDA MCP 带来的工作流变化安全测试和逆向分析是另一个被 MCP 快速渗透的领域。Burp Suite 是渗透测试的标配工具它的 MCP Server 让 AI 能直接驱动代理拦截、重放、扫描和基线对比。过去你需要手工配置一堆规则、翻阅一堆请求包现在可以让 AI 按你指定的测试策略自动完成一部分重复劳动。IDA MCP 对应的是逆向方向它把反汇编、函数名解析、交叉引用和反编译结果变成可供模型检索的资源。分析恶意样本或二进制漏洞时AI 可以像资深逆向工程师一样在代码里“翻找线索”再结合自己的推理给出分析建议。这个场景特别能说明 MCP 的“上下文”设计价值——它不是简单调一个函数而是把专业工具的整个状态空间都开放给了模型。4.4 场景速查这些 MCP Server 分别解决什么问题场景代表 MCP Server解决的问题适合谁设计交付Figma MCP、蓝湖 MCP设计稿读取、切图、标注转代码前端、设计团队浏览器自动化Playwright MCP、Chrome DevTools MCP页面操作、调试、抓包、自动化测试测试、前端、运维安全测试Burp Suite MCP代理拦截、重放、扫描任务编排安全工程师逆向分析IDA MCP反汇编、交叉引用、恶意样本分析逆向工程师3D 制作Blender MCP、Unity MCP场景编辑、资产管理、自动化搭建游戏、设计工业软件TIA Portal Openness MCPPLC 工程文件读写与自动化流程工控开发这张表想说明的是MCP 不是某一类工具的专享方案它适合所有“专业工具希望被 AI 以标准方式连接”的场景。5. 迁移决策与落地经验什么时候该上 MCP上了之后怎么少踩坑5.1 先判断场景四个象限帮你看清是否要迁移是不是所有项目都要立刻迁到 MCP我的答案是别跟风。我自己用的判断框架是拿“工具数量”和“数据实时性”两个维度画四个象限少量工具 静态数据比如一个客服机器人只查一次知识库Function Calling 完全够用不需要引入 MCP。少量工具 实时数据比如需要订阅行情、日志流、传感器数据的场景MCP 的资源订阅和双向通道会更合适。大量工具 静态数据工具多但数据变化不频繁MCP 的动态发现能省下大量 context 开销。大量工具 实时数据 跨系统协作这类复杂 Agent 是 MCP 的主场比如我在开头说的“设计稿 → 切图 → 浏览器验证”链路。一句话总结如果你的工具是“十几个固定 API”那就留在 Function Calling如果你的工具开始成为一个“生态”比如几十个 Server、独立开发维护、需要跨模型复用那就理直气壮地迁到 MCP。5.2 MCP 落地我踩过的坑超时、上下文爆炸、日志和权限MCP 虽然设计得很规整实际落地还是有坑。我分享几个踩过的你遇到了可以少走弯路。第一个是 Client 超时。MCP 有些非标准 Server 第一次启动时要加载模型、连接外部服务启动时间很长。默认的 30 秒超时很容易被触发表现就是“Client 连接 Server 超时任务中断”。解决办法是分两步一是把 Server 改成常驻后台进程避免每次冷启动二是在 MCP Client 配置里显式调大超时时间给重型 Server 预留充分初始化窗口。第二个是上下文爆炸。MCP 提供了丰富资源但它不会帮你决定哪些资源该读。如果你在 Prompt 里把所有资源一次性暴露给模型token 消耗很快会失控。我的建议是配置精细的资源过滤器只暴露当前任务相关的部分还要为大型资源加摘要机制让模型先看摘要再按需读细节。第三个是 Server 日志管理。MCP 的 stdio 模式下stdout 是协议通道日志如果直接打到 stdout 会污染协议消息。正确做法是把日志落到单独文件或 stderr并用结构化 JSON 记录方便集中排查。很多刚上手的人在这里栽跟头——工具调用失败了看 stdout 全是日志而非协议响应非常迷惑。第四个是权限与审批策略。默认全审批在调试期真的很烦但全放开又失去安全意义。折中方案是做分级授权把 Server 用 Roots 限制到指定工作目录对只读工具放开审批对写操作强制人工确认。这个策略可以在安全性和流畅性之间找到平衡。5.3 给团队的三条落地建议最后给想在团队里推 MCP 的人三条实在的建议。第一先挑一个最痛的场景做 PoC不要搞“全面迁移”。找一个像“设计稿切图”或“浏览器自动化测试”这样收益明显的点做出效果后自然会有团队主动跟上来。第二优先拥抱现成的 MCP Server 生态不要急着自研。热词里那些成熟项目已经覆盖了设计、测试、安全、3D 等领域。先用现成的跑通流程再用自研补短板是最稳妥的路径。第三统一审批、日志和监控策略。MCP Server 多了以后管理成本和功能复杂度一起上升。最好在接第一个 Server 时就把日志规范、Roots 边界、权限审批和超时配置定好之后每接一个新 Server 都是套模板而不是从头搭。我在实际项目里的体会是MCP 的价值不在于“模型多会干活”而在于它把工具生态的接入成本大幅降低了。Function Calling 是模型时代的能力地基MCP 是工具时代的连接协议两者会在很长一段时间里并存。真正值得你花时间思考的不是选哪一边而是你的系统接入外部世界时有没有一套稳定、安全、可复用的方式——这才是这个协议最想解决的问题。最后再分享一个小技巧如果你刚开始实验 MCP别急着上远程 HTTP 模式先用本地 stdio 模式把所有流程跑通再看情况部署成服务。本地模式下消息延迟低、调试方便、权限边界也清晰等你对协议的行为足够熟悉再换流式或远程模式也不迟。
阅读完成 · 觉得有帮助？
