Decagon 開源 PACT：企業怎麼確認 AI 代理代表誰、能做什麼？
Decagon 與 Instinct 公開 PACT，以 A2A 和 OAuth 分開驗證代理身分與使用者授權。解析查詢、修改與追加權限如何在同一段任務中處理。
當個人 AI 替你聯絡企業，企業需要知道兩件事：這個代理從哪個平台來，以及你允許它做什麼。Decagon 的 PACT 將這兩種確認分開，避免只認出代理身分，就把它當成有權操作客戶帳號。
2026 年 10 月 6 日，Decagon 與 Instinct 在官方公告公開 Personal Agent Consent & Trust Protocol。PACT 建立在 A2A 與 OAuth 之上，前者讓代理交換訊息，後者處理使用者授予的存取權。
PACT 先辨認代理，再確認客戶授權
企業先提供可被發現的代理資訊，內容包括服務位置、驗證要求和能申請的權限。個人代理連線時，會以可驗證的簽章證明自己來自哪個平台。
這一步只確認平台身分，還沒有證明它能操作某個客戶帳號。把兩件事分開，可以避免「知道誰在呼叫」被誤當成「知道誰同意了操作」，這是 PACT 的核心設計。
登入留在企業，代理取得有限授權
要存取客戶帳號時，PACT 讓使用者透過企業的登入頁完成身分驗證，並選擇批准的權限。個人代理不需要處理使用者的登入密碼。
接著，系統發出短期有效的授權憑證，把客戶、代理平台、目標企業與批准範圍綁在一起。這讓每次操作都能回到同一份授權，而不是依賴聊天中的一句模糊同意。
查詢與修改可以取得不同範圍
企業可自行定義權限，例如讀取訂單與取消訂單。若使用者只允許查詢，代理就應只在這個範圍工作，不能因為看得到訂單就直接修改。
當任務需要額外權限，協定允許在同一段對話中提出追加要求。這對多步驟工作很重要，因為使用者可以先看清選項，再決定是否授權會改變帳號或訂單的動作。
企業政策與操作紀錄仍然保留
PACT 設計讓個人代理表達需求，由企業代理依企業政策執行相關工具。回覆可附簽署的收據，記錄使用了哪些權限和執行了哪些動作。
我的判斷是，這比把私人帳號完整交給助手更容易管理。實際效果仍需看企業與代理平台如何實施，尤其是權限到期、撤回和異常操作是否處理清楚。開放規格提供共同方法，但不能自動變成每個系統的安全認證。
兩份憑證分別回答「誰在連線」與「誰授權」
PACT 將代理平台身分和客戶授權分開。平台身分說明請求來自哪個代理服務，客戶授權則說明它是否得到某位客戶批准，以及允許做什麼。兩件事相關，卻不能互相代替。
可以用辦事的情境理解：知道來的人屬於哪家公司，不等於知道他有權處理某個客戶的訂單。系統必須同時核對來訪者與客戶委託，才能判斷請求是否符合範圍。
官方設計使用可驗證的短期憑證，讓企業在請求中檢查這些條件。JWT 是一種攜帶簽署資訊的憑證格式，企業能夠確認資料是否來自相應發行者。它不是讓任何持有人無限操作的通行證。
我認為這種拆法有實際意義，因為代理平台可能同時服務很多客戶。若只驗證平台，就無法確定每次操作屬於誰。若只看客戶帳號，又可能缺少對代理來源的確認。
Agent Card 幫助發現入口，但不代表已取得權限
A2A 的 Agent Card 可以理解成企業代理的能力說明，包含服務位置與可用資訊。個人代理先知道如何連線，再依企業要求完成驗證，避免只靠猜測網站或操作方式。
這份說明的價值在於讓能力可被發現，但發現與授權是不同階段。某張說明卡列出取消訂單的權限，不代表任何連線者都能使用。使用者仍需要批准，企業也要核對具體請求。
企業應讓描述符合實際能力。若某項操作只對部分客戶開放，或需要額外條件，就應在後續流程體現，不能因為代理讀到功能名稱，就假設所有情境都成立。
對開發者，我會把能力發現當成入口，再建立權限與結果檢查。只有前者，代理可能知道去哪。補上後兩者，才比較接近能可靠完成工作。
直接在企業登入，減少代理處理密碼的需要
PACT 使用 OAuth 裝置授權流程，讓使用者在企業端完成登入與同意。裝置流程適合把登入步驟從代理對話中分開，讓企業確認客戶，而不是讓助手代收密碼。
使用者看到授權時，應能辨認企業與請求範圍。若只是查詢訂單，就不應在沒有需要的情況下要求更廣泛修改能力。清楚的權限文案，會影響使用者能否作出真正理解的決定。
完成登入後，短期授權憑證將客戶、代理平台、企業與批准範圍關聯。這樣企業可以把每次請求回到同一份授權，而不是僅依據聊天記錄判斷使用者是否同意。
本文沒有將這種設計當成所有實現都已通過安全審查的保證。協議提供方法，實際系統仍要正確驗證、管理到期與處理異常，才能讓設計發揮作用。
範圍應該貼近任務，不必一次要求全部能力
權限範圍可以區分讀取與修改，也可以依企業服務細分。一個助手先查詢訂單，再提出取消選項，通常不需要在第一步就取得所有操作權限。讓範圍隨任務增加，更容易讓使用者看懂。
例如查詢後發現訂單已出貨，取消可能不適用。這時再要求修改權限就沒有意義。先取得足夠資訊，再決定下一步，可減少不必要授權，也讓流程更符合真實狀態。
企業定義範圍時，應避免名稱過於抽象。「管理帳號」可能包含很多後果，使用者很難理解。明確說明能讀取什麼、改變什麼，通常比較適合呈現在授權頁面。
我的建議是，把權限當成產品內容設計。技術上能核對範圍很重要，使用者是否理解同樣重要。若確認文案太模糊，系統即使取得一次點選，也不一定形成清楚委託。
追加授權是正常流程，不應被當成失敗
任務執行中可能發現需要更多能力，例如原本只查狀態，後來使用者決定變更。PACT 允許流程提出追加要求，讓新的動作取得相應批准，不必把最初範圍無限擴大。
這對多步驟工作很實用，因為使用者通常先需要看結果，才知道是否採取行動。代理應說明為什麼需要新增權限、會改變什麼，以及目前已完成哪些部分，幫助使用者作決定。
若使用者不批准，已完成的查詢結果仍可保留。清楚的流程應該知道任務停在哪一步，而不是把整個工作重來，或偷偷改用另一個沒有相同限制的入口。
我認為追加授權讓個人代理更接近真正協作。它承認人在看到新資訊後會改變決定，也讓重要動作有獨立依據，而不是依賴第一次對話中的泛泛同意。
企業政策仍決定操作是否能完成
使用者同意取消，不代表企業一定能取消。訂單狀態、時間與服務規則都會影響結果。PACT 的設計保留企業代理依政策執行的角色，個人助手主要表達需求並處理授權。
這種責任分配有助於避免個人代理自行猜測企業規則。若企業拒絕某項請求，結果應說明原因與可用選項，讓助手能向用戶解釋，而不是把拒絕當成需要繞過的障礙。
企業也應區分權限不足和業務條件不符。前者可能需要追加授權，後者則可能根本沒有可執行動作。錯誤原因不清楚，代理就容易重複相同請求，增加無效工作。
對我而言，協議的價值不只在成功路徑。能在不適用時給出清楚結果，讓使用者保留判斷，才適合處理真實企業服務中的各種例外。
簽署收據能保留操作紀錄，但要看記錄內容
官方設計允許回覆附帶簽署收據，記錄使用的權限與執行動作。簽署提供來源驗證方向，幫助雙方回頭核對發生了什麼，而不是只儲存一段助手自己的總結。
收據的內容也很重要。使用者需要知道目標物件、結果與時間，企業則要能把操作對應到系統狀態。若記錄只寫「已處理」，就很難解釋實際改了哪些內容。
也應區分已送出請求與最終完成。例如企業受理後仍在處理，收據就應呈現相應狀態。代理可以繼續追蹤，但不能把受理立即翻譯成所有工作已經結束。
我會把記錄看成交付的一部分。即使操作順利，之後遇到疑問時仍需要證據。讓人和系統都能理解的紀錄，比只在對話中得到一句肯定回覆更容易接手。
PACT 與 PAP 的關係，要從範圍理解
Decagon 表示加入 PAP 工作群，同時與 Instinct 推出 PACT。PAP 討論個人代理與企業連線的廣泛方向，PACT 則更集中在同意、身分與信任的技術安排，兩者不宜簡單寫成誰取代誰。
開放協議仍需要後續規格、實現與互通。企業參與討論，不等於所有服務已經採用相同方法。個人代理支援某個協議，也不代表每家企業都能立刻完成同一項任務。
對想匯入的團隊，可以先把自己的操作和權限整理清楚，再看哪些標準符合需要。若內部服務邊界不明確，任何新協議都難以替團隊自動解決業務判斷。
PACT 給出的方向，是讓代理身分、使用者批准與企業政策同時可核對。未來是否有實際價值，應看具體流程能否安全接續、清楚回報，並在使用者不批准時保留可理解的停止點。
到期、撤回與重複請求，需要有可理解行為
短期憑證意味著授權可能到期，使用者也可能改變決定。系統在這些情況下如何回應，應由實際實現說明。不能因為協議採用短期設計，就替所有平台保證已經具備同樣撤回功能。
代理收到權限失效時，應先說明狀態，再決定是否需要使用者重新授權。若反覆自動嘗試相同請求，可能只增加無效工作。清楚的失敗路徑讓人知道目前沒有完成什麼，也讓下一步有明確依據。
重複操作同樣值得考慮。一次取消請求送出後，代理應該知道結果，而不是因為沒有及時看到回覆就再次取消。協議與企業工具需要提供足夠狀態，使用者才能判斷是否應繼續等待或聯絡服務。
我會將這些情境放進匯入測試。成功操作展示能力，到期、拒絕和重複請求則展示系統能否保持正確邊界，兩者一起才比較貼近真實代辦。
PACT 常見問題
A2A 與 OAuth 各自做什麼？
A2A 提供代理之間的發現和溝通方式，OAuth 讓使用者授予有限存取權。PACT 指定它們如何配合，讓企業同時核對代理與客戶授權。
企業一定要開放取消訂單嗎？
企業自行定義可申請的權限與允許的操作。協定統一的是如何發現與取得授權，不會替每家企業決定業務政策。
結語：把同意變成每次操作都能核對的條件
PACT 的價值在於分開身分、授權與企業政策。對想讓 AI 代辦事情的使用者，清楚看到允許範圍與操作紀錄，比只知道代理能與企業對話更有意義。
