編輯 | 云昭

今天凌晨，知名開源 Web 框架作者 Ronacher 發表了一篇引起熱烈反響的博客。雖然他自謙地在X上稱這篇“爛文章”，但網友們卻非常認同。

圖片

這篇文章標題為：《Tools：Code is all your need》。文中，作者開門見山的指出自己不是 MCP 的忠實擁躉，并認為 MCP 現在的宣傳言過其實。

圖片

此外，Ronacher 指出 MCP 并不具備真正的可組合性，而且依賴且消耗本可以不必如此多的推理上下文，遠不如單純運行代碼那么簡單。

基于此，MCP 的可擴展性，變成了一個很大的問題。沒有可擴展性，就不能自動化。

進而，作者提出了一種Agentic Coding場景下的可擴展的方式：代碼生成 + 評審 + 批量運行。

網友看罷，大多表示贊同。“如今的 LLM 有點像3D打印機，無論是炒作還是實用性方面。”

在某種程度上，我現在把 LLM 看作是“3D 打印機”——不管是炒作程度還是實用性都很相似。它們在快速連接模塊方面表現出色，就像 3D 打印在快速原型制造中一樣。

但要想實現可靠性和規模化運行，你最終還是希望由 LLM 或工程師來把那個“打印/推理”出來的連接件換成更堅固、更確定的材料（比如金屬/代碼）——這樣才能在大規模下便宜又高效地運行。

圖片

此前，小編有報道過 MCP 存在的一些安全問題，但回到其本身所有達到的效果而言，究竟還有哪些挑戰呢？如何看待未來大模型、Agentic AI 的走向呢？相信本篇文章能給大家啟發。建議大家收藏細品。

1.開源大佬：“我不是MCP的擁躉”

如果你有關注我在 Twitter 上的動態，你會知道我現在并不是 MCP（Model Context Protocol）的忠實擁躉。并不是我不喜歡這個理念，而是我發現它的實際效果遠未達到宣傳中的那樣。在我看來，MCP 存在兩個主要問題：

1. 它并不真正具備可組合性，大部分所謂的“組合”其實是依賴模型的推理完成的；
2. 它對上下文的依賴過重：你需要預先提供大量輸入信息，而且每次調用工具時消耗的上下文甚至比你自己寫代碼還多。

一個簡單的實驗就能看出問題：試著用 GitHub 的 MCP 工具完成一個任務，然后用 ??gh?? 命令行工具再做一遍。你幾乎一定會發現后者的上下文使用效率更高，也能更快地得到你想要的結果。

2.但，MCP 是不是未來？至少編碼場景下，并不是

我想回應一些人對我上述觀點的反饋。

我主要在 Agentic Coding（智能體式編程）的語境中評估 MCP，而這正是 MCP 弱點最明顯的場景。有人指出，MCP 可能并不適合通用代碼生成場景——畢竟模型已經很擅長生成代碼了——但它在面向終端用戶的場景下，比如金融公司中的特定任務自動化，可能更有意義。也有人建議我應該從“未來世界”的視角看問題：屆時模型可以調用更多工具，處理更復雜的任務。

我目前的看法是：從數據來看，現階段的 MCP 在使用難度上幾乎始終高于直接寫代碼，主要因為它過度依賴推理。

你看看當下各種擴展工具數量的方案，無一例外都引入了“篩選層”：你把所有工具喂給 LLM，然后讓它基于任務從中選出一個。這類方案目前還沒有更優的替代品。

我也傾向認為，就算是非編程類的特定領域任務，用 MCP 也并不劃算，因為代碼生成依舊是組合性更強、驗證性更高的方式。

3.用 Shell 腳本替代你自己

可以換個方式思考這個問題：

在沒有 AI 的時代，作為工程師解決問題的工具就是代碼；如果你不是程序員，那代碼對你來說可能是遙不可及的。

但現實中，很多日常重復性的任務，其實都可以被自動化。問題是，你未必能找到程序員為你定制工具，也未必愿意自己學會編程。

也許你的任務需要推理，但并不是每一步都需要。我們常說“用 shell 腳本替代自己”，因為這就是自動化的本質。而如今，有了 LLM，新的替代邏輯是“用 LLM 替代自己”。

