編輯 | 伊風
出品 | 51CTO技術棧（微信號：blog51cto）
你的 MCP，可能真用錯了？
MCP 常被視作大模型的“USB 接口”。不少開發者第一反應就是：往里堆更多專用工具（grep、sed、tmux……），好像這樣就能讓 AI 更強大。
但在 Hacker News 上，一篇熱帖卻拋出截然相反的結論：
?? 工具越多越亂，MCP 的最優解是——只留一個代碼執行器。
圖片
開發者都知道：命令行工具其實很“脆”。
- 跨平臺/版本兼容性差
- 換行符、特殊字符動不動就出錯
- 會話一亂套，進程直接跑飛
作者敏銳地意識到：這些不是小 bug，而是底層結構性的難題。
所以問題來了：命令行的問題究竟出在哪？為什么答案不是更多小工具，而是一個「超級工具」——一個能直接運行 Python/JS 的解釋器？
1.MCP 調命令行工具為什么總崩？
作者表示，調用命令行工具，最讓人抓狂的是：
AI 一旦出錯，要么推倒重來，要么干脆換別的工具，只因為一個小細節沒處理對。
這背后有兩個明顯的缺陷：
第一，平臺和版本兼容性差。
命令行工具常常依賴具體環境，有時甚至缺乏文檔支持。結果就是——幾乎每次首次調用都會踩坑。
更典型的例子是處理非 ASCII 字符：Claude Sonnet、Opus 有時都分不清該怎么在 shell 里傳遞換行符或控制字符。
這種情況并不少見，C 語言編譯時，末尾常常需要保留一個換行符，而 AI 工具偏偏會在這里卡死，一大堆令人“嘆為觀止”的工具循環來解決。
第二，調用鏈太長，狀態管理困難。
有些智能體（尤其是 Claude Code）在執行 shell 調用前，shell 調用前還會多一道“安全預檢”。Claude 會先用小模型 Haiku 判斷這個調用是不是危險的，再決定要不要執行。
更棘手的是多輪調用。比如讓它用 tmux 遠程控制 LLDB，理論上能行，但它常常“失憶”：半路改掉 session 名字，忘了自己還有會話，也就沒法正常結束任務。
總的來說，命令行工具一旦進入多輪調用場景，穩定性就成了最大軟肋。
而這反而掩蓋了 CLI 工具原本的優勢。
2.命令行的本事在“組合”，而 MCP 正在削弱它
命令行工具本質上不是單一工具，而是一整套可以通過編程語言（bash）組合起來的工具。
在 bash 里，你可以把 grep、awk、sed、tmux 這些小工具接起來，前一個工具的輸出直接作為后一個工具的輸入，一行命令就能解決復雜問題。
這就是命令行的“組合性”。
然而，一旦轉向 MCP，這種無需額外推理的組合就不見了（至少以今天的實現）。
為什么？
因為 MCP 的調用模型是把工具當作黑箱：一次只調一個工具，拿到結果，再進入下一輪推理。
這意味著，AI 想復現 bash 的那種靈活組合，就必須自己重新推理、逐步調用，過程既慢又容易出錯。
一個經典例子是用 tmux 遠程控制 lldb，在 CLI 下，AI 會這樣串：
- 它先用 tmux send-keys 輸入命令
- 再用 tmux capture-pane 抓取輸出
- 甚至會插入 sleep 等待，再繼續 capture，避免過早讀取結果
當它遇到復雜字符編碼問題時，還會換種方式，比如轉成 base64 再解碼。
而在 MCP 下，這個過程會被拆成很多輪，每走一步，每走一步都要重新推理狀態（比如 session 名、斷點位置、上次輸出片段），鏈條任一環掉了就全盤重來。
作者還強調了另一個 CLI 強項：讓 AI 先寫小腳本、再復用、再拼裝，最終長成一套穩定的自動化腳本。
而在 MCP 的黑箱調用里，這種“腳本化+復用”的自增長路徑目前很難自然出現。
3.更好的 MCP 方式
作者的激進方案：別搞幾十個工具，MCP 只要一個“超級工具”。
這個超級工具就是 Python/JS 解釋器，有狀態、會執行代碼。
shell 工具是有極限的，你遲早會陷入和工具“搏斗”的狀態，尤其是當智能體需要維護復雜會話時。
MCP 天生有狀態。一個更實用的思路是：只暴露一個“超級工具”——帶狀態的 Python 解釋器。它通過 eval() 執行代碼并保持上下文，讓智能體用熟悉的方式操作。
作者的實驗是 pexpect-mcp。表面上叫 pexpect_tool，本質上是一個運行在 MCP 服務器端、預裝了 pexpect 庫的持久化 Python 解釋器環境。pexpect 是經典 expect 工具的 Python 移植版，可以腳本化地和命令行交互。
這樣，MCP 服務器變成一個有狀態的 Python 解釋器，它暴露的工具接口非常簡單直接：執行傳入的 Python 代碼片段，并繼承之前所有調用累積的上下文狀態。
工具接口說明大致如下：
在 pexpect 會話中執行 Python 代碼，可啟動進程并與其交互。
參數：
code: 要執行的 Python 代碼。用變量 child 與進程交互。
已導入 pexpect，可直接用 pexpect.spawn(...) 來啟動。
timeout: 可選，超時時間（秒），默認 30 秒。
示例：
child = pexpect.spawn('lldb ./mytool')
child.expect("(lldb)")
返回：
代碼執行結果或錯誤信息這種模式下，MCP 的角色不再是“工具集”，而是代碼執行器，帶來幾個直接好處：
- MCP 負責會話管理和交互
- 智能體寫出的代碼幾乎就是腳本本身
- 會話結束后，可以順手整理成可復用的調試腳本
4.實戰驗證：效率與復用性的飛躍
驗證 pexpect-mcp 的效果，作者用它調試了一個已知會崩潰的 C 程序（demo-buggy）。
過程如下：
- 首次調試 (傳統 MCP 模式模擬)： AI 通過 pexpect_tool 與 LLDB 交互定位崩潰原因（內存未分配、數組越界）。耗時約 45 秒，涉及 7 輪工具調用。
- 腳本化： AI 將整個調試過程自動導出為一個獨立的、可讀的 Python 腳本 (debug_demo.py)。
- 復用驗證： 在全新會話中，僅用 1 次工具調用執行 uv run debug_demo.py。腳本5 秒內復現了崩潰分析，精準定位問題根源。
作者表示，最關鍵的是：這個腳本是獨立的，我作為人類也能直接運行它，甚至完全不依賴 MCP！
pexpect-mcp 的成功案例揭示了一個更普適的 MCP 設計方向：與其暴露一堆零散且易出錯的黑箱工具，不如將編程語言本身作為交互接口。
5.創新：自己手搓小型MCP
MCP 的一個通病是：工具越多，越容易導致上下文腐爛，而且輸入限制很大。
但如果 MCP 暴露的不是一堆工具，而是一門編程語言，那么它就間接開放了模型在訓練中學到的全部能力。
當你要構建一些全新的東西時，至少編程語言是 AI 熟悉的。你完全可以手搓一個小型 MCP，讓它：
- 導出應用的內部狀態
- 提供數據庫查詢輔助（哪怕支持分片架構）
- 提供數據讀取 API
過去，AI 只能靠讀代碼理解這些接口；現在，它還能直接通過一個有狀態的 Python/JavaScript 會話去調用并進一步探索。
更妙的是：這也讓智能體有機會調試 MCP 本身。得益于 Python 和 JavaScript 的靈活性，它甚至能幫你排查 MCP 的內部狀態。
6.網友爭議：AI 應該如何操作代碼？
這篇博客的討論，其實已經觸碰到 AI 編程的底層哲學。
AI 究竟應該如何操作代碼：
是繼續停留在文本層面（字符串），還是通過更結構化的接口來理解與操控？
我們知道，CLI 工具的脆弱性（換行符出錯、會話管理混亂）本質上就是基于字符串操作的局限。
那么問題來了：如果 AI 寫“真代碼”更好，是不是要再進一步，讓它理解 AST？注：AST（抽象語法樹）：是一種將代碼轉化為樹狀結構的表示方式。每個節點代表變量、函數或語句。 對編譯器和 IDE 來說，AST 是比純文本更精準的結構化接口。
有網友認為：
編輯器本該更多利用語言服務器等結構化能力，而不是讓智能體在 grep、sed、awk 這些老舊工具上兜圈子。而且對大多數語言來說，操作的也不應該是字符串，而應該是 token 流和 AST。
圖片
另一派則指出：
現實決定了 AI 還是更適合操作代碼本身：同意現在的工具使用方式效率低，但 AI 主要還是操作代碼而不是語法樹，有幾個原因：
- 訓練集里代碼遠遠多于語法樹。
- 代碼幾乎總是更簡潔的表示形式。
過去有人嘗試用圖神經網絡或 transformer 來訓練 AST 邊信息，但要想超過主流 LLM 可能需要重大突破（和巨額資金）。 實驗表明讓智能體用 ast-grep（語法感知的搜索替換工具）效果不錯，本質上還是把一切當作代碼，但用語法感知的方式來替換。
圖片
還有人強調了 字符串的普適性：
字符串是無依賴的通用接口。你可以跨任意語言、跨任意文件完成幾乎任何事。其他抽象反而會嚴重限制你能做到的事情。 另外，大語言模型（LLMs）不是在 AST 上訓練的，而是在字符串上訓練的 —— 就像程序員一樣。
圖片
這揭示了一個問題：
LLM 學到的是“人類寫代碼”的方式，而不是機器最優的結構化方式。
如果未來真的有人用 AST 來大規模訓練模型，那需要極其龐大的算力和資金，而且還可能犧牲通用世界知識。
但也許在未來，會出現一種更高效、更貼近機器的新范式。
你覺得這種思路，會顛覆我們今天的 AI IDE 編程體驗嗎？
