你不用急着上MCP!3步选对AI工具路线,效率翻倍少踩3年坑:588分热帖揭秘

你好，欢迎关注「AI工程手记」。

这里主要分享 AI 工程、Agent、自动化工作流和开源项目实战。

不讲太多概念，重点是怎么做、怎么用，趟过哪些坑。

选协议，押的是未来三年的技术路线。

先说结论：

工具接多了，调试到头疼、出了事查不到源头、换个框架全部重来——这是很多团队给 AI Agent 接工具时最真实的困扰。选错协议路线，浪费的不是一个周末，是未来两三年的技术债。

MCP 这个协议，眼下正处在最吵也最关键的时刻：一边是 OpenAI 同周重注，上线官方仓库把 MCP 塞进 ChatGPT 插件体系当一等公民；一边是黑客新闻上一篇 588 分、331 条评论的雄文，把 MCP 的老账全翻了出来。

最有意思的是，写这篇雄文的人，恰恰是圈内最著名的 MCP 反对者——他们曾经在自己产品的首页挂出「我们不支持 MCP」的宣言，最后还是亲手把 MCP 装回了产品核心。

反对者回头，支持者加注，这场标准之争基本到了摊牌时刻。

这篇文章会按 6 个问题讲清楚：MCP 之争到底在吵什么 / 各方押了什么注 / 怎么影响你的选型 / 你的 Agent 到底该不该上（附 3 步判断清单和 4 条不用 MCP 的替代路线）。

一、发生了什么

先把时间线摆出来。

9 月 29 日，OpenAI 上线了官方仓库 mcp-extensions，简介只有一句话：「构建用起来像 ChatGPT 原生功能的插件」。上线两天，462 颗星。明眼人都看得出来，这不是玩票——OpenAI 是要把 MCP 从「开发者协议」升格为「插件生态的底层标准」。

同一周，黑客新闻头版挂着一篇 588 分的雄文，标题叫《You said no MCP!》，331 条评论吵了整整两天。

这篇文章的作者背景有点特殊。他们做的是一个叫 Pi 的 Agent 产品，过去凡是播客访谈、技术文章，你能反复听到他们对 MCP 的嫌弃。官网首页甚至挂着一句骄傲的宣言：Pi 不支持 MCP。

结果这一次，他们官宣：Pi 的最新版本，MCP 成了核心支持的功能。

标题那句「You said no MCP!」，与其说是控诉，不如说是自嘲——骂了两年，最后还是真香了。

我在评论区泡了半小时，感受很直观：这不是一次反转打脸的爽文，而是一次非常认真的工程复盘——一个坚定的反对者，是在什么条件下、经过哪些权衡，才决定拥抱自己曾经反对的东西。这种内容比单纯的赞美或抨击值钱得多。

二、为什么重要

你可能会想，协议之争是巨头和框架作者的事，跟我一个做应用的有什么关系。

关系大了。

第一，MCP 已经不是「开发者协议」，而是正在变成普通人也会被卷进去的基础设施。就看这一周的 GitHub：有把 MCP 接进工业 CAD 软件 SolidWorks 的项目（380 颗星，AI 助手可以直接驱动画草图、倒角、导出模型）；有把 ChatGPT 变成本地 Agent 运行时的项目（240 颗星）；还有支持 MCP 调用的个人知识库（497 颗星）。

工具一旦都用这套协议说话，你的 Agent 能不能听懂，就成了选型问题。

第二，国内外的温差本身就是信号。B 站上「MCP 协议」的教程已经多到刷不完：尚硅谷的实战指南 41.7 万播放，马克的技术工作坊的终极指南 29.9 万播放，北大李晓华的新教程也在持续出。国际社区在激烈争论「该不该用」，中文社区在埋头学「怎么用」。

不对，应该说得更准确一点：两边其实都没错。学的人拿到的是当下的饭碗，吵的人争的是未来三年的生态位。但如果你只学不吵，就很容易在标准转向时白白浪费力气——想想 2015 年多少人熬夜背的框架，现在连文档都找不到了。

