SEO、AEO 之後的 AXO：讓 AI Agent 真正完成網站任務

- 從被搜尋、被理解，到被 Agent 執行 -

這幾年，網站優化一直在改變問題的問法。

SEO 時代，我們關心的是：

Google 搜不搜尋得到我？

生成式 AI 普及後，問題變成：

ChatGPT、Gemini 或 Perplexity 能不能理解我、引用我、推薦我？

這是 AEO（Answer Engine Optimization，解答引擎優化）所處理的問題。

但看完 Greg Isenberg 訪談 Vinny、介紹 WebMCP 的影片後，我開始思考：下一個網站優化階段，可能不只是讓 AI 看懂內容，而是讓 AI Agent 能直接替使用者完成任務。

這個方向可以先用一個概念來描述：

AXO（Agent Experience Optimization，AI Agent 體驗優化）。

本文的 AXO 是一個用來理解下一代網站體驗的觀念框架，目前並不是所有平台都採用的統一標準。文中提到的 WebMCP 也仍處於實驗／提案階段，實際規格、瀏覽器支援與產品做法都可能持續變動。

為什麼 AEO 還不夠？

假設你問 AI：

幫我找一台適合每天做兩杯 Flat White，而且寬度不能超過 32 公分的義式咖啡機。

現在的 AI 已經可以搜尋資料、比較規格，再整理出幾個推薦選項。這是 AEO 很重要的價值：讓 AI 能夠理解產品、條件與內容，並用比較容易閱讀的方式回答問題。

但是，得到答案之後，使用者往往還要自己完成一長串工作：

• 打開商品網站，確認機器尺寸。
• 找到相容的磨豆機、把手與濾杯。
• 比對不同配件的規格與價格。
• 將商品加入購物車。
• 尋找折扣碼並完成結帳。

AI 可以告訴你答案，但不一定能替你把事情做完。這正是 AEO 與 AXO 的差別：

也可以用三個英文單字記住這條演進線：

SEO → Search

AEO → Answer

AXO → Action

什麼是 AXO？

我會這樣定義 AXO：

AXO 是針對 AI Agent 存取、理解、操作網站，以及完成使用者任務的整體體驗進行優化。

它關心的已經不只是「AI 看不看得懂你的內容」，還包括：

• Agent 知不知道你的網站可以做什麼？
• Agent 能不能搜尋你的商品或服務？
• Agent 能不能理解商品之間的相容性？
• Agent 能不能查看使用者有權限查看的資料？
• Agent 能不能預約、加入購物車或修改設定？
• Agent 能不能完成交易，並正確回報結果？
• 操作失敗時，Agent 能不能知道原因並恢復流程？

因此，AXO 的終點不是讓 Agent「來過網站」，而是讓 Agent 在權限、安全與確認機制都清楚的前提下，完成使用者交代的任務。

WebMCP 可能是 AXO 的一塊拼圖

影片中介紹的 WebMCP，是一個很值得觀察的方向。最容易理解的說法是：

網站主動告訴 AI Agent：「你可以怎麼操作我。」

過去的 Browser Agent 通常要模仿人類操作網頁：讀取 DOM、分析 HTML、尋找按鈕與輸入框、點擊，再透過畫面或頁面狀態確認是否成功。Computer Use 與 Browser Automation 並不是不能使用，但流程可能較慢，也可能因網站改版而失效。

WebMCP 所代表的思路則不同：網站提供一組結構化、可描述的工具，讓 Agent 不必只靠猜測畫面上的按鈕，而能直接理解可使用的操作。

例如牙醫診所可以提供這類工具：

1
2
3
4
5
6

search_services
get_doctor_schedule
check_available_slots
book_appointment
get_my_appointments
cancel_appointment

當 Agent 看到 book_appointment，它可以知道這是預約動作；看到 check_available_slots，則可以知道這是查詢可用時段。這比讓 Agent 猜「這個藍色按鈕是不是預約」更接近一個可理解、可測試的操作介面。

不過，工具名稱只是起點。要讓 Agent 真正可靠地使用網站，還需要進一步處理：

