了解 Webflow 如何重新設計 API 以支援 AI 代理，涵蓋 MCP 伺服器架構、工具介面設計、可觀測性策略與分發擴展經驗。
為代理設計 API：Webflow MCP 伺服器的經驗教訓
專為開發者設計的 API 無法滿足代理的需求。以下是我們在建構 Webflow MCP 伺服器過程中學到的經驗，以及真正能使代理 API 可靠的關鍵因素。
為什麼開發者 API 不適合代理
使用者可能會請求代理更新首頁的 Hero 區塊。在傳統 API 中，這會變成一連串低層級操作：
- 列出頁面
- 找到首頁
- 取得頁面內容
- 檢查內容樹狀結構
- 找到 Hero 區塊
- 更新內容
早期的 MCP 實作通常直接將現有的開發者 API 公開為 MCP 工具：
getPages()
getPageContent(pageId)
updateContent(contentId, payload)
publishPage(pageId)
MCP 協定本身沒有問題，協定運作如預期。LLM 只能看到工具描述、結構描述、先前的回應和當前的上下文視窗。它必須動態推斷執行策略，同時跨多次工具呼叫保留中間狀態。這就是失敗模式開始出現的地方。每增加一次工具呼叫，就會增加延遲、Token 消耗、上下文壓力和執行失敗的機率。代理現在必須：
- 正確保留中間識別碼
- 從模糊結果中選擇正確資源
- 解讀雜訊或過於通用的回應
- 依序協調相依操作
- 決定失敗是可重試還是終止性
即使 API 技術上支援該工作流程，模型的大部分執行預算都花在導航 API，而非完成使用者任務。
代理 API 需要什麼
我們的教訓是：透過 MCP 公開 API 只是起點。可靠的代理執行更多取決於工具本身的形狀和語義。開發者 API 通常優化靈活性和可組合性。代理 API 需要優化執行可靠性：更少的模糊選擇、更少的相依呼叫、更少的狀態保留、以及發生錯誤時更清晰的指引。
針對首頁 Hero 更新，更好的介面是直接匹配使用者意圖的任務層級工具：
update_page_section({
"page": "home",
"section": "hero",
"changes": {
"heading": "Build faster with Webflow"
}
})
宣告式 API 將複雜的多步驟工作流程轉化為單一意圖驅動的呼叫。平台內部處理編排，代理無需探索內部結構、保留中間狀態、協調相依操作或從部分失敗中恢復。這減少了失敗模式，讓代理專注於使用者目標而非執行細節。
從低層級 API 轉向任務層級工具方向正確，但在 Webflow 的規模下引發新問題：工具爆炸。Webflow 支援太多有效工作流程，無法將每個都建模為獨立的 MCP 工具。純任務導向設計會快速產生龐大、重疊的工具介面，使代理難以高效導航。解決此問題有兩種主要方法：
1. 分層工具架構
不公開數百個獨立工具，而是將相關能力分組為領域層級工具，內含類型化的可組合動作。這給代理一個更結構化、可導航的產品介面地圖，同時保持頂層工具空間可控。
工具介面演進為數層：
- 領域工具：組織廣泛的產品領域（如 CMS、Designer）
- 動作：在每個領域內提供可組合的類型化原語
- 工作流工具：封裝編排繁重的任務
- 指引工具：提供操作指示和產品上下文以利安全執行
這緩解了工具介面和編排問題，但未根本消除。隨著產品能力擴展，即使在分層架構中，有效工作流程和動作數量仍可能快速增長。挑戰從單純組織工具轉向減少系統對顯式工具發現的依賴。
2. 檔案系統抽象與程式碼表示
代理可針對結構化專案表示進行操作，使用熟悉的程式設計和 Shell 風格工作流程。這將互動模型從 API 編排轉向執行環境和程式碼驅動的操作。
範例：首頁更新任務的程式碼模式
// 代理以程式碼編輯您的網站
read src/pages/home.tsx
write src/components/Hero.tsx
write src/styles/theme.css
這更符合當前 LLM 的優勢：模型擅長推理結構化文本、生成程式碼、編輯檔案、在執行環境中操作。將互動模型從 API 編排轉向結構化狀態操作，可減少發現開銷、上下文消耗和多步驟協調負擔。
深層教訓：擴展代理系統不僅是增加更多工具，而是給模型一個更可導航、更高效的操作環境。
啟動與擴展我們的 MCP 伺服器
設計代理 API 不只關乎 API 介面本身。一旦代理成為長期工作流程的活躍參與者，許多周邊系統決策開始直接影響執行品質：會話架構、工具組織、執行時協調、可觀測性、甚至分發。
實踐中，建構可靠的代理系統成為全端設計問題。這塑造了我們在四個領域對 Webflow MCP 伺服器的方法：
- 有狀態執行與執行時協調的基礎設施
- 清晰且高效能力發現的工具介面設計
- 理解真實代理行為的可觀測系統
- 降低設定摩擦並擴展採用的分發模式
1. 基礎設施
MCP 伺服器的基礎設施需求與傳統 API 服務截然不同。雖然 MCP 不要求伺服器端狀態，但真實代理工作流程高度有狀態。代理可能一次認證、檢查網站上下文、跨不同產品介面呼叫多個工具、並在長期工作流程中持續推理。將每次互動視為完全無狀態會強迫模型反覆重建上下文和執行狀態，增加延遲和失敗機率。
我們在 Cloudflare 上使用 Durable Objects 建構 Webflow MCP 伺服器，因為它們提供天然的會話導向執行模型。每個 MCP 會話擁有自己的伺服器實例，管理使用者上下文、可用工具和執行時協調，無需額外會話基礎設施。
我們也必須支援兩種不同的執行環境：
- 部分操作透過 Webflow API 無頭運行
- Designer 動作（如插入元素、更新樣式）依賴即時瀏覽器畫布
對後者，MCP 伺服器維護 WebSocket 橋接至使用者活躍 Webflow 會話中運行的 Designer Extension。
此架構給代理統一的 MCP 介面，同時允許系統在後台將操作路由至正確執行時。同時，我們逐步將更多 Designer 能力移至無頭 API。減少對即時瀏覽器執行的依賴簡化了執行時架構，降低協調複雜度，提升代理工作流程的整體穩定性和可靠性。
2. 設計工具介面
如前所述，我們發現兩種方法有助於減少代理的編排和發現開銷：分層工具組織、檔案系統抽象與 Webflow 專案的程式碼表示。隨時間推移，我們將它們視為同一根本問題的短期和長期解決方案。
短期：分層工具架構隨著 MCP 介面擴展而幫助，因為我們給代理一張更好的地圖，而不是一次公開所有工具。
長期：檔案系統風格抽象和程式碼導向環境變得越來越重要。代理不必透過顯式 MCP 工具呼叫進行每次互動，而是能像在可程式化工作區中操作結構化專案表示。
3. 可觀測性
一旦代理開始跨長期工作流程自主操作，可觀測性變得更重要。
傳統日誌和追蹤對基礎設施除錯有用——能告知哪些請求失敗、延遲模式、伺服器端例外。但它們不適合理解代理行為：無法告知代理實際嘗試完成什麼、期望存在哪些能力、工作流程在哪裡變得混淆、或為什麼看似「成功」的會話仍產生不佳結果。
為填補這個缺口，我們整合 MCPCat 作為 MCP 伺服器周圍的可觀測層。透過在初始化時包裝伺服器，它捕獲工具呼叫、資源讀取、缺失工具嘗試、會話元資料、整個執行流程的回應模式。最有價值的訊號是意圖。
- 缺失工具嘗試揭露代理預期但找不到的能力或命名模式
- 會話重播浮現退化工作流程：模型反覆探索、重試、改變方向卻從未產生硬性錯誤
- 許多情況下，系統從基礎設施角度看似健康，但代理體驗仍在靜默失敗
我們最初預期 CMS 遷移和內容管理將主導使用量。實際上，Agent Goals 顯示透過第三方代理直接在 Webflow 畫布設計佔 27.7% 的會話。我們也發現影響超過 10% 會話的靜默錯誤，並發現 58.7% 的會話集中在三個核心工作流程。
隨時間推移，我們意識到代理系統的可觀測性根本不同於 API 可觀測性。目標不僅是理解請求是否成功，而是理解模型如何推理、探索能力、從模糊中恢復、以及在執行中如何失敗。
4. 擴展分發
MCP 伺服器的分發擴展不僅是處理更多流量。關鍵在於降低採用摩擦、擴展代理可使用 Webflow 的場景、提升代理可執行工作流程的品質。
2026 年初推出託管 MCP 連接器（從 Claude 開始）後採用加速，顯著降低使用者設定摩擦。使用者無需手動配置 MCP 連線和認證流程，即可透過託管整合連接 Webflow，大幅減少運維開銷。我們觀察到過去 3 個月會話增長 6.7 倍。
擴展採用也讓一點明確：代理需要的不只是工具。工具揭露代理能做什麼；技能編碼如何做好。對 Webflow 而言，許多成功結果需要產品判斷、可重用工作流程和領域慣例——不只是 API 存取。將更多有用技能引入 Webflow MCP 體驗（如版面模式、CMS 遷移劇本、SEO 工作流程、無障礙檢查、品牌系統指引），隨著代理從簡單工具呼叫邁向端到端網站工作而變得關鍵。
隨採用增加，挑戰從協定機制轉向自主系統的產品體驗：提供更豐富的網站上下文、擴展技能層、理解代理行動是否真正幫助使用者達成有意義的結果。
總結
代理不只是另一個 API 客戶端。它們是不同類型的執行時參與者：能透過上下文推理、動態探索能力、從介面結構學習、並依賴系統使下一個正確動作可被發現且可靠。
為這類使用者設計改變的不只是 API。它影響我們如何建構工具、管理編排、公開上下文、建構執行環境、觀察工作流程、甚至產品介面本身的建模方式。隨時間推移，我們發現自己不只是設計 MCP 介面，而是為自主系統設計完整的作業環境。
這推動我們走向分層工具架構、工作流程抽象、檔案系統風格專案表示、更豐富的可觀測性、技能層。目標從來不是單純向代理公開更多能力，而是幫助模型以更少探索、更少編排負擔、更高執行可靠性做出正確決策。
未來的工作不只是讓 Webflow 可被代理程式化。而是讓 Webflow 對自主系統可讀、可導航、操作可靠，同時不失使平台對人類強大的靈活性。這既是深度產品挑戰，也是系統挑戰——正是我們在 Webflow 熱衷解決的問題。
最後更新：2026 年 7 月 21 日
分類：開發