對Agent真正重要的，是控制面設計本身
整理版優先睇
對Agent嚟講，控制面設計本身先係關鍵，唔係協議形式
呢篇文章係作者收到上篇反饋之後嘅反思。佢發現自己之前寫嘅內容，真正有說服力嘅部分唔係「命令行比協議高級」，而係指出Agent最需要嘅係一個清楚表達能力邊界、動作語義、參數約束同執行護欄嘅系統。kubectl-style CLI係呢種設計哲學嘅好例子，但唔係唯一。MCP一樣可以做到「將猜測變成選擇」，問題往往出喺點樣將結構暴露畀模型——例如一次過倒曬成個schema，定係逐層展開。
作者結論係：真正難嘅永遠係底層控制面建模。如果底層仲係一堆歷史動作、語義混亂、冇文檔，無論包CLI定MCP都唔會Agent-friendly。佢提出一個好嘅控制面要有六個要素：清晰資源邊界、穩定動作語義、顯式scope、可探索性、可驗證性同護欄機制。另外，文檔對於Agent嚟講唔係補充，而係接口本體嘅一部分，因為Agent冇人類工程師嘅「體感」，容易出幻覺同過早收斂。
最後作者總結咗幾個關鍵：MCP做到結構化；kubectl-style真正強係因為佢內建咗漸進探索同範式一致性；MCP嘅短板係默認暴露策略；而最核心嘅永遠係控制面建模本身。
- Agent友好嘅系統關鍵係控制面設計，唔係協議形式：要有清晰能力邊界、動作語義、參數約束同執行護欄。
- kubectl-style CLI嘅真正優勢係將漸進式探索同範式一致性內建咗喺接口表面，而MCP嘅呢啲特性要靠設計者自覺維護。
- MCP一樣可以做到「將猜測變成選擇」，但常見問題係默認一次過暴露全量schema，成本高又令模型分心。
- 一個結構良好嘅控制面需要六個要素：清晰資源邊界、穩定動作語義、顯式scope、可探索性、可驗證性同護欄機制。
- 文檔對Agent嚟講係接口本體嘅一部分，因為Agent冇體感，要靠清晰語義避免幻覺同過早收斂。
上一篇文章其實在講咩？兩個維度嘅控制面設計
作者話，將Agent接入一個系統，可以拆成兩個維度。第一個係底層能力本身結唔結構化，例如有冇清晰嘅資源模型、穩定嘅動作語義、顯式嘅scope/context、可預期嘅狀態變化，同埋冪等、dry-run、審計呢啲治理護欄。
第二個維度係呢啲結構點樣暴露畀模型。模型係一次過睇曬全量schema，定係按需逐層展開？面對幾十個工具，定係先睇目錄再入子目錄？呢兩個維度都好重要，因為協議形式同能力質量唔係一回事。一個掛住MCP名嘅系統可能暴露得又闊又亂，一個似CLI嘅系統都可能只係換咗個殼。
kubectl-style CLI嘅優勢，好多時係因為佢承載咗一套更成熟嘅控制面設計
MCP其實都可以「將猜測變成選擇」
作者補充上篇講過嘅「Agent需要嘅係有選項嘅考卷」，佢話呢點唔係CLI獨佔。MCP一樣做到，只要接口設計得好。最差嘅情況係接口令人「猜」：例如一堆唔統一嘅POST介面，參數風格又亂，Agent根本唔知點揀。
但係如果同樣能力通過MCP暴露，好似pipeline.stop(workspace, pipeline, dry_run)咁，模型見到嘅係一組有名字、有描述、有參數schema嘅工具，唔使自己發明endpoint，唔使猜HTTP method同payload。呢個已經將大量「接口猜謎」變咗做「工具選擇」。
kubectl-style CLI真正強喺邊？漸進探索同範式一致性
作者強調，漸進式探索係kubectl-style CLI嘅接口表面天然自帶嘅能力。Agent可以好似新同事咁：先睇目錄，再睇某類動作，再睇具體參數，最後決定點執行。呢個探索路徑唔係後加，而係內建喺控制面度。
另一個重要優勢係範式一致性。kubectl-style嘅命令結構天然要求verb resource [flags]，無論設計咩新資源都要跟呢個模式。呢種結構約束唔係建議，而係接口形式本身強制嘅。相比之下，MCP嘅tools雖然都可以設計得一致，但冇機制阻止混用命名風格。
kubectl-style CLI嘅範式一致性係接口形式自帶嘅約束，MCP要靠設計者自覺
MCP嘅問題唔係唔結構化，而係暴露策略
作者澄清上篇佢將MCP寫得太負面。其實MCP喺結構化描述能力方面唔弱，問題係默認暴露策略：Server有幾十個tools，Client一嚟就全量暴露曬啲名、描述、參數schema。呢個會帶來成本高同分心嘅問題。模型喺太多近似選項下容易選錯、漏看或者過早收斂。
不過呢個係可以改嘅：如果Client夠聰明或者Server有意識做discovery design，可以改做逐層暴露——第一層淨係畀domain，第二層畀某個domain下嘅動作，第三層先用先畀具體schema，高風險動作前再補文檔確認。咁樣MCP就可以逼近CLI嘅「目錄式探索」體驗。
結構良好嘅控制面六要素，同埋文檔嘅關鍵角色
作者歸納咗一個好嘅控制面至少要具備六個要素：
- 1 清晰嘅資源邊界：系統有乜嘢一級資源？生命週期同層級關係係點？
- 2 穩定嘅動作語義：同一動詞（stop、pause、delete）喺唔同資源上含義一致嗎？副作用明確嗎？冪等嗎？
- 3 顯式嘅scope同context：參數有冇明確workspace、tenant？定係藏喺session、header度？
- 4 可探索性（Discovery）：Agent能唔能夠逐層發現能力？參數schema係需要時先拎到？
- 5 可驗證性（Dry-run / Validation）：高風險動作可以預演嗎？參數執行前可以校驗嗎？
- 6 護欄機制（Confirmation / Audit）：破壞性動作有冇二次確認？有冇審計日誌？
如果呢六點做唔好，無論包CLI定MCP都唔會真正Agent-friendly。另外，作者強調文檔對Agent嚟講係接口本體嘅一部分，唔係錦上添花。因為Agent冇「體感」，面對模糊描述好易出接口幻覺同過早收斂。
文檔要寫清動作嘅語義、副作用、邊界條件、錯誤含義，否則schema再靚都唔夠
上篇文出咗之後，收到一啲好好嘅回饋。
其中有一句說話令到我停低再諗過：
你文章講嗰啲 kubectl-style CLI 嘅優點，我都認同。
但你真正喺度比較嘅，可能唔係 CLI 同 MCP，
而係結構化嘅接口設計同亂嚟嘅接口。
我返頭再讀咗一次自己寫嘅嘢，發現呢個提點好啱。
上一篇文真正有說服力嘅部分，其實唔係喺度證明「命令行天生比協議更高級」。我喺度證明嘅係另一件事：對 Agent 嚟講，最 friendly 嘅系統，係嗰啲將能力邊界、動作語義、參數約束同執行護欄都講到清清楚楚嘅系統。
kubectl-style CLI 的確係呢種設計哲學嘅優秀實現。但佢唔係唯一選擇。
MCP 其實都可以做到「將猜測變成選擇」，都可以支援運行時探索，都可以做漸進式暴露。佢常見嘅問題，更加係喺結構點樣暴露俾模型、幾時暴露、一次暴露幾多呢啲細節上。
所以呢篇文，我想基於上一篇文章，結合回饋同我嘅調研再重新整理嚇思考。
一、上一篇文其實係讚緊啲乜？
如果將 Agent 接入一個系統嘅過程拆開嚟睇，其實有兩個維度。
第一個維度，係底層能力本身結唔結構化。
即係呢個系統到底有冇：
清晰嘅資源模型 穩定嘅動作語義 顯式嘅 scope / context 可預期嘅狀態變化 冪等、dry-run、審計呢啲治理護欄
第二個維度，係呢啲結構點樣暴露俾模型。
模型見到能力嘅時候，係一次過睇曬全量 schema，定係按需要逐層展開？係直接面對幾十上百個工具，定係先睇目錄、再入子目錄？
呢兩個維度都好重要。因為現實裏面，協議形式同能力質量唔係同一回事。
一個系統掛住 MCP 個名，都可能暴露得又闊又亂。一個系統似 CLI，都可能只係幫一堆歷史動作接口換咗個殼。反轉嚟講，一個設計得好嘅 MCP，完全可能比好多普通 CLI 更適合 Agent。
所以而家我更願意咁樣講：kubectl-style CLI 嘅優勢，好多時係因為佢往往承載咗一套更成熟嘅控制面設計。
二、「將猜測變成選擇」，MCP 其實都做到
上一篇文裏面，我寫過一句說話：
Agent 需要嘅唔係自由發揮嘅舞台，而係有選項嘅考卷。
呢句說話我而家都係認同嘅。但我想補充一點：將猜測變成選擇呢件事，唔係 kubectl-style CLI 獨佔嘅能力。MCP 喺呢件事上都做到。
先睇最差嘅情況：接口真係令到模型去「猜」
假設一個系統對外暴露嘅係咁樣一組接口：
POST /stopPipelinePOST /pauseJobPOST /updateStatusPOST /terminateRun
然後參數風格仲唔統一：
有的傳 pipelineId有的傳 id有的傳 workspace有的傳 tenant有的 stop係停定義有的 terminate係停實例
呢個時候 Agent 面對嘅，先係真正意義上嘅「猜」：
用戶話「停咗呢個 pipeline」，到底應該 call 邊個？ stop和terminate有咩分別？停嘅係未來調度，定係而家呢次運行？ 參數到底應該點樣拼？
呢個算唔上結構化控制面，更加似係一堆歷史動作接口嘅堆積。
MCP 其實唔係呢種情況
如果同樣嘅能力通過 MCP 暴露，可能會係咁樣：
pipeline.stop(workspace, pipeline, dry_run)run.terminate(run_id)schedule.pause(workspace, schedule)
呢個時候模型見到嘅，係一組有名、有描述、有參數 schema 嘅工具。
佢唔需要自己發明 endpoint，唔需要估 HTTP method，亦唔需要猜 payload 係點樣。佢真正要做嘅，係喺已經結構化暴露咗出嚟嘅候選能力裏面，揀一個最符合當前任務嘅。
其實呢個已經將大量「接口猜謎」變成咗「工具選擇」。由呢個角度睇，MCP 喺「將猜測變成選擇」呢件事上，本來就成立。
kubectl-style CLI 都係做緊同一件事，只係方式唔同
如果換成 CLI，Agent 嘅路徑可能會係：
lakectl --help
lakectl stop --help
lakectl stop pipeline user_profile_sync -w growth
佢都唔係憑空創造動作，而係喺：
睇下有邊啲動詞 睇動詞下面有邊啲對象 再將參數填完整
所以更準確嘅講法係：kubectl-style CLI 同 MCP，都可以做到「將猜測變成選擇」。
三、kubectl-style CLI 真正強喺邊度？
如果話上一篇有一個判斷我而家都好想保留，就係呢點：
kubectl-style CLI 有一個好實在嘅優勢——佢將漸進式探索做咗接口表面天然自帶嘅能力。
我哋平時睇 --help，會覺得佢只係幫助文檔。但由 Agent 嘅角度睇，佢其實更加似係運行時嘅能力發現接口。
比如一個陌生工具，Agent 可以咁樣探索：
lakectl --help
lakectl apply --help
lakectl context --help
呢個過程好啱一個新同事入職之後嘅工作方式：先睇目錄，再睇某類動作，再睇具體參數，最後決定點樣執行。
關鍵係，呢個探索路徑唔係後加嘅，而係 kubectl-style CLI 嘅接口表面本來就組織好咗。佢將一套本來需要產品、文檔、工具鏈共同協作先可以形成嘅「能力導航路徑」，直接內建咗喺控制面裏面。
仲有一個容易忽略嘅點：範式一致性
kubectl-style CLI 仲有一個對 LLM 特別友好嘅地方。
佢默認強制咗範式一致性。而呢種一致性喺 MCP 裏面，需要設計者自覺維護。
kubectl-style 嘅命令結構天然要求 verb resource [flags]。呢個意味住無論你設計咩新資源，都要跟呢個模式：
kubectl get pods
kubectl describe pod my-pod
kubectl get deployments
kubectl describe deployment my-deploy
呢種結構約束唔係建議，係接口形式本身強制嘅。
相比之下，MCP 嘅 tools 雖然都可以設計得好一致（比如 pipeline.stop(), run.stop(), schedule.stop()），但呢種一致性完全靠設計者自覺。冇咩機制阻止你混用唔同嘅命名風格。
所以 kubectl-style CLI 喺範式一致性上有天然優勢，唔係因為佢更高級，主要係因為佢嘅接口形式自帶約束。
四、MCP：問題唔係「唔結構化」，而係「暴露策略」
上一篇文裏面，我將 MCP 寫得有啲似「一嚟就將巨大 schema 倒俾模型」嘅機制。而家返轉頭睇，咁樣寫唔夠準確。
更準確嘅講法係：MCP 喺「結構化描述能力」呢件事上並唔弱。佢真正常見嘅問題，更多係出喺呢啲結構有冇按最適合 LLM 嘅方式逐層展開。
問題出喺邊度
好多 MCP 接入嘅典型做法係：
Server 裏面有幾十個、上百個 tools Client 一嚟就將所有 tool 嘅名、描述、參數 schema，全量暴露俾模型
咁樣會帶嚟兩個好現實嘅問題。
第一係成本。上下文好貴。工具面一闊，齋係「先自我介紹一次」就要用好 token。
第二係注意力。模型面對一個過闊嘅能力面，容易分散注意力。佢唔係唔識揀，而係喺太多近似選項裏面，更容易揀錯、漏睇、或者過早收斂。
呢個其實就係我上一篇入面成日講嘅上下文預算問題。不過而家我會更準確咁講：MCP 嘅問題，好多時唔係「冇結構」，而係默認冇將結構按最適合模型嘅方式逐層暴露。
呢件事其實可以改
如果 Client 夠聰明，或者 Server 有意識咁做 discovery design，就可以改成：
第一層淨係畀 domain 第二層淨係畀某個 domain 下面嘅動作 第三層真正用到嘅時候，先畀具體 schema 高風險動作之前，再補文檔同確認
咁樣一嚟，MCP 雖然仲未完全等同於 kubectl-style CLI，但已經可以明顯逼近嗰種「目錄式探索」嘅體驗。
所以我而家更願意咁樣概括：MCP 嘅短板，好多時唔係協議本身，而係默認暴露策略。
五、咩叫做「結構良好嘅控制面」？
喺討論 CLI 同 MCP 之前，我哋可能需要先諗清楚：咩先叫做「結構良好嘅控制面」？
如果將呢個問題拆開，一個好嘅控制面至少應該具備呢六個要素：
1. 清晰嘅資源邊界
系統裏面有邊啲一級資源？（pipeline、run、workspace、dataset...） 每種資源嘅生命週期係咩？ 資源之間嘅層級關係係咩？
2. 穩定嘅動作語義
同一個動詞（stop、pause、delete）喺唔同資源上嘅含義一致嗎？ 動作嘅副作用明確嗎？（會影響下游嗎？會級聯刪除嗎？） 動作冪等嗎？
3. 顯式嘅 scope 同 context
參數裏面明確咗 workspace、tenant、namespace 嗎？ 定係將 scope 收埋喺 session、header、環境變量裏面？
4. 可探索性（Discovery）
Agent 可以逐層發現能力嗎？（先睇有邊啲資源，再睇資源下有邊啲動作） 參數 schema 可以喺需要嘅時候攞到嗎?
5. 可驗證性（Dry-run / Validation）
高風險動作可以事先試行嗎？ 參數可以喺執行之前校驗嗎？
6. 護欄機制（Confirmation / Audit）
破壞性動作有二次確認嗎？ 有審計日誌嗎？
如果呢六點做唔好，無論包 CLI 定包 MCP，都好難真正對 Agent 友好。嗰啲唔係真正嘅 Agent Ready，更加似係接口換皮。
六、文檔唔係補充材料，而係控制面本體嘅一部分
仲有一個回饋，我都好認同：即使接口設計本身唔錯，如果冇文檔，改造仍然會好難。
而且呢個唔係偶發現象。喺好多項目裏面，佢真係會重複發生：
接口有咗 schema 有咗 但語義冇寫清楚 示例冇畀 邊界條件冇寫 副作用冇寫 錯誤含義冇寫
點解文檔對 Agent 特別關鍵？
因為 Agent 冇「體感」。
人類工程師見到一個模糊接口名，可能會憑經驗腦補出一部分語義。但 Agent 面對模糊描述嘅時候，特別容易發生兩件事：
第一，接口幻覺。佢會自己補完一個佢以為合理嘅用法。
第二，過早收斂。佢睇咗少少信息，就以為自己已經明，唔再繼續查落去。
舉個最簡單嘅例子，同樣係一個 stop：
停嘅係未來調度，定係而家呢個運行實例？ 會唔會影響下游？ 冪等嗎？ 返回 success 係「請求已受理」，定係「真係停成功」？
如果呢啲冇寫清楚，schema 再靚都唔夠。
對 Agent 嚟講，文檔唔係錦上添花，而係接口本體嘅一部分。
七、寫到最後
最後重新整理嚇關鍵嘅幾個結論：
第一，MCP 並唔係做唔到結構化。佢同樣可以將「猜測」變成「選擇」。
第二，kubectl-style CLI 真正強嘅地方，唔只係因為佢係 CLI，而係佢將資源導向、幫助分層、範式一致性同執行護欄，天然組織成咗一套控制面形態。
第三，MCP 嘅問題往往唔喺協議本身，而喺暴露策略。如果一嚟就將全量工具同 schema 端俾模型，又貴又亂。但如果做好分層 discovery 同漸進暴露，體驗會好好多。
第四，真正最難嘅，永遠係底層控制面建模。如果底層仍然係歷史動作堆砌、語義混亂、冇文檔嘅狀態，咁無論包 CLI 定包 MCP，都好難真正對 Agent 友好。
上一篇文章發出去之後，收到了一些很好的反饋。
其中有一句話讓我停下來重新想了想：
你文章裏說的那些 kubectl-style CLI 的優點，我都認同。
但你真正在對比的，可能不是 CLI 和 MCP，
而是結構化的接口設計和胡亂設計的接口。
我回頭又讀了一遍自己寫的東西，發現這個提醒很對。
上一篇文章裏真正有說服力的部分，其實不是在證明”命令行天生比協議更高級”。我在證明的是另一件事：對 Agent 來說，最友好的系統，是那些把能力邊界、動作語義、參數約束和執行護欄都表達清楚的系統。
kubectl-style CLI 確實是這種設計哲學的優秀實現。但它不是唯一選項。
MCP 其實也可以做到”把猜測變成選擇”，也可以支持運行時探索，也可以做漸進式暴露。它常見的問題，更多是在結構怎麼暴露給模型、什麼時候暴露、一次暴露多少這些細節上。
所以這篇文章，我想基於上一篇文章，結合反饋和我的調研再重新整理下思考。
一、上一篇文章其實在誇什麼？
如果把 Agent 接入一個系統的過程拆開看，其實有兩個維度。
第一個維度，是底層能力本身結不結構化。
也就是這個系統到底有沒有：
清晰的資源模型 穩定的動作語義 顯式的 scope / context 可預期的狀態變化 冪等、dry-run、審計這些治理護欄
第二個維度，是這些結構怎麼暴露給模型。
模型看到能力時，是一次性看到全量 schema，還是按需逐層展開？是直接面對幾十上百個工具，還是先看目錄、再進子目錄？
這兩個維度都很重要。因為現實裏，協議形式和能力質量不是一回事。
一個系統掛着 MCP 的名字，也可能暴露得又寬又亂。一個系統長得像 CLI，也可能只是給一堆歷史動作接口換了個殼。反過來，一個設計得好的 MCP，完全可能比很多普通 CLI 更適合 Agent。
所以現在我更願意這樣說：kubectl-style CLI 的優勢，很大程度上是因為它往往承載了一套更成熟的控制面設計。
二、”把猜測變成選擇”，MCP 其實也能做到
上一篇文章裏，我寫過一句話：
Agent 需要的不是自由發揮的舞台，而是有選項的考卷。
這句話我現在還是認同的。但我想補充一點：把猜測變成選擇這件事，並不是 kubectl-style CLI 獨佔的能力。MCP 在這件事上也能做到。
先看最差的情況：接口真的在讓模型”猜”
假設一個系統對外暴露的是這樣一組接口：
POST /stopPipelinePOST /pauseJobPOST /updateStatusPOST /terminateRun
然後參數風格還不統一：
有的傳 pipelineId有的傳 id有的傳 workspace有的傳 tenant有的 stop是停定義有的 terminate是停實例
這時候 Agent 面對的，才是真正意義上的”猜”：
用戶說”停掉這個 pipeline”，到底該調哪個？ stop和terminate有什麼區別？停的是未來調度，還是當前這次運行？ 參數到底該怎麼拼？
這算不上結構化控制面，更像是一堆歷史動作接口的堆積。
MCP 其實不是這種情況
如果同樣的能力通過 MCP 暴露，可能會長這樣：
pipeline.stop(workspace, pipeline, dry_run)run.terminate(run_id)schedule.pause(workspace, schedule)
這時候模型看到的，是一組有名字、有描述、有參數 schema 的工具。
它不需要自己發明 endpoint，不需要猜 HTTP method，也不需要猜 payload 長什麼樣。它真正要做的，是在已經結構化暴露出來的候選能力裏，選一個最符合當前任務的。
這其實已經把大量”接口猜謎”，變成了”工具選擇”。從這個角度說，MCP 在”把猜測變成選擇”這件事上，本來就是成立的。
kubectl-style CLI 也在做同樣的事，只是方式不同
如果換成 CLI，Agent 的路徑可能是：
lakectl --help
lakectl stop --help
lakectl stop pipeline user_profile_sync -w growth
它也不是在憑空創造動作，而是在：
看有哪些動詞 看動詞下面有哪些對象 再把參數填完整
所以更準確的說法是：kubectl-style CLI 和 MCP，都可以做到”把猜測變成選擇”。
三、kubectl-style CLI 真正強在哪裏？
如果說上一篇有一個判斷我現在還是很想保留，那就是這一點：
kubectl-style CLI 有一個很實在的優勢——它把漸進式探索做成了接口表面天然自帶的能力。
我們平時看 --help，會覺得那只是幫助文檔。但從 Agent 的角度看，它其實更像是運行時的能力發現接口。
比如一個陌生工具，Agent 可以這樣探索：
lakectl --help
lakectl apply --help
lakectl context --help
這個過程很像一個新同事入職後的工作方式：先看目錄，再看某類動作，再看具體參數，最後決定怎麼執行。
關鍵是，這個探索路徑不是後加的，而是 kubectl-style CLI 的接口表面本來就組織好了的。它把一套本來需要產品、文檔、工具鏈共同協作才能形成的”能力導航路徑”，直接內建到了控制面裏。
還有一個容易被忽略的點：範式一致性
kubectl-style CLI 還有一個對 LLM 特別友好的地方。
它默認強制了範式一致性。而這種一致性在 MCP 裏，需要設計者自覺維護。
kubectl-style 的命令結構天然要求 verb resource [flags]。這意味着無論你設計什麼新資源，都得遵循這個模式：
kubectl get pods
kubectl describe pod my-pod
kubectl get deployments
kubectl describe deployment my-deploy
這種結構約束不是建議，是接口形式本身強制的。
相比之下，MCP 的 tools 雖然也可以設計得很一致（比如 pipeline.stop(), run.stop(), schedule.stop()），但這種一致性完全靠設計者自覺。沒有什麼機制阻止你混用不同的命名風格。
所以 kubectl-style CLI 在範式一致性上有天然優勢，倒不是因為它更高級，主要是因為它的接口形式自帶約束。
四、MCP：問題不是”不結構化”，而是”暴露策略”
上一篇文章裏，我把 MCP 寫得有點像”一上來就把巨大 schema 倒給模型”的機制。現在回頭看，這樣寫不夠準確。
更準確的說法是：MCP 在”結構化描述能力”這件事上並不弱。它真正常見的問題，更多出在這些結構有沒有按最適合 LLM 的方式逐層展開。
問題出在哪裏
很多 MCP 接入的典型做法是：
Server 裏有幾十個、上百個 tools Client 一上來把所有 tool 的名字、描述、參數 schema，全量暴露給模型
這樣會帶來兩個很現實的問題。
第一是成本。上下文很貴。工具面一寬，光是”先自我介紹一遍”就要花很多 token。
第二是注意力。模型面對一個過寬的能力面，容易分散注意力。它不是不會選，而是在太多近似選項裏，更容易選錯、漏看、或者過早收斂。
這其實就是我上一篇裏一直在講的上下文預算問題。只不過現在我會更準確地說：MCP 的問題，很多時候不是”沒有結構”，而是默認沒有把結構按最適合模型的方式逐層暴露。
這件事其實可以改
如果 Client 足夠聰明，或者 Server 有意識地做 discovery design，就可以改成：
第一層只給 domain 第二層只給某個 domain 下的動作 第三層真正用到時，再給具體 schema 高風險動作前，再補文檔和確認
這樣一來，MCP 雖然還不完全等同於 kubectl-style CLI，但已經可以明顯逼近那種”目錄式探索”的體驗。
所以我現在更願意這樣概括：MCP 的短板，很多時候不是協議本身，而是默認暴露策略。
五、什麼算是”結構良好的控制面”？
在討論 CLI 和 MCP 之前，我們可能需要先想清楚：什麼才算是”結構良好的控制面”？
如果把這個問題拆開，一個好的控制面至少應該具備這六個要素：
1. 清晰的資源邊界
系統裏有哪些一級資源？（pipeline、run、workspace、dataset...） 每種資源的生命週期是什麼？ 資源之間的層級關係是什麼？
2. 穩定的動作語義
同一個動詞（stop、pause、delete）在不同資源上的含義一致嗎？ 動作的副作用明確嗎？（會影響下游嗎？會級聯刪除嗎？） 動作冪等嗎？
3. 顯式的 scope 和 context
參數裏明確了 workspace、tenant、namespace 嗎？ 還是把 scope 藏在了 session、header、環境變量裏？
4. 可探索性（Discovery）
Agent 能逐層發現能力嗎？（先看有哪些資源，再看資源下有哪些動作） 參數 schema 能在需要時獲取嗎?
5. 可驗證性（Dry-run / Validation）
高風險動作能先預演嗎？ 參數能在執行前校驗嗎？
6. 護欄機制（Confirmation / Audit）
破壞性動作有二次確認嗎？ 有審計日誌嗎？
如果這六點沒做好，無論包 CLI 還是包 MCP，都很難真正對 Agent 友好。那不是真正的 Agent Ready，更像是接口換皮。
六、文檔不是補充材料，而是控制面本體的一部分
還有一個反饋，我也很認同：即使接口設計本身不錯，如果缺文檔，改造也仍然會很難。
而且這不是偶發現象。在很多項目裏，它真的會重複發生：
接口有了 schema 有了 但語義沒寫清楚 示例沒給 邊界條件沒寫 副作用沒寫 錯誤含義沒寫
為什麼文檔對 Agent 特別關鍵？
因為 Agent 沒有”體感”。
人類工程師看到一個模糊接口名，可能會憑經驗腦補出一部分語義。但 Agent 面對模糊描述時，特別容易發生兩件事：
第一，接口幻覺。它會自己補全一個它以為合理的用法。
第二，過早收斂。它看了一點信息，就以為自己已經懂了，不再繼續往下查。
舉個最簡單的例子，同樣是一個 stop：
停的是未來調度，還是當前運行實例？ 會不會影響下游？ 冪等嗎？ 返回 success 是”請求已受理”，還是”真的停成功”？
如果這些沒寫清楚，schema 再漂亮也不夠。
對 Agent 來說，文檔不是錦上添花，而是接口本體的一部分。
七、寫到最後
在最後重新整理下關鍵的幾個結論：
第一，MCP 並不是做不了結構化。它同樣可以把”猜測”變成”選擇”。
第二，kubectl-style CLI 真正強的地方，不只是因為它是 CLI，而是它把資源導向、幫助分層、範式一致性和執行護欄，天然組織成了一套控制面形態。
第三，MCP 的問題往往不在協議本身，而在暴露策略。如果一上來就把全量工具和 schema 端給模型，既貴又亂。但如果做好分層 discovery 和漸進暴露，體驗會好很多。
第四，真正最難的，永遠是底層控制面建模。如果底層仍然是歷史動作堆砌、語義混亂、缺少文檔的狀態，那麼無論包 CLI 還是包 MCP，都很難真正對 Agent 友好。