Meta 與 Sierra 推 Personal Agent Protocol：個人 AI 如何與企業連線？
Meta、Sierra 與多家企業共同開發 Personal Agent Protocol，處理個人代理與企業的授權和連線。解析運作方向與預計於 10 月公佈的 v0.1 規格。
Personal Agent Protocol 想建立個人 AI 與企業之間的共通連線方式。使用者讓代理查商品、改訂單或處理服務時，企業需要知道它代表誰、得到哪些授權，以及可以做哪些事。
2026 年 10 月 6 日，Sierra 官方公告表示，正與 Meta 及 Genesys、Instinct、Rocket、Shopify、Stripe、Walmart 共同開發這個開放標準。公告規劃在 10 月稍後發布 v0.1 規格，因此現在應把它理解為共同開發中的協定方向。
個人代理需要比模仿點選更清楚的連線
個人代理是替使用者執行任務的 AI 助手。若它只能用一般網頁點按流程，可能要逐頁搜尋、填寫表單，遇到問題再打客服電話。企業也不容易區分一般訪客與已獲授權的代理。
Sierra 提出的方向，是讓企業提供一致的發現、登入與執行路徑。這有機會減少不必要的繞行，但是否更快，仍取決於參與企業實際開放了哪些操作。
消費者控制授權，企業決定操作範圍
協定的原則是，消費者決定給代理哪些存取權，企業則設定允許的操作。查詢商品可能以訪客身分就能完成，若要存取帳號或修改訂單，便需要相應授權。
公告使用 OAuth 這種讓服務取得有限存取權的標準建立會話。會話可以延續到不同服務渠道，讓登入前的問題和登入後的操作接成同一段互動。這對追蹤一件事如何完成很重要。
企業可以開放網站、介面或自己的代理
Personal Agent Protocol 的設計允許三種路徑：企業網站、API，以及企業自己的代理。API 是提供給軟體呼叫的服務介面，適合讓系統直接取得資料或執行功能。
不同企業可以按需求選擇路徑。簡單查詢可能直接呼叫介面，涉及保固等需要多輪溝通的工作，則可能經由企業代理處理。這個彈性讓標準更容易對應現有服務，但也意味著使用者不能預設每家企業支援相同功能。
正式規格與未來擴充仍需分開看
Sierra 規劃發布 v0.1、舉辦設計工作坊與提供參考實作。更細的權限、推播通知和支付擴充，則列為後續可能方向。
我支援把連線和授權公開討論的方向，因為跨企業代理不能只靠每個平台自行定義規則。下一步應看規格是否按計劃公開、參與者能否實作，以及使用者能否清楚撤回或限制權限。
個人代理與企業代理，服務的是不同一方
個人代理協助使用者達成目標，企業代理則依公司的服務與政策處理請求。兩者可能都使用 AI，但責任與可用資料不同。建立共通協定，是讓雙方能清楚交換需求與授權，而不是把企業系統全部交給個人助手。
以訂單查詢為例，使用者希望快速知道商品進度，企業需要確認帳號與訂單是否屬於本人。即使個人代理理解使用者的偏好，也不能只憑一段自我介紹就取得企業資料。
企業同樣不能只相信代理說「使用者同意了」。它需要能核對的登入與授權方式，也要知道允許的是查詢、修改，還是其他操作。這些條件會決定協作是否能進入真正的服務流程。
我認為 PAP 的重要性，在於把這些原本分散在不同網站的問題放到共同討論。模型是否聰明是一回事，雙方如何確認身分、權限與結果，則是能否可靠代辦的基礎。
一次改訂單的構想，可以拆成幾個階段
假設使用者想更改某筆尚未出貨的訂單，個人代理可以先查詢企業入口，確認有哪些服務方式，再取得需要的登入與授權。這是依協定方向設計的情境，並非公告已完成的跨企業實際測試。
取得身分後，也要讀取當前狀態。訂單是否可改、能改哪些欄位，以及是否產生費用，都由企業規則決定。個人代理可以整理選項，不能因為使用者提出目標，就跳過服務限制。
若使用者只批准查詢，接下來需要修改時就應提出新的決定。這讓人能先理解選項，再同意具體動作。清楚的階段比一開始要求交出所有權限，更容易符合實際需要。
最後應取得結果與必要紀錄。使用者需要知道是否改成功、哪些內容變了，以及企業回覆什麼。代辦工作不能停在「已送出請求」，因為請求被接受與結果完成是不同狀態。
既有網站、服務介面與企業代理可以並存
官方說明涵蓋網站、API 與企業代理等連線方向。API 是供程式呼叫服務的介面，MCP 與 OpenAPI 則可以協助描述工具與操作。不同企業有不同既有系統，因此共通協定需要容納多種入口。
這種方向的好處是，不必假設所有企業都在同一時間改成同一套軟體。有些服務可能先透過網站提供，有些已經有程式介面，其他則有自己的客服代理。協定處理的是如何連線，而不是統一所有內部實現。
不過，支援多種方式也需要清楚描述各入口能做什麼。網站能檢視資料，不代表介面已允許同樣修改。企業代理能回答問題，也不代表所有後臺操作都開放。能力應該逐項被發現與確認。
對開發者，我會先確認目標企業提供哪些入口，再決定連線方式。只看到協定名稱，很難推論某一家公司已能處理哪些任務，實際支援仍需要當前文件。
訪客與登入狀態，對應不同服務範圍
企業網站往往允許訪客檢視公開商品與一般資訊，但帳號資料需要登入。個人代理也應區分這兩種狀態，不能因為能讀取公開頁面，就認定可以檢視私人訂單。
OAuth 是讓使用者授予有限存取權的方法，重點是授權範圍與身分可被確認。它可以讓代理取得處理某項工作所需的權限，而不必把密碼直接交給代理平台。
實際應用還需要知道授權的時間與物件。使用者可能只想讓助手查一次訂單，不希望它永久保有修改能力。是否支援這種範圍與到期方式，應依最終規格和企業實現確認。
我會把登入視為一個重要分界。訪客探索適合先找資訊，登入之後才可能接觸個人服務。把分界說清楚，能讓使用者更容易知道自己在什麼時候交出了哪些能力。
個人授權與企業政策，必須同時成立
即使使用者已同意，企業仍可能不允許某個操作。例如訂單已出貨、服務已超過修改期限，或該項請求需要其他確認。協定不會替企業改寫業務規則，代理應能把限制說明清楚。
反過來，企業提供某個功能，也不代表代理已取得使用者同意。查詢、取消與付款可能都在服務範圍內，但個人授權仍應只包含當次需要的部分。兩邊條件都成立，操作才有依據。
這種雙方規則需要在結果中保留。若請求被拒絕，應知道是企業政策不允許、身分尚未確認，還是權限不足。不同原因會導向不同下一步，不能一律重新送出。
我的看法是，清楚回報限制能提升代辦的實用性。代理不需要每件事都成功，但需要讓使用者知道哪些選項仍可行，哪些已經不符合條件，才不會在流程中浪費時間。
開放標準的價值，要由共同實作證明
多家企業參與討論有助於建立共通需求，但參與名單不等於每家公司所有服務都已上線。標準需要規格、實現與互通測試，才能知道不同系統是否真的以相同方式理解請求。
官方預計稍後公佈 v0.1，並安排相關工作。這表示目前重要成果包含合作方向與規格開發，不能把未來計劃寫成已經全面部署的產品功能。
對企業，早期參與可以幫助整理自己的權限、服務入口與錯誤狀態。對個人代理平台，則需要思考如何把技術授權轉成使用者看得懂的確認內容。兩邊都需要完成實際設計。
我認為開放標準值得支援，原因是它可能減少每個組合各自重做連線的成本。但是否真的減少整合工作，仍要看後續文件、參考實現與不同系統之間的證據。
付款與主動通知，應保留目前與未來的區別
官方提到更細的權限、主動通知與付款相關能力是後續方向。它們很容易引起想像，但新聞應保留推出階段，不把規劃功能寫成今天就能使用。
主動通知可能讓代理更及時取得狀態，付款則讓代辦進入更有後果的階段。兩種能力都需要清楚說明誰觸發、使用者同意什麼，以及如何知道結果，這些問題不能僅靠模型推理解決。
對使用者，現階段可以關注最終規格如何呈現這些條件。若未來服務支援，也應從小範圍任務開始理解流程，而不是因為有共同協議就把所有日常事務一次交給助手。
我的判斷是，PAP 是否成熟，會體現在這些重要步驟能否被清楚核對。能力增加之後，使用者仍應看得懂自己的授權與結果，才能真正減少操作負擔。
企業準備連線前，可以先整理自己的服務邊界
即使規格仍在發展，企業也能先盤點哪些工作適合由個人代理提出。公開資訊、帳號查詢與實際修改，應該有不同範圍。需要人工處理的情境，也應有明確轉接方式。
接著可以整理每種操作的輸入、完成狀態與失敗原因。若這些資料原本就不清楚，連線任何代理都會增加混淆。共同協議提供交換方式，企業仍要負責定義自己的服務。
也應讓使用者能看見關鍵決定。例如取消訂單之前說明影響，完成後回傳確認內容。清楚的服務設計能同時幫助人類與代理，不必等到所有 AI 技術都成熟才開始整理。
PAP 的前景在於讓個人助手與企業服務有共同語言。對我而言，最值得觀察的後續不是參與公司又增加多少，而是一個具體任務能否從授權、執行到結果都留下可理解的證據。
使用者看到的確認，應該對應實際授權
技術規格里的權限名稱，最後需要變成一般人看得懂的說明。若使用者看到「處理訂單」，實際範圍卻同時包含查詢與修改，就可能產生理解落差。協議發展時，這種產品設計值得和技術驗證一起討論。
企業與個人代理可以分別保留必要紀錄，但使用者也應能取得自己的結果。清楚說明動作與狀態，會讓代辦更容易核對，尤其一項工作在多個服務之間進行時。
我會關注最終規格如何連線技術與介面。開放標準最有意義的成果，是讓使用者能理解誰代表自己做了什麼，而不是只讓系統之間多一種交換格式。
Personal Agent Protocol 常見問題
所有合作企業都已經全面啟用嗎？
公告說明共同開發及後續規格規劃，沒有表示所有企業的全部業務都已接通。實際可用範圍仍取決於各企業的實施。
它和 Decagon 的 PACT 一樣嗎？
兩者都處理個人代理與企業互動。PACT 已公開自己的授權設計，Decagon 也宣布加入 Personal Agent Protocol 工作組，但不能把兩個名稱當成同一份已定稿規格。
結語：代理能做什麼，需要有共同的授權語言
Personal Agent Protocol 的意義在於讓消費者、企業與代理開發者共同定義連線方式。規格公開與實際實施會決定它能走多遠，使用者則應繼續用具體權限判斷每項任務。
