为什么MCP正在让LLM变无聊：一位老程序员的反思

在这场直言不讳的演讲中，拥有25年编程经验的Manuel Odendahl提出一个反常识观点：MCP正在让大语言模型失去原本的“魔力”。他结合自己从嵌入式开发到Copilot早期用户的经历，剖析工具调用、工程复杂性与LLM创造力之间的张力。

从“写代码的快乐”到“LLM的魔法时刻”

要理解Manuel为什么会觉得“MCP很无聊”，必须先理解他是谁。他并不是一个突然闯入AI领域的新人，而是一位有着25年经验的老程序员，自嘲已经是“veteran coder”。他做过嵌入式开发、搜索引擎、数据库和大量后端工程，熟悉那些被称为“样板代码”的枯燥工作。正因为如此，当他在2022年接触到GitHub Copilot的alpha版本，并在ChatGPT发布后“决定用LLM完成所有编码”时，那种冲击感尤为强烈。

他在演讲中反复强调，最初使用LLM编程的体验是“magical”。这种魔力并不来自更快地写CRUD，而是来自一种全新的交互方式：你用语言描述意图，模型就能回应、补全、甚至提出你没想到的解决路径。这也是他运营“program with AI”账号、持续分享技巧和发现的原因。换句话说，他珍惜的是LLM作为“语言生产者”的本质，而不是把它们当成又一个API调用器。

工具调用的高光时刻，以及它为何曾经如此迷人

Manuel并不否认工具调用（tool calling）的价值。相反，他明确承认：当你第一次把LLM和几个工具连起来，尤其是你自己写的工具时，那种体验“非常神奇”。原因在于，LLM天生就是语言生产者，而我们已经在文档、示例和代码中教会了它们如何“谈论”工具、参数和调用方式。

问题在于，这种魔法很容易被工程化消耗掉。当MCP（Model Context Protocol）出现后，任何LLM应用都可以接入别人构建的工具生态，看起来是一次标准化的胜利。但Manuel抛出了一个尖锐的问题：当你给一个MCP接入“太多工具”时，会发生什么？他的回答很直接——“It's not great.” 模型要在庞杂的工具空间中做选择，本身就变成了一种负担，而不是能力的放大器。

在他看来，这标志着一个转折点：我们开始用工程便利性，换掉了最初那种探索式、对话式的智能体验。

延迟、参数与90年代工程幽灵的回归

除了工具数量的问题，Manuel点出了一个更实际、也更让人沮丧的体验：延迟。当LLM决定调用一个工具，它必须生成完整、结构化的参数；而工具执行、返回结果，再被模型整合成回答，这个过程可能让用户“等上5分钟”。他的评价很朴素：“that's not great.”

更深层的担忧在于，他觉得这种复杂性似曾相识。为了解决MCP的局限，我们开始讨论约束、schema、参数验证、工程规范——这让他想起了90年代和2000年代的老路：本体论、语义网、图结构、三元组、XML schema。这些技术并非没有价值，但它们往往意味着“lots of boring engineering”。

在Manuel看来，当我们试图用这些手段“驯服”LLM时，实际上是在把一种新范式，硬塞回旧世界的模具里。

也许我们根本不需要那么多MCP

演讲中一个有意思的转折是，Manuel并没有提出某种宏大的替代协议，而是抛出了一系列看似“偷懒”的想法。比如，在调用工具之前，为什么不给用户一个简单的UI，让人来确认或补全意图？他承认这超出了演讲范围，但点到为止，留下了工程之外的想象空间。

更激进的是，他反问：“为什么我们甚至需要MCP？” 通过eval、函数、视图，你已经可以非常快地构建出工具化系统。他用一个夸张但生动的例子说明：你可以“boom”，直接拼出一个完整的CRM，“我甚至都不再需要LLM了”。这句话并不是否定LLM，而是在提醒听众：如果系统已经完全确定性、结构化，那LLM的角色可能已经被消耗殆尽。

这正是他所担心的——我们把LLM用到不再需要它的地方。

递归思维与找回LLM的“Sparkle”

在结尾，Manuel把话题拉回到最初的热情上。他说：“LLMs are absolute magic.” 问题不在于模型能力下降，而在于我们如何使用它们。他鼓励开发者“get used to thinking recursively”，把LLM视为可以参与思考过程本身的系统，而不仅是执行命令的节点。

他还用一个细节来说明LLM的局限与潜力：当模型在使用编辑文件工具时“struggling”，这并不是因为它笨，而是因为我们让一个语言模型去假装成文件编辑器。真正的魔力，来自于让模型做它最擅长的事——理解、生成、重组语言。

他的呼吁很简单，也很个人化：希望听众能“bring back the magic… the sparkle sparkle sparkle”，不要在工程的安全感中，耗尽LLM最初带来的惊喜。

总结

这场演讲的价值，不在于提出一个现成的替代方案，而在于一次来自老程序员的提醒：当我们沉迷于协议、工具和标准化时，可能正在错过LLM真正独特的能力。MCP并非原罪，但如果它让系统变得臃肿、迟缓、缺乏探索性，那么“无聊”就成了警报。对开发者而言，真正的问题或许是：你是在放大LLM的语言智能，还是在把它磨平成另一个后端组件？

关键词： 大语言模型， MCP， 工具调用， ChatGPT， GitHub Copilot

事实核查备注： Manuel Odendahl；AI Engineer频道；2025-06-10；GitHub Copilot alpha（2022）；ChatGPT；Model Context Protocol（MCP）；语义网、本体论、XML schema；原话引用如“It's not great.”、“LLMs are absolute magic.”