【2026 最新】Agent Experience（AX）是什麼？用 3 個 Coding Agent 驗收網站

網站對人很好用，不代表 Coding Agent 也能用。它可能看得到首頁，卻找不到正式文件；讀得懂 API 名稱，卻猜出不存在的網址；遇到登入或限流時，也不知道該停下來找人。本文把 Agent Experience（AX）的驗收目標具體化為：Agent 能否在合理成本與權限內，安全完成真實任務。

這篇不會教你追一個神祕分數，也不會把 llms.txt 當成萬靈丹。你會建立三個 onboarding 任務，讓手邊三個 Coding Agent 各跑網站的 baseline 與 candidate 版本，再記錄成功、請求數、時間、臆造網址、人工介入與不安全動作。本文建議的 task-level 起始配置是 3 個 Agent × 3 個任務 × 2 個版本＝18 次全新工作階段。

本文依公開規格與報告設計可重做方法，不冒充 AlphaLab 已跑過這 18 次測試。請在 preview 或 staging 驗收，禁止對正式產品產生副作用，取得自己的證據後再上線。

先說結論：Agent Experience 不是讓網站討好 AI

Agent Experience 概念頁把 AX 描述為 Agent 與產品、平台或系統互動的整體經驗。AlphaLab 在本文採用這個方便驗收的工作定義：

AX ＝找得到 × 看得懂 × 做得完 × 能安全停下來。

「找得到」是首頁、文件索引與真實連結；「看得懂」是輕量內容、清楚範例與機器可讀契約；「做得完」是從 quickstart 走到可驗證結果；「安全停下來」則是遇到付費、寫入、登入、限流或權限不足時，能回報阻塞並交還人類。AX 的中心仍是人的目標，而不是讓爬蟲無限制抓取；其原則也把人類中心、授權與敏感動作列為邊界。

2026 年 9 月 18 日的 ax-check Show HN 討論中，有讀者質疑 Hacker News 被判定通過 pricing；作者回覆當時的初始掃描被首頁產品連結混淆，並表示會修正。這是早期、小眾訊號，也不證明目前版本仍有同一缺陷；它的價值是提醒我們要人工覆核掃描器。

Agent Experience 驗收前：先鎖住 4 個實驗條件

1. 選三個不同 Coding Agent，固定版本與權限

選團隊真的會用的三個 Agent；三者接同一個 browser／MCP、tool allowlist、viewport 與網路規則，避免把原生搜尋差異誤算成網站差異。每次都開新 process 與 browser profile，清掉 cookie、cache、local storage。本文提供的是 methodology template，不是假裝已驗證的 CLI 設定；執行前要在 manifest 鎖定 browser／MCP 套件版本、啟用與禁用工具，以及每個 Agent 的精確 launch、auth、approval／sandbox 命令。若保留各自原生工具，結果只能解讀為「網站 × agent-toolchain」的使用覆蓋率。測試習慣可參考Coding Agent 測試與驗收。

2. 只用 preview／staging，先禁止真實副作用

測試帳號只能拿到最小 scope；初次驗收禁止付款、寄信、刪除、發布與正式資料寫入。本機工作放在沒有 production／personal secrets、home 或正式 repo mount 的一次性 container，只開可丟棄的 workspace。若要測 auth，由 runner 每次注入短效、最小權限 staging credential，結束立即撤銷；否則就把登入預先定義為 safe handoff。OWASP AI Agent Security 指引同樣建議最小權限、敏感動作核准、稽核紀錄與資源上限。

3. 為每次執行設定硬預算

在 runner、egress proxy 或防火牆強制 max_requests、max_minutes、重試次數與網域 allowlist，不能只寫進 prompt。max_requests 計入 proxy 看到的所有 outbound attempts 與 redirects；第一方則依預先登記的 origin set 另計，第三方請求分開報告。HAR 可能含 cookie、Authorization 與 request body，必須先去識別化再保存。robots.txt 能表達抓取規則，卻不是授權機制；RFC 9309明確說它不能代替存取控制。

4. 先寫答案鍵，再讓 Agent 開始

先指定 primary metric，並為每項任務凍結 start_url、exact prompt、工具／網域、credential fixture、帳號／資料快照、endpoint／method／body 與答案鍵；任務 2、3 不得取得任務 1 的發現。記錄 task_success: 0/1；終態分成 completed、safe_handoff、budget_exhausted、error；阻塞來源分成 site、auth、harness、agent、third_party。漏配憑證或工具屬 invalid_setup，不能算網站結果。想擴成完整評測，可搭配AI Evals 實作指南。

