別再沉迷協議，專注代理體驗

2025 年，如果你沒有使用 MCP（模型上下文協議）進行開發，那你可能沒有認真對待 AI 代理。MCP 主導了一整年的代理話題討論：會議演講、路線圖、招聘計劃，幾乎一切都圍繞 MCP 展開。

然而，到了 2025 年底至 2026 年，AI Skills 出現並立即引發了反彈。工程師們宣稱 MCP 已死，取而代之的是 Skills，隨後又轉向 CLI。Perplexity 的 CTO 公開表示公司正在降低對 MCP 的優先級。這個循環快、響且可預測：新工具、新熱潮、新重寫。

我在 2025 年初便開始推廣代理體驗（Agent Experience，簡稱 AX），當時 MCP 仍是核心焦點。回應大多是質疑：AX 想得太複雜了，MCP 才是唯一重要的層面。這種觀點如今看來有失偏頗。那些否定 AX 的人並非認為 MCP 無用，而是錯將協議當成了戰略。

他們忽略的是，而且我認為整個行業仍然在忽略的是：協議本身不值得精通，真正值得精通的是這門學科。

我們不斷掉入工具陷阱

我們的行業有一個眾所周知的習慣：混淆工具與戰略。微服務、Kubernetes、GraphQL 時代如此，現在對代理協議也是如此。

MCP、AI Skills、A2A、ACP 都是實現方式。它們很重要，解決了實際問題。但沒有任何一個值得你在此基礎上構建戰略。因為它們本質上就是會變化的東西。

當你圍繞一個特定協議組織代理戰略時，你是在一個由他人控制的、市場隨時可能拋棄的基礎上建造。更糟糕的是，你跳過了本該先做的步驟——判斷該協議是否真正適合你的用例。

這就是工具陷阱。你優化了一個特定集成機制的使用，卻沒有首先理解你究竟在優化什麼。

那麼，什麼是代理體驗？

代理體驗（AX）是研究 AI 代理如何發現、理解你的系統並與之交互，然後系統性地改進這些交互的學科。

可以將其視為面向代理的用户體驗（UX）。UX 的出現並非因為某個 UI 框架勝出，而是因為團隊意識到人類與軟件交互的質量是一個設計問題，它超越了任何特定技術。在 React 中構建糟糕的體驗和在原生 JavaScript 中一樣容易。框架不是決定性變量，設計思維才是。

AX 同理。代理如何發現你的服務能做什麼？它如何理解 API 的邊界？當它失敗時，能否獲得足夠的上下文進行恢復？交互是否高效，還是代理在無謂的往返中浪費 token？

這些問題與協議無關。無論你是通過 MCP、Skills、A2A 還是尚未發明的方式來暴露能力，它們都適用。能夠回答這些問題的團隊將適應任何未來變化，因為他們理解問題空間，而不僅僅是當前的工具鏈。

AX 是你已關心之事物的延伸

AX 並非用户體驗、開發者體驗或客户體驗的競爭對手。它是這三者的延伸。

你的首要目標仍是提供卓越的客户體驗。但變化在於客户與你互動的方式。越來越多客户將任務委託給代理。當客户要求代理與你的 API 集成、部署到你的平台或從你的服務中拉取數據時，該代理正代表客户行事。代理的體驗決定了它實現客户目標的可能性。

如果客户的代理在身份驗證上掙扎，為了解析你的錯誤消息而消耗大量 token，或者因為你的 API 缺乏上下文而靜默失敗，那就不僅僅是投訴那麼簡單了。代理會悄無聲息地轉向能提供更好體驗的替代服務。你的客户可能甚至不會注意到這一轉變。你就在沒有任何支持工單的情況下失去了客户。

UX 優化的是人類點擊界面的體驗，DX 優化的是開發者在你平台上構建的體驗，CX 審視整個客户旅程。AX 則將這種思考延伸到了客户如今派出的代理身上。

協議跑步機不可持續

回顧一下 MCP 的實際歷程。團隊投入大量精力編寫 MCP 服務器實現。但很多實現並不理想。不是 MCP 本身有缺陷，而是這些團隊沒有仔細思考代理真正需要從他們的系統獲得什麼。2026 年女王大學的一項研究分析了 103 個 MCP 服務器中的 856 個工具，發現 97.1% 的工具描述至少包含一個質量問題，56% 未能清晰説明其目的。協議運行正常，但體驗設計才是問題所在。

當 Skills 出現時，同樣的團隊面臨換湯不換藥的熟悉問題。他們仍然沒有回答根本性問題：代理需要利用我們的服務完成什麼？最小的可行交互界面是什麼？代理需要哪些上下文才能做出良好決策？

