Personal Agent Protocol 草案解析：Poppy 如何讓個人 AI 取得授權、跨網站辦事？
Personal Agent Protocol 已公開 Poppy 0.1 草案。本文解析個人 AI 的探索入口、登入授權、跨介面工作階段與撤銷權限，並以購物售後案例說明企業導入前需要完成的驗證。
Personal Agent Protocol 想解決的問題，是讓企業知道 AI 正替誰辦事，以及這個人允許它做到哪一步。
我們可以請個人 AI 查訂單、找替代商品，真正進到帳號與交易流程後，企業卻需要更多資訊。
知道對方是 AI，還不足以判斷它能否看資料、修改訂單，或替使用者作出承諾。
Sierra 在2026年10月9日公開了名為 Poppy 的協定草案，讓這些問題有了可討論的介面。
它建立在既有網路標準上，嘗試把登入、授權與不同辦事管道接成一致流程。
對企業來說，現在適合研究與做小範圍試點，還不能把設計夥伴名單當成全面部署的證明。
理解這份草案，可以從最貼近日常的一個問題開始：讓 AI 查訂單，為什麼不等於允許它改訂單？
Personal Agent Protocol 的核心是委託邊界
協定是不同系統共同遵守的溝通規則。Personal Agent Protocol 關心的是個人代理與企業之間的互動，讓雙方能辨認身分、建立連線，再依權限提供服務。
個人代理代表消費者，企業則保留自己的服務規則。消費者可以選擇授權哪些操作，企業仍要判斷這些操作是否符合帳號權限與業務條件。
這兩層規則同時存在，才適合真正的辦事流程。使用者說「幫我處理訂單」，可能是在要求查詢進度，也可能是在要求取消。系統不能只憑模糊一句話決定後續所有動作。
可以把它想成委託同事辦事。同事需要知道你希望完成什麼，而服務窗口也需要知道他有沒有代辦權限，以及哪些操作仍須你本人確認。
Poppy 提供共同的互動方式，卻不會替每家企業決定所有流程。店家的退貨條件、可變更項目與確認時機，仍由店家自己的系統落實。
公開草案與正式服務有什麼差別？
官方規格標示為0.1草案，並明確說明穩定版本之前可能有不相容的改動。這代表今天寫好的串接，未來仍可能需要調整。
Sierra 的發布文章也說明，新增夥伴參與的是設計流程，後續還有工作坊與參考實作計畫。名單可以反映參與意願，不能直接證明消費者已能在每個品牌使用。
因此，讀這項新聞最有用的方式，是看共同問題是否被拆清楚。對正在做個人代理的團隊而言，這份草案能幫忙整理接口。對一般消費者而言，實際可用性仍應逐家確認。
從發現企業到取得授權，流程如何接起來？
一個代理要替你辦事，第一步是找到企業正式提供的入口。Poppy 讓企業在固定位置發布說明文件，告訴代理如何開始工作階段，以及有哪些登入與服務方式。
工作階段可以理解成同一次拜訪的紀錄。代理查資料、與企業對話、再進入網頁操作時，企業需要知道它們屬於同一個辦事過程。
這種連續性對售後流程尤其重要。前面已經確認商品與問題，後面取得帳號權限時，不應又把它當成完全無關的訪問，要求客戶重講全部內容。
固定入口能減少哪些猜測？
草案的探索文件放在 /.well-known/poppy.json。代理可以從這裡找出企業公佈的連線方式，減少自行猜測接口或反覆搜尋網頁的工作。
但文件出現在某個網址，還要確認它真的代表目標企業。草案也安排驗證企業網域與登入服務的關係，避免代理因為讀到一份看似合理的文件，就把授權交給錯誤對象。
這項設計對一般讀者的意義很直接：代理不能只相信頁面上的品牌名稱。企業來源的驗證，必須由實作完成，才能支撐後續登入與資料存取。
登入與授權應分別看待
登入回答你是誰，授權回答你允許代理做什麼。即使已經知道帳號身分，企業仍要限制代理能讀取與修改的內容。
Poppy 以 OAuth 等既有標準承接這個流程。OAuth 是讓使用者授予特定存取權的方式，可以把「允許辦事」與「把完整帳號交出去」分開處理。
對產品設計而言，授權頁面的用語非常重要。若只寫「同意連線」，讀者可能不知道它包括查訂單、更新地址，還是其他變更，後面的規則就難以被理解。
較好的方式是讓使用者看到具體用途。即使底層用同一套協定，每個產品仍需用清楚的文案，說明將讀取什麼資料、什麼操作會再要求確認。
跨網站、API 與企業代理，為什麼需要同一段脈絡？
企業不必只用一種介面服務個人代理。官方草案涵蓋網頁、API 與企業自己的代理對話，可以依任務選擇適合的管道，詳見協定官方說明。
API 是系統之間交換資料與請求的介面。查詢庫存可以走結構化介面，需要補充問題的售後服務則可能透過對話，最後的確認也可能回到網頁。
這些切換本身並不罕見，難的是每個環節都要認得前面的使用者與權限。如果切到新管道就失去脈絡，流程會回到人工重填資料的狀態。
共用工作階段，不等於共用全部權力
即使是同一段辦事過程，每個操作仍應檢查權限。能讀取訂單，不自然推出能改付款方式。能建立退貨申請，也不自然推出能接受所有替代條件。
這是企業導入時需要特別確認的一步。若只確認代理能登入、能對話，就把所有接口打開，介面雖然串通，委託邊界仍沒有落實。
產品團隊應把每個服務動作寫成可檢查的條件。例如已登入且具備查詢權限，才回傳個人訂單。變更類操作則另看使用者授權與業務規則。
這些條件應在企業服務端執行。代理的自然語言保證可以協助溝通，但不宜成為唯一的權限判斷，因為系統需要能穩定檢查與拒絕操作。
MCP 和 Poppy 各自處理什麼？
MCP 是讓代理使用工具的共同介面，Poppy 則還處理個人代理如何代表使用者與企業互動。兩者可以搭配，不能單憑一個工具能被呼叫，就判斷代辦授權已經完成。
這個分工能幫團隊避免重複建設。如果企業已有工具接口，可以先評估如何承接工作階段與權限，而不是因為新協定出現，就把原本服務全部重做。
是否需要企業自己的對話代理，也應由任務決定。簡單資料查詢未必需要多一層對話。需要釐清問題與處理例外時，對話才可能降低使用者負擔。
用一個售後案例，看清楚 AI 可以做到哪一步
以下是說明用的假設情境：使用者買了一盞桌燈，收到後發現尺寸不合，希望代理協助比較換貨與退貨。這不是特定品牌已上線的服務。
代理可以先查公開政策與替代商品，不必立刻取得個人帳號資料。這樣能讓使用者先理解選項，再決定是否授權查詢訂單。
當流程需要實際訂單時，才進入企業提供的登入與授權方式。產品應清楚告訴使用者，這次需要查哪張訂單，以及為什麼公開資料不足以繼續。
先整理選項，再確認會改變什麼
取得資料後，代理可以整理尺寸、差額與處理期限。這時仍是協助判斷，不能把使用者「比較一下」的要求理解成已決定換貨。
若使用者選擇換貨，下一個確認應呈現將變更的商品、相關金額與寄送安排。與其詢問抽象的「要繼續嗎」，直接顯示操作結果，更容易讓人發現錯誤。
企業收到操作請求後，還要確認商品是否符合條件。即使使用者授權代理辦理，也不能跳過企業原本的商品資格與帳號檢查。
最後，代理應取得企業回傳的結果，例如申請編號或目前狀態。介面上說「我已處理」，必須能對應到實際回執，才能讓使用者知道接下來該等待什麼。
卡住時應如何交回使用者？
如果商品缺貨或尺寸資訊不完整，代理可以解釋缺口並列出下一步。它不需要為了完成任務，替使用者接受另一個沒被批准的條件。
例如替代商品需要額外付款，就應重新取得決定。原本同意查訂單，不會自動涵蓋所有後續費用。這也是授權與產品確認需要配合的原因。
轉人工時，應保留已釐清的問題與已完成的操作。客服能接著處理，使用者也不必從頭描述，但敏感資料仍應依既有客服流程管理。
這個案例顯示，協定減少的是系統之間的摩擦。能否讓客戶放心辦事，仍取決於清楚的確認畫面、正確的權限與可查的結果。
企業導入前，先完成一條可以撤回的流程
企業適合從低影響的查詢流程開始，例如訂單狀態或保固規則。先驗證代理能否連線、辨識使用者與取得正確資料，再加入會修改狀態的功能。
第一條流程要同時包含成功與拒絕情況。測試代理拿到正確資料很重要，也要確認它沒有權限時，企業確實不回傳個人內容。
若企業只驗證成功路徑，很容易把網路連通誤當成授權完成。真正的驗收應包含帳號切換、權限不足與工作階段過期，才能看出邊界是否存在。
撤銷授權後，代理還能做什麼？
草案區分短期工作階段權杖與可支援後續登入的帳號憑證。權杖可以理解成系統用來辨認存取資格的通行證，期限與用途需要分開管理，詳見Poppy 授權規格。
因此，不能只刪除介面上的連線圖示，就宣稱所有存取立即結束。企業與代理實作需要依憑證類型檢查撤銷方式，並測試撤銷後的新請求是否遭到拒絕。
對一般使用者而言，產品應提供容易找到的已授權服務清單與解除方式。如果需要客服協助才能停止代辦，委託控制就仍不夠完整。
草案升版時，如何保留可維護性？
團隊應記錄使用的草案版本、支援管道與限制。未來規格改變時，先比較行為差異，再決定更新範圍，不要讓接口悄悄改動而無人知道。
建議把協定串接與業務規則分開。如此一來，即使工作階段格式改變，退貨資格與訂單檢查仍能維持，修改影響也比較容易確認。
擴大導入的前提，是一條流程已有清楚的完成率、例外原因與交接方式。只展示一次順利對話，還不足以判斷多帳號、重試或跨管道情況是否可靠。
Personal Agent Protocol 常見問題
一般使用者現在就能在所有夥伴網站使用嗎？
不能從設計夥伴名單得出這個結論。Poppy 目前是公開草案，各企業的實際服務範圍與開放時間仍要分別確認，示範也不等於全面提供。
我一定要把帳號密碼交給 AI 嗎？
不一定。草案包含在企業頁面登入的方式。產品應清楚說明採用哪種登入流程與允許的權限。使用者不應因為看到協定名稱，就假設每個實作的資料處理都相同。
它會取代所有電商與支付協定嗎？
Poppy 的重點是代理與企業之間的身分、授權與互動。購物或支付流程仍可能搭配其他標準，導入時應看各自負責的問題，而非只選一個名稱。
企業一定要先建立自己的聊天機器人嗎？
不一定。企業可以依任務提供網站或接口，對話代理是可選的管道。先讓既有服務能正確承接使用者與權限，通常更容易形成有價值的試點。
能被控制的代辦，才有機會走進日常服務
Personal Agent Protocol 的重要性，在於把個人 AI 的代辦問題拆成可實作的介面。它讓企業能討論誰在辦事、代表誰，以及允許完成哪些操作。
目前最合理的行動，是用草案研究一條真實流程，再測試授權、撤銷與交接。當使用者看得懂、企業查得到結果，跨系統的 AI 服務才有機會成為可靠的日常工具。
想持續追蹤 AI 科技新聞與開發工具解析，歡迎免費註冊 AI 郵報會員，訂閱後續文章。
延伸閱讀：Meta 與 Sierra 推 Personal Agent Protocol：個人 AI 如何與企業連線？
延伸閱讀：ElevenLabs 推出合成語音偵測：客服 AI 接到另一個 AI，該怎麼辨識？
資料來源
資料查核日期：2026年10月12日。本文售後流程為說明用情境，不代表特定企業已完成部署。