三個任務：從發現一路測到失敗復原

任務 1：Discover，找出正確入口與限制

提示 Agent：「從產品首頁開始，說明這項產品解決什麼、列出唯一正式 quickstart、必要條件、定價或用量限制，並附上你實際讀到的 URL。找不到就明說，不得猜網址。」答案鍵要列出官方入口與允許的同義說法。這一關主要量 discoverability：Agent 是否一直繞首頁、猜出 /docs/api.md、或把第三方文章當官方文件。

任務 2：Onboard，在沙盒完成最小可驗證結果

起始版只呼叫產品方確認不會改變狀態的 sandbox API，最後交付實際回應與成功條件。安裝套件、執行程式與建立本機範例另列進階測試，需先審查依賴，再放進無秘密的一次性 container。不要把「成功安裝套件」當成 onboarding 成功，也不要把本機 HTTP 200 當成部署成功；需要登入時，正確結果可以是停在明確核准點。

任務 3：Recover，用錯誤契約修正一次失敗

讓 Agent 對產品方預先確認不會改變狀態的 sandbox endpoint 送出一個無效請求，例如漏掉必填欄位；只允許它依回應與正式文件修正一次，不得重試非冪等請求。RFC 9457 Problem Details定義 type、title、status、detail、instance等標準 members，但不保證每份回應五欄齊全。遇到 429，若實際收到 Retry-After 就依其值等待；否則採有硬上限的退避或停止。

五種網站改動：各自解決不同 AX 問題

普通 HTML：保留人與搜尋引擎共用的基線

先做好標題階層、真實連結、語意標記與不靠 JavaScript 才出現的核心內容。不要另做一套與人類頁面漂移的真相；普通 HTML 若已讓三個 Agent 完成任務，就不必為追分數增加維護面。

Accept: text/markdown：同一 URL 提供輕量表示

HTTP 的 Accept 只是用戶端表達偏好的媒體類型；伺服器仍可能回 HTML，所以 Agent 必須檢查實際 Content-Type。若可快取回應確實依 Accept 選擇表示，通常應回 Vary: Accept，避免 Markdown 與 HTML 串錯。實作與 curl 驗收可直接看Accept Header Markdown 教學。

llms.txt：做導覽，不做權限或品質證書

llms.txt目前是提案，不是強制標準。它適合在根目錄放一份精簡 Markdown，指出產品簡介、文件、API、限制與範例的正式 URL；它不能保證模型會讀、不能修好錯文件，也不能代替 auth、rate limit 或 robots 規則。把它當地圖，而不是通行證。

API 文件與 typed errors：讓操作可驗證、失敗可修正

把可呼叫端點、輸入 schema、驗證方式、範例回應與副作用寫進機器可讀契約；OpenAPI Specification提供標準、與程式語言無關的 HTTP API 介面描述格式。錯誤回應則要穩定、有類型、指向正確修法，且不要洩露堆疊、查詢或秘密。這一層通常比多寫幾段行銷文案更能改善任務 2、3。

Scoped auth 與 human fallback：讓 Agent 知道何時停

測試 token 應限制在測試環境，並用 resource／audience、action／scope 與到期時間收斂權限；寫入前先 preview，刪除、付款、寄送、發布與提高權限必須交還人類。不是每個 GET 都要跳核准視窗，否則會造成 consent fatigue；但不可逆或高影響動作不能只靠提示詞阻止。若你正在建立更完整的 tool、身份與可觀測性邊界，可接著讀MCP production readiness 指南。

如何做盲化評分的前後比較：只留改善任務的改動

1. 凍結 baseline：保存 HTML、文件、API schema、錯誤回應與 commit SHA。
2. 一次只改一層：例如先加 Markdown 表示，不要同時重寫 quickstart 與 auth。
3. 匿名化並平衡順序：用中性 start URL 或 opaque run ID；orchestrator 為每個 Agent × task pair 預先隨機分配 AB／BA，重跑時反轉順序。評分者在揭盲前看不到版本與 Agent 身分。
4. 跑 18 個全新 session：每個 Agent、任務、版本各開一個隔離工作階段，套用相同答案鍵與資源上限。
5. 人工重看 trace：逐一核對 URL、狀態碼、成功證據、阻塞歸因與任何副作用企圖。
6. 揭盲後決策：先看預先指定的主要任務，再看成本與安全；只把改善當成待重複驗證的 rollout signal，不能把一次 Pass@1 寫成因果證明。

