MCP 的新原語，正在淘汰自製 agent middleware

MCP 的 elicitation、structured output 和 prompt templates，正在取代大量自製的 agent middleware。

MCP 已經跨過關鍵門檻：原本團隊手工補上的 agent 行為，開始變成協議本身的一部分。MuleSoft 的 MCP Connector 更新加入 elicitation、structured output 與 prompt templates，代表系統可以直接追問缺失欄位、限制回傳格式、統一提示詞，而不必每條工作流都帶著脆弱的膠水程式。這不是小修小補，而是把 agent 行為從應用層搬到基礎設施層。

第一個論點

自製澄清邏輯本來就是稅，不是功能。過去一年，幾乎所有認真的 agent 工作流都得自己處理缺資料的情況：缺 region、account ID、approval flag 或日期區間時，工程師要寫分支、停下來問、驗證、再重試。這些程式碼重複、難測、也很容易在新工具或新後端接上來時壞掉。elicitation 把這段互動移進協議，因為每次工具呼叫本來就會經過協議層。

實務上的好處很直接。少了散落各服務的 one-off handler，少了藏在 orchestration code 裡的 prompt hack，也少了 agent 該問卻亂猜造成的失敗。MuleSoft 的方向很清楚：原本每個 workflow 都要自己做的 middleware，現在應該成為 protocol primitive。只要某個模式會在多個 agent 重複出現，它就該下放到應用層以下，而不是塞進每個產品團隊的自訂邏輯裡。

第二個論點

structured output 的價值，在於它把「能看」和「能用」分開。agent 失敗不只發生在缺輸入，也發生在工具回傳一大段文字，對人類看起來合理，對下一步機器操作卻毫無幫助。一般 MCP 工具回應常混有狀態敘述、metadata、協議摘要與說明文字，這對看 log 的人沒問題，對要抽一個欄位、比對一個值、或觸發下一個動作的 agent 來說卻是毒藥。structured output 讓回應變成模型能可靠消化的結構，而不是靠猜。

這一點之所以重要，是因為 agent stack 的強度取決於最弱的交接點。輸入再乾淨，只要輸出還是雜訊，系統最後還是會退化成 prompt parsing 和 regex 補丁。structured output 拿掉了這個脆弱中介層，給 agent 一份契約，而契約才是 automation 能擴張的前提。沒有契約，團隊只是在針對某個工具的措辭做過度擬合，無法在工具與領域之間重用行為。

第三個論點

prompt templates 不是便利功能，而是治理工具。共享模板能統一 agent 怎麼提問、怎麼使用工具、怎麼處理不確定性，這會直接降低團隊之間的漂移。漂移是 agent 系統變得不可維護的最快路徑之一：每個 workflow 都發明自己的提示風格，最後組織看起來不像平台，只像一堆實驗。

模板也讓審查與稽核成為可能。資安團隊可以檢查一套核准過的模式，而不是追著散落在各種 codebase 和 low-code flow 裡的提示變體跑。產品團隊也能集中調整行為，而不是在每個整合裡重複踩同樣的坑。MuleSoft 把 templates、elicitation、structured output 綁在一起是對的，因為三者本來就是同一個系統：先問對問題，再收對答案，最後保持互動一致。

反方可能怎麼說

最強的反對意見是：協議功能不會消滅複雜度，只是把它搬家。elicitation 仍然需要產品決策，像是什麼時候中斷使用者、要問多少資訊、要暴露多少上下文；structured output 仍然依賴 schema 設計，壞 schema 只會帶來另一種僵化；prompt templates 也可能變成新的中央控制層，讓每次變更都要經過平台審批，拖慢團隊。

這個批評成立，但它沒有推翻這套原語，反而劃出邊界。協議不該取代判斷、政策或領域設計；它能取代的是每個 workflow 都重寫一次的澄清、解析與提示格式化邏輯。真正該被保留在應用程式裡的，是那些確實因產品而異的決策。其他共通機械，應該標準化。

所以答案不是拒絕 protocol primitives，而是接受它們的限制，並把重複的 middleware 從每個 app 裡抽走。不要在每個團隊裡重新造同一套輪子。把共通機制下放，才有空間讓應用程式專注在真正不同的地方。

你能做什麼

如果你是工程師，先停止為每個 agent tool 寫獨立的 retry-and-clarify 流程，改把這些行為收斂到可共享的 MCP 模式。若你是 PM，先定義 agent 什麼時候必須追問、必須回傳哪些欄位、交接格式長什麼樣，再上線下一個 workflow。若你是創辦人，把 elicitation 和 structured output 當成平台能力，而不是可有可無的附加價值，因為先標準化的人，會更快交付、更少故障，也更少陷在 agent folklore 裡 debug。