公開動態與原創分析 · 消息日期: · 消息來源
顧客請自己的 AI 助手向商家查詢退貨方式，助手應讀網頁、呼叫 API，還是聯絡商家的客服 Agent？Sierra 於 11 月 13 日發布 Personal Agent Protocol 1.0，簡稱 Poppy，為這次接觸提供共通的服務探索與互動規則。企業面對的新工作，是清楚說明既有服務，讓外部助手找到入口及存取條件。
Sierra 同時表示，Shopify 已讓平台商家發布 Poppy 檔案，Meta 的 Muse 會優先檢查網站是否支援。這些屬於發布方揭露的採用情況，無法據此推定所有商家的售後事項都能由 Agent 自動完成。探索檔案能說明入口，訂單查詢、退貨受理與款項處理，仍取決於商家實際開放的服務及規則。
探索資訊如何對應既有服務
Poppy 1.0 規範涵蓋探索、身分、帳戶存取，以及 API、網頁和對話等互動方式。企業透過 poppy.json 公布相關入口。規範明確指出，這些組成並非必須依序完成的採用層級，企業可自行選擇提供管道。已有可存取網頁的商家，可以先說明網頁入口，無須為採用協定先建置所有介面。
設想一家客製商品商家，希望個人助手代顧客詢問交期並處理售後，這是分析用的假設情境。公開製作週期可從網頁取得；某筆訂單是否已投入生產，則需要訂單系統的現況。同樣叫作「查交期」，所需資料及授權卻不同。寬泛的能力名稱，可能讓接入說明超出後台可提供的資訊。
較有用的整理方式，是沿請求對象核對既有服務。公開政策有沒有明確入口，帳戶查詢能否回傳正確顧客的紀錄，辦理動作能否區分受理及完成。缺少 API 時可保留網頁或客服管道；客服若也只能查一般政策，就應說明如何取得訂單細節。可交付的服務決定開放範圍，檔案負責表達這個範圍。
協定連接多種管道，讓助手有機會依企業指定方式處理，減少猜測入口。相對成本是共同維護入口、文件與後台行為：網頁路徑、API 欄位或客服可辦事項變更時，探索資訊也須更新。若沒有維護負責人，多發布一份檔案，可能只多出一處過時資訊。
帳戶權限與個別辦理條件
Poppy 以 OAuth 處理帳戶存取，並區分請求身分、工作階段連續性與帳戶存取。讀取公開政策，以及取得某位顧客訂單的查詢權限，具有不同條件。企業可先清楚提供無須帳戶資料的諮詢，再依需求開放帳戶功能；這是業務選擇，並非規範強制的升級次序。
以上述假設商家而言，查詢訂單狀態、申請修改收件地址，以及取消已投入生產的商品，後果各不相同。如果後台把這些動作放在同組過寬權限，一次登入就可能讓助手取得超過目前任務所需的能力。對話提醒難以彌補這項設計，應由實際執行的服務限制可讀紀錄及可寫動作。
帳戶同意與業務同意也須分開。顧客允許助手存取帳戶，代表授予相應存取權；訂單是否仍可修改，取決於當下狀態及商家規則。涉及費用、交付變動或難以撤銷的動作，可以先呈現明確對象及後果，再取得對應確認。採用協定無法取代後台對訂單及操作條件的判斷。
因此，早期不宜以開放動作數量為目標。需求主要是政策諮詢時，穩定的公開入口已可能有用；確有大量帳戶查詢時，才值得負擔身分、工作階段、權杖與支援工作。是否繼續開放修改，應依既有服務的錯誤處理及顧客確認機制決定，無須因版本進入 1.0 就擴大範圍。
無法辦理的任務與業務狀態
Poppy 的任務涵蓋設計，讓企業列出不提供的任務及替代途徑；對話管道也定義轉人工。整個管道不提供某項服務，與某位顧客的訂單不符合條件，需要分別說明。規範將帳戶相關限制留給實際請求的錯誤回應。
客製商品若完全不接受透過 Agent 申請某種特殊修改，可指向能說明選擇的人工管道；一般地址修改已開放，但某訂單已出貨，則應在該次結果說明限制。全部回成「暫不支援」，顧客便無從判斷該換管道、補資料，還是接受辦理條件已改變。
企業亦須區分已發起與已完成。要求轉人工後，是否有人加入要有真實狀態；提出退貨申請後，是否核准要看業務結果。規範還明定，關閉對話不會取消對話中發起的訂單或退貨。顧客結束聊天之後，業務紀錄仍須依原規則處理，避免把介面狀態當成交易狀態。
已有線上業務的團隊，可先核對一項真實高頻服務：顧客從何處進入、何時需要帳戶、最後得到什麼結果，以及受限後如何繼續。官方企業實作工具包提供驗證器，也保留紀錄與同意措辭等人工檢查項目。協定檢查能找出實作缺漏，顧客工作是否確實辦妥，仍須由完整服務過程證明。
消息來源
墨客雲編輯部 · neo@mokyun.com