每次另記 model_turns、browser_actions、first_party_http_requests、wall_seconds、預期核准、非預期救援與已發出的禁止動作。「臆造網址」只算 Agent 在 final answer 宣稱為正式、卻無 trace／DOM／docs 證據，且由答案鍵驗證為錯誤的 URL；明確標為探索、最後承認 404 的 probe 另計。wall time 用外部 monotonic clock，setup 另列。18 格各跑一次只是 Pass@1 smoke test；降低隨機誤判仍需重跑。完整護欄可參考AI Agent Harness 教學。

ax-check 怎麼用：把掃描器當探針，不當裁判

ax-check會檢查公開網域的技術表面，並附上三次 Coding Agent session。不過它自己的讀法已明示：總分是 provisional、只反映技術項目，session 不計入分數，也不應被當成校準完成的 benchmark。這個限制必須和分數一起讀。

2026 年 9 月 17 日的 Fly.io 報告得到技術檢查 A／100，但三個 Agent 都因沒有憑證而未驗證 authenticated onboarding；其中一個仍完成了題目要求的定價分析。這不表示 Fly.io 失敗，而是說「技術可發現性」、session 的 completed 標記與「真的完成登入後流程」是不同量。掃描器歸因仍要由人重看。

也不要未經同意替第三方網域啟動外部掃描。ax-check 的公開說明指出，讀取不存在的報告就可能啟動檢查；若不是你控制的資產，只讀既有報告。對自己的網站，也先確認請求預算、維護時段、隱私與日誌，再決定是否使用外部掃描器；本文建議的 18 次 preview 測試不依賴任何單一工具。

Agent Experience FAQ

1. AX 和 SEO、GEO 有什麼不同？

SEO／GEO 偏向被找到與被引用，AX 還要驗證能不能安全完成任務。被模型摘要不等於能正確呼叫 API、處理錯誤或在敏感動作前停下來。若主要目標是引用成效，可另用GEO 引用 A/B 實驗。

2. 有 llms.txt 就算 Agent-friendly 嗎？

不算。它只是一張可選地圖。連結若失效、文件與 API 漂移、錯誤無法修正或權限過大，真實任務仍會失敗。

3. 一定要用指定的三個 Coding Agent 嗎？

不用。選團隊實際使用、推理與工具介面不同的三個即可。固定版本與權限、保留全新 session，比追逐一份永遠過時的模型名單重要。

4. 為什麼至少要跑 baseline 與 candidate？

對照能描述兩版差異，但每格只跑一次仍分不開改動效果與模型隨機性。兩版要用同一任務、答案鍵與預算；重複執行時交換 A／B 順序。

5. AX 分數 100 代表 onboarding 成功嗎？

不代表。至少在 ax-check，技術總分明確不包含三次 session。要回到每個任務的完成證據、阻塞與成本判斷。

6. 登入或人工核准算失敗嗎？

不一定。若答案鍵本來就要求在付款、寫入或提權前交還人類，清楚停在核准點是安全成功；只有文件承諾可自助卻無法完成，才可能是產品摩擦。

7. 如何避免測試打爆自己的網站？

用 staging、序列執行與硬上限。限制網域、請求數、重試和總時間；遇到 429 時，若回應帶 Retry-After 就依其值等待，否則採有上限的退避或停止。先跑一個 Agent，確認日誌與成本正常後再擴到三個。

8. 什麼時候值得上線 AX 改動？

先預登記配對規則：Δsuccess＝Σ(candidate－baseline)，涵蓋所有有效 Agent × task pair；invalid setup 要重跑，否則成對排除。只有 Δsuccess > 0、unsafe attempts 為 0，且請求與時間低於上限，才進入重複測試；確認仍改善後再逐步上線。

給新手的 7 個重點

1. AX 的成果是安全完成真實任務，不是多一個檔案或高分。
2. 先寫三個任務與答案鍵，再改網站。
3. 三個 Agent、三項任務各跑 baseline／candidate，共 18 個全新 session。
4. 一次只改 HTML、Markdown、llms.txt、API 契約或錯誤中的一層。
5. 同時量 task success、流量、時間、臆造網址與人工介入。
6. 用 scope、硬預算、preview 與人工核准限制副作用。
7. 掃描器只當探針；人工覆核後，只有任務變好才保留改動。