但這帶來三個問題：成本、速度和可靠性。這三者是我們在談論工具調用或 MCP 之前必須優先解決的問題。我們需要確保自動化流程在規模化運行時依舊是正確的。

4.可擴展的自動化的可行方案

自動化的真正價值，在于那些會反復出現的任務。沒人會去自動化一次性的操作，自動化是為了把一件事情做一次之后交給機器去重復上千次。要做到這點，使用代碼始終是更具優勢的方式。

用推理去做小任務也許能成功，但驗證過程所耗的時間可能和你自己做一遍差不多。相比之下，讓 LLM 生成一段 Python 代碼去計算，就更具確定性。為什么？因為你可以審查它寫的公式，而不是猜測計算結果是否正確。

不僅如此，你還能請另一個 LLM 審查前者寫的代碼。這種代碼生成 + 評審 + 批量運行的閉環，是當前推理主導流程做不到的。

5.舉個例子：博客格式轉換

比如這篇博客，我最近才把它從 reStructuredText 格式轉為 Markdown。我拖延了很久，部分原因是懶，部分是因為我不信任 LLM 會完整正確地進行轉換。如果它在中途用完了上下文，可能會開始“幻覺”，甚至改動原文的表述。

我最后還是用了 LLM，但用的是另一種方式：讓它寫代碼。

我讓 LLM 把 reStructuredText 解析成 AST（抽象語法樹），再轉換成 Markdown 的 AST，最后渲染成 HTML。然后我請它寫了一個腳本，比較轉換前后的 HTML 差異，自動清理一些無關因素（比如 footnote 渲染差異），再分析哪些差異是可接受的。

最終我跑了幾十輪，先用 10 篇測試，差異減少后再跑完全部內容。整個過程只用了 30 分鐘左右。

最關鍵的是，我信任這個流程的原因，是我能看到、能檢查它的操作。

甚至，我還能請另一個 LLM 審查第一位 LLM 的代碼。這讓我確信不會出現數據丟失或結構回退的問題。

而且，推理的成本是穩定的，不隨文檔數量成倍增長。你分析 15 篇還是 150 篇，最終 diff 腳本工作量差不多。

6.MCP 做不到這些事

說了這么多，我其實只是想表達一個核心觀點：整個轉化過程都是通過代碼完成的。

這個流水線其實就是：

人類給出目標 → 生成代碼 → LLM 審核 → 反復迭代。

這個結構幾乎可以泛化到所有其他通用自動化任務上。舉個例子，你可能會使用的某個 MCP 工具是 Playwright。

但我發現，在很多場景下，用代碼來替代 Playwright 的調用其實是非常困難的，因為它本質上是在遠程控制你的瀏覽器。

你給它的任務通常包括：讀取頁面、理解頁面內容、點擊“下一步”按鈕……

這是典型的每一步都需要推理的場景，很難徹底消除 LLM 推理過程中的不確定性。

但如果你已經知道頁面內容——比如你在操作自己正在開發的 App ——那就可以讓它寫一個 Playwright 的 Python 腳本來跑這個流程。

這個腳本可以順序執行多個步驟，幾乎不需要推理。我發現這種方式運行更快、出錯更少，因為它理解的是你自己的代碼。

它不需要實時地去判斷按鈕在哪、輸入框在哪，而是一次性生成一整個自動化流程。

而且這個過程是可復用的：腳本寫好之后，我可以執行 100、200，甚至 300 次，而不需要任何額外的推理開銷。

這正是 MCP 工具難以提供的巨大優勢。

要讓 LLM 理解抽象、通用的 MCP 調用非常困難。我多希望可以直接把 MCP 客戶端嵌進 shell 腳本里，通過代碼生成高效調用遠程服務。

但現實是，這些 MCP 工具根本不是為了“無推理自動化”而設計的，所以實現起來極其困難。

而且，諷刺的是：我畢竟是人類，不是 MCP 客戶端。

我可以手動運行、調試一個腳本，但我連怎么可靠地調用 MCP 工具都搞不明白。每次都像在賭運氣，難以調試。