第三，这背后是平台权力的博弈。OpenAI 把 MCP 捧起来，本质是想让 ChatGPT 插件成为事实标准入口；而社区的疑虑在于，一个由单一巨头主导的协议，会不会让所有人的工具生态都变成它的附庸。眼下 FTC 刚对包括 OpenAI、Anthropic 在内的 AI 巨头开启调查，这个大背景下，协议之争就不只是技术问题了。

对已经上了 MCP 的团队，这次雄文同样有价值：它点名了服务端实现的通病——只会在上下文里堆工具、靠返回纯文本来省成本。如果你的 MCP 服务端还在这么干，优先把返回值改成结构化数据、给工具配上像样的文档描述，这两处改动的收益立竿见影，Agent 的调用准确率和轮次消耗都会明显改善。协议没换，体验先上一个台阶。

三、影响分析

那篇雄文里最值得记的，是反对者回头的两个理由，它们恰好说清了 MCP 真正的软肋和变化。

软肋一：难组合。传统用法里，工具被一股脑塞进模型的上下文，Agent 每调一次工具都来回消耗轮次。雄文作者的评价很扎心：问题一半在协议本身，另一半在生态里那些「只会在上下文里堆工具、靠返回文本来省成本」的服务端实现。

软肋二：暴露面。工具越多、跨机器越多，你的审计和安全边界就越难画。一个内网用得好好的 Agent，接上十几个外部工具源，出了事你都不知道该查谁。

但变化也是真的。作者承认，今天的 MCP 已经不是去年的 MCP——工具返回结构化数据、按文档智能发现工具这些改进，让它更像一个「带智能发现的开放接口规范」。所以他们没有硬扛，而是换了个方式接纳：在自家产品里搞了一个叫 Codemode 的沙箱，让 Agent 用一段小程序把多次工具调用编排起来，状态跟会话走而不是跟文件系统走，把组合难题和信任边界一起解决。

看明白了吗？高手的做法从来不是站队或者抵制，而是把协议装进自己的架构约束里，为我所用。

对普通开发者，影响可以概括成一句话：上不上 MCP，正在从一个「技术品味问题」变成一个「生态位选择问题」。跟对了省三年力气，跟错了多还三年技术债。

四、各方观点

OpenAI 阵营：动作最实在，直接给了官方仓库和插件框架，口号是「像原生功能一样的插件体验」。押注逻辑很清晰——插件生态繁荣，ChatGPT 就从聊天工具变成平台。

反对者转化的务实派（也就是雄文作者）：结论是有条件的接纳。他们的原话大意是：与其在场边看着，不如参与进去，把它塑造成对小体量工具友好的样子。

工业落地派：SolidWorks 那个项目的用户评论很有代表性——设计师不在乎协议叫什么，只在乎「我说一句『把这个零件倒个角』，软件真的动了」。

中文社区：学习热情高涨，但深度讨论偏少。知乎热榜今天 AI 相关只有两条，MCP 没上榜。

我前阵子的经历可以补充一个视角：帮朋友的团队接两个内部工具到他们的客服 Agent 上，工具全在内网、总共不到十个。当时团队里有人提议上 MCP，理由是「以后扩展方便」。最后我们没上，直接写了函数调用，两天上线，比原计划省了至少一周的联调时间，至今没觉得少了什么。工具数量和共享需求，才是决定性变量，不是潮流。

给个量化的参考：同样接 5 个内部工具，直写函数调用大约 2 天搞定；上 MCP 要搭服务端、配握手、逐个调试，顺利也要 1 到 2 周，后续每次加工具还有固定的接入成本。对工具少于 10 个的团队，这笔账怎么算都不划算。

谁适合读这篇：每天跟 AI 工具、自动化工作流打交道的开发者和团队负责人，尤其是正打算「标准化」工具接入的人——这篇能帮你先算清要不要标准化的账。

五、我的判断

落到操作层面，给你一份 3 步判断清单，10 分钟出结论。

第一步，数工具。你的 Agent 现在和可预见的一年里，要接的工具少于 10 个吗？是 → 记 1 分。

第二步，看边界。这些工具是不是全部在你控制的内网或同一台机器上，不跨团队、不跨机器共享？是 → 再记 1 分。

