今天凌晨易倍策略，知名开源 Web 框架作者 Ronacher 发表了一篇引起热烈反响的博客。虽然他自谦地在X上称这篇“烂文章”，但网友们却非常认同。
这篇文章标题为：《Tools：Code is all your need》。文中，作者开门见山的指出自己不是 MCP 的忠实拥趸，并认为 MCP 现在的宣传言过其实。
此外，Ronacher 指出 MCP 并不具备真正的可组合性，而且依赖且消耗本可以不必如此多的推理上下文，远不如单纯运行代码那么简单。
基于此，MCP 的可扩展性，变成了一个很大的问题。没有可扩展性，就不能自动化。
进而，作者提出了一种Agentic Coding场景下的可扩展的方式：代码生成 + 评审 + 批量运行。
网友看罢，大多表示赞同。“如今的 LLM 有点像3D打印机，无论是炒作还是实用性方面。”
在某种程度上，我现在把 LLM 看作是“3D 打印机”——不管是炒作程度还是实用性都很相似。它们在快速连接模块方面表现出色，就像 3D 打印在快速原型制造中一样。展开剩余90% 但要想实现可靠性和规模化运行，你最终还是希望由 LLM 或工程师来把那个“打印/推理”出来的连接件换成更坚固、更确定的材料（比如金属/代码）——这样才能在大规模下便宜又高效地运行。此前，小编有报道过 MCP 存在的一些安全问题，但回到其本身所有达到的效果而言，究竟还有哪些挑战呢？如何看待未来大模型、Agentic AI 的走向呢？相信本篇文章能给大家启发。建议大家收藏细品。
01 开源大佬：“我不是MCP的拥趸”如果你有关注我在 Twitter 上的动态，你会知道我现在并不是 MCP（Model Context Protocol）的忠实拥趸。并不是我不喜欢这个理念，而是我发现它的实际效果远未达到宣传中的那样。在我看来，MCP 存在两个主要问题：
它并不真正具备可组合性，大部分所谓的“组合”其实是依赖模型的推理完成的； 它对上下文的依赖过重：你需要预先提供大量输入信息，而且每次调用工具时消耗的上下文甚至比你自己写代码还多。一个简单的实验就能看出问题：试着用 GitHub 的 MCP 工具完成一个任务，然后用 gh 命令行工具再做一遍。你几乎一定会发现后者的上下文使用效率更高，也能更快地得到你想要的结果。
02 但，MCP 是不是未来？至少编码场景下，并不是我想回应一些人对我上述观点的反馈。
我主要在 Agentic Coding（智能体式编程）的语境中评估 MCP，而这正是 MCP 弱点最明显的场景。有人指出，MCP 可能并不适合通用代码生成场景——毕竟模型已经很擅长生成代码了——但它在面向终端用户的场景下，比如金融公司中的特定任务自动化，可能更有意义。也有人建议我应该从“未来世界”的视角看问题：届时模型可以调用更多工具，处理更复杂的任务。
我目前的看法是：从数据来看，现阶段的 MCP 在使用难度上几乎始终高于直接写代码，主要因为它过度依赖推理。
你看看当下各种扩展工具数量的方案，无一例外都引入了“筛选层”：你把所有工具喂给 LLM，然后让它基于任务从中选出一个。这类方案目前还没有更优的替代品。
我也倾向认为，就算是非编程类的特定领域任务，用 MCP 也并不划算，因为代码生成依旧是组合性更强、验证性更高的方式。
03 用 Shell 脚本替代你自己可以换个方式思考这个问题：
在没有 AI 的时代，作为工程师解决问题的工具就是代码；如果你不是程序员，那代码对你来说可能是遥不可及的。但现实中，很多日常重复性的任务，其实都可以被自动化。问题是，你未必能找到程序员为你定制工具，也未必愿意自己学会编程。
也许你的任务需要推理，但并不是每一步都需要。我们常说“用 shell 脚本替代自己”，因为这就是自动化的本质。而如今，有了 LLM，新的替代逻辑是“用 LLM 替代自己”。
但这带来三个问题：成本、速度和可靠性。这三者是我们在谈论工具调用或 MCP 之前必须优先解决的问题。我们需要确保自动化流程在规模化运行时依旧是正确的。
04 可扩展的自动化的可行方案自动化的真正价值，在于那些会反复出现的任务。没人会去自动化一次性的操作，自动化是为了把一件事情做一次之后交给机器去重复上千次。要做到这点，使用代码始终是更具优势的方式。
用推理去做小任务也许能成功，但验证过程所耗的时间可能和你自己做一遍差不多。相比之下，让 LLM 生成一段 Python 代码去计算，就更具确定性。为什么？因为你可以审查它写的公式，而不是猜测计算结果是否正确。
不仅如此，你还能请另一个 LLM 审查前者写的代码。这种代码生成 + 评审 + 批量运行的闭环，是当前推理主导流程做不到的。
05 举个例子：博客格式转换比如这篇博客，我最近才把它从 reStructuredText 格式转为 Markdown。我拖延了很久易倍策略，部分原因是懒，部分是因为我不信任 LLM 会完整正确地进行转换。如果它在中途用完了上下文，可能会开始“幻觉”，甚至改动原文的表述。
我最后还是用了 LLM，但用的是另一种方式：让它写代码。
我让 LLM 把 reStructuredText 解析成 AST（抽象语法树），再转换成 Markdown 的 AST，最后渲染成 HTML。然后我请它写了一个脚本，比较转换前后的 HTML 差异，自动清理一些无关因素（比如 footnote 渲染差异），再分析哪些差异是可接受的。
最终我跑了几十轮，先用 10 篇测试，差异减少后再跑完全部内容。整个过程只用了 30 分钟左右。
最关键的是，我信任这个流程的原因，是我能看到、能检查它的操作。
甚至，我还能请另一个 LLM 审查第一位 LLM 的代码。这让我确信不会出现数据丢失或结构回退的问题。
而且，推理的成本是稳定的，不随文档数量成倍增长。你分析 15 篇还是 150 篇，最终 diff 脚本工作量差不多。
06 MCP 做不到这些事说了这么多，我其实只是想表达一个核心观点：整个转化过程都是通过代码完成的。
这个流水线其实就是：
人类给出目标 → 生成代码 → LLM 审核 → 反复迭代。
这个结构几乎可以泛化到所有其他通用自动化任务上。举个例子，你可能会使用的某个 MCP 工具是 Playwright。
但我发现，在很多场景下，用代码来替代 Playwright 的调用其实是非常困难的，因为它本质上是在远程控制你的浏览器。
你给它的任务通常包括：读取页面、理解页面内容、点击“下一步”按钮……
这是典型的每一步都需要推理的场景，很难彻底消除 LLM 推理过程中的不确定性。
但如果你已经知道页面内容——比如你在操作自己正在开发的 App ——那就可以让它写一个 Playwright 的 Python 脚本来跑这个流程。
这个脚本可以顺序执行多个步骤，几乎不需要推理。我发现这种方式运行更快、出错更少，因为它理解的是你自己的代码。
它不需要实时地去判断按钮在哪、输入框在哪，而是一次性生成一整个自动化流程。
而且这个过程是可复用的：脚本写好之后，我可以执行 100、200，甚至 300 次，而不需要任何额外的推理开销。
这正是 MCP 工具难以提供的巨大优势。
要让 LLM 理解抽象、通用的 MCP 调用非常困难。我多希望可以直接把 MCP 客户端嵌进 shell 脚本里，通过代码生成高效调用远程服务。
但现实是，这些 MCP 工具根本不是为了“无推理自动化”而设计的，所以实现起来极其困难。
而且，讽刺的是：我毕竟是人类，不是 MCP 客户端。
我可以手动运行、调试一个脚本，但我连怎么可靠地调用 MCP 工具都搞不明白。每次都像在赌运气，难以调试。
相比之下，我更喜欢 Claude Code 在生成代码时顺便产出的那些小工具，有些我已经长期加入自己的开发流程中。
07 我们会走向哪里？这是一个思考的关键时刻说实话，我也不知道。但我觉得，这是一个值得思考的关键时刻：我们该怎么改进代码生成，从而真正为“agentic coding”（智能体式编程）赋能？
说来奇怪，MCP 在成功运行用的时候其实挺不错的。但它现在的形式给人的感觉太像死胡同了 —— 特别是在规模化自动化任务中，因为它对推理依赖太强，几乎没法扩展。
也许我们应该去寻找一种新的抽象层，重新划分 MCP 和代码生成各自擅长的任务领域。这可能需要我们打造更好的沙盒环境，甚至重新思考如何以更高效的方式暴露 API，让 LLM 在任务执行前可以做一些“分发”和“收敛”的操作（fan out / fan in for inference）。
理想的模式是：让 LLM 尽可能生成大量代码，然后在执行完之后，再用 LLM 来做判断和优化。
我也设想过一个很有意思的方向：让代码生成过程足够透明，便于 LLM 向非程序员用人类语言解释脚本在做什么。如果能做到这点，就有可能让非技术用户也能参与到这类自动化工作流中。
总之，我只想说一句：大家别被 MCP 局限住了，去探索更多可能性吧。
只要你让 LLM 写代码，它的能力还远远没有被发挥出来。
08 写在最后：LLM 编程存在的问题文章到这里就结束了。不过正如开头所说，作者 Ronacher 在今天的 X 上建议一位粉丝去读一读另一位大佬 Mario Zechner 的博客文章。
小编翻阅了一下，的确 Mario 更进一步的表述了对于 Coding 场景而言，现有编程 AI 产品的不足，让程序员用自然语言编程 LLM，多少有些：宰牛用了杀鸡刀！
作为程序员，我们已经习惯用编程语言表达精确意图。 与 LLM 互动时，别因为它是“自然语言”就放弃结构化思维。 我们需要一种桥梁思维：把“聊天”变成“建模”。比如：想想“输入、状态、输出”这些基本组件，而不是“和 AI 聊聊”，你就更接近在“工程化”地使用它，而不是在“碰运气”。
总结下来，AI 编程目前存在两种严峻的问题：一、上下文不够。二、大模型品味也不够。
首先，对于大型代码库来说，主要的问题就是上下文不够用。这些 AI 工具并不能理解你整个项目的全貌。要么是你没提供整体信息，要么就是它们的上下文窗口太小，放不下各个模块之间的连接关系。但问题远不止于此。
即便现在的 LLM 增加了所谓的“推理”能力——其实也就是“逐步思考”这个老把戏，再加上更多的 scratch space（临时记忆空间），它们依然很难真正跟上程序的执行流程。
一旦超出线性脚本的范畴，它们就彻底迷路：比如涉及多进程、进程间通信（IPC）、客户端-服务器架构，或者同一进程里的并发执行。即使你设法把所有相关上下文塞进模型，它们生成的代码也常常和你实际的系统架构不匹配。
其次，LLM 还缺乏“品味”。它们在训练时吃进了整个互联网（可能还有一些私有代码），最终生成的代码，简单说就是统计意义上的平均值。如果任由它自由发挥，你会得到一堆难维护、难理解、漏洞百出的代码。
而资深工程师追求的是优雅、简洁、可维护性高的解决方案，这能减少 bug 和复杂性。
篇幅关系，这里就不再展开介绍了，可以下篇继续为大家解读。
最根本的原因，还是现在的大模型在Coding工程场景下是通过推理和工具调用完成，而推理过程中上下文的消耗、不确定性造成了 MCP 这种方式似乎变成无法完美解决生产环境的问题。更别提自动化了！
看来，LLM短期难以取代程序员又多了一个理由！
大家怎么看呢？MCP 还有哪些使用上的不便呢？欢迎评论区交流易倍策略。
发布于：海南省信钰证券提示：文章来自网络，不代表本站观点。
相关文章
沪深京指数
热点资讯
