首頁 / 技術文章 / Agentic Web 是什麼？網站開放 AI 代理操作的能力分級與權限界線
技術文章
Agentic Web 是什麼？網站開放 AI 代理操作的能力分級與權限界線
網站要支援 AI 代理互動，應先開放公開資訊讀取與受限查詢，再逐步開放草稿、經人工確認的提交及交易。Agentic Web 的準備重點，是界定代理能做什麼、誰授權，以及出錯後如何處理。
Agentic Web 的核心：代理代表使用者完成任務
《Agentic Web: Weaving the Next Web with AI Agents》將 Agentic Web 描述為自主、目標導向的互動型態，代理會彼此互動，代表使用者規劃、協調並執行複雜任務。這個定義的重心在任務執行：代理取得資訊之後，還可能繼續比較選項、安排流程與採取行動。
從網站經營的角度看，這意味著設計問題將從內容是否容易理解，延伸到操作是否能被可靠執行。商品說明讀得懂，不代表代理知道報價是否仍有效；表單欄位辨識正確，也不代表使用者已授權送出。本站的判斷是，資訊理解與操作授權應分開設計，不能因為代理能讀取頁面，就一路開放到交易。
W3C AI Agent Protocol Community Group的使命，是開發讓代理能在 Web 上發現、識別與協作的開放互通協議，工作範圍也涵蓋身分模型、標準化中繼資料、安全與隱私機制。這支持一個重要判斷：Agentic Web 涉及的設計範圍，遠超過新增一份網站說明檔。社群群組的工作方向，也不能直接解讀為已完成的全球通用正式標準。
agent.json 能宣告能力，實際授權仍須另外設計
Agent Web Protocol（AWP）文件目前標示為 Draft RFC，將 agent.json定義為放在網域根目錄的機器可讀檔案，用來說明代理可以做什麼、需要哪些輸入，以及如何從錯誤中復原。這是 AWP 提出的實作路徑，不能據此推定所有代理都會採用，或把它視為 W3C 已核定的共同要求。
Agent Handshake Protocol（AHP）草案白皮書也主張由網站發布機器可讀的 manifest，宣告能力、可回答內容、可採取動作與限制。這類提案有助於把互動條件寫清楚，但在權限設計上，網站仍應區分能力存在、代理身分與使用者授權。宣告提供取消訂單功能，不應被當成任何代理都能取消任何訂單的依據。
較穩健的做法，是讓宣告內容對應到實際執行時的檢查：哪些資料可公開查詢、哪些操作必須登入、授權涵蓋哪個帳戶與哪項任務、遇到什麼情況必須停下來。manifest 可以作為入口；本站建議，真正的權限界線應由網站在接受請求時落實。
代理互動分級表：從公開讀取到受控交易
以下分級是本站提出的決策框架，並非任何協議的官方等級或認證。網站可依操作造成的影響選擇開放程度，不必把所有功能推到最高層。內容網站可以停在讀取與能力宣告；涉及預約、帳戶或交易的服務，則應逐項判斷權限。
| 層級 | 可開放的能力 | 建議保留的界線 |
|---|---|---|
| 第 0 層：公開讀取 | 讀取公開內容、產品說明與政策 | 不含私人資料、帳戶操作或資料修改 |
| 第 1 層：能力宣告 | 說明網站可回答哪些問題、提供哪些能力 | 明列不支援的任務與必要條件；宣告不等於授權 |
| 第 2 層：結構化查詢 | 取得結構化資料、可用選項或報價 | 交代適用條件與有效範圍；查詢不應暗中建立預約或扣款 |
| 第 3 層：草稿與預填 | 準備草稿、預填表單、組合待確認選項 | 保留為可檢視、可丟棄的暫存結果，不對外送出 |
| 第 4 層：確認後提交 | 由代理準備提交內容，經人類確認後送出 | 確認須對應實際內容、對象及後果；內容改變應重新確認 |
| 第 5 層：授權內執行 | 在明確委派範圍內執行交易或變更狀態 | 需要更嚴格的身分、權限與範圍檢查；超出條件即停止 |
| 第 6 層：完整治理 | 留下操作記錄，提供授權撤回、錯誤復原與責任追蹤 | 屬於前面各層的治理要求，不能等全面開放交易後才補做 |
分級應依操作後果判定，不能只看按鈕名稱。若儲存草稿會通知外部人員，或查詢時就占用庫存，本站建議將其按具有外部影響的操作處理。涉及私人資料的唯讀查詢，也應另外檢查存取權限；讀取行為本身不會修改資料，並不代表資料適合公開。
第 6 層也不是額外放大代理權力。它用來提醒經營者，開放能力時必須同步安排治理。即使只允許草稿，也應交代草稿保存在哪裡、誰能查看；開始接受提交後，就應能查明提交內容與確認依據。撤回未來授權、取消待辦操作，以及補救已完成交易，則應分別設計，避免把它們統稱為撤回而留下責任空白。
用預約流程檢查人工確認的邊界
以假設的預約網站為例，第一版可以讓代理讀取服務內容、查詢可預約時段與費用，再準備待確認的預約草稿。查詢結果宜附上適用條件，並清楚說明取得時段資訊是否代表保留名額。如果網站無法提供可驗證的保留狀態，就不應讓代理把查詢結果表述成預約成功。
進入提交階段時，建議讓使用者確認服務項目、時間、費用、取消條件及將送出的個人資料。若確認後費用或時段已改變，應重新取得確認，而非沿用先前同意。代理能替使用者準備選項，與代理有權接受新條件，應是不同的授權。
提交結果也應能核對。本站建議，回應應清楚區分已接受、仍在處理、失敗與狀態未知，並提供後續查詢方式。若代理未收到明確結果，流程應優先查詢既有操作狀態，再決定是否重試。這是降低重複提交風險的設計建議，並非現有提案已保證的共同能力。
能被摘要、能被引用，仍不足以證明可以代理操作
《Designing Agent-Ready Websites for AI Web Agents》提出的框架涵蓋可讀性、可解釋性、可驗證性與可行動性，並指出現有 SEO 與 GEO 指標無法完整評估網站支援代理互動的能力。因此，本站建議把內容是否被找到或引用，與任務是否在授權範圍內正確完成，分成不同的評估問題。
對產品團隊而言，驗收可以從具體情境開始：條件缺漏時是否拒絕提交、使用者取消後是否停止、報價改變後是否重新確認、結果未知時能否查明狀態。對行銷與經營團隊而言，則不宜把加入 manifest 直接當成曝光或轉換成長的承諾；目前資訊不足以證明這種必然關係。
權限政策可延伸閱讀本站的代理存取政策與操作界線；如果眼前的問題仍是 AI 搜尋是否取得內容，可先參考AI 搜尋取得網頁的判斷方式。先分清內容存取與任務執行，才容易找出真正需要修改的環節。
開放下一層能力前，先確認網站能承擔後果
目前資訊仍不足以判斷哪種宣告格式會成為主流、主要代理是否一致遵守，以及跨平台交易責任會採用哪些通用規則。網站可以先整理資料與操作條件，但不宜把這些尚未確定的部分，當成已由協議處理好的前提。
對多數網站，較合理的第一版是公開資訊、能力宣告、受限查詢與可檢視草稿。下單、付款、正式送出表單及帳戶變更，應在確認機制與更高權限就緒後才逐步開放。判斷是否進到下一層的依據，應是網站能否說清楚誰授權、實際改了什麼、結果如何核對，以及失敗由誰處理；這些問題沒有答案，就應保留人工確認或暫停開放。
常見問題
網站放上 agent.json，就算支援 Agentic Web 嗎？
不能只用檔案是否存在來判斷。AWP 文件用 agent.json 宣告能力、輸入與錯誤復原方式，但網站仍應落實授權檢查、操作限制與結果核對。目前也無法確認所有主要代理都會採用這個格式。
第一版應該讓 AI 代理直接下單或付款嗎？
對多數網站，建議先提供查詢、報價與草稿。正式提交先採人工確認；只有在委派範圍、身分與權限檢查、結果驗證及錯誤處理都明確後，才考慮開放授權範圍內的自動交易。
代理互動分級是 W3C 或 AWP 的官方標準嗎？
不是。這是本站用來協助網站決定開放順序的編輯框架。治理層也不代表取得更多操作權限，而是要求記錄、撤回與復原能力隨風險提前導入。
Agentic Web 會取代 SEO 或 GEO 嗎？
目前沒有足夠依據確認取代關係。較合理的判斷是，網站的評估範圍會從內容能否被找到與引用，延伸到代理能否理解限制、取得授權並可靠完成任務；兩者應分開驗收。