編輯 | 云昭

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

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

圖片

這篇文章標(biāo)題為：《Tools：Code is all your need》。文中，作者開(kāi)門見(jiàn)山的指出自己不是 MCP 的忠實(shí)擁躉，并認(rèn)為 MCP 現(xiàn)在的宣傳言過(guò)其實(shí)。

圖片

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

基于此，MCP 的可擴(kuò)展性，變成了一個(gè)很大的問(wèn)題。沒(méi)有可擴(kuò)展性，就不能自動(dòng)化。

進(jìn)而，作者提出了一種Agentic Coding場(chǎng)景下的可擴(kuò)展的方式：代碼生成 + 評(píng)審 + 批量運(yùn)行。

網(wǎng)友看罷，大多表示贊同。“如今的 LLM 有點(diǎn)像3D打印機(jī)，無(wú)論是炒作還是實(shí)用性方面。”

在某種程度上，我現(xiàn)在把 LLM 看作是“3D 打印機(jī)”——不管是炒作程度還是實(shí)用性都很相似。它們?cè)诳焖龠B接模塊方面表現(xiàn)出色，就像 3D 打印在快速原型制造中一樣。

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

圖片

此前，小編有報(bào)道過(guò) MCP 存在的一些安全問(wèn)題，但回到其本身所有達(dá)到的效果而言，究竟還有哪些挑戰(zhàn)呢？如何看待未來(lái)大模型、Agentic AI 的走向呢？相信本篇文章能給大家啟發(fā)。建議大家收藏細(xì)品。

1.開(kāi)源大佬：“我不是MCP的擁躉”

如果你有關(guān)注我在 Twitter 上的動(dòng)態(tài)，你會(huì)知道我現(xiàn)在并不是 MCP（Model Context Protocol）的忠實(shí)擁躉。并不是我不喜歡這個(gè)理念，而是我發(fā)現(xiàn)它的實(shí)際效果遠(yuǎn)未達(dá)到宣傳中的那樣。在我看來(lái)，MCP 存在兩個(gè)主要問(wèn)題：

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

一個(gè)簡(jiǎn)單的實(shí)驗(yàn)就能看出問(wèn)題：試著用 GitHub 的 MCP 工具完成一個(gè)任務(wù)，然后用 gh 命令行工具再做一遍。你幾乎一定會(huì)發(fā)現(xiàn)后者的上下文使用效率更高，也能更快地得到你想要的結(jié)果。

2.但，MCP 是不是未來(lái)？至少編碼場(chǎng)景下，并不是

我想回應(yīng)一些人對(duì)我上述觀點(diǎn)的反饋。

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

我目前的看法是：從數(shù)據(jù)來(lái)看，現(xiàn)階段的 MCP 在使用難度上幾乎始終高于直接寫代碼，主要因?yàn)樗^(guò)度依賴推理。

你看看當(dāng)下各種擴(kuò)展工具數(shù)量的方案，無(wú)一例外都引入了“篩選層”：你把所有工具喂給 LLM，然后讓它基于任務(wù)從中選出一個(gè)。這類方案目前還沒(méi)有更優(yōu)的替代品。

我也傾向認(rèn)為，就算是非編程類的特定領(lǐng)域任務(wù)，用 MCP 也并不劃算，因?yàn)?/span>代碼生成依舊是組合性更強(qiáng)、驗(yàn)證性更高的方式。

3.用 Shell 腳本替代你自己

可以換個(gè)方式思考這個(gè)問(wèn)題：

在沒(méi)有 AI 的時(shí)代，作為工程師解決問(wèn)題的工具就是代碼；如果你不是程序員，那代碼對(duì)你來(lái)說(shuō)可能是遙不可及的。

但現(xiàn)實(shí)中，很多日常重復(fù)性的任務(wù)，其實(shí)都可以被自動(dòng)化。問(wèn)題是，你未必能找到程序員為你定制工具，也未必愿意自己學(xué)會(huì)編程。

也許你的任務(wù)需要推理，但并不是每一步都需要。我們常說(shuō)“用 shell 腳本替代自己”，因?yàn)檫@就是自動(dòng)化的本質(zhì)。而如今，有了 LLM，新的替代邏輯是“用 LLM 替代自己”。

但這帶來(lái)三個(gè)問(wèn)題：成本、速度和可靠性。這三者是我們?cè)谡務(wù)摴ぞ哒{(diào)用或 MCP 之前必須優(yōu)先解決的問(wèn)題。我們需要確保自動(dòng)化流程在規(guī)模化運(yùn)行時(shí)依舊是正確的。

4.可擴(kuò)展的自動(dòng)化的可行方案

自動(dòng)化的真正價(jià)值，在于那些會(huì)反復(fù)出現(xiàn)的任務(wù)。沒(méi)人會(huì)去自動(dòng)化一次性的操作，自動(dòng)化是為了把一件事情做一次之后交給機(jī)器去重復(fù)上千次。要做到這點(diǎn)，使用代碼始終是更具優(yōu)勢(shì)的方式。

用推理去做小任務(wù)也許能成功，但驗(yàn)證過(guò)程所耗的時(shí)間可能和你自己做一遍差不多。相比之下，讓 LLM 生成一段 Python 代碼去計(jì)算，就更具確定性。為什么？因?yàn)槟憧梢詫彶樗鼘懙墓剑皇遣聹y(cè)計(jì)算結(jié)果是否正確。

