GitHub 扩展远程 MCP 的血泪史：越强的 AI 系统，越容易被拖垮

GitHub 在扩展自家远程 MCP Server 时，踩到的坑远比“模型不够聪明”要多。上下文爆炸、工具频繁失败、安全像幽灵一样缠身——Sam Morrow 用一场演讲揭开了一个反直觉真相：真正限制 AI 系统规模的，往往不是模型能力，而是工程现实。

所有人都在堆能力，GitHub 却先被“上下文”打懵了

在这场分享里，最让人意外的不是 GitHub 用了什么新模型，而是他们很早就意识到：上下文正在成为扩展 MCP 的最大敌人。MCP 的初衷是让模型通过工具访问更广阔的世界，但现实是——工具一多，提示词一长，系统就开始变得又慢又不稳定。

Sam Morrow 提到，GitHub 在公开推进 MCP 之后，很快发现“把所有东西都塞给模型”根本行不通。理论上，模型应该能自行选择有用的工具；但在真实使用中，大多数用户并不会精细设计提示词，模型也经常被无关上下文干扰。这不是单纯的使用问题，而更像是一个“半个规范问题”：我们对模型能理解多少，其实高估了。

这也解释了为什么像 LangChain 这样的工具框架会频繁出现在讨论中——它们不是在解决模型能力，而是在帮工程师对抗失控的上下文规模。

工具失败不是 bug，而是规模化的必然结果

另一个被反复强调的现实是：当 MCP 从实验走向真实用户，工具失败会从“偶发事件”变成“日常状态”。Sam 直言，他们不得不投入大量精力去减少 tool failures，而这本身几乎可以单独做一场演讲。

在小规模 demo 中，工具调用失败往往可以忽略；但在 GitHub 这种量级下，每一个失败都会被指数级放大，直接影响用户对 AI 系统的信任感。更残酷的是，很多失败并不是代码错误，而是模型“选择错了工具”或“在错误时间调用了正确工具”。

这也让 GitHub 在设计 MCP 时逐渐转向更保守的策略：不是让模型“想用什么就用什么”，而是通过更明确的 tool set 管理、甚至一定程度的限制，来换取整体稳定性。这里的潜台词很清楚——自由度越高，规模化越痛苦。

安全不是功能，而是一种持续存在的“威胁模型”

如果说上下文和工具失败是工程问题，那安全就是一只永远不会消失的幽灵。Sam 用了一个很形象的说法：安全是一种“constant menace”。当 MCP 能访问代码、服务甚至企业内部资源时，任何一个设计疏忽都会被放大成风险。

GitHub 的做法并不是追求一次性“绝对安全”，而是不断调整安全姿态，让系统在实验和防护之间保持张力。这包括更容易审计的日志、更严格的权限边界，以及在企业场景下对功能做“减法”。

一个值得注意的信号是：他们越来越强调让登录、权限管理变得简单而可控。这意味着，未来的 MCP 设计里，安全不会是附加模块，而是架构的起点。

真正的教训：MCP 的难点不在 AI，而在工程自律

整场演讲听下来，有一个反复出现的主题：GitHub 并没有被“更强模型”拯救，而是被更谨慎的工程决策救了一次又一次。从上下文削减，到工具治理，再到安全边界，这些选择看起来都不性感，却决定了 MCP 能不能活下来。

Sam 甚至暗示，很多团队之所以在 MCP 上受挫，并不是技术不行，而是太快相信模型能“自己搞定一切”。GitHub 的经验恰恰相反：你必须替模型提前做出大量约束，系统才能在规模化时保持理智。

总结

GitHub 扩展远程 MCP Server 的经历，给所有 AI 从业者敲了一个现实的警钟：当系统开始走向规模，真正拖慢你的往往不是模型能力，而是上下文、工具失败率和安全边界。对开发者来说，下一步不是盲目加功能，而是学会做减法——减少上下文、限制工具自由度、把安全当成默认前提。一个值得思考的问题是：如果你的 AI 系统明天用户量翻十倍，它会先崩在哪？

关键词： GitHub， MCP， AI 工程， 上下文管理， LangChain

事实核查备注： 需要核查：GitHub MCP 项目公开时间（提到为去年4月）；Sam Morrow 的具体表述是否为原话或意译；LangChain 在该演讲中的引用语境；关于工具失败与安全的描述是否为总结性转述而非直接引用。