AgentID 公開推出：AI 代理有自己的登入身分，誰擁有它、能做什麼怎麼分？

當 AI 代理開始替人操作網頁，登入往往成為最不自然的一步。使用者希望它完成工作，網站卻通常只知道一個人類帳號正在操作。如果同一個人管理多個代理，哪個代理建立了帳號、用掉哪些配額、該停用哪一個，便很難從既有登入資料看清楚。

AgentMail 在 2026 年 10 月 6 日的 AgentID 公開發布文 中，提出讓代理以自己身分登入的方案。每個 AgentMail 信箱對應一個 AgentID，接受這種登入的應用可以辨識代理，並在取得相應授權時知道它的真人擁有者。官方以「給 AI 代理的登入按鈕」描述產品。

它值得關注的地方，是把代理帳號與擁有者關係變成應用能讀取的資料。這個身分基礎有助於配額、追蹤與停用，卻不會自動決定代理能做哪些事。讀者需要分開看身分驗證、資料揭露與應用內權限，才能判斷它能解決哪一段問題，以及整合後還留下哪些工作。

代理登入自己的帳號，為什麼與借用主人帳號不同？

借用主人帳號的優點是可以沿用既有服務，但活動紀錄容易把人與代理混在一起。若代理處理不同任務，又共用一個帳號，遇到問題時可能只能暫停整個帳號。讓每個代理有獨立身分，能讓網站把紀錄連到更明確的操作主體，方便分別管理。

例如，假設公司有一個蒐集公開資料的代理，以及一個整理客服工單的代理。兩者由同一個人管理，但使用不同服務與配額。若網站能辨識每個代理，就有機會單獨停止某一個的登入，保留另一個的正常工作。這是本文的管理情境示例，並非官方公佈的企業實測。

網站同時需要知道它們的擁有者，才能處理一個人建立多個代理的情況。單看不同信箱，可能把十個代理當成十個無關客戶。加入擁有者關係後，應用便有依據按人或組織管理配額，真正的配額規則仍由接入網站決定。

這也說明 AgentID 的定位與反機器人偵測不同。反機器人工具可以判斷流量是否像自動化，卻未必能告訴網站這個代理屬於誰。AgentID 關注的是帳號身分與擁有者紀錄，可以與網站其他流量管理方法並存，並沒有宣稱接受登入後就不需要處理異常使用。

OpenID Connect 讓它接入既有登入系統

AgentID 採用標準 OpenID Connect，縮寫 OIDC。這是一種讓應用透過身分提供者取得登入證明的協定。使用者常見的第三方登入，也採用類似分工：網站信任特定提供者簽發的證明，再建立或識別自己的本地帳號。

官方提供 Clerk、Supabase、Auth0、Better Auth 與 Auth.js 等整合文件，也有自訂 OIDC 的參考。這表示部分團隊可以沿用既有登入框架，不必重新設計整套身分協定。不過，「支援協定」與「每個應用不用修改就能完成」仍是不同事情，帳號映射與權限規則需要接好。

登入後，應用會收到代理的穩定識別值及依授權範圍提供的資料。官方文件說明，信箱在其生命週期中有穩定 subject，也就是用來識別登入主體的值。刪除信箱後，即使重建相同地址，新信箱仍有不同識別值，因此不能只把 email 當成永久不變的帳號主鍵。

這對維護歷史紀錄很重要。若應用只按地址把新舊帳號自動合併，可能把已停用代理的資料或配額接回新身分。比較合理的做法，是保留提供者的主體識別值，再依自己的帳號政策處理地址變更與重建。這是由官方識別規則延伸出的整合判斷。

驗證代理身分，不等於讀取它的信箱

發布文說明，接受 AgentID 登入不會讓應用取得代理郵件內容，也不需要代理把密碼交給接入網站。代理信箱是可用於聯繫的身分地址，與允許網站讀信是不同權限。應用可以寄送一般通知給該地址，是否由代理讀取或處理，屬於另一段工作流。

