【引】MCP 过时了？昙花一现还是会一直服务于系统？老码农觉得，很多时候是我们用错了。
对于MCP，简单而已，它就是让 AI Agent 能连上你们公司各种系统（Salesforce、GitHub、Jira 这些）的一套标准。各大厂商都在推，每个 AI 平台也都在支持。
协议本身设计得不错，挺优雅的。Agent 能发现系统里有什么工具，然后调用它们。但是，很多人开始说 MCP 过时了。我倒不这么觉得，问题不在 MCP 本身，问题在于大家是怎么用它的。
大多数人对待 MCP 连接的态度，跟当年对待 API 集成一模一样：先连上再说，治理的事情后面补。但 Agent 跟普通 API 不一样啊，它是真的会动手干活的——创建数据、更新数据、删数据、跑流程，而且是以机器的速度，不带犹豫的。
这就出问题了。下面这六种反模式，是我看不少团队踩过的坑。演示环境里啥事没有，一到生产就炸。
反模式之一：直接连上去就开干
很多 SaaS 系统的 MCP 服务器，暴露出来的不是一个功能，而是一堆功能——几十个甚至几百个。你把 Salesforce 的 MCP 服务器连给 Agent，你不是给了它“读联系人”的权限，你给了它建记录、改记录、删记录、跑任意 SQL、改元数据……全套大礼包。
问题来了：你们公司每个人都需要这些权限吗？营销团队的 AI 助手，有必要一次性批量更新 100 多个订单吗？有必要删生产数据吗？有必要改权限配置吗？显然不需要。
可怕的是，Agent 不需要恶意，它只需要一个幻觉就够了。它会自信满满地觉得“应该清理一下这些记录”，然后你就得去跟领导解释，为什么 200 个客户账号在无人批准的情况下被改得一塌糊涂。
所以，别一股脑把所有工具都扔给 Agent。你得有能力按角色、按用户，只开放真正需要的那些工具。不然就是蒙着眼在雷暴里飞。
反模式之二：把“界面权限”和“Agent权限”划等号
这坑连架构师都容易掉进去。
SaaS 系统自己有权限控制，这没错。一个用户在 Salesforce 网页上只能看到某些记录，那么 MCP 服务器代表他操作时，按理说也会受同样限制，对吧？
对，但不全对。
人类在界面上点按钮，是有天然摩擦的——他看得见自己在干什么，会确认，会看弹窗警告。Agent 调用 MCP 工具的时候，没有确认对话框，没有人问它“你确定要删掉这 47 条记录吗？”它直接执行。
就算用户本身在界面上有权限修改记录，但让 Agent 以他的身份去干同样的事，风险完全不一样。当“用户”是一个几秒钟能调上百次 API 的大模型时，“最小权限原则”就有了全新的含义。别拿 UI 权限当 Agent 权限用。
反模式之三：认证方式一团浆糊
这事在 MCP 的炒作中几乎没人提——MCP 服务器的认证模型，非常不一致。
有的实现支持用户身份传播，Agent 每步操作都带上具体用户信息，权限正常生效，审计日志清晰。但更多的实现是用一个服务账号，权限很宽泛。不管谁触发的动作，Agent 都以这个高权限账号在行动。没有用户级别的审计，你根本查不出来到底是谁干了什么。
还有各种中间状态：部分身份传播、混搭的认证流程、令牌方案说不清道不明……
对你的每个 MCP 连接，一定要问清楚：“这个操作到底是以谁的身份在执行？” 不问清楚，就是定时炸弹。演示里看不出来，安全审计或者事故报告里你就能看到了。
反模式之四：明明用不了，还拼命调
实际生产中常见的一个问题：大多数 MCP 服务器会把全部工具列表发给连接的 Agent，不管这个用户实际能不能用。所以 Agent 看到 50 个工具，热情满满地尝试调用其中 30 个，结果一半返回 403 禁止访问。
然后呢？Agent 会重试、重新规划、换各种组合尝试。浪费 token，增加延迟，最后要么失败，要么瞎猫碰上死耗子。有时候它还会自己“发明”一个更糟的替代方案。
这不是小麻烦，这是结构性低效。你花钱让它跑那些永远不会成功的交互，Agent 花时间推理那些它根本用不了的工具。用户就在那儿等着，等来一个更差的结果。
解决方案不在 Agent 这边，在治理层——在工具列表到达 Agent 之前就过滤掉它无权访问的，让它只能看到自己真正能用的。
反模式之五：把几千条数据全塞进上下文
我见过太多次了：团队连上 MCP 服务器，把几千条记录一股脑拽进大模型的上下文窗口，然后让它“分析”数据。
这路子从根本上就是错的：
烧钱：数据还没开始分析呢，光加载就花掉大量 token。
撑爆：上下文窗口很快就满了。满了怎么办？截掉一部分，然后赌运气？
瞎编：大模型不是数据库。它做近似、做总结、产生统计幻觉。它给你的那个“分析”，数据可能全是编的。
不重复：同一个提示跑两次，答案不一样。
正确做法是什么？专业化。任务如果从“在系统里做点事”变成了“分析系统里的数据”，那就交给专门的 Agent 去干。这个专门 Agent 能直接访问你的数据层，跑真正的查询，用真正的分析框架，返回可验证、可重复的结果。
记住：做编排，别乱塞东西。通用 Agent 发请求，数据专家 Agent 干重活，结果干干净净地回来。
反模式之六：凑合事的破架构
下面这些野路子，我看着都皱眉头：
Zapier 粘合剂：用 Zapier 的 webhook 串起来一堆 MCP 服务器，没有错误处理、没有重试、没有可观测性。演示环境里跑得挺好，某个 API 被限流了，凌晨两点它准崩。
提示词注入当“网关”：搞个中间层，靠系统提示词来“管理”MCP 调用，比如“只使用安全的工具”。这哪是管理，这就是个建议。大模型在忽略建议这方面，创造力丰富得很。
上帝模式的大单体 Agent：一个 Agent 连上所有 MCP 服务器，所有系统的所有工具都能用。能读 CRM、能改 ERP、能发邮件、能更新项目管理、还能看 HR 记录。权限策略？API 密钥复制粘贴到环境变量，环境之间共享，从不轮换。这不是认证，这是等着被黑。
给每个工具都包一层：嫌原始 MCP 工具太危险，团队就给每个工具写自定义包装函数。加校验、加范围、加审批、加日志。然后发现，你手搓了一个集成平台，还搓得很烂，没有经过实际集成平台多年的打磨、测试和合规。
那该怎么做？几个实在的建议
MCP 是个好东西，但咱们得拿它当正经的企业集成层来对待，不能凑合。
工具级治理：只暴露每个角色、团队、用户真正需要的工具。不是全量，而是精心设计的、有意识的工具界面。
身份感知执行：Agent 的每个动作都要关联到真实的用户身份，强制走他的权限，留下完整的审计日志。别搞服务账号的捷径，别搞模糊的身份验证。
破坏性操作的护栏：高风险操作（批量更新、删除、改权限、动钱）必须走人工审批。Agent 提建议，人来点确认。
统一的控制平面：一个地方管所有 MCP 连接的策略、监控、治理。不要分散配置，不要每个 Agent 自己定规则。集中、一致、可审计。
Agent 专业化：别再让你那个聊天的通用 Agent 去当数据分析师了。把数据密集的任务分给专门构建的 Agent，它能真正查询、计算、验证。组一个 Agent 网络，各司其职，权限得当。
有范围的工具发现：Agent 只能发现它被授权使用的工具。别再出现 403 荒地，别再浪费循环。Agent 能看到就能调用，看到不了的就别让它看见。
小结
MCP 确实是个有变革意义的协议，可以说是 Agent AI 世界的 USB-C。但 USB-C 也得配个电源控制器，不然笔记本电脑能把你手机烧了。
MCP 同样需要治理，不然 Agent 能把你业务烧了。真正能跑过演示阶段的架构，不是谁连得最快、连得最多，而是建立在有管理的基础之上——每个 Agent 都有边界，每个操作都可审计，每个工具界面都是经过思考的。
PS: 作译者互助群中的作品推荐——
【关联阅读】
什么可能会定义人工智能的下一个十年？
拆解OpenAI最大对手的杀手锏：为什么会是MCP？
大模型应用系列：两万字解读MCP
MCP规范完整中译稿：2025-3-26版
全网首发：MCP 的10种架构模式
A2A 的Java 实现
让你的服务变成MCP Server？FastAPI MCP 指南
在大模型应用中使用长短记忆： OpenMemory MCP
开发MCP服务，何时使用工具？何时使用资源？
当Semantic Kernel 遇上MCP......
Pydantic AI与MCP相逢
万字解读：8种常见框架，选择哪一种来开发MCP呢？
采用LangGraph集成多个MCP服务器的应用
当RAG遇上MCP...
全网首发：安全性问题，使MCP成为AI应用的双刃剑，如何化险为夷呢？
智能体间协作的"巴别塔困境"如何破解？解读Agent通信4大协议：MCP/ACP/A2A/ANP