相比之下，我更喜歡 Claude Code 在生成代碼時順便產出的那些小工具，有些我已經長期加入自己的開發流程中。

7.我們會走向哪里？這是一個思考的關鍵時刻

說實話，我也不知道。但我覺得，這是一個值得思考的關鍵時刻：我們該怎么改進代碼生成，從而真正為“agentic coding”（智能體式編程）賦能？

說來奇怪，MCP 在成功運行用的時候其實挺不錯的。但它現在的形式給人的感覺太像死胡同了 —— 特別是在規模化自動化任務中，因為它對推理依賴太強，幾乎沒法擴展。

也許我們應該去尋找一種新的抽象層，重新劃分 MCP 和代碼生成各自擅長的任務領域。這可能需要我們打造更好的沙盒環境，甚至重新思考如何以更高效的方式暴露 API，讓 LLM 在任務執行前可以做一些“分發”和“收斂”的操作（fan out / fan in for inference）。

理想的模式是：讓 LLM 盡可能生成大量代碼，然后在執行完之后，再用 LLM 來做判斷和優化。

我也設想過一個很有意思的方向：讓代碼生成過程足夠透明，便于 LLM 向非程序員用人類語言解釋腳本在做什么。如果能做到這點，就有可能讓非技術用戶也能參與到這類自動化工作流中。

總之，我只想說一句：大家別被 MCP 局限住了，去探索更多可能性吧。

只要你讓 LLM 寫代碼，它的能力還遠遠沒有被發揮出來。

8.寫在最后：LLM 編程存在的問題

文章到這里就結束了。不過正如開頭所說，作者 Ronacher 在今天的 X 上建議一位粉絲去讀一讀另一位大佬 Mario Zechner 的博客文章。

小編翻閱了一下，的確 Mario 更進一步的表述了對于 Coding 場景而言，現有編程 AI 產品的不足，讓程序員用自然語言編程 LLM，多少有些：宰牛用了殺雞刀！

作為程序員，我們已經習慣用編程語言表達精確意圖。與 LLM 互動時，別因為它是“自然語言”就放棄結構化思維。我們需要一種橋梁思維：把“聊天”變成“建模”。

比如：想想“輸入、狀態、輸出”這些基本組件，而不是“和 AI 聊聊”，你就更接近在“工程化”地使用它，而不是在“碰運氣”。

總結下來，AI 編程目前存在兩種嚴峻的問題：一、上下文不夠。二、大模型品味也不夠。

首先，對于大型代碼庫來說，主要的問題就是上下文不夠用。這些 AI 工具并不能理解你整個項目的全貌。要么是你沒提供整體信息，要么就是它們的上下文窗口太小，放不下各個模塊之間的連接關系。但問題遠不止于此。

即便現在的 LLM 增加了所謂的“推理”能力——其實也就是“逐步思考”這個老把戲，再加上更多的 scratch space（臨時記憶空間），它們依然很難真正跟上程序的執行流程。

一旦超出線性腳本的范疇，它們就徹底迷路：比如涉及多進程、進程間通信（IPC）、客戶端-服務器架構，或者同一進程里的并發執行。

即使你設法把所有相關上下文塞進模型，它們生成的代碼也常常和你實際的系統架構不匹配。

其次，LLM 還缺乏“品味”。它們在訓練時吃進了整個互聯網（可能還有一些私有代碼），最終生成的代碼，簡單說就是統計意義上的平均值。如果任由它自由發揮，你會得到一堆難維護、難理解、漏洞百出的代碼。

而資深工程師追求的是優雅、簡潔、可維護性高的解決方案，這能減少 bug 和復雜性。

篇幅關系，這里就不再展開介紹了，可以下篇繼續為大家解讀。

最根本的原因，還是現在的大模型在Coding工程場景下是通過推理和工具調用完成，而推理過程中上下文的消耗、不確定性造成了 MCP 這種方式似乎變成無法完美解決生產環境的問題。更別提自動化了！

看來，LLM短期難以取代程序員又多了一個理由！

大家怎么看呢？MCP 還有哪些使用上的不便呢？

 本文轉載自??51CTO技術棧??，作者：云昭