這種區分能降低整合者的誤解。看到一個與信箱相連的登入方式，不代表登入按鈕附帶郵件存取能力。相反地，若產品真正需要代理讀取郵件，還必須另外確認它的工具、授權與資料範圍。新聞介紹身分協定時，不應把其他平臺功能一起包進來當成預設。

網站收到的登入證明也需要驗證。官方文件要求檢查簽章、發行者與目標應用等資訊。用白話來說，應用要知道這份證明確實由信任的提供者發出，而且是發給自己。只把收到的文字拆開、看到 email 欄位，就當成登入成功，沒有完成這段身分驗證。

身份正確之後，應用才有基礎決定如何對待它。例如是否讓它建立工作區、只讀取公開資料，或沿用某個組織配額。這些決定不包含在「它是某個代理」的證明裡。將驗證與權限分開，可以讓整合者知道每一項產品行為由哪一段設定控制。

真人擁有者資料，需要相應範圍與授權

現行官方文件區分開放客戶端與已註冊客戶端。開放客戶端不能要求真人擁有者資料，已註冊應用則能在相應範圍獲準時收到擁有者姓名與 email。這裡的 scope 指本次登入請求取得的資料範圍，並非應用只要加上按鈕就一定得到全部欄位。

文件也說明，揭露擁有者資料需要 AgentMail 憑證具有 App: Share Owner 權限。若沒有，代理不能單獨完成相應登入，擁有者需要從自己的帳號覈准。這讓「代理能辨識自己」與「網站能取得主人聯繫資訊」保持不同的條件，應用設計應明確顯示自己的資料需求。

在截至本文查閱時的文件中，已獲準的 owner_name、owner_email 可以出現在 ID token 與 userinfo。ID token 是登入身分證明，userinfo 則是取得已授權身分資料的介面。較早介紹文的欄位位置與現行文件有差異，因此實作應使用當前技術文件，並核對實際回傳。

另一個容易漏掉的環節，是登入套件可能只保留標準欄位，沒有把額外的擁有者資料存進應用工作階段。官方文件明確提醒這點。因此，看見提供者回傳資料，不等於自己的系統已能使用它。整合驗收要回到應用內真正用於配額與帳號管理的資料。

應用能如何使用擁有者關係，又不能從中推論什麼？

擁有者關係可以協助網站把同一人管理的多個代理放在同一個配額範圍。例如應用可以按 owner_sub 聚合使用量，而不是依每個代理地址各送一份免費額度。owner_sub 是不直接顯示原始姓名的擁有者識別值，適合用來連結，而不是拿來猜測個人的其他資料。

驗證過的擁有者 email 也不是代理每個行動都已得到主人個別同意的證明。它說明代理與帳號擁有者之間的身分關係。某項付款、公開發布或資料變更是否被允許，仍要回到該應用的權限與操作規則。把身分關係直接當成所有行為授權，會擴大登入功能的範圍。

活動紀錄最好同時保留代理識別、擁有者連結與具體操作結果。這樣才能回答哪一個代理在何時使用多少配額，而不是只留下「某人登入過」。網站可以按任務管理代理，也可以讓擁有者看見各代理的活動。是否提供這些介面，仍取決於接入網站的產品實作。

這些設計對代理服務尤其重要，因為代理不一定只執行一次短任務。工作可能在不同時間恢復，或由不同版本接續。穩定身分能提供活動的連結點，但不能代替對工具權限、任務狀態與完成結果的管理。AgentID 補上的是身分層，其他層仍需配合。

有效期與停用規則，決定帳號能否真正收回

現行文件列出不同有效期：登入交易五分鐘、授權碼六十秒且只能使用一次、ID 與存取 token 十分鐘。較長的應用工作階段由接入應用自己建立，文件沒有提供更新 token。讀者要分清楚，短期登入證明過期與應用把使用者登出，並不是自動相同的一件事。