不僅如此，你還能請(qǐng)另一個(gè) LLM 審查前者寫的代碼。這種代碼生成 + 評(píng)審 + 批量運(yùn)行的閉環(huán)，是當(dāng)前推理主導(dǎo)流程做不到的。

5.舉個(gè)例子：博客格式轉(zhuǎn)換

比如這篇博客，我最近才把它從 reStructuredText 格式轉(zhuǎn)為 Markdown。我拖延了很久，部分原因是懶，部分是因?yàn)槲?/span>不信任 LLM 會(huì)完整正確地進(jìn)行轉(zhuǎn)換。如果它在中途用完了上下文，可能會(huì)開(kāi)始“幻覺(jué)”，甚至改動(dòng)原文的表述。

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

我讓 LLM 把 reStructuredText 解析成 AST（抽象語(yǔ)法樹(shù)），再轉(zhuǎn)換成 Markdown 的 AST，最后渲染成 HTML。然后我請(qǐng)它寫了一個(gè)腳本，比較轉(zhuǎn)換前后的 HTML 差異，自動(dòng)清理一些無(wú)關(guān)因素（比如 footnote 渲染差異），再分析哪些差異是可接受的。

最終我跑了幾十輪，先用 10 篇測(cè)試，差異減少后再跑完全部?jī)?nèi)容。整個(gè)過(guò)程只用了 30 分鐘左右。

最關(guān)鍵的是，我信任這個(gè)流程的原因，是我能看到、能檢查它的操作。

甚至，我還能請(qǐng)另一個(gè) LLM 審查第一位 LLM 的代碼。這讓我確信不會(huì)出現(xiàn)數(shù)據(jù)丟失或結(jié)構(gòu)回退的問(wèn)題。

而且，推理的成本是穩(wěn)定的，不隨文檔數(shù)量成倍增長(zhǎng)。你分析 15 篇還是 150 篇，最終 diff 腳本工作量差不多。

6.MCP 做不到這些事

說(shuō)了這么多，我其實(shí)只是想表達(dá)一個(gè)核心觀點(diǎn)：整個(gè)轉(zhuǎn)化過(guò)程都是通過(guò)代碼完成的。

這個(gè)流水線其實(shí)就是：

人類給出目標(biāo) → 生成代碼 → LLM 審核 → 反復(fù)迭代。

這個(gè)結(jié)構(gòu)幾乎可以泛化到所有其他通用自動(dòng)化任務(wù)上。舉個(gè)例子，你可能會(huì)使用的某個(gè) MCP 工具是 Playwright。

但我發(fā)現(xiàn)，在很多場(chǎng)景下，用代碼來(lái)替代 Playwright 的調(diào)用其實(shí)是非常困難的，因?yàn)樗举|(zhì)上是在遠(yuǎn)程控制你的瀏覽器。

你給它的任務(wù)通常包括：讀取頁(yè)面、理解頁(yè)面內(nèi)容、點(diǎn)擊“下一步”按鈕……

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

但如果你已經(jīng)知道頁(yè)面內(nèi)容——比如你在操作自己正在開(kāi)發(fā)的 App ——那就可以讓它寫一個(gè) Playwright 的 Python 腳本來(lái)跑這個(gè)流程。

這個(gè)腳本可以順序執(zhí)行多個(gè)步驟，幾乎不需要推理。我發(fā)現(xiàn)這種方式運(yùn)行更快、出錯(cuò)更少，因?yàn)樗斫獾氖悄阕约旱拇a。

它不需要實(shí)時(shí)地去判斷按鈕在哪、輸入框在哪，而是一次性生成一整個(gè)自動(dòng)化流程。

而且這個(gè)過(guò)程是可復(fù)用的：腳本寫好之后，我可以執(zhí)行 100、200，甚至 300 次，而不需要任何額外的推理開(kāi)銷。

這正是 MCP 工具難以提供的巨大優(yōu)勢(shì)。

要讓 LLM 理解抽象、通用的 MCP 調(diào)用非常困難。我多希望可以直接把 MCP 客戶端嵌進(jìn) shell 腳本里，通過(guò)代碼生成高效調(diào)用遠(yuǎn)程服務(wù)。