第三步，查审计。你有没有严格的合规审计要求，需要每一次工具调用都有统一出口可回溯？没有 → 再记 1 分。

打分之前，说个判断时的常见坑：别把「以后可能会接很多工具」当成现在的理由。选型要按当下 12 个月内确定要接的数量算，未来焦虑是技术选型里最贵的成本——真到工具多起来那天，再迁移也来得及，迁移成本远低于一开始就背上一套用不上的协议。

3 分：别上 MCP，直接函数调用，简单、快、好调试。1 到 2 分：混合方案，核心工具直连，长尾工具走网关聚合。0 分：认真评估 MCP，你已经站在它真正适用的场景里——工具多、跨机器、跨团队，还想要标准化的接入和退出方式。

就这么简单。

如果判断结果是「暂时不用」，给你 4 条替代路线：

路线一，直写函数调用。所有大模型原生支持，工具少的时候这是最不折腾的方案。

路线二，文件约定。给 Agent 一个目录，约定好哪些文件是「能力说明书」，Agent 自己读自己懂。适合个人和两三人的小团队，维护成本几乎为零。

路线三，本地网关聚合。工具多了以后，在本地起一个网关进程统一管理，Agent 只面对一个入口。相当于自己造了一个迷你协议，好处是完全可控。

路线四，垂直集成。像 SolidWorks 那样，针对一个具体软件深挖，把体验做到极致。协议是什么不重要，用户爽不爽才重要。

我的立场说清楚：MCP 不是坏东西，它在「跨机器、跨团队共享工具」的场景里是眼下最不坏的标准。但多数个人和小团队的 Agent，工具就那么几个，全在自己机器上——这时候上 MCP 不是先进，是给自己找事。

六、值得关注的方向

往后看半年，三件事比站队更值得盯。

一是 Codemode 这类「沙箱编排」思路会不会成为标配。它绕开了 MCP 最大的组合难题，而且和具体协议无关——如果你在选 Agent 框架，优先看有没有类似能力。

二是 OpenAI 插件生态的开放程度。mcp-extensions 现在 462 颗星还只是起点，真正的问题是要不要入场：等它长成事实标准再跟随，成本会高；现在跟进，赌注又太大。我的建议是先做「兼容层」而不是「深度绑定」，进可攻退可守。

三是中文社区什么时候开始「吵」。哪天知乎热榜出现一篇认真拆解 MCP 架构缺陷的高赞回答，说明国内的选型讨论成熟了。在那之前，教程照学，架构决策照自己的清单走。

标准之争最忌讳的就是情绪化站队。协议是拿来用的，不是拿来信仰的。

再补一段实操细节，讲讲清单里 1 到 2 分的「混合路线」怎么落地，这是最多人卡住的地方。核心思路是分层：高频、核心的工具（比如查订单、改库存）直写函数调用，延迟低、调试直接；低频、长尾的工具（比如每月用一次的报表导出）统一挂到本地网关后面，网关负责转发和记录日志。这样你日常 90% 的调用走最快的路，剩下 10% 慢一点也无妨，而且每一次调用都有日志可查——审计这条腿也顺便保住了。落地成本比全面上 MCP 低一个量级，改动空间还留在自己手里。

最后说一句适用边界：这份判断清单针对的是「自用 Agent」的选型。如果你做的是对外产品、要接第三方生态，标准兼容性权重会大幅上升，那是另一套算法了。

原文：https://earendil.com/posts/you-said-no-mcp/^[1]

仓库：https://github.com/openai/mcp-extensions^[2]

Stars：462 ⭐ （截至 2026-10-01）

一句话总结：工具少、全内网、无强审计 → 别上 MCP，函数调用直接写；工具多、跨机器、跨团队 → 再认真考虑，并且优先配上沙箱编排能力。

你的 Agent 现在接了几个工具？评论区聊聊你的选型，下期想看哪个协议或框架的拆解也可以留言。

这里是「AI工程手记」。

我会持续更新 AI 工程、Agent 工作流、自动化实战和开源项目观察。

关注 AI 工程怎么真正跑起来。

引用链接