MCP薄封装争议背后：Agent连接架构重选与工具调用取舍-北京尧图网络

最近几个月我在技术社区频繁看到两种截然对立的论调一边有人说“MCP无非是个薄封装删掉它之后Agent反而更稳更快”另一边又有团队发出“给调试器、EDA软件、甚至ERP接上MCP之后封闭工具链突然变得会聊天”的欢呼。这两个现象一点都不矛盾它们恰恰同时指向同一个问题MCP是不是真的要到退出历史舞台的边缘了在Agent连接架构重选的时候我们究竟该把它放在什么位置又该把哪几层“薄封装”果断删掉这篇文章不打算站队我只想结合自己做过的几个Agent项目把“删掉薄封装”这个动作拆开来看MCP到底做了什么、没做什么什么场景下它是多余的什么场景下它又比原生Function Calling香得多。看完之后你会得到一个可以拿去直接做选型的判断框架而不是一句“MCP已死”或“MCP万岁”的口号。1. 唱衰声从哪里来“薄封装”到底薄在哪一层1.1 “薄封装”这个说法的出处与准确含义大约从2024年下半年开始AI Agent开发社区里流行起一个批评角度MCPModel Context Protocol本质上只是把“工具调用”这件事包了一层协议。你的数据库查询、HTTP接口、文件操作本来写成函数就能直接丢给大模型偏偏要按MCP的规范写成server用JSON-RPC来回传参数和结果。在多了一层序列化、反序列化、网络传输和进程调度之后响应延迟多了几十毫秒出错的环节也多了几个。这话对不对对一半。我们去翻一下MCP协议规范就会发现它暴露的三类原语是tools、resources、prompts。Tools对应的是“模型可以调用什么”Resources对应的是“模型可以读取什么”Prompts对应的是“模型可以被安排成什么工作模式”。这本质上就是把工具元数据标准化然后用统一方式完成调用。从计算机工程的角度看它确实是在“函数到模型的通路”上套了一层壳厚度谈不上有多深。但这里有个概念误区薄封装不等于无用封装。USB协议本质上也是“把PCIe总线上的数据传输包了一层薄薄的标准化封装”HDMI、DisplayPort也一样。封装的价值从来不在厚度而在它构筑的边界和生态。MCP这个薄层重新定义了“工具如何被模型发现、调用和审计”。把这一层称之为“薄”更像是在描述实现成本而不是在否定它存在的理由。1.2 为什么社区会喊出“删掉薄封装”我翻了大量相关讨论发现喊“删掉薄封装”最凶的通常是被两类问题折磨过的开发者。第一类是“为了MCP而MCP”的滥用者。有人把所有工具都包成server哪怕这个工具只是读取本机的一个配置文件。结果模型要拿一个file path还得先过一遍MCP的三次握手和session初始化。多出来一个进程、一堆日志、一个崩溃点。这种场景下把MCP删掉、直接改成函数内联确实是正确决策——你要删掉的不是MCP这个协议而是那些毫无必要的进程边界和网络开销。第二类是被server质量坑怕的集成者。社区里有大量MCP server是“伪server”本质上只是在一个子进程里调用HTTP API却引入了Python环境、Node依赖、配置文件三个故障源。模型一旦调不通错误日志还是晦涩的协议层报错排查难度直线上升。这时候回归原生工具调用少一层抽象就少一层魔鬼也是在降低运维成本。真正经得起推敲的结论是“删掉薄封装”这个动作本身没有错错的是把它当成一条放之四海而皆准的真理。你删掉的应该是不合理的进程边界、冗余传输和过度抽象而不是“工具接入标准化”这个长期有价值的工程方向。2. MCP不负责的三种能力很多“垃圾体验”是期待错位2.1 规划与任务拆分协议不管“下一步做什么”我在GitHub、知乎和各种Agent教程里都见过一种抱怨“接上MCP之后我的Agent还是笨得很。” 这句话最大的问题是误把MCP当成了Agent智能的来源。MCP只解决“模型知道有哪些工具、怎么调用、调用后如何返回”它完全不参与“该不该调用、先调哪个、调完A再调B还是调C”。举个具体例子。我做过一个内部工单分析Agent它通过MCP连接了工单数据库、用户画像服务、历史解决方案知识库三个server。刚开始跑的时候模型经常乱调明明应该先查用户画像再决定怎么搜索知识库它却先去拉历史方案导致回复牛头不对马嘴。问题出在哪里出在我没有给它一个清晰的规划和任务拆分层。后来我在Agent的prompt里明确写了一个“先用户、后工单、再方案”的pipeline并要求模型每走一步都输出当前状态和下一步意图效果立刻改善。这就是典型的“把Agent效果差归咎于MCP等于把操作系统崩溃归咎于Shell命令”。规划、任务拆解、工具选择策略这些属于Agent架构里编排层和Harness层的事。MCP只是你递给模型的“工具箱说明书”说明书再全模型自己不动脑子规划结果还是乱。2.2 记忆与状态持久化session只活一轮另一个常见的错位是“MCP能不能记住我的偏好/上下文”。不少开发者天真的以为只要工具都走在MCP里模型就能像老友一样记住上次交互。真实情况是MCP的session生命周期非常短一个session可以对应一次或几次交互但协议层面并没有定义跨会话的长期记忆持久化方案。你上一次调用工具时模型说了什么“我记住了”下一次调用时它依然一无所知。想要“记忆”必须在Agent框架层面自己实现记忆模块通常是向量数据库加摘要压缩的组合方案。MCP server可以帮你把记忆库暴露成resource比如让模型去检索过去的摘要但这份记忆的存储、更新、索引全部是Agent连接架构中Agent自己的责任。我见过一个失败的案例有人为了让Agent“记住用户偏好”把用户ID存进了MCP server的本地文件结果多实例部署时模型一会儿读到A实例的偏好、一会儿读到B实例的偏好行为完全不可控。这恰好从反面说明MCP是一个连接协议不是一个状态管理方案。把记忆放进去就是把豆腐放在刀刃上——看着稳一碰就碎。2.3 多步骤编排与失败恢复MCP不保证调用序列正确再往深一层说MCP协议并不关心“工具调用的序列是否符合逻辑”。它可以保证一次请求被正确送达并返回但无法保证一个业务场景下先后调用五个工具的结果在语义上是自洽的。一个真实的教训来自我给供应链系统开发的Agent。当时业务流程需要先查库存、再锁单、再通知物流三个工具串成一条调用链。某一次模型在库存查询成功之后锁单工具因为超时返回了错误码模型居然直接去通知物流放行——因为它“觉得”锁单可能成功了。这就是典型的缺一个状态校验和回滚机制。MCP视角下每一次工具调用都是独立的“查库存”“锁单”它们之间的事务一致性协议完全不管。后来我在架构上加了两个东西首先是调用链编排器它会显式校验每个工具返回的状态码只有全部成功才继续下一步其次是回滚策略任意一步失败就调用一个补偿工具撤回前面的动作。这已经不是“选不选MCP”的问题而是“Agent的Harness层具备不具备事务意识”的问题。所以请把下面这句话刻在脑子里MCP管的是“工具能不能被调用”Agent框架管的是“调用序列是否合理、失败之后怎么办”。把你对智能、记忆、稳定性的期待从MCP身上拿开很多“MCP是辣鸡”的情绪自然就消解了。3. MCP被低估的工程价值工具连接层的“标准口”意义3.1 一次编写、多宿主接入带来的生态红利聊完了MCP不干什么我们得客观说说它确实干得很好的部分——生态和可移植性。最近热搜里能看到一串例子IDA MCP、x32dbg的MCP插件、Altium Designer的AI接口MCP、CherryStudio的工具流式输出到文件、Codex接入Figma和蓝湖时问的“怎么授权”……这些都指向同一个变化MCP正在成为工具链与AI宿主之间的公共插座。什么叫公共插座你在一个支持某个语义的IDE里写一个MCP server换个客户端照样能识别。比如你写了一个让模型操作PostgreSQL的MCP server那么Claude Code能直接用Codex配置上也能调自研的POC客户端通过标准SDK一样能跑。这就好像今天不会有人给每个家电单独设计一个插座口而是大家都锚定交流电标准。MCP就是AI生态里的“标准插座”只不过它还在普及早期墙上的插座与插头还没完全统一偶尔会接触不良。反过来对比原生Function Calling你可以给OpenAI的模型写一批JSON Schema函数定义也可以在Anthropic的模型里写类似的原生工具描述但它们之间是不通用的。你换模型厂商工具定义、调用方式、返回格式全部要改。如果你的产品需要同时支持多个模型或者多个宿主MCP的“一次封装、处处连接”价值就会被放大——这种标准化收益比那几十毫秒的传输开销贵得多。3.2 流式输出与长任务反馈别小看这个能力大家平时聊MCP焦点都放在tool calling上很少有人注意它其实支持流式输出和进度通知。这个能力在做长任务时非常救命。举一个我踩过坑的场景早前用原生函数调用让模型触发一个耗时2分钟的数据报表生成。模型把函数调用发出去之后整个会话就干等用户界面一直转圈体验非常糟糕。后来跳到MCP server通过streaming可以在任务执行中持续把日志、进度百分比、中间结果推回来模型可以根据进度反馈决定是继续等待还是改道. 这种“工具边跑边说话”的体验对于一个面向用户的Agent产品来说几乎是从“能用”到“好用”的门槛。CherryStudio那个热搜词“使用MCP工具流式输出内容到文件”指的就是类似的场景大模型在生成代码或长文时通过MCP的流能力把内容一段一段实时写入本地文件而不是等全部生成完再一次性落盘。这种场景下你要是一直用内联函数串行等待会把人逼疯。所以别只盯着MCP的“薄”也要看到它在交互协议层面的流式设计是真有深思的。3.3 权限边界与审计生产环境里最贵的工程能力在生产环境里跑Agent最让我头疼的往往不是模型聪明不聪明而是“安全的工具访问边界”怎么建。如果你的Agent有权限读数据库、发邮件、改配置你不可能让模型直接持有所有凭证。MCP的server/client分离架构正好提供了一层天然的权限隔离区。我可以把危险操作“发邮件”独立成一个MCP server运行在专门的环境里只暴露send_email和一个dry_run_preview两个工具。Agent本体运行在另一个低权限环境它只能通过MCP协议调用这两个动作无法直接操作SMTP服务器。同时MCP请求可以统一走网关把每一笔工具调用的入参、出参、耗时、调用方记到审计日志里。这对金融、医疗、企业内部系统来说不是锦上添花而是刚需。如果你用原生函数调用实现同样的事一样可以做但需要自己造出一整套权限拦截、日志中间件、server隔离方案。MCP的价值在于这些工程设施已经被协议和SDK天然框定了你不用从零开始设计“如何让模型安全地碰外部世界”这个问题. 这也是为什么我始终认为MCP未来大概率不会消失而是会像一个被遗忘的水管一样默默藏在Agent连接架构的底层.4. 一次真实的连接架构重选复盘删掉的到底是什么4.1 项目背景与最初的架构设计为了把问题讲清楚我拿去年做的一套企业内网知识库Agent来复盘。场景是这样的公司内部有一堆文档散落在Wiki、Confluence、共享网盘和数据库里员工希望用自然语言问“某某模块的负责人是谁”“上一季度营收数据出来没有”“这份合同的审批流程走到哪了”。我们希望能做一个统一的问答Agent把多源数据串起来。初始架构我选择了All-in-MCP把Wiki接口包成resource server把数据库查询包成tool server把合同审批流程包成一个带写操作的tool server。设想很美好一套协议多种数据源加上一个LLM调度循环就能上岗。真正跑起来之后才发现问题远不止“工具能不能调”这么简单。第一周我们就遭遇了性能问题。数据库查询这个工具高频场景下用户会连续提5到6个问题每个问题触发2到3次查询全部走MCP的JSON-RPC来回传输。在本地进程内测还能忍受一旦server部署在容器里、客户端在另一个容器里单次查询的p95延迟暴涨到800毫秒。模型等久了就开始“自由发挥”偶尔编造一个错误数据出来。无奈之下我们只能临时给高频查询做了结果缓存但缓存又导致数据时效性出问题。4.2 为什么砍掉了一半MCP调用复盘时我们画了一组调用热力图结论非常清晰占80%请求量的就三个工具——查文档索引、查员工信息、查数据库表数据。这三个工具的逻辑都非常简单参数是确定的结构化数据返回值也是固定的JSON。它们完全不需要“跨进程的抽象”更不需要“继往开来的标准化”它们只需要一个又快又稳的函数调用。于是我在第二轮架构里做了一个“分层混合”决策把这三个高频、高确定性工具从MCP server迁出来改成Agent框架内部的原生函数工具Function Calling直接走进程内调用。效果立竿见影p95延迟从800毫秒降到60毫秒错误率降了一半以上模型因为等待导致的幻觉行为大幅度减少。这个过程就是网上说的“删掉薄封装”的一个活案例。删掉的到底是什么删掉的不是标准化协议而是“为一个本来就直连的函数调用而强行建立网络进程边界”的过度设计。当工具本身就在同一进程里你还在外面包一层server这就等于在自己的家里还给电灯装了个电表箱——多此一举。4.3 保留下来的是什么以及为什么但我没有把MCP全部删掉。合同审批、权限确认、跨部门数据拉取这三个场景我反而加强了MCP的使用。原因有三第一它们涉及多个外部系统调用路径天然分布在不同的服务里需要一个统一的权限边界第二流程类工具需要回流状态和进度MCP的流式反馈能更好支持第三审计要求非常高每一笔“查询合同”“修改状态”的操作都要留痕MCP的统一网关让日志采集变得顺手。最终架构变成了一个“内环直连外环MCP”的混合形态内环是高频确定性的数据查询走原生函数调用外环是低频高价值的跨系统写操作与权限敏感操作走MCP server。这套结构跑了大半年稳定性比第一版All-in-MCP高出一截而功能覆盖度基本没降。这个复盘想说明一个点“从删掉薄封装到Agent连接架构重选”并不是一条单行道而是一个动态调优的过程。你需要不断根据调用频次、延迟敏感度、权限需求把每一个工具划到合适的连接层里。好的架构师不是“永远选MCP”或“永不选MCP”而是知道每个工具该住哪层楼。工具类型连接方式主要原因运行时开销高频确定性查询文档索引、员工信息、单表查询原生Function Calling延迟敏感单进程内调用最快最低跨系统低频查询多表关联、跨部门数据MCP 缓存需要统一鉴权与请求追踪中等写操作/审批流改状态、发通知、锁单MCP需要权限边界、流式反馈与审计中高第三方封闭工具调试器、EDA、设计软件MCP工具本身无法直接函数化必须外部连接高但值得5. Agent连接架构怎么选我现在的判断框架5.1 三组基础场景的选型策略基于上面的复盘我给大家一个可以直接套用的选型策略。不用管外面的口水仗先对号入座。第一组单模型、单进程、私有工具调用。典型情况是你在做一个个人助理或是一个轻量级Demo工具就是几个本地函数模型也只有一家。这时候的正确答案就是“删掉薄封装”。直接在Agent框架里写Function Calling把函数定义填清楚让模型调用。你不需要MCP甚至不需要一个独立的server进程。我之前见过有人写一个“读取天气的MCP server”里面只有一行HTTP GET。这种场景下托管MCP server带来的部署复杂度已经超过了工具本身的价值属于典型过度封装。第二组多宿主、多模型、需要工具生态互操作。典型情况是你想把同一套工具能力给Claude Code、Codex、自研Web应用同时使用或者希望团队里其他人也能各自接上这些工具。这时候MCP是最省心的选择。你只需要写好server配置好授权所有宿主都能发现并调用。热搜里那些“Codex接入Figma MCP”“Codex接入蓝湖MCP”本质就是在解决这种跨宿主接入场景的认证问题。如果你遇到类似的“我换个工具链就要重写一遍工具定义”的痛点MCP就是正解。第三组生产级Agent混合负载强审计要求。这就是我上面讲的“内环直连、外环MCP”形态。高频确定性工具用Function Calling低频高价值工具用MCP。没有争议没有情怀只按性能与安全两个指标分配。5.2 一套快速打分清单如果你还是不确定某个工具到底该不该走MCP我用一个简单的打分表帮大家做决定。每一项按0到5分打分满分越高就走MCP低分则走原生函数调用。是否会被多个宿主/模型复用越高越走MCP是否涉及跨进程、跨机器的外部系统越高越走MCP是否需要流式反馈和进度上报越高越走MCP是否有审计、权限隔离的合规要求越高越走MCP调用是否会进入高频热路径越低越走MCP协议层带来的延迟是否可接受越低越走MCP—— 参考值是单次额外延迟超过150ms且可以被缓存替代的优先改内联。我拿这个清单回头验算过好几个项目命中率非常高。你可以把它当成一个检查表遇到纠结时跑一遍比翻十篇博客都有用。5.3 未来趋势MCP会从“明星协议”变成“隐形协议”再聊一个更大的趋势。我个人的判断是MCP不会退出历史舞台但它会从话题C位退到幕后。它正在走一条所有成功协议都走过的路先成为热点再成为默认基础设施最后变得无人讨论。当你用USB接口时你不会天天喊“USB要统治世界”你只是希望设备的接口能统一。MCP也一样过了这一两年的概念炒作期之后它大概率会沉淀为Agent连接架构里最底层的那一层工具Schema标准化、身份认证、请求追踪、审计日志。大家选的Agent框架会内置MCP客户端工具市场会大量出现开箱即用的server而应用开发者不再需要手动配置connection只需要说一句“给我接上数据库”就完事。到那时候再讨论“MCP要不要退场”就是伪命题——它已经“退场”到了连讨论都不值得的位置但它仍然支撑着Agent生态的互操作性。真正需要你操心的是Agent的规划、记忆、编排和事务一致性。那才是决定产品智能上限的东西。最后分享一点我自己的取舍心得做Agent开发这件事最大的坑不是选错协议而是把某个技术方案当成信仰。我踩过All-in-MCP的坑也见过为了省那几十毫秒把安全边界丢掉的事故。现在我的态度很简单MCP是一种连接架构的选择不是Agent智能的救世主更不是应该被批斗的靶子。删掉不需要的薄封装把协议放在它该在的位置剩下的精力全部留给规划和记忆层的打磨你的Agent才能真正从“玩具”走向“产品”。下次有人再在群里争论MCP死不死你可以把这篇文章转给他然后问一句你的工具调用延迟和权限审计现在是怎么解决的

MCP薄封装争议背后：Agent连接架构重选与工具调用取舍

相关推荐

直播带货退潮后，普通人如何用AI实现效率套利

AI教材开发：知识图谱与大模型如何提升效率与降低查重率

GEO优化服务：短期流量与长期品牌的平衡策略

更多资讯

在线判题系统（OJ）架构解析：从Web端到判题端的部署与优化

TPS259483AYWPR与PIC18F85K22工业电源路径保护方案

深度学习调参指南：超参数搜索的可执行流程与常见问题排查

AI+Three.js：智慧农业3D大屏巡检系统开发实战

AI如何助力本科生高效完成文献综述

MiFlash 2022.05.07刷机：驱动、Fastboot与9008避坑

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？