但現(xiàn)實(shí)是，這些 MCP 工具根本不是為了“無(wú)推理自動(dòng)化”而設(shè)計(jì)的，所以實(shí)現(xiàn)起來(lái)極其困難。

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

我可以手動(dòng)運(yùn)行、調(diào)試一個(gè)腳本，但我連怎么可靠地調(diào)用 MCP 工具都搞不明白。每次都像在賭運(yùn)氣，難以調(diào)試。

相比之下，我更喜歡 Claude Code 在生成代碼時(shí)順便產(chǎn)出的那些小工具，有些我已經(jīng)長(zhǎng)期加入自己的開(kāi)發(fā)流程中。

7.我們會(huì)走向哪里？這是一個(gè)思考的關(guān)鍵時(shí)刻

說(shuō)實(shí)話，我也不知道。但我覺(jué)得，這是一個(gè)值得思考的關(guān)鍵時(shí)刻：我們?cè)撛趺锤倪M(jìn)代碼生成，從而真正為“agentic coding”（智能體式編程）賦能？

說(shuō)來(lái)奇怪，MCP 在成功運(yùn)行用的時(shí)候其實(shí)挺不錯(cuò)的。但它現(xiàn)在的形式給人的感覺(jué)太像死胡同了 —— 特別是在規(guī)模化自動(dòng)化任務(wù)中，因?yàn)樗?/span>對(duì)推理依賴太強(qiáng)，幾乎沒(méi)法擴(kuò)展。

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

理想的模式是：讓 LLM 盡可能生成大量代碼，然后在執(zhí)行完之后，再用 LLM 來(lái)做判斷和優(yōu)化。

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

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

只要你讓 LLM 寫代碼，它的能力還遠(yuǎn)遠(yuǎn)沒(méi)有被發(fā)揮出來(lái)。

8.寫在最后：LLM 編程存在的問(wèn)題

文章到這里就結(jié)束了。不過(guò)正如開(kāi)頭所說(shuō)，作者 Ronacher 在今天的 X 上建議一位粉絲去讀一讀另一位大佬 Mario Zechner 的博客文章。

小編翻閱了一下，的確 Mario 更進(jìn)一步的表述了對(duì)于 Coding 場(chǎng)景而言，現(xiàn)有編程 AI 產(chǎn)品的不足，讓程序員用自然語(yǔ)言編程 LLM，多少有些：宰牛用了殺雞刀！

作為程序員，我們已經(jīng)習(xí)慣用編程語(yǔ)言表達(dá)精確意圖。與 LLM 互動(dòng)時(shí)，別因?yàn)樗恰白匀徽Z(yǔ)言”就放棄結(jié)構(gòu)化思維。我們需要一種橋梁思維：把“聊天”變成“建模”。

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

總結(jié)下來(lái)，AI 編程目前存在兩種嚴(yán)峻的問(wèn)題：一、上下文不夠。二、大模型品味也不夠。

首先，對(duì)于大型代碼庫(kù)來(lái)說(shuō)，主要的問(wèn)題就是上下文不夠用。這些 AI 工具并不能理解你整個(gè)項(xiàng)目的全貌。要么是你沒(méi)提供整體信息，要么就是它們的上下文窗口太小，放不下各個(gè)模塊之間的連接關(guān)系。但問(wèn)題遠(yuǎn)不止于此。

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

一旦超出線性腳本的范疇，它們就徹底迷路：比如涉及多進(jìn)程、進(jìn)程間通信（IPC）、客戶端-服務(wù)器架構(gòu)，或者同一進(jìn)程里的并發(fā)執(zhí)行。

即使你設(shè)法把所有相關(guān)上下文塞進(jìn)模型，它們生成的代碼也常常和你實(shí)際的系統(tǒng)架構(gòu)不匹配。

其次，LLM 還缺乏“品味”。它們?cè)谟?xùn)練時(shí)吃進(jìn)了整個(gè)互聯(lián)網(wǎng)（可能還有一些私有代碼），最終生成的代碼，簡(jiǎn)單說(shuō)就是統(tǒng)計(jì)意義上的平均值。如果任由它自由發(fā)揮，你會(huì)得到一堆難維護(hù)、難理解、漏洞百出的代碼。

而資深工程師追求的是優(yōu)雅、簡(jiǎn)潔、可維護(hù)性高的解決方案，這能減少 bug 和復(fù)雜性。

篇幅關(guān)系，這里就不再展開(kāi)介紹了，可以下篇繼續(xù)為大家解讀。

最根本的原因，還是現(xiàn)在的大模型在Coding工程場(chǎng)景下是通過(guò)推理和工具調(diào)用完成，而推理過(guò)程中上下文的消耗、不確定性造成了 MCP 這種方式似乎變成無(wú)法完美解決生產(chǎn)環(huán)境的問(wèn)題。更別提自動(dòng)化了！

看來(lái)，LLM短期難以取代程序員又多了一個(gè)理由！

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