• 工具描述是否清楚，能不能讓模型選對工具？
• 參數與資料格式是否明確？
• 哪些資料需要登入後才能取得？
• 哪些動作需要使用者確認？
• 付款、刪除、取消等高風險操作如何避免誤用？
• 失敗時要回傳什麼錯誤，Agent 才能繼續處理？
• 任務成功後，系統如何提供可驗證的結果？

這些問題都屬於 Agent Experience，而不只是某一個 Web API 的問題。

網站未來可能同時存在三層介面

以前我們談網站，通常從 Human Interface 開始；未來的網站可能同時提供三種不同的理解與操作層。

1. Human Layer：給人看的介面

這一層包括：

• HTML、CSS 與 JavaScript。
• 圖片、文字、選單與按鈕。
• CTA、表單、結帳頁與動畫。
• 人類用來理解品牌與完成操作的視覺介面。

例如，人看到的是「立即預約」、「加入購物車」與「查詢訂單」。

2. Answer Layer：給 AI 理解的資訊

這一層包括：

• Entity 與品牌資訊。
• Schema 與結構化資料。
• Metadata、FAQ 與清楚的內容結構。
• 可供 AI 驗證、整理與引用的知識。

這是 AEO 關注的範圍，目標是讓 AI 正確知道你是誰、提供什麼，以及內容之間如何互相關聯。

3. Action Layer：給 Agent 操作的能力

這一層包括：

• Tools 與 Actions。
• Authentication 與 Permission。
• Transaction、Workflow 與 Confirmation。
• Error Handling 與 Task Completion。

人看到「立即預約」，Agent 可能需要理解的是 book_appointment()；人看到「加入購物車」，Agent 需要理解的是 add_to_cart()；人看到「查詢訂單」，Agent 需要理解的是 get_my_orders()。

WebMCP 可能協助網站補上這個 Action Layer，而 AXO 關注的是整個操作層是否容易被發現、理解、執行與驗證。

AXO 會怎麼改變電子商務？

影片裡 Vinny 示範了一個義式咖啡機器材商店的購物情境。重點不是問「哪一台咖啡機最好」，而是要求 Agent 根據多個條件，找出最適合使用者的一整套組合：

• 每天製作兩杯 Flat White。
• 咖啡機必須放進指定大小的櫃檯。
• 咖啡機要搭配正確的把手與濾杯。
• 磨豆機與其他配件也要符合需求。

這類任務很適合 Agent，因為它需要同時理解需求、搜尋商品、比較規格、確認相容性，再把多個步驟串起來。

Agent 的工作流程可能是：

1. 了解使用者的需求與限制。
2. 搜尋相關商品與規格。
3. 比較尺寸、功能與相容性。
4. 找到適合的配件組合。
5. 將選定商品加入購物車。
6. 在需要時套用折扣，並交由使用者確認交易。

這就不只是傳統搜尋，也不只是推薦系統，而是 Agent Commerce：由 AI Agent 協助使用者完成消費流程。

未來最大的網站訪客，可能不一定是人

傳統網站流量大致是：

1
2
3
4
5
6
7
8
9

Google
  ↓
搜尋結果
  ↓
使用者點擊
  ↓
進入網站
  ↓
瀏覽與轉換

Agent 參與之後，流程可能變成：

1
2
3
4
5
6
7
8
9

使用者提出任務
  ↓
AI Agent 搜尋與比較
  ↓
Agent 呼叫網站工具
  ↓
網站執行服務或交易
  ↓
Agent 回報完成結果

使用者甚至可能沒有直接打開網站，但 Agent 已經替他完成搜尋、預約或購物。這會讓一些傳統網站分析指標不再足以描述完整價值，例如：

• Page View
• Session
• Time on Site
• Bounce Rate

這些指標仍然有用，但未來可能還要觀察新的任務型指標：

• Agent Discoverability：Agent 能不能找到網站與可用工具？
• Tool Success Rate：工具被呼叫後，成功執行的比例是多少？
• Task Completion Rate：使用者交代的任務，有多少能完整完成？
• Agent Conversion Rate：Agent 促成預約、加購或交易的比例是多少？

