編輯 | 伊風
你的 MCP，可能真的用錯了？
MCP 常被視為大型模型的「USB 介面」。不少開發者第一反應就是：往裡堆更多專用工具（grep、sed、tmux……），好像這樣就能讓 AI 更強大。
但在 Hacker News 上，一篇熱門貼文卻拋出截然相反的結論：
👉 工具越多越亂，MCP 的最佳解是——只留一個程式碼執行器。
開發者都知道：命令列工具其實很「脆弱」。
• 跨平台/版本相容性差
• 換行符、特殊字元動不動就出錯
• 會話一混亂，程序直接跑飛
作者敏銳地意識到：這些不是小錯誤，而是底層結構性的難題。
所以問題來了：命令列的問題究竟出在哪？為什麼答案不是更多小工具，而是一個「超級工具」——一個能直接執行 Python/JS 的直譯器？
MCP 呼叫命令列工具為什麼總是崩潰？
作者表示，呼叫命令列工具，最讓人抓狂的是：
AI 一旦出錯，要么推倒重來，要么乾脆換別的工具，只因為一個小細節沒處理對。
這背後有兩個明顯的缺陷：
第一，平台和版本相容性差。
命令列工具常常依賴具體環境，有時甚至缺乏文件支援。結果就是——幾乎每次首次呼叫都會踩雷。
更典型的例子是處理非 ASCII 字元：Claude Sonnet、Opus 有時都分不清該怎麼在 shell 裡傳遞換行符或控制字元。
這種情況並不少見，C 語言編譯時，末尾常常需要保留一個換行符，而 AI 工具偏偏會在這裡卡死，一大堆令人「嘆為觀止」的工具循環來解決。
第二，呼叫鏈太長，狀態管理困難。
有些智能體（尤其是 Claude Code）在執行 shell 呼叫前，還會多一道「安全預檢」。Claude 會先用小模型 Haiku 判斷這個呼叫是不是危險的，再決定要不要執行。
更棘手的是多輪呼叫。比如讓它用 tmux 遠端控制 LLDB，理論上能行，但它常常「失憶」：半路改掉 session 名字，忘了自己還有會話，也就沒法正常結束任務。
總的來說，命令列工具一旦進入多輪呼叫場景，穩定性就成了最大軟肋。
而這反而掩蓋了 CLI 工具原本的優勢。
命令列的本事在於「組合」，而 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 的黑箱呼叫裡，這種「腳本化+複用」的自增長路徑目前很難自然出現。
更好的 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 負責會話管理和互動
• 智能體寫出的程式碼幾乎就是腳本本身
• 會話結束後，可以順手整理成可複用的偵錯腳本
實戰驗證：效率與複用性的飛躍
驗證 pexpect-mcp 的效果，作者用它偵錯了一個已知會崩潰的 C 程式（demo-buggy）。
過程如下：
1. 首次偵錯 (傳統 MCP 模式模擬)： AI 透過 pexpect_tool 與 LLDB 互動定位崩潰原因（記憶體未分配、陣列越界）。耗時約 45 秒，涉及 7 輪工具呼叫。
2. 腳本化： AI 將整個偵錯過程自動匯出為一個獨立的、可讀的 Python 腳本 (debug_demo.py)。
3. 複用驗證： 在全新會話中，僅用 1 次工具呼叫執行 uv run debug_demo.py。腳本 5 秒內重現了崩潰分析，精準定位問題根源。
作者表示，最關鍵的是：這個腳本是獨立的，我作為人類也能直接執行它，甚至完全不依賴 MCP！
pexpect-mcp 的成功案例揭示了一個更普適的 MCP 設計方向：與其暴露一堆零散且易出錯的黑箱工具，不如將程式語言本身作為互動介面。
創新：自己手搓小型 MCP
MCP 的一個通病是：工具越多，越容易導致上下文腐爛，而且輸入限制很大。
但如果 MCP 暴露的不是一堆工具，而是一門程式語言，那麼它就間接開放了模型在訓練中學到的全部能力。
當你要建構一些全新的東西時，至少程式語言是 AI 熟悉的。你完全可以手搓一個小型 MCP，讓它：
• 匯出應用的內部狀態
• 提供資料庫查詢輔助（哪怕支援分片架構）
• 提供資料讀取 API
過去，AI 只能靠讀程式碼理解這些介面；現在，它還能直接透過一個有狀態的 Python/JavaScript 會話去呼叫並進一步探索。
更妙的是：這也讓智能體有機會偵錯 MCP 本身。得益於 Python 和 JavaScript 的靈活性，它甚至能幫你排查 MCP 的內部狀態。
網友爭議：AI 應該如何操作程式碼？
這篇部落格的討論，其實已經觸碰到AI 程式設計的底層哲學。
AI 究竟應該如何操作程式碼：
是繼續停留在文本層面（字串），還是透過更結構化的介面來理解與操控？
我們知道，CLI 工具的脆弱性（換行符出錯、會話管理混亂）本質上就是基於字串操作的局限。
那麼問題來了：如果 AI 寫「真程式碼」更好，是不是要再進一步，讓它理解 AST？註：AST（抽象語法樹）：是一種將程式碼轉化為樹狀結構的表示方式。每個節點代表變數、函式或語句。對編譯器和 IDE 來說，AST 是比純文本更精準的結構化介面。
有網友認為：
編輯器本該更多利用語言伺服器等結構化能力，而不是讓智能體在 grep、sed、awk 這些老舊工具上兜圈子。而且對大多數語言來說，操作的也不應該是字串，而應該是 token 流和 AST。
另一派則指出：
現實決定了 AI 還是更適合操作程式碼本身：同意現在的工具使用方式效率低，但 AI 主要還是操作程式碼而不是語法樹，有幾個原因：
1.訓練集裡程式碼遠遠多於語法樹。
2.程式碼幾乎總是更簡潔的表示形式。
過去有人嘗試用圖神經網路或 transformer 來訓練 AST 邊資訊，但要想超過主流 LLM 可能需要重大突破（和鉅額資金）。實驗表明讓智能體用 ast-grep（語法感知的搜尋替換工具）效果不錯，本質上還是把一切當作程式碼，但用語法感知的方式來替換。
還有人強調了字串的普適性：
字串是無依賴的通用介面。你可以跨任意語言、跨任意文件完成幾乎任何事。其他抽象反而會嚴重限制你能做到的事情。另外，大型語言模型（LLMs）不是在 AST 上訓練的，而是在字串上訓練的——就像程式設計師一樣。
這揭示了一個問題：
LLM 學到的是「人類寫程式碼」的方式，而不是機器最佳的結構化方式。
如果未來真的有人用 AST 來大規模訓練模型，那需要極其龐大的算力和資金，而且還可能犧牲通用世界知識。
但也許在未來，會出現一種更高效、更貼近機器的新範式。
你覺得這種思路，會顛覆我們今天的 AI IDE 程式設計體驗嗎？歡迎在評論區聊聊。