Sierra 公布了 《個人代理協定》草案 0.1，也就是 Poppy，時間是 10 月 9 日，比 與 Meta 等夥伴宣布這項計畫晚了三天。這份新文件把發布時的廣泛願景，轉化為一套提議中的規則，說明如何找到公司的代理介面、識別個人代理、讓客戶登入，以及如何讓同一次造訪跨越網站、API 與公司代理。

這仍是草案。規格指出，穩定版本推出前，任何部分都可能變更，包括不相容的變更。Sierra 也 新增了 35 家設計合作夥伴。參與設計過程並不代表這些公司已部署 Poppy 介面。

重大變化

  • 變了什麼： 10 月 6 日的公告描述個人代理與企業互動的方式；10 月 9 日的草案則詳述公司與代理需要實作的身分、權限及工作階段交換流程。
  • 為何重要： 客戶可以授權代理執行帳戶工作，同時由公司識別該代理並限制其存取。草案把這項控制連結到網站瀏覽、API 和對話，但公司可自行選擇提供哪些管道與權限。
  • 接下來觀察： 實作者現在有具體介面可檢視，同時也有尚未解決的付款、通知及附件規則。Sierra 計畫在接下來一個月舉辦設計工作坊並發布參考實作；目前兩者都還不能證明互通性已廣泛實現。

探索從公司的網域開始

依據 草案規格，參與的公司會透過 HTTPS 發布 /.well-known/poppy.json 。該文件列出其組織與 OAuth 發行者、支援的登入方式，以及它提供的網站工作階段端點、OpenAPI 或 MCP API，或公司代理對話端點。公司不必提供每一種路徑。代理會用這份檔案探索可用功能，而不是把網站當成唯一入口。

這份檔案本身不能授權代理。其組織網域必須與代理要求的網域相符。代理也必須檢查 OAuth 伺服器中繼資料：發行者必須與檔案相符，而且其 poppy_domains 清單必須包含該組織的網域。這些檢查旨在防止無關網域冒稱其他公司的發行者並取得權杖。

個人代理透過 HTTPS 的 client_id URL 識別自身；該 URL 會提供用戶端中繼資料，包括公開簽署金鑰與允許的重新導向位址。公司可以要求事先註冊、封鎖或撤銷代理 ID，並限制工作階段建立。這些是草案賦予公司的控制權；它沒有要求每家公司都必須接受每個代理。

訪客工作階段可轉為帳戶工作階段

個人代理會為使用者建立一個依公司而異、穩定且不透明的 ID，並以簽署的聲明啟動工作階段。公司會回傳一個未登入工作階段權杖。這讓公司能在不同工作階段辨識同一代理與使用者，但不會把該使用者視為已登入。草案禁止以姓名、電子郵件地址或電話號碼推導該使用者 ID，即使使用帶金鑰的雜湊也不行。

若要存取帳戶，公司會公布其支援的登入方式。直接登入會在使用者的瀏覽器中使用 OAuth 授權頁面與 PKCE。裝置登入會要求使用者透過連結和代碼前往公司頁面。中介登入則讓代理將使用者提供的憑證提交到指定的公司端點；這是獨立且可選的路徑，並有明確的憑證處理與速率限制規則。草案承認一項信任限制：公司不一定能確認是人而非代理完成了直接登入頁面。

權限以範圍表示。Poppy 定義了廣泛的 poppy:read 與 poppy:write 範圍，同時允許公司改提供較窄的自訂範圍。公司不能授予超過代理要求的權限，也不能超過特定登入方式允許的權限。登入後核發的帳戶權杖，讓代理可在核准範圍內取得後續已登入工作階段權杖。若工作需要更多存取權，使用者必須重新登入並核准那些範圍。

兩種權杖的區別很重要。工作階段權杖有效期短，用於 API 呼叫和對話。帳戶權杖則是有效期較長的 OAuth 更新憑證，只能用於公司的權杖與撤銷端點。草案要求代理不得把它放進模型上下文、訊息、日誌或 URL。登出會撤銷帳戶權杖，並登出與其連結的工作階段；公司也能結束這些工作階段。先前核發的工作階段權杖仍可能有效，因此草案建議公司在每個請求中檢查工作階段狀態，或使用短得多的權杖有效期。

一個工作階段，三種可能路徑

Poppy 提議讓使用者透過個人代理進行的活動共用一個公司工作階段。對 OpenAPI 呼叫與公司代理對話，代理會在授權標頭中傳送工作階段權杖。草案通常會用代理持有的金鑰與 DPoP 證明綁定這些權杖，並要求公司在每個請求中驗證。MCP 是明確例外：其授權使用限於所列 MCP 伺服器的 bearer 權杖，而且草案僅允許在 MCP API 使用該形式。這些是協定要求，不代表已證明某項實作安全。

網站瀏覽以不同方式加入同一工作階段。若公司發布瀏覽器工作階段端點，代理的瀏覽器會提交短效簽署聲明，並取得公司自己的工作階段 Cookie。接著網站會套用工作階段目前的登入狀態與範圍。若沒有該端點，代理會像一般未登入訪客一樣瀏覽。Sierra 的 發布帳戶 描述跨管道的一次造訪；草案則規定在此共用工作階段下，瀏覽器流量與 API 流量使用不同憑證。

公司可在探索檔案中列出 OpenAPI 描述、MCP 伺服器及對話端點。草案說明一種 Poppy 對話格式，用於與公司代理交談，並在需要時引入真人。每個 API 的結構描述仍由該 API 自行決定。公司決定公開哪些路徑，即使在已登入的工作階段中也可以限制代理的操作。

草案尚未解決的事項

協定的 未解決主題頁面 列出三項較大的缺漏：付款、沒有開啟請求時的推播通知，以及收據、標籤、圖片或表格等附件。頁面指出清單並不完整。草案範例使用虛構公司和佔位憑證。

Sierra 於 10 月 9 日的貼文描述了一場 Meta Muse 與 Rocket 的會議示範。這是 Sierra 對一場安排好的示範所作的敘述，不是對正式部署的獨立稽核。Sierra 表示，將在接下來一個月舉辦設計工作坊並發布參考實作。目前，Poppy 是一份已發布、包含實作細節且設計夥伴名單持續擴大的提案。它實際能觸及多少範圍，取決於哪些公司和個人代理建置者實作相容版本，以及他們實際提供哪些存取權。

來源與延伸閱讀

  • 《個人代理協定》規格草案 0.1，更新於 2026 年 10 月 9 日。探索、身分、登入、範圍、權杖、工作階段與管道規則的主要來源。文件明確允許穩定版本推出前出現不相容變更；範例為虛構情境。
  • Poppy 未解決主題，更新於 2026 年 10 月 9 日。列出目前草案未涵蓋的付款、推播通知與附件；頁面指出還可能有其他缺口。
  • Sierra 10 月 9 日公告。記錄發布日期、另外 35 家設計合作夥伴、所述的會議示範，以及計畫中的工作坊／參考實作。這些是 Sierra 的說法，不是部署證據。
  • Sierra 10 月 6 日介紹。說明最初公告提出的構想，以及後續技術草案帶來的變化。