研究主題頁 · AX
AX 代理人體驗AI 代理人用你的產品，
能把事情辦完嗎？
AX（Agent Experience，代理人體驗）關注 AI 代理人使用產品時，能否理解操作、取得適當權限、完成任務，並把可驗證的結果交回使用者。
從產品入口到錯誤恢復，這裡整理四個檢查點與任務閉環，連結設計方法和平台案例。
01
AX 閱讀指南
從一筆完整任務，延伸到交易準備、存取邊界與網站規則。
- 研究報告
AI 選對工具，為什麼還會做錯？TCC 工具契約框架
以 152 筆測試檢查選用、參數及回傳判讀，認識 TCC 題卡。
- 行銷成長
AX 是什麼？從訂房看代理人體驗
用一筆訂房，檢查介面操作、授權、結果驗證與出錯後的處理。
- 行銷成長
你的網站準備好讓 AI 代理人下單了嗎？
對照商品資料、交易條件與結帳流程，整理代理購物的準備工作。
- 新聞快訊
摩根大通開始封鎖 AI 代理人？
從平台限制登入與代操的案例，理解代理人存取的邊界。
- 行銷成長
robots.txt 該不該擋 AI？
分清訓練、搜尋與使用者觸發的存取，再判斷網站規則。
延伸閱讀：從可供性理解代理人能否操作產品。
02
UX、DX 與 AX 的差別
UX 設計給看畫面操作的人，DX 設計給讀文件接 API 的開發者，AX 設計給替人辦事的 AI 代理人。代理人拿到一句目標就開始自己找路，產品原本藏在介面裡的假設，會一個一個冒出來。
UXUser Experience
以使用者為對象
人自己看畫面、判斷下一步
- 使用者選日期、挑時段
- 操作介面看價格、確認條件
- 任務結果完成訂位
畫面要清楚。人卡住時，還能自己看懂、回頭修正。
DXDeveloper Experience
以開發者為對象
工程師先讀文件，再把能力接進系統
- 開發者讀文件、取得金鑰
- API／SDK查空位、建立訂位
- 系統整合上線後維護
文件可以長。工程師會先理解規格，再寫程式。
AXAgent Experience
以 AI 代理人為對象
代理人接下目標，自己決定怎麼完成
- 使用者目標今晚 19:00，兩位
- 代理人找入口、選工具、填參數
- 人機合作必要時確認，拿到訂位紀錄
入口、工具、參數與錯誤回覆都要能直接操作。卡住時，還要有人能接手。
03
AX 的四個檢查點
AX 分成存取、上下文、工具與編排四個領域，出自 Biilmann 2026 年 1 月的〈One Year of AX〉。本頁把它們整理成存取、理解、執行、交接四個檢查點。它們不必照順序做，重點是找出代理人走到你的產品時，可能在哪裡停下來。
- 01
存取 Access
它能不能開始，什麼時候該停？
登入、權限、付款與送出前的確認，都可能把任務切回人手上。高風險動作本來就該停，但要停得清楚：讓代理人知道缺什麼，也讓人知道自己正在同意什麼。
- 02
理解 Context
它知不知道這是什麼、下一步能做什麼？
文件、工具描述、錯誤訊息與回傳格式都會影響判斷。與其堆品牌形容詞，不如把產品能力、限制與操作方式寫成代理人可直接使用的句子。MCP、Skills 或回傳 Markdown，都是交接脈絡的方式。
- 03
執行 Tools
它有沒有動作可以呼叫？
把查空位、保留座位與建立訂位拆成不同工具，寫清楚輸入、輸出與失敗狀態。工具準備好之後，模型會不會選它，才是 TSO 要處理的事。
- 04
交接 Orchestration
任務中斷時，誰接手、怎麼接？
產品要能把任務交給代理人，也要在需要人判斷時把脈絡交回來。例如在後台按下一個鍵讓代理人接手，但遇到例外時，人能看到它做到哪裡、為什麼停。只丟一句「請洽客服」，等於讓整段任務從頭再來。
設計時看的是產品缺什麼；實際跑任務時，看的是它卡在哪一步。下一節把同一筆訂位拆成三種結局，會比較容易看出兩者的差別。
04
代理人訂位失敗的三種情況
把「今晚 19:00，兩位」交給代理人，不一定會訂位成功。它可能在登入時停下，可能停在等人確認，也可能收到成功訊息，卻無法證明訂位真的存在。
使用者問「今晚 19:00，幫兩位找一家餐廳並訂位。」
代理人需要登入才能繼續
- 理解需求19:00，兩位
- 進入訂位需要登入
- 繼續執行等待使用者
交接：請使用者先完成登入
怎麼檢查先確認代理人能不能完成登入。需要驗證碼、簡訊或既有帳號時，把步驟交回人；人完成後，流程要能從原本的地方接下去，而不是重新開始。
交給使用者確認時沒有帶上訂位條件
- 查詢空位有合適座位
- 人類確認餐廳與條件
- 送出訂位等待確認
決定交給人，脈絡一起交接。
怎麼檢查把餐廳、時段、人數與取消條件一起交給人確認。只問「要不要訂？」不夠，人要知道自己正在同意哪一筆交易。
工具回覆成功但沒有可核對的訂位紀錄
- 餐廳、日期、時間與人數
- 可核對的訂位紀錄
- 後續修改或取消方式
怎麼檢查把工具回覆整理成可核對的紀錄：餐廳、時間、人數、訂位編號與修改方式。代理人回報完成之前，狀態要先對得上。
產品端要準備什麼？看四個環節 ↓
05
任務閉環
任務閉環指一筆任務從開始到確認完成的完整過程。以訂位為例，會經過四個環節：可發現、可執行、可驗證、可恢復。任何一環斷掉，代理人都得停下來，或把問題丟回給人。選一個環節，看產品要準備什麼、事後能觀察什麼。
Discoverable
讓代理人知道工具能做什麼
操作線索（Signifier）・語義明確性・選用傾向（Propensity）
如何設計
把查空位與建立訂位拆成兩個工具，例如 search_tables 與 reserve_table。名稱說動作，描述說能力，參數說格式，還要寫明什麼情況下不能呼叫。
查今晚空位 → 選時段 → 建立訂位
觀察什麼
- 功能辨識率
- 正確工具選擇率
- 無效探索步數
Executable
依步驟分開授權並由人確認送出
可操作性（Affordance）・最小權限・人機協同
觀察什麼
- 授權後操作成功率
- 權限阻礙率
- 單次任務成本
Verifiable
用可核對的狀態確認成功
狀態回饋（State Feedback）・結果導向驗證
觀察什麼
- 結果驗證準確率
- 誤判成功率（False Positive）
- 誤判失敗率（False Negative）
Recoverable
中斷後讓任務可以接續
容錯設計・冪等性（Idempotency）・安全停止
觀察什麼
- 錯誤恢復率
- 重複訂位率
- 高風險異常安全停止率
挑一個最常發生的任務，讓代理人從頭跑到尾，只記錄第一個中斷點：它找不到入口、看不懂工具、沒有權限，還是無法確認結果？先修那一點，通常比一次補完四份文件有效。
06
常見問題
AX 是誰提出的？
AX 由 Netlify 執行長暨共同創辦人 Mathias Biilmann 在 2025 年 1 月提出，原文是〈Introducing AX: Why Agent Experience Matters〉。本頁的四個檢查點，對應他在 2026 年 1 月〈One Year of AX〉中的存取、上下文、工具與編排四個領域。
AX 和 UX、DX 有什麼不同？
UX 設計給看畫面操作的人，DX 設計給讀文件接 API 的開發者，AX 設計給替人辦事的 AI 代理人。代理人拿到一句目標就自己找路，所以入口、工具、參數與錯誤回覆都要能直接操作。
AX 和 GEO、TSO 有什麼不同？
GEO 處理 AI 回答裡有沒有提到、引用你；TSO 處理代理人有沒有選到你的工具；AX 處理代理人真的把任務做完。三件事會互相影響，但發生的位置不同。
一般品牌網站要先從哪一塊開始？
別急著把四個領域都補齊。先挑一個真實任務，讓代理人從頭操作一次，找出第一個中斷點，再從那裡修。通常會比先寫完一套文件更快看到問題。
AX 只跟有 API 的產品有關嗎？
不用。網站本身就是代理人會讀、會點的介面。沒有 API 時，先把產品資訊、聯絡方式與人工接手流程整理清楚，還是能改善 AX。
代理人出錯時，怎麼把任務交回真人？
逾時後先查訂位狀態，需要重試時沿用同一筆操作的冪等鍵，避免重複訂位。遇到無法處理的狀況就停止，把做到哪裡、為什麼停交還給人，而不是只丟一句「請洽客服」。
代理人回報「已完成」，就代表訂位成功了嗎？
不一定。工具回覆成功之後，還要有可核對的紀錄：餐廳、時間、人數、訂位編號與修改方式。代理人要分得清「已送出」與「已確認」，才不會把處理中當成完成。
代理人需要的權限，要全部開放嗎？
不用。查空位、暫留座位與送出訂位可以分開授權，讓代理人只做範圍內的事；真正送出前，把時段、人數與取消條件交給人確認。
07
四個研究主題的關係
GEO 看自然回答裡的提及與引用，TSO 看代理人選用哪個工具，AX 看任務能不能完成，AI 廣告看回答下方的付費版位怎麼配對與轉換。四者處理相鄰的問題，可依內容交叉閱讀。