這些名稱目前比較像是分析方向，而不是已經完全統一的產業標準。重點在於：網站價值可能要從「有多少人瀏覽」延伸到「有多少任務被成功完成」。

SEO、AEO、AXO 是同一條演進線

把網站優化的問題拉遠來看，可以看到三個階段：

SEO：讓搜尋引擎找得到

SEO 會處理關鍵字、Title、Meta Description、Sitemap、站內連結與 Structured Data 等基礎，目標是讓搜尋引擎更容易發現、理解並呈現網站。

AEO：讓 AI 理解與回答

AEO 更關心 Entity、Schema、FAQ、權威來源、內容結構與品牌 Identity，目標是讓 AI 能夠理解、驗證、整理與引用你的資訊。

AXO：讓 Agent 使用與執行

AXO 所處理的問題則是 Tools、Actions、Authentication、Permission、Transaction、Confirmation、Error Handling 與 Task Completion。

也就是說，網站的設計可能會從 Information Architecture，逐步延伸到 Action Architecture。

WebMCP 不等於 AXO

這一點需要特別釐清。

WebMCP 可能是 AXO 的技術元件，但 WebMCP 不等於完整的 AXO。

這就像 Schema.org 不等於完整的 SEO。Schema 可以協助搜尋引擎理解資料，但 SEO 還包括內容、網站結構、權威性與使用者體驗；同樣地，提供工具也不代表整個 Agent 體驗已經做好。

完整的 AXO 還要問：

• Agent 找不找得到網站？
• Agent 能不能理解品牌、商品與服務？
• Agent 取得的資料是否正確且最新？
• 工具名稱、描述與參數是否足夠清楚？
• 登入後的權限邊界是否明確？
• 高風險操作是否需要使用者確認？
• 操作失敗後，Agent 能不能知道下一步？
• 交易成功後，Agent 能不能取得可驗證的結果？

WebMCP 解決的可能是「如何把網站能力描述給 Agent」；AXO 要解決的則是「Agent 能不能可靠地使用整個網站完成任務」。

哪些產業可能最早需要 AXO？

第一波最需要 AXO 的，可能不是單純提供資訊的內容型網站，而是「任務複雜，且完成任務本身具有商業價值」的服務。

複雜型電商

汽車零件、相機配件、咖啡器材、電腦零組件與工業設備，都可能需要規格比對、相容性判斷與多商品組合。Agent 若能理解這些關係，就不只是推薦單一商品，而是協助組出可用的方案。

預約型服務

牙醫、醫美、美容、健身教練、顧問、律師與居家服務，都可能讓 Agent 代為查詢服務、比較時段與完成預約。這類流程的重點不只是找到店家，而是取得正確服務、時間、地點與預約結果。

SaaS 工具

CRM、廣告管理、Email Marketing、分析工具與 ERP，都有大量需要登入、查詢與設定的操作。未來使用者可能不必打開二十個選單，而是直接告訴 Agent：

把這個月沒有回覆的 Lead 找出來，建立 Follow-up Campaign。

企業內部系統

企業內部的 CRM、ERP、報表與管理後台，可能是 AXO 最早落地的場景之一。企業可以先在受控環境中讓 Agent 操作內部系統，權限與風險範圍較容易管理，也比較容易計算任務成功率與投資報酬。

Agent 神秘客：下一種網站稽核服務？

如果越來越多 Agent 會使用網站，企業就會需要知道：

我的網站對 Agent 到底好不好用？

過去網站會做 SEO Audit、UX Audit 與 Conversion Audit；未來可能出現 Agent Experience Audit，甚至直接派 Agent 當「神秘客」測試網站。

一個 Agent 神秘客可以依照指定任務測試：

1. 能不能找到指定商品或服務？
2. 能不能正確理解規格與限制？
3. 能不能完成登入與權限流程？
4. 能不能加入購物車、輸入折扣或預約時段？
5. 需要人工確認時，是否能清楚停下來等待？
6. 失敗時，是否能產生可理解的錯誤原因？

最後產出的報告，可能包含：

這些分數不應被視為放諸四海皆準的標準，而是幫助企業找出 Agent 在哪一步失敗，以及哪個資訊或流程造成轉換流失。