代理瀏覽器持有的登入憑證另有三十天有效期，應用同意紀錄則從上次登入起保留一百八十天。官方圖解把同意與憑證分開。同意紀錄還在時，憑證可能已經不能使用。撤銷憑證之後，先前的同意紀錄也可能繼續存在，因為不同時間控制的是不同環節。

撤銷代理登入憑證會阻止它用該憑證再登入，但不會自動終止所有接入應用已建立的工作階段。清掉某個瀏覽器的登入資料，也只影響該瀏覽器。若擁有者想完全停止代理在某個應用的活動，該應用仍需要處理自己的工作階段與執行中的任務。

這個差別會影響客服與管理介面的文字。按鈕若寫「停止新登入」，就應對應撤銷登入憑證。「立即停止所有工作」則需要涵蓋應用工作階段和任務。本文沒有執行任何撤銷或登入操作，這裡說明的是官方文件中的行為界線，避免把一項控制誤寫成全面停用。

一千萬代理的說法，是觸及主張而非客戶保證

公開發布文用「一千萬代理能找到你」說明目錄觸及。公司把 AgentMail 信箱與 AgentID 對應，並透過目錄、API 與命令列工具讓代理發現接受登入的應用。這是平臺對可被發現範圍的主張，沒有在該文提供一千萬活躍真人客戶或付費訂閱者的證據。

接入目錄可以降低代理尋找適合服務的摩擦，但實際使用仍取決於產品是否能完成任務。若服務需要很多純視覺手動操作，即使登入成功，代理也可能難以繼續。登入與發現改善了入口，穩定的功能介面、清楚錯誤回應與合理配額則決定後面的體驗。

官方列出 Firecrawl、Turso、TinyFish、Manufact、Telnyx 與 Rho 等接受登入的應用，完整目錄會持續變動。這份名單表示產品整合方向，不能推論各應用都提供相同權限、價格或服務品質。讀者真正要使用時，仍需查看該應用自己的條件與支援範圍。

官方說明，應用接受 AgentID 登入沒有每次登入費用，AgentMail 則透過信箱服務收費。這兩項計費要分開看。免費增加登入入口，不代表代理建立與使用信箱、執行工具、呼叫模型或接入其他應用的所有費用都免除，總成本仍與實際工作有關。

常見問題：什麼情況值得考慮 AgentID？

若產品開始遇到多個代理共用主人帳號、難以歸屬使用量，或想讓代理建立自己的服務帳號，這種身分方案值得評估。它能提供穩定代理識別與相應的擁有者連結。若現有服務只是讓一個代理使用已限定權限的 API，則可以先檢查目前方法是否已足夠。

是否接入後就不必管理 API 金鑰？登入與工具授權處理不同環節，依應用設計仍可能需要 API 憑證。AgentID 沒有把所有服務的工具權限改成同一套。較合理的導入順序，是先說清楚自己需要獨立代理帳號，還是讓代理在既有帳號內執行受限任務。

是否可以把擁有者 email 當成每個代理行為的責任結論？它提供帳號關係與聯繫線索，並沒有解決所有組織授權與行為歸屬問題。產品應保留實際操作與權限紀錄，才能在出現爭議時重建過程。單一身分欄位難以描述整個代理工作流。

AgentID 的發布顯示，AI 代理正在從借用人的登入方式，走向可被網站明確辨識的帳號。它最實際的價值，是讓身分、配額與活動連結更清楚。把登入證明、擁有者資料與應用權限接好，並確定停用能到達需要的環節，才有機會把新入口變成可管理的服務。

資料來源

• AgentID：Introducing AgentID，2026 年 10 月 6 日公開發布文。
• AgentID 現行技術文件，截至 2026 年 10 月 8 日查閱的客戶端、欄位、資料範圍、有效期與停用規則。
• AgentMail 九月介紹 提供產品背景，欄位實作以現行文件為準。圖片採用官方發布主視覺與官方有效期區塊截圖，本文未建立帳號、登入應用或執行整合。