而那些已經解決了這些問題的團隊適應得很快。當你已經知道代理面向的接口應該是什麼樣子時，從一個協議遷移到另一個協議只是機械性工作。協議是序列化格式，體驗設計才是難點。

這種模式會不斷重複。無論是通用商務協議、A2A 還是下一個熱門事物，總會有新東西流行。如果你的策略是成為每種連續協議方面的專家，你就踏上了一條只會加速的跑步機。

AX 實踐的模樣

那麼，認真對待代理體驗究竟意味着什麼？如果你曾經建立過 UX 研究實踐或 DX 項目，你會覺得這一切很熟悉。步驟並不新鮮，只是角色變了。

我在演講中將其分解為五個步驟：

1. 審計你的客户使用的代理。 瞭解什麼在進入你的系統。查看流量數據和日誌，區分哪些是代理流量哪些是人類流量，以及具體是哪些代理。你的客户是否在使用 Claude Code、Cursor 或基於你的 API 構建的定製代理？你不能為未曾觀察過的東西進行設計。這與 UX 團隊進行用户研究是同樣的動機，只是方法不同。

1. 識別客户希望委託的用例。 並非每次交互都需要針對代理進行優化。利用相同的日誌數據，查看代理向你的平台發出的請求，並推斷它們試圖完成什麼。你也可以使用 AEO 數據來了解客户在面向代理的搜索中詢問哪些領域。首先關注最高價值的部分。如果你曾經通過查看開發者實際如何使用你的 API 來排定 DX 路線圖的優先級，那你就已經具備這種能力了。

1. 驗證和審計這些交互的體驗。 觀察代理在嘗試完成這些任務時會發生什麼。它在哪一步卡住了？它在哪一點誤解了你的服務能做什麼？這就是可用性測試。用户是語言模型，困難在於上下文而不是按鈕位置，但你要回答同樣的問題：它們能完成工作嗎？

1. 改進和重複。 代理能力不斷進化，模型變得更聰明，新的交互模式出現。在 Netlify，我們發現有些情況我們的產品以一種方式工作，但代理普遍假設它以另一種方式工作且從不詢問。我們沒有與這種假設抗爭，而是改進產品使其按代理期望的方式工作。結果是代理流程的採用率更高，錯誤更少。把 AX 作為活實踐來對待的團隊，將勝過那些從一個協議遷移忙到下一個的團隊。

1. 自動化驗證並防止退化。 一旦你有了“良好”的基線，就把它鎖定下來。像 AXIS 這樣的開源評分框架，允許你對真實場景運行真實代理並得到可比較的分數。將其集成到 CI 中，就像捕捉測試失敗一樣捕捉 AX 退化。這樣你就能從軼事式的改進轉向可衡量、可重複的 AX 質量。

當你的實踐到位後，協議選擇就變得顯而易見。你可以根據新工具的實際優點來評估它們：它是否解決了你觀察到的真實摩擦點？它是否解鎖了你以前無法實現的能力？還是僅僅是對你已經做得很好的事情進行了不同的包裝？

困難之處是熟悉的

AX 比學習新協議更難掌握，這是事實。學習 MCP 或 Skills 是一個有邊界的工程問題：閲讀文檔、編寫代碼、交付集成。明確的終點，容易展示進展。這相當有吸引力，特別是當你或你的團隊快速前進時。

而建立 AX 學科意味着在短期內要忍受模糊性。在你有清晰答案之前研究代理行為。承認正確的集成策略取決於你需要發現的上下文，而不是可以跟隨的教程。但如果你曾從零開始建立 UX 或 DX 實踐，那麼你以前就經歷過這些。原因相同：理解你的用户、減少摩擦、讓他們容易成功。方法不同是因為用户不同。學科本身並不新鮮，而是我們行業幾十年來工作的延伸。

好消息是，這種思維正在獲得動力。John Maeda 的 2026 年設計科技報告明確討論從 UX 到 AX 的轉變。研究人員正在將代理交互質量作為一流的工程問題進行研究。BCG 和 MIT Sloan 發現 35% 的組織已經在使用代理型 AI，另有 44% 在計劃中。問題不再是 AX 是否重要，而是你的團隊是否在競爭對手之前建立實踐。

2028 年的代理與 2025 年的代理與你的系統交互方式將不同。協議不同，能力不同，期望不同。但不會改變的是，你的系統需要為使用它們的人，以及現在那些人派出的代理，提供卓越體驗這一根本需求。

精通於此，其他都只是實現細節。