網站現在可以如何準備？

AXO 還在發展中，不代表所有網站現在都要立刻重做成 Agent 專用系統。比較務實的做法，是先從最重要、最常發生的任務開始盤點：

1. 先列出使用者真正想完成的任務

不要只問「網站有哪些頁面」，而要問：使用者來到網站後，最希望完成哪三件事？可能是查詢規格、預約時段、提交申請、查詢訂單或修改設定。

2. 讓內容與資料可以被清楚理解

品牌、商品、服務、價格、規格、庫存、地點與限制條件，都應該以一致、可讀、可驗證的方式呈現。這是 AEO 的基礎，也會影響 Agent 是否能正確做決策。

3. 把可執行的能力描述清楚

如果網站支援預約、查詢、加購或修改設定，就要思考這些能力如何用清楚的工具、動作、參數與結果描述出來。工具命名要讓人與 Agent 都容易理解，不能只依賴畫面上的顏色與位置。

4. 先設計權限、確認與錯誤處理

查詢公開資訊與付款、刪除、取消等高風險操作，應該有不同的權限與確認要求。每個操作也要有明確的成功、失敗、需要補資料與需要人工介入等狀態。

5. 用真實任務測試，而不是只測單一按鈕

真正的 AXO 測試，應該從使用者的完整任務開始，例如「找到符合條件的商品並加入購物車」，而不只是確認 add_to_cart 這個工具能不能被呼叫。只有把整條流程跑過，才知道 Agent 是否真的能完成工作。

結語：下一代網站要問的是「Agent 能不能使用我？」

以前我們做網站，會問：

Google 搜不搜尋得到我？

後來我們開始問：

ChatGPT 會不會理解並推薦我？

接下來真正重要的問題可能是：

當 AI Agent 選擇了我，它能不能順利使用我？

這就是：

SEO → AEO → AXO

從被搜尋，到被理解，再到被執行。

WebMCP 值得注意的地方，也不只是多了一個網站 API，而是它讓我們看見一種可能：Web 正在開始為 AI Agent 重新設計。

未來網站的競爭力，不只在於誰的介面漂亮、SEO 做得好或內容寫得完整，也可能取決於：

你的網站，準備好被 Agent 使用了嗎？

參考來源

本文觀點整理自 Greg Isenberg 訪談 Vinny 的影片：WebMCP: Let AI Agents pay you money。WebMCP、瀏覽器支援與 Agent 操作方式仍可能持續演進，實作前應以當時可取得的官方文件與產品規格為準。

常見問答 (FAQ)

Q1：AXO 是什麼？

AXO（Agent Experience Optimization）是針對 AI Agent 存取、理解、操作網站，以及完成使用者任務的整體體驗進行優化。它的重點不只在內容能否被理解，也包括工具、權限、交易、確認、錯誤處理與任務完成度。

Q2：AEO 和 AXO 有什麼差別？

AEO 主要讓 AI 理解、整理與引用網站內容；AXO 則進一步讓 AI Agent 能搜尋資料、呼叫網站能力、執行操作並完成預約、購物或其他任務。AEO 偏向 Answer，AXO 偏向 Action。

Q3：WebMCP 就等於 AXO 嗎？

不等於。WebMCP 可以視為協助網站向 Agent 描述可用工具與操作方式的技術方向，而完整的 AXO 還要處理資料品質、工具設計、登入權限、使用者確認、交易安全、錯誤恢復與任務完成驗證。

Q4：哪些網站最適合優先思考 AXO？

需要多步驟、規格比對或交易操作的網站，通常更適合優先思考 AXO，例如複雜型電商、預約服務、SaaS 後台與企業內部系統。單純提供文章閱讀的網站，則可以先從 SEO、AEO 與內容結構打好基礎。

Q5：網站要如何開始準備 AXO？

可以先盤點使用者最常想完成的任務，再把商品、服務與限制條件整理成一致且可理解的資料，接著設計清楚的工具、參數、權限、確認與錯誤回應，最後用完整任務測試 Agent 是否真的